Agile Development

敏捷开发模型是一个用于描述迭代软件开发的术语。迭代软件开发通过以较小的增量来缩短软件开发生命周期。敏捷开发通常与传统或瀑布式开发形成对比，后者预先计划大型项目并根据该计划执行。

实际运行过程就和增量模型类似，迭代地运行瀑布模型，只不过敏捷模型迭代更加快速，规模也更小，适应变化更加快速，Agile = 增量+迭代，每次迭代处理一个小规模增量。

敏捷方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要特征:

(1)敏捷开发方法是“适应性" 而非”预设性”。

这里说的预设性，可以通过一般性工程项目的做法理解，比如土木工程，在这类工程实践中，有比较稳定的需求，同时建设项目的要求也相对固定，所以此类项目通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。

然而，在软件开发的项目中，这些稳定的因素却很难寻求。软件的设计难处在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目模式都是试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。所以，这类方法在不可预测的环境下，很难适应变化，甚至是拒绝变化。

与之相反的敏捷方法则是欢迎变化，目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。所以称之为适应性方法。

(2) 敏捷开发方法是“面向人”而非 ”面向过程”。

Martin Fowler认为:“在敏捷开发过程中， 人是第位的， 过程是第二位的。所以就个人来说，应该可以从各种不同的过程中找到真正适合自己的过程。” 这与软件 工程理论提倡的先过程后人正好相反。(续致信网上一 页内容)

在传统的软件开发工作中，项目团队分配工作的重点是明确角色的定义，以个人的能力去适应角色，而角色的定义就是为了保证过程的实施，即个人以资源的方式被分配给角色，同时，资源是可以替代的，而角色不可以替代。

然而，传统软件开发的这些方法在敏捷开发方式中被完全颠覆。敏捷开发试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。

敏捷开发的目的是建立起一个项目团队全员参与到软件开发中，包括设定软件开发流程的管理人员，只有这样软件开发流程才有可接受性。同时敏捷开发要求研发人员独立自主在技术上进行决策，因为他们是最了解什么技术是需要和不需要的。再者，敏捷开发特别重视项目团队中的信息交流，有调查显示:“项目失败的原因最终都可追溯到信息没有及时准确地传递到应该接受它的人。
 

一般的敏捷模型有以下四个原则：

• 递增，而不是连续的：如果开发实践是真正的敏捷精神，那么交付的工作软件是一小部分一小部分递增的。不必等到一个阶段完全完成后才开始另一个，工作也不是向大的发布日期而努力。完成的工作，但并不是业务最终期限，驱动着敏捷交付。但敏捷精神也承认业务操纵着最后截止日期。

• 避免不必要的开销：如果实践仍然是真正的敏捷精神，那么团队就致力于尽可能多地减少项目计划和文档。与其讨论要做什么，然后再写下来，不如赶紧动手去做，否则，就是在浪费时间在工作的工作上。在工作对工作中，敏捷精神有利于实际的工——作交付工作软件。而且它也值面对面的交流通过邮件和其他书面文件。

• 协作：根据需求，团队成员一直与其它人进行交互，以及一些外部利益相关者。在敏捷教练世界中，整个团队的负责人Lisa Crispin能够解决所有问题，在问题出现之前 。真正的敏捷精神团队是自助的。他们分配需要做的工作。虽然每个成员承担的任务都在他们的专业技能范围内，他们还是需要与团队协作的。没有人的工作是孤立的，也没有团队本身是独立工作的。没有业务利益相关者，以及诸如用户体验方面的外部专家的重大投入，团队就不可能使项目向前发展，

• 说真话：为了保证真正的敏捷，团队探讨的与项目相关的一切都要是真实的。在一些至关重要的专业领域，如冲刺测试的编码技能，他们承认存在差距。关于实际生产力，他们的要讲事实；这也就是说，在y时间内，团队是否有能力做到x。他们承认错误。说真话是一项挑战，因为他们害怕承认缺点会让他们显得很弱。但敏捷精神知道说出事实需要勇气。承认问题需要信心，然后快速地去解决问题。