Scrum綜合指南

Scrum是一個項目管理框架，強調團隊合做，問責制和迭代進展，以實現明確的目標。該框架從一個簡單的前提開始：從能夠看到或已知的東西開始。以後，跟蹤進度並根據須要進行調整。

Scrum的三大支柱

Scrum的基礎是經驗主義，它指出知識來自經驗，咱們應該根據已知的事情作出決定。有三個支柱將Scrum結合在一塊兒。

爲何選擇Scrum？

Scrum一次提供功能，而瀑布只提供階段。典型的瀑布式開發是基於階段的順序過程，在項目結束以前不會給出價值。Scrum將這種模式轉變爲每一週提供新功能，而不是專一於將來的大發布。

Scrum將複雜的工做劃分爲簡單的部分，將大型組織劃分爲小型團隊，將影響深遠的項目劃分爲一系列短期的稱爲sprint的視野。

經過迭代和漸進式構建，公司可以更快，更有效地爲客戶提供他們真正須要的產品和服務。使用Scrum，您能夠在每一個小開發週期結束時接收並整合客戶反饋，這意味着您的結果將經過實際使用而非您的假設來塑造。這使得讓客戶和主要利益相關者密切參與和參與變得更加容易。

敏捷與Scrum

敏捷方法是一種有助於在SDLC過程當中持續迭代開發和測試的實踐。敏捷將產品分解爲更小的構建。Scrum只是衆多迭代和增量敏捷軟件開發過程當中的一個，它使咱們可以專一於在最短的時間內提供業務價值。

Scrum框架一般處理的是需求可能會發生變化，或者大部分時間在項目開始時都不知道。Scrum的特色是：

• 輕量級
• 簡單易懂
• 很難掌握

Scrum的好處

如下是scrum爲組織，團隊，產品和我的提供的好處。

1. 更好的質量：存在實現願景或目標的項目。Scrum提供持續反饋和曝光的框架，以確保質量儘量高。Scrum經過如下實踐幫助確保質量
2. 縮短產品上市時間：Scrum已被證實可以爲傳統方法提供比最終客戶快30％到40％的價值。
3. 提升投資回報率：縮短上市時間是Scrum項目實現更高投資回報率（ROI）的一個關鍵緣由。因爲收入和其餘目標福利開始提早，早期積累意味着更高的總回報率。這是淨現值（NPV）計算的基本原則。
4. 士氣高級團隊：與喜歡工做的快樂人士一塊兒工做能夠使人滿意和有益。自我管理將一般由經理或組織作出的決策放入scrum團隊成員的手中。
5. 增強團隊協做：當Scrum團隊負責項目和產品時，他們能夠產生很好的結果。Scrum團隊經過加強團隊參與和溝通來協做並掌握質量和項目績效。

Scrum框架

Scrum很簡單。它與大量交織的強制組件相反。Scrum不是一種方法論。Scrum實現了經驗主義的科學方法。Scrum用啓發式方法取代了程序化的算法方法，尊重人和自組織，以處理不可預測性和解決複雜問題。下圖顯示了Ken Schwaber和Jeff Sutherland在他們的「30天軟件」一書中描述的Scrum in Action，它將咱們從規劃到軟件交付。

Scrum流程的組成部分

Scrum框架自己很是簡單。它僅定義了一些通用指南，僅包含一些規則，角色，工件和事件。然而，這些組件中的每個都很重要，用於特定目的，對於成功使用框架相當重要。

Scrum Framework的主要組件是：

• Scrum角色：Scrum Master，Scrum產品負責人和Scrum團隊
• 工件：Sprint積壓，產品積壓，燃盡圖，日誌等......
• Scrum活動：Sprint計劃，春季評論，每日站立，衝刺復古等......
• 短跑

下圖顯示了SCRUM框架的關鍵元素。該過程已由敏捷軟件工具Scrum Process Canvas應用。

Scrum角色

當一個組織決定接受Scrum時，首先要了解的是Scrum角色與傳統項目執行角色的不一樣之處。雖然Scrum中只有三個主要角色，但它們並不會自動與咱們大多數人熟悉的標題保持一致。讓咱們從每一個的簡要定義開始：

產品擁有者

產品全部者是表明業務或用戶社區的人員的scrum開發角色，負責與用戶組合做以肯定產品版本中的功能。產品負責人的主要職責是：

• 制定產品和服務的方向和戰略，包括短時間和長期目標;
• 提供或獲取有關產品或服務的知識;
• 瞭解並解釋開發團隊的客戶需求;
• 收集，優先排序和管理產品或服務要求;
• 接管與產品或服務預算相關的任何責任，包括其盈利能力;
• 肯定產品或服務功能的發佈日期;
• 天天與開發團隊一塊兒回答問題並作出決定;
• 接受或拒絕與Sprint相關的已完成功能;
• 在每一個Sprint的最後展現開發團隊的主要實現;
• 負責產品Backlog

