Scrum是最著名的敏捷框架。它是敏捷宣言的價值觀和原則背後的重要思想源泉，⽽這些價值觀和原則也是所有敏捷⽅法的基礎

Scrum是一個用於打造產品的框架，一個團隊流程。當利益干係人需要一個產品時， Scrum就啟動了

Scrum要求在團隊和利益干係⼈之間保持資訊透明。因此， Scrum團隊會把當前的計劃和進度視覺化

零、敏捷宣言

0.1 四種核心價值觀

• 個體與互動 高於 流程和工具
  賴於不同團隊和團隊中的個體之間的信任以及他們之間的合作方式

  • 團隊確定該做什麼，
  • 團隊確定如何去實現
  • 然後由團隊來完成
  • 團隊發現前進道路上的障礙，並負責解決職責範圍內的所有困難。
  • 團隊也會與組織內的其他部門合作去解決團隊職責範圍外的困難

• 工作的軟體 高於 詳盡的文件
  團隊每個Sprint都必須交付可工作的產品增量
  儘管還會有類似於分析、設計、測試的工作，可能需要文件記錄下來，但是隻有可工作的軟體能幫助組織達到專案成功

• 客戶合作 高於 合同談判

• 響應變化 高於 遵循計劃

0.2 十二條原則

• 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
• 欣然面對需求變化，即使在開發後期也一樣。善於掌控變化， 幫助客戶獲得競爭優勢。
• 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
• 業務人員和開發人員必須相互合作，專案中的每一天都不例外。
• 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
• 激發個體的鬥志，以他們為核心搭建專案。提供他們所需的環境和支援，相信他們能夠達成目標。
• 可工作的軟體是進度的首要度量標準。
• 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
• 對技術精益求精，對設計不斷完善，將提高敏捷能力。
• 以簡潔為本，極力減少不必要工作量。
• 最好的架構、需求和設計出自於自組織的團隊。
• 團隊定期地反思如何能提高成效，並依此調整團隊的行為。

0.3 注意

• 即便是敏捷開發，也是需要專案章程
• 即便是敏捷開發，也是需要計劃的，但是敏捷開發主張計劃接近實際工作
• 敏捷開發中的進度計劃可以通過估算故事點、優先順序和開發速度來制定
• 敏捷開發的理想團隊應該合理配置空間，使得成員之間面對面，沒有或很少障礙物
• 使用者故事不要超過2-3周的人工量
• Scrum的理想團隊成員個數在5-9人
• 每日例會不要超過15分鐘

一、 Scrum角色

Scrum團隊包括三個角色

1.1 產品負責人

並不是所有的事情都由產品負責人1個人負責。整個Scrum團隊需要讓團隊變得儘可能的高效，改善他們的實踐、提出正確的問題、幫助產品負責人等等。

• 產品負責人：決定要做什麼
  
  • 由1個人來擔任，他負責在限定期限內擬定可能的最有價值的產品
  • 產品負責人可能需要其他人的支援，但他只能是1個人
  • 產品負責人維護產品待辦事項列表（ Product Backlog），並確保大家都知道包括的內容以及優先順序
  • 產品負責人通常是離專案的“業務層”最近的人，一般由組織指派來負責“把這個產品做出來”，而且通常期望他以最好的工作成果來滿足所有的利益干係人
  • 產品負責人通過選擇開發團隊下一步應該做什麼以及要推遲什麼，來權衡範圍和進度，以得到儘可能好的產品

1.2 開發團隊成員

開發團隊決定1個Sprint要做多少事情，並負責每個Sprint產出可用的產品增量。

• 開發團隊成員：通過一系列稱為Sprint的短時間週期以增量式打造產品
  
  • 開發團隊是由實現產品增量的專業成員組成，他們採用自組織的方式完成工作。對於專案而言，開發團隊的成員是全職的
  • 開發團隊成員需要以自組織的方式實現Sprint目標，根據Sprint的計劃完成產品增量
  • 開發團隊成員共同預測在1個Sprint能完成的工作量，並決定如何實現 (產品負責人準備1個有序的代辦事項列表)

Sprint是一個固定的時間週期，長度可以是1周到四周，但越短越好。在每個Sprint中，Scrum團隊會開發並交付1個產品增量
每個增量是1個可識別的，對產品功能有明顯提升的，可操作的功能子集，符合明確的接受條件，並且質量標準達到了“完成的定義”

1.3 ScrumMaster

