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結束時接受或拒絕接受開發團隊的工做成果。

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

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

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

2.2 Scrum Master

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

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

Scrum Master 須要根據以上的狀況更新反映天天完成的工做量以及還有多少沒有完成的燃盡圖（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

• 產品待辦事項列表存在（並演化）於產品的整個生命週期，它是產品的路線圖。
• 任什麼時候候，產品待辦事項列表都是「團隊依照優先排列順序完成工做」的惟1、最終的歸納。
• 一個產品只有一個產品待辦事項列表，這就意味着產品負責人必須縱觀全局作出優先級排列的決策，以體現利益相關人（包括團隊）的意願。

 

產品待辦事項列表包括不一樣種類的事項：

• 全新的客戶特性（「使全部用戶能夠將書籍放入購物車」），
• 也有主要的技術改進目標（如「用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燃盡圖上畫點。這個圖顯示天天新的對團隊完成工做所剩餘工做量的估計。理想中，這應該是一條向下的斜線圖，其軌跡指向Sprint最後一天沒有剩餘工做量的那一點。因此它被稱爲燃盡圖。

 

6. 參考

1. Scrum Guide