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