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

[[211673]]

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

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

產品分析用戶需求，按照商業(yè)價值依次排序估算，輸出計劃產品功能列表。

經過計劃會議討論，按照計劃面板梳理功能列表，輸出產品版本迭代任務。

進入開發(fā)迭代周期，按照任務面板增量迭代開發(fā)，輸出可交付的迭代版本。

進入評審驗收環(huán)節(jié)，按照發(fā)布面板匯總問題原因，輸出迭代周期報表數據。

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

4個輸入/輸出

1.用戶需求，分析轉化，產品BACKLOG

這個部分的內容由PM具體負責，主要的工作內容如下：

用戶調研、需求分析，確定產品迭代功能，出具產品BACKLOG。

決定產品的發(fā)布日期與發(fā)布內容，給迭代計劃預設目標。

根據RIO（商業(yè)價值/工作量）排序優(yōu)先級，考慮必要風險。

制定Sprint計劃，根據實際情況調整功能與優(yōu)先級。

2.產品BACKLOG，Sprint計劃會議，Sprint BACKLOG

這個部分的內容主要由開發(fā)經理負責，主要工作內容如下：

將產品BACKLOG拆分為在本次Sprint中可細化的Sprint BACKLOG。

Sprint BACKLOG中的開發(fā)任務以小時估算，預計1-16小時的工作量化。

根據開發(fā)優(yōu)先級管理Sprint BACKLOG，隨時更新Sprint BACKLOG狀態(tài)。

每個團隊成員都可以自主挑選任務，修改Sprint BACKLOG。

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

這部分內容主要由開發(fā)團隊共同推進，主要工作內容如下：

依照Sprint BACKLOG，開始開發(fā)工作，更新工作任務面板。

參加每日例會，明確各團隊的整體開發(fā)進度與開發(fā)難點。

保證整體開發(fā)進度不大幅度的偏離預設的Sprint燃盡圖。

高度的自我組織管理，保持良好的跨職能團隊溝通，確保實現Sprint目標。

4.驗收發(fā)布版本，評審回顧會議，周期數據報表

這部分內容主要由Sprint團隊成員共同參與，主要工作內容如下：

產品開發(fā)團隊通過操作演示的方式展示Sprint中完成的功能與架構。

PM根據產品BACKLOG，驗收開發(fā)交付的迭代版本，發(fā)布產品迭代版本。

收集Sprint問題反饋，尋找根本原因，討論解決方法，改善Sprint過程。

3個關鍵物 1.產品BACKLOG

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

如圖：

2.Sprint BACKLOG

由開發(fā)負責人維護管理的一個Sprint任務清單，根據產品BACKLOG細化而來，細化為開發(fā)過程中可用的產品功能任務，每個任務用小時估算時間，團隊成員可自行管理任務，每天的任務進度會更新到對應的任務面板上。

如圖：

3.燃盡圖

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

如圖：

3個會議1.Sprint計劃會議（明確目標，細化任務）

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

2.Sprint每日例會（定點，定時，人齊，會短，高效）

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

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

如圖：

3.Sprint評審回顧會議

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

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

在筆者的眼中，敏捷開發(fā)作為一種團隊協作方法論，高效與清晰是兩個特別明顯的特點，保持敏捷開發(fā)的理念開始Sprint工作的團隊，一定有正向的開發(fā)BUFF加成，我們需要面對的是如何將敏捷開發(fā)的流程執(zhí)行到位，最大化的獲取加成收益。我很認同敏捷開發(fā)對于精英團隊的加成是最大化的，因為大家目標清晰，技術能力完善，執(zhí)行力強，這是最理想的工作模型。但對于現實中的非理想工作模型，我們可以從以下幾個方面去加強這種團隊加成效果：

產品BACKLOG的來源一定要盡可能的準確，最好是有明確的數據分析結果作為支持依據，Sprint BACKALOG的任務細化盡可能細致，保證在后續(xù)的Sprint迭代過程中，團隊的工作目標清晰明確。因為沒有人會希望自己的工作量最后轉化為無用功，而不是KPI，這對于團隊士氣是一種相當沉重的打擊。如果還是出現了這種情況，Sprint負責人也要積極轉移大家的情緒，勸慰大家盡快投入下一個更加正確的Sprint周期中去。

團隊成員之間要形成積極溝通的氛圍，保證各職能團隊之間的信息溝通準確對稱。為了保證開發(fā)過程中靈活性，敏捷開發(fā)往往為了高效而不會過多的對成員做工作流程上的束縛，需求在迭代過程隨時可發(fā)生變動，開發(fā)任務清單可由團隊成員自主選擇，任務面板由成員自主更新，是一種以溝通為主的工作模式。

對于中國特色社會主義建設的國內而言，非理想工作模型下，團隊成員往往更愿意被動的選擇工作分配。開發(fā)經理應該合理的根據團隊成員的能力維度安排工作任務清單，盡可能避免團隊成員因為能力失控導致進度延期、工作效率低、工作情緒泛濫等不利于團隊建設的情況出現。

團隊成員的組成結構在Sprint周期內盡量保證不變動，尤其是核心主導成員更不能做人事變動。在一個Sprint周期內，團隊整體的開發(fā)關注力是需要高度集中的，如果這時團隊的頭部成員發(fā)生更換，一定會存在溝通成本損耗，影響整體迭代效率。

Sprint開發(fā)過程，會議的頻次與時長需要做適當的把控。筆者參加過蠻多工作會議，個人覺得有些會議的RIO并不成正比，耗時且沒有正向的工作計劃輸出，這往往是蠻多人都吐槽且不喜歡參加會議的原因。每次最好由負責人主導會議，做好會議相關數據報表的輸入輸出，階段性的展示成果，給予團隊積極的正向會議反饋。