Scrum 學習筆記
羅朝輝(http://m.shnenglu.com/kesalin)

敏捷火了很長一段時間了，但是一直沒有機會實踐，現在開始組隊實踐了，哈哈，先好好研習下規則~~

什么是 scrum
Scrum是一個敏捷開發框架，是一個增量的、迭代的開發過程。在這個框架中，整個開發周期包括若干個小的跌代周期，每個小的的跌代周期稱為一個 Sprint，每個 Sprint 的建議長度2到4周。在 Scrum 中，使用產品 Backlog 來管理產品或項目的需求，產品 backlog 是一個按照商業價值排序的需求列表，列表條目的體現形式通常為用戶故事。Scrum 的開發團隊總是先開發的是對客戶具有較高價值的需求。在每個 Sprint 中，Scrum 開發團隊從產品Backlog中挑選最有價值的需求進行開發。Sprint 中挑選的需求經過 Sprint 計劃會議上的分析、討論和估算得到一個 Sprint 的任務列表，我們稱它為 Sprint backlog。在每個迭代結束時，Scrum 團隊將交付潛在可交付的產品增量。

敏捷價值觀之敏捷四宣言
• 個體與交互重于過程和工具
• 可用的軟件重于完備的文檔
• 客戶協作重于合同談判
• 響應變化重于遵循計劃

敏捷價值觀之敏捷十二原則
• 我們的最高目標是，通過盡早和持續地交付有價值的軟件來滿足客戶。
• 歡迎對需求提出變更——即使是在項目開發后期。要善于利用需求變更，幫助客戶獲得競爭優勢。
• 要不斷交付可用的軟件，周期從幾周到幾個月不等，且越短越好。
• 項目過程中，業務人員與開發人員必須在一起工作。
• 要善于激勵項目人員，給他們以所需要的環境和支持,并相信他們能夠完成任務。
• 無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
• 可用的軟件是衡量進度的主要指標。
• 敏捷過程提倡可持續的開發。項目方、開發人員和用戶應該能夠保持恒久穩定的進展速度。
• 對技術的精益求精以及對設計的不斷完善將提升敏捷性。
• 要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
• 最佳的架構、需求和設計出自于自組織的團隊。
• 團隊要定期反省如何能夠做到更有效，并相應地調整團隊的行為。

Scrum 的特點
• Scrum 規定了一個非常簡單的開發流程。
• Scrum 是現有設計流程的總結。
• Scrum 以團隊為基礎，是一種在需求迅速變化情況下迭代地、增量地開發系統和產品的方法。
• Scrum 是一個控制由利益和需求沖突導致的混亂的流程。
• Scrum 是改善交流并最優化合作的方式。
• Scrum 是一種檢測產品開發和生產過程中障礙并將其去除的方式。
• Scrum 是最大化生產率的一種方法。
• Scrum 適用于單一的項目到整個企業。Scrum 可以控制并組織多個具有相關性的產品開發以及擁有超過千名開發者和執行者的項目實施過程。
• Scrum 能讓每個參與者都對自己所做的工作以及自己做出的貢獻感到驕傲，并讓他們發揮到最佳水平。

Sprints
• Scrum的項目過程有一系列的Sprint組成。
• Sprint的長度一般控制在2-4周。
• 通過固定的周期保持良好的節奏。
• 產品的設計、開發、測試都在Sprint期間完成。
• Sprint結束時交付可以工作的軟件。
• 在Sprint過程中不允許發生變更。

Scrum 框架
三個角色：產品負責人，Scrum Master，團隊
四個儀式：Sprint 計劃會議，每日站會，Sprint 評審會議，Sprint 回顧會議
三個物件：產品 Backlog，Sprint Backlog，燃盡圖

Scrum 角色之產品負責人
產品負責人(Product Owner)的職責如下: 
• 確定產品的功能。
• 決定發布的日期和發布內容。
• 為產品的 profitability of the product (ROI)負責。
• 根據市場價值確定功能優先級。
• 每個 Sprint，根據需要調整功能和優先級(每個 Sprint 開始前調整)。
• 接受或拒絕接受開發團隊的工作成果。

Product Owner參與Scrum planning。

Scrum角色之 Scrum Master
作為Team Leader和Product owner緊密地工作在一起,他可以及時地為團隊成員提供幫助。 他必須:
• 保證團隊資源完全可被利用并且全部是高產出的。
• 保證各個角色及職責的良好協作。
• 解決團隊開發中的障礙。
• 做為團隊和外部的接口，屏蔽外界對團隊成員的干擾。
• 保證開發過程按計劃進行，組織 Daily Scrum, Sprint Review and Sprint Planning meetings。

Scrum角色之團隊
• 一般情況人數在5-9個左右
• 團隊要跨職能(包括開發人員、測試人員、用戶界面設計師等) 
• 團隊成員需要全職。(有些情況例外，比如數據庫管理員)
• 在項目向導范圍內有權利做任何事情已確保達到 Sprint 的目標。
• 高度的自我組織能力。
• 向 Product Owner演示產品功能。
• 團隊成員構成在 Sprint 內不允許變化。

Scrum 儀式之 Sprint 計劃會議
> 排列優先級：
• 分析和評估產品Backlog
• 確定Sprint目標

> Sprint 計劃：
• 決定如何達到 Sprint 目標(設計)。
• 根據產品 Backlog 條目(用戶故事，功能)創建 Sprint Backlog(任務)。
• 為 Sprint Backlog 中的任務做估算，用小時來計算

Scrum 儀式之 Sprint 評審會議
Sprint評審會用來演示在這個 Sprint 中開發的產品功能給 Product Owner。Produc Owner 會組織這階段的會議并且邀請相關的干系人參加。
• 團隊展示 Sprint 中完成的功能
• 一般是通過現場演示的方式展現功能和架構
• 不要太正式
• 不需要PPT
• 一般控制在2個小時
• 團隊成員都要參加
• 可以邀請所有人參加

Scrum 儀式之 Sprint 回顧會議
• 團隊的定期自我檢視，發現什么是好的，什么是不好的。
• 一般控制在 15 - 30 分鐘
• 每個 Sprint 都要做
• 全體參加：Scrum Master，產品負責人，團隊，可能的客戶或其它干系人

Sprint 回顧會議上，全體成員討論有哪些好的做法可以啟動，哪些不好的做法不能再繼續下去了，哪些好的做法要繼續發揚。

Scrum 物件之產品 Backlog
• 一個需求的列表。
• 一般情況使用用戶故事來表示 backlog 條目
• 理想情況每個需求項都對產品的客戶或用戶有價值
• Backlog 條目按照商業價值排列優先級
• 優先級由產品負責人來排列
• 在每個 Sprint 結束的時候要更新優先級的排列

Scrum 物件之 Sprint Backlog
Sprint backlog 定義了 Sprint 的目標，明確了 Sprint 過程中具體需要完成的任務。
管理 Sprint 的 backlog:
• 團隊成員自己挑選任務，而不是指派任務
• 對每一個任務，每天要更新剩余的工作量估算
• 每個團隊成員都可以修改 Sprint backlog，增加、刪除或者修改任務

Scrum 物件之燃盡圖(Burn Down Chart)
燃盡圖直觀的反映了Sprint過程中剩余的工作量情況，Y軸表示剩余的工作，X軸表示 Sprint 的時間。隨著時間的消耗工作量逐漸減少，在開始的時候，由于估算上的誤差或者遺漏工作量有可能呈上升態勢。

擴展 Scrum
• 一般情況一個團隊的人數控制在5-9人。大型項目可以采用多團隊，通過team of teams來擴展Scrum。
• 影響擴展的因素：團隊規模，項目類型，項目周期，團隊分布。
• Scrum 曾被用于超過 1000 人團隊規模的項目。