Scrum 學習筆記

Scrum 學習筆記

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

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

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


敏捷價值觀之敏捷十二原則
• 咱們的最高目標是，經過儘早和持續地交付有價值的軟件來知足客戶。
• 歡迎對需求提出變動——即便是在項目開發後期。要善於利用需求變動，幫助客戶得到競爭優點。
• 要不斷交付可用的軟件，週期從幾周到幾個月不等，且越短越好。
• 項目過程當中，業務人員與開發者必須在一塊兒工做。
• 要善於激勵項目人員，給他們以所需要的環境和支持,並相信他們能夠完畢任務。
• 不論是團隊內仍是團隊間，最有效的溝通方法是面對面的交談。
• 可用的軟件是衡量進度的主要指標。
• 敏捷過程提倡可持續的開發。項目方、開發者和用戶應該能夠保持恆久穩定的進展速度。
• 對技術的精益求精以及對設計的不斷無缺將提高敏捷性。
• 要作到簡潔，即盡最大可能下降沒必要要的工做。這是一門藝術。
• 最佳的架構、需求和設計出自於自組織的團隊。
• 團隊要按期檢討怎樣能夠作到更有效，並對應地調整團隊的行爲。

Scrum 的特色
• Scrum 規定了一個很easy的開發流程。
• 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 人團隊規模的項目。