文章對Scrum敏捷開發(fā)流程進(jìn)行系統(tǒng)的分析，希望借此文能夠加深你對敏捷開發(fā)的認(rèn)知，更好的展開產(chǎn)品工作。

Scrum敏捷開發(fā)，是一種敏捷開發(fā)框架，是一個(gè)增量的、迭代的開發(fā)過程，具備可視、可集成和可運(yùn)行使用的特征。與傳統(tǒng)的瀑布式開發(fā)模式不同，它更傾向于對一個(gè)復(fù)雜系統(tǒng)的局部模塊做短平快的版本迭代，快速響應(yīng)預(yù)期的市場需求驗(yàn)證。

從圖中可以看到，主要流程如下：

1. 產(chǎn)品分析用戶需求，按照商業(yè)價(jià)值依次排序估算，輸出計(jì)劃產(chǎn)品功能列表。
2. 經(jīng)過計(jì)劃會議討論，按照計(jì)劃面板梳理功能列表，輸出產(chǎn)品版本迭代任務(wù)。
3. 進(jìn)入開發(fā)迭代周期，按照任務(wù)面板增量迭代開發(fā)，輸出可交付的迭代版本。
4. 進(jìn)入評審驗(yàn)收環(huán)節(jié)，按照發(fā)布面板匯總問題原因，輸出迭代周期報(bào)表數(shù)據(jù)。

從上述流程中可以看到有4個(gè)輸入/輸出，3個(gè)關(guān)鍵物，3個(gè)會議，下面的我們依次了解一下這些內(nèi)容。

4個(gè)輸入/輸出

1.用戶需求，分析轉(zhuǎn)化，產(chǎn)品BACKLOG

這個(gè)部分的內(nèi)容由PM具體負(fù)責(zé)，主要的工作內(nèi)容如下：

• 用戶調(diào)研、需求分析，確定產(chǎn)品迭代功能，出具產(chǎn)品BACKLOG。
• 決定產(chǎn)品的發(fā)布日期與發(fā)布內(nèi)容，給迭代計(jì)劃預(yù)設(shè)目標(biāo)。
• 根據(jù)RIO（商業(yè)價(jià)值/工作量）排序優(yōu)先級，考慮必要風(fēng)險(xiǎn)。
• 制定Sprint計(jì)劃，根據(jù)實(shí)際情況調(diào)整功能與優(yōu)先級。

2.產(chǎn)品BACKLOG，Sprint計(jì)劃會議，Sprint BACKLOG

這個(gè)部分的內(nèi)容主要由開發(fā)經(jīng)理負(fù)責(zé)，主要工作內(nèi)容如下：

• 將產(chǎn)品BACKLOG拆分為在本次Sprint中可細(xì)化的Sprint BACKLOG。
• Sprint BACKLOG中的開發(fā)任務(wù)以小時(shí)估算，預(yù)計(jì)1-16小時(shí)的工作量化。
• 根據(jù)開發(fā)優(yōu)先級管理Sprint BACKLOG，隨時(shí)更新Sprint BACKLOG狀態(tài)。
• 每個(gè)團(tuán)隊(duì)成員都可以自主挑選任務(wù)，修改Sprint BACKLOG。

3.Sprint BACKLOG，迭代開發(fā)周期，可交付的迭代版本

這部分內(nèi)容主要由開發(fā)團(tuán)隊(duì)共同推進(jìn)，主要工作內(nèi)容如下：

• 依照Sprint BACKLOG，開始開發(fā)工作，更新工作任務(wù)面板。
• 參加每日例會，明確各團(tuán)隊(duì)的整體開發(fā)進(jìn)度與開發(fā)難點(diǎn)。
• 保證整體開發(fā)進(jìn)度不大幅度的偏離預(yù)設(shè)的Sprint燃盡圖。
• 高度的自我組織管理，保持良好的跨職能團(tuán)隊(duì)溝通，確保實(shí)現(xiàn)Sprint目標(biāo)。

4.驗(yàn)收發(fā)布版本，評審回顧會議，周期數(shù)據(jù)報(bào)表

這部分內(nèi)容主要由Sprint團(tuán)隊(duì)成員共同參與，主要工作內(nèi)容如下：

