通過前面兩篇文章，我們介紹了敏捷宣言，包括4條宣言和12條準則。可以說敏捷開發的所有理念，思想，方法都**於敏捷宣言，所有想要實施敏捷，要先理解敏捷宣言。那麼經過上面的文章，我們大家都知道了敏捷實際上是一種理念，一種思想的轉變，從傳統的開發模式進入到新的以價值為驅動的開發模式中。那麼有什麼具體的方法呢。從這篇文章開始，我們逐一介紹一些主流的敏捷開發方法。
首先，現在敏捷開發中比較流行的方法就是scrum了，而且很多人在實際應用中，也把scrum和敏捷劃上等號。實際上在這裡，我們要先分清一點，包括scruｍ，還有我們以後要介紹的ｋａｎｂａｎ，ｘｐ等都是敏捷理念落實到實踐中的一種實際方法而已，它們從不同角度體現了敏捷思想，並且可以根據企業的實際情況，來進行落地和調整。並不是說某種方法是敏捷的，其他的就不是敏捷的了。
好了，言歸正傳，我們先了解一下ｓｃｒｕｍ的前世今生。
當然，scrum這個詞沒有什麼標準的中文解釋，它是**於橄欖球中的乙個爭球的動作，如下圖。
竹內弘高和 野中鬱次郎在new new product development game文章首次提到將scrum應用與產品開發，他們指出：
傳統的「接力式」的開發模式已經不能滿足快速靈活的市場需求，而整體或「橄欖球式」的方法——團隊作為乙個整體前進，在團隊的內部傳球並保持前進，這也許可以更好的滿足當前激烈的市場競爭。
上圖是scrum的乙個典型架構圖，我們可以看到裡面有很多要素，下面我們一一介紹這些要素。
3355原則：
大家可能很多人都聽過3355原則，這個就是ｓｃｒｕｍ框架總結出來的核心要素了。
一 ３個角色：
ｐｒｏｄｕｃｔ ｏｗｎｅｒ：產品負責人，能夠直接和客戶和團隊接觸，非常了解客戶需要什麼，並且能夠將客戶需求分解為合適的ｕｓｅｒ ｓｔｏｒｙ，在某些公司，該職位可能會和ｂａ想關聯，但是實際上ｐｏ的角色要比ｂａ重要的多，因為在大部分實際情況裡，他是要對產品的交付負主要責任。
ｓｃｒｕｍ ｍａｓｔｅｒ：可以理解為ｓｃｕｒｍ主管，在團隊中保證ｓｃｒｕｍ流程，同時幫助團隊解決可能出現的問題，同時也負責團隊和ｐｏ的ｃｏａｃｈ功能，最終目標讓團隊成為真正的自組織團隊。
ｓｃｒｕｍ ｔｅａｍ：可以認為是開發團隊，但是要是乙個跨職能的團隊，也就是能夠交付乙個端到端的真正對客戶有價值的產品。很多公司可能無法做到，但是只要少包括開發，測試和一些系統設計人員。
二 ３個元件
ｐｒｏｄｕｃｔ ｂａｃｋｌｏｇ：產品開發列表，將需求轉變為ｐｂ裡面的具體的ｉｔｅｍ，能夠使所有相關人看到一張統一的ｂａｃｋｌｏｇ，這樣大家可以對產品開發形成統一的優先順序和價值導向。
sprint backlog：每個迭代的功能開發列表，也就是每個sprint要從上面的pb中按照優先順序獲得本迭代要做item。然後原則上在每個迭代中是不能被打斷的。
burndown chart:燃盡圖，在每個迭代顯示剩餘工作時間和任務完成情況的圖示。
sprint backlog 圖
二 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在 2023年首次在easel公司定義了用於了軟體開發行業的scrum流程，並開始實施。
2023年jeff sutherland和ken schwaber規範化了scrum框架，並在oopsla 95上公開發布。
2023年 敏捷宣言及原則發布、敏捷聯盟成立，scrum是其中一種敏捷方法。
2023年，ken schwaber和mike beedle推出第一本scrum書籍《scrum敏捷軟體開發》。
2023年ken schwaber 和mike cohn共同創辦了scrum聯盟。
scrum敏捷方法
scrum是一套敏捷實踐的fang方 scrum不是乙個縮寫，是乙個橄欖球的術語。使用橄欖球和爭球來隱喻miaomiao shu描述產品開發。我們在做產品開發時，想避免事前的大量架構設計，採用一種更均衡的設計方式，在開始的時候進行一些設計，然後在後續guo cheng zh過程中進行適量 適時的修改...
敏捷開發之Scrum
現在敏捷開發是越來越火了，人人都在談敏捷，人人都在學習scrum和xp.什麼是敏捷開發？敏捷開發 agile development 是一種以人為核心 迭代 循序漸進的開發方法。怎麼理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去一步一步...
敏捷開發之Scrum
什麼是敏捷開發？敏捷開發 agile development 是一種以人為核心 迭代 循序漸進的開發方法。怎麼理解呢？首先，我們要理解它不是一門技術，它是一種開發方法，也就是一種軟體開發的流程，它會指導我們用規定的環節去一步一步完成專案的開發 而這種開發方式的主要驅動核心是人 它採用的是迭代式開發 ...