這篇文章，我將會去簡單探討為什麼需要敏捷？

    先貼出連結，如果你有時間的話，可以考慮仔細看看：The New Methodology (Martin Fowler's description of the background to agile methods)

1. 軟體工程從無開始，到重量級開發，再到輕量級開發（敏捷）

    軟體開發最原始是啥都沒有的，就如同我們大學做第一個大作業差不多的情況（自己寫的，而不是網上下載的那種），只知道一個大體的目的，混亂的程式碼拼接，越做Bug越多，而且很難排查。預計一個通宵能完成的，結果花了一個周的通宵也還沒讓程式執行起來。

    然後引薦了傳統工程上的計劃驅動方法，制定了嚴格的、詳細的開發過程（參考瀑布型開發流程）。據Martin介紹，這個方式最常見的批評就是，每一步都很繁瑣，都需要做大量工作，而且有些工作最後發現是無用的，甚至偏離目標，最後導致，開發的預期和實際相差過大。當然，我認為這東西既然存在，肯定在早期對軟體開發也起到了相當大的貢獻，哪會一無是處。

    而敏捷開發的提出，就是對傳統開發模式的反叛。反叛之處在於，它推崇更少的開發步驟，靈活的開發過程，不需要詳細的文件說明，推崇原始碼即文件。核心特點就是：一是，敏捷是自適應的，基於的思想就是，不可知論（我們開發的一切行為都不一定是最貼近目標產品的），而我們需要時刻檢查和保證開發的方向在可控的範圍類。產品的需求也是會有變化的，因為軟體這種虛無的東西，不同於傳統工程，不可能一開始就是清晰的。二是，對於軟體來說，開發團隊的技能才是起決定作用的，而不是一個開發流程，即軟體開發是面向人的，而不是面向過程的。

我也不是很清楚第二個特點的含義，是否說的是？軟體的成功與否，更加依賴所工作的人員，而不是依賴一個詳盡的流程？我的想法應該是，軟體開發更應該鼓勵一個開發人員用一個創造性、適應性的方式去開發軟體，

2. 傳統工程是預見性的建造，而軟體應該是適應性的創造

    傳統工程，例如橋樑建造，設計費用一般佔整個工程的10％， 左右，餘下的90％左右為施工建造費用。在一個大型專案中，編碼佔據軟體開發總時間的10％，而編碼過程中真正寫程式碼的時間只是佔用編碼過程的10%。什麼意思呢？你真正寫生產程式碼的時間只是佔用軟體開發總時間的1%，這是一個恐怖的事實。軟體開發是一個創造性的過程。需求分析，各種設計，各種測試等等已經佔用了90%的時間。而編碼的時候，理解需求，看懂原有程式碼又花了90%（保守的不能再保守的比例了，據某個敏捷教練說，光看原有程式碼已經佔用90%的時間了）。簡而言之，基於傳統工程的計劃驅動方法並不是軟體開發的最佳解決方案。

3. 一般情況下，需求是不可預見的

    需求總會變的。不解釋了，自己體會。所以不可能一開始就能決定軟體的最終細節。

4. 用迭代來控制不可預見

    通過快速迭代的方式，最快的速度適應需求的變化。迭代不是沒計劃，而且小而明確的目標。參考迭代開發模型，當然它只是一個模型，並不是實際解決方案。

5. 面向人的管理

    通過開發人員去自適應地、自發性地去開發，比起工廠式、流程化的過程管理，更容易進行迭代開發。因為IT行業的技術變化速度非常之快，管理層的技術技能（如果有）也會很快就會過時的。

6. 業務專家的引領

    參考領域驅動設計的思想，我就不解釋了，我也不大明白。但有一點的清晰的，技術人員不可能啥事都幹得了，在業務領域，需要和相關領域專家持續地溝通，不斷地獲取專門知識，共建一個領域模型作為軟體的參考。

7. 極限程式設計（XP）

       極限程式設計是敏捷的一個很好的實踐（不知道說最佳有沒有太過）。也已經過很多專案的驗證，極限程式設計的很多實踐已經被敏捷開發作為標準了。XP五條基本價值觀：交流，反饋，簡潔，勇氣和尊重。介紹部分實踐：結對程式設計，測試驅動開發，持續重構和持續優化，簡單的設計，單元測試先行, 程式碼稽核(code review)。

8. 該不該走向敏捷

    走向敏捷是必須的，但不是所有人都會使用，包括我。但必須根據所在環境去適應，如果大家都排斥，強推就失去了敏捷的意義。也不可能一下就能用好所有好的實踐，可以慢慢地試著轉變。走向敏捷存在阻力: 1.很多程式設計師本身熱愛技術, 但忽視了一個專案的成功很大程度上也取決於開發管理. 2. 管理層沒有敏捷的想法, 甚至於排斥它. 3. 客戶的認同