• 產(chǎn)品開發(fā)團(tuán)隊(duì)通過操作演示的方式展示Sprint中完成的功能與架構(gòu)。
• PM根據(jù)產(chǎn)品BACKLOG，驗(yàn)收開發(fā)交付的迭代版本，發(fā)布產(chǎn)品迭代版本。
• 收集Sprint問題反饋，尋找根本原因，討論解決方法，改善Sprint過程。

3個(gè)關(guān)鍵物

1.產(chǎn)品BACKLOG

由產(chǎn)品負(fù)責(zé)人維護(hù)管理的一個(gè)已排序，已估算，可漸進(jìn)的需求清單列表，可參考PRD文檔中的功能模塊記錄列表或者產(chǎn)品需求池的記錄列表。在一般的情況下，會根據(jù)功能模塊對應(yīng)的用戶故事流程來表示BACKLOG條目內(nèi)容。在每個(gè)Sprint結(jié)束或者臨時(shí)需求變更時(shí)，都需要更新優(yōu)先級的排列順序。

如圖：

2.Sprint BACKLOG

由開發(fā)負(fù)責(zé)人維護(hù)管理的一個(gè)Sprint任務(wù)清單，根據(jù)產(chǎn)品BACKLOG細(xì)化而來，細(xì)化為開發(fā)過程中可用的產(chǎn)品功能任務(wù)，每個(gè)任務(wù)用小時(shí)估算時(shí)間，團(tuán)隊(duì)成員可自行管理任務(wù)，每天的任務(wù)進(jìn)度會更新到對應(yīng)的任務(wù)面板上。

如圖：

3.燃盡圖

燃盡圖是指在1個(gè)Sprint周期內(nèi)，工時(shí)/工作量的二維圖表，主要是為了讓團(tuán)隊(duì)成員明白在Sprint截止時(shí)間點(diǎn)前剩余開發(fā)工作量的整體情況，通過實(shí)際燃盡圖與理想燃盡圖的線性對比，可快速調(diào)整開發(fā)節(jié)奏，降低Sprint版本交付存在的風(fēng)險(xiǎn)。

如圖：

3個(gè)會議

1.Sprint計(jì)劃會議（明確目標(biāo)，細(xì)化任務(wù)）

在Sprint計(jì)劃會議上，需要明確Sprint目標(biāo)與Sprint BACKLOG，討論時(shí)要考慮團(tuán)隊(duì)的接受力，開發(fā)的速度、技術(shù)水平和商業(yè)條件等，提前確定好Sprint交付日期，增量迭代開發(fā)任務(wù)，產(chǎn)品版本迭代內(nèi)容等。

2.Sprint每日例會（定點(diǎn)，定時(shí)，人齊，會短，高效）

每日進(jìn)行的Scrum會議是團(tuán)隊(duì)交流的形式，固定地點(diǎn)，固定時(shí)間點(diǎn)，團(tuán)隊(duì)成員都參與，會議維持在15分鐘左右，發(fā)言內(nèi)容圍繞昨日進(jìn)度、今日安排、所遇困難三個(gè)方面快速的梳理一遍任務(wù)面板上的工作內(nèi)容，所遇困難在會后點(diǎn)對點(diǎn)進(jìn)行討論解決。每例會是在Sprint周期內(nèi)（2-4周）的開發(fā)進(jìn)度反饋，在這個(gè)周期內(nèi)，會經(jīng)常更新任務(wù)面板。

任務(wù)面板是“任務(wù)狀態(tài)/工作進(jìn)程”的二維工作面板，便簽顏色可代表團(tuán)隊(duì)成員，便簽內(nèi)容代表團(tuán)隊(duì)成員所負(fù)責(zé)的開發(fā)任務(wù)。任務(wù)狀態(tài)一般可劃分為：ToDo，Doing，Tested，Reviewed，F(xiàn)inished五個(gè)狀態(tài)，在一塊方形劃分區(qū)域中貼滿了顏色便簽，隨時(shí)更新任務(wù)面板狀態(tài)，保證團(tuán)隊(duì)所有成員隨時(shí)隨地都可以了解Sprint周期內(nèi)的整體開發(fā)進(jìn)度

如圖：

3.Sprint評審回顧會議

