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

3 評論 26313 瀏覽 127 收藏 11 分鐘

文章對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é)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. RIO(商業(yè)價(jià)值/工作量),ROI?

    來自廣東 回復(fù)
  2. 最近一直在學(xué)習(xí)敏捷方面的知識 受益匪淺 我們公司現(xiàn)在引進(jìn)了做敏捷的魚骨軟件 就更能實(shí)施敏捷了

    來自北京 回復(fù)