• ScrumMaster：一個僕人型領導，幫助團隊和組織來讓Scrum發揮最大效用
  
  • 作為Scrum團隊的教練，幫助Scrum團隊遵守他們的流程
  • 幫助產品負責⼈理解如何建立和維護產品待辦事項列表（ Product Backlog）
  • 和開發團隊一起發現並實施技術實踐，確保團隊在Sprint結束時能夠完成工作
  • 注意團隊前進的障礙已被清除
  • ScrumMaster培養團隊的自組織能力。團隊應該儘可能地獨立解決問題
  • 確保團隊內部和外部人員對Scrum有充分的理解，並保證Scrum被恰當地使用。
  • 幫助團隊之外的人理解流程，並明確和團隊的哪些互動是有益的，哪些不是。
  • ScrumMaster幫助每個人改進，使團隊更加高效和有價值

二、Scrum基本工件

在敏捷專案中計劃有幾個層次：產品願景、產品路線、釋出計劃類似於大版本要實現什麼[產品待辦事項列表]，衝刺計劃(迭代)完成釋出計劃中的某些功能[Sprint待辦事項列表]，每日計劃包含當日應該完成的任務

2.1 產品待辦事項列表（ Product Backlog）

• 產品待辦事項列表（ Product Backlog）：1個有關產品想法的有序列表，這些想法將按照其期望被實現的順序排列
  
  • 它是所有需求的唯1來源。這意味著開發團隊的所有工作都來自產品待辦事項列表
  • 每個產品待辦事項都包括描述和估算
  • 開始階段它比較短小而模糊，隨著時間的推移，逐漸變長，越來越明確
  • 通過《產品待辦事項列表梳理活動》，即將被實現的產品待辦事項會得到澄清，變得明確，粒度也拆得更細
  • 由產品負責人維護
  • 可能來自於產品負責人，團隊成員，或者其它利益干係人

2.1.1 使用者故事

一個編寫良好的使用者故事是敏捷開發的基礎。它們應該相互獨立，詳情應該便於開發者和使用者進行溝通，應該對使用者有價值，應該對於開發者來說盡可能的清晰以便進行估計，應該短小，通過預定義測試用例的使用確保它是可以測試的。

2.1.1.1 Invest特性

• I dependent(獨立的):

  • 一個使用者故事對於另一個使用者故事應該是獨立的（儘可能的）。故事之間的依賴性使得增加了計劃編制，確立有限級，故事估計這些工作非常困難。通常，可以通過組合使用者故事或者分割使用者故事來減少依賴性。

• N egotiable(便於溝通的):

  • 一個使用者故事是便於溝通的。一個故事的卡片是包含故事詳情的簡短描述。這些詳情是通過討論階段來完成的。一張還有很多詳情的卡片實際上減少了和客戶的會談。

• V aluable(有價值的):

  • 每個故事必須對客戶具有價值（無論是使用者還是購買方）。一個讓使用者故事有價值的好方法是讓客戶來寫下它們。一旦一個客戶意識到一個使用者故事並不是一個契約而且可以進行協商的時候，他們將非常樂意寫下故事。

• E stimable(可估計的):

  • 開發者需要去估計一個使用者故事以便確定有限級並對故事進行規劃。但是讓開發者難以估計故事的問題來自：對於領域知識的缺乏（這種情況下需要更多的溝通），或者故事太大了（這時需要把故事切分成小些的）。

• S mall(短小):

  • 一個好的故事應該在工作量上短小，描述具有代表性，而且不超過2-3人周的工作量。超過這個範圍的使用者故事，將會在劃分範圍和估計時出現很多錯誤。

• T estable(可測試的) :

  • 一個使用者故事是可測試的來用於確認完成，記住，我們不開發不能測試的故事。如果你不能測試那麼你永遠不知道你什麼時候是完成了。一個不可測試的使用者故事例子：軟體應該是易於使用的。

2.1.1.2 優秀使用者故事準則

• 考慮每一個使用者角色，從目標故事（高層次故事）開始衍生
• 切蛋糕原則：每個故事具有某種程度的完整性
• 編寫封閉的故事，有明確的範圍邊界
• 卡片約束
• 根據時間來確定故事規模和精確度
• 不要過早涉及使用者介面
• 有些需求並不是故事，可以使用其他的形式表達某些需求
• 故事裡包括使用者角色
• 一個使用者故事只為一個角色編寫
• 以主動語態編寫
• 由客戶編寫
• 不需要編號，增加無謂的流程
• 有序號，表示優先順序
• 故事卡用來提醒客戶和開發的對話討論，要簡潔，儘量只有切人點提醒，不加入太多的細節

