敏捷開發流程詳解

敏捷開發流程詳解 

 

1       敏捷開發流程

ü   敏捷軟件開發核心是迭代式開發，增量交付。 

ü   每一次迭代都創建在穩定的質量基礎上，並做爲下一輪迭代的基線，整個系統的功能隨着迭代穩定地增加和不斷完善。每次迭代要邀請用戶表明（外部或內部）驗收，提供需求是否知足的反饋。

ü   迭代型的方法就是將整個軟件生命週期分紅多個小的迭代，每一次迭代都由需求分析、設計、實現和測試在內的多個活動組成，每一次迭代均可以生成一個穩定和被驗證過的軟件版本。

ü   迭代建議採用固定的週期（1-4）周，能夠每一個迭代週期不必定要相同，但迭代內工做不能完成，應該縮減交付範圍而不是延長週期。

1.1      敏捷流程詳解圖-敏捷流程圖

1.2      敏捷流程三種角色及其職責

角色名稱	角色定義	角色職責	注意事項
Product Owner（PO）- 產品負責人	確保Team作正確的事	l   表明利益相關人（如用戶、市場、管理等），對產品投資回報負責 l   肯定產品發佈計劃 l   定義產品需求，根據市場價值肯定功能優先級 l   驗收迭代結果，並根據驗收結果和需求變化更新需求清單和優先級	l   除了客戶需求以外，內部任務如重構、持續集成環境搭建等也由PO歸入統一管理
Scrum Master（SM）- Scrum 教練	確保Team正確的作事	l   輔導團隊正確應用敏捷實踐 l   引導團隊創建並遵照規則 l   保護團隊不受打擾 l   推進解決團隊遇到的障礙 l   保證開發過程按計劃進行，組織站立會，衝刺評審會，衝刺回顧會議	l   不命令和控制Team
Team – 開發團隊	負責產品需求實現	l   負責估計工做量並根據自身能力找出最佳方案去完成任務且保證交付質量 l   向PO和利益相關人員演示工做成果（可運行的軟件） l   團隊自身管理、持續改進	l   通常由5-9人左右跨職能領域人員（開發人員、測試人員、設計師等）組成 l   團隊車管員構成在sprint內不容許變化 l   有共同的目標、共擔責任 l   團隊成員嚴格遵照團隊規則

 

1.3      敏捷開發流程詳解

1.3.1   流程圖詳解步驟

1.          制定產品需求列表

ü   PO收集來自客戶、市場、領導等渠道的信息，從業務角度和市場價值編制一份按優先級排序的、明確的、可度量的、合理的產品需求列表；

2.          召開計劃會議

ü   PO召集TM和SM（也可邀請其餘利益相關者參加）召開計劃會議（發佈計劃會議和衝刺會議一塊開），發佈計劃主要是說明產品完整交付給客戶的計劃時間和交付物，

ü   衝刺計劃就是肯定該衝刺階的長度（建議衝刺長度1-4周）、目標和衝刺任務單及其工做量估算（以理想人天manday=7.5h估算，單位爲小時計算），會議時間建議不要超過6h時間；

ü   在計劃會議上就須要進行確認，是否須要使用持續集成；若使用持續集成，團隊須要天天下班前至少提交一次私有構建成功的代碼到服務器，而且要求寫詳細的日誌信息；若不使用持續集成，團隊天天有完成任務單的狀況，都須要在svn上以增量形式發包並通知到相關人員；

ü   項目計劃會議上能夠肯定天天站立會時間及其規則要求（建議會議時間在15-20分鐘左右），每一個人回答3個問題：昨天作了什麼，遇到什麼問題，今天要作什麼。具體問題討論及其解決，在私下進行溝通，不要在會議上討論。站立會上只有TM人員有發言權，其餘人員不要干預，SM主要是維護秩序、規則及其引導做用。

3.          需求分析、設計、編碼和測試：

ü   計劃會議結束後，TM獲取各自的衝刺任務單進行後面的需求分析、設計、編碼和測試；

ü   這裏特別要說明的是，開發和測試是並行工做，必要的文檔仍是須要輸出（如：討論次數較多的功能點、備選方案不少但最後確認一種、重要功能、業務邏輯複雜的等等）。具體狀況，須要項目組根據實際狀況決定，但客戶要求交付的文檔必需要輸出；

4.          衝刺任務單和燃盡圖更新