Sprint評審回顧會議主要有兩個(gè)部分的內(nèi)容，一是做Sprint交付版本與計(jì)劃版本的驗(yàn)收，二是總結(jié)和完善后續(xù)Sprint的開發(fā)建設(shè)。

我眼中的敏捷開發(fā)

在筆者的眼中，敏捷開發(fā)作為一種團(tuán)隊(duì)協(xié)作方法論，高效與清晰是兩個(gè)特別明顯的特點(diǎn)，保持敏捷開發(fā)的理念開始Sprint工作的團(tuán)隊(duì)，一定有正向的開發(fā)BUFF加成，我們需要面對的是如何將敏捷開發(fā)的流程執(zhí)行到位，最大化的獲取加成收益。我很認(rèn)同敏捷開發(fā)對于精英團(tuán)隊(duì)的加成是最大化的，因?yàn)榇蠹夷繕?biāo)清晰，技術(shù)能力完善，執(zhí)行力強(qiáng)，這是最理想的工作模型。但對于現(xiàn)實(shí)中的非理想工作模型，我們可以從以下幾個(gè)方面去加強(qiáng)這種團(tuán)隊(duì)加成效果：

• 產(chǎn)品BACKLOG的來源一定要盡可能的準(zhǔn)確，最好是有明確的數(shù)據(jù)分析結(jié)果作為支持依據(jù)，Sprint BACKALOG的任務(wù)細(xì)化盡可能細(xì)致，保證在后續(xù)的Sprint迭代過程中，團(tuán)隊(duì)的工作目標(biāo)清晰明確。因?yàn)闆]有人會希望自己的工作量最后轉(zhuǎn)化為無用功，而不是KPI，這對于團(tuán)隊(duì)士氣是一種相當(dāng)沉重的打擊。如果還是出現(xiàn)了這種情況，Sprint負(fù)責(zé)人也要積極轉(zhuǎn)移大家的情緒，勸慰大家盡快投入下一個(gè)更加正確的Sprint周期中去。
• 團(tuán)隊(duì)成員之間要形成積極溝通的氛圍，保證各職能團(tuán)隊(duì)之間的信息溝通準(zhǔn)確對稱。為了保證開發(fā)過程中靈活性，敏捷開發(fā)往往為了高效而不會過多的對成員做工作流程上的束縛，需求在迭代過程隨時(shí)可發(fā)生變動(dòng)，開發(fā)任務(wù)清單可由團(tuán)隊(duì)成員自主選擇，任務(wù)面板由成員自主更新，是一種以溝通為主的工作模式。
• 對于中國特色社會主義建設(shè)的國內(nèi)而言，非理想工作模型下，團(tuán)隊(duì)成員往往更愿意被動(dòng)的選擇工作分配。開發(fā)經(jīng)理應(yīng)該合理的根據(jù)團(tuán)隊(duì)成員的能力維度安排工作任務(wù)清單，盡可能避免團(tuán)隊(duì)成員因?yàn)槟芰κЭ貙?dǎo)致進(jìn)度延期、工作效率低、工作情緒泛濫等不利于團(tuán)隊(duì)建設(shè)的情況出現(xiàn)。
• 團(tuán)隊(duì)成員的組成結(jié)構(gòu)在Sprint周期內(nèi)盡量保證不變動(dòng)，尤其是核心主導(dǎo)成員更不能做人事變動(dòng)。在一個(gè)Sprint周期內(nèi)，團(tuán)隊(duì)整體的開發(fā)關(guān)注力是需要高度集中的，如果這時(shí)團(tuán)隊(duì)的頭部成員發(fā)生更換，一定會存在溝通成本損耗，影響整體迭代效率。
• Sprint開發(fā)過程，會議的頻次與時(shí)長需要做適當(dāng)?shù)陌芽?。筆者參加過蠻多工作會議，個(gè)人覺得有些會議的RIO并不成正比，耗時(shí)且沒有正向的工作計(jì)劃輸出，這往往是蠻多人都吐槽且不喜歡參加會議的原因。每次最好由負(fù)責(zé)人主導(dǎo)會議，做好會議相關(guān)數(shù)據(jù)報(bào)表的輸入輸出，階段性的展示成果，給予團(tuán)隊(duì)積極的正向會議反饋。

本文由 @jo，hoo』 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自PEXELS，基于CC0協(xié)議