2.2 Sprint待辦

事項列表（ Sprint Backlog）

• Sprint待辦事項列表（ Sprint Backlog）：下個Sprint的詳細開發計劃
  
  • 一個需要在當前Sprint完成的且梳理過的產品待辦事項，幷包括了一個團隊完成這些工作的計劃
  • 反映了團隊對當前Sprint⾥需要完成工作的預測
  • Scrum團隊共同指定和維護
  • 有了Sprint待辦事項列表後， Sprint就開始了，開發團隊成員按照Sprint待辦事項列表來開發新的產品增量

2.3 產品增量

• 產品增量：每個Sprint的必要產出。它是個整合好的產品版本，具備足夠好的質量並在產品負責人需要時被交付出去
  
  • 每個Sprint都應該有新的產品增量。
  • 它的質量好到可以隨時交付給客戶。
  • 產品增量必須符合Scrum團隊當前的“完成的定義”，它的每個部分都應該被產品負責人接受。

2.4 其他可見的進度指示

• Scrum要求在團隊內部和外部都保證透明性，產品增量是保證這種透明性的最重要方式

• 除此之外， Scrum團隊還會根據需要去建立一些其他工件來讓大家瞭解專案狀態

  • * 燃盡圖和任務板是常⻅的展式進度的額外工件*
  • 燃盡圖關注剩下還有多少工作未完成,應該是一個向下的曲線，表示隨著剩餘工作的完成，燒盡至0
  • 燃燒圖關注已經完成了多少工作,應該是一個向上的曲線，表示隨著已完成工作的增多，達到全量

• 交付產品增量時，需要依據共同認可的“完成”標準來確認完成。
• 每個Scrum團隊的“完成的定義”不盡相同，隨著團隊的成熟，其範圍將擴⼤，並且變得越來越嚴格
• “完成的定義”必須總是保證產品增量的質量足夠好，從而達到可交付使用的狀態：產品負責人可以選擇隨時釋出它

三、 Scrum活動或會議

3.1 產品待辦事項列表梳理

產品待辦事項通常會很大，也很寬泛，而且想法會變來變去、優先順序也會變化，所以產品待辦事項列表梳理是一個貫穿整個Scrum專案始終的活動

• 包含但不限於以下的內容：
  
  • 保持產品待辦事項列表有序
  • 把看起來不再重要的事項移除或者降級
  • 增加或提升湧現出來的或變得更重要的事項
  • 將事項分解成更小的事項
  • 將事項歸併為更大的事項
  • 對事項進行估算

產品待辦事項列表梳理的最大好處是為即將到來的幾個Sprint做準備。為此，梳理時會特別關注那些即將被實現的事項

• 需要考慮不少因素，這包括但不限於以下的內容：
  
  • 理想情況下，下一個Sprint的備選事項都應該提升“商業價值”。
  • 開發團隊需要能夠在一個Sprint內完成每一個事項
  • 每個人都需要清楚預期產出是什麼
  • 產品開發決定了，有可能需要其它的技能和輸入。因此，產品待辦事項列表梳理最好是所有團隊成員都參與的活動，而不單單是產品負責人

3.2 Sprint計劃會議

決定如何完成工作是開發團隊的職責，決定做什麼則是產品負責人的職責

每個Sprint都由一個限定時間的會議開始，這個會議稱作Sprint計劃會議。在這個會議中，Scrum團隊共同選擇和理解在即將到來的Sprint中要完成的工作。

• 所有的Scrum會議都是限定時⻓的。 Sprint計劃會議推薦時⻓是Sprint中的每一週對應兩個時或者更少
  因為會議是限制時間的， Sprint計劃會議的成功十分依賴於產品待辦事項列表的質量
• 整個團隊都要參加Sprint計劃會議
• 針對排好序的產品待辦事項列表（ Product Backlog），產品負責人和開發團隊成員討論每個事項，並對該事項達成共識，包括根據當前的“完成的定義”，為了完成該事項所需要完成的所有事情

在Scrum中， Sprint計劃會議有兩部分：

