淺談Scrum敏捷開(kāi)發(fā):4個(gè)輸入/輸出、3個(gè)關(guān)鍵物、3個(gè)會(huì)議
文章對(duì)Scrum敏捷開(kāi)發(fā)流程進(jìn)行系統(tǒng)的分析,希望借此文能夠加深你對(duì)敏捷開(kāi)發(fā)的認(rèn)知,更好的展開(kāi)產(chǎn)品工作。
Scrum敏捷開(kāi)發(fā),是一種敏捷開(kāi)發(fā)框架,是一個(gè)增量的、迭代的開(kāi)發(fā)過(guò)程,具備可視、可集成和可運(yùn)行使用的特征。與傳統(tǒng)的瀑布式開(kāi)發(fā)模式不同,它更傾向于對(duì)一個(gè)復(fù)雜系統(tǒng)的局部模塊做短平快的版本迭代,快速響應(yīng)預(yù)期的市場(chǎng)需求驗(yàn)證。
從圖中可以看到,主要流程如下:
- 產(chǎn)品分析用戶需求,按照商業(yè)價(jià)值依次排序估算,輸出計(jì)劃產(chǎn)品功能列表。
- 經(jīng)過(guò)計(jì)劃會(huì)議討論,按照計(jì)劃面板梳理功能列表,輸出產(chǎn)品版本迭代任務(wù)。
- 進(jìn)入開(kāi)發(fā)迭代周期,按照任務(wù)面板增量迭代開(kāi)發(fā),輸出可交付的迭代版本。
- 進(jìn)入評(píng)審驗(yàn)收環(huán)節(jié),按照發(fā)布面板匯總問(wèn)題原因,輸出迭代周期報(bào)表數(shù)據(jù)。
從上述流程中可以看到有4個(gè)輸入/輸出,3個(gè)關(guān)鍵物,3個(gè)會(huì)議,下面的我們依次了解一下這些內(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)先級(jí),考慮必要風(fēng)險(xiǎn)。
- 制定Sprint計(jì)劃,根據(jù)實(shí)際情況調(diào)整功能與優(yōu)先級(jí)。
2.產(chǎn)品BACKLOG,Sprint計(jì)劃會(huì)議,Sprint BACKLOG
這個(gè)部分的內(nèi)容主要由開(kāi)發(fā)經(jīng)理負(fù)責(zé),主要工作內(nèi)容如下:
- 將產(chǎn)品BACKLOG拆分為在本次Sprint中可細(xì)化的Sprint BACKLOG。
- Sprint BACKLOG中的開(kāi)發(fā)任務(wù)以小時(shí)估算,預(yù)計(jì)1-16小時(shí)的工作量化。
- 根據(jù)開(kāi)發(fā)優(yōu)先級(jí)管理Sprint BACKLOG,隨時(shí)更新Sprint BACKLOG狀態(tài)。
- 每個(gè)團(tuán)隊(duì)成員都可以自主挑選任務(wù),修改Sprint BACKLOG。
3.Sprint BACKLOG,迭代開(kāi)發(fā)周期,可交付的迭代版本
這部分內(nèi)容主要由開(kāi)發(fā)團(tuán)隊(duì)共同推進(jìn),主要工作內(nèi)容如下:
- 依照Sprint BACKLOG,開(kāi)始開(kāi)發(fā)工作,更新工作任務(wù)面板。
- 參加每日例會(huì),明確各團(tuán)隊(duì)的整體開(kāi)發(fā)進(jìn)度與開(kāi)發(fā)難點(diǎn)。
- 保證整體開(kāi)發(fā)進(jìn)度不大幅度的偏離預(yù)設(shè)的Sprint燃盡圖。
- 高度的自我組織管理,保持良好的跨職能團(tuán)隊(duì)溝通,確保實(shí)現(xiàn)Sprint目標(biāo)。
4.驗(yàn)收發(fā)布版本,評(píng)審回顧會(huì)議,周期數(shù)據(jù)報(bào)表
這部分內(nèi)容主要由Sprint團(tuán)隊(duì)成員共同參與,主要工作內(nèi)容如下:
- 產(chǎn)品開(kāi)發(fā)團(tuán)隊(duì)通過(guò)操作演示的方式展示Sprint中完成的功能與架構(gòu)。
- PM根據(jù)產(chǎn)品BACKLOG,驗(yàn)收開(kāi)發(fā)交付的迭代版本,發(fā)布產(chǎn)品迭代版本。
- 收集Sprint問(wèn)題反饋,尋找根本原因,討論解決方法,改善Sprint過(guò)程。
3個(gè)關(guān)鍵物
1.產(chǎn)品BACKLOG
由產(chǎn)品負(fù)責(zé)人維護(hù)管理的一個(gè)已排序,已估算,可漸進(jìn)的需求清單列表,可參考PRD文檔中的功能模塊記錄列表或者產(chǎn)品需求池的記錄列表。在一般的情況下,會(huì)根據(jù)功能模塊對(duì)應(yīng)的用戶故事流程來(lái)表示BACKLOG條目?jī)?nèi)容。在每個(gè)Sprint結(jié)束或者臨時(shí)需求變更時(shí),都需要更新優(yōu)先級(jí)的排列順序。
如圖:
2.Sprint BACKLOG
由開(kāi)發(fā)負(fù)責(zé)人維護(hù)管理的一個(gè)Sprint任務(wù)清單,根據(jù)產(chǎn)品BACKLOG細(xì)化而來(lái),細(xì)化為開(kāi)發(fā)過(guò)程中可用的產(chǎn)品功能任務(wù),每個(gè)任務(wù)用小時(shí)估算時(shí)間,團(tuán)隊(duì)成員可自行管理任務(wù),每天的任務(wù)進(jìn)度會(huì)更新到對(duì)應(yīng)的任務(wù)面板上。
如圖:
3.燃盡圖
燃盡圖是指在1個(gè)Sprint周期內(nèi),工時(shí)/工作量的二維圖表,主要是為了讓團(tuán)隊(duì)成員明白在Sprint截止時(shí)間點(diǎn)前剩余開(kāi)發(fā)工作量的整體情況,通過(guò)實(shí)際燃盡圖與理想燃盡圖的線性對(duì)比,可快速調(diào)整開(kāi)發(fā)節(jié)奏,降低Sprint版本交付存在的風(fēng)險(xiǎn)。
如圖:
3個(gè)會(huì)議
1.Sprint計(jì)劃會(huì)議(明確目標(biāo),細(xì)化任務(wù))
在Sprint計(jì)劃會(huì)議上,需要明確Sprint目標(biāo)與Sprint BACKLOG,討論時(shí)要考慮團(tuán)隊(duì)的接受力,開(kāi)發(fā)的速度、技術(shù)水平和商業(yè)條件等,提前確定好Sprint交付日期,增量迭代開(kāi)發(fā)任務(wù),產(chǎn)品版本迭代內(nèi)容等。
2.Sprint每日例會(huì)(定點(diǎn),定時(shí),人齊,會(huì)短,高效)
每日進(jìn)行的Scrum會(huì)議是團(tuán)隊(duì)交流的形式,固定地點(diǎn),固定時(shí)間點(diǎn),團(tuán)隊(duì)成員都參與,會(huì)議維持在15分鐘左右,發(fā)言內(nèi)容圍繞昨日進(jìn)度、今日安排、所遇困難三個(gè)方面快速的梳理一遍任務(wù)面板上的工作內(nèi)容,所遇困難在會(huì)后點(diǎn)對(duì)點(diǎn)進(jìn)行討論解決。每例會(huì)是在Sprint周期內(nèi)(2-4周)的開(kāi)發(fā)進(jìn)度反饋,在這個(gè)周期內(nèi),會(huì)經(jīng)常更新任務(wù)面板。
任務(wù)面板是“任務(wù)狀態(tài)/工作進(jìn)程”的二維工作面板,便簽顏色可代表團(tuán)隊(duì)成員,便簽內(nèi)容代表團(tuán)隊(duì)成員所負(fù)責(zé)的開(kāi)發(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)的整體開(kāi)發(fā)進(jìn)度
如圖:
3.Sprint評(píng)審回顧會(huì)議
Sprint評(píng)審回顧會(huì)議主要有兩個(gè)部分的內(nèi)容,一是做Sprint交付版本與計(jì)劃版本的驗(yàn)收,二是總結(jié)和完善后續(xù)Sprint的開(kāi)發(fā)建設(shè)。
我眼中的敏捷開(kāi)發(fā)
在筆者的眼中,敏捷開(kāi)發(fā)作為一種團(tuán)隊(duì)協(xié)作方法論,高效與清晰是兩個(gè)特別明顯的特點(diǎn),保持敏捷開(kāi)發(fā)的理念開(kāi)始Sprint工作的團(tuán)隊(duì),一定有正向的開(kāi)發(fā)BUFF加成,我們需要面對(duì)的是如何將敏捷開(kāi)發(fā)的流程執(zhí)行到位,最大化的獲取加成收益。我很認(rèn)同敏捷開(kāi)發(fā)對(duì)于精英團(tuán)隊(duì)的加成是最大化的,因?yàn)榇蠹夷繕?biāo)清晰,技術(shù)能力完善,執(zhí)行力強(qiáng),這是最理想的工作模型。但對(duì)于現(xiàn)實(shí)中的非理想工作模型,我們可以從以下幾個(gè)方面去加強(qiáng)這種團(tuán)隊(duì)加成效果:
- 產(chǎn)品BACKLOG的來(lái)源一定要盡可能的準(zhǔn)確,最好是有明確的數(shù)據(jù)分析結(jié)果作為支持依據(jù),Sprint BACKALOG的任務(wù)細(xì)化盡可能細(xì)致,保證在后續(xù)的Sprint迭代過(guò)程中,團(tuán)隊(duì)的工作目標(biāo)清晰明確。因?yàn)闆](méi)有人會(huì)希望自己的工作量最后轉(zhuǎn)化為無(wú)用功,而不是KPI,這對(duì)于團(tuán)隊(duì)士氣是一種相當(dāng)沉重的打擊。如果還是出現(xiàn)了這種情況,Sprint負(fù)責(zé)人也要積極轉(zhuǎn)移大家的情緒,勸慰大家盡快投入下一個(gè)更加正確的Sprint周期中去。
- 團(tuán)隊(duì)成員之間要形成積極溝通的氛圍,保證各職能團(tuán)隊(duì)之間的信息溝通準(zhǔn)確對(duì)稱。為了保證開(kāi)發(fā)過(guò)程中靈活性,敏捷開(kāi)發(fā)往往為了高效而不會(huì)過(guò)多的對(duì)成員做工作流程上的束縛,需求在迭代過(guò)程隨時(shí)可發(fā)生變動(dòng),開(kāi)發(fā)任務(wù)清單可由團(tuán)隊(duì)成員自主選擇,任務(wù)面板由成員自主更新,是一種以溝通為主的工作模式。
- 對(duì)于中國(guó)特色社會(huì)主義建設(shè)的國(guó)內(nèi)而言,非理想工作模型下,團(tuán)隊(duì)成員往往更愿意被動(dòng)的選擇工作分配。開(kāi)發(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ì)整體的開(kāi)發(fā)關(guān)注力是需要高度集中的,如果這時(shí)團(tuán)隊(duì)的頭部成員發(fā)生更換,一定會(huì)存在溝通成本損耗,影響整體迭代效率。
- Sprint開(kāi)發(fā)過(guò)程,會(huì)議的頻次與時(shí)長(zhǎng)需要做適當(dāng)?shù)陌芽?。筆者參加過(guò)蠻多工作會(huì)議,個(gè)人覺(jué)得有些會(huì)議的RIO并不成正比,耗時(shí)且沒(méi)有正向的工作計(jì)劃輸出,這往往是蠻多人都吐槽且不喜歡參加會(huì)議的原因。每次最好由負(fù)責(zé)人主導(dǎo)會(huì)議,做好會(huì)議相關(guān)數(shù)據(jù)報(bào)表的輸入輸出,階段性的展示成果,給予團(tuán)隊(duì)積極的正向會(huì)議反饋。
本文由 @jo,hoo』 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來(lái)自PEXELS,基于CC0協(xié)議
RIO(商業(yè)價(jià)值/工作量),ROI?
最近一直在學(xué)習(xí)敏捷方面的知識(shí) 受益匪淺 我們公司現(xiàn)在引進(jìn)了做敏捷的魚(yú)骨軟件 就更能實(shí)施敏捷了