最近把之前學習 Scrum 的資料整理為一篇文檔，在接下來的團隊和項目開發中，根據項目的情況引入 Scrum 的一些實踐，提高團隊成員之間的協作能力和項目的傳遞品質。
參考資料：
- 《輕松Scrum之旅—靈活開發故事》、《靈活無敵》
- 硝煙中的Scrum 和 XP
- 火星人靈活開發手冊
- Scrum-Checklists
- 維基百科：http://zh.wikipedia.org/wiki/Scrum
Scrum 工具
- 禅道
- JIRA+GreenHopper
Scrum 中的角色
Scrum Master——項目負責人、項目經理
保護團隊不受外界幹擾，是團隊的上司和推進者，負責提升 Scrum 團隊的工作效率，控制 Scrum 中的“檢視和适應”周期過程。與 Product Owner 一起将投資産出最大化，他確定所有的利益相關者都可以了解靈活和尊重靈活的理念。
Team——開發人員、測試人員、美工設計、DBA等全職能性團隊
團隊負責傳遞産品并對其品質負責，團隊與所有提出産品需求的人一起工作，包括客戶和最終使用者，并共同建立 Product Backlog 。團隊按照大家的共識來建立功能設計、測試 Backlog 條目傳遞産品。
Product Owner——産品負責人、産品經理、營運人員
從業務角度驅動項目，傳播産品的明确願景，并定義其主要特性。Product Owner 的主要職責是確定團隊隻開發對于組織最重要的 Backlog 條目，在 Sprint 中幫助團隊完成自己的工作，不幹擾團隊成員，并迅速提供團隊需要的所有資訊。
User——最終使用者、營運人員、系統使用人員
很多人都可能成為最終使用者，比如市場部人員、真正的最終使用者、最好的領域專家，也可能是因其專業知識而被雇傭的資訊顧問。最終使用者會根據自己的業務知識定義産品，并告知團隊自己的期望，提出請求。
Manager——管理層、投資人
管理層要為 Scrum 團隊搭建良好的環境，以確定團隊能夠出色工作，必要的時候，他們也會與 Scrum Master 一起重新組織結構和指導原則。
Customer——客戶、系統使用人員、營運人員
客戶是為 Scrum 團隊提出産品需求的人，她會與組織簽訂合同，以開發産品。一般來說，這些人是組織中的進階管理人員，負責從外部軟體開發公司購買軟體開發能力。在為内部産品的公司中，負責準許項目預算的人就是客戶。
Scrum 中的産出物
Product Backlog——Backlog 待開發項，積壓的任務。
産品 Backlog 包括了所有需要傳遞的内容，其内容根據業務需求的價值順序排列，每個 Backlog 的優先級是可以調整的，需求是可以增減的，是以産品 Backlog 将根據不斷增長來持續驅動維護。
Sprint Backlog——Sprint 本意為“沖刺”，指疊代周期，長度通常是一至六周。
在 Sprint 開始前，定義本次 Sprint 要讨論的“Sprint Backlog”，從中産生本次 Sprint 要完成的 “已定 Product Backlog”。
已定 Product Backlog
Sprint 計劃會議的産物，它定義了團隊所接受的工作量，在整個 Sprint 過程中它将保持不變。
User Story、Task——使用者故事、任務
用 User Story 來描述 Sprint Backlog 裡的項目，User Story 是從使用者的角度對系統的某個功能子產品所作的簡短描述。一個 User Story 描述了項目中的一個小功能，以及這個功能完成之後将會産生什麼效果，或者說能為客戶創造什麼價值。一個 User Story 的大小和複雜度應該以能在一個 Sprint 中完成為宜。如果 User Story 太大，可能會導緻對它的開發橫跨幾個 Sprint，此時就應該将這個 User Story 分解。
為了能夠及時，高效地完成每個 Story，Scrum 團隊會把每個 Story 分解成若幹個 Task。每個Task 的時間最好不要超過8小時，保證在1個工作日内完成，如果 Task 的時間超過了8個小時，就說明Task的劃分有問題，需要特别注意。
障礙 Backlog——問題清單，積壓的待處理事務。
列舉了所有團隊内部和團隊相關的和阻礙項目的進度的問題，Scrum Master 需要確定所有的障礙 Backlog 中的問題都已配置設定并可以得到解決。
通用會議規則
基本要求
- 每次會議都要準時開始、準時結束。
- 每次會議都采取開放形式，所有人都可以參加。
會前準備
- 提前邀請所有必須參會的人，讓他們有時間準備。
- 發送帶有會議目标和意圖的會議綱要。
- 預訂會議所需的全部資源：房間、投影儀、挂圖、主持裝置，以及此會議需要的其他東西。
- 會前24小時發送提醒。
- 準備帶有會議規則的挂圖。
會議推進
- 展開讨論時，會議的推進人必須在場。他不能參與到具體讨論中，但是他需要注意讨論程序，如果讨論參與者失去重點，他還要将讨論帶回正規。
- 推進人展示會議的目标和意圖。
- 有必要時，推進人可以商定由某個撰寫會議記錄。
- 推進人可以記錄團隊的意見，或是教授團隊如何自己記錄文檔；而且推進人可能會在挂圖上進行記錄，将對話可視化。
- 推進人會對會議進行收尾，并進行非常簡短的回顧。
會議輸出
- 使用手寫或挂圖說明來記錄文檔，給白闆和挂圖上的内容拍照。
- 必須傳達會議記錄和大家對會議結果的明确共同認知。
讓團隊坐在一起！
- 大家都懶的動，盡量讓“産品負責人”和“全功能團隊”都坐在一起！
- 互相聽到：所有人都可以彼此交談，不必大聲喊，不必離開座位。
- 互相看到：所有人都可以看到彼此，都能看到任務闆——不用非得近到可以看清楚内容，但至少可以看到個大概。
- 隔離：如果你們整個團隊突然站起來，自發形成一個激烈的設計讨論，團隊外的任何人都不會被打擾到，反之亦然。
團隊建設
- Scrum 團隊最佳人數控制在“5～9”人。
- 全職能性團隊：開發組（背景開發、前端開發、測試人員——3~8人）、Scrum Master（項目經理）、産品負責人
- 兼職團隊成員：美工、DBA、運維
每日立會（Daily Standup Meeting）——建議下班前開始
會議目的
- 團隊在會議中作計劃，協調其每日活動，還可以報告和讨論遇到的障礙。
- 任務闆能夠幫助團隊聚焦于每日活動之上，要在這個時候更新任務闆和燃盡圖。
構成部分
- 任務闆、即時貼、馬克筆
- 提示：ScrumMaster 不要站在團隊前面或是任務闆旁邊，不要營造類似于師生教學的氣氛。
基本要求
- 成員：團隊、Scrum Master
- 無法出席的團隊成員要由同伴代表。
- 持續時間/舉辦地點：每天15分鐘，同樣時間，同樣地點。
- 提示：團隊成員在聆聽他人發言時，都應該想這個問題：“我該怎麼幫他做得更快？”
會議輸出
- 團隊彼此明确知道各自的工作，最新的工作進度圖。
- 得到最新的“障礙 Backlog”
- 得到最新的“Sprint Backlog”
會議過程
- 團隊聚在故事闆旁邊，可以圍成環形。
- 從左邊第一個開始，向團隊夥伴說明他到現在完成的工作。
- 然後該成員将任務闆上的任務放到正确的列中。
- 如果可以的話，該成員可以選取新的任務，交将其放入“進行中工作”列。
- 如果該成員遇到問題或障礙，就要将其報告給 Scrum Master。
- 每個團隊成員重複步驟2到步驟5。
每個人三個問題：
- 上次會議時的任務哪些已經完成？：把任務從“正在處理”狀态轉為“已完成”狀态。——今天完成了什麼？
- 下次會議之前，你計劃完成什麼任務？：如果任務狀态為“待處理”，轉為“正在處理”狀态。如果任務不在 Sprint Backlog 上，則添加這個任務。如果任務不能在一天成，把這任務細分成多個任務。如果任務可以在一天内完成，把任務狀态設為“正在處理”。如果任務狀态已經是“正在 處理”，詢問是否存在阻礙任務完成得問題。——明天做什麼？
- 有什麼問題阻礙了你的開發？：如果有阻礙你的開發進度的問題，把該障礙加入到障礙 Backlog中。——今天遇到了什麼問題？
注意事項
- 不要遲到
- 不要超出限制時間
- 不要讨論技術問題
- 不要轉變會議話題
- 不要在沒有準備的情況下參加
- Scrum Master 不要替團隊成員移動任務卡片，不要替團隊更新燃盡圖。
- Scrum Master 不要提出問題，團隊成員不要向 Scrum Master 或管理層人員報告。
- 如果不能出席會議，需要通知團隊，并找一名代表參加。
任務闆
- 任務闆集合了選擇好的 Product Backlog 和 Sprint Backlog，并以可視化方式展示。
- 任務闆隻能由團隊維護，使用不同顔色的“即時貼”來區分開發人員，或者在“即時貼”寫上接受任務的姓名。
- 盡量使用大白闆，也可以使用軟體。
任務闆有4列：
- 選擇好的 Product Backlog：按照優先級，将團隊在目前 Sprint 中要着手的 Product Backlog 條目或是故事放在該列中。
- 待完成的任務：要完成一個故事，你得完成一些任務。在 Sprint 規劃會議中，或是在進行目前 Sprint 中，收集所有特定 Backlog 條目需要完成的新任務，并将它們放入該列。
- 進行中的工作：當團隊成員開始某個任務後，他會将該任務對應的卡片放到“進行中的工作”列中。從上個每日 Scrum 例會開始，沒有完成的任務都會放在該列中，并在上面做标記（通常是個紅點）。如果某個任務在“待完成任務”列中所處時間超過一天，就盡量将該任務分為更小 的部分，然後把新任務放到那一列，移除其所屬大任務卡片。如果一個新任務因為某個障礙無法完成，就會得到一個紅點标記，Scrum Master 就會記下一個障礙。
- 完成：當一個任務卡完成後，完成此任務的成員将其放入“完成”列，并開始選取下一張任務卡。
燃盡圖（Burn Down Chart）
- 跟蹤進度要由團隊來完成，燃盡圖的橫軸表示整個Sprint 的總時間，縱軸表示 Sprint 中所有的任務，其機關可以是小時，人天等。一般來說，燃盡圖有”Sprint燃盡圖”和”Release燃盡圖”之分。
- 團隊每天更新燃盡圖。
- 如果燃盡圖一直是上升狀态，或當 Sprint 進行一段時間之後，Sprint 燃盡圖上的Y值仍然與 Sprint 剛開始時相差無幾，就說明這個 Sprint 中的 Story 過多，要拿掉一些 Story 以保證這個 Sprint 能順利完成。 如果Sprint 燃盡圖下降得很快，例如 Sprint 剛過半時Y值已經接近0了，則說明這個 Sprint 配置設定的任務太少，還要多加一些任務進來。在 Sprint 計劃會議上，如果團隊對即将要做的任務了解和認識不充分，就很可能導緻這兩種情況的出現。（鍛煉團隊人員的自我估算時間）
- 燃盡圖要便于團隊更新，沒必要讓它看起來很炫，也不要過于複雜，難以維護。
Release 燃盡圖：記錄整個Scurm項目的進度，它的橫軸表示這個項目的所有Sprint， 縱軸表示各個Sprint開始前，尚未完成的工作，它的機關可以是個（Story 的數量），人天等。
Sprint 規劃會議——第一部分（上午）
會議目的
- 該會議的工作以分析為主，目的是要詳細了解最終使用者到底要什麼，産品開發團隊可以從該會議中詳細了解最終使用者的真實需要。在會議的結束，團隊将會決定他們能夠傳遞哪些東西。
- 産品負責人在會前準備：條目化的需求（使用者故事），優先級排序，最近1~2個疊代最希望看到的功能。會前準備至關重要，可幫助産品負責人理清頭緒，不至于在疊代期内頻繁提出變更、增加或删除故事。
基本要求
- 疊代計劃會在每個疊代第一天召開，目的是選擇和估算本次疊代的工作項。
- 隻有團隊成員才能決定團隊在目前 Sprint 中能夠領取多少個 Backlog 條目的工作。
構成部分：
- 經過估算和排序的 Product Backlog。
- 挂圖、馬克筆、剪刀、膠水、即時貼、白闆、鉛筆和蠟筆。
- 假期計劃表、重要人員的詳細聯系資訊。
- 參會成員：團隊成員、Scrum Master、産品負責人
持續時間：在 Sprint 中，每周該會議占用時間為 60 分鐘，在早上召開該會議，這樣還有可能在同一天召開 Sprint 規劃會議的第二部分。
會議輸出
- 選擇好的 Product Backlog 條目。
- 各個 Backlog 條目的需求。
- 各個 Backlog 條目的使用者驗收測試。
會議過程
- 從第一個 Product Backlog 條目（故事）開始。
- 讨論該 Product Backlog 條目，以深入了解。
- 分析、明确使用者驗收測試。
- 找到非功能性需求（性能、穩定性...）
- 找到驗收條件。
- 弄清楚需要“完成”到何種水準。
- 獲得 Backlog 條目各個方面的清晰了解。
- 繪制出所需傳遞物的相關圖表，包括流程圖、UML圖、手繪草圖、螢幕 UI 設計等。
- 回到步驟1，選取下一個 Backlog 條目。
流程檢查：詢問團隊能否快速回答下列問題，隻需要簡要回答即可：“我們能在這個 Sprint 中完成第一個 Backlog 條目嗎？”如果能得到肯定的回答，那麼繼續詢問下一個 Backlog 條目，一直到已經分析完的最後一個 Backlog 條目。——接下來，休息一下。在休息後，對下一個 Backlog 條目展開上述流程。
結束流程：
- 在 Sprint 規劃會議第一部分結束前留出 20 分鐘。
- 再次提問——這次要更加嚴肅、正式：“你們能否完成第一個 Backlog 條目，...第二個，...？”
- 如果團隊認為他們不能再接受更多的 Backlog 條目，那就停下來。
- 現在是非常重要的一步：送走 Product Owner，除了團隊和 Scrum Master 之外的所有人，都得離開。
- 當其他人都離開後，再詢問團隊：“說真的——你們相信自己可以完成這個清單？”
- 希望團隊現在能短暫讨論一下，看看他們到底認為自己能完成多少工作。
- 将結果與 Product Owner 和最終使用者溝通。
注意事項：不要改變 Backlog 條目大小，不要估算任務。
Sprint 規劃會議——第二部分（下午）
會議目的
- 該會議的工作以設計為主，産品開發團隊可以為他們要實作的解決方案完成設計工作，在會議結束後，團隊知道如何建構他們在目前 Sprint 中要開發的功能。
基本要求
- 隻有産品開發團隊才能制定解決方案，架構師或其他團隊之外的人隻是受邀幫助團隊。
構成部分：
- 能夠幫助團隊在該 Sprint 中建構解決方案的人，比如廠商或是來自其他團隊的人員。
- 選擇好的 Product Backlog 條目。
- 挂圖......
注意事項：不要估算任務，不要配置設定任務。
會議輸出
- 應用設計、架構設計圖、相關圖表
- 確定團隊知道應該如何完成任務！
會議過程
- 從第一個 Backlog 條目開始。
- 檢視挂圖，确定對于客戶的需求了解正确。
- 圍繞該 Backlog 條目進行設計，并基于下列類似問題：
- 我們需要編寫什麼樣的接口？
- 我們需要建立什麼樣的架構？
- 我們需要更新哪些表？
- 我們需要更新或是編寫哪些元件？
- ......
當團隊明确知道自己應該如何開發該功能後，就可以轉向下一個 Backlog 條目了。在會議的最後 10 分鐘，團隊成員使用即時貼寫出初步的任務。這能幫助團隊成員知道接下來的工作從哪裡開展，将這些任務放在任務闆上。
持續時間：在 Sprint 規劃會議第一部分完成後，召開該會議。可以将午餐作為兩次會議的一個更長久的休息。但是要在同一天完成 Sprint 規劃第一部分，在 Sprint 中，每周該會議占用時間為 60 分鐘。
估算會議——根據項目情況合并到 Sprint 第二部分會議
會議目的
- 要做好戰略規劃，你需要知道 Backlog 中各項的大小，這是版本規劃的必要輸入；如果想知道團隊在一個 Sprint 中能夠完成多少工作，這個資料也是必須的。
- 團隊成員可以從會議中知道項目接下來的階段會發生哪些事情。
基本要求
- 隻有團隊才能作估算，Product Owner（産品負責人）需要在場，以幫助判定某些使用者故事能否拆分為更小的故事。
構成部分：
- Product Owner 根據業務價值排定 Product Backlog 各項順序。
- 需要參加的人員：Team、Product Owner、User、Scrum Master
注意事項：
- 不要估算工作量大小——隻有團隊能這麼做。
- Product Owner 不參與估算。
會議過程
- Prodcut Owner 展示她希望得到估算的 Product Backlog 條目。
- 團隊使用規劃撲克來估算 Backlog 條目。
- 如果某個 Backlog 條目過大，需要放到下一個或是後續的 Sprint 中，團隊就會将該大 Backlog 條目劃分為較小的幾個 Backlog 條目，并對新的 Backlog 條目使用規劃撲克進行估算。
- 重新估算 Backlog 中目前沒有完成、但是可能會在接下來三個 Sprint 中要完成的條目。
持續時間：該會議時間限制為不超過90分鐘。如果 Sprint 持續時間長于一周，那麼每個 Sprint 舉行兩次估算會議比較合适。
會議輸出
- 經過估算的 Product Backlog。
- 更小的 Backlog 條目。
撲克牌估算（Planning Poker）
具體步驟：
- 每個人各自估算後獨立出暗牌，聽密碼一起開牌。
- 數值最大者與最小者PK，其他人旁聽也可參考。
- 讨論結束後重新出牌和開牌。
- 重複上述過程，直到結果比較接近。
常見問題
1、為什麼任務要分給組而不是個人？
答：因為怕出錯了牌又說不出是以然，這樣即使日後他不做這個功能，也對這個功能很了解。
2、為什麼不讓最後領任務的人自己估算？
答：因為他很可能因為不知道某代碼可用、不知道某軟體不行....而選擇了錯誤的實作方法。
3、為什麼不讓師傅估算大家采納，他不是最厲害嗎？
答：師傅的想法常常是徒弟們了解不了的，比如為什麼不留在女兒國而偏偏去西天取經之類的，共同估算就是讓大家在思考中對照自己的實作方法和師傅差異的過程。
Sprint 評審會議（Review Meeting）——根據項目需要舉行
會議目的
- Scrum 團隊在會議中向最終使用者展示工作成果，團隊成員希望得到回報，并以之建立或變更 Backlog 條目。
基本要求
- Sprint 複審會議允許所有的參與者嘗試由團隊展示的新功能。
構成部分
- 有可能釋出的産品增量，由團隊展示。
會議輸出
- 來自最終使用者的回報。
- 障礙 Backlog 的輸入。
- 團隊 Backlog 的輸入。
- 來自團隊的回報為 Product Backlog 産生輸入。
持續時間：90分鐘，在 Sprint 結束時進行。
會議過程
- Product Owner 歡迎大家來參加 Sprint 複審會議。
- Product Owner 提醒大家關于本次 Sprint 的目的：Sprint 目标、Scrum 團隊在本次 Sprint 中標明要開發的故事。
- 産品開發團隊展示新功能，并讓最終使用者嘗試新功能。
- Scrum Master 推進會議程序。
- 最終使用者的回報将會由 Product Owner 和/或 Scrum Master 記錄在案。
注意事項：
- 不要展示不可能釋出的産品增量。
- Scrum Master 不要負責展示結果。
- 團隊不要針對 Product Owner 展示。
- Sprint 反思會議（Retrospective Meetin）——根據項目需要舉行
會議目的
- 該會議的對應隐喻：醫療診斷！其目的不是為了找到治愈方案，而是要發現哪些方面需要改進。
構成部分
- 參與人員：團隊成員、Scrum Master
基本要求
- 從過去中學習，指導将來。
- 改進團隊的生産力。
注意事項
- 不要讓管理層人員參與會議。
- 不要在團隊之外讨論找到的東西。
會議輸出
- 障礙 Backlog 的輸入。
- 團隊 Backlog 的輸入。
持續時間：90分鐘，在 Sprint 評審會議結束後幾分鐘開始。
會議過程
- 準備一個寫着“過去哪些做的不錯？”的挂圖。
- 準備一個寫着“哪些應該改進？”的挂圖。
- 繪制一條帶有開始和結束日期的時間線。
- 給每個團隊成員發放一疊即時貼。
- 開始回顧。
- 做一個安全練習。
- 收集事實：發放即時貼，用之構成一條時間線。每個團隊成員（包括 Scrum Master）在每張即時貼上寫上一個重要的事件。
- “過去哪些做的不錯？”：采取收集事實同樣的過程，不過這次要把即時貼放在準備好的挂圖上。
- 做一個分隔，以區分“過去哪些做的不錯”和接下來要産出的東西。
- “哪些應該改進？”：像“過去哪些做的不錯”那樣進行。
- 現在将即時貼分組：
- 我們能做什麼》團隊 Backlog 的輸入。
- 哪些不在我們掌控之内？》障礙 Backlog 的輸入。
- 根據團隊成員的意見對兩個清單排序。
- 将這兩個清單作為下個 Sprint 的 Sprint 規劃會議第一部分和 Sprint 規劃會議第二部分的輸入，并決定到時候要如何處理這些發現的資訊。
附兩張流程圖（資料截圖）