敏捷開發之初接觸

什麼是敏捷開發？

     敏捷不是指某一種具體的方法論、過程或框架，而是一組價值觀和原則。符合敏捷價值觀和原則的開發方法包括：極限編程（XP），Scrum，精益軟件開發（Lean Software Development），動態系統開發方法（DSDM），特徵驅動開發（Feature Driver Development），水晶開發（Crystal Clear）等等。在軟件工業界，敏捷開發已成爲衆多高效開發團隊的制勝之道。在全球一百強的企業中，敏捷開發也已大行其道，受到許多資深項目管理者和開發人員的推崇。到2008年，歐美軟件企業中，有近半企業已採用敏捷方法進行開發。中國的外企，外包公司和許多知名企業也都開始採用了敏捷方法。例如，騰訊內部幾乎全部的開發團隊都在實施敏捷。敏捷方法給這些企業也已帶來了巨大的收益。

    全部符合敏捷價值觀和原則的開發方法都具備如下共同特徵：

    1. 迭代式開發。即整個開發過程被分爲幾個迭代週期，每一個迭代週期是一個定長或不定長的時間塊每一個迭代週期持續的時間通常較短，一般爲一到六週。

    2. 增量交付。產品是在每一個迭代週期結束時被逐步交付使用，而不是在整個開發過程結束的時候一次性交付使用。每次交付的都是能夠被部署到用戶應用環境中被用戶使用的、能給用戶帶來即時效益和價值的產品。

    3. 開發團隊和用戶反饋推進產品開發。敏捷開發方法主張用戶可以全程參與到整個開發過程當中。這使需求變化和用戶反饋能被動態管理並及時集成到產品中。同時，團隊對於用戶的需求也能及時提供反饋意見。

    4. 持續集成。新的功能或需求變化老是儘量頻繁地被整合到產品中。一些項目是在每一個迭代週期結束的時候集成， 有些項目則天天都在這麼作。

    5. 開發團隊自我管理。擁有一個積極的、自我管理的、具有自由交流風格的開發團隊，是每一個敏捷項目必不可少的條件。人是敏捷開發的核心。敏捷開發老是以人爲中心創建開發的過程和機制，而非把過程和機制強加給人。

    2001年2月11日到13日，17位軟件開發領域的領軍人物彙集在美國猶他州的滑雪勝地雪鳥（Snowbird）雪場。通過兩天的討論，「敏捷」（Agile）這個詞爲全體參會者所接受，用以歸納一套全新的軟件開發價值觀。這套價值觀核心是如下幾點：個體和交互 重於 過程和工具、可用的軟件 重於 完備的文檔、客戶協做 重於 合同談判、響應變化 重於 遵循計劃。在每對比對中，後者並不是全無價值，但咱們更看重前者。

敏捷開發的十二條宣言

    在敏捷開發中，咱們遵循如下的十二條準則：

1. 咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。
2. 歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。
3. 要不斷交付可用的軟件，週期從幾周到幾個月不等，且較短的週期越好。
4. 項目過程當中，業務人員與開發人員必須相互合做，貫穿項目的每一天工做。
5. 要善於激勵項目人員，給他們以所須要的環境和支持，並相信他們可以完成任務。
6. 不管是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。
7. 可用的軟件是衡量進度的主要指標。
8. 敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該可以保持恆久穩定的進展速度。
9. 對技術的精益求精以及對設計的不斷完善將提高敏捷性。
10. 要作到簡潔爲本，即盡最大可能減小沒必要要的工做。這是一門藝術。
11. 最佳的架構、需求和設計出自於自組織的團隊。
12. 團隊要按期回顧如何可以作到更有效，並相應地優化和調整團隊的行爲。

用戶故事

    用戶故事是從用戶的角度來描述用戶渴望獲得的功能。一個好的用戶故事包括三個要素：

        1. 角色：誰要使用這個功能。

        2. 活動：須要完成什麼樣的功能。

        3. 商業價值：爲何須要這個功能，這個功能帶來什麼樣的價值。

    用戶故事一般按照以下的格式來表達：

        英文： As a , I want to , so that .

        中文：做爲一個<角色>, 我想要<活動>, 以便於<商業價值>。

    舉例：做爲一個「網站管理員」，我想要「統計天天有多少人訪問了個人網站」，以便於「個人贊助商瞭解個人網站會給他們帶來什麼收益。」須要注意的是用戶故事不可以使用技術語言來描述，要使用用戶能夠理解的業務語言來描述。（說白了就是不要有技術人員的通病，專業術語一大堆，用大白話或者舉一個生活中的例子描述最好。）

    關於用戶故事，Ron Jeffries用3個C來闡釋它：

• 故事卡（Card） – 用戶故事通常寫在小的記事卡片上。卡片上可能會寫上故事的簡短描述，工做量估算等。
• 交談或者描述（Conversation）- 用戶故事背後的細節來源於和客戶或者產品負責人的交流溝通。
• 確認或驗收條件（Confirmation）- 經過驗收測試確認用戶故事被正確完成。

    用戶故事的六個特性--INVEST

    INVEST == Independent, Negotiable, Valuable, Estimable, Small, Testable。一個好的用戶故事應該遵循INVEST原則。

• 獨立性（Independent）— 要儘量的讓一個用戶故事獨立於其餘的用戶故事。用戶故事之間的依賴使得制定計劃，肯定優先級，工做量估算都變得很困難。一般咱們能夠經過組合用戶故事和分解用戶故事來減小依賴性。
• 可協商性（Negotiable）— 一個用戶故事的內容要是能夠協商的，用戶故事不是合同。一個用戶故事卡片上只是對用戶故事的一個簡短的描述，不包括太多的細節。具體的細節在溝通階段產出。一個用戶故事卡帶有了太多的細節，實際上限制了和用戶的溝通。
• 有價值（Valuable）— 每一個故事必須對客戶具備價值（不管是用戶仍是購買方）。一個讓用戶故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到這是一個用戶故事並非一個契約並且能夠進行協商的時候，他們將很是樂意寫下故事。
• 能夠估算性（Estimable）—開發團隊須要去估計一個用戶故事以便肯定優先級，工做量，安排計劃。可是讓開發者難以估計故事的問題來自：對於領域知識的缺少（這種狀況下須要更多的溝通），或者故事太大了（這時須要把故事切分紅小些的）。
• 短小（Small）— 一個好的故事在工做量上要儘可能短小，最好不要超過10個理想人/天的工做量,至少要確保的是在一個迭代或Sprint中可以完成。用戶故事越大，在安排計劃，工做量估算等方面的風險就會越大。
• 可測試性（Testable）—一個用戶故事要是能夠測試的，以便於確認它是能夠完成的。若是一個用戶故事不可以測試，那麼你就沒法知道它何時能夠完成。一個不可測試的用戶故事例子：軟件應該是易於使用的。

參考資料：

 Scrum中文網

Agile Alliance

Scrum Alliance