小團(tuán)隊(duì)如何落地敏捷開發(fā)

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

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

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

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

為什么要實(shí)施

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

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

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

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

• 需求插入隨意、頻繁，不計(jì)成本

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

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

使用的工具

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

如何做好這件事情

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

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

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

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

公開需求管理

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

• 重要客戶（學(xué)校）

• 用戶日常使用反饋（教師、學(xué)生、家長(zhǎng)）

• 銷售渠道

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

• 用戶使用體驗(yàn) → 客戶成功同學(xué) → 記錄問題 → 反饋處理結(jié)果

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

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

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

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

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

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

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

• 技術(shù)需求：研發(fā)內(nèi)部為了穩(wěn)定性、擴(kuò)展性、維護(hù)性而進(jìn)行的技術(shù)重構(gòu)類需求

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

• P0：緊急任務(wù)，必須窮盡所能，最短時(shí)間完成；可以調(diào)人支援，可以停止其他項(xiàng)目，需要加班

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

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

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

技術(shù)需求等級(jí)劃分

• T0：重大性能和漏洞，需要加班加點(diǎn)進(jìn)行修復(fù)

• T1：擴(kuò)展性和性能風(fēng)險(xiǎn)問題，一般是單獨(dú)任務(wù)進(jìn)行修復(fù)

• T2：設(shè)計(jì)或者一般性能缺陷，一般是隨著迭代進(jìn)行相關(guān)改進(jìn)

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

主要包含了：

• 背景描述

• 業(yè)務(wù)目標(biāo)的描述

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

需求看板的泳道有P0、P1、P1以下、技術(shù)需求的4個(gè)泳道，為了便于搜索，在快捷搜索列加入了常用的搜索關(guān)鍵詞，卡片主要包含：需求等級(jí)、到期日、需求負(fù)責(zé)人。

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

技術(shù)任務(wù)管理（任務(wù)效能看板）

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

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

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

• 測(cè)試用例編寫：QA

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

技術(shù)任務(wù)類型的問題，主要來源于2個(gè)方面：

• 產(chǎn)品需求

• 技術(shù)需求

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

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

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

點(diǎn)擊開始Sprint，并設(shè)置好時(shí)間，如下圖：

RD