團隊引入Scrum的初期，會有一個常見的現(xiàn)象，就是成員們發(fā)現(xiàn)開的會變多了，自己安靜開發(fā)寫代碼的時間變少了。在這篇文章中，我嘗試基于自己曾經(jīng)參與和指導過的Scrum團隊闡述一下這些會議的意義，以及如何規(guī)劃并且讓團隊更好地執(zhí)行Scrum會議。

Scrum的會議及其意義

標準的Scrum流程包含了四個類型的會議，即Sprint Plan、Daily Scrum、Sprint Review和Sprint Retrospective。首先我們要知道，Scrum是敏捷開發(fā)的一種實踐，它自然也遵循敏捷開發(fā)原則。它的目標是交付可使用的軟件，所以上面提到的這些會議都對這個目標有著直接的幫助。

Sprint Plan會議主要是計劃當前迭代的工作內(nèi)容做計劃。和傳統(tǒng)開發(fā)流程里面項目例會或者啟動會不同，Sprint Plan著重于Product Owner 和Dev Team的交流和互動。通過Product Owner的講解，Dev Team的理解和提問，整個團隊對于每一個Work Item最終都會達成充分一致，同時對于每一個Work Item的工作難度、涉及范圍、可出現(xiàn)的問題和潛在的難點都會有充分的預判。最終在這個基礎(chǔ)上，團隊對Work Item的工作量（復雜度）進行打分。這些會上工作看似耗時，但是它的作用是把開發(fā)中可能遇到的問題提前暴露。如果以整個Sprint周期來衡量，這種充分的溝通能縮短開發(fā)時間，而且最大限度的規(guī)避了開發(fā)中出現(xiàn)問題的風險。所以Sprint Plan會議占用的時間是完全有意義且必要的。

Daily Scrum作為每天都會進行的會議，主要保證了團隊成員充分的溝通。雖然時長較短，但是因為它需要每個成員介紹自己當天的工作內(nèi)容、第二天的工作計劃以及目前的困難，從流程上確保了大家必須提前安排好自己的工作。而且這個會議也能督促沒有工作的成員主動領(lǐng)取任務。

Sprint Review作為團隊工作的驗收，要求成員通過現(xiàn)場演示的方式展示自己的成果。這種驗收方式踐行了敏捷宣言中“可工作的軟件高于詳盡的文檔”。Product Owner作為最終用戶的代表，基于實際可演示（可工作）的軟件進行驗收。

Sprint Retrospective作為對當前Sprint的總結(jié)，看似和產(chǎn)品開發(fā)無關(guān)，其實在某種意義上可以說是最重要的會議。敏捷的原則就是在實踐中不斷總結(jié)和改進。Sprint Retrospective會議就是專門為團隊總結(jié)Scrum執(zhí)行過程的問題而設立的。

對于一個新成立或者剛開始實踐Scrum的團隊，建議在第一次Sprint Plan或者啟動會的時候?qū)ι鲜鯯crum各種會議的作用和意義有一個簡單介紹，盡量讓團隊成員認識到它們的重要性，從而最大限度的避免對會議的抵觸情緒。

當然，僅僅了解會議的重要性還不夠。為了保證會議高效而有序的進行，需要在會前、會中以及會后做很多工作，讓團隊切實感受到重要性。接下來我們針對不同類型的會議簡單介紹一下如何執(zhí)行的。

Sprint Plan會議

Sprint Plan會議最主要的就是討論和評估Product Backlog里面的Work Item。首先，Product Owner需要在平時就注意維護好Product Backlog，即保證Backlog里面的Work Item都反映了最新的需求，內(nèi)容具體明確，優(yōu)先級合理。

其次，在開始Sprint Plan會議前，Product Owner需要預先對需要討論的Work Item在進行一次梳理。必要的時候，可以和團隊的技術(shù)骨干或者主要開發(fā)人員事先溝通。這樣的好處是，在Sprint Plan會議中，團隊針對每個Work Item的討論更加高效，避免會上花大量時間思考和討論具體的需求細節(jié)。

另外，Sprint Plan會議還有一個可能引起拖延的問題就是對Work Item的打分。在標準的Scrum流程中，團隊成員需要根據(jù)自己對Work Item的理解，在不被其他成員影響的情況下獨立打分，然后針對不同的分數(shù)進行討論，直到達成一致為止。但是實際情況往往是，團隊成員由于各自的專業(yè)技能不同、知識面不同、能力不同，打出的分數(shù)各不相同?；蛘哂捎谝恍┘夹g(shù)細節(jié)，導致幾名成員討論的時候各不相讓。最終導致一個Work Item遲遲無法確定Effort。雖然充分的討論有助于提前發(fā)現(xiàn)問題和規(guī)避風險，但是這種過于陷入細節(jié)的爭論卻不利于會議的進程。因此可借鑒的做法是，在對Work Item打分的時候，選一個對此任務最為熟悉的成員打一個基準分，然后大家針對這個基準分投票。如果有不同意見再討論。

最后，當團隊工作量已經(jīng)飽和后，理論上來說Sprint Plan會議就結(jié)束了。但是為了應對估算誤差導致Sprint后期沒有任務可做的情況，可以適當多估算幾個Work Item作為備用。

Daily Scrum會議

Daily Scrum會議相對簡單，因此只需要注意成員在發(fā)言的時候避免幾個人過多的討論細節(jié)，導致會議無限期延長的情況。一旦出現(xiàn)這種情況，Scrum Master需要及時制止。

