研發團隊如何實現敏捷開發管理

敏捷開發的實質是通過迭代式增量軟件開發的方式，防止出現長期閉門造車嚴重偏離客戶需求，達到快速響應市場變化的目的。

應用敏捷就會一帆風順嗎？顯然答案是否定的。越來越多的組織、團隊開始學習、實踐、導入敏捷，然而效果確實相差甚遠、判若雲泥。爲什麼會這樣？或者說敏捷轉型有這麼多痛點？

其實，敏捷開發只是一種指導思想和原則，敏捷開發並沒有給出具體的實踐步驟，重要的是通過實踐哪些方法可以幫助達到目標，或者解決哪些問題從而達到目標。

接下來會結合過往的實際經驗，介紹敏捷團隊走完一個迭代所涉及的內容，希望給即將或已經進行敏捷實踐的個人、團隊和組織帶來一些思考和參照。

以下的內容會以 Scrum 框架爲主，但不僅限於 Scrum 框架。

這裏我們爲了提效利用 Gitee 幫助我們更好的理解如何實踐敏捷開發。

版本規劃

在版本規劃時，建議綜合考慮客戶的價值、整體質量與範圍、進度、預算等限制條件。常見版本四種發佈規則 ，團隊採用最適合的即可。

  1. 在每個衝刺後發佈，而是把多個衝刺的結果合併爲一個版本進行發佈；

  2. 發佈和衝刺保持一致，即衝刺結束後立刻進行版本發佈；

  3. 按特性發布，即每次做完一個特性就進行一次發佈，我們管這種發佈也叫持續交付；

  4. 按需發佈，它是綜合以上發佈，按業務方的需求來選擇何時發佈。

不管你採用哪種方式進行發佈，大多數組織實踐中發現最好能夠稍微做一些長期的規劃，有利於整體統籌規劃。有些組織可能用別的名稱來代替，比如：長期規劃（放眼於多個衝刺）、里程碑（各版本與重大里程碑一致）。

通過 Gitee「里程碑」對每一條業務上線做一次迭代規劃

我們需要理解，在這裏程碑可以是一個迭代，也可以是多個迭代，這和我們的規劃相關。爲了方便，我們在這裏視一個里程碑爲一個迭代，即 “庫存管理上線” 爲一個迭代。

團隊管理

Scrum 框架下有三種常見角色：產品負責人（Product Owner）、Scrum 主管（Scrum Master）、團隊成員（Scrum Team）。

根據我們開發中的實際情況將角色分爲以下四種：

  1. 項目經理：相當於 Scrum 主管，負責協調團隊內部合作，召集站立會議，把控項目整體進度；

  2. 產品經理：相當於產品負責人，負責決定應該做什麼工作，明確工作項、評定優先級，擬定待辦事項 Backlog 清單的內容，確定各個事項的優先順序；

  3. 開發人員：開發人員是項目開發任務具體的實施者。他們負責完成開發任務，及時反饋開發進度；

  4. 測試人員：測試人員是項目測試任務具體的實施者。他們負責制定測試計劃，編寫測試用例，創建以及迴歸缺陷。

在 Gitee 的「項目成員」中可對參與項目的成員進行分組和權限管理

需求梳理

項目開始前，由產品負責人收集來自各方需要、期望和訴求，明確工作項、評定優先級，整理出 Backlog 待辦事項列表，常見的條目信息表達形式爲用戶故事。在衝刺計劃會議上，Scrum 團隊從產品待辦列表中挑選其中事項組成 Sprint Backlog。

在 Gitee 中新建任務梳理需求

產品負責人對需求任務設置優先級，結合自身情況自定義需求狀態，利用「子任務」進行細化和拆解，設置任務歸屬於不同的資源池，形成完整的故事結構。

迭代計劃

