團(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é)議