淺談Scrum敏捷開發(fā)：4個輸入/輸出、3個關(guān)鍵物、3個會議

作者：佚名 2017-11-29 16:32:05

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

建網(wǎng)站原本是網(wǎng)站策劃師、網(wǎng)絡(luò)程序員、網(wǎng)頁設(shè)計師等，應(yīng)用各種網(wǎng)絡(luò)程序開發(fā)技術(shù)和網(wǎng)頁設(shè)計技術(shù)配合操作的協(xié)同工作。創(chuàng)新互聯(lián)專業(yè)提供成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè),網(wǎng)頁設(shè)計,網(wǎng)站制作(企業(yè)站、響應(yīng)式網(wǎng)站開發(fā)、電商門戶網(wǎng)站)等服務(wù),從網(wǎng)站深度策劃、搜索引擎友好度優(yōu)化到用戶體驗的提升,我們力求做到極致!

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

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

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

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

經(jīng)過計劃會議討論，按照計劃面板梳理功能列表，輸出產(chǎn)品版本迭代任務(wù)。

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

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

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

4個輸入/輸出

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

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

用戶調(diào)研、需求分析，確定產(chǎn)品迭代功能，出具產(chǎn)品BACKLOG。

決定產(chǎn)品的發(fā)布日期與發(fā)布內(nèi)容，給迭代計劃預(yù)設(shè)目標。

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

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

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

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

將產(chǎn)品BACKLOG拆分為在本次Sprint中可細化的Sprint BACKLOG。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3個關(guān)鍵物 1.產(chǎn)品BACKLOG

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

如圖：

2.Sprint BACKLOG

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

如圖：

3.燃盡圖

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

如圖：

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

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

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

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

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

如圖：

3.Sprint評審回顧會議

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

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

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

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

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

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

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

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

當前名稱：淺談Scrum敏捷開發(fā)：4個輸入/輸出、3個關(guān)鍵物、3個會議
當前鏈接：http://www.5511xx.com/article/ccegijc.html