先寫關鍵字

重點：快速開發、快速交付、快速反饋、溝通大於文件、可執行程式大於文件、響應變化

誤區：可以節省工作量、高質量、文件可以省略、敏捷工具好用、敏捷很簡單

然後來三大關鍵

敏捷是什麼：敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體開發。

敏捷能幹什麼：這個我想了很久，發現還是片面了。敏捷能管理軟體開發過程。能幫助我們管理軟體開發中的很多問題，比如:需求變化，客戶要專案要最後才能看到成果等。

敏捷需要怎麼做：

敏捷當時拿到手的時候我是懵逼的，為啥懵，因為覺得難而且麻煩。直到，看完《大教堂與集市》Eric S. Raymond 的作品，開源運動的聖經。

為啥和開源扯上關係了呢！因為他的開源思想和敏捷根本就是一回事，你看。

1、儘量小的開發任務。  -- 快速開發

2、在可執行的情況下能釋出就釋出。 --快速交付

3、儘快的收集使用者的反饋，並修改。  --快速反饋

然後，敏捷宣言中的幾點

個體和互動 重於 過程和工具。    在開源中，往往都是郵件來郵件去，基本上是沒有流程的，也沒有要求什麼工具。

可執行的軟體 重於 詳盡的文件。  開源專案中，我極少能看到文件。及時有也是事後整理的api說明。設計和需求文件基本上是沒有的。大家都是先去看你的軟體好不好之後再去找你的文件。注意：並不是沒有文件，只是文件的地位沒有那麼高，在有時間整理的情況下，開源也是會去整理文件。實際上這裡我的理解是這樣的：可執行的軟體優於事前規劃的文件。事後的說明性文件和設計文件都是一些必須的東西，不然根本沒辦法交接，過去的程式碼往往會變成雷坑。

 客戶合作 重於 合同談判。    開源有所謂的合同說法麼，工作還不是一樣的做。和客戶鬧的不開心也是影響自己的專案，大家都不好。合同上的東西往往會變成專案的底線，而不是標準。

 響應變化 重於 遵循計劃。   經常性看到開源的東西，今天做這個，明天就砍掉了。這是啥，你說開源沒有計劃麼，並不是，而是會根據實際情況去調整計劃。不要的就不要了，優勢就繼續發揮深度挖掘。

最後使用心得：

敏捷其實最大的好處在於適應變化。需求變化，人員變化，技術變化等等。這些在瀑布式開發中都是無比痛苦的。

其實敏捷還有許多，我都沒有放到關鍵字中比如：測試驅動、持續整合、結對程式設計、極限程式設計等等。

因為我覺得這些都和敏捷關係並不大，如果我用需求驅動（領域驅動、使用者故事驅動）難道就不能用敏捷了麼，我不結對程式設計就不能敏捷了麼。我只有一次整合就不能用敏捷了嗎？一個迭代的敏捷和瀑布式開發也是有根本上的不一樣。

只是，用了這些東西之後，敏捷起來會更舒服，實際上這些東西對任何方式都有很大的幫助。

最後，敏捷除了適應變化之外，還有一個非常重要的一點，那就是持續改進。做任何事都要持續改進！切記切記。

誤區解釋：

敏捷可以節省工作量：其實如果需求沒有任何變動，敏捷其實比瀑布式開發要多花費很多工作量。什麼都是明確的開發起來根本不用猶豫一路到底的感覺當然會快很多。而且即使需求存在變化，敏捷也需要花費很多時間去溝通，調整變化。所以想使用敏捷來節省工作量是不靠譜的。

高質量：敏捷根本無法保證高質量，敏捷沒有任何一個思想可以解決程式碼質量問題，高質量的程式碼還是要看管理。使用測試驅動，結對程式設計才是提高程式碼質量的方式。

文件可以省略：少文件，不代表沒有文件。以需求驅動舉例，在每次迭代之前就需要確定明確的需求。迭代之中出現變化要及時體現在需求文件中。決不能以口頭形式去表達需求。以測試驅動而言，測試案例也是要比程式碼先出來的，寫完程式碼相應的測試程式碼也要出來。再多的註釋和極度良好的命名也沒辦法取代文件。

敏捷工具好用：這個我無法評判，多長時間之後或許有更好的呢，不能迷信是吧！現在我就知道CMMI也是一種非常不錯的管理方式啊。敏捷能不能用好都是一個問題呢！

敏捷很簡單：很多人看了幾句話就去用敏捷，結果自己累死不說還帶著專案進入泥沼。《Scrum實戰——敏捷軟體專案管理與開發》中就有很多例子可以說明。如果只是簡單的把專案分成幾個階段，然後加上晨會啊，週報啊，必須在某時間提交什麼東西啊！根本不是敏捷。敏捷能否用好，好不好用還是的看人，看專案，看公司。

最後總結，請謹記：敏捷的核心是 溝通和響應變化以及階段性戰果。