You can't manage what you don't measure. - Peter Drucker
你如果無法度量它，就無法管理它。

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

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

本文將以公司SaaS產(chǎn)品為例，介紹下“小團隊”是如何進行敏捷研發(fā)的落地的。

為什么要實施

• 需求的進展不透明，不知道現(xiàn)在到哪里了

• 需求延期發(fā)布成為了家常便飯，不知道什么時候會發(fā)布上線

• 需求發(fā)布上線后，心里總是忐忑不安，不知道什么時候會出現(xiàn)問題和故障

• 團隊溝通成本太高，經(jīng)常性出現(xiàn)RD、FE、QA、PM信息不一致

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

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

在互聯(lián)網(wǎng)初創(chuàng)公司里，需求和有限的資源，永遠是矛盾命題，如何在矛盾中尋找平衡，把有限的資源專注于符合公司戰(zhàn)略的需求，保持團隊的節(jié)奏和良好的情緒，就是要實施敏捷管理的痛點，也是我們?yōu)槭裁匆獙嵤?，敏捷管理也可以很好的回答上面出現(xiàn)的各種問題，給出答案。

使用的工具

下面是我們所使用的工具，Confluence主要是知識庫和文檔的匯集，Jira是項目管理工具和BUG管理工具，下面是之前寫的如何搭建這些工具的文章，大家可以參考：
Atlassian Confluence：https://www.jianshu.com/p/bda2638fdbc2
Atlassian Jira：https://www.jianshu.com/p/093cf14361ed

如何做好這件事情

需求評審 → 設計評審 → 研發(fā)實現(xiàn) → 測試 → 驗收 → 發(fā)布 → 后評估
為了讓產(chǎn)品和研發(fā)過程可視化，更加可控，信息互通，我們采用4個看板模型進行敏捷管理實踐，看板名稱和功能如下：
公開需求看板（Kanban Board）
通過「看板」建立一個公開需求池，向跨部門成員廣泛收集需求，一切市場反饋及時傳遞到位?？窗孱愋蜑镵anban Board。

需求看板（Kanban Board）
為需求生命周期搭建流程，按「Backlog - 評審 - 排期 - 設計 - 開發(fā) - 發(fā)布」設立多個階段，需求流轉可視化。

任務效能看板（Scrum Board）
為需求預設好發(fā)版時間，所有人都可以及時預知逾期風險；產(chǎn)品、開發(fā)和需求提出者隨時發(fā)起溝通，及時同步需求變化或者開發(fā)進展。

BUG看板（Kanban Board）
通過看板查詢，迭代中的各種類型的BUG數(shù)量情況，清楚明了。

公開需求管理

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

• 重要客戶（學校）

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

• 銷售渠道

甄別和過濾偽需求和次要或者不符合戰(zhàn)略的需求，在這里進行，但是“業(yè)務方”提出的眾多的需求如何管理，也是一件頭疼的事情，這里主要流程發(fā)生有下列幾種：

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

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

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

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

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

產(chǎn)品研發(fā)需求管理

需求分類
產(chǎn)品研發(fā)內部，我們把需求分成2類：

• 產(chǎn)品需求：PM提出的迭代、緊急、日常類需求

• 技術需求：研發(fā)內部為了穩(wěn)定性、擴展性、維護性而進行的技術重構類需求

需求等級
古語云：師出有名，需求的提出也是如此，為了讓研發(fā)同學知道需求的重要和緊急程度，需求等級劃分是特別需要的一件事情。
產(chǎn)品需求等級劃分

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

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

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

• P3：錦上添花的正常任務，優(yōu)先級最低

技術需求等級劃分

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

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

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

產(chǎn)品需求管理（需求看板）
PM和研發(fā)同學，通過PRD的方式進行溝通和交流，研發(fā)同學最終也是通過PRD進行開發(fā)、測試工作，所以第一步是需要創(chuàng)建PRD，PRD的管理方式采用相對靈活的方式，PM寫PRD的工具有的是藍湖，有的墨刀，我們這里為了統(tǒng)一歸檔，在Confluence做了歸檔的統(tǒng)一管理（PRD的詳細鏈接可以是任何工具的鏈接）， 在Confluence創(chuàng)建時選擇模板創(chuàng)建，見下圖：

主要包含了：

• 背景描述

• 業(yè)務目標的描述

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

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

技術需求管理（需求看板）
類似數(shù)據(jù)結構的變更、技術架構的改進，比如：更換配置中心為Apollo，這類需要簡稱技術需求，其數(shù)據(jù)顯示和看板功能，和產(chǎn)品需求基本一致，也顯示在需求看板內，看板如下：

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

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

• 開發(fā)任務：RD、FE

• 開發(fā)自測：RD、FE

• 測試用例編寫：QA

• 測試用例執(zhí)行：QA

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

• 產(chǎn)品需求

• 技術需求

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

然后，以產(chǎn)品需求和技術需求為父任務，在需求看板內，創(chuàng)建子任務，界面如下：

創(chuàng)建好后，可以查看父子任務詳情，并有工作量體現(xiàn)。

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

RD