Scrum學習筆記
1. 概述
Scrum是跨職能團隊以迭代、增量的方式開發產品或項目的一種開發框架。
它把開發組織成被稱為Sprint的工作周期。這些迭代每個都不超過4周（最常見的是兩周），并且無間歇地相繼進行。Sprint是受時間箱限制的，無論工作完成與否它們都會在特定日期結束，并且從不延長。通常由Scrum團隊來選定一個Sprint的時長，并且對于他們所有的Sprint都使用這一時長，直到這個團隊能力提高，可以使用較短周期。
在每個Sprint的初始，跨職能團隊（大約7名成員）從排好優先級的列表中選擇事項（客戶需求）。團隊對于在Sprint結尾他們相信自己可以交付哪些目標集合達成一致意見，這些交付應該是有形的并且能被真正“完成”的。
在Sprint過程中不可以增加新事項，Scrum在下一Sprint時才接受變化，當前這么短的一個Sprint周期里只注重于短小、清晰、相對固定的目標。團隊每天都進行簡短會面來檢驗工作進程，并調整后續步驟以確保完成剩余工作。
在Sprint結尾，團隊與利益關系人一起回顧這個Sprint，并演示所構建的產品。團隊成員從中獲取可以結合到下一Sprint中的反饋。Scrum 強調在Sprint結尾產生真正“完成”了的可工作產品。在軟件領域是指已經集成的、完全測試過的、已經為最終用戶生成文檔的、潛在可交付的系統。
2. 主要角色
2.1 Product Owner
- 確定產品的功能，負責維護產品Backlog。
- 決定產品的發布日期和發布內容。
- 為產品的投資回報率(ROI)負責。
- 根據市場價值確定功能優先級。
- 在每個Sprint開始前調整功能和調整功能優先級。
- 在Sprint結束時接受或拒絕接受開發團隊的工作成果。 </ul>
- 保證團隊資源完全可被利用并且全部是高產出的。
- 保證各個角色及職責的良好協作。
- 解決團隊開發中的障礙。
- 做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。
- 保證開發過程按計劃進行，組織每日站會、Sprint計劃會議、Sprint評審會議和Sprint回顧會議。 </ul>
-
Scrum團隊的規模控制在5-9個人
- 如果成員少于5人，那么相互交流就減少了，團隊的生產力也會下降。更重要的是，團隊在Sprint中可能會受到技能限制，從而導致無法交付可發布的產品模塊。
- 如果成員多于9人，那么成員之間就需要太多的協調溝通工作。
- 大型團隊會產生太多復雜性，不便于經驗過程控制。
- 對于大型項目來說，可以采用多個小的Scrum團隊，通過Scrum of Scrums解決團隊間的溝通協調問題。 </ul> </li>
-
Scrum團隊是跨職能的團隊
- 團隊成員必須具備交付產品增量所需要的各種技能。
- 團隊成員常常具備如編程、質量控制、業務分析、架構、用戶界面設計或數據庫設計等的專業技能。
- 在Scrum團隊中沒有頭銜的概念，每個人都必須盡心盡力完成Sprint目標。
- 團隊中不允許包括測試或業務分析等在特定領域工作的子團隊。 </ul> </li>
-
Scrum團隊是自組織的
- 任何人，包括Scrum Master都沒有權利規定團隊如何將產品Backlog轉化成可交付的功能增量，而是由團隊自己確定。
- 每個團隊成員利用自己的專業技能，解決遇到的問題。這種協同配合提高了團隊整體效率。
- 團隊的構成在Sprint結束時可能會發生變化，每次團隊成員的變化，都會降低通過自組織而獲取的生產力。因此，改變團隊構成時務必要謹慎。 </ul> </li> </ol>
- 產品待辦事項列表存在（并演化）于產品的整個生命周期，它是產品的路線圖。
- 任何時候，產品待辦事項列表都是“團隊依照優先排列順序完成工作”的唯一、最終的概括。
- 一個產品只有一個產品待辦事項列表，這就意味著產品負責人必須縱觀全局做出優先級排列的決策，以體現利益相關人（包括團隊）的意愿。 </ul>
- 全新的客戶特性（“使所有用戶可以將書籍放入購物車”），
- 也有主要的技術改進目標（如“用Java代替C++重寫系統”），
- 還有改進目標（如“加速測試”）、調研工作（“探討加速信用卡有效驗證的解決方法”），
- 還可能會有已知的缺陷（“分析并修復訂單處理腳本錯誤”），
- 如果問題不多的話（如果系統有很多缺陷，通常就會有單獨的缺陷跟蹤系統）。 </ul>
- 粗細適宜的（Detailed appropriately） </ul>
- 估算過的（Estimated） </ul>
- 涌現式的（Emergent） </ul>
- 排好優先級的（Prioritized） </ul>
-
關于做什么
- 參與者：產品負責人、團隊、ScrumMaster
- 長度：時間箱的小時數與Sprint的周數相等
- 產品負責人和團隊審視產品待辦事項列表中產品負責人有興趣在這個Sprint中實現的那些高優先級的事項。通常，這些事項應當已經在前一個Sprint中（的產品待辦事項列表梳理會議里）被很好地分析過了，因此在這個會上只有較少的需要在最后時刻澄清的問題。在這個會議中，產品負責人和團隊討論產品待辦事項列表中這些高優先級事項的目標和上下關聯，讓團隊洞悉產品負責人的思想，關注于理解產品負責人想要什么以及為什么需要它。 </ul> </li>
-
關于怎么做
- 參與者：團隊、ScrumMaster、產品負責人（不強制參加，但是要能被找到來回答問題）
- 長度：時間箱的小時數與Sprint的周數相等
- 關注于如何實現團隊決定要開始做的那些事項。團隊預期他們在Sprint結尾能夠完成多少事項，從產品待辦事項列表的頂部開始（換句話說，就是從對于產品負責人來講最高優先級的事項開始）， 并依次查看事項。以下是Scrum中的關鍵實踐：由團隊決定將完成多少工作，而不是由產品負責人分配給他們。因為團隊是基于他們自己的分析和計劃，這使得 預期更可靠。雖然產品負責人對于團隊接受多少工作沒有控制權，但他明白產品待辦事項列表中的事項是從頂部開始拿取的，換句話說，就是先拿那些被他評為重要 的事項。團隊可以為列表中很后面的事項進行游說，這通常發生在團隊和產品負責人發現低優先級的某些東西很容易并可以恰當地與高優先級的事項合并時。 </ul> </li> </ol>
4.2 產品待辦事項列表梳理
概述 ： 為了將來的Sprint拆分大事項、分析事項、重新估計并重排優先級。
參與者 ： 團隊；如果產品負責人是能夠幫助梳理細節的專家，那么他會全程參與整個活動，否則他可以只參與其中一部分來設定方向或者重排優先級；其他理解需求并能給予 團隊幫助的人；Scrum Master將在會議的開始部分來指導團隊如何有效地開這個會，否則的話他不必參加。
時長 ： 通常來講不多于團隊一個Sprint工作容量的10％，但有時對于“有大量分析工作”的事項來講要更長一些。例如，對于兩周的Sprint，可能要有一天的時間花在梳理上。
4.3 Sprint評審會議
概述 ： 演示產品增量，并且在會議上對于功能性的產品增量進行審視并調整。它讓產品負責人了解產品和團隊的當前狀況（也就是對于這個Sprint的評審），也讓團隊了解產品負責人和市場的當前狀況。
參與者 ： 團隊、產品負責人、ScrumMaster。產品負責人可以邀請其他恰當的利益相關人參加。
時長 ： 時間箱為Sprint中的每一周對應一個小時。
4.4 Sprint回顧會議
概述 ： 針對流程和環境進行審視并調整。
參與者 ： 團隊、ScrumMaster、產品負責人（非必須）。團隊可能會邀請其他利益相關人，否則這些人不準參加。
時長 ： 時間箱為對應Sprint中的每一周為45分鐘。
4.5 開始下一個Sprint
Sprint評審之后，產品負責人可以根據任何新的見解來更新產品待辦事項列表，如添加新事項、刪除過時事項或修改現有事項。產品負責人負責保證這些變化反映在產品待辦事項列表中。
5. 其他
5.1 工作量估算
//todo
5.2 “完成”的定義
是所有代碼被check-in就算故事做完了，或者是放到測試環境并且被整合測試團隊驗證過，才算是做完？
這一點是非常重要的，產品負責人和團隊必須同意，要對“做完”有一致的定義。
5.3 每日會議
概述 ： 在團隊成員間更新信息和進行協調。
參與者 ： 團隊必須參加；產品負責人不是必須的；ScrumMaster通常會在場，但要保證團隊自己主持會議。
時長 ： 最長15分鐘。
這是一個自組織團隊互相分享目前工作情況的時刻，每個團隊成員一個接一個地向團隊的其他成員報告三件事：
- 自上次會議以來完成了哪些工作？
- 在下次會議前有哪些工作會被做完？
- 遇到了什么阻礙？ </ol>
5.4 Sprint過程中跟蹤進度
Scrum中的團隊是自管理的，想要做到這一點，團隊必須要知道自己做得怎么樣。每天，團隊成員都會在Sprint Backlog上更新他們對還需要多少工作量來完成他們當前工作的估計。一個也很常見的做法是有人把這些剩余工作量加起來，然后在Sprint燃盡圖上畫點。這個圖顯示每天新的對團隊完成工作所剩余工作量的估計。理想中，這應該是一條向下的斜線圖，其軌跡指向Sprint最后一天沒有剩余工作量的那一點。所以它被稱為燃盡圖。
6. 參考
2.4 用戶和利益相關者（客戶，提供商）
3. 工件
3.1 Product Backlog
產品待辦事項列表包括不同種類的事項：
一個好的產品待辦事項列表要做到：
優先級列表頂端的事項比低級別的事項更為精確和詳細，因為前者要比后者先被開發。比如，待辦事項列表頂端的百分之十可能包含非常小且分析得很詳細的事項，而其他的百分之九十則不是那么具體。
</blockquote>當前發布版本的事項需要有估算，而且隨著大家了解得更多和新信息的融入應當在每個Sprint中重新考慮這些估算。 團隊提供給產品負責人產品待辦事項列表中每個事項的工作量估算和技術風險估算。 產品負責人和其他商業利益相關人提供產品需求的價值信息，其中可能會包括獲得的收益、減少的成本、商業風險、對不同利益相關人的重要性等等。
</blockquote>為了響應學習和變化，要定期梳理產品待辦事項列表。 每個Sprint，可能要加入、刪除、修改、分解或者調整事項的優先級別。因此，產品負責人會不斷地更新產品待辦事項列表，以反映客戶需求的變化、新想法或見解、競爭而導致的變化、出現的技術障礙等等。
</blockquote>在產品待辦事項列表頂端的事項具有最高優先級，或者是從1開始順序排列。 一般來說，最高優先級別的事項應當最物超所值：高收益（商業價值）低花銷（成本）。 提高某事項優先級的另一誘因是在高風險來襲之前及早解決掉它。
</blockquote>3.2 Sprint Backlog
團隊為每個Product Backlog事項建立一個工作列表，有時由產品待辦事項列表中的事項分解出的任務組成。或者當產品待辦事項列表中的事項很小，只要幾個小時就能實現時，就簡單的由產品待辦事項列表事項組成。
4. Scrum開發流程事件
4.1 Sprint計劃會議
通常分成兩部分：
產品負責人是一個人，而不是一個委員會。可能會有一些委員會向產品負責人提出建議或影響他的決策，但要想改變某條目的優先級必須先說服產品負責人。
實施Scrum的企業可能發現這樣會影響他們制定優先級和需求的方法。
為保證產品負責人的工作取得成功，企業中的所有人員都必須尊重他的決定。任何人都不得要求團隊按照另一套優先級開展工作，團隊也不允許聽從任何人帶有威脅 恐嚇性的指令。產品負責人所作的決定需要通過產品Backlog內容和優先級使其可視化。這種可視化要求產品負責人全力以赴，同時也使其成為一個費心費力 但又值得去做的角色。
2.2 Scrum Master
Scrum Master 需要知道什么任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估算可能已經發生變化。
Scrum Master 需要根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的燃盡圖（Burndown Chart）。
Scrum Master 還必須仔細考慮同時在進行開發的任務數，同時進行的工作需要做到最小化，以實現精益生產率的收益。
Scrum Master需要找出阻礙團隊的障礙和依賴。他們需要的優先次序和跟蹤。根據優先級指定計劃解決這些障礙。其中有些問題可以在團隊內部解決，有些則要團隊 之間的協調，還有的要管理層的介入來解決，甚至有些是公司的問題阻礙了團隊達到他們的生產力。比如：一個電信公司最近實施了Scrum，但后來發現只有兩 個問題和Scrum Team有關，其他的全是公司的問題需要管理層關注。
最后但并非最不重要， Scrum Master 可能會注意到，個人問題或沖突在Scrum里是需要解決的。這些都需要被澄清，或通過內部的溝通解決，或向管理層和HR尋求幫助解決。Scrum Master 必須注意去確保團隊資源完全可被利用并且全部是高產出的。