在迭代開始前，我們需要有一個迭代計劃會議。在會議中安排迭代中要做的工作以及確定迭代目標。在迭代計劃會上，產品負責人需要告訴團隊迭代待辦列表中條目實現的優先級順序。團隊承諾在迭代中他們能夠完成多少個條目。在迭代的過程中，任何人不能單方面擅自變更衝刺內容。最終的計劃是由整個 Scrum 團隊協作完成的。

Gitee 中的迭代待辦條目列表

在每個迭代 / 版本開始前，交付團隊和需求方就應當在計劃會議上針對下一個迭代 / 版本要交付的範圍進行討論，交付團隊就討論結果，做出 在迭代結束時一定會交付約定範圍的需求 的承諾。

跟蹤迭代進度

迭代目標明確後，即將進入迭代衝刺。一般迭代週期爲 1 至 4 周左右。在整個迭代過程中，需要由 Scrum Master 確保團隊在無外界干擾的情況下全力以赴的衝刺。在衝刺的過程中，建議採用可視化管理方式將迭代過程和工作必須對執行工作的人員和接受工作的人員都是可見的。

Gitee 中的任務狀態看板模式

每日站會

迭代開始後，團隊在每日站立會議（Daily Scrum Meeting）中對每天工作進行迭代跟蹤。各成員快速彙報昨天任務進度、是否需要修改計劃、遇到的困難等，保證 Scrum Master 和團隊成員可以快速處理障礙，集中精力進行目標衝刺。同時建議站會結束後，將比較有價值的信息同步到 Wiki 中。

通過 Gitee 中的倉庫 Wiki 功能在系統中保存每次會議的會議紀要

關注團隊進度

除了應用可視化看板、每日站會可以監控項目進度和風險以外，還有一個特別好用的實踐，即燃盡圖。

燃盡圖以圖形化方式展現了剩餘工作量與時間的關係。要求團隊每日更新工作進度，養成良好的更新習慣。從圖中可以瞭解團隊計劃，把握團隊進展以及知曉工作步調是否一致。同時可以及時發現問題並做出改進。

Gitee 中的燃盡圖

通過甘特圖能隨時查看迭代的具體進度以及每個項目成員的任務分工情況，做到分配合理。

Gitee 中的「甘特圖」功能讓項目排期可視直觀，進度一目瞭然

迭代評審

迭代衝刺的結果是潛在的可交付的產品增量，那麼如何來評估衝刺目標完成的結果呢？接下來要進行另外一個事件，即迭代評審會議。

迭代評審的目的是檢視迭代衝刺的成果並確定未來的適應性。團隊向關鍵利益相關者展示他們的工作結果，並討論產品目標的進展情況。在迭代評審期間，團隊和利益相關者將評審在這次迭代衝刺中完成了什麼，以及環境發生了什麼變化。基於這些信息，與會者可以就下一步的工作進行協作。PBI 也可能會進行調整以適應新的機會。這裏需要注意，迭代評審是一個工作會議，團隊應避免將其僅限於展示。

迭代回顧

最後一個環節爲回顧改善會。迭代回顧會議的目的是規劃提高質量和效能的方法。應當對整個迭代的過程進行回顧，檢視最近一個迭代衝刺中有關個體、交互、過程、工具和他們的 DoD 的完成情況如何及遇到哪些問題，這些問題是如何解決或未解決的。團隊識別出最有用的改變以提高其效能。最有影響力的改進將盡快得到執行。甚至可以將它們添加到下一個迭代衝刺的迭代待辦列表中。如果需要，可將重要的信息更新到 Wiki 中，讓團隊成員時時可見。

最後總結一下，敏捷開發只是一種管理方式，不會告訴我們具體每個項目應該怎麼做，選擇一款趁手的工具能幫助更好的管理實踐，達到事半功倍的效果。

工欲善其事必先利其器， Gitee 企業版不僅能爲需求管理、迭代規劃、進度跟蹤等經典 Scrum 環節提供工具支撐，還能很好的幫助企業有序管理研發全流程，雲端 / 本地均可靈活部署，已爲 18 萬家企業提供服務。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/T0BM3AqADIc6_Xg_p9SGMw

猜你喜歡