摘要：
在IT界中，“敏捷”是一个很酷的词汇，“敏捷”的相关理论可谓铺天盖地。
“敏捷”一词实质没有统一定义，各家有自家的说法，本教程将让你了解“敏捷”的来龙去脉，抓住“敏捷”本质，并能在工作中实践“敏捷”。
大纲：
“敏捷”陷阱
为什么会有“敏捷”这个说法？
极限编程
敏捷开发
RUP
敏捷开发的实质是什么？
如何才能敏捷起来？
正文：
“敏捷”陷阱
小甲想到某开发公司应聘开发工程师，向该公司的某开发人员打听他们的开发方式。
小甲：请问贵公司开发模式是怎样的？
开发人员：咱们敏捷开发！不用写文档，写好代码就可以了。
小甲心想：哇，爽啊！赶紧去应聘！
小甲已经在该公司工作了数周，他觉得很郁闷：
无需求文档，要做东西都是口头分配的。
无计划可言，想到啥就做啥。
加班不在话下，返工是家常便饭。
这就是敏捷开发吗？
不少公司搞CMMI认证，推行过程改进，往往被开发人员嗤之以鼻，开发人员喜欢自由奔放有创造力的工作模式，喜欢敏捷！
然而很多号称“敏捷”的公司，其实只是手工作坊的工作模式，想到啥就干啥，如果你是开发人员可能还会好一点，如果你是测试人员、实施人员，在这样的公司你简直会觉得无法沟通无法工作！
到底什么是敏捷呢？如何才不会跌入敏捷陷阱呢？
为什么会有“敏捷”这个说法？
大学时我们就被灌输了这样的知识：
生命周期模型有瀑布型、喷泉型、迭代型、螺旋型等。
一般来说，大型的、复杂的、对安全要求高的系统，应该采用传统的瀑布型来开发，应采取重型过程。
对于中小型、需要快速投产的系统，应采用灵活的生命周期，采用敏捷的方式开发。
其实“敏捷”是相对于“重型”提出来的，重型开发有这样的特点：（摘自互联网）
1.刻板而严格控制。
2.很多活动和工件，官僚主义气息浓重。
3.文档繁多。
4.长期而详细的计划。
5.过程高于本质核心的工作。
6.面向过程而不是面向人，把人看成机械方法中的插件。
7.预见而不是适应。
于是我就很有疑问了，如果重型开发有这样的特点，那么请问：对于大型的、复杂的、安全要求高的系统，也需要用具备上述特点的重型过程来开发吗？如果是这样，谁愿意在这样的工作环境下工作？具备这样特点的过程对项目成功有什么好处？
“重型”的重要特点是呆板，因为大家不喜欢呆板，喜欢灵活，所以提出了“敏捷”的说法！
我猜想：
1.重型过程其实是一些没有实际项目经验的理论家搞出来的产物。
2.重型过程的出发点纯粹就是为了过程而过程。
当然上述论述纯属瞎猜，无法证实。
每个人对“重型”与“敏捷”的理解其实都不太一样，这里我用一个问题来测试一下你：
我国的航天事业取得长足的发展，让国人振奋，请问：你认为嫦娥工程采用的过程是重型的还是敏捷的？
这么重大的项目，很多人可能认为应该是重型过程，很多人可能认为敏捷的过程是不太严禁的过程，其实嫦娥工程是灵活而又十分严谨的工程。
大家有没有留意到我们火箭发射时间是如何预报的？是不是具体说某天某时某刻发射？
不是！而是说某段时间内择机发射！“择机发射”是多么灵活、科学、严谨的发射计划啊，完全与我们传统的计划想法不一样，难道你能说这也是重型过程吗？
所谓“重型”与“敏捷”其实都是相对的，我们没有必要去争论到底是“重型”还是“敏捷”。我们平时见到这么多“重型”“敏捷”的不同说法，其实大家都是各自从不同的标准出发。
下面我们将介绍常见的几种敏捷开发，每种理念其实背后的道理是很类似的，我们没有必要去争论哪种方式更好，你完全可以吸取百家所长化为自己的理念，按照你的想法将项目做好。
极限编程
极限编程英文叫：Extreme P