敏捷實施步驟與價值觀

　　做為(使用者角色)，我可以(做什麼)，以便(業務價值)。後面的業務價值在比較簡單或者大家都比較明確的時候刻意不需要註明。

　　敏捷的首要價值觀: 擁抱變化

　　一、分析需求為使用者故事

　　方法：做為(使用者角色)，我可以(做什麼)，以便(業務價值)。後面的業務價值在比較簡單或者大家都比較明確的時候刻意不需要註明。

　　價值觀：1、讓需求獨立，方便理解，分析以及實現

　　2、明確需求的業務價值

　　3、快捷增加，刪除，變更使用者故事

　　二、對使用者故事估計

　　方法：在估計會議上，主持人拿出一個使用者故事，大家對這個使用者故事分，最後取平均值

　　價值觀：1、估計是對實現規模的相對估計，不是對實際耗費資源的度量估計，因為實際的偏差可能比較大。

　　2、當某人的估計偏差較大時，說明對故事的理解上出現了一定的問題，這時是消除理解誤差的好時機

　　3、估計值不是一成不變的，當實際實現過程中發現問題時需要對該故事以及關聯的故事盡心重估

　　三、優先順序調查

　　方法：使用每個故事的功能存在問題和功能缺失問題進行調查。根據結果統計得出該故事的優先順序：基本需求、線性需求、興奮點需求、反對需求、疑問需求、無所謂需求

　　價值觀：1、通過有效調查量化的方法來劃分需求的級別，目的是為了

　　2、優先順序不是一成不變的，隨著對業務瞭解的不斷深入，以及產品的發展會對優先順序進行修正

　　四、釋出規劃

　　方法：首先要確定的是迭代週期的長度，以周為單位，然後估計出每個迭代週期團隊的速度。然後可以從使用者故事池中選擇出合適的使用者故事來填充到第一次和第二次的迭代週期中。其餘的暫時可以先不用填充，隨著每次迭代週期的完成來對釋出計劃進行更新。最後根據估計的速度和需要開發的故事來確定需要幾個迭代週期，並最終有幾個迭代週期來確定需要開發的時間週期。

　　釋出計劃可以以功能來驅動進行，也可以以日期來驅動進行。

　　價值觀：1、以月做為時間範圍，規劃物件是使用者故事，估計的單位是故事點

　　2、釋出規劃詳細程度不超過3個迭代週期，因為未完成得需求集會發生變動

　　3、選擇迭代週期1-4周，短時間的目的是可以快速反饋

　　4、功能驅動，確定要完成的使用者故事，然後根據功能的點數除以迭代值，得到需要迭代週期，算出完成時間

　　5、日期驅動，確定釋出時間，計算需要迭代週期，確立點數，填充使用者故事

　　五、迭代規劃

　　方法：對當前要進行的一次迭代週期內的使用者故事來分解成工作任務，工作任務包括設計工作，不同層次的開發工作，除錯工作和測試工作等等具體的任務，然後對任務進行估計，這時候估計的單位以理想工作小時做為單位。比如，設計需要兩個人小時，開發持久層需要1個人小時，除錯持久層需要半個人小時，開發業務層需要2個人小時，除錯中間層需要1個小時等等。。。

　　然後根據每個故事的人小時和這個迭代週期內參與的人數，以及每個人所能參與的實際有效時間(注意有效時間約為每天6小時，需要考慮到會議，討論，頭腦休息等非理想工作時間)來判斷這個迭代週期的填充是否足夠，如果不夠則再加入一個使用者故事，如果超出則移出一個使用者故事到下一個迭代週期中。

　　價值觀：1、以周做為時間範圍，規劃物件是工作任務，估計的單位是理想小時。

　　2、使用承諾驅動的方法，團隊為自己所承諾的工作負責，同時也讓規劃更趨於理性

　　5.1迭代啟動

　　方法：啟動會議

　　價值觀：團隊

　　5.2迭代進行

　　方法：每日會議

　　價值觀：溝通，掃清障礙

　　5.3迭代結束

　　方法：反饋修正

　　價值觀：不管完善團隊

　　5.4迭代測試

　　方法：同步測試/非同步測試

　　價值觀：完整性

　　六、結束髮布

　　方法：資料統計，經驗總結，收尾迭代

　　價值觀：1、統計資料做為下次相同條件釋出過程的參考

　　2、共享團隊經驗

　　3、根據客戶反饋對最終簡單功能進行收尾，複雜功能留給下個釋出版本

　　重要實踐：

　　客戶參與，頻繁釋出，外部測試，內部測試，釋出規劃，迭代規劃，結對程式設計，頻繁重構，持續繼承，程式碼集體所有。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-408744/，如需轉載，請註明出處，否則將追究法律責任。