如何更好地執(zhí)行Scrum會議?
團(tuán)隊(duì)引入Scrum的初期,會有一個(gè)常見的現(xiàn)象,就是成員們發(fā)現(xiàn)開的會變多了,自己安靜開發(fā)寫代碼的時(shí)間變少了。在這篇文章中,我嘗試基于自己曾經(jīng)參與和指導(dǎo)過的Scrum團(tuán)隊(duì)闡述一下這些會議的意義,以及如何規(guī)劃并且讓團(tuán)隊(duì)更好地執(zhí)行Scrum會議。
Scrum的會議及其意義
標(biāo)準(zhǔn)的Scrum流程包含了四個(gè)類型的會議,即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective。首先我們要知道,Scrum是敏捷開發(fā)的一種實(shí)踐,它自然也遵循敏捷開發(fā)原則。它的目標(biāo)是交付可使用的軟件,所以上面提到的這些會議都對這個(gè)目標(biāo)有著直接的幫助。
Sprint Plan會議主要是計(jì)劃當(dāng)前迭代的工作內(nèi)容做計(jì)劃。和傳統(tǒng)開發(fā)流程里面項(xiàng)目例會或者啟動(dòng)會不同,Sprint Plan著重于Product Owner 和Dev Team的交流和互動(dòng)。通過Product Owner的講解,Dev Team的理解和提問,整個(gè)團(tuán)隊(duì)對于每一個(gè)Work Item最終都會達(dá)成充分一致,同時(shí)對于每一個(gè)Work Item的工作難度、涉及范圍、可出現(xiàn)的問題和潛在的難點(diǎn)都會有充分的預(yù)判。最終在這個(gè)基礎(chǔ)上,團(tuán)隊(duì)對Work Item的工作量(復(fù)雜度)進(jìn)行打分。這些會上工作看似耗時(shí),但是它的作用是把開發(fā)中可能遇到的問題提前暴露。如果以整個(gè)Sprint周期來衡量,這種充分的溝通能縮短開發(fā)時(shí)間,而且最大限度的規(guī)避了開發(fā)中出現(xiàn)問題的風(fēng)險(xiǎn)。所以Sprint Plan會議占用的時(shí)間是完全有意義且必要的。
Daily Scrum作為每天都會進(jìn)行的會議,主要保證了團(tuán)隊(duì)成員充分的溝通。雖然時(shí)長較短,但是因?yàn)樗枰總€(gè)成員介紹自己當(dāng)天的工作內(nèi)容、第二天的工作計(jì)劃以及目前的困難,從流程上確保了大家必須提前安排好自己的工作。而且這個(gè)會議也能督促沒有工作的成員主動(dòng)領(lǐng)取任務(wù)。
Sprint Review作為團(tuán)隊(duì)工作的驗(yàn)收,要求成員通過現(xiàn)場演示的方式展示自己的成果。這種驗(yàn)收方式踐行了敏捷宣言中“可工作的軟件高于詳盡的文檔”。Product Owner作為最終用戶的代表,基于實(shí)際可演示(可工作)的軟件進(jìn)行驗(yàn)收。
Sprint Retrospective作為對當(dāng)前Sprint的總結(jié),看似和產(chǎn)品開發(fā)無關(guān),其實(shí)在某種意義上可以說是最重要的會議。敏捷的原則就是在實(shí)踐中不斷總結(jié)和改進(jìn)。Sprint Retrospective會議就是專門為團(tuán)隊(duì)總結(jié)Scrum執(zhí)行過程的問題而設(shè)立的。
對于一個(gè)新成立或者剛開始實(shí)踐Scrum的團(tuán)隊(duì),建議在第一次Sprint Plan或者啟動(dòng)會的時(shí)候?qū)ι鲜鯯crum各種會議的作用和意義有一個(gè)簡單介紹,盡量讓團(tuán)隊(duì)成員認(rèn)識到它們的重要性,從而最大限度的避免對會議的抵觸情緒。
當(dāng)然,僅僅了解會議的重要性還不夠。為了保證會議高效而有序的進(jìn)行,需要在會前、會中以及會后做很多工作,讓團(tuán)隊(duì)切實(shí)感受到重要性。接下來我們針對不同類型的會議簡單介紹一下如何執(zhí)行的。
Sprint Plan會議
Sprint Plan會議最主要的就是討論和評估Product Backlog里面的Work Item。首先,Product Owner需要在平時(shí)就注意維護(hù)好Product Backlog,即保證Backlog里面的Work Item都反映了最新的需求,內(nèi)容具體明確,優(yōu)先級合理。
其次,在開始Sprint Plan會議前,Product Owner需要預(yù)先對需要討論的Work Item在進(jìn)行一次梳理。必要的時(shí)候,可以和團(tuán)隊(duì)的技術(shù)骨干或者主要開發(fā)人員事先溝通。這樣的好處是,在Sprint Plan會議中,團(tuán)隊(duì)針對每個(gè)Work Item的討論更加高效,避免會上花大量時(shí)間思考和討論具體的需求細(xì)節(jié)。
另外,Sprint Plan會議還有一個(gè)可能引起拖延的問題就是對Work Item的打分。在標(biāo)準(zhǔn)的Scrum流程中,團(tuán)隊(duì)成員需要根據(jù)自己對Work Item的理解,在不被其他成員影響的情況下獨(dú)立打分,然后針對不同的分?jǐn)?shù)進(jìn)行討論,直到達(dá)成一致為止。但是實(shí)際情況往往是,團(tuán)隊(duì)成員由于各自的專業(yè)技能不同、知識面不同、能力不同,打出的分?jǐn)?shù)各不相同?;蛘哂捎谝恍┘夹g(shù)細(xì)節(jié),導(dǎo)致幾名成員討論的時(shí)候各不相讓。最終導(dǎo)致一個(gè)Work Item遲遲無法確定Effort。雖然充分的討論有助于提前發(fā)現(xiàn)問題和規(guī)避風(fēng)險(xiǎn),但是這種過于陷入細(xì)節(jié)的爭論卻不利于會議的進(jìn)程。因此可借鑒的做法是,在對Work Item打分的時(shí)候,選一個(gè)對此任務(wù)最為熟悉的成員打一個(gè)基準(zhǔn)分,然后大家針對這個(gè)基準(zhǔn)分投票。如果有不同意見再討論。
最后,當(dāng)團(tuán)隊(duì)工作量已經(jīng)飽和后,理論上來說Sprint Plan會議就結(jié)束了。但是為了應(yīng)對估算誤差導(dǎo)致Sprint后期沒有任務(wù)可做的情況,可以適當(dāng)多估算幾個(gè)Work Item作為備用。
Daily Scrum會議
Daily Scrum會議相對簡單,因此只需要注意成員在發(fā)言的時(shí)候避免幾個(gè)人過多的討論細(xì)節(jié),導(dǎo)致會議無限期延長的情況。一旦出現(xiàn)這種情況,Scrum Master需要及時(shí)制止。
另外,有的團(tuán)隊(duì)因?yàn)镻roduct Owner參與多個(gè)Scrum團(tuán)隊(duì),或者Product Owner和Dev Team距離較遠(yuǎn)(地理位置、時(shí)差),導(dǎo)致無法每次都參與Daily Scrum。為此可以考慮Dev Team的一個(gè)成員作為Product Owner Agent,臨時(shí)代理Product Owner的職責(zé)。對于相對簡單的需求問題可以直接決定,而對于那些不好判斷的問題則在會后單獨(dú)和Product Owner溝通。而這個(gè)Product Owner Agent的人選建議從測試人員中尋找,因?yàn)樵贒ev Team中測試人員對于需求的理解和把握是相對準(zhǔn)確且中立的。
Sprint Review & Retrospective會議
Sprint Review一定要保證每一個(gè)Work Item都是以演示的形式進(jìn)行驗(yàn)收。對于功能性的Work Item,演示起來相對比較好實(shí)現(xiàn)。而對于那些非功能性Work Item,比如架構(gòu)設(shè)計(jì)、技術(shù)調(diào)研、可行性分析等,則看上去很難演示。對此,一般的做法是,對于架構(gòu)設(shè)計(jì),通常在Work Item分解到Task的時(shí)候就包含和設(shè)計(jì)、評審、更新三個(gè)部分。而在評審部分,團(tuán)隊(duì)成員和相關(guān)技術(shù)專家已經(jīng)Review過設(shè)計(jì),并且在后續(xù)的更新環(huán)節(jié)針對評審結(jié)果做了修改。因此在最終的Sprint Review會議可以直接略過,或者簡單介紹一下評審結(jié)果。對于技術(shù)調(diào)研和可行性分析,則需要在Sprint Review會議上演示調(diào)研分析的成果,譬如例子程序、測試報(bào)告、分析報(bào)告等??傊?,Sprint Review會議里面要求的演示并不僅僅指狹義的界面操作,也可以是文檔、例子、報(bào)告等一切能夠展示工作結(jié)果的東西。
Sprint Review的演示不宜過長,一般控制在每個(gè)5分鐘之內(nèi),這就要求每個(gè)Work Item的負(fù)責(zé)人在會前準(zhǔn)備好自己的演示環(huán)境和步驟。有一個(gè)可行的做法,就是在會前每個(gè)成員都在自己的測試環(huán)境準(zhǔn)備好演示要用到的場景,會議開始后輪流接入投影儀演示。對于一些比較耗時(shí)或者操作等待時(shí)間很長的演示,也可以實(shí)現(xiàn)通過屏幕錄像的方式進(jìn)行演示。這么做可以讓成員在演示前細(xì)心準(zhǔn)備,也就是進(jìn)行必要的測試。而進(jìn)一步的,能夠讓團(tuán)隊(duì)在開發(fā)過程中就對自己負(fù)責(zé)的Work Item的質(zhì)量進(jìn)行持續(xù)關(guān)注。
Sprint Retrospective會議是對Sprint流程的總結(jié)會,因此需要注意不要成為對Sprint結(jié)果,或者對于團(tuán)隊(duì)成員的總結(jié)會。Retrospective經(jīng)常會變成成員的批評與自我批評會議,這其實(shí)是不對的,需要Scrum Master特別注意。Scrum倡導(dǎo)的是團(tuán)隊(duì)而非個(gè)人,因此Retrospective總結(jié)的也是團(tuán)隊(duì)而非個(gè)人。
鑒于東方人大多比較含蓄和內(nèi)斂,Retrospective也有可能變成無聲靜默會議。這時(shí)候需要Scrum Master在會議前就能總結(jié)出一些待改進(jìn)的事項(xiàng),會上帶頭提出,引導(dǎo)其他成員參與?;蛘卟扇≥喠靼l(fā)言的機(jī)制,強(qiáng)制每個(gè)成員都要參與。但是無論什么手段,都要確保對流程不對結(jié)果,對事不對人。
最后,為了防止Retrospective只抱怨不解決,會議記錄需要明確提出來的每個(gè)問題的提出者、內(nèi)容、解決方案、負(fù)責(zé)人和截止時(shí)間。在下一次Retrospective會議中,Scrum Master可以先匯報(bào)上次Retrospective會議的記錄以及解決結(jié)果。這樣做的好處是用實(shí)際行動(dòng)表明成員提出的每一個(gè)改進(jìn)建議都是被重視被落實(shí)的,鼓勵(lì)大家繼續(xù)提出問題并改進(jìn)。同時(shí)要指出,對于解決結(jié)果來說,某個(gè)問題最終沒能解決也是一種可接受結(jié)果。
一些通用原則
準(zhǔn)時(shí)參會
– 會議開始前5分鐘之前,可以申請遲到。
– 會議開始后5分鐘內(nèi)到場,不算遲到。
– 會議開始后5分鐘之后,算遲到。
– 每一個(gè)遲到的成員需要給團(tuán)隊(duì)發(fā)紅包或請吃零食等。
發(fā)言權(quán)
– 只有對項(xiàng)目有直接貢獻(xiàn)的成員可以發(fā)言
準(zhǔn)時(shí)結(jié)束
– 絕不拖堂
– 未討論的內(nèi)容另行組織會議
會議記錄
– 除Daily Scrum外,所有會議均保存會議記錄,使用統(tǒng)一模板
– 會議記錄包括:時(shí)間、參會人、議題、決議、負(fù)責(zé)人和截止時(shí)間。
總結(jié)
Scrum流程中,各種會議是其主要的組成部分,也是推進(jìn)Scrum進(jìn)行的基礎(chǔ)。確保這些會議有序高效的進(jìn)行是能否成功開展Scrum的關(guān)鍵。因此團(tuán)隊(duì),特別是Scrum Master要對此給予足夠的重視。
上面提到的一些原則、經(jīng)驗(yàn)和流程僅僅是基于我之前參與過的Scrum項(xiàng)目總結(jié)而來的。而實(shí)際上,Scrum團(tuán)隊(duì)各不相同,會議的內(nèi)容、進(jìn)程和安排也不會完全一樣。這需要整個(gè)團(tuán)隊(duì)不斷地嘗試、磨合、改進(jìn)。最重要的,確保會議的討論是有意義的,是得到團(tuán)隊(duì)認(rèn)可的,才能最終達(dá)到目的。
#專欄作家#
袁林,人人都是產(chǎn)品經(jīng)理專欄作家。分享SaaS運(yùn)營和企業(yè)管理/協(xié)作/辦公的相關(guān)知識
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Pexels ,基于 CC0 協(xié)議
- 目前還沒評論,等你發(fā)揮!