隨著Choerodon豬齒魚的不斷迭代更新，它已經被越來越多的使用者開始在專案管理和開發中使用，成為了開發團隊的一部分。
這個過程中，有很多使用者向團隊提出一些關於敏捷管理上的問題，或者想了解豬齒魚敏捷團隊是怎麼來進行專案管理的。
今天就來聊一聊這方面，以下內容請使用敏捷管理的專案經理或產品經理務必仔細閱讀。
本文將以敏捷管理這個子產品團隊為例，由敏捷管理的產品負責人親自講述，希望能給大家提供一些參考和幫助，從而改善團隊協作，提升團隊交付價值和開發效率。
團隊組成
豬齒魚旨在幫助團隊進行敏捷化的應用交付和自動化的運營管理，由敏捷、測試、CI/CD、開發流水線、知識管理等多個子產品組成，除了各個子產品團隊團隊還有架構組這樣的基礎服務團隊。每個團隊根據開發工作量由6-10人構成。
敏捷管理團隊從組建以來一直保持8-10人的規模，目前有6名開發人員（2前端，4後端）、1名產品負責人（PO）、1名UI設計師，所有人都全職投入在這個專案中，基本上不會有跨團隊的情況發生。
開發節奏
整個豬齒魚產品的所有團隊都保持在同一個開發節奏上，2週一個迭代，2個迭代加上1周的持續改進，這樣5週一個版本的速率穩定向前更新。
有人會問：為什麼是2周而不是1週一個迭代呢？經過團隊長期的驗證，2周的時間可以開發一些較為複雜的需求，並且還能完成測試驗收。
當然，沒有準確的標準說1周好還是2周好，這個可以通過團隊的磨合，不斷進行調整。
執行
團隊組建好了，開發節奏也達成了一致。那麼每個迭代都有什麼工作要做？什麼先做什麼後做？誰來做？這些問題，敏捷管理子產品團隊是這樣來進行的：
新迭代開始前
之前的文章中，提到在SCRUM開發過程中涉及了很多會議，在一個迭代真正開始開發前，有一個重要的會議——迭代計劃會，來討論說明下個迭代的開發內容。
敏捷管理團隊是每個迭代的第一天上午，召集團隊全員，找一個相對安靜的地方，大家坐在一起花費2-3個小時的時間進行計劃會議。
會議上大家會開啟下個迭代整理的待辦事項，結合之前確認的UI介面，由PO給開發團隊描述這些使用者故事。過程中根據PO的功能描述，團隊成員提出自己的疑問，在相互的反饋溝通中達成共識。最後給每個使用者故事指派一個主要負責人，並對這個故事進行估算，將前後端的工作量進行統計，得出一個故事點。這個故事就結束了，進入下一個故事的討論。
有可能你們會問，計劃好的使用者故事一定要在這個迭代完成嗎？如果做不完怎麼辦呢？你們會有這樣的情況嗎？
當然有，敏捷小組是這樣處理的：
大家把所有故事討論完後，評估發現需要100個故事點（半天=1個點），超過了以往的迭代速率（80個故事點）。此時先把所有的問題按優先順序排列，由PO把當前優先順序最低的1個故事或幾個故事（故事點加起來大約在10個左右）從未開啟的迭代列表中移出。現在團隊計劃的故事中還有10個故事點是大於迭代速率的，這時PO可能會和開發團隊商量：是否能嘗試在這個迭代中完成90個故事點，如果達成一致，這時候迭代速率就從80個變為90個了。
當然，還有一種保守的做法：繼續減少排列靠後的故事。不過，大家得遵循一個原則，減少掉的這個故事得是較為獨立的，且與該迭代中其他的故事沒有依賴關係，或者關係不大。
故事評估完後，將在每個故事的經辦人處指定主要開發責任人。會後，由負責人帶領參與這個故事的開發人員一同進行故事的拆分，並將拆分的任務以子任務問題型別建立在對應的故事下。
隨後開啟這個衝刺，正式進入該迭代的開發階段。
▷ 系統工具：敏捷管理待辦事項模組、sketch（UI原型設計） ▷ 物理工具：大螢幕（討論時投放）
迭代中
團隊在開發階段中時，每個人都按之前領取的任務的優先順序進行開發工作。期間，對於功能不確定的地方需要及時與PO溝通，甚至直接與提出需求的使用者溝通。
SCRUM流程中還有一個大家都很熟悉的會議——每日站會。在開發階段，每天早上敏捷管理團隊都會舉行10-15分鐘的站會，會上只丟擲遇到的問題，不對複雜的問題給出結論，會後再由開發人員與PO一同討論作出決定。
▷ 系統工具：豬齒魚敏捷管理活躍衝刺模組
那麼迭代中，開發人員進行程式碼的編寫，其他的成員幹什麼呢？
▌工作1：整理下個迭代的內容
PO將下個迭代需要進行的需求進行拆分，以使用者故事的方式進行描述，建立在backlog中。這時，PO與UI會就這些故事開始討論，PO描述故事所要達成的功能，UI根據功能描述儘快出具高保真原型圖。（在產品初期的迭代，PO也出具簡單的原型圖，使用者確認後，再由UI出具高保真原型圖。隨著迭代的持續演進，逐漸弱化了PO出圖這一環節，更多的關注在溝通、確認和產品體驗上。）
在這個過程中，有一些不確定的問題及時與該功能模組較為熟悉的開發人員進行簡單溝通，如可執行性、是否存在前置條件等等，這些問題不會花費開發人員太多的時間，他們的重點還是在當前迭代的任務中。確定了基本的功能設計，UI就可以進行出圖工作。
UI設計完成後，首先與PO進行溝通調整，再邀請豬齒魚產品經理或者使用者參與最後方案的確認。會後PO與UI一同將反饋的修改意見進行優化調整，然後將這些原型圖與相關的故事關聯，以便後續開發人員有針對性的檢視，另一方面也是一種存檔。
▌工作2：編寫測試用例
一旦功能確認後，測試人員或者PO需要開始編寫這個迭代各個功能點的測試用例。比如這個迭代的功能均屬於1.0版本釋出的，PO可以在豬齒魚測試管理找到0.9版本的用例，將其克隆一份到1.0版本，再針對新增的功能在1.0下建立新的用例，對於變更的功能找到之前的用例，在此基礎上進行修改。最後，繼續測試計劃，指派測試人員。
▷ 系統工具：豬齒魚測試管理
▌工作3：按故事進行測試
在團隊自己的活躍衝刺看板中，有一列“驗證測試”。團隊成員達成共識：當卡片流動到這一列時，預設開發已經完成並且測試通過，這時PO和UI可以針對故事進行多方面測試，有功能的、樣式的。一旦發現問題，若與開發人員確定是bug，則將相關的子任務打回給開發人員，然後建立缺陷，隨即關聯該故事或子任務。
所以開發人員在迭代中除了功能開發，還要進行bug修復。只有當bug驗證通過後，這個故事才能算開發完成，並拖動到看板的已完成列。
團隊所有成員在迭代後期協作完成的工作內容——針對測試用例進行全量測試
之前提到過，豬齒魚產品的節奏是2週一個迭代，2個迭代一個版本。通常在第一個迭代，團隊的開發任務會計劃到第2周的週四，這個時候只是PO做增量測試，預留1天修改bug。而第二個迭代往往只會計劃到第2周的週三，因為在剩下的2天時間，是全員一起對整個敏捷管理做全量測試和bug修復。
也許你們會問，開發人員也參與測試嗎？答案是：是的，並且是交叉測試。
豬齒魚測試管理，支援在每個用例的步驟建立bug，並可以直接關聯到當前衝刺，顯示在看板上，這時相關的開發人員會停下手頭的測試工作優先修復bug。修復完後，各自負責對自己提出的bug進行迴歸測試，隨後做上線前的準備。
在實際的開發工作中，總是不會那麼理想。比如，距離上線釋出還有2天，仍然有開發任務沒有完成，且不是幾個小時就可以完成的。這時，PO需要做的決定是果斷放棄還沒有做完的任務，投入測試中。而不是推遲釋出時間，更不是縮短測試的時間，甚至不做測試去開發功能。因為大家一直遵循著敏捷的思想，交付的產品功能一定是有價值的，是可用的。
在敏捷管理團隊的日常專案管理中，還有很多其他的環節，比如評審會、回顧會、技術研討會、技術分享、論壇需求評估以及回覆、與其他團隊溝通討論等等，後續再跟大家分享。
豬齒魚敏捷小組可能不是敏捷專案管理的最佳實踐，每個環節也不可能適用於一個團隊的整個專案管理生命週期，更不可能適合每個團隊。但大家需要勇敢去嘗試，經過一段時間的磨合，通過不斷的調整，相信總能找到適合於自己團隊的敏捷管理方法。
希望那些想嘗試敏捷轉型、還在敏捷中摸索的團隊能獲得一些參考。更希望豬齒魚敏捷管理能幫助大家改善團隊，提升效率，交付更多的價值。
關於Choerodon豬齒魚
Choerodon豬齒魚是一個開源企業服務平臺，基於Kubernetes的容器編排和管理能力，整合DevOps工具鏈、微服務和移動應用框架，來幫助企業實現敏捷化的應用交付和自動化的運營管理的開源平臺，同時提供IoT、支付、資料、智慧洞察、企業應用市場等業務元件，致力幫助企業聚焦於業務，加速數字化轉型。
大家也可以通過以下社群途徑瞭解豬齒魚的最新動態、產品特性，以及參與社群貢獻：
- 官網：choerodon.io
- 論壇：forum.choerodon.io
- Github：github.com/choerodon
- 微信公眾號：Choerodon豬齒魚
- 微博：Choerodon豬齒魚