小團隊如何落地敏捷開發

You can't manage what you don't measure. - Peter Drucker

你如果無法度量它，就無法管理它。

這是現代管理學之父，彼得 · 德魯克的一句名言。

項目管理、敏捷開發的前提，還是需要把數據串起來，進行可視化、數據化，這樣才能看到它，管理它。

本文將以公司 SaaS 產品爲例，介紹下 “小團隊” 是如何進行敏捷研發的落地的。

爲什麼要實施

• 需求的進展不透明，不知道現在到哪裏了

• 需求延期發佈成爲了家常便飯，不知道什麼時候會發布上線

• 需求發佈上線後，心裏總是忐忑不安，不知道什麼時候會出現問題和故障

• 團隊溝通成本太高，經常性出現 RD、FE、QA、PM 信息不一致

• 需求插入隨意、頻繁，不計成本

• 不清楚，研發團隊的工作量，是正常、超負荷、還是有人不飽和

在互聯網初創公司裏，需求和有限的資源，永遠是矛盾命題，如何在矛盾中尋找平衡，把有限的資源專注於符合公司戰略的需求，保持團隊的節奏和良好的情緒，就是要實施敏捷管理的痛點，也是我們爲什麼要實施，敏捷管理也可以很好的回答上面出現的各種問題，給出答案。

使用的工具

下面是我們所使用的工具，Confluence 主要是知識庫和文檔的彙集，Jira 是項目管理工具和 BUG 管理工具，下面是之前寫的如何搭建這些工具的文章，大家可以參考：

Atlassian Confluence：https://www.jianshu.com/p/bda2638fdbc2

Atlassian Jira：https://www.jianshu.com/p/093cf14361ed

如何做好這件事情

需求評審 → 設計評審 → 研發實現 → 測試 → 驗收 → 發佈 → 後評估

爲了讓產品和研發過程可視化，更加可控，信息互通，我們採用 4 個看板模型進行敏捷管理實踐，看板名稱和功能如下：

公開需求看板（Kanban Board）

通過「看板」建立一個公開需求池，向跨部門成員廣泛收集需求，一切市場反饋及時傳遞到位。看板類型爲 Kanban Board。

需求看板（Kanban Board）

爲需求生命週期搭建流程，按「Backlog - 評審 - 排期 - 設計 - 開發 - 發佈」設立多個階段，需求流轉可視化。

任務效能看板（Scrum Board）

爲需求預設好發版時間，所有人都可以及時預知逾期風險；產品、開發和需求提出者隨時發起溝通，及時同步需求變化或者開發進展。

BUG 看板（Kanban Board）

通過看板查詢，迭代中的各種類型的 BUG 數量情況，清楚明瞭。

公開需求管理

公司屬於教育類 SaaS，其公開需求主要來源有下面幾類：

• 重要客戶（學校）

• 用戶日常使用反饋（教師、學生、家長）

• 銷售渠道

甄別和過濾僞需求和次要或者不符合戰略的需求，在這裏進行，但是 “業務方” 提出的衆多的需求如何管理，也是一件頭疼的事情，這裏主要流程發生有下列幾種：

• 用戶使用體驗 → 客戶成功同學 → 記錄問題 → 反饋處理結果

• 大客戶需求 → 客戶成功同學 → 記錄問題 → 反饋處理結果

客戶成功同學、銷售同學或者其他干係人，都可以在這個看板內，提交原始需求問題，產品同學會過濾、調研，轉化爲產品需求，到產品需求池內，下面是公開需求看板，卡片的內容主要包含了：需求描述、問題類型、解決狀態、經辦人。

• 判斷價值很低或者肯定不會做的需求，直接拖到已完成

• 判斷有一定價值或需要在分析的需求，拖到調研討論，最終確定後，再拖到已完成

產品研發需求管理

需求分類

產品研發內部，我們把需求分成 2 類：

• 產品需求：PM 提出的迭代、緊急、日常類需求

• 技術需求：研發內部爲了穩定性、擴展性、維護性而進行的技術重構類需求

需求等級

古語云：師出有名，需求的提出也是如此，爲了讓研發同學知道需求的重要和緊急程度，需求等級劃分是特別需要的一件事情。

產品需求等級劃分

• P0：緊急任務，必須窮盡所能，最短時間完成；可以調人支援，可以停止其他項目，需要加班