Scrum大師

Scrum master是敏捷開發團隊的推進者。Scrum是一種方法，容許團隊根據敏捷原則自我組織並快速進行更改。Scrum master管理信息交換的過程。Scrum Master的主要職責是：

• 充當教練，幫助團隊遵循Scrum價值觀和實踐;
• 幫助消除障礙並保護團隊免受外部干擾;
• 促進團隊與利益相關者之間的良好合做;
• 促進團隊內部的常識;
• 保護團隊免受組織干擾;

Scrum團隊

Scrum團隊（又名開發團隊）由3到9人組成，他們必須知足提供產品或服務的全部技術需求。它們將由Scrum Master直接引導，但不會直接管理。他們必須是自我組織的，多才多藝的，而且負責任地完成全部必需的任務。

開發團隊負責從分析，設計，開發，測試到技術寫做等每一個sprint提供潛在的可交付產品增量。對於Scrum團隊具備如下特徵很是重要：

• 團隊必須是自組織的。全部團隊組件必須管理本身的工做以完成已經給出的任務。在Agile Scrum中，沒有團隊負責人或直線經理的身影。每一個人都必須作出足夠的承諾來開展本身的活動，併爲團隊的成功作出貢獻。若是一個失敗，每一個人都會失敗。
• 團隊必須是跨職能的。全部團隊成員必須擁有全部必需的知識和技能，以提供作得好而且隨時可用的服務或產品。專家可用於必要的案例，但僅做爲教練將知識傳授給團隊以實現特定差距。
• 成爲產品負責人須要企業願景。產品負責人表明客戶的聲音，須要將他們的需求轉化爲Scrum Master和開發團隊。這一般是一份全職工做。
• Scrum Master不是直線經理。他們幫助向開發團隊提供所需的教練，並幫助消除團隊面臨的任何障礙。

Scrum工件

SCRUM工件用於幫助定義進入團隊而且當前正在團隊中工做的工做負載。還有更多的工件，例如，用戶故事，發佈積壓，刻錄圖表等。但咱們將專一於核心三：

產品積壓

產品待辦事項是用戶故事的集合，其呈現產品團隊所需/指望的功能。一般，產品全部者負責此列表。

Sprint積壓

Sprint積壓包含一系列能夠包含在當前sprint中的故事。有關sprint積壓與將項目包含在sprint中之間關係的兩個要點須要注意。1）團隊決定添加到sprint的內容。所以，團隊負責交付這些物品的全部權和責任。2）在將項目從sprint backlog中刪除並添加到sprint以前，團隊必須確保他們擁有積壓中所需的全部信息。一般，團隊定義在添加項目以前必須存在的項目清單。

產品Backlog與Sprint Backlog

在衝刺積壓是Scrum的衝刺過程當中完成了由Scrum團隊肯定的任務列表。在sprint計劃會議期間，團隊一般以用戶故事的形式選擇一些產品待辦事項，並肯定完成每一個用戶故事所需的任務，以下圖所示：

刻錄圖表

刻錄圖表是剩餘工做與時間的圖形表示。突出的工做（或積壓工做）一般在垂直軸上，沿水平方向的時間。也就是說，這是一份傑出工做的運行圖表。它可用於預測什麼時候完成全部工做。它一般用於敏捷軟件開發方法，如Scrum。可是，刻錄圖表能夠應用於任何包含一段時間內可衡量進展的項目。傑出的工做能夠用時間或故事點來表示。

Scrum活動

溝通是關鍵！SCRUM依賴於團隊的全部方面而且透明地工做（Scrum支柱＃1）。考慮到這種核心理念，該方法圍繞一系列關鍵事件構建，以確保其餘兩個支柱：檢查和調整以下表所示：

事件

檢查

適應

Sprint計劃

• 產品積壓
• （承諾回顧）
• （Done的定義）
• 衝刺目標
• 預測
• Sprint積壓

每日Scrum

• 衝刺目標的進展
• Sprint積壓
• 每日計劃

Sprint評論

• 產品增量
• 產品積壓（發佈）
• 市場商業條件
• 產品積壓

Sprint回顧

• 團隊合做
• 技術與工程
• 完成的定義
• 切實可行的改進

注意：在執行每一個sprint期間，Scrum中有五個主要會議，以下圖所示：

Sprint計劃

全部衝刺都從計劃開始。團隊須要肯定並承諾將做爲sprint的一部分交付哪些項目。可能的項目老是從Sprint Backlog中獲取，以下圖所示：

