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

《Scrum敏捷開發實戰》系列：

方法介紹

團隊組建

敏捷框架（本章節）

看板工具

每日站會

常見問題

一、完整開發流程

一個軟體產品的完整開發流程分為4個部分，分別是：

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

二、Scrum框架-334

三、完整的Scrum流程

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

3個角色：

Product Owner 產品負責人

Scrum Master 敏捷教練

Scrum Team 開發團隊

3個物件：

Product Backlog 產品功能列表

Sprint Backlog 迭代任務列表

燃盡圖

4個儀式：

Sprint衝刺計劃會

每日站會

Sprint衝刺評審會

Sprint衝刺回顧會

3個角色我們在上一篇文章

《組建敏捷團隊》

已經詳細介紹，本章就不做過多的闡述。

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

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

“燃盡圖”則是一個公開的圖表，是專案進度的一種看板表現形式，有助於專案成員能夠直觀的理解專案進展，直到所有任務開發完畢。

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

四、Sprint衝刺計劃會

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

衝刺會最終產出1張表和3個時間節點：

Sprint里程碑任務計劃表

可測試介入的時間節點、整體開發完成的時間節點、上線時間節點

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

一個Sprint的週期不宜過長，控制在4周內，

而且以2周為佳

每次會議全員必須參加，每個人都要清楚本次版本的目標，我們能交付什麼，明確各自的職責和責任

全員承諾，PO不死壓完不成的任務量

任務估算時可以討價還價，但一旦接受則所有人都要對里程碑no delay，

做到當日事當日畢

儘量不要壓縮測試的時間

在任務進度表沒有出來之前，不要中斷會議

1. 任務估算

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

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

2. 任務卡

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

明確的交付內容

責任人（可以使用代號，只要不重複即可）

任務完成時間（可以用小時H或天D作單位）

五、任務卡

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

1）目標一致

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

2）任務拆解

單個任務1天為最佳，最多不能超過2天

，絕大多數的任務都是可以拆解的，很多人無法拆解是沒有掌握正確的拆解方法，我們可以按照頁面數量、介面數量、製作步驟等方法進行拆解。

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

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

第二個好處是SM每天都知道誰交付了什麼，如果沒有完成第二天也能及時風控，而不是等幾天之後才發現某人完成不了。

3）明確資訊

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

例如：

錯誤：完成介面的開發（不具體）

正確：完成使用者註冊5個介面開發

4）消除瓶頸

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

如何評估任務估算過長？

里程碑的總時長是否和你預期的相差過長，如果是，和團隊表達你的想法，一起尋找瓶頸點

培養自己的直覺，和歷史同類任務進行對比進行判斷

把握不準的，可以使用同崗位使用撲克牌估時法，找出差異大的估時邏輯

在前幾次的里程碑中，觀察和評估每個人的工作效率，用於後期對每個人的估時進行判斷是否有很大的不飽和情況

那如果有人任務估算過長，應該如何處理呢？

我們可以從以下幾個角度進行分析解決：

資訊缺失：

有可能是對所負責的任務還不是很瞭解，或把解決方案想複雜了，或對專案不熟悉，不知道有些方法已存在，可以直接使用等等，這些都可以透過深度溝通來解決；

任務拆解：

儘可能的拆細，檢視每一天的任務的工作量是否飽和，直到無法再拆為止，拆到一個點就很容易評估時間；

能力不足：

一些新人剛開始可能不知道如何拆解任何和評估，這個時候需要更資深的開發來進行輔導，梳理業務邏輯，輸出合理的卡片，輔導2~3次之後即可解決該問題（如果沒有資深開發可以考慮招聘一個，一個經驗豐富的開發，對於消除瓶頸有極大的幫助）

態度問題：

極個別的情況可能是員工的工作態度問題，態度問題很難在會議上進行解決，短期內也不太好解決，這時需要PO使用權威來推進，適當給予壓力，日常工作中要進行引導，若發現還是沒有改變的跡象，需要考慮替換；

5）打通關聯

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

6）交付承諾

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

六、每日站會

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

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

昨天我為團隊做了什麼？

今天我將要做什麼？

我需要哪些幫助？

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

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

固定時間、固定地點，養成習慣，遲到的人要有懲罰

全員參與、站立開會，保持專注，時長控制在10~15分鐘

三個問題、更新進度，不要討論技術問題，不要轉移會議話題

注意聆聽、迴應問題，別人在講時其他人要注意聽，需要幫助時相關人員要及時迴應

七、Sprint衝刺評審會

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

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

八、Sprint衝刺回顧會

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

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

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

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

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

作者：周武，曾就職於騰訊、邊鋒，現在一家上市公司產品負責人；公眾號：周武說。

本文由@ 周武 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於CC0協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。