什麼是敏捷軟件開發？

敏捷是一個術語，用於描述軟件開發的方法，強調增量交付，團隊協做，持續計劃和持續學習，而不是試圖在接近結束時當即交付。

敏捷專一於保持流程的精益，並建立最小的可行產品（MVP），在最終結果出現以前經歷屢次迭代。不斷收集和實施反饋，總而言之，這是一個更加動態的過程，每一個人都在朝着一個目標努力。

Scrum和其餘領先的敏捷方法

敏捷是一種思惟方式，它是一套價值觀和原則。敏捷是一種思考和行動的方式。敏捷就是短週期，迭代和增量交付，快速失敗，得到反饋，及早向客戶提供商業價值，關於人員，協做和互動。敏捷是一種關於透明度，檢查和適應的心態。可是，敏捷不包含任何角色，事件或工件。這是一種心態。例如，Scrum是敏捷傘下普遍使用的框架之一，它能夠幫助你變得更敏捷，但敏捷運動中有更多的框架，如看板，XP，Crystal等等，如圖所示下面：

Scrum

Scrum是一個框架，人們能夠在其中解決複雜的自適應問題，同時高效且創造性地提供具備最高價值的產品。它用於管理軟件項目和產品或應用程序開發。它的重點是適應性產品開發戰略，其中跨職能團隊做爲一個單元在2-4周內達成共同目標（Sprint）。它由一系列價值，文物，角色，儀式，規則和最佳實踐組成。

Lean (精益)

精益起源於豐田生產系統（TPS），它在20世紀50年代，60年代及之後完全改變了實物商品的生產。精益保持其在製造業中的地位，但也在知識工做中找到了新的應用，幫助全部行業的企業消除浪費，改進流程並促進創新。軟件開發是精益方法的天然應用，由於與製造業同樣，它一般遵循一個肯定的過程，具備必定的接受條件，並致使有形價值的傳遞。指導精益方法全部實踐的關鍵概念，咱們稱之爲精益支柱。他們是：

• 連續的提升
• 尊重人
• 輕量級領導

看板 (Kanban)

看板是一種高度可視化的工做流管理方法，在精益團隊中很受歡迎。事實上，83％的精益生產團隊使用看板來可視化並積極管理產品的建立，重點是持續交付，同時不會使開發團隊負擔太重。與Scrum同樣，看板是一個旨在幫助團隊更有效地協同工做的流程。

看板基於3個基本原則：

• 可視化您今天要作的事情（工做流程）：查看彼此上下文中的全部項目能夠提供很是豐富的信息
• 限制正在進行的工做量（WIP）：這有助於平衡基於流的方法，所以團隊沒法啓動並當即承諾過多的工做
• 加強流程：當某些內容完成後，積壓中的下一個最高優先級項目將被激活

看板經過定義最佳的團隊工做流程，促進持續協做並鼓勵積極，持續的學習和改進。

動態系統開發方法（DSDM）

DSDM是一個由八個原則組成的框架，包括生命週期和產品，角色和職責以及幾種最佳實踐技術。這些支撐和支持的理念是儘早提供具備戰略意義的商業利益，從而爲組織提供最佳的投資回報率（ROI）。

DSDM是一種優先考慮計劃和質量而非功能的方法，它在一開始就修復了成本，質量和時間，並使用MoSCoW優先級排序方法，將項目分解爲四種不一樣類型的要求：

• 必須有（Must have）
• 應該有（Should have）
• 能夠有（Could have）
• 不會有（Won't have）

支持DSDM Atern的原則有八個[13]。這些原則指導團隊必須採起的態度和他們必須採起的思惟方式，以始終如一地提供。

1. 專一於業務需求
2. 按時交貨
3. 合做
4. 毫不妥協質量
5. 從堅實的基礎逐步創建起來
6. 迭代開發
7. 持續清晰地溝通
8. 表現出控制力

極限編程

最初由Kent Beck描述的極限編程（XP）已經成爲最受歡迎和最有爭議的敏捷方法之一。XP是一種快速，持續地提供高質量軟件的規範方法。它旨在提升面對不斷變化的客戶需求的軟件質量和響應能力。它促進了高客戶參與度，快速反饋循環，持續測試，持續規劃以及密切的團隊合做，以很是頻繁的間隔（一般每1-3周）提供工做軟件。

該方法的名稱來源於傳統軟件工程實踐的有益元素被帶到「極端」水平的想法。例如，代碼審查被認爲是一種有益的作法。極端狀況下，能夠經過結對編程的實踐不斷檢查代碼。

最初的XP方法基於四個簡單的價值觀 - 簡單，溝通，反饋和勇氣。

它還有12個支持實踐：

