一個軟件產品的完整開發(fā)流程，分為需求確定、產品研發(fā)、產品驗收、全量測試發(fā)布這四個階段，而Scrum框架為每一個階段都設定了對應的解決方案。本文作者對Scrum敏捷框架進行了分析，一起來看一下吧。

《Scrum敏捷開發(fā)實戰(zhàn)》系列：

1. 方法介紹
2. 團隊組建
3. 敏捷框架（本章節(jié)）
4. 看板工具
5. 每日站會
6. 常見問題

一、完整開發(fā)流程

一個軟件產品的完整開發(fā)流程分為4個部分，分別是：

1. 需求確定階段
2. 產品研發(fā)階段
3. 產品驗收階段
4. 全量測試發(fā)布階段

在實際的開發(fā)過程中，為了提高效率，②③是有可能重疊交替進行，Scrum框架為每一個階段都設定了對應的解決方案。

二、Scrum框架-334

三、完整的Scrum流程

完整的Scrum流程包含了3個角色、3個物件，以及4個會議；

3個角色：

• Product Owner 產品負責人
• Scrum Master 敏捷教練
• Scrum Team 開發(fā)團隊

3個物件：

• Product Backlog 產品功能列表
• Sprint Backlog 迭代任務列表
• 燃盡圖

4個儀式：

• Sprint沖刺計劃會
• 每日站會
• Sprint沖刺評審會
• Sprint沖刺回顧會

3個角色我們在上一篇文章《組建敏捷團隊》已經詳細介紹，本章就不做過多的闡述。

3個物件屬于敏捷工具，會使用即可，其中“產品功能列表”由產品負責人維護，然后進行優(yōu)先級排序，以用戶故事的形式展示，能夠讓團隊成員容易理解。

“迭代任務列表”是當前沖刺迭代版本的任務集，由產品將用戶故事拆成任務，并讓團隊成員各自領取。

“燃盡圖”則是一個公開的圖表，是項目進度的一種看板表現(xiàn)形式，有助于項目成員能夠直觀的理解項目進展，直到所有任務開發(fā)完畢。

4個儀式貫穿整個敏捷流程，領悟每個會議的作用，將決定整個敏捷開發(fā)的質量。

四、Sprint沖刺計劃會

每個沖刺版本都由一個Sprint沖刺計劃會開始，產品負責人PO或團隊成員選擇用戶故事，然后由產品負責人詳細講解用戶故事，產品經理負責講解滿足用戶故事的產品功能解決方案，開發(fā)團隊進行任務估算。

沖刺會最終產出1張表和3個時間節(jié)點：

• Sprint里程碑任務計劃表
• 可測試介入的時間節(jié)點、整體開發(fā)完成的時間節(jié)點、上線時間節(jié)點

沖刺計劃會要注意幾個關鍵點：

• 一個Sprint的周期不宜過長，控制在4周內，而且以2周為佳
• 每次會議全員必須參加，每個人都要清楚本次版本的目標，我們能交付什么，明確各自的職責和責任
• 全員承諾，PO不死壓完不成的任務量
• 任務估算時可以討價還價，但一旦接受則所有人都要對里程碑no delay，做到當日事當日畢
• 盡量不要壓縮測試的時間
• 在任務進度表沒有出來之前，不要中斷會議

1. 任務估算

任務估算是沖刺計劃會中最重要的一個環(huán)節(jié)，只有理解了本次會議的需求內容，才能估算出準確的時間，確保里程碑的進度可控，SM要在這個環(huán)節(jié)把控全局，確認好里程碑的時間節(jié)點。

如果團隊內崗位都不相同，團隊成員分別編寫自己的任務卡，而如果有相同的崗位，應當以小組的形式來估時，比如一個團隊中有2個后端，那他們就要對本次里程碑的所有任務都進行估時（可參考撲克牌估算法），雙結果不同需要討論并重新出牌，結果比較接近即結束。

2. 任務卡

一張完整的任務卡要包含三個內容：

1. 明確的交付內容
2. 責任人（可以使用代號，只要不重復即可）
3. 任務完成時間（可以用小時H或天D作單位）

五、任務卡

敏捷教練SM在和每個人確認任務卡片時，需要注意以下幾點：

1）目標一致

做最后確認，確保所有人都清楚本次里程碑的目的和邏輯細節(jié)，只有理解了業(yè)務細節(jié)才能很好的拆解任務卡片，確保不丟失業(yè)務邏輯。

2）任務拆解

單個任務1天為最佳，最多不能超過2天，絕大多數(shù)的任務都是可以拆解的，很多人無法拆解是沒有掌握正確的拆解方法，我們可以按照頁面數(shù)量、接口數(shù)量、制作步驟等方法進行拆解。

例：我們要畫一張原畫，正常需要7天，我們可以按照步驟拆解： 找參考（可省略）→ 畫草稿 → 畫線稿（將草稿清晰化）→ 上色（上底色、上陰影色、上第二層陰影色）→ 加特效（畫背景、光影）→ 優(yōu)化細節(jié) → 完稿。

拆解到人天的好處就是讓每個人都知道每天要完成什么內容，工作目標清晰透明，驗收時只有兩個結果是和否，不存在模糊不清的進度（比如完成30%這種），既讓成員有一定壓力，也能夠有效的減少工作不飽和的情況。

第二個好處是SM每天都知道誰交付了什么，如果沒有完成第二天也能及時風控，而不是等幾天之后才發(fā)現(xiàn)某人完成不了。