另外，有的團隊因為Product Owner參與多個Scrum團隊，或者Product Owner和Dev Team距離較遠（地理位置、時差），導致無法每次都參與Daily Scrum。為此可以考慮Dev Team的一個成員作為Product Owner Agent，臨時代理Product Owner的職責。對于相對簡單的需求問題可以直接決定，而對于那些不好判斷的問題則在會后單獨和Product Owner溝通。而這個Product Owner Agent的人選建議從測試人員中尋找，因為在Dev Team中測試人員對于需求的理解和把握是相對準確且中立的。

Sprint Review & Retrospective會議

Sprint Review一定要保證每一個Work Item都是以演示的形式進行驗收。對于功能性的Work Item，演示起來相對比較好實現(xiàn)。而對于那些非功能性Work Item，比如架構(gòu)設計、技術(shù)調(diào)研、可行性分析等，則看上去很難演示。對此，一般的做法是，對于架構(gòu)設計，通常在Work Item分解到Task的時候就包含和設計、評審、更新三個部分。而在評審部分，團隊成員和相關(guān)技術(shù)專家已經(jīng)Review過設計，并且在后續(xù)的更新環(huán)節(jié)針對評審結(jié)果做了修改。因此在最終的Sprint Review會議可以直接略過，或者簡單介紹一下評審結(jié)果。對于技術(shù)調(diào)研和可行性分析，則需要在Sprint Review會議上演示調(diào)研分析的成果，譬如例子程序、測試報告、分析報告等?？傊?，Sprint Review會議里面要求的演示并不僅僅指狹義的界面操作，也可以是文檔、例子、報告等一切能夠展示工作結(jié)果的東西。

Sprint Review的演示不宜過長，一般控制在每個5分鐘之內(nèi)，這就要求每個Work Item的負責人在會前準備好自己的演示環(huán)境和步驟。有一個可行的做法，就是在會前每個成員都在自己的測試環(huán)境準備好演示要用到的場景，會議開始后輪流接入投影儀演示。對于一些比較耗時或者操作等待時間很長的演示，也可以實現(xiàn)通過屏幕錄像的方式進行演示。這么做可以讓成員在演示前細心準備，也就是進行必要的測試。而進一步的，能夠讓團隊在開發(fā)過程中就對自己負責的Work Item的質(zhì)量進行持續(xù)關(guān)注。

Sprint Retrospective會議是對Sprint流程的總結(jié)會，因此需要注意不要成為對Sprint結(jié)果，或者對于團隊成員的總結(jié)會。Retrospective經(jīng)常會變成成員的批評與自我批評會議，這其實是不對的，需要Scrum Master特別注意。Scrum倡導的是團隊而非個人，因此Retrospective總結(jié)的也是團隊而非個人。

鑒于東方人大多比較含蓄和內(nèi)斂，Retrospective也有可能變成無聲靜默會議。這時候需要Scrum Master在會議前就能總結(jié)出一些待改進的事項，會上帶頭提出，引導其他成員參與?；蛘卟扇≥喠靼l(fā)言的機制，強制每個成員都要參與。但是無論什么手段，都要確保對流程不對結(jié)果，對事不對人。

最后，為了防止Retrospective只抱怨不解決，會議記錄需要明確提出來的每個問題的提出者、內(nèi)容、解決方案、負責人和截止時間。在下一次Retrospective會議中，Scrum Master可以先匯報上次Retrospective會議的記錄以及解決結(jié)果。這樣做的好處是用實際行動表明成員提出的每一個改進建議都是被重視被落實的，鼓勵大家繼續(xù)提出問題并改進。同時要指出，對于解決結(jié)果來說，某個問題最終沒能解決也是一種可接受結(jié)果。

一些通用原則

準時參會

– 會議開始前5分鐘之前，可以申請遲到。

– 會議開始后5分鐘內(nèi)到場，不算遲到。

– 會議開始后5分鐘之后，算遲到。

– 每一個遲到的成員需要給團隊發(fā)紅包或請吃零食等。

發(fā)言權(quán)

– 只有對項目有直接貢獻的成員可以發(fā)言

準時結(jié)束

– 絕不拖堂

– 未討論的內(nèi)容另行組織會議

會議記錄

– 除Daily Scrum外，所有會議均保存會議記錄，使用統(tǒng)一模板

– 會議記錄包括：時間、參會人、議題、決議、負責人和截止時間。

總結(jié)

Scrum流程中，各種會議是其主要的組成部分，也是推進Scrum進行的基礎(chǔ)。確保這些會議有序高效的進行是能否成功開展Scrum的關(guān)鍵。因此團隊，特別是Scrum Master要對此給予足夠的重視。

上面提到的一些原則、經(jīng)驗和流程僅僅是基于我之前參與過的Scrum項目總結(jié)而來的。而實際上，Scrum團隊各不相同，會議的內(nèi)容、進程和安排也不會完全一樣。這需要整個團隊不斷地嘗試、磨合、改進。最重要的，確保會議的討論是有意義的，是得到團隊認可的，才能最終達到目的。

#專欄作家#

袁林，人人都是產(chǎn)品經(jīng)理專欄作家。分享SaaS運營和企業(yè)管理／協(xié)作／辦公的相關(guān)知識

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels ，基于 CC0 協(xié)議