通過前面兩篇文章，我們介紹了敏捷宣言，包括4條宣言和12條準則。可以說敏捷開發的所有理念，思想，方法都來源於敏捷宣言，所有想要實施敏捷，要先理解敏捷宣言。那麼經過上面的文章，我們大家都知道了敏捷實際上是一種理念，一種思想的轉變，從傳統的開發模式進入到新的以價值為驅動的開發模式中。那麼有什麼具體的方法呢。從這篇文章開始，我們逐一介紹一些主流的敏捷開發方法。 首先，現在敏捷開發中比較流行的方法就是SCRUM了，而且很多人在實際應用中，也把SCRUM和敏捷劃上等號。實際上在這裡，我們要先分清一點，包括SCRUＭ，還有我們以後要介紹的ＫＡＮＢＡＮ，ＸＰ等都是敏捷理念落實到實踐中的一種實際方法而已，它們從不同角度體現了敏捷思想，並且可以根據企業的實際情況，來進行落地和調整。並不是說某種方法是敏捷的，其他的就不是敏捷的了。 好了，言歸正傳，我們先了解一下ＳＣＲＵＭ的前世今生。 Scrum的歷史可以追溯到1986年《哈佛商業評論》中的一篇文章《新型的新產品開發策略》（The New New Product Development Game，竹內弘高、野中鬱次郎，1986）。這篇文章描述了像本田、佳能、富士施樂這樣的公司是如何通過可伸縮、基於團隊的並行產品開發方式開發出了世界一流的產品。文章同時強調了授權、自組織團隊的重要性，並概要描述了管理在開發過程中發揮的作用。 當然，SCRUM這個詞沒有什麼標準的中文解釋，它是來源於橄欖球中的一個爭球的動作，如下圖。
竹內弘高和 野中鬱次郎在New New Product Development Game文章首次提到將Scrum應用與產品開發，他們指出： 傳統的“接力式”的開發模式已經不能滿足快速靈活的市場需求，而整體或“橄欖球式”的方法——團隊作為一個整體前進，在團隊的內部傳球並保持前進，這也許可以更好的滿足當前激烈的市場競爭。
上圖是SCRUM的一個典型架構圖，我們可以看到裡面有很多要素，下面我們一一介紹這些要素。 3355原則： 大家可能很多人都聽過3355原則，這個就是ＳＣＲＵＭ框架總結出來的核心要素了。 一　３個角色： Ｐｒｏｄｕｃｔ　Ｏｗｎｅｒ：產品負責人，能夠直接和客戶和團隊接觸，非常瞭解客戶需要什麼，並且能夠將客戶需求分解為合適的ｕｓｅｒ　ｓｔｏｒｙ，在某些公司，該職位可能會和ＢＡ想關聯，但是實際上ＰＯ的角色要比ＢＡ重要的多，因為在大部分實際情況裡，他是要對產品的交付負主要責任。 Ｓｃｒｕｍ　Ｍａｓｔｅｒ：可以理解為Ｓｃｕｒｍ主管，在團隊中保證ｓｃｒｕｍ流程，同時幫助團隊解決可能出現的問題，同時也負責團隊和ＰＯ的ｃｏａｃｈ功能，最終目標讓團隊成為真正的自組織團隊。 Ｓｃｒｕｍ　Ｔｅａｍ：可以認為是開發團隊，但是要是一個跨職能的團隊，也就是能夠交付一個端到端的真正對客戶有價值的產品。很多公司可能無法做到，但是隻要少包括開發，測試和一些系統設計人員。 二　３個元件 Ｐｒｏｄｕｃｔ　Ｂａｃｋｌｏｇ：產品開發列表，將需求轉變為ＰＢ裡面的具體的ｉｔｅｍ，能夠使所有相關人看到一張統一的Ｂａｃｋｌｏｇ，這樣大家可以對產品開發形成統一的優先順序和價值導向。 Sprint Backlog：每個迭代的功能開發列表，也就是每個sprint要從上面的PB中按照優先順序獲得本迭代要做item。然後原則上在每個迭代中是不能被打斷的。 Burndown chart:燃盡圖，在每個迭代顯示剩餘工作時間和任務完成情況的圖示。 Sprint Backlog 圖
Burndown chart
二 5個價值 專注：每個迭代只專注於迭代要完成的事情，團隊和個人的能力和精力是有限的，在有限的時間內專注於最有價值的事情，以取得好的結果。 勇氣：要有勇氣去面對各種挑戰。 公開：團隊所有的進展，問題，阻礙都是對所有人視覺化，透明的。這樣的團隊才是彼此尊重。同時也能暴露問題。 承諾：作為一個自組織團隊，在迭代開始的時候做出承諾，並在迭代中全力完成。 尊重：團隊是長期坐到一起，並且穩定的，有助於加深彼此的瞭解和溝通。 三 5個活動 Sprint:衝刺sprint,一個固定的時間週期（通常為2w-4w） sprint planning meeting：每個迭代開始之前，PO負責講解需求，團隊進行估算每個user story的大小，以便於決定在該迭代選擇哪些user story進行開發。 daily standupo meeting:每日站會，scrum為了加強團隊溝通，每天團隊都要選擇一個時間站在一起，互相交流彼此的進展和問題。 sprint review:評審會議，通常在每個迭代的最後一天，會議上團隊交付自己在這個迭代中開發的產品或者軟體（一定要可以工作）有PO和團隊成員進行評審，看是否符合產品開發要求。 retrospective meeting:回顧會議，通常在reivew會議之後開始，有團隊成員在衝刺結束之後對上個迭代進行總結，同時提出一些改進方案，這是一個持續改進的過程。 SCRUM的其他一些要素： user story:使用者故事，因為敏捷要求每個特性都是對客戶有價值的，所以以使用者故事的方式來設計特性，通常是作為客戶，我要實現A功能，以至於我可以達到什麼目的的結構。 task：每個迭代中為了開發一個user story,將其分解為一些task,比如說我要開發一個協議，其中需要幾個task,包括搭建伺服器，找一些開原始碼，搭建自動化測試框架，編碼，測試任務，便於更小粒度的track每個迭代的進展。 release planning：在某些大型組織，可能更關注release級別的產品交付，所以每個release之前要進行整個release的plan,決定這個release的PB。 points：故事點數，代表使用者故事的大小，要記住，這裡的大小不代表開發時間，只是一個相對的使用者故事的複雜度，工作量大小。因為很難理解，所以scrum team要建立一個基準的user story，作為一個points，然後其他的user story和它進行相對比較。這個points大部分時間用來作為評估team的交付能力。 SCRUM開發流程： Scrum 是一個用於開發和維持複雜產品的框架 ，是一個增量的、迭代的開發過程。在這個框架中，整個開發過程由若干個短的迭代週期組成，一個短的迭代週期稱為一個Sprint，每個Sprint的建議長度是2到4周(網際網路產 品研發可以使用1周的Sprint)。在Scrum中，使用產品Backlog來管理產品的需求，產品backlog是一個按照商業價值排序的需求列表，列表條目的體現形式通常為使用者故事。Scrum團隊總是先開發對客戶具有較高價值的需求 。在Sprint中，Scrum團隊從產品Backlog中挑選最高優先順序的需求進行開發。挑選的需求在Sprint計劃會議上經過討論、分析和估算得到相應的任務列表，我們稱它為Sprint backlog。在每個迭代結束時，Scrum團隊將遞交 潛在可交付的產品增量。 SCRUM各個角色之間的關係和作用： PO和team的關係：一個人拿到了客戶的一個專案，開發一個產品，他就是ＰＯ，他想找一個團隊開做這個產品，但是現在有Ａ團隊和Ｂ團隊，Ａ團隊跟PO說，ok,交給我吧，3個月後你過來，我們把產品給你.而B團隊說，我們每個月都可以讓你看一下我們的產品，但是可能一開始功能不完善，但是可以工作的，然後你可以把我們的產品給客戶看，如果運氣好的話客戶可能先給你點錢呢。 如果你作為PO，你會選擇哪個團隊呢？對了，A就是傳統的開發團隊，而B則是我們的scrum team. scrum master和team還有PO的關係： 個人給SM有以下幾個定義： 1　ｔｅａｍ　ｃｏａｃｈ：他可以ｃｏａｃｈ　ｔｅａｍ，不僅是保證流程，主要的是改變大家的思想，讓大家接受敏捷開發理念，從而更好的組織團隊，交付產品。 ２.　ｔｅａｍ　ｄｕｄ：scrum master不是ｌｅａｄｅｒ，他實際上是ｔｅａｍ的夥伴，希望通過自己的幫助，讓ｔｅａｍ能夠解決在ｓｃｒｕｍ框架下發生的問題，移除障礙，從而讓ｔｅａｍ不斷的發展，自我組織。 ３.　ｔｅａｍ　ｐｒｏｔｅｃｔｅｒ：團隊保護者，ＳＭ要根據團隊情況，儘量保證團隊在每個迭代中不被打擾，如果發現有影響團隊迭代的事情，比如說臨時增加任務等，一定要站出來保護團隊。 ４.　ＰＯ　ｃｏａｃｈ：我個人現在發現，SM作為coach，有意無意的往往會忽略了對ＰＯ的ｃｏａｃｈ作用，因為現實環境中PO往往是專案經理或者leader轉化而來，具有先天的權利優勢，但是一個好的PO往往是決定一個團隊的成敗關鍵之一，所以SM 作為team coach的角色，很重要一點就是coach PO，從而使得PO，TEAM能夠更好的協作，達到一個共贏團隊。 SCRUM大事表： Jeff Sutherland在 1993年首次在Easel公司定義了用於了軟體開發行業的Scrum流程，並開始實施。 1995年Jeff Sutherland和Ken Schwaber規範化了Scrum框架，並在OOPSLA 95上公開發布。 2001年 敏捷宣言及原則釋出、敏捷聯盟成立，Scrum是其中一種敏捷方法。 2001年，Ken Schwaber和Mike Beedle推出第一本Scrum書籍《Scrum敏捷軟體開發》。 2002年Ken Schwaber 和Mike Cohn共同創辦了Scrum聯盟。