敏捷開發
前言
迭代開發
敏捷開發的核心是迭代開發（iterative development）。敏捷一定是採用迭代開發的方式。那麼什麼是"迭代開發"呢？迭代的英文是 iterative，直譯爲"重複"，迭代開發其實就是"重複開發"。
對於大型軟件項目，傳統的開發方式是採用一個大週期(比如半年)進行開發，整個過程就是一次"大開發"；迭代開發的方式則不一樣，它將開發過程拆分成多個小週期，即一次"大開發"變成多次"小開發"，每次小開發都是同樣的流程，所以看上去就好像重複在做同樣的步驟。
舉例來說，SpaceX 公司想造一個大推力火箭，將人類送到火星。但是，它不是一開始就造大火箭，而是先造一個最簡陋的小火箭 Falcon 1。結果，第一次發射就爆炸了，直到第四次發射，才成功進入軌道。然後，開發了中型火箭 Falcon 9，九年中發射了70次。最後，纔開發 Falcon 重型火箭。如果 SpaceX 不採用迭代開發，它可能直到現在還無法上天。
迭代開發將一個大任務，分解成多次連續的開發，本質就是逐步改進。開發者先快速發佈一個有效但不完美的最簡版本，然後不斷迭代。每一次迭代都包含規劃、設計、編碼、測試、評估五個步驟，不斷改進產品，添加新功能。通過頻繁的發佈，以及跟蹤對前一次迭代的反饋，最終接近較完善的產品形態。
增量開發
迭代開發只是要求將開發分成多個迭代，並沒有回答一個重要的問題：怎麼劃分迭代，哪個任務在這個迭代，哪個任務在下個迭代？這時，一般採用"增量開發"（incremental development）劃分迭代。
所謂的"增量開發"，指的是軟件的每個版本，都會新增一個用戶可以感知的完整功能。也就是說，按照新增功能來劃分迭代。
舉例來說，房地產公司開發一個10棟樓的小區。如果採用增量開發的模式，該公司第一個迭代就是交付一號樓，第二個迭代交付二號樓…每個迭代都是完成一棟完整的樓。而不是第一個迭代挖好10棟樓的地基，第二個迭代建好每棟樓的骨架，第三個迭代架設屋頂…
增量開發加上迭代開發，纔算是真正的敏捷開發。
敏捷開發的好處
早期交付
敏捷開發的第一個好處，就是早期交付，從而大大降低成本。
還是房地產公司爲例，如果按照傳統的"瀑布開發模式"，先挖10棟樓的地基、再蓋骨架、然後架設屋頂，每個階段都等到前一個階段完成後開始，可能需要兩年才能一次性交付10棟樓。也就是說，如果不考慮預售，該項目必須等到兩年後才能回款。
敏捷開發是六個月後交付一號樓，後面每兩個月交付一棟樓。因此，半年就能回款10%，後面每個月都會有現金流，資金壓力就大大減輕了。
降低風險
敏捷開發的第二個好處是，及時瞭解市場需求，降低產品不適用的風險。
請想一想，哪一種情況損失比較小：10棟樓都造好以後，才發現賣不出去，還是造好第一棟樓，就發現賣不出去，從而改進或停建後面9棟樓？
對於軟件項目來說，先有一個原型產品，瞭解市場的接受程度，往往是項目成功的關鍵。有一本書叫做《夢斷代碼》，副標題就是"20+個程序員，三年時間，4732個bug，100+萬美元，最後失敗的故事"，這就是沒有采用敏捷開發的結果。相反的，Instagram 最初是一個地理位置打卡 App，後來發現用戶不怎麼在乎地理位置，更喜歡上傳照片，就改做照片上傳軟件，結果成了獨角獸。
由於敏捷開發可以不斷試錯，找出對業務最重要的功能，然後通過迭代，調整軟件方向。相比傳統方式，大大增加了產品成功的可能性。如果市場需求不確定，或者你對該領域不熟悉，那麼敏捷開發幾乎是唯一可行的應對方式。
如何進行每一次迭代
雖然敏捷開發將軟件開發分成多個迭代，但是也要求，每次迭代都是一個完整的軟件開發週期，必須按照軟件工程的方法論，進行正規的流程管理。
&emssp;具體來說，每次迭代都必須依次完成以下五個步驟。
- 需求分析（requirements analysis）
- 設計（design）
- 編碼（coding）
- 測試（testing）
- 部署和評估（deployment / evaluation）
每個迭代大約持續2~6周。
敏捷開發的價值觀
《敏捷軟件開發宣言》裏面提到四個價值觀。
- 程序員的主觀能動性，以及程序員之間的互動，優於既定流程和工具。
- 軟件能夠運行，優於詳盡的文檔。
- 跟客戶的密切協作，優於合同和談判。
- 能夠響應變化，優於遵循計劃。
十二條原則
該宣言還提出十二條敏捷開發的原則。
- 通過早期和持續交付有價值的軟件，實現客戶滿意度。
- 歡迎不斷變化的需求，即使是在項目開發的後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
- 不斷交付可用的軟件，週期通常是幾周，越短越好。
- 項目過程中，業務人員與開發人員必須在一起工作。
- 項目必須圍繞那些有內在動力的個人而建立，他們應該受到信任。
- 面對面交談是最好的溝通方式。
- 可用性是衡量進度的主要指標。
- 提倡可持續的開發，保持穩定的進展速度。
- 不斷關注技術是否優秀，設計是否良好。
- 簡單性至關重要，盡最大可能減少不必要的工作。
- 最好的架構、要求和設計，來自團隊內部自發的認識。
- 團隊要定期反思如何更有效，並相應地進行調整。