基于DAD方法的IBM敏捷開發過程中的敏捷管理

　　在構建階段 - 即核心敏捷所關注的高優先級產品Backlog的實現、測試、驗收的過程 -這個階段由多個迭代組成。每個迭代均有可以工作的產品交付，靠近最后的幾個迭代交付的產品將是潛在可發布的。

　　圖3. 構建階段

　　既然我的流程定制與開發已經在RMC的平臺中完成了，我就通過RMC的生成過程視圖的給大家演示每個階段的詳細流程設計吧。例如我展開這個構建階段部分即展開構建階段流程圖如下圖：

　　圖3. 構建階段流程圖

　　上圖所示我們通過一個Iteration[1..n] 的圖標元素來代表多個迭代過程，這個元素是可以被展開的，讓我們點擊這個圖標展示迭代的內部流程圖如下所示：

　　圖3. 構建階段迭代內部流程圖

　　如上圖所示，在一個核心構建迭代中，團隊完成的有“迭代規劃(Plan Iteration)，完成故事(Complete Story)，穩定構建(Stabilize)以及準備用戶文檔”的主要幾個任務。同時，這個流程結構中，有個特別的任務是“持續性任務(ongoing tasks)”，它記錄的是在項目過程當中，那些支持團隊完成故事、穩定構建等一系列核心過程所需的“輔助、支持”工作，有管理、計劃和各種報告的輸出。在理解和分解“迭代規劃(Plan Iteration)，完成故事(Complete Story)之前，我們先看看這個“持續性任務(ongoing tasks)”，它是如何通過“迭代管理(Manage Iteration)， 風險管理(Manage Risks)， 監控和管理測試(Monitor & Control Test)，變更管理RequestChange”幾個部分工作來支撐團隊的呢?

　　圖3. 構建期迭代內持續性任務(OngoingTasks)過程圖

　　迭代管理(Manage Iteration) – 發展團隊其實也是迭代執行的一部分。提高團隊成員之間的協作和新人的培養，以及如何更好的納“團隊建設”到項目開發的活動中來的努力，這正是迭代管理所考慮的范疇。所謂迭代管理是一個以目標驅動而不是隨著迭代結束而結束的事務，這個過程我們實際上是項目內外都在堅持。

　　圖3 展開RMC的任務節點圖 ——持續性任務迭代管理(ManageIteration [Team Level])

　　迭代管理事務力主通過系統對項目進度、工作項剩余時間的監控，以及幫助團隊去除“政治化、部門墻”等制約因素，而達到團隊的迭代目標的。當團隊落后于預期進度，系統報警，此時項目管理團隊將需要幫助團隊評估如何通過減少工作量而仍然可以滿足迭代的目標。例如利益相關人，如產品負責人、團隊負責人將在關鍵時候參與決策，審批項目范圍變更、工作項延期、任務刪減的計劃和行為?？傊?，就是危機響應，幫助團隊解決掉那些影響重要目標的關鍵問題和風險。

　　理想的迭代管理實現是由系統自動收集數據、自動度量并提交預警報告的。系統將通過事先定義的幾個度量尺度或者度量矩陣，實時監控項目過程。當然，在不滿足全自動化的條件下，也可以靠人工收集和處理，或兩者兼而有之。

　　管理風險(ManageRisks)– 建立一個該項目的潛在風險的清單，在早期項目的迭代我們和團隊坐在一起，討論并創建之。并為了減小風險列表的大小且保持我們的關注力在高風險上，我們將類似的風險合并，且按照風險對項目產生影響、可能性由大到小的順序排名風險清單。

　　量化風險管理建議的將風險根據整體風險的大小進行排序。要確定風險大小需要估計的以下信息：

　　風險的影響：計算如果在風險發生之時，對項目計劃進行調整，因此對日程、人力資源、成本規劃而產生了的偏差。

　　發生可能性：該風險將實際發生的概率(通常以百分比表示)

　　風險值：由“風險的影響” 乘以 “風險發生可能性”表示了風險的實際大小

　　明確了一句風險大小優先排序制定風險應變計劃。典型的策略應遵循如下：

　　風險的緩解計劃：即通過關鍵問題的解決，減少發生風險的影響和可能性。

　　風險的應急計劃：即通過預留額外的時間、資源的B計劃，以應對風險。

　　風險的回避計劃：那就是重組項目，將風險的行為減到零，以消除風險。

　　在軟件開發中，我們如此制定我們風險應對策略的:

　　為了減少產品X和Y不能被整合的風險，我們需要在初期就建立一個原型用以研究整合的難度及風險。設計一系列的測試點(在一個列表中列舉)，以確保整合是成功的。

　　為了減少數據庫A將不正常運作的風險，我們需要模擬目標軟件在并發訪問、壓力的環境下訪問數據庫，可能需要虛擬出數據流，或者虛擬目標軟件來滿足在目標軟件沒有建成之前就要驗收數據庫的前提.

原文轉自：http://www.kjueaiud.com