適應和收尾階段

一個良好的願景和持續的反饋可以消除迭代專案來回擺動而停滯不前的風險。

每個專案團隊都需要在下列4個方面不斷地評估並做出適當的調整：

——產品價值

——產品質量

——團隊績效

——專案狀態

1 適應階段

適應事件比遵循計劃更困難，因為專案團隊必須回答下列4個關鍵問題：

（1）價值（以可釋出產品的形式），是否得到了交付？

（2）質量目標（構建可靠的、適應能力強的產品），是否得到了實現？

（3）專案進展，是否在可接受的約束內令人滿意？

（4）團隊對於管理層、客戶或技術施加的變更，是否做出來有效的適應？

適應階段包括產品、專案和團隊評審及適應措施。

2 產品、專案和團隊評審及適應措施

評審和適應措施旨在確保在各種規模的專案中經常反饋資訊並進行高層級的學習。

在每次迭代結束時進行評審和對適應措施進行討論有兩個主要原因：反思、學習和適應；改變一下步調。

在反思期間，有4種類型的評審很有用：從客戶團隊的角度看產品功能性，從工程團隊的角度看產品技術質量，團隊績效檢查點，以及對專案整體狀態的評審。

2。1 客戶焦點小組

客戶焦點小組會議向產品團隊展示最終產品的現行版本，獲得產品如何更好的滿足客戶需求的定期反饋。

客戶或產品團隊透過客戶焦點小組的參與和演示實際的產品，從而進行產品的接收測試，這是最重要和最有益的敏捷實踐之一。

客戶焦點小組評審是建立客戶團隊與開發團隊合作關係的最佳紐帶。

客戶焦點小組會議的目的是鼓勵大家展開有關產品的各種討論，從而產生來自客戶和產品團隊的反饋意見。該會議旨在鼓勵參與、提問和來自產品團隊的變更請求。

客戶焦點小組評審會議應該是：

——有所引導的。

——限制在8~10個客戶和產品團隊成員（開發團隊應列席，但主要是作為觀察員）。

——評審產品本身，而不是文件。

——主要是發現和記錄客戶需求的變更，而不是收集詳盡的要求（如是否識別新增特性）。

2。2 技術評審

定期技術評審，包括非正式和定期安排的，為專案團隊提供了有關技術問題、設計問題和架構缺陷的反饋。技術評審應提出簡單設計、持續整合、無情的測試和重構等關鍵技術實踐，以確保它們得到有效執行。這些評審應遵循一貫的敏捷開發精神：簡單、剛剛好、最低限度的文件、短時會議和大量的相互交流。

2。3 團隊績效評估

專案團隊應遵循一個總的架構和準則（如敏捷專案管理架構及其相關的指導原則），但應調整實踐，使其符合自己的特殊需求。自組織原則規定，有效的架構應該賦予團隊儘可能大的靈活性和決策權力；自律原則規定，一旦架構取得一致同意，團隊成員就要遵循該架構。團隊績效的評估應該涉及這兩個方面。

團隊自我評估從兩方面著手：交付績效和團隊行為。分成3個等級：不達標、達標、超標。

團隊成員評估自己的整體行為並制定改進意見。

團隊應評估其流程和實踐，從而使之更好的適應團隊。

2。4 專案狀態報告

專案狀態報告對專案經理、產品經理、高層管理者和其他主要利益相關方和專案團隊本身應該很有價值。資訊彙報應促進那些旨在保持對專案的控制並提高團隊績效。編寫報告應有助於專案和產品經理反思整個專案的狀態——將“森林”與他們每天為之奮鬥的“樹”進行分離。報告的數量、頻率與報告的資訊應與專案的大小、期限和重要程度相匹配。

狀態報告提供的資訊必須有助於回答下列問題：“透過預測，該產品從經濟角度看是否依然切實可行？”“必須放棄一些特性來確保產品如期釋出嗎？”

1. 價值和範圍狀態

“停車場”圖為開發團隊、客戶團隊和管理層提供了一個很有用的有關價值和範圍狀態的檢視。甘特圖強調的是進度和任務，而停車場圖首先強調能力和故事的進展。

在一個敏捷專案裡，價值可以用範圍績效來表示（而不是衡量），如透過對每次迭代中計劃完成的故事和已完成的故事來表示價值。

2. 質量狀態

基於技術評審結果、缺陷報告（如發現和維修率）和團隊對專案的“感覺”或“嗅覺”，如下圖展示了每次迭代的技術質量水平——由團隊評估。

在軟體開發中，另一個質量度量的示例是測試程式碼相對於可執行程式碼的增長——兩者都應該成比例的增長。

3. 進度和風險狀態

在每次迭代的重新計劃期間，團隊應根據進度和故事變更，估算整個專案所需的週數。

風險的量化評估結果，即在整個專案週期中，風險遞減，特別是在早期迭代中，下降的更快。

4. 敏捷性

敏捷性的評估也非常有用。在故事層級上，團隊可以記錄並報告每次迭代中故事的變化——計劃的原始故事、刪除或延遲的故事及新增的故事等。團隊也可以記錄來自客戶焦點小組的變更請求，並報告要求的、實施的、刪除的或延遲的變更。這些揭示團隊響應變更請求的報告，有助於解釋進度和成本出現差異的原因。

5.成本狀態

工具組織的實踐不同，成本報告的形式也是多種多樣。

6. 專案團隊資訊

專案團隊需要準備好重要資訊以在整個社群共享。資訊應是可見的，對於協作團隊資訊應該醒目的張貼在牆上或白板上，或者對於分散式的團隊資訊應公佈在公共虛擬白板上。

資訊雷達在路人都可以看見的地方顯示資訊。有了資訊雷達，路人就不需再提問題：當他們路過時，資訊會自動跳入他們的眼簾。

視覺化顯示的資訊應集中在願景、目標、進展、問題、風險和其他團隊認為重要的方面。檢視產品願景資訊或指導原則，常常能夠解決對細節的爭論。風險和問題列表可以用來喚醒團隊成員的自覺性，使他們定期思考解決方案。

2。5 適應措施

適應措施覆蓋全過程，從微小的調整到下一次迭代計劃的故事，到增加資源，到縮短專案進度（透過適當的故事調整）。

產品、技術、團隊和專案狀態，任意一種都會導致適應措施。

3 收尾階段

收尾活動：

慶祝，慶祝可以達到兩個主要目的：一是對所有為該專案努力工作地成員表示感謝；二是讓重要客戶參加慶祝有助於宣告專案已經圓滿結束，從而具有完結之意。

清理未完成的工作，將原材料或製造的輔助材料編製成最後的正式文件，並準備專案結束時必須的管理報告、版本說明和財務報告。

專案回顧。團隊內部學習，為機構內團隊之間相互傳遞哪些實踐可行和哪些實踐會失敗。

4 結束語

監督和適應（傳統上稱為監督和控制）是所有優秀專案管理方法的組成部分。

適應階段的簡短評審、適應和重新計劃活動，使團隊成員在匆忙進入下一次迭代之前，有力喘息並讓大腦放鬆的時間。

參考個人部落格：cyz