• 決定在Sprint中需要完成哪些工作；

  • 產品負責人向開發團隊介紹排好序的產品待辦事項，整個Scrum團隊共同理解這些工作
  • Sprint中需要完成的產品待辦事項數目完全由開發團隊決定
    做多少工作只能由開發團隊決定。
    產品負責人或任何其它人，都不能給開發團隊強加更多的工作量。
  • 為了決定做多少，開發團隊需要考慮當前產品增量的狀態，團隊過去的工作情況，團隊當前的生產能力，以及排好序的產品待辦事項列表
  • 通常Sprint都有個目標，稱作Sprint目標

• 決定這些工作如何完成

  • 開發團隊需要根據當前的“完成的定義”一起決定如何實現下一個產品增量
  • 進行足夠的設計和計劃，從而有信心可以在Sprint中完成所有工作
  • 頭幾天的工作會被分解成小的單元，每個工作單元不超過1天。之後要完成的工作可以稍大些，以後再對它們進行分解
  • 產品負責人可以繼續留下來回答問題，以及澄清⼀些誤解。不管怎樣，團隊應該很容易找到產品負責人

Sprint計劃會議最終需要Scrum團隊對Sprint需要完成工作的數量和複雜度達成共識，並預期在一個合理的條件範圍內完成它們。
開發團隊預測並共同承諾他們要完成的工作量

總之：在Sprint計劃會議中，開發團隊

• 和產品負責人一起考慮並討論產品待辦事項，
• 確保他們對這些事項的理解，
• 選擇一些他們預測能完成的事項，
• 建立足夠詳細的計劃來確保他們能夠完成這些事項
• 產出《Sprint待辦事項列表（ Sprint Backlog）》

3.3 每日Scrum會議

開發團隊是自組織的。開發團隊通過每日Scrum會議來確認他們仍然可以實現Sprint的目標。這個會議每天在同樣的時間和同樣的地點召開

• 每個開發團隊成員需要提供以下三點資訊：

  • 從上一個每日Scrum到現在，我完成了什麼；
  • 從現在到下一個每日Scrum，我計劃完成什麼；
  • 有什麼阻礙了我的進展。

• 每日Scrum中可能有簡要的問題澄清和回答，但是不應該有任何話題的討論。
  通常，許多團隊會在每日Scrum之後馬上開會處理他們遇到的任何問題

• 每日Scrum既不是向管理層彙報，也不是向產品負責人或者ScrumMaster彙報
  它是一個開發團隊內部的溝通會議，來保證他們對現狀有一致的瞭解

• 每日Scrum是Scrum的一個關鍵組成部分，它可以帶來透明性，信任和更好的績效。能幫助快速發現問題，並促進團隊的自組織和自立

• 所有Scrum會議都是限定時⻓的。每日Scrum通常不超過15分鐘

3.4 Sprint評審會議

Sprint結束時， Scrum團隊和相關人員一起評審Sprint的產出。

所有Scrum會議都是限定時間的， Sprint評審會議的推薦時長是Sprint中的每一週對應2個小時
Sprint評審會議向每個人展示了當前產品增量的概況。因此，通常都會在Sprint評審會議中調整產品待辦事項列表

• 討論圍繞著Sprint中完成的產品增量

  • 由於Sprint的產出會涉及到一些人的“利益”，因此一個明智的做法是邀請他們參加這個會議，這會很有幫助
  • 這個會議是個非正式的會議，幫助大家瞭解我們當前進展到哪⾥，並一起討論我們下一步如何推進
  • 每個人都可以在Sprint評審會議上發表意見
  • 產品負責人會對未來做出最終的決定，並適當地調整產品待辦事項列表（ Product Backlog）

• 團隊會找到他們自己的方式來開Sprint評審會議

  • 通常會演示產品增量
  • 整個小組也會經常討論他們在Sprint中觀察到了什麼、有哪些新的產品想法出現
  • 還會討論產品待辦事項列表的狀態、可能的完成工期以及在這些工期前能完成什麼

3.5 Sprint回顧會議

Sprint回顧會議的推薦時間是Sprint中的每1周對應1個小時

在每個Sprint結束後， Scrum團隊會聚在一起開Sprint回顧會議，目的是回顧下團隊在流程、人際關係以及工具方面做得如何

Scrum團隊總是在Scrum的框架內，改進他們自己的流程

3.6 Scrum合作會議

合作會議允許不同的團隊來參加，以協調團隊之間的工作

四、Scrum價值觀

• 專注：一段時間內只專注於少數件事情
• 勇氣
• 公開
• 承諾
• 尊重