• 規劃遊戲 (Planning Game)
• 小版本 (Small Releases)
• 客戶驗收測試 (Customer Acceptance Tests)
• 簡單的設計 (Simple Design)
• 配對編程 (Pair Programming)
• 測試驅動開發 (Test-Driven Development
• 重構 (Refactoring)
• 持續集成 (Continuous Integration)
• 集體代碼全部權 (Collective Code Ownership)
• 編碼標準 (Coding Standard)
• 隱喻 (Metaphor)
• 可持續發展 (Sustainable Pace)

特徵驅動開發（FDD）

功能驅動開發（FDD）由Jeff De Luca於1997年在一家大型新加坡銀行的軟件開發項目中開展。它是一個迭代和增量的軟件開發過程，是一種開發軟件的敏捷方法。FDD將許多業界公認的最佳實踐融合爲一個有凝聚力的總體。這些實踐是從客戶端值的功能（特性）角度推進的。其主要目的是及時反覆提供有形的，有效的軟件。使用FDD的優點在於，因爲「初期設計足夠」（JEDI）的概念，它甚至能夠擴展到大型團隊。因爲其以功能爲中心的流程，它是一個很好的解決方案，能夠保持對敏捷，增量和固有複雜項目的控制。它由五個基本活動組成：

1. 開發總體模型
2. 構建功能列表
3. 按功能規劃
4. 按功能設計
5. 按功能構建。

每一個項目都有本身獨特的模型，這將產生一個功能列表。最後三個活動是短迭代過程，其構建時間不超過兩週。若是它須要兩週以上，那麼它將被分解爲更小的功能。

水晶 (Crystal)

水晶方法是由Alistair Cockburn在20世紀90年代中期開發的一系列方法（Crystal系列）。這些方法來自Cockburn多年的學習和團隊採訪。Cockburn的研究代表，他採訪過的團隊並無遵循正式的方法，但他們仍然提供了成功的項目。Crystal家族是Cockburn對他們所作的事情進行編目的方式，這些項目使項目成功。水晶方法主要關注：

• 人 (people)
• 相互做用 (Interaction)
• 社區 (Community)
• 技能 (Skills)
• 人才 (Talents)
• 通信 (Communications)

敏捷宣言

「敏捷」一詞是在2001年的敏捷宣言中創造的。該宣言旨在創建指導更好的軟件開發方法的原則。敏捷宣言由4個重要的價值觀組成。閱讀敏捷宣言的方式並非右側的物品再也不具備價值，而是敏捷運動更重視左側的物品。

那麼讓咱們來看看敏捷宣言的第一行。這條線代表，咱們重視人，他們的互動，溝通和協做，而不是擁有各類普遍的流程和工具。固然，流程和工具頗有價值，可是，若是它們真正支持人們一塊兒工做並提供優質產品，那麼它們就更有價值。咱們如今在不少組織中看到的是，流程和工具自己就是目標。從敏捷的角度來看，咱們對此有不一樣的見解。流程和工具應該支持人們共同合做併爲客戶創造價值。

敏捷宣言原則

做爲敏捷宣言的補充，敏捷聯盟還定義了一套12項基本原則，除了敏捷宣言以外，還提供了指導和更詳細的解釋：

1. 咱們的首要任務是經過早期和持續交付有價值的軟件來知足客戶。
2. 歡迎不斷變化的要求，甚至是開發後期。敏捷流程利用變化來實現客戶的競爭優點。
3. 常常提供工做軟件，從幾周到幾個月，優先考慮更短的時間尺度。
4. 業務人員和開發人員必須在整個項目中天天一塊兒工做。
5. 圍繞有動力的我的創建項目。爲他們提供所需的環境和支持，並相信他們可以完成工做。
6. 向開發團隊內部和內部傳達信息的最有效和最有效的方法是面對面交談。
7. 工做軟件是進步的主要衡量標準。
8. 敏捷過程促進可持續發展。
9. 贊助商，開發者和用戶應該可以無限期地保持穩定的步伐。
10. 持續關注技術卓越和良好的設計可提升靈活性。
11. 簡單性 - 最大化未完成工做量的藝術 - 相當重要。
12. 最好的架構，要求和設計來自自組織團隊。團隊按期反思如何變得更有效，而後相應地調整和調整其行爲。

摘要

敏捷開發是軟件開發行業的一個流行詞，它是管理軟件開發項目的另外一種方式。它不是特定的軟件開發方法，而是基於敏捷宣言中表達的價值觀和原則的一套方法和實踐的總稱。解決方案經過自組織，跨職能團隊之間的協做發展，利用適合其背景的實踐。

基本的Scrum閱讀

Scrum和自組織團隊 (Scrum and Self-Organizing Team)
敏捷和Scrum - 有什麼區別？
在Scrum Sprint中發佈的頻率是如何肯定的？
經過3個步驟創建自組織團隊
The Best Free Scrum Learning Resources, Guides and Articles
爲何敏捷開發是您項目的更好選擇？
爲何Scrum是 - 快速失敗技術?
8常常被誤解的Scrum Master角色
Scrum Events - 初學者閱讀文章
Scrum在3分鐘內完成

Scrum工件

• 什麼是Scrum工件？
• 完成與接受標準的定義
• Scrum中Ready的定義是什麼？
• 如何寫短距離目標？
• 如何使用MoSCoW方法肯定產品積壓的優先級
• 如何使用100點方法肯定產品待辦事項的優先級？