這是SCRUM主人能夠發光的時間。產品全部者從業務/客戶的角度肯定他們須要的方面，SCRUM團隊，肯定他們認爲能夠提供哪些項目，以及SCRUM主人適應全部項目並確保知足兩個方面的最佳要求。

每日Scrum會議

一旦團隊肯定了他們承諾做爲sprint的一部分交付的項目。該團隊將舉行每日站立會議。這次會議的核心目標是確保團隊中的每一個人（以及可能的觀察員）徹底瞭解正在完成的任務的狀態和進度：

• 他們作了什麼
• 他們今天要作什麼
• 什麼阻止他們

此每日更新向團隊提供實例反饋並提供。這些會議意味着簡短，每人不超過3分鐘。

注意：

觀察員在那裏觀察，SCRUM主人必須儘量減輕外部干擾和團隊干擾。

Sprint評審會議

在Sprint結束時舉行Sprint評審/演示會議以檢查增量。團隊根據完成定義演示增量，重點關注Sprint目標。產品負責人審覈並接受交付的增量。

Sprint回顧

衝刺回顧一般是衝刺中最後完成的事情。許多團隊將在衝刺審查後當即執行此操做。包括Scrum Master和產品全部者在內的整個團隊都應該參與其中。您能夠安排scrum回顧展達一個小時，這一般是足夠的。回顧展讓團隊有機會肯定3個關鍵方面：

1. 應該開始作什麼？
2. 什麼不順利（並再次中止作）？
3. 什麼進展順利（而且應該繼續作什麼？）？

這種方法的目的是不斷提升團隊效率。

積壓細化會議

將積壓視爲項目的路線圖。當團隊協做建立須要爲項目完成構建或完成的全部事項的列表時，能夠修改此列表並將其添加到整個項目中，以確保知足項目的全部必要需求。

短跑

在Scrum框架中，Scrum產品Backlog中實現條目所需的全部活動都在Sprint中執行（也稱爲「Iterations」）。短跑老是很短：一般大約2-4周。每一個Sprint都遵循一個定義的過程，以下所示：

如前所述，產品待辦事項中的項目按優先級排序並選擇sprint backlog。一個sprint只包含幾個大項目，即便單個項目低估工做的影響也會對sprint產生深遠的影響。並且因爲較大的項目每每難以估計和理解，所以短跑失敗的可能性會進一步增長。經驗豐富的Scrum團隊花費時間和精力將複雜和較大的項目（即用戶功能或史詩）分解爲較小的用戶故事（或隨後分解爲任務或子任務）。

史詩

史詩捕捉了大量的做品。它本質上是一個「大型用戶故事」，能夠分解爲許多小故事。完成史詩可能須要幾回衝刺。所以，當咱們將epic用於開發時，它必須被分解爲更小的用戶故事。

在項目週期的早期，咱們提出了Epics。這些是很是高級的，幾乎以營銷爲中心的功能性要點。

咱們將大型故事稱爲「史詩」，以傳達有關它們的信息。我喜歡把這與電影有關。若是我告訴你一部特定的電影是一部「動做冒險電影」，它會告訴你有關電影的一些信息。可能有一些汽車追逐，多是一些射擊，等等。一樣，將一個故事稱爲「史詩」有時能夠傳達其餘意義。

用戶故事

故事是產品要求或業務案例的簡要陳述。一般，故事用簡單的語言表達，以幫助讀者理解軟件應該完成的內容。產品全部者建立故事。而後，scrum用戶將故事分紅一個或多個scrum任務。

用戶故事一般是最終用戶可見的功能。用戶故事遵循「我做爲世界衛生組織想要作什麼」的格式，以便爲何。用戶故事爲客戶/用戶提供價值。這是客戶/用戶的產品要求。

例如「做爲客戶，我但願可以建立一個賬戶，以便我能夠看到我去年購買的商品，以幫助我明年的預算。」

任務

另外一方面，任務更具技術性，任務一般相似於代碼，設計，爲此類建立測試數據，自動執行等等。這些每每是由一我的完成的事情。任務不是以用戶素材格式編寫的。任務更具技術性。

例如「評估用戶界面的角度材料設計」或「將應用程序提交到應用商店」。

為初學者提供更多敏捷和Scrum文章

Scrum和自組織團隊 (Scrum and Self-Organizing Team)
敏捷和Scrum - 有什麼區別？
在Scrum Sprint中發佈的頻率是如何肯定的？
經過3個步驟創建自組織團隊
The Best Free Scrum Learning Resources, Guides and Articles
爲何敏捷開發是您項目的更好選擇？
爲何Scrum是 - 快速失敗技術?
8常常被誤解的Scrum Master角色
Scrum Events - 初學者閱讀文章
Scrum在3分鐘內完成