3）明確信息

任務卡片里的內容要清晰準確，要有量化的內容，不能用模糊不清的概念，SM要能夠理解每個卡片上交付的內容，如果不理解需要讓成員修改，并檢查每個人卡片上三要素是否齊全。

例如：

• 錯誤：完成接口的開發(fā)（不具體）
• 正確：完成用戶注冊5個接口開發(fā)

4）消除瓶頸

檢查卡片時需要關注是否包含了所有的需求，是否有估算時長與預期、或和以往類似功能時間嚴重不符的任務卡片，單人的任務時間是否過長，評估整體里程碑時長是否過長。

如何評估任務估算過長？

• 里程碑的總時長是否和你預期的相差過長，如果是，和團隊表達你的想法，一起尋找瓶頸點
• 培養(yǎng)自己的直覺，和歷史同類任務進行對比進行判斷
• 把握不準的，可以使用同崗位使用撲克牌估時法，找出差異大的估時邏輯
• 在前幾次的里程碑中，觀察和評估每個人的工作效率，用于后期對每個人的估時進行判斷是否有很大的不飽和情況

那如果有人任務估算過長，應該如何處理呢？我們可以從以下幾個角度進行分析解決：

• 信息缺失：有可能是對所負責的任務還不是很了解，或把解決方案想復雜了，或對項目不熟悉，不知道有些方法已存在，可以直接使用等等，這些都可以通過深度溝通來解決；
• 任務拆解：盡可能的拆細，查看每一天的任務的工作量是否飽和，直到無法再拆為止，拆到一個點就很容易評估時間；
• 能力不足：一些新人剛開始可能不知道如何拆解任何和評估，這個時候需要更資深的開發(fā)來進行輔導，梳理業(yè)務邏輯，輸出合理的卡片，輔導2~3次之后即可解決該問題（如果沒有資深開發(fā)可以考慮招聘一個，一個經驗豐富的開發(fā)，對于消除瓶頸有極大的幫助）
• 態(tài)度問題：極個別的情況可能是員工的工作態(tài)度問題，態(tài)度問題很難在會議上進行解決，短期內也不太好解決，這時需要PO使用權威來推進，適當給予壓力，日常工作中要進行引導，若發(fā)現(xiàn)還是沒有改變的跡象，需要考慮替換；

5）打通關聯(lián)

SM需要全局觀察每個人的任務排序和時間，觀察上下游任務銜接情況，合理調整順序，確保任務的連貫性，盡早的交付可供測試的軟件。

6）交付承諾

任務卡片確認完畢，明確三個時間節(jié)點，所有人達成共識，將任務按照優(yōu)先級展示在看板上，輸出里程碑計劃表，全體成員承諾交付結果。

六、每日站會

里程碑確定之后，通過每日站會來推進項目進度，由SM發(fā)起，全體成員參加，PO和其他需求方選擇性參加（但只參與、不說話），每日站會是快速專注的會議，用來分享進度和迭代看板進展，每個團隊成員就他們將要完成的任務對其他人口頭承諾。

所有人圍繞在看板周圍，每個人輪流上前回答一下三個問題：

1. 昨天我為團隊做了什么？
2. 今天我將要做什么？
3. 我需要哪些幫助？

回答完畢之后將已完成的任務移入Test泳道，將今天的任務移入Doing泳道。

一個有效的站會需要做到以下原則：

1. 固定時間、固定地點，養(yǎng)成習慣，遲到的人要有懲罰
2. 全員參與、站立開會，保持專注，時長控制在10~15分鐘
3. 三個問題、更新進度，不要討論技術問題，不要轉移會議話題
4. 注意聆聽、回應問題，別人在講時其他人要注意聽，需要幫助時相關人員要及時回應

七、Sprint沖刺評審會

在開發(fā)完畢后，即將交付上線之前，由SM發(fā)起，全體成員參加，開發(fā)團隊將可交付物演示給需求方，需要方進行功能評審，收集反饋意見。

評審會并不是必須的，但Scrum團隊要經常和需求方保持信息互通，確保接受到最新的市場動態(tài)和用戶反饋，交付的產品滿足利益相關者的期望，讓團隊的產出有價值。

八、Sprint沖刺回顧會

每一個沖刺會完成后，都會舉行一次沖刺回顧會議，在會議上所有團隊成員對本次沖刺進行反思，包括：什么進展順利？缺少什么？需要改變什么等等。

沖刺回顧會是針對迭代末期進行的時間盒會議，目的是幫助團隊如何提高他們的工作效率和改進工作方式，就未來的迭代改進計劃達成一致；同時梳理以往的項目缺陷和債務，對用戶故事進行審視，是否需要新增、刪除、修改用戶故事，對用戶故事進行優(yōu)先級排序。

需要注意的是，讓團隊自己反思，PO盡量不參加，或者參加也盡量少說話，反思時要找出明確的問題和意見，不要情緒化，切勿開成批斗會。

Scrum敏捷流程讓在早期發(fā)現(xiàn)可能的問題，可以用更快更小損失應對問題，“沒有問題被掃入地毯下”，Scrum鼓勵每個團隊成員清楚的描述自己所遇到的困難，其他成員積極的響應解決，降低項目風險，SM必須有預警風控能力，能判斷出可能的延遲或者偏差。

敏捷之路，不可能一帆風順，團隊只有在不斷遇到問題解決問題才能快速成長。