1.1 為什麼敏捷
由於傳統的瀑布模型管理方法無法滿足現代某些軟體產品開發過程的特點，我們需要使用敏捷的方法（例如，Scrum是一個讓我們關注於在短時間裡交付高質量商業價值的敏捷框架）。
需求頻繁變動，技術不確定，這正式傳統管理方法不滿足現在軟體產品開發的兩個突出問題。因為傳統管理方法不滿足需要，才出現了敏捷的方法。
需求不明確是指：雖然對要做一個怎麼的產品有規劃，但是並不明確和確定所有的功能細節；並且隨著產品的開發，極有可能對產品功能不斷地改變以適應終端使用者的需求。這種情況經常發生對全新概念的產品的開發過程中。
技術的不確定性指的是：技術的發展日新月異，對於所定義功能的可實現性面臨著多重不確定性的因素。
實施Scrum對組織和專案的好處： 1.更高的生產力和更低的成本 2.員工的參與度與工作滿意度增加 3.更快的產品上市時間 4.更高的質量 5.專案干係人滿意度提升
1.2 什麼是敏捷
敏捷方式的核心思想在於迅速把產品投放給使用者來為公司帶來盈利，敏捷的特點是迭代和增量。
對於公司來說，敏捷開發的目的就是儘早開發出可以工作的產品給使用者贏得市場帶來的利潤。在產品投放市場以後，通過客戶的反饋，公司可以繼續改進產品功能。而實現這一目的的過程就是，專案被分成若干個迭代，每段時間裡開發出一部分產品功能（增量），並且按照計劃將這些功能投放到市場成為為公司盈利的產品。與傳統管理方法提前做好計劃，儘量規避變化的管理方式不同，敏捷擁抱需求和技術的變化，認為需求和技術的不明確和變化是必然的。
1.4 敏捷宣言
敏捷宣言是敏捷的根本，它由兩部分組成，分別是敏捷價值觀和敏捷原則。
敏捷宣言： 1.個體和互動高於流程和工具：敏捷強調‘人’，人最清楚如何完成工作，要尊重人的意見和想法。 2.工作的軟體高於詳盡的文件：這裡強調的是要把重點放在工作的軟體上，讓文件服務於軟體，而不是把工作聚焦放在文件上。 3.客戶合作高於合同談判：和合作方建立良好的合作關係共同解決問題要比逐條談判合同細節更重要。 4.響應變化高於遵循計劃：我們認為變化是一件好事，專案是流動的，因此專案有變化是正常的，必須隨時調整。
敏捷宣言遵循的原則 1.我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意， 2.欣然面對需求變化，即使在開發的後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。 3.經常的交付可工作的軟體，相隔幾個星期或一兩個月，傾向於採用較短的迭代。 4.業務人員和開發人員必須合作，專案中的每一天都不例外。 5.激發個體鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達到目標。 6.不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。 7.可工作的軟體是進度的首要度量標準。 8.敏捷過程倡導可持續開發。責任人，開發人員和使用者要能夠共同維持其步調穩定延續。 9.堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。 10.以簡潔為本，它是極力減少不必要工作量的藝術。 11.最好的架構，需求和設計出自組織團隊。 12.團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
1.5 敏捷之傘
按照敏捷之傘的劃分，可以將敏捷的各種方法分為兩個部分。一個部分是輕量級的方法（服務於單個團隊的方法），另一部分是服務於多個敏捷團隊的方法。在輕量級方法中，又可以從方法的問題這個角度將它們分為兩類，其中，Scrum, Kanban都是生產產品的框架，用於產品開發或工作管理。而XP(極限程式設計)，FDD(特性驅動開發)則是工程實踐類的方法。敏捷之傘的另外一部分是服務於多個團隊的方法，根據不同的專案規模和團隊之間的耦合度，有多個方法來協調敏捷團隊的協同工作（如SAFe,Scrum-of-Scrums,LeSS等）。
Scrum:作為最受歡迎，使用最為廣泛的敏捷方法，Scrum是一種迭代的增量化過程，用於產品開發或工作管理。
它是一種可集合各種開發實踐的經驗化過程框架。
Kanban:是一種源於豐田精益化管理的方法，它是僅次於Scrum的另外一種敏捷開發的框架方法。它有以下特點：流程視覺化，
限制WIP(Work In Progress,在製品數量)，度量生產迭代（沒有固定時長的迭代）。相對於Scrum更適合於開發新產品，
Kanban則更加適合於運營團隊實施敏捷的使用。
XP: 極限程式設計，XP注重的核心是溝通，簡明，反饋和勇氣。因為知道計劃永遠趕不上變化，
XP無需開發人員在軟體開始之初期寫出很多的文件。XP提倡測試先行，為了將以後出現bug的概率將到最低。
在XP的12個團隊實踐中，TDD（測試驅動開發）是其中之一。它的原理是在開發功能程式碼之前，
先編寫單元測試用例程式碼，測試程式碼確定編寫什麼產品程式碼，即通過測試驅動整個開發的進行。
FDD：特性驅動開發，FDD是一套針對中小型軟體開發專案的開發模式，是一個模型驅動的快速迭代開發過程，
它強調的是簡化，實用，易於被開發團隊接受，適用於需求經常變動的專案。
Scrum-of-Scrums: SoS是一種管理大型的Scrum團隊的技術（團隊多於12人，被劃分5～10人一組的Scrum小組）。
每個小組都選出一名代表成員去參加所在團隊的每日會議。根據不同團隊的需求，根據不同團隊的需求，
這些代表可以是工程師或ScrumMaster。通過SoS會議達到小組之間的資訊同步，解決問題的目的。
SAFe: The Scaled Agile Framework是一個企業及的敏捷管理框架，適用於管理大型的Scrum團隊。
SAFe框架提供了三層管理模型，分別由專案組合，專案集，實施團隊構成。
1.6 敏捷怎麼工作
1.建立一個人物列表
專案組需要和產品負責人一起討論，並且由產品負責人建立一個關於‘Scrum電子任務板’應包括的功能列表。在這裡我們使用使用者故事來描述這些功能，我們稱每一個要完成的功能為一個使用者故事。
2.給任務標記工作量大小
使用敏捷的估算技術，給這些故事彼此之間相對的任務大小並且估算完成這些故事需要的時間。
3.給故事設定優先順序
專案組需要和產品負責人確認每一個故事的優先順序，以便保證一直處理高優先順序的任務。
4.開始執行
5.根據專案實際情況更改計劃
在專案的進行中，團隊先後碰到以下兩種情況。 （1）專案進行的比預期的要快。（2）有太多事情要做，時間不夠用 此時，專案組可以有以下兩個選擇。 （1）少做一些，縮減一部分功能範圍（推薦做法）。 （2）加緊做，加班也要完成。
1.7 敏捷和瀑布模型的區別
瀑布模型是一個迭代模型，一般情況下將其分為計劃，需求分析，概要設計，詳細設計，編碼以及單元測試，測試，執行維護幾個階段。瀑布模型的迭代是環環相扣的，每個迭代中互動點都是一個里程碑，上一個迭代的結束需要輸出結果作為下一個迭代的輸入。這樣，當某一個階段出現了不可控的問題的時候，就會導致返工，返回到上一個階段，甚至會延遲下一個階段。
瀑布模型的弊端：
1.質量不高 當發現專案已經沒有錢和時間的時候，測試已經成為唯一剩下的還沒有做的事情。這就意味著專案必須剪掉測試的時間和預算，因此，產品質量就必須定出問題。 2.可見性不高 因為直到專案的最後才能看到產品，在瀑布模型的專案裡，你永遠不知道你真正在哪。專案的最後20%經常花費80%的時間。 3.太多風險 在專案一開始你就有風險：首先，你有時間安排上的風險，因為你永遠不知道專案會在什麼時候完成；接下來，你有技術上的風險，
因為你只有在專案的最後測試階段才會知道你的設計和架構問題；最後你還有產品上的風險，因為你根本不知道是否開發一個正確的產品，
直到專案的後期無論做什麼任何變化都已經太晚了。 4.無法應對變化 瀑布模型是環環相扣的迭代模型，是無法應對變化的。
敏捷有以下特點：
1，需求分析，設計，編碼和測試的工作是持續進行的。 2，產品開發過程是迭代的。 3，計劃更加靈活，可以調整 4，專案成員為了同一個目標努力，做出力所能及的奉獻；而不強調‘角色’的分工和明確的職責劃分。 5，擁抱變化，及時調整。 6，交付可工作的軟體是最重要的衡量專案是否成功的標誌。
1.8 什麼是Scrum
Scrum是一個框架，在此框架中人們可以解決複雜的自適應難題，同時也能高效並創造性地交付儘可能高價值的產品。Scurm作為一個框架，它的最大特點就是迭代和增量。專案以一個迭代接著一個迭代的方式運轉，麼哥迭代的產出就是產品增量。在迭代當中，專案組每天都進行檢查和調整。每個迭代的工作內容就是實現產品列表上的功能。
Scrum的工作方式：在每一個迭代開始的時候，Scrum團隊找出他們要做的產品列表條目。然後開始在這些條目上工作。並且在迭代結束的時候完成這些條目成為潛在可釋出的產品增量。在日常開發中，我們經常定義迭代名為Sprint 1, Sprint 2,...Sprint N,這裡Sprint就是衝刺的意思。
Scrum大概會如下面過程：
衝刺工作前的工作 （1）組建Scrum團隊。 （2）首先確定衝刺長度是兩週。 （3）準備好產品列表。 衝刺當中的工作 （1）計劃：團隊從產品列表中選擇優先順序最高的一兩個（具體取決於團隊能力和故事的難度）使用者故事。 （2）工作於計劃的使用者故事（）召開每日站會以便隨時進行檢視和調整 （3）在衝刺結束前完成這些功能，提交潛在可釋出的增量（也許立即釋出，也許以後釋出，什麼時候釋出取決於產品釋出策略）。 （4）召開評審和回顧會議。
1.9 Scrum框架
Scrum通過三個角色----產品負責人，ScrumMaster，開發團隊----來完成一系列的流程：計劃會議，每日站會，評審會議，回顧會議，工件，產品列表，衝刺列表，潛在可交付產品增量以實現迭代，增量開發。
產品負責人是有授權的產品領導力核心，一方面他擔任著產品經理的角色以確保能開發出正確的解決方案，另一方面他還必須和開發團隊交流以保證
特性的接受標準有明確的說明（使用者故事）並且已經滿足後續需要執行測試驗收的標準，以確保特性完成（業務分析師和測試人員的部分工作）。
這個角色責任重大，負責構建正確的產品。
ScrumMaster負責幫助每個人理解並樂於接受Scrum的價值觀，原則和實踐。對於團隊和產品負責人來說，ScrumMaster履行的是教練，
過程領導的職責。他負責幫助團隊和組織其他成員發展具有組織特色的高效的Scrum方法。
開發團隊是主任工程師，開發，測試工程師，資料庫管理員，介面設計工程師和其他傳統軟體開發方法當中定義的不同工作型別的
所有型別的人的跨職能的集合。開發團隊負責用正確的方法構建產品。
衝刺（Sprint）是Scrum的核心，它的持續時間為一個月或者更短（兩週時間最為普遍），在這段時間內構建產品增量。
在整個開發過程中，Sprint的長度都應儘量保持一致。前一個Sprint結束後，下一個Sprint緊接著立即開始。
潛在可釋出產品增量：在衝刺結束時，團隊應當得到一個潛在可釋出的產品或者產品增量。如果業務上合適，就可以釋出；
如果不合適在每次衝刺後釋出，可以把多個衝刺的一組特性合併在一起釋出。
產品列表：是一個優先順序排序的，有粗略估算的，成功開發產品所需特性及其它功能的列表。在產品列表的指導下，
我們總是優先做優先順序最高的條目。換句話說就是，當一個衝刺完成時，已完成的條目都是優先順序最高的。
衝刺計劃會： 一般情況下，產品列表中的工作量遠遠不是一個短期衝刺內能夠完成的。所以衝刺開始的，
團隊需要定製計劃，說明一下衝刺中要建立產品列表中的哪幾個高優先順序的特性（生產Spint列表）。
Sprint列表（也稱待辦列表）：是一組當前Sprint選出的產品待辦列表項，同時加上交付產品增量和實現
Scrum目標的計劃（包括每個待辦列表項完成所需的估算等）。
衝刺評審會和回顧會：在衝刺結束時，團隊與利益干係人一起評審已經完成的特性，獲得它們的反饋產品負責人和
團隊既可以對下一步工作內容進行修改（在評審會上），也可以修改以前的工作方式（在回顧會議上）。評審會議，
如果利益干係人在看到一個完成特性時，意識到自己沒有考慮到另一個必須包含在產品中的特性。此時，
產品負責人只要建立一個代表該特性的新條目，並把它以適當的順序插入到產品列表，留到後面的衝刺中完成。
回顧會上，如果開發團隊在回顧衝刺過程中，意識到自己沒有考慮到依賴風險導致開發過程不必要的等待時，
開發團隊可以提出下一個衝刺計劃會上考慮依賴風險並做好相應的控制。
每日站會是整個Scrum裡面非常有特色的一個會議。開發團隊一個限制在15分鐘內的會議。名副其實，
每日站會需要每天都舉行。這個會議的目的是實現開發團隊每天對完成Sprint目標的進度和
Sprint待辦列表的工作進度趨勢的檢視，並且作出相應的調整和適應。
ScrumMaster在正式開始Sprint 1之前和團隊一起確認了Sprint的長度，開始和結束時間，各個會議的具體時間和與會人員，產品列表和Sprint列表中所應該包括的內容等。在Sprint 1 開始的第一天，SM按照與大家約定組織召開專案組的第一個會議。在會議上，產品負責人向開發團隊解釋了產品列表當中優先順序最高的幾個使用者故事，並且表示這些使用者故事是他希望可以儘快完成的功能。在會議上，開發團隊的工程師們向產品負責人提出使用者故事對應的一些功能性的問題。在對功能清晰以後，SM指導開發團隊開始對每一個使用者故事的工作量進行估算。SM幫助大家澄清如何才能進行正確的估算，估算後的結果如何記錄，估算和實際工作量之間的關係等問題。
下面是一份團隊轉型的評估要素：
1 表示完全不不符合 6 表示完全符合
分數< 27: 專案不適合轉型
27<分數<40:專案適合轉型
分數>40:專案非常適合轉型
對於第7點的解釋：如果以前的專案做的很糟糕，感覺已經無藥可救，那麼轉型帶來的變化再在糟糕也不會比以前糟糕了，所以說在這種團隊非常適合轉型。
對於第8點的解釋：因為試點團隊的轉型對公司未來整體轉型具有重要意義，所以我們建議一定要在重點專案上進行試點，這樣才能暴露問題。在非重要專案中進行轉型，無法積累足夠的經驗，也就無法引起足夠的重視。
1.10 實踐類問題
1.10.1 我可以同時實踐Scrum和PRINCE2嗎
PRINCE2是一個過程驅動的專案管理方法論。它是基於7個基本原則的：持續的業務驗證，經驗學習，角色與責任，按階段管理，例外管理，關注產品，根據專案環境剪裁。PRINCE2關注於專案的計劃和控制。推薦《敏控創變》講解柔實踐Scrum和PRINCE2。
1.10.2 Scrum是否可以部分應用
Scrum就像下國際象棋要麼遵守遊戲規則，要麼不遵守。如果只使用部分Scrum管理專案，那就不叫Scrum專案。不建議公司對Scrum團隊定製太多的“流程”，“規定”，“標準”，只要Scrum團隊按照《Scrum指南》裡的各部分去做就好，應該儘量給各個團隊留下足夠的管理空間。
1.10.3 我什麼時候不能用Scrum
1.當你的專案不用Scurm也能執行的很好的時候 2.當團隊跨國或者有外包參與的時候，Scrum就很難管理了 3.一些對需求很清晰的專案，也不必非要使用Scrum
1.10.4 Scrum可以在大型組織中實踐嗎
通常在大型組織中最大的阻礙就是人們拒絕任何改變。很多人都不相信Scrum真的對組織有用。大多數的組織都認為自己很特別，Scrum的規則不適用於他們。另外一些你可能聽到爭議是：質量控制對我們執行Scrum太重要了，我們的專案太複雜了以至於不能Scrum，高管不支援Scrum。。。在種時候，最好的辦法是嘗試從很小的變動開始，證明變化有效，然後慢慢推廣。所以，在大型組織中推廣Scrum容易嗎？當然不，但是可以在大型組織可以推廣Scrum嗎？當然可以～
1.10.5 Scrum是一個框架不是一個方法
框架和方法之間的差別就在於，方式是一個防止四海皆准的，格式化的途徑，就好比PRINCE2，PMP都是方法；但是框架相比之下就更靈活，它是一個平臺，根據環境的不同，它可以提供一系列不同的途徑。對於Scrum框架來說，遵守它的規則是最重要的。而它的所有規則都在《Scrum指南》當中。
到此敏捷Scrum入門相關的知識介紹完了～～