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結束時接受或拒絕接受Team Dev的工作成果。

產品負責人是一個人，而不是一個委員會。可能會有一些委員會向產品負責人提出建議或影響他的決策，但要想改變某條目的優先順序必須先說服產品負責人。

實施Scrum的企業可能發現這樣會影響他們制定優先順序和需求的方法。

為保證產品負責人的工作取得成功，企業中的所有人員都必須尊重他的決定。任何人都不得要求團隊按照另一套優先順序開展工作，團隊也不允許聽從任何人帶有威脅恐嚇性的指令。產品負責人所作的決定需要通過產品Backlog內容和優先順序使其可視化。這種可視化要求產品負責人全力以赴，同時也使其成為一個費心費力但又值得去做的角色。

2.2 Scrum Master

• 保證團隊資源完全可被利用並且全部是高產出的。
• 保證各個角色及職責的良好協作。
• 解決團隊開發中的障礙。
• 做為團隊和外部的介面，屏蔽外界對團隊成員的幹擾。
• 保證開發過程按計划進行，組織每日站會、Sprint計劃會議、Sprint評審會議和Sprint回顧會議。

Scrum Master 需要知道什麼任務已經完成，哪些任務已經開始，哪些新的任務已發現，和哪些估算可能已經發生變化。

Scrum Master 需要根據以上的情況更新反映每天完成的工作量以及還有多少沒有完成的燃盡圖 (burndown chart)（Burndown Chart）。

Scrum Master 還必須仔細考慮同時在進行開發的任務數，同時進行的工作需要做到最小化，以實現精益生產率的收益。

Scrum Master需要找出阻礙團隊的障礙和依賴。他們需要的優先次序和跟蹤。根據優先順序指定計劃解決這些障礙。其中有些問題可以在團隊內部解決，有些則要團隊之間的協調，還有的要管理層的介入來解決，甚至有些是公司的問題阻礙了團隊達到他們的生產力。比如：一個電信公司最近實施了Scrum，但後來發現只有兩個問題和Scrum Team有關，其他的全是公司的問題需要管理層關注。

最後但並非最不重要， Scrum Master 可能會注意到，個人問題或衝突在Scrum裡是需要解決的。這些都需要被澄清，或通過內部的溝通解決，或向管理層和HR尋求協助解決。Scrum Master 必須注意去確保團隊資源完全可被利用並且全部是高產出的。

2.3 Team

1. Scrum團隊的規模控制在5-9個人

   • 如果成員少於5人，那麼相互交流就減少了，團隊的生產力也會下降。更重要的是，團隊在Sprint中可能會受到技能限制，從而導致無法交付可發布的產品模組。
   • 如果成員多於9人，那麼成員之間就需要太多的協調溝通工作。
   • 大型團隊會產生太多複雜性，不便於經驗過程式控制制。
   • 對於大型項目來說，可以採用多個小的Scrum團隊，通過Scrum of Scrums解決團隊間的溝通協調問題。

2. Scrum團隊是跨職能的團隊

   • 團隊成員必須具備交付產品增量所需要的各種技能。
   • 團隊成員常常具備如編程、品質控制、業務分析、架構、使用者介面設計或資料庫設計等的專業技能。
   • 在Scrum團隊中沒有頭銜的概念，每個人都必須盡心儘力完成Sprint目標。
   • 團隊中不允許包括測試或業務分析等在特定領域工作的子團隊。

3. Scrum團隊是自組織的

   • 任何人，包括Scrum Master都沒有權利規定團隊如何將產品Backlog轉化成可交付的功能增量，而是由團隊自己確定。
   • 每個團隊成員利用自己的專業技能，解決遇到的問題。這種協同配合提高了團隊整體效率。
   • 團隊的構成在Sprint結束時可能會發生變化，每次團隊成員的變化，都會降低通過自組織而擷取的生產力。因此，改變團隊構成時務必要謹慎。

2.4 使用者和利益相關者（客戶，供應商）3. 工件3.1 Product Backlog

• 產品待辦事項清單存在（並演化）於產品的整個生命週期，它是產品的路線圖。
• 任何時候，產品待辦事項清單都是“團隊依照優先排列順序完成工作”的唯一、最終的概括。
• 一個產品只有一個產品待辦事項清單，這就意味著產品負責人必須縱觀全域做出優先順序排列的決策，以體現利益相關人（包括團隊）的意願。

產品待辦事項清單包括不同種類的事項：

• 全新的客戶特性（“使所有使用者可以將書籍放入購物車”），
• 也有主要的技術改進目標（如“用Java代替C++重寫系統”），
• 還有改進目標（如“加速測試”）、調研工作（“探討加速信用卡有效驗證的解決方案”），
• 還可能會有已知的缺陷（“分析並修複訂單處理指令碼錯誤”），
• 如果問題不多的話（如果系統有很多缺陷，通常就會有單獨的缺陷跟蹤系統）。

