以下敏捷系列博客均為在學習過程的的筆記，只作為學習使用，不用作其他用途，特此聲明。
一、什么是敏捷？
從本質上講，敏捷（Agile）並不是一種開發方法，而是一種理念。對於項目管理而言，敏捷是一個全新的術語，敏捷強調在軟件研發過程中持續性的根據用戶反饋和需求優先級來發布新版本，不斷進行迭代，讓產品逐漸完善。
在數十年前，瀑布式項目管理是軟件研發的主流方法，在研發過程中，團隊成員將會花大把的時間和精力在項目前期去收集資源和信息，然后基於這些去做產品設想和研發規划。到了70年代，有先覺的研發人員發現瀑布式研發不僅在執行中各處受限，研發速度還很慢，顯然Out了。尤其到了90年代末期，開始出現黑客來搗亂，這就意味着前功盡棄、全部推倒重來，這簡直是研發的噩夢。
相比瀑布基於線性、可預測性地去開發產品，研發人員更想要能夠靈活管理用戶反饋、Bug和需求的方法。這也就是敏捷方法出來以后受歡迎的原因。
2001年2月11日至13日，在美國猶他州瓦薩奇山雪鳥滑雪勝地，17個人聚到一起交談、滑雪、休閑，當然還有聚餐。參會者們包括來自於極限編程、Scrum、DSDM、自適應軟件開發、水晶系列、特征驅動開發、實效編程的代表們，還包括了希望找到文檔驅動、重型軟件開發過程的替代品的一些推動者。他們試圖找到共識，最終的成果就是《敏捷軟件開發宣言》（Manifesto for Agile Software Development），如下圖所示：
可以總結為：
- 以人為本：重視個體間的合作互動
- 目標導向：我們最終交付的是“可使用的軟件”，而不是一堆繁重的文檔
- 客戶為先：理解客戶需求，與客戶合作
- 擁抱改變：客戶會在不斷變化需求的過程中明晰真正需要的，因此敏捷需要擁抱變化。
盡管如此，這四項價值觀並不意味着我們就該放棄工具、文檔和計划。因為它們對研發結果依然有非常重要的價值，只是相比之下，我們應該關注更核心的事物：人、產品模型、協作和迭代。
為了讓這四項原則變得簡單易懂好執行，他們又寫了敏捷開發12項原則作為指導：如下圖所示：
1、我們最優先要做的是通過盡早的、持續的交付有價值的軟件來使客戶滿意。
規划迭代故事時必須按照優先級安排，為客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷小組關注完成和交付具有用戶價值的功能，而不是孤立的任務。以前我們都用需求規格說明書或者用例來編寫詳細的需求，敏捷使用用戶故事來羅列需求。用戶故事是一種表示需求的輕量級技術，它沒有固定的形式和強制性的語法。但是有一些固定的形式可以用來參考還是比較有益的。敏捷估算中使用了這個模板：“作為【用戶的類型】，我希望可以【能力】以便【業務價值】“。使用基於用戶故事的需求分析方法時，仍可能需要原型和編寫文檔，只是工作重點更多的轉移到了口頭交流。
2、即使到了開發的后期，也歡迎改變需求。敏捷過程利用變化來為客戶創造競爭優勢。
敏捷過程參與者不怕變化，他們認為改變需求是好事情，因為這些改變意味着我們更了解市場需求。
3、經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
迭代是受實踐框架限制的，意味着即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟件可以很好的工作，那么交付時間越短，我們和客戶協作就越緊密，對產品質量就更有益。雖然我們多次迭代，但並不是每次迭代的結果都需要交付給用戶，敏捷開發的目標是讓他們可以交付。這意味着開發小組在每次迭代中都會增加一些功能，增加的每個功能都是經過編碼、測試，達到了可發布的質量標准的。
另外敏捷開發項目中對開發階段沒有什么重要的分割，沒有先期的需求階段，然后是分析階段，架構設計階段，編碼測試階段等，在項目真正開始后，每次迭代中都會同時進行所有的上述階段工作。
4、在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
軟件項目不會依照之前設定的計划原路執行，中間對業務的理解、軟件的解決方案肯定會存在偏差，所以客戶、需求人員、開發人員以及涉眾之間必須進行有意義的、頻繁 的交互，這樣就可以在早期及時的發現並解決問題。
5、圍繞被激勵起來的個人來構建項目。給他們提供所需要的環境和支持，並且信任他們能夠完成工作。
業務和技術是引起不確定的二個主要方面，人是第三個方面。而業務和技術又必須由人來執行，所以能夠激勵人來解決這些問題是解決不確定性的關鍵。只要個人的目標和團隊的目標一致，我們就需要鼓舞起每個人的積極性，以個人為中心構建項目，提供所需的環境、支持與信任。
6、在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。
在十幾或者二十幾個人組成的大團隊中，文檔是一種比較合適的傳遞知識和交流的途徑。而敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），所以大量的文檔交流其實並不是很經濟的做法。此時面對面的交談反而更快速有效。
7、工作的軟件是首要進度度量標准。
一般的工作都比較容易衡量任務進展，比如讓你去搬運1噸的石頭，我只要去稱一下你已經搬運的石頭重量就知道你完成多少了。而對於軟件來說，在軟件沒有編碼、測試完成之前，我們都不能因為代碼編寫了多少行，測試用例跑了多少個就去度量這個功能是否完成了。衡量這個功能是否完成的首要標准就是這個功能可以工作了，對用戶來說已經可以應用了。
8、敏捷過程提倡可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。
很多人都認為軟件開發中加班是很正常的，不加班反而不正常，我對此有點不理解，這個可能是國情所致吧。敏捷過程希望能夠可持續的進行開發，開發速度不會隨着迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態度，開發工作不應該是突擊行為。我們不能指望說突擊這個項目后就可以輕松了，因為完成一個項目后會接踵而來下一個項目，而只要還是拼拼的態度，下一個項目依舊會讓你的組員再次突擊。這時不知道有人會不會說，那我們就一直加班，也是“持續的開發速度”啊，這時可要注意了，持續加班只會導致人疲勞、厭倦，保持長期恆定的速度也只是一種理想而已。
9、不斷地關注優秀的技能和好的設計會增強敏捷能力。
敏捷過程有很多好的技術實踐可以加強產品敏捷能力，很多原則、模式和實踐也可以增強敏捷開發能力。
10、簡潔為本----極力減少不必要工作量的藝術。
我們不可能預期后面需求會如何變化，所以不可能一開始就構建一個完美的架構來適應以后的所有變化。敏捷團隊不會去構建明天的軟件，而把注意力放在如何通過最簡單的方法完成現在需要解決的問題。這時有人會說，我已經預計到了肯定存在哪些需求擴展點，我們在一開始是否需要考慮呢？這時團隊需要根據自己的理解去決定是否考慮，如果深信在明天發生了這個問題也可以輕易處理的話，那么就最好先不考慮。
11、最好的構架、需求和設計出自於自組織的團隊。
敏捷中有很多種實踐，大家都知道，迭代式開發是主要的實踐方法，而自組織團隊也是主要的實踐之一。在自組織團隊中，管理者不再發號施令，而是讓團隊自身尋找最佳的工作方式來完成工作。要形成一個自組織團隊其實比較難。自組織團隊的第一個要素就是必須有一個團隊，而不僅僅是一群人。一群人是一幫在一起工作的人，他們彼此之間並沒有太多的溝通，他們也並不視彼此為一體。項目一開始，我們就會組建“團隊”，但很多時候由構架師、需求人員、開發人員和測試人員組成的是一群人而已。他還認為，團隊的形成必須經歷幾個時期。在經歷了初期的磨合后，成員才會開始對團隊共同的工作理念與文化形成一個基本的認識和理解。團隊內會逐漸形成規矩，而且這些規矩是不言而喻的。比如，每個人都知道上午九點來上班，都會主動詢問別人是否需要幫助，也都會去主動和別人探討問題。如果團隊成員之間能夠達成這樣的默契，那么這個團隊將成為一個真正高效的工作團隊。在這樣的團隊中，成員之間相互理解，工作效率非常高。在自組織團隊中，團隊成員不需要遵從別人的詳細指令。他們需要更高層次的指導，這種指導更像是一個目標，一個致力於開發出更好的軟件的目標。總之，自組織團隊是一個自動自發、有着共同目標和工作文化的團隊，這樣的團隊總是在向它的組織做出承諾。但是，實現這些承諾對於自組織團隊來說非常重要。否則，一旦出現問題，團隊成員之間就會出現信任危機。
雖然敏捷開發小組是以小組為整體來工作的，但是還是有必要指明一些承擔一定任務的角色。第一個角色是產品負責人。產品負責人的主要職責包括：確認小組所有成員都在追求一個共同的項目前景，確定功能的優先級以便總是在處理最具有價值的功能，以及作出決定使得對項目的投入可以產生良好的回報。可以對應為以前開發中的“產品經理”。另一角色是跨職能團隊成員，這里包括了架構師、設計師、程序員、需求人員、測試人員、文檔編寫者等。還有一個重要角色就是團隊促進者，也被稱為項目經理、SCRUM主管、項目團隊領導或者團隊教練。敏捷開發的團隊促進者會更多的關注仆人式領導而不是管理。
12、每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應地對自己的行為進行調整。
由於很多不確定性因素會導致計划失效，比如項目成員增減、技術應用效果、用戶需求的改變、競爭者對我們的影響等都會讓我們作出不同的反應。 敏捷不是基於預定義的工作方式，而是基於經驗性的方式，對以上這些變化，小組通過不斷的反省調整來保持團隊的敏捷性。
如果我們把這些原則和遇到的問題對號入座，很快我們就會發現，這12項原則正是對應了客戶期望。比如，客戶不會關心開發文檔寫的怎么樣，他們更感興趣交付的成品能干什么；他們不在意你的開發計划，他們希望你能立馬交付；昨天他們想要修個BUG，而不是等到下次版本更新。
我們總會遇到需求多樣化的客戶，而這時，敏捷能夠確保你在研發過程中始終將用戶需求作為核心。
綜上，那么敏捷到底如何定義呢？
PMI於2018年首次出版《敏捷實踐指南》，本書是美國項目管理協會新發布的敏捷實踐標准，當中對敏捷的描述是：敏捷是一種思維模式，由《敏捷宣言》的4條價值觀所界定，以《敏捷宣言》12原則指導，並通過各種實踐實現，敏捷實踐者根據自身需求選擇不同的實踐。
常用的敏捷實踐有：
Scrum、XP極限編程、水晶、DSDM動態系統開發、FDD功能驅動開發、AUP敏捷統一過程、精益、看板、OpenUP，后面的文章再做詳細介紹。