先寫關鍵字
重點：快速開發、快速交付、快速反饋、溝通大於文檔、可運行程序大於文檔、響應變化
誤區：可以節省工作量、高質量、文檔可以省略、敏捷工具好用、敏捷很簡單
然後來三大關鍵
敏捷是什麼：敏捷開發以用戶的需求進化爲核心，採用迭代、循序漸進的方法進行軟件開發。
敏捷能幹什麼：這個我想了很久，發現還是片面了。敏捷能管理軟件開發過程。能幫助我們管理軟件開發中的很多問題，比如:需求變化，客戶要項目要最後才能看到成果等。
敏捷需要怎麼做：
敏捷當時拿到手的時候我是懵逼的，爲啥懵，因爲覺得難而且麻煩。直到，看完《大教堂與集市》Eric S. Raymond 的作品，開源運動的聖經。
爲啥和開源扯上關係了呢！因爲他的開源思想和敏捷根本就是一回事，你看。
1、儘量小的開發任務。 -- 快速開發
2、在可運行的情況下能發佈就發佈。 --快速交付
3、儘快的收集用戶的反饋，並修改。 --快速反饋
然後，敏捷宣言中的幾點
個體和交互 重於 過程和工具。 在開源中，往往都是郵件來郵件去，基本上是沒有流程的，也沒有要求什麼工具。
可運行的軟件 重於 詳盡的文檔。 開源項目中，我極少能看到文檔。及時有也是事後整理的api說明。設計和需求文檔基本上是沒有的。大家都是先去看你的軟件好不好之後再去找你的文檔。注意：並不是沒有文檔，只是文檔的地位沒有那麼高，在有時間整理的情況下，開源也是會去整理文檔。實際上這裏我的理解是這樣的：可運行的軟件優於事前規劃的文檔。事後的說明性文檔和設計文檔都是一些必須的東西，不然根本沒辦法交接，過去的代碼往往會變成雷坑。
客戶合作 重於 合同談判。 開源有所謂的合同說法麼，工作還不是一樣的做。和客戶鬧的不開心也是影響自己的項目，大家都不好。合同上的東西往往會變成項目的底線，而不是標準。
響應變化 重於 遵循計劃。 經常性看到開源的東西，今天做這個，明天就砍掉了。這是啥，你說開源沒有計劃麼，並不是，而是會根據實際情況去調整計劃。不要的就不要了，優勢就繼續發揮深度挖掘。
最後使用心得：
敏捷其實最大的好處在於適應變化。需求變化，人員變化，技術變化等等。這些在瀑布式開發中都是無比痛苦的。
其實敏捷還有許多，我都沒有放到關鍵字中比如：測試驅動、持續集成、結對編程、極限編程等等。
因爲我覺得這些都和敏捷關係並不大，如果我用需求驅動（領域驅動、用戶故事驅動）難道就不能用敏捷了麼，我不結對編程就不能敏捷了麼。我只有一次集成就不能用敏捷了嗎？一個迭代的敏捷和瀑布式開發也是有根本上的不一樣。
只是，用了這些東西之後，敏捷起來會更舒服，實際上這些東西對任何方式都有很大的幫助。
最後，敏捷除了適應變化之外，還有一個非常重要的一點，那就是持續改進。做任何事都要持續改進！切記切記。
誤區解釋：
敏捷可以節省工作量：其實如果需求沒有任何變動，敏捷其實比瀑布式開發要多花費很多工作量。什麼都是明確的開發起來根本不用猶豫一路到底的感覺當然會快很多。而且即使需求存在變化，敏捷也需要花費很多時間去溝通，調整變化。所以想使用敏捷來節省工作量是不靠譜的。
高質量：敏捷根本無法保證高質量，敏捷沒有任何一個思想可以解決代碼質量問題，高質量的代碼還是要看管理。使用測試驅動，結對編程纔是提高代碼質量的方式。
文檔可以省略：少文檔，不代表沒有文檔。以需求驅動舉例，在每次迭代之前就需要確定明確的需求。迭代之中出現變化要及時體現在需求文檔中。決不能以口頭形式去表達需求。以測試驅動而言，測試案例也是要比代碼先出來的，寫完代碼相應的測試代碼也要出來。再多的註釋和極度良好的命名也沒辦法取代文檔。
敏捷工具好用：這個我無法評判，多長時間之後或許有更好的呢，不能迷信是吧！現在我就知道CMMI也是一種非常不錯的管理方式啊。敏捷能不能用好都是一個問題呢！
敏捷很簡單：很多人看了幾句話就去用敏捷，結果自己累死不說還帶着項目進入泥沼。《Scrum實戰——敏捷軟件項目管理與開發》中就有很多例子可以說明。如果只是簡單的把項目分成幾個階段，然後加上晨會啊，週報啊，必須在某時間提交什麼東西啊！根本不是敏捷。敏捷能否用好，好不好用還是的看人，看項目，看公司。
最後總結，請謹記：敏捷的核心是 溝通和響應變化以及階段性戰果。