敏捷开发分析和总结.docx

敏捷开发（agiledevelopment）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。简言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

敏捷开发是全新理论吗？答案莫衷一是。细心的人们可以发现，敏捷开发其实借鉴了大量软件工程中的方法。迭代与增量开发，这两种在任何一本软件工程教材中都会被提到的方法，在敏捷开发模式中扮演了很重要的角色。再向前追溯，我们还也可见到瀑布式与快速原型法的影子，也许还有更多。

改善，而非创新。敏捷开发可理解为在原有软件开发方法基础上的整合——取其精华，去其糟粕。因此敏捷开发继承了不少原有方法的优势。“在敏捷软件开发的过程中，我们每两周都会得到一个可以工作的软件，”Fowler介绍，“这种非常短的循环，使终端客户可以及时、快速地看到他们花钱构建的软件是一个什么样的结果。”

也许是因为时间关系，Fowler只说出了这些优势中的一部分。允许开发过程中的需求变化、通过早期迭代可以较早发现风险、使代码重用变得可行、减少项目返工……借鉴了众多先进方法和丰富经验，拥有的众多优势使得敏捷开发看来已经成为解决软件危机的标准答案。

问题与思考

然而，我们不得不面对的现实却是，模式与方法的优化并不意味着问题的终结。作为一种开发模式，敏捷开发同样需要面对众多挑战。

大项目的拆分意味着更多子项目的出现，协调这些同步或异步推进的子项目，合理的资源调配都将变得更加复杂。另外，在当前项目和项目组普遍“增容”的情况下，遇到的问题同样成倍增长。人的重要性被提到了更高的高度，而缺乏有效协调手段，减少人员流动和项目变更对整个项目造成的影响也将成为一大挑战……新方法带来众多便利的同时，也相应引发了几乎同样多的问题。

敏捷开发（agiledevelopment）概念从2004年初开始广为流行。Bailar非常支持这一理论，他采取了敏捷方式组建团队：CapitalOne的敏捷团队包括3名业务人员、两名操作人员和5～7名IT人员，其中包括1个业务信息指导（实际上是业务部门和IT部门之间的翻译者）；另外，还有一个由项目经理和至少80名开发人员组成的团队。这些开发人员都曾被Bailar送去参加过敏捷开发的培训，具备相关的技能。

每个团队都有自己的敏捷指导（Bailar聘用了20个敏捷指导），他的工作是关注流程并提供建议和支持。最初提出的需求被归纳成一个目标、一堆记录详细需要的卡片及一些供参考的原型和模板。在整个项目阶段，团队人员密切合作，开发有规律地停顿--在9周开发过程中停顿3～4次，以评估过程及决定需求变更是否必要。在CapitalOne，大的IT项目会被拆分成多个子项目，安排给各敏捷团队，这种方式在敏捷开发中叫蜂巢式（swarming），所有过程由一名项目经理控制。

为了检验这个系统的效果，

为了检验这个系统的效果，Bailar将项目拆分，从旧的瀑布式开发转变为并列式

开发，形成了敏捷开发所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行冲刺--每个冲刺始于一个启动会议，到下个冲刺前结束。

在Bailar将其与传统的开发方式做了对比后，他感到非常兴奋--敏捷开发使开发时间减少了30%～40%，有时甚至接近50%，提高了交付产品的质量。不过，有些需求不能用敏捷开发来处理。Bailar承认，敏捷开发也有局限性，比如对那些不明确、优先权不清楚的需求或处于较快、较便宜、较优的三角架构中却不能排列出三者优先级的需求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难

的事，但经过阵痛之后，需求处理流程会让CIO受益匪浅。

敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速

工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为：

????

?

?

?

?

个体和交互胜过过程和工具

可以工作的软件胜过面面俱到的文档

客户合作胜过合同谈判响应变化胜过遵循计划

并提出了以下遵循的原则：

?

?

?

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。

即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。

经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。

?

?

在整个项目开发期间，业务人员和