• P1：非常重要任務，有 Deadline，並且不可以 Delay；如遇到 P0，那麼就需要加班保證 P1 的 Deadline

• P2：重要、有影響力的任務，有 Deadline，如遇到 P0 和 P1，可以順延（應該是大部分任務）

• P3：錦上添花的正常任務，優先級最低

技術需求等級劃分

• T0：重大性能和漏洞，需要加班加點進行修復

• T1：擴展性和性能風險問題，一般是單獨任務進行修復

• T2：設計或者一般性能缺陷，一般是隨着迭代進行相關改進

產品需求管理（需求看板）

PM 和研發同學，通過 PRD 的方式進行溝通和交流，研發同學最終也是通過 PRD 進行開發、測試工作，所以第一步是需要創建 PRD，PRD 的管理方式採用相對靈活的方式，PM 寫 PRD 的工具有的是藍湖，有的墨刀，我們這裏爲了統一歸檔，在 Confluence 做了歸檔的統一管理（PRD 的詳細鏈接可以是任何工具的鏈接）， 在 Confluence 創建時選擇模板創建，見下圖：

主要包含了：

• 背景描述

• 業務目標的描述

• 需求鏈接和功能列表（即 Story）

需求看板的泳道有 P0、P1、P1 以下、技術需求的 4 個泳道，爲了便於搜索，在快捷搜索列加入了常用的搜索關鍵詞，卡片主要包含：需求等級、到期日、需求負責人。

技術需求管理（需求看板）

類似數據結構的變更、技術架構的改進，比如：更換配置中心爲 Apollo，這類需要簡稱技術需求，其數據顯示和看板功能，和產品需求基本一致，也顯示在需求看板內，看板如下：

技術任務管理（任務效能看板）

這個階段，主要是從需求階段進入到了研發階段，這個階段主要包含如下類型的任務：

• 開發任務：RD、FE

• 開發自測：RD、FE

• 測試用例編寫：QA

• 測試用例執行：QA

技術任務類型的問題，主要來源於 2 個方面：

• 產品需求

• 技術需求

對於此類任務管理，我們使用的看板是任務效能看板。在開始之前，我們需要在 Backlog 內，拖動需要進行迭代的技術需求或產品需求，如下圖：

然後，以產品需求和技術需求爲父任務，在需求看板內，創建子任務，界面如下：

創建好後，可以查看父子任務詳情，並有工作量體現。

點擊開始 Sprint，並設置好時間，如下圖：

RD & QA & FE，在每天下班前，填寫其任務的工作量即可達到任務工作量跟蹤的效果，如下圖：

測試 BUG 管理（BUG 看板）

在 Sprint 中產生的 BUG 都會顯示在 BUG 看板中，工作流主要是打開 → 處理中 → 已解決 → 已關閉，如下圖：

我們所採用的 BUG 類的問題類型有以下幾種：

• 功能錯誤

• 界面優化

• 功能優化

• 性能問題

• 安全相關

在這個迭代結束後，測試人員，會根據 BUG 的統計報告數據，分析得出本次迭代的測試報告，測試報告，我們在 Confluence 創建了統一模板，主要內容如下：

小結

需求和效能的生命週期管理，這裏僅僅是按照目前產品和團隊的需求和階段，規定了一些適合我們的方法，這個週期管理，還是需要隨着人員和階段的不同而進行不斷的改造和演進的，下面是我們在 Jira 和 Confluence 使用的一些核心流程和方法：

4 個看板

• 公開需求看板：處理市場、銷售前端部門提出的 “大客戶需求” 和“用戶使用體驗問題”

• 需求看板：主要是管理技術需求和產品需求

• 任務效能看板：主要是管理開發階段，RD & FE & QA 的任務和工作量，跟蹤其任務合理性

• BUG 看板：主要是管理迭代內產生的 5 類 BUG 問題，功能優化 & 功能錯誤 & 界面優化 & 性能問題 & 安全相關

2 個模板

• 產品需求模板：產品需求的管理

• 測試報告模塊：迭代後，針對 BUG 和其他問題，進行的測試相關的總結

目前，敏捷相關的管理，這個階段也僅僅是做了一小部分，還有很多實踐方法，在後續的變化中，會加入和實施。

敏捷管理是爲了快速、穩定的交付產品而服務的，切忌不要爲了追求敏捷工具的使用而耽誤了實際要達成的目標。

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