敏捷開發是軟件開發行業的熱門詞彙之一，它是管理軟件開發項目的另一種方式。它不是一種特定的軟件開發方法，而是一組基于敏捷方法中所表達的價值觀和原則的方法和實踐的統稱，解決方案是通過自組織，跨職能的團隊之間的協作來發展的。
敏捷是一個用來描述強調增量交付、團隊協作、持續規劃和持續學習的軟件開發方法的術語，而不是試圖在項目接近尾聲時一次性交付所有內容。
敏捷側重于保持過程精益，並創建在最終實現之前經過多次叠代的最小可行産品(MVPs)。反饋被不斷地收集和執行，總的來說，這是一個更加動態的過程，每個人都朝著一個目標共同努力。
敏捷開發
Scrum和其他領先的敏捷方法
- 敏捷是一種思維方式，是一套價值觀和原則。
- 敏捷是一種思考和行動的方式。
- 敏捷是涉及短周期、叠代和增量交付、快速失敗獲得反饋、盡早向客戶交付業務價值以及有關人員協作、交互的一種開發方式。
- 敏捷是一種關于透明度、檢查和適應的思維方式。
然而，敏捷並不包含任何角色、事件或工件。例如，Scrum是敏捷保護傘下被廣泛使用的框架之一，它可以幫助你變得更加敏捷，然而在敏捷運動中還有更多的框架，如看板、XP、Crystal等，如下圖所示：
Scrum敏捷傘
Scrum
Scrum是一個框架，在這個框架中，人們可以解決複雜的適應性問題，同時高效、創造性地交付最高價值的産品。它用于管理軟件項目、産品或應用程序開發。它的重點是自適應産品開發策略，其中跨職能團隊作爲一個單位，在2-4周內(Sprint)達到一個共同的目標。它由價值、工件、角色、儀式、規則和最佳實踐組成。
Lean
精益源自豐田生産系統(TPS)，該系統在20世紀50年代、60年代及以後掀起了制造行業的革命。精益技術在制造業中占有一席之地，幫助各行各業消除浪費、改進流程並促進了創新。軟件開發是精益方法的自然應用，因爲它與制造非常相似，通常遵循一個已定義的過程，有一些已定義的驗收條件，並導致有形價值的交付。指導精益方法的所有實踐的關鍵概念，我們稱爲精益支柱。他們是：
- 持續改進
- 尊重員工
- 輕量級的領導
看板
看板是一種高度可視化的工作流管理方法，在精益團隊中很流行。實際上，83%的實踐精益的團隊使用看板來可視化和積極地管理産品的創建，強調持續的交付，而不是給開發團隊增加過多的負擔。與Scrum一樣，看板是一個旨在幫助團隊更有效地協作的過程。
看板基于以下三個基本原則：
- 可視化你今天要做什麽（工作流程）：在彼此的上下文中查看所有項目是非常有用的
- 限制進行中的工作量（WIP）：這有助于平衡基于流程的方法，這樣團隊就不會一次開始和提交過多的工作
- 增強流程:當某件事完成時，待辦事項列表中優先級第二高的項就會被拉進來發揮作用
看板通過定義最好的團隊工作流程，促進持續的協作，鼓勵積極的、持續的學習和改進。
動態系統開發方法（DSDM）
DSDM是一個由8個原則、一個生命周期和産品、角色和職責以及一些最佳實踐技術組成的框架。這些支持盡早交付戰略上一致的業務利益理念，從而爲組織提供最佳的投資回報(ROI)。
DSDM是一種將進度和質量優先級置于功能之上的方法，它在一開始就確定了成本、質量和時間，並使用MoSCoW方法確定了優先級，該方法將項目分解爲四種不同類型的需求：
- 必須（M）
- 應該（S）
- 可能（C）
- 沒有（W）
有八個原則支持DSDM Atern。這些原則指導團隊必須采取的一致的態度和思維方式，以便盡快交付。
- 專注于業務需求
- 及時交付
- 協作
- 永不妥協的品質
- 從穩固的基礎上逐步構建
- 叠代式開發
- 持續而清晰地溝通
- 展示控制力
極限編程
最初由Kent Beck描述的極限編程(XP)已經成爲最流行、最具爭議的敏捷方法之一。XP是一種紀律嚴明的快速、持續地交付高質量軟件的方法。它的目的是在面對客戶需求變化時提高軟件質量和響應能力。它促進了客戶的高度參與，快速的反饋循環，持續的測試，持續的計劃，以及緊密的團隊合作，以非常頻繁的間隔交付工作軟件，通常是每1-3周。
該方法的名字來源于將傳統軟件工程實踐的有益元素帶到“極端”水平的想法。例如，代碼審查被認爲是有益的做法。更極端的是，可以通過結對編程的實踐來連續檢查代碼。
最初的XP方法基于四個簡單的價值觀:簡單、溝通、反饋和勇氣。
它還有12個配套實踐：
- 計劃項目
- 短時發布
- 客戶驗收測試
- 簡化設計
- 結對編程
- 測試驅動開發
- 代碼重構
- 持續集成
- 程式碼共有
- 代碼規範
- 隱喻
- 可持續的開發節奏
極限編程
功能驅動開發（FDD）
功能驅動開發（FDD）是傑夫·德盧卡（Jeff De Luca）1997年爲一家大型新加坡銀行進行軟件開發項目時引入的。它是一種叠代的、增量的軟件開發過程，是一種敏捷的軟件開發方法。FDD將許多業界公認的最佳實踐融合在一起。這些實踐是從客戶重視的價值功能(特性)的角度出發的。它的主要目的是及時地重複交付有形的、可工作的軟件。使用FDD的優勢在于，它甚至可以擴展到大型團隊，因爲它的概念是“剛開始就足夠的設計”(JEDI)。由于它以功能爲中心，因此它是保持對敏捷，增量和固有複雜項目的控制的絕佳解決方案。它包含五個基本活動：
- 開發整體模型
- 構建功能列表
- 按功能規劃
- 按功能設計
- 按功能構建
功能驅動開發（FDD）
每個項目都有自己獨特的模型，這將産生一個獨特的功能列表。最後三個活動是簡短的叠代過程，其特性的構建時間不會超過兩周。如果要花費兩周以上的時間，則必須將其分解爲較小的功能。
Crystal
Crystal方法是由Alistair Cockburn在90年代中期開發的一個方法論系列Crystal系列)。這些方法來自于Cockburn多年的研究和對團隊的訪談。Cockburn的研究表明，他采訪的團隊沒有遵循正式的方法論，但是他們仍然交付了成功的項目。Crystal系列是Cockburn對他們所做的使項目成功的事情進行分類的方式。方法論重點包括：
- 人
- 交互作用
- 社區
- 技能專長
- 人才專長
- 通訊技術
敏捷方法
“敏捷”一詞是2001年在《敏捷宣言》中提出的。宣言旨在建立指導更好的軟件開發方法的原則。敏捷宣言由4個重要的價值觀組成。閱讀敏捷宣言的方式並不是說右邊的項目已經沒有價值了，而是敏捷運動更加重視左邊的項目。
敏捷方法
讓我們看一下敏捷方法的第一行。這句話表明，我們重視人員的互動，溝通和協作，而不是擁有各種各樣的廣泛的流程和工具。當然，程和工具很有價值，但是，如果它們能夠真正地支持人們一起工作並交付出色的産品，那麽它們就更有價值。我們現在在許多組織中看到的是，流程和工具本身就是目標。從敏捷的角度來看，我們對它的期望是不同的。過程和工具應該支持人們一起工作並向客戶交付價值。
敏捷方法原則
作爲敏捷方法的補充，敏捷聯盟還定義了12條基本原則，除了敏捷方法之外，這些原則還提供了指導和更詳細的解釋。
敏捷方法原則
- 我們的首要任務是通過盡早並持續交付有價值的軟件來滿足客戶。
- 即使在開發後期，也歡迎不斷變化的需求。敏捷流程利用變更來獲得客戶的競爭優勢。
- 頻繁交付工作軟件，從幾周到幾個月不等，優先選擇較短的時間尺度。
- 在整個項目中，業務人員和開發人員必須每天一起工作。
- 圍繞有積極性的個人構建項目。給他們需要的環境和支持，並信任他們能完成工作。
- 在開發團隊中傳遞信息的最有效的方法是面對面的對話。
- 可工作的軟件是進度的主要度量。
- 敏捷過程促進可持續開發。
- 發起人，開發者和用戶應該能夠無限期地保持一個恒定的步調。
- 持續關注技術卓越和良好的設計可提高敏捷性。
- 簡潔性（最大化未完成工作量的藝術）至關重要。
- 最好的架構、需求和設計來自自組織的團隊。團隊會定期思考如何提高效率，然後相應地調整其行爲。