成功推進Scrum需要一些重要的會議，包括Sprint計劃、Sprint審查、每日Scrum和Sprint回顧等。
作為一個敏捷教練，我在輔導(dǎo)很多Scrum團隊的時候發(fā)現(xiàn)，很多人對關(guān)于誰應(yīng)該參加這些會議、什么時候舉行這些會議、每個會議需要多長時間、會議的目的等等有很多困惑，后來我就做了一個Scrum迭代日歷發(fā)給了他們，他們頓時覺得清晰多了（微信搜索“小船哥說敏捷”，回復(fù)“迭代日歷”可以直接下載Excel版）：
下面我來就這個日歷做一些解讀：
0.寫在前面
我在輔導(dǎo)團隊的時候經(jīng)常會遇到的一個反饋是：Scrum的會議太多了，我們能不能少開一些？
遇到這個問題的時候，我一般的回答是：
會議只是形式，敏捷不強求一定要開會，只要能達到每種會議背后的目的即可。
那如果我們不開會，怎樣來達到這些目的呢？對于我們經(jīng)常說的這些會議（Meeting），Jeff在Scrum指南中稱作事件（Event），Mike Cohn將其稱作儀式（Ceremony），我個人比較偏向于儀式（Ceremony）這個詞。
儀式的簡單解釋是“從一種狀態(tài)向另一種狀態(tài)轉(zhuǎn)化的過渡階段、中間狀態(tài)”，比如結(jié)婚的儀式，就是情侶向夫妻轉(zhuǎn)化的中間階段。但是儀式只是一個抽象的概念，我們要怎樣實現(xiàn)儀式呢？還拿結(jié)婚舉例，常見的儀式就是婚禮，除了婚禮之外，現(xiàn)在也有很多的年輕人通過旅行結(jié)婚、集體婚禮的方式來完成這個儀式。
所以要實現(xiàn)敏捷的各種儀式，我們“常見”的方式就是會議（Meeting）（類比結(jié)婚這個儀式的常見實現(xiàn)形式是婚禮），除了會議以外，我們也可以采用其他一些方式來實現(xiàn)，下文中會給出一些建議。
那我們可以放棄或裁減掉一些儀式嗎？我之前看過一篇心理學的調(diào)研（暫時找不到在哪了，后續(xù)找到的話我會把鏈接貼出來），心理學家采集了結(jié)婚7年后的夫妻的很多關(guān)于幸福度的指標，調(diào)研結(jié)果顯示：那些辦了婚禮的夫妻，比那些未辦婚禮的夫妻，幸福度要高很多。所以，這些敏捷的儀式要不要裁剪，你們自己看著辦吧~ :)
1.需求梳理
需求梳理是指確保產(chǎn)品待辦列表頂部的需求已準備好排入下一個迭代。這包括為需求增添細節(jié)、估算和排序等。需求梳理的目的是使需求更適合排入Sprint。
雖然需求梳理這個過程是必須的，但并不強制要求團隊將其作為一個正式的會議。但是大多數(shù)團隊會定期召開需求梳理會，通常每迭代一次或每周一次。
需求梳理的一般原則是，無論在會議中，還是在可能由這些會議引發(fā)的討論中，花費在改進產(chǎn)品待辦列表的時間不應(yīng)超過團隊總可用時間的10％。
Scrum指南建議讓Scrum團隊來決定如何以及何時完成需求梳理的工作。大多數(shù)團隊是讓整個開發(fā)團隊、PO和SM一起參與。但是《用戶故事實戰(zhàn)》一書建議，除非團隊要在梳理會上對用戶故事進行估算，否則只要開發(fā)團隊的一半到三分之二的人就足夠了；《用戶故事地圖》一書建議，由業(yè)務(wù)、研發(fā)和測試這三個角色組成的3-5人的跨職能小組參加即可。后面的2種組織方式，可以減輕團隊的總體會議時間負擔。
這個流程的輸入是Product Backlog。輸出是梳理后的Product Backlog，Backlog中的需求項通常被分割成更小的、更適合排入Sprint的用戶故事，以及對某些需求的更深刻的理解。
2.Sprint計劃
Sprint計劃標志著迭代的正式開始。一旦這個會議開始，迭代也就開始了。
整個開發(fā)團隊、PO和SM都將參與這個會議。Sprint計劃會的長度與迭代的長度成正比。按照Scrum指南的建議，一個月的迭代，計劃會議最好不超過8個小時，如果是兩周的迭代，會議時長最好不超過4小時。
這個時間是最大的時間盒，我建議團隊可以通過不斷的迭代，將時間控制在最大時間盒的一半左右，即兩周的迭代能控制在2小時左右。
這個流程的輸入是團隊的平均速率（我一般建議是過去3個迭代的數(shù)據(jù)做平均）、最新速率、Product Backlog，前兩個數(shù)據(jù)由SM提供，后一個的數(shù)據(jù)由PO提供。在許多團隊中，PO還會提供一個Sprint目標的草案，該目標草案可以在計劃的過程中，與開發(fā)團隊一起協(xié)商、修改。
Sprint計劃的輸出是Sprint Backlog，以及一個大家都認同的Sprint目標，還有一個隱性的輸出是一個對即將到來的工作更加了解并為之做好了充分準備的團隊。
3.每日Scrum
每日Scrum（Daily Scrum），也稱為每日站會（Daily Stand-up），是一個簡短的、團隊成員同步工作、尋求協(xié)作的每日會議。每日Scrum使團隊成員能夠確保正確的人在正確的時間處理正確的事情。
Scrum指南中對每日Scrum的召開方式給了一個“可以使用的范例”：
- 昨天，我為幫助開發(fā)團隊達成 Sprint 目標做了什么？
- 今天，我為幫助開發(fā)團隊達成 Sprint 目標準備做什么？
- 是否有任何障礙在阻礙我或開發(fā)團隊達成 Sprint 目標？
除了這種范例以外，也可以使用其他的方式來進行，例如，很多團隊發(fā)現(xiàn)相比于描述自己“做了什么”，他們認為描述“完成了什么”更有利于目標的實現(xiàn)。
每日Scrum的參與者包括整個開發(fā)團隊、PO和SM。關(guān)于PO是否應(yīng)該參加每日Scrum，在一些Scrum的微信群、論壇上存在不少爭議，我個人認為如果將PO從每日Scrum中排除出去，會使PO和開發(fā)團隊造成隔閡。Scrum強調(diào)的是跨職能組織，要推倒部門墻，我們既然都是一個團隊了，為什么要把PO排除在外呢？
每日Scrum的時間限制為15分鐘，其目的是為了進行簡短的更新和同步。與Sprint計劃不同，我建議每日Scrum的時間不要太短，對于大多數(shù)團隊而言，5-7分鐘的會議時間根本不足以提出任何實質(zhì)的問題或理解正在完成的工作。當團隊將每日Scrum的時間縮短得太多時，會議就會變成一系列機械的更新，比如“昨天我做了這樣那樣的事，今天我要做這個和那個，沒有什么問題阻礙我?！?/p>
每日Scrum沒有正式的輸入，唯一的輸出是增加了開發(fā)團隊的工作協(xié)調(diào)性。
4.Sprint評審
Sprint評審在迭代的最后一天進行。整個開發(fā)團隊、PO、SM和任何相關(guān)的利益相關(guān)者都應(yīng)參加。利益相關(guān)者可能會根據(jù)迭代交付內(nèi)容的不同而有所變化。
按照Scrum指南的建議，一個月的迭代，Sprint評審的時間最多為4個小時。評審的時間會隨著迭代長短按比例縮放，對于兩周的迭代，則應(yīng)縮短到2小時。
這個流程的輸入是，所有符合完成定義（DoD）的用戶故事，這意味著團隊不會演示仍在進行中的工作。
在Atlassian公司（旗下的產(chǎn)品有Jira、Confluence、Trello等），他們的一些團隊會采用非會議的方式進行Sprint評審，比如他們會聚集在團隊成員的辦公桌旁看他們演示新功能。在辦公室里大家經(jīng)常會聽到鼓掌的情況。
Sprint評審的主要流程是完成功能的演示，但大多數(shù)團隊也會花時間來討論進展和問題，以便從利益相關(guān)者那里獲得更多關(guān)于構(gòu)建結(jié)果和未來產(chǎn)品方向的反饋。PO會考慮所有反饋，并更改Product Backlog。因此，迭代評審的輸出是一份修訂后的Product Backlog。
5.Sprint回顧
Sprint回顧是團隊成員考慮如何改進工作方式的時間，在這個會議上大家可以討論Scrum的流程、合作的方式，遇到的障礙、改進的辦法等等。整個開發(fā)團隊、PO和SM都應(yīng)該參加Sprint回顧。
Sprint回顧的輸入是團隊的客觀數(shù)據(jù)，我一般會帶來團隊過去5個迭代的故事數(shù)、故事點數(shù)、故事流動時間等數(shù)據(jù)的趨勢圖，以及本次迭代的燃盡圖，以此引發(fā)大家對團隊產(chǎn)出、合作流程的思考和討論。輸出是團隊對其工作方式的改進項。
按照Scrum指南的建議，一個月的迭代，Sprint回顧會的時間限制為3小時。對于較短的Sprint來說，會議時間通常會縮短。但是這個縮短的時間跟Sprint計劃和Sprint評審不一樣，它沒法做到會議時間隨迭代長短按比例縮放，但是我們要盡可能的縮短這個會議的時間。
6.小結(jié)
Scrum創(chuàng)始人Jeff在《敏捷革命》一書提到，敏捷實踐要遵循“守破離”的節(jié)奏：先遵守規(guī)則，再打破規(guī)則，最后成為規(guī)則。所以對于這份Scrum迭代日歷，我建議大家先嘗試以“會議”的形式，在熟練掌握各個會議的流程及其背后的意義之后，再嘗試做一些規(guī)則的突破。
至于最后能不能成為新的規(guī)則，不努力一下怎么會知道呢？
全文完，微信搜索“小船哥說敏捷”，回復(fù)“迭代日歷”可以直接下載Excel版。
