Choerodon豬齒魚團隊敏捷項目管理實踐應用

隨着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出圖

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，Istio，knative，Gitlab和Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

• 官網：http://choerodon.io
• 論壇：http://forum.choerodon.io
• Github：https://github.com/choerodon
• 微信公衆號：Choerodon豬齒魚
• 微博：Choerodon豬齒魚