随着敏捷软件开发宣言的签署和发布，多个敏捷方法框架在全球得到传播和使用。因为各个敏捷方法框架由不同的专家组维护，所以各个方法有不同的表述方式，有不同的着眼点和侧重点。本文将为你介绍敏捷开发方法框架的共同特征，理解与传统软件工程的联系和不同。

短迭代的生命周期模型

生命周期是事物发展的客观规律，软件同样存在生命周期。早期的软件生命周期往往是说“软件从计划、需求开始，经历分析设计、实现、部署、维护，直到最后逐渐消亡的”。这是受到了第一个软件生命周期模型—瀑布型生命周期影响，上述语句实质上简要的描述了瀑布型生命周期。现在的软件生命周期不再只考虑瀑布型生命周期，另外常见的软件生命周期模型有原型模型、螺旋模型、迭代模型。所以现在的软件生命周期说明应当不再包括瀑布型生命周期中的典型阶段。本书对软件生命周期及软件生命周期模型采用如下定义：

软件生命周期是指软件的产生直到报废的全部过程。

软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

敏捷软件开发明确对生命周期模型提出了要求：短迭代开发。迭代模型的历史可以追溯到上世纪50年代，但以往的迭代模型并没有对迭代周期长度提出要求。而在敏捷软件开发中，迭代周期长度一般不超过2个月，而常见的迭代周期是2周到4周，因此可以称之为“短迭代”。

有些敏捷软件开发在主开发过程前安排有预研或计划或架构或需求阶段等等，在主开发过程后安排有系统集成测试或验收测试或试运行等等，这样做并不违反敏捷开发原则，但其主开发过程应当采用短迭代开发，而且主开发过程的工期应当占有显著的比例，形成多个短迭代。

敏捷开发讲究固定的节奏，建议按照固定的节奏开发，所以短迭代的周期长度在开始选定之后，一般不作改变。同样的原因，敏捷迭代与迭代之间一般不安排缓冲期，上个迭代未完成的内容放到下个迭代中进行处理。

敏捷开发迭代与瀑布生命周期的阶段是不同的。瀑布型中需求分析阶段的产物一般是需求规格说明书，不同阶段的产物是不同的；而敏捷开发迭代的产物是软件本身，前期迭代的产物也许不完整，但各个敏捷开发迭代的产物是一致的、逐步改进完善的软件本身。

开发中可运行的软件

软件最终是需要运行的，而正在开发中的软件往往是难以运行的。在瀑布型生命周期和衍生于瀑布型的其他多个生命周期模型中，为了保证最终运行的软件满足用户的需要，安排了多个对于文档的里程碑评审。而敏捷软件开发则是尽快的把软件运行起来，主要根据可运行的软件来判断软件是否满足用户需要。显然的，通过软件本身来判断比起通过文档来判断，更加直接，更加准确。

为了让开发中的软件可运行，敏捷软件开发在这方面的基本要求是敏捷开发迭代的产物可以运行，也即是每个迭代至少得到一次可运行的软件。

而敏捷软件开发推荐更加快速更高频度的获得可运行的软件，这样带来更大的好处。极限的，每次代码修改都能得到可运行的软件，这样的做法叫做“持续集成”（下文将详细说明）。按照得到可运行软件频率从高到低，得到下列排序：

1， 持续集成— 一天之内可能集成多次

2， 每日集成

3， 每周或每双周集成

4， 每迭代集成

为了判断可运行的软件满足用户需要并得到高质量产出，敏捷软件开发在得到可运行软件的同时还常常采用如下方法：

1， 静态代码检查

2， 自动化测试

3， 产品展示

4， 用户试用

短线沟通和快速反馈

现代管理学的研究表明管理者在沟通方面花费了大量的时间，参与方数量的线性增长将带来沟通工作量的指数增长。敏捷软件开发讲究短线沟通和快速反馈，在这方面的基本要求是安排用户检查每个迭代的可运行产物。推荐面对面的交流，为了密切交流，办公环境值得为此进行改变，让团队的沟通更加便捷，比如整个团队在相同的房间里，位置接近，大会议桌式分布。

快速反馈的范围包括了客户、领导、同伴，希望客户能够快速的告诉团队“这个样子不是我想要的”，XP推荐现场客户，这样反馈更加及时。

变化的需求和架构

瀑布型生命周期假设在需求里程碑之后，需求可以冻结；而敏捷开发不做需求可以冻结的假设。瀑布型生命周期假设在设计里程碑之后，设计可以冻结，而敏捷开发也不做设计可以冻结的假设。

相反的，敏捷开发认为需求变更和设计变化是正常的，为此利用短迭代的机会，不断的澄清需求，设计尽量不做超前设计，将设计浓缩到架构，而架构也不是不变的，架构在每个迭代中将会演进。