一個好的產品待辦事項清單要做到：

• 粗細適宜的（Detailed appropriately）

優先順序列表頂端的事項比低層級的事項更為精確和詳細，因為前者要比後者先被開發。比如，待辦事項清單頂端的百分之十可能包含非常小且分析得很詳細的事項，而其他的百分之九十則不是那麼具體。

• 估算過的（Estimated）

當前發布版本的事項需要有估算，而且隨著大家瞭解得更多和新資訊的融入應當在每個Sprint中重新考慮這些估算。 團隊提供給產品負責人產品待辦事項清單中每個事項的工作量估算和技術風險估算。 產品負責人和其他商業利益相關人提供產品需求的價值資訊，其中可能會包括獲得的收益、減少的成本、商業風險、對不同利益相關人的重要性等等。

• 湧現式的（Emergent）

為了響應學習和變化，要定期梳理產品待辦事項清單。 每個Sprint，可能要加入、刪除、修改、分解或者調整事項的優先順序別。因此，產品負責人會不斷地更新產品待辦事項清單，以反映客戶需求的變化、新想法或見解、競爭而導致的變化、出現的技術障礙等等。

• 排好優先順序的（Prioritized）

在產品待辦事項清單頂端的事項具有最高優先順序，或者是從1開始順序排列。 一般來說，最高優先順序別的事項應當最物超所值：高收益（商業價值）低花銷（成本）。 提高某事項優先順序的另一誘因是在高風險來襲之前及早解決掉它。

3.2 Sprint Backlog

團隊為每個Product Backlog事項建立一個工作列表，有時由產品待辦事項清單中的事項分解出的工作群組成。或者當產品待辦事項清單中的事項很小，只要幾個小時就能實現時，就簡單的由產品待辦事項清單事項組成。

4. Scrum開發流程事件4.1 Sprint計劃會議

通常分成兩部分：

1. 關於做什麼

   • 參與者：產品負責人、團隊、ScrumMaster
   • 長度：時間箱的小時數與Sprint的周數相等
   • 產品負責人和團隊審視產品待辦事項清單中產品負責人有興趣在這個Sprint中實現的那些高優先順序的事項。通常，這些事項應當已經在前一個Sprint中（的產品待辦事項清單梳理會議裡）被很好地分析過了，因此在這個會上只有較少的需要在最後時刻澄清的問題。在這個會議中，產品負責人和團隊討論產品待辦事項清單中這些高優先順序事項的目標和上下關聯，讓團隊洞悉產品負責人的思想，關注於理解產品負責人想要什麼以及為什麼需要它。

2. 關於怎麼做

   • 參與者：團隊、ScrumMaster、產品負責人（不強制參加，但是要能被找到來回答問題）
   • 長度：時間箱的小時數與Sprint的周數相等
   • 關注於如何?團隊決定要開始做的那些事項。團隊預期他們在Sprint結尾能夠完成多少事項，從產品待辦事項清單的頂部開始（換句話說，就是從對於產品負責人來講最高優先順序的事項開始），並依次查看事項。以下是Scrum中的關鍵實踐：由團隊決定將完成多少工作，而不是由產品負責人分配給他們。因為團隊是基於他們自己的分析和計劃，這使得預期更可靠。雖然產品負責人對於團隊接受多少工作沒有控制權，但他明白產品待辦事項清單中的事項是從頂部開始拿取的，換句話說，就是先拿那些被他評為重要的事項。團隊可以為列表中很後面的事項進行遊說，這通常發生在團隊和產品負責人發現低優先順序的某些東西很容易並可以恰當地與高優先順序的事項合并時。

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分鐘。

這是一個自組織團隊互相分享目前工作情況的時刻，每個團隊成員一個接一個地向團隊的其他成員報告三件事：

1. 自上次會議以來完成了哪些工作？
2. 在下次會議前有哪些工作會被做完？
3. 遇到了什麼阻礙？

5.4 Sprint過程中跟蹤進度

Scrum中的團隊是自管理的，想要做到這一點，團隊必須要知道自己做得怎麼樣。每天，團隊成員都會在Sprint Backlog上更新他們對還需要多少工作量來完成他們當前工作的估計。一個也很常見的做法是有人把這些剩餘工作量加起來，然後在Sprint燃盡圖 (burndown chart)上畫點。這個圖顯示每天新的對團隊完成工作所剩餘工作量的估計。理想中，這應該是一條向下的斜線圖，其軌跡指向Sprint最後一天沒有剩餘工作量的那一點。所以它被稱為燃盡圖 (burndown chart)。

6. 參考

1. Scrum Guide

Scrum學習筆記