天天SM須要根據每日站立會上TM反饋的狀況，進行更新衝刺任務單和燃盡圖或SM和TM之間達成共識，TM各自完成後進行更改狀態，這裏涉及到的文檔都會有相對應的模板供參考使用。

5.          迭代週期結束點

ü   已到迭代週期結束點，只有哪些通過測試經過的衝刺需求列表才能算是真正的完成，其餘未通過測試或測試不經過的不能算是完成。

ü   這裏要特別注意，所謂的測試經過不是說要把全部的問題都解決纔算是經過，這個要根據項目具體的要求和規定來定。尚未達到迭代結束點，該衝刺任務需求列表就完成，能夠從產品需求列表中挑選優先級高的進行開發。

6.          衝刺評審會議

ü   TM須要召開衝刺評審會議，邀請PO、客戶或客戶表明來參加，由這些客戶或客戶表明來表決是否知足需求和指望目標。通常會議時間建議不要超過2個小時，參加人員除PO及其相關利益人來參加外，TM全體成員，也能夠邀請其餘相關人員參加。

7.          衝刺回顧會議

ü   迭代輸出的增量交付可能會引發原產品需求列表的改變，可能須要更新原產品需求列表；最後TM須要開展本次迭代的好的實踐和不足的改進機會，最終稿由SM整理彙總，做爲下一次的迭代的經驗參考。回顧會議建議時間不用太長，通常15-30分鐘便可，全體人員都須要參加，包括：PO、SM、TM，其餘相關人員也能夠參加。

ü   這裏要說明的是在每次的計劃會議上要注意安排時間作衝刺評審會議和衝刺回顧會議。下一次迭代的計劃會議建議在上一次迭代的衝刺回顧會議結束後再開展。

8.          重複2-7步驟

ü   直到全部列入本版本規劃的任務單都完成，最後發佈版本；

ü   特別說明：一般最後一個迭代多是全量進行驗證的週期，

 

1.3.2  管理

結合目前jira進行管理「使用敏捷開發模式的項目」也是很方便。每個迭代在jira中做爲一個版本控制，每一個迭代下面的任務單，參照迭代計劃預估的時間進行建立，實際工時根據每一個人的實際填寫日報爲準計算。能夠考慮安裝一款支持jira的敏捷開發插件GreenHopper，徹底實現電子版的看板功能和圖表功能。

在confluence上以項目名稱建立項目，而後二級目錄是每一個迭代名稱、產品需求列表，三級目錄放每次迭代衝刺評審會議紀要、衝刺回顧會議紀要、站立會紀要、燃盡圖、迭代任務訂單。

 

說明：燃盡圖使用excel表格式的模板，項目組能夠參照使用。

1.3.3   度量

類別	指標	XX項目
迭代1	迭代2	迭代3
範圍	計劃交付任務訂單數	26	14	15
實際交付任務訂單數	26	13	15
價值交付率	100%	92.85%	100%
工做量	實際完成率	開發任務完成100%（遺留大量BUG）	100%（全部任務完成，BUG清空）	100%（遺留2個偶現BUG）
	計劃估算精準度	誤差31%=（實際-計劃）/計劃	誤差31%=（實際-計劃）/計劃	誤差31%=（實際-計劃）/計劃
開發計劃估算精確度	誤差20%=（實際開發-計劃開發）/計劃開發	誤差20%=（實際開發-計劃開發）/計劃開發	誤差20%=（實際開發-計劃開發）/計劃開發
測試計劃估算精確度	誤差30%=（實際測試-計劃測試）/計劃測試	誤差30%=（實際測試-計劃測試）/計劃測試	誤差30%=（實際測試-計劃測試）/計劃測試
質量	開發測試工時比	開發工時：測試工時	開發工時：測試工時	開發工時：測試工時
	測試效率	發現有效bug/測試工時	發現有效bug/測試工時	發現有效bug/測試工時
測試驗證一次經過率（按任務單）	一次經過任務訂單/本迭代預計要完成的任務訂單*100%	一次經過任務訂單/本迭代預計要完成的任務訂單*100%	一次經過任務訂單/本迭代預計要完成的任務訂單*100%
測試驗證一次經過率（按用例）
缺陷總數
缺陷密度（個/開發工時）
缺陷級別	1:20:10:4:3
測試用例內BUG佔比
系統測試先後BUG比	NA（無單獨系統測試）	NA（無單獨系統測試）	系統測試前：系統測試後
成本	不良質量成本佔比	修復bug所耗工時/總工時
	總工時數	800人時
團隊工做負載	100%	112%	80%（學習其餘）