Scrum敏捷開發實戰（3）：開啟敏捷流程《Scrum靈敏開發實戰》系列：

方法介紹團隊組建靈敏框架（本章節）看板工具每日站會常見問題一、完整開發流程

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

需求確定階段產品研發階段產品驗收階段全量測試發布階段在實際的開發過程中，為了提高效率，②③是有可能重疊交替進行，Scrum框架為每一個階段都設定了對應的解決方案。

二、Scrum框架-334

三、完整的Scrum流程

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

3個角色：

ProductOwner產品負責人ScrumMaster靈敏教練ScrumTeam開發團隊3個物件：

ProductBacklog產品功能列表SprintBacklog迭代任務列表燃盡圖4個儀式：

Sprint沖刺方案會每日站會Sprint沖刺評審會Sprint沖刺回顧會3個角色我們在上一篇文章（《組建靈敏團隊》）已經具體介紹，本章就不做過多的闡述。

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

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

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

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

四、Sprint沖刺方案會

每個沖刺版本都由一個Sprint沖刺方案會開頭，產品負責人PO或團隊成員選擇用戶故事，然后由產品負責人具體講解用戶故事，產品經理負責講解滿意用戶故事的產品功能解決方案，開發團隊進行任務估算。

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

Sprint里程碑任務方案表可測試介入的時間節點、整體開發完成的時間節點、上線時間節點沖刺方案會要留意幾個關鍵點：

一個Sprint的周期不宜過長，掌握在4周內，而且以2周為佳每次會議全員必需參與，每個人都要清晰本次版本的目標，我們能交付什么，明確各自的職責和責任全員承諾，PO不死壓完不成的任務量任務估算時可以討價還價，但一旦接受則全部人都要對里程碑nodelay，做到當日事當日畢盡量不要壓縮測試的時間在任務進度表沒有出來之前，不要中斷會議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盡量不參與，或者參與也盡量少說話，反思時要找出明確的問題