最近把之前學(xué)習(xí) Scrum 的資料整理為一篇文檔，在接下來的團(tuán)隊和項目開發(fā)中，根據(jù)項目的情況引入 Scrum 的一些實踐，提高團(tuán)隊成員之間的協(xié)作能力和項目的交付質(zhì)量。
參考資料：
Scrum 工具
Scrum 中的角色
Scrum Master——項目負(fù)責(zé)人、項目經(jīng)理
保護(hù)團(tuán)隊不受外界干擾，是團(tuán)隊的領(lǐng)導(dǎo)和推進(jìn)者，負(fù)責(zé)提升 Scrum 團(tuán)隊的工作效率，控制 Scrum 中的“檢視和適應(yīng)”周期過程。與 Product Owner 一起將投資產(chǎn)出最大化，他確保所有的利益相關(guān)者都可以理解敏捷和尊重敏捷的理念。
Team——開發(fā)人員、測試人員、美工設(shè)計、DBA等全職能性團(tuán)隊
團(tuán)隊負(fù)責(zé)交付產(chǎn)品并對其質(zhì)量負(fù)責(zé)，團(tuán)隊與所有提出產(chǎn)品需求的人一起工作，包括客戶和最終用戶，并共同創(chuàng)建 Product Backlog 。團(tuán)隊按照大家的共識來創(chuàng)建功能設(shè)計、測試 Backlog 條目交付產(chǎn)品。
Product Owner——產(chǎn)品負(fù)責(zé)人、產(chǎn)品經(jīng)理、運(yùn)營人員
從業(yè)務(wù)角度驅(qū)動項目，傳播產(chǎn)品的明確愿景，并定義其主要特性。Product Owner 的主要職責(zé)是確保團(tuán)隊只開發(fā)對于組織最重要的 Backlog 條目，在 Sprint 中幫助團(tuán)隊完成自己的工作，不干擾團(tuán)隊成員，并迅速提供團(tuán)隊需要的所有信息。
User——最終用戶、運(yùn)營人員、系統(tǒng)使用人員
很多人都可能成為最終用戶，比如市場部人員、真正的最終用戶、最好的領(lǐng)域?qū)＜?，也可能是因其專業(yè)知識而被雇傭的資訊顧問。最終用戶會根據(jù)自己的業(yè)務(wù)知識定義產(chǎn)品，并告知團(tuán)隊自己的期望，提出請求。
Manager——管理層、投資人
管理層要為 Scrum 團(tuán)隊搭建良好的環(huán)境，以確保團(tuán)隊能夠出色工作，必要的時候，他們也會與 Scrum Master 一起重新組織結(jié)構(gòu)和指導(dǎo)原則。
Customer——客戶、系統(tǒng)使用人員、運(yùn)營人員
客戶是為 Scrum 團(tuán)隊提出產(chǎn)品需求的人，她會與組織簽訂合同，以開發(fā)產(chǎn)品。一般來說，這些人是組織中的高級管理人員，負(fù)責(zé)從外部軟件開發(fā)公司購買軟件開發(fā)能力。在為內(nèi)部產(chǎn)品的公司中，負(fù)責(zé)批準(zhǔn)項目預(yù)算的人就是客戶。
Scrum 中的產(chǎn)出物
Product Backlog——Backlog 待開發(fā)項，積壓的任務(wù)。
產(chǎn)品 Backlog 包括了所有需要交付的內(nèi)容，其內(nèi)容根據(jù)業(yè)務(wù)需求的價值順序排列，每個 Backlog 的優(yōu)先級是可以調(diào)整的，需求是可以增減的，因此產(chǎn)品 Backlog 將根據(jù)不斷增長來持續(xù)驅(qū)動維護(hù)。
Sprint Backlog——Sprint 本意為“沖刺”，指迭代周期，長度通常是一至六周。
在 Sprint 開始前，定義本次 Sprint 要討論的“Sprint Backlog”，從中產(chǎn)生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog
Sprint 計劃會議的產(chǎn)物，它定義了團(tuán)隊所接受的工作量，在整個 Sprint 過程中它將保持不變。
User Story、Task——用戶故事、任務(wù)
用 User Story 來描述 Sprint Backlog 里的項目，User Story 是從用戶的角度對系統(tǒng)的某個功能模塊所作的簡短描述。一個 User Story 描述了項目中的一個小功能，以及這個功能完成之后將會產(chǎn)生什么效果，或者說能為客戶創(chuàng)造什么價值。一個 User Story 的大小和復(fù)雜度應(yīng)該以能在一個 Sprint 中完成為宜。如果 User Story 太大，可能會導(dǎo)致對它的開發(fā)橫跨幾個 Sprint，此時就應(yīng)該將這個 User Story 分解。
為了能夠及時，高效地完成每個 Story，Scrum 團(tuán)隊會把每個 Story 分解成若干個 Task。每個Task 的時間最好不要超過8小時，保證在1個工作日內(nèi)完成，如果 Task 的時間超過了8個小時，就說明Task的劃分有問題，需要特別注意。
障礙 Backlog——問題列表，積壓的待處理事務(wù)。
列舉了所有團(tuán)隊內(nèi)部和團(tuán)隊相關(guān)的和阻礙項目的進(jìn)度的問題，Scrum Master 需要確保所有的障礙 Backlog 中的問題都已分配并可以得到解決。
通用會議規(guī)則
基本要求
- 每次會議都要準(zhǔn)時開始、準(zhǔn)時結(jié)束。
- 每次會議都采取開放形式，所有人都可以參加。
會前準(zhǔn)備
- 提前邀請所有必須參會的人，讓他們有時間準(zhǔn)備。
- 發(fā)送帶有會議目標(biāo)和意圖的會議綱要。
- 預(yù)訂會議所需的全部資源：房間、投影儀、掛圖、主持設(shè)備，以及此會議需要的其他東西。
- 會前24小時發(fā)送提醒。
- 準(zhǔn)備帶有會議規(guī)則的掛圖。
會議推進(jìn)
- 展開討論時，會議的推進(jìn)人必須在場。他不能參與到具體討論中，但是他需要注意討論進(jìn)程，如果討論參與者失去重點，他還要將討論帶回正規(guī)。
- 推進(jìn)人展示會議的目標(biāo)和意圖。
- 有必要時，推進(jìn)人可以商定由某個撰寫會議記錄。
- 推進(jìn)人可以記錄團(tuán)隊的意見，或是教授團(tuán)隊如何自己記錄文檔；而且推進(jìn)人可能會在掛圖上進(jìn)行記錄，將對話可視化。
- 推進(jìn)人會對會議進(jìn)行收尾，并進(jìn)行非常簡短的回顧。
會議輸出
- 使用手寫或掛圖說明來記錄文檔，給白板和掛圖上的內(nèi)容拍照。
- 必須傳達(dá)會議記錄和大家對會議結(jié)果的明確共同認(rèn)知。
讓團(tuán)隊坐在一起！
- 大家都懶的動，盡量讓“產(chǎn)品負(fù)責(zé)人”和“全功能團(tuán)隊”都坐在一起！
- 互相聽到：所有人都可以彼此交談，不必大聲喊，不必離開座位。
- 互相看到：所有人都可以看到彼此，都能看到任務(wù)板——不用非得近到可以看清楚內(nèi)容，但至少可以看到個大概。
- 隔離：如果你們整個團(tuán)隊突然站起來，自發(fā)形成一個激烈的設(shè)計討論，團(tuán)隊外的任何人都不會被打擾到，反之亦然。
團(tuán)隊建設(shè)
- Scrum 團(tuán)隊最佳人數(shù)控制在“5～9”人。
- 全職能性團(tuán)隊：開發(fā)組（后臺開發(fā)、前端開發(fā)、測試人員——3~8人）、Scrum Master（項目經(jīng)理）、產(chǎn)品負(fù)責(zé)人
- 兼職團(tuán)隊成員：美工、DBA、運(yùn)維
每日立會（Daily Standup Meeting）——建議下班前開始
會議目的
- 團(tuán)隊在會議中作計劃，協(xié)調(diào)其每日活動，還可以報告和討論遇到的障礙。
- 任務(wù)板能夠幫助團(tuán)隊聚焦于每日活動之上，要在這個時候更新任務(wù)板和燃盡圖。
構(gòu)成部分
- 任務(wù)板、即時貼、馬克筆
- 提示：ScrumMaster 不要站在團(tuán)隊前面或是任務(wù)板旁邊，不要營造類似于師生教學(xué)的氣氛。
基本要求
- 成員：團(tuán)隊、Scrum Master
- 無法出席的團(tuán)隊成員要由同伴代表。
- 持續(xù)時間/舉辦地點：每天15分鐘，同樣時間，同樣地點。
- 提示：團(tuán)隊成員在聆聽他人發(fā)言時，都應(yīng)該想這個問題：“我該怎么幫他做得更快？”
會議輸出
- 團(tuán)隊彼此明確知道各自的工作，最新的工作進(jìn)度圖。
- 得到最新的“障礙 Backlog”
- 得到最新的“Sprint Backlog”
會議過程
- 團(tuán)隊聚在故事板旁邊，可以圍成環(huán)形。
- 從左邊第一個開始，向團(tuán)隊伙伴說明他到現(xiàn)在完成的工作。
- 然后該成員將任務(wù)板上的任務(wù)放到正確的列中。
- 如果可以的話，該成員可以選取新的任務(wù)，交將其放入“進(jìn)行中工作”列。
- 如果該成員遇到問題或障礙，就要將其報告給 Scrum Master。
- 每個團(tuán)隊成員重復(fù)步驟2到步驟5。
每個人三個問題：
- 上次會議時的任務(wù)哪些已經(jīng)完成？：把任務(wù)從“正在處理”狀態(tài)轉(zhuǎn)為“已完成”狀態(tài)?！裉焱瓿闪耸裁?？
- 下次會議之前，你計劃完成什么任務(wù)？：如果任務(wù)狀態(tài)為“待處理”，轉(zhuǎn)為“正在處理”狀態(tài)。如果任務(wù)不在 Sprint Backlog 上，則添加這個任務(wù)。如果任務(wù)不能在一天成，把這任務(wù)細(xì)分成多個任務(wù)。如果任務(wù)可以在一天內(nèi)完成，把任務(wù)狀態(tài)設(shè)為“正在處理”。如果任務(wù)狀態(tài)已經(jīng)是“正在 處理”，詢問是否存在阻礙任務(wù)完成得問題?！魈熳鍪裁矗?/li>
- 有什么問題阻礙了你的開發(fā)？：如果有阻礙你的開發(fā)進(jìn)度的問題，把該障礙加入到障礙 Backlog中?！裉煊龅搅耸裁磫栴}？
注意事項
- 不要遲到
- 不要超出限制時間
- 不要討論技術(shù)問題
- 不要轉(zhuǎn)變會議話題
- 不要在沒有準(zhǔn)備的情況下參加
- Scrum Master 不要替團(tuán)隊成員移動任務(wù)卡片，不要替團(tuán)隊更新燃盡圖。
- Scrum Master 不要提出問題，團(tuán)隊成員不要向 Scrum Master 或管理層人員報告。
- 如果不能出席會議，需要通知團(tuán)隊，并找一名代表參加。
任務(wù)板
- 任務(wù)板集合了選擇好的 Product Backlog 和 Sprint Backlog，并以可視化方式展示。
- 任務(wù)板只能由團(tuán)隊維護(hù)，使用不同顏色的“即時貼”來區(qū)分開發(fā)人員，或者在“即時貼”寫上接受任務(wù)的姓名。
- 盡量使用大白板，也可以使用軟件。
任務(wù)板有4列：
- 選擇好的 Product Backlog：按照優(yōu)先級，將團(tuán)隊在當(dāng)前 Sprint 中要著手的 Product Backlog 條目或是故事放在該列中。
- 待完成的任務(wù)：要完成一個故事，你得完成一些任務(wù)。在 Sprint 規(guī)劃會議中，或是在進(jìn)行當(dāng)前 Sprint 中，收集所有特定 Backlog 條目需要完成的新任務(wù)，并將它們放入該列。
- 進(jìn)行中的工作：當(dāng)團(tuán)隊成員開始某個任務(wù)后，他會將該任務(wù)對應(yīng)的卡片放到“進(jìn)行中的工作”列中。從上個每日 Scrum 例會開始，沒有完成的任務(wù)都會放在該列中，并在上面做標(biāo)記（通常是個紅點）。如果某個任務(wù)在“待完成任務(wù)”列中所處時間超過一天，就盡量將該任務(wù)分為更小 的部分，然后把新任務(wù)放到那一列，移除其所屬大任務(wù)卡片。如果一個新任務(wù)因為某個障礙無法完成，就會得到一個紅點標(biāo)記，Scrum Master 就會記下一個障礙。
- 完成：當(dāng)一個任務(wù)卡完成后，完成此任務(wù)的成員將其放入“完成”列，并開始選取下一張任務(wù)卡。
燃盡圖（Burn Down Chart）
- 跟蹤進(jìn)度要由團(tuán)隊來完成，燃盡圖的橫軸表示整個Sprint 的總時間，縱軸表示 Sprint 中所有的任務(wù)，其單位可以是小時，人天等。一般來說，燃盡圖有”Sprint燃盡圖”和”Release燃盡圖”之分。
- 團(tuán)隊每天更新燃盡圖。
- 如果燃盡圖一直是上升狀態(tài)，或當(dāng) Sprint 進(jìn)行一段時間之后，Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾，就說明這個 Sprint 中的 Story 過多，要拿掉一些 Story 以保證這個 Sprint 能順利完成。 如果Sprint 燃盡圖下降得很快，例如 Sprint 剛過半時Y值已經(jīng)接近0了，則說明這個 Sprint 分配的任務(wù)太少，還要多加一些任務(wù)進(jìn)來。在 Sprint 計劃會議上，如果團(tuán)隊對即將要做的任務(wù)理解和認(rèn)識不充分，就很可能導(dǎo)致這兩種情況的出現(xiàn)。（鍛煉團(tuán)隊人員的自我估算時間）
- 燃盡圖要便于團(tuán)隊更新，沒必要讓它看起來很炫，也不要過于復(fù)雜，難以維護(hù)。
Release 燃盡圖：記錄整個Scurm項目的進(jìn)度，它的橫軸表示這個項目的所有Sprint， 縱軸表示各個Sprint開始前，尚未完成的工作，它的單位可以是個（Story 的數(shù)量），人天等。
Sprint 規(guī)劃會議——第一部分（上午）
會議目的
- 該會議的工作以分析為主，目的是要詳細(xì)理解最終用戶到底要什么，產(chǎn)品開發(fā)團(tuán)隊可以從該會議中詳細(xì)了解最終用戶的真實需要。在會議的結(jié)束，團(tuán)隊將會決定他們能夠交付哪些東西。
- 產(chǎn)品負(fù)責(zé)人在會前準(zhǔn)備：條目化的需求（用戶故事），優(yōu)先級排序，最近1~2個迭代最希望看到的功能。會前準(zhǔn)備至關(guān)重要，可幫助產(chǎn)品負(fù)責(zé)人理清頭緒，不至于在迭代期內(nèi)頻繁提出變更、增加或刪除故事。
基本要求
- 迭代計劃會在每個迭代第一天召開，目的是選擇和估算本次迭代的工作項。
- 只有團(tuán)隊成員才能決定團(tuán)隊在當(dāng)前 Sprint 中能夠領(lǐng)取多少個 Backlog 條目的工作。
構(gòu)成部分：
- 經(jīng)過估算和排序的 Product Backlog。
- 掛圖、馬克筆、剪刀、膠水、即時貼、白板、鉛筆和蠟筆。
- 假期計劃表、重要人員的詳細(xì)聯(lián)系信息。
- 參會成員：團(tuán)隊成員、Scrum Master、產(chǎn)品負(fù)責(zé)人
持續(xù)時間：在 Sprint 中，每周該會議占用時間為 60 分鐘，在早上召開該會議，這樣還有可能在同一天召開 Sprint 規(guī)劃會議的第二部分。
會議輸出
- 選擇好的 Product Backlog 條目。
- 各個 Backlog 條目的需求。
- 各個 Backlog 條目的用戶驗收測試。
會議過程
- 從第一個 Product Backlog 條目（故事）開始。
- 討論該 Product Backlog 條目，以深入理解。
- 分析、明確用戶驗收測試。
- 找到非功能性需求（性能、穩(wěn)定性...）
- 找到驗收條件。
- 弄清楚需要“完成”到何種水平。
- 獲得 Backlog 條目各個方面的清晰了解。
- 繪制出所需交付物的相關(guān)圖表，包括流程圖、UML圖、手繪草圖、屏幕 UI 設(shè)計等。
- 回到步驟1，選取下一個 Backlog 條目。
流程檢查：詢問團(tuán)隊能否快速回答下列問題，只需要簡要回答即可：“我們能 在這個 Sprint 中完成第一個 Backlog 條目嗎？”如果能得到肯定的回答，那么繼續(xù)詢問下一個 Backlog 條目，一直到已經(jīng)分析完的最后一個 Backlog 條目。——接下來，休息一下。在休息后，對下一個 Backlog 條目展開上述流程。
結(jié)束流程：
- 在 Sprint 規(guī)劃會議第一部分結(jié)束前留出 20 分鐘。
- 再次提問——這次要更加嚴(yán)肅、正式：“你們能否完成第一個 Backlog 條目，...第二個，...？”
- 如果團(tuán)隊認(rèn)為他們不能再接受更多的 Backlog 條目，那就停下來。
- 現(xiàn)在是非常重要的一步：送走 Product Owner，除了團(tuán)隊和 Scrum Master 之外的所有人，都得離開。
- 當(dāng)其他人都離開后，再詢問團(tuán)隊：“說真的——你們相信自己可以完成這個列表？”
- 希望團(tuán)隊現(xiàn)在能短暫討論一下，看看他們到底認(rèn)為自己能完成多少工作。
- 將結(jié)果與 Product Owner 和最終用戶溝通。
注意事項：不要改變 Backlog 條目大小，不要估算任務(wù)。
Sprint 規(guī)劃會議——第二部分（下午）
會議目的
- 該會議的工作以設(shè)計為主，產(chǎn)品開發(fā)團(tuán)隊可以為他們要實現(xiàn)的解決方案完成設(shè)計工作，在會議結(jié)束后，團(tuán)隊知道如何構(gòu)建他們在當(dāng)前 Sprint 中要開發(fā)的功能。
基本要求
- 只有產(chǎn)品開發(fā)團(tuán)隊才能制定解決方案，架構(gòu)師或其他團(tuán)隊之外的人只是受邀幫助團(tuán)隊。
構(gòu)成部分：
- 能夠幫助團(tuán)隊在該 Sprint 中構(gòu)建解決方案的人，比如廠商或是來自其他團(tuán)隊的人員。
- 選擇好的 Product Backlog 條目。
- 掛圖......
注意事項：不要估算任務(wù)，不要分配任務(wù)。
會議輸出
- 應(yīng)用設(shè)計、架構(gòu)設(shè)計圖、相關(guān)圖表
- 確保團(tuán)隊知道應(yīng)該如何完成任務(wù)！
會議過程
- 從第一個 Backlog 條目開始。
- 查看掛圖，確定對于客戶的需求理解正確。
- 圍繞該 Backlog 條目進(jìn)行設(shè)計，并基于下列類似問題：
- 我們需要編寫什么樣的接口？
- 我們需要創(chuàng)建什么樣的架構(gòu)？
- 我們需要更新哪些表？
- 我們需要更新或是編寫哪些組件？
- ......
當(dāng)團(tuán)隊明確知道自己應(yīng)該如何開發(fā)該功能后，就可以轉(zhuǎn)向下一個 Backlog 條目了。在會議的最后 10 分鐘，團(tuán)隊成員使用即時貼寫出初步的任務(wù)。這能幫助團(tuán)隊成員知道接下來的工作從哪里開展，將這些任務(wù)放在任務(wù)板上。
持續(xù)時間：在 Sprint 規(guī)劃會議第一部分完成后，召開該會議?？梢詫⑽绮妥鳛閮纱螘h的一個更長久的休息。但是要在同一天完成 Sprint 規(guī)劃第一部分，在 Sprint 中，每周該會議占用時間為 60 分鐘。
估算會議——根據(jù)項目情況合并到 Sprint 第二部分會議
會議目的
- 要做好戰(zhàn)略規(guī)劃，你需要知道 Backlog 中各項的大小，這是版本規(guī)劃的必要輸入；如果想知道團(tuán)隊在一個 Sprint 中能夠完成多少工作，這個數(shù)據(jù)也是必須的。
- 團(tuán)隊成員可以從會議中知道項目接下來的階段會發(fā)生哪些事情。
基本要求
- 只有團(tuán)隊才能作估算，Product Owner（產(chǎn)品負(fù)責(zé)人）需要在場，以幫助判定某些用戶故事能否拆分為更小的故事。
構(gòu)成部分：
- Product Owner 根據(jù)業(yè)務(wù)價值排定 Product Backlog 各項順序。
- 需要參加的人員：Team、Product Owner、User、Scrum Master
注意事項：
- 不要估算工作量大小——只有團(tuán)隊能這么做。
- Product Owner 不參與估算。
會議過程
- Prodcut Owner 展示她希望得到估算的 Product Backlog 條目。
- 團(tuán)隊使用規(guī)劃撲克來估算 Backlog 條目。
- 如果某個 Backlog 條目過大，需要放到下一個或是后續(xù)的 Sprint 中，團(tuán)隊就會將該大 Backlog 條目劃分為較小的幾個 Backlog 條目，并對新的 Backlog 條目使用規(guī)劃撲克進(jìn)行估算。
- 重新估算 Backlog 中當(dāng)前沒有完成、但是可能會在接下來三個 Sprint 中要完成的條目。
持續(xù)時間：該會議時間限制為不超過90分鐘。如果 Sprint 持續(xù)時間長于一周，那么每個 Sprint 舉行兩次估算會議比較合適。
會議輸出
- 經(jīng)過估算的 Product Backlog。
- 更小的 Backlog 條目。
撲克牌估算（Planning Poker）
具體步驟：
- 每個人各自估算后獨立出暗牌，聽口令一起開牌。
- 數(shù)值最大者與最小者PK，其他人旁聽也可參考。
- 討論結(jié)束后重新出牌和開牌。
- 重復(fù)上述過程，直到結(jié)果比較接近。
常見問題
1、為什么任務(wù)要分給組而不是個人？
答：因為怕出錯了牌又說不出所以然，這樣即使日后他不做這個功能，也對這個功能很了解。
2、為什么不讓最后領(lǐng)任務(wù)的人自己估算？
答：因為他很可能因為不知道某代碼可用、不知道某軟件不行....而選擇了錯誤的實現(xiàn)方法。
3、為什么不讓師傅估算大家采納，他不是最厲害嗎？
答：師傅的想法常常是徒弟們理解不了的，比如為什么不留在女兒國而偏偏去西天取經(jīng)之類的，共同估算就是讓大家在思考中對照自己的實現(xiàn)方法和師傅差異的過程。
Sprint 評審會議（Review Meeting）——根據(jù)項目需要舉行
會議目的
- Scrum 團(tuán)隊在會議中向最終用戶展示工作成果，團(tuán)隊成員希望得到反饋，并以之創(chuàng)建或變更 Backlog 條目。
基本要求
- Sprint 復(fù)審會議允許所有的參與者嘗試由團(tuán)隊展示的新功能。
構(gòu)成部分
- 有可能發(fā)布的產(chǎn)品增量，由團(tuán)隊展示。
會議輸出
- 來自最終用戶的反饋。
- 障礙 Backlog 的輸入。
- 團(tuán)隊 Backlog 的輸入。
- 來自團(tuán)隊的反饋為 Product Backlog 產(chǎn)生輸入。
持續(xù)時間：90分鐘，在 Sprint 結(jié)束時進(jìn)行。
會議過程
- Product Owner 歡迎大家來參加 Sprint 復(fù)審會議。
- Product Owner 提醒大家關(guān)于本次 Sprint 的目的：Sprint 目標(biāo)、Scrum 團(tuán)隊在本次 Sprint 中選定要開發(fā)的故事。
- 產(chǎn)品開發(fā)團(tuán)隊展示新功能，并讓最終用戶嘗試新功能。
- Scrum Master 推進(jìn)會議進(jìn)程。
- 最終用戶的反饋將會由 Product Owner 和/或 Scrum Master 記錄在案。
注意事項：
- 不要展示不可能發(fā)布的產(chǎn)品增量。
- Scrum Master 不要負(fù)責(zé)展示結(jié)果。
- 團(tuán)隊不要針對 Product Owner 展示。
- Sprint 反思會議（Retrospective Meetin）——根據(jù)項目需要舉行
會議目的
- 該會議的對應(yīng)隱喻：醫(yī)療診斷！其目的不是為了找到治愈方案，而是要發(fā)現(xiàn)哪些方面需要改進(jìn)。
構(gòu)成部分
- 參與人員：團(tuán)隊成員、Scrum Master
基本要求
- 從過去中學(xué)習(xí)，指導(dǎo)將來。
- 改進(jìn)團(tuán)隊的生產(chǎn)力。
注意事項
- 不要讓管理層人員參與會議。
- 不要在團(tuán)隊之外討論找到的東西。
會議輸出
- 障礙 Backlog 的輸入。
- 團(tuán)隊 Backlog 的輸入。
持續(xù)時間：90分鐘，在 Sprint 評審會議結(jié)束后幾分鐘開始。
會議過程
- 準(zhǔn)備一個寫著“過去哪些做的不錯？”的掛圖。
- 準(zhǔn)備一個寫著“哪些應(yīng)該改進(jìn)？”的掛圖。
- 繪制一條帶有開始和結(jié)束日期的時間線。
- 給每個團(tuán)隊成員發(fā)放一疊即時貼。
- 開始回顧。
- 做一個安全練習(xí)。
- 收集事實：發(fā)放即時貼，用之構(gòu)成一條時間線。每個團(tuán)隊成員（包括 Scrum Master）在每張即時貼上寫上一個重要的事件。
- “過去哪些做的不錯？”：采取收集事實同樣的過程，不過這次要把即時貼放在準(zhǔn)備好的掛圖上。
- 做一個分隔，以區(qū)分“過去哪些做的不錯”和接下來要產(chǎn)出的東西。
- “哪些應(yīng)該改進(jìn)？”：像“過去哪些做的不錯”那樣進(jìn)行。
- 現(xiàn)在將即時貼分組：
- 我們能做什么》團(tuán)隊 Backlog 的輸入。
- 哪些不在我們掌控之內(nèi)？》障礙 Backlog 的輸入。
- 根據(jù)團(tuán)隊成員的意見對兩個列表排序。
- 將這兩個列表作為下個 Sprint 的 Sprint 規(guī)劃會議第一部分和 Sprint 規(guī)劃會議第二部分的輸入，并決定到時候要如何處理這些發(fā)現(xiàn)的信息。
附兩張流程圖（資料截圖）
轉(zhuǎn)自：http://www.cnblogs.com/astar/archive/2012/02/28/Scrum.html
