首先要提的是參考書目，這個也是《系統與分析》課上推薦的書目，是由Henrik Kniberg編寫的《硝煙中的Scrum和XP》，裡面主要介紹了敏捷開發中的Scrum和XP的經驗，另外的參考是在《軟體工程》和《系統與分析》這兩門課中的筆記，這裡主要是想分享敏捷開發的經驗，算是一個快餐過程。

首先是敏捷開發（AgileModeling，有些地方可能簡稱為AM）要注意的是，敏捷開發並不是一個完整的方法論，而是對已有宣告週期模型的補充，在應用的生命週期模型時可以借鑑AM的過程指導思想。

敏捷開發可以分為一下幾個分類：極限程式設計（XP），迭代增量過程（SCRUM），水晶方法系列（Crystal Methods），以及特性驅動開發（FDD）。

敏捷開發的概念比較難理解，上面的那個定義也是一家之言，我通過學習，總結來說可以這麼理解，快速地開發一個軟體。因為有軟體生命週期模型的存在，這裡存在很多完整的方法論，但是例如原型（prototype）和文件是極其影響效率的事，所以就有了敏捷開發。因此，敏捷開發不是一個說明性過程，只是一種想法，一種開發軟體的辦法，可以這麼說，學習敏捷開發不需要系統性的學習，例如買一個書，這只是一個想法，因為條件苛刻。

然後就是敏捷開發的優缺點。首先是優點快，這個前面就說了，較短的開發週期意味著成本被大幅度降低。缺點十分明顯，就是風險。缺點是敏捷開發的重點，它的風險承擔能力特別差，如果需求改變，或者致命性的軟體缺陷都有可能導致比傳統開發更高的成本，傳統的開發在風險方面比敏捷開發低得多，並且更加有序。接著就是利益分配，敏捷開發沒有固定的工作分配，基本是靠軟體工程師的信念驅使的，即是說，假如其中有人不滿的話，很容易讓團隊分崩離析。但是這個風險不是不可控的，有關於敏捷開發隊伍的條件。

用通俗易懂的話來說，你玩一個遊戲，50個平均等級為20的玩家很艱難才可以過一個關卡，那5個99級的玩家可以很輕鬆通過。就是這個道理，敏捷開發的首要條件就是遠超平均水平的軟體工程師，這個“遠超”特別重要，敏捷開發並不是新手可以駕馭的，我的老師給出的一個例子就是，28歲的本科生或研究生，就是至少工作了一段時間的軟體工程師，並且有系統性訓練和在大公司工作過多年的經驗，才能駕馭這個方法。然後就是相同的理念，這個十分重要，大多數敏捷開發是自覺加班，自覺工作，所以可能會有分配不均的情況，所以利益驅使的團隊是無法完成敏捷開發的，相同的行年也同樣重要。

所以也可以這麼理解，敏捷開發就是老手的一個快速開發軟體的辦法。