上篇文章《Choerodon豬齒魚敏捷管理實踐（一）——需求管理》中介紹了在敏捷管理中如何獲取、規劃和管理需求。這篇文章將介紹說明收集好需求後接著做什麼，幫助大家掌握敏捷管理中很重要的一部分——衝刺管理，也可以叫做迭代管理。
▌主要內容：
- 規劃衝刺
- 計劃會議
- 討論故事
- 拆分任務
- 承擔責任
- 估算和確認
- 開啟衝刺
- 專注於質量
- 減少在製品
- 頻繁交付
- 根據交付速率來平衡任務的請求量
- 優先順序排序
- 總結
在敏捷開發的實踐中，通過規劃衝刺中不同的階段，開發可以達到如下幾個目的：
- 視覺化管理團隊的目標；
- 明確目標的優先順序；
- 明確目標分解後的任務項；
- 視覺化管理任務的進展狀況。
規劃衝刺
利用釋出計劃，可順利地將粗顆粒度的故事分配到釋出中的多輪迭代中。不過，在開始一輪迭代時，有必要去針對該迭代再去做進一步的計劃。
計劃會議
整個團隊通過舉行計劃會議來為下一個迭代做計劃。客戶以及團隊中的所有開發人員，包括程式設計師，測試人員和其他人都要參與這個會議，計劃會議的內容一般如下：
- 討論分析使用者故事；
- 從故事中拆分出任務；
- 分配每個開發人員需要承擔的任務；
- 開發人員單獨估計自身所承擔的任務，以確保他們不會做出過於樂觀的承諾。
在實際的操作中，團隊計劃會議後會開啟一個衝刺，將backlog中確定在該衝刺進行的故事拖到衝刺列表中，隨後為每個故事進行分解並關聯對應的任務。
討論故事
迭代計劃會後，團隊會獲得一個已經排好優先順序的故事集合。正如程式設計師可能改變他們對實現一個故事難度的看法，客戶或產品負責人一樣可以改變他們對故事優先順序的想法。計劃會議是客戶或產品負責人為團隊調整故事優先順序的最佳階段。
會議中，PO（產品負責人）會從最高優先順序的故事開始給團隊講解每個故事的內容。然後由開發人員提問，直到他們充分理解故事，能從故事中分解出任務。這個過程沒有必要理解故事的所有細節，過分地深入每個故事細節會使會議變得低效、冗長，因為會議中不是每個人都需要聆聽所有故事的細節。在計劃會議後，開發人員可以和PO一起理清故事的關鍵細節。
拆分任務
理解使用者故事的大致內容後，需再將故事分解為任務。在Choerodon敏捷管理中，可以通過建立子任務的方式來分解故事，並將故事與這些拆分後的任務進行關聯。只有當所有的子任務狀態變成已完成時，這個故事才能拖到已完成的列中。
為何要拆分故事而不直接把故事作為獨立的工作單位？
儘管故事的確可以小到作為工作單位，但將故事拆分出更小的任務，一般更符合專案開發的需要。
首先，對於很多團隊來說，實現故事的開發人員不止一個，需要由多個開發人員共同完成一個故事。這要麼是因為開發人員在某些特定技術上的專業性，比如前後端分離開；要麼是因為工作劃分是完成故事的最快途徑。
其次，故事是對使用者或客戶有價值的功能的描述，不是開發人員的代辦事項，把故事拆解成任務有助於發現那些可能會被遺忘的任務。一整個小組一起來拆分任務，依靠的是所有人的集體智慧，避免某個人忘記了故事中的某個部分。
相比瀑布過程，敏捷沒有前期設計階段，其過程特點是做頻繁的短期設計，當腦海裡至少有一個最小的設計方案時，才可能從故事中拆分出任務。所以，一個故事的任務拆分其實是即時設計中的一次短脈衝，以這些短脈衝的集合取代瀑布過程的前期設計階段。
在團隊成員說明任務時，需要實時將圍繞某個故事的任務都記錄下來，然後將任務以卡片的形式在物理或電子看板中進行展示。
Choerodon豬齒魚敏捷管理中的活躍衝刺模組，團隊可以針對每一個迭代開啟一個新的衝刺，規劃好時間，通過看板工具實時檢視工作進度或開發瓶頸。
承擔責任
通過看板，我們可以清晰地看到每個任務的責任人（採用結對程式設計時，每個任務也只關聯一個人的名字，此人將承擔完成任務和與PO、客戶溝通訊息的責任，確保在迭代期間完成任務。）
雖然任務事先已經由每個人認領，但在衝刺期間並不是一成不變的。在衝刺中，隨著開發取得進展，成員會比之前預想的更瞭解任務，因此任務的認領及承諾也需要相應做出調整。
在敏捷中，團隊協作非常重要，只有所有人達到預期，這個迭代才算完成，如果有開發人員不能完成他承擔的所有任務，團隊中的其他成員應該儘量勇於承擔。
估算和確認
通常當一個團隊經歷了3個以上的迭代之後，基本可以確定團隊的速率（即一個迭代可以完成的故事點總數），當然前提是每個迭代的時間週期是一樣的。
假如你的團隊的速率是平均每個迭代40個故事點，每個開發人員首先以理想時間估算自己承擔的工作量，然後整個團隊相加進而做出實際的評估，判斷在該迭代中能否完成所有任務。
例如，為期2周的衝刺開始了，一個開發人員估算完成任務實際需要55個小時，算上必須要做的其他事情，沒有把握在這些任務上投入更多時間，這種情況有以下選擇：
- 繼續往前走，一個一個的去完成，寄希望於一切順利
- 請求團隊中其他成員接收一部分任務
- 與PO討論，放棄一個故事，或者拆分故事，放棄其中一部分
最好的方法是後兩種，整個團隊必須同舟共濟。
開啟衝刺
迭代會議結束後，團隊正式進入到這個迭代的開發中。Choerodon豬齒魚敏捷管理中，把一個正式開啟的迭代稱作為一個活躍衝刺，一個看板針對一個活躍衝刺。團隊根據計劃制定這個迭代的目標和時間範圍。
在迭代過程中，Choerodon敏捷管理引用了看板方法來管理我們的開發。 看板的結構通常包括如下幾個列：
- Backlog ：是這個衝刺需要完成的所有使用者故事，這些故事加在一起就是這個迭代的目標，這些故事通常按照優先順序從上到下排列。
- Todo ：這一列代表的是待辦任務項，使用者故事會被拆分為對應的開發任務，這些待辦的開發任務將展示在Todo這一列中。
- Doing ： 進行中的任務。
- Done ：已經完成的任務和使用者故事。
任務看板上除了有預設的4列之外，還可以自定義新建泳道，通過泳道來管理故事和任務的對應關係。
在衝刺的交付階段我們應該將以下幾點作為看板方法的步驟去貫徹執行：
- 專注於質量；
- 減少進行中的工作（work-in-process）；
- 頻繁交付；
- 根據交付速率來平衡任務的請求量；
- 按照任務的優先順序排序進行開發；
- 消除變異性的根源，提高可預測性。
專注於質量
很多開發團隊將可用資源花在與缺陷修復相關的工作上，這會對高缺陷率團隊的生產力和交付速率產生巨大影響。
鼓勵提高初始質量，很可能提升2-4倍的交付速率，如果團隊真的很糟糕，那麼通過“專注於質量”的做法，甚至都可能獲得10倍的交付速率的提升。
專業的測試人員應該做好測試，讓測試人員來發現缺陷，防止缺陷遺漏在程式碼中。要求開發人員編寫單元測試程式碼，使單元測試程式碼自動化，也就是我們經常提及的自動化測試，以提供自動化的迴歸測試，這樣也可以產生巨大的效果。測試驅動開發似乎確實能帶來使測試覆蓋更為完整的好處。對於普通團隊，在功能編碼前編寫測試程式碼，能夠提高程式碼質量。
程式碼檢查能夠幫助改善外部和內部的程式碼質量，最好經常做，並且以小批量進行為好。
協作式的分析和設計，也能夠提高程式碼質量。團隊一起分析問題和設計解決方案，產出的質量會更高。
還有使用現代開發工具提高質量，許多現代開發工具都包括靜態程式碼分析和動態程式碼分析的功能，需要在開發中不斷地進行程式碼優化，這些工具可以防止程式設計師犯低階錯誤。
減少在製品
在製品和平均前置時間之間存在相關性。前置時間越長，質量就會顯著下降，而在製品數量越多，平均前置時間則越長。因此，提高質量的關鍵是減少在製品數量。
減少在製品的數量或縮短迭代的長度，將對初始質量產生重大影響。隨著在製品數量的增加，缺陷數量會不成比例地增加。為期2周的迭代比4周的迭代好是很有道理的。較短的的迭代會產出更高的質量。
僅需使用看板來限制在製品數量便可提升質量，那為什麼不引入明確的規則來限制在製品數量，解放管理人員使其可關注於其他的管理工作。
敏捷管理中強調的對於在製品的限制，Choerodon敏捷管理也進行了應用。團隊可以根據開發能力和進度設定列約束，通過限制處理中的卡片數量來控制開發人員的在製品數量，只有當在製品卡片數量小於限制數，才可以到backlog中拉取新的任務。如下圖：
頻繁交付
減少在製品數量能夠縮短前置時間，縮短前置時間意味著可以更為頻繁地提交可用的程式碼。頻繁的提交程式碼，能夠與外部團隊或業務建立信任。
Choerodon敏捷開發中，開發人員會在每天定點提交合並程式碼（即使只完成部分功能）。如下圖的程式碼提交日誌會記錄每個人提交合並的時間，會對提交程式碼部分進行備註，這樣可以提高多個開發人員的合作效率：
在軟體開發中，規模雖小但是頻繁、高質量地釋出交付，較之規模大但頻率低的釋出，更能夠在團隊合作上建立起信任。小規模的釋出說明，團隊具有交付能力，並能夠一直致力於產出價值。便於軟體開發團隊與市場、與使用者之間建立起信任。
為什麼以小批量的方式進行編碼能夠提高產品質量？這點其實也很好理解。隨著進行中工作項數量的增加，問題的複雜性也會呈指數級增加。在軟體開發中，有很多知識遷移和資訊發現活動，他們是隱性的，而且都是面對面的協作過程中發生的。雖然這些資訊具備口頭表述性和可視性的特徵，但是他們大多以畫像在草圖之類的非正式形態存在。我們的大腦無法儲存這些隱性知識，即時記住，也會遺忘。更無法記得確切的細節，並會因此犯錯。
如果減少進行中的工作，能減少對隱性知識的遺忘，從而獲得高質量的產品，並促進更為頻繁地釋出。
根據交付速率來平衡任務的請求量
意味著根據交付可工作程式碼的速率，來設定新的任務進入開發流中，這樣便可有效地將進行中的任務數量固定在某個值。在有交付後，便會從SpringBacklog里拉入新的任務。因此，任何對新工作的優先順序排序，只可能在現有任務被交付的情況下才發生。
這一變化具有深遠的影響，流程的交付速率會受限於某個瓶頸，可往往很難準確的找到這個瓶頸在何處。事實上，價值流中的每個人都會說自己已經超載。但通過交付速率，處於價值流其他環節的人員就會發現他們有了富餘能力，而那些處於瓶頸處的人員的工作會很忙，但不會過載。這時整個團隊成員會有一種手頭終於有時間的感覺了。
在活躍衝刺中，團隊可以實時檢視每個成員的任務量，從而掌握團隊進度以及瓶頸。
人們只有釋放了大部分壓力，才能集中精力準確高質量地完成工作。那些手上有富餘時間的工作者，會開始將精力投向於環境改造。他們可能會開始不斷提升自身技能，改進使用的工作，改善溝通協作方式等。隨著時間的推移，團隊在持續進行改善，進而整個團隊都會得到改變。通過限制在製品以及當只有可用產能時才拉入新工作的做法，產生的富餘時間能帶來無法想象的改善行動。
想要進行持續改善，就要具備富餘時間，為了產生富餘時間，要做到根據交付速率來平衡需求請求量，限制在製品的數量。
優先順序排序
當團隊做到前幾點要求後，心理重心應該轉向優先順序排序，而不僅僅只是交付的程式碼數量。
當交付方面缺乏可預測性時，很少有人會去關注優先順序排序的問題。在解決這個問題之前，需要保證次序的可靠性，將管理精力重點用於改善交付能力和交付的可預測性上，一旦能夠真正做到按需求請求的大致次序交付需求，就應該把思考轉向如何對輸入的需求進行優先順序排序。
Choerodon豬齒魚敏捷管理中，根據計劃會議討論後的結果，PO可以重新對故事的優先順序進行排序，團隊也將根據這個優先順序安排開發任務的順序。
如果不具備定期交付高質量程式碼的能力，就不可能建立起信任關係，因此，在優先順序排序上具備影響力的可能性也會很小，也就無法進一步優化團隊交付的價值。
總結
在敏捷管理方法中，前期的需求計劃和討論必不可少。而在正式的開發過程中，首先要學習構建高質量的程式碼，其次，減少進行中的工作項數量，縮短前置時間，並頻繁釋出。第三，根據交付速率來平衡需求請求量，對在製品設定限制，進而產生富餘時間並釋放個體的創造力，促進改善行為的發生。第四，隨著軟體開發的順暢運轉和能力優化，通過改善優先順序排序來優化交付的價值。
期望一步實現優化業務價值，只是一種不切實際的美好願望。遵循以上幾點並採取行動，會讓你的敏捷團隊逐步達到期望的成熟度水平。
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源企業服務平臺，是基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。
大家可以通過以下社群途徑瞭解豬齒魚的最新動態、產品特性，以及參與社群貢獻：
- 官網：choerodon.io
- 論壇：forum.choerodon.io
- Github：github.com/choerodon/
- 微信：Choerodon豬齒魚
- 微博：Choerodon豬齒魚
歡迎加入Choerodon豬齒魚社群，共同為企業數字化服務打造一個開放的生態平臺。