敏捷开发一

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

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

      为了检验这个系统的效果，Bailar将项目拆分，从旧的"瀑布式"开发转变为"并列式"开发，形成了"敏捷开发"所倡导的精干而灵活的开发团队，并将开发阶段分成30天一个周期，进行"冲刺"--每个冲刺始于一个启动会议，到下个冲刺前结束。

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

      敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为： 

个体和交互 胜过 过程和工具 
可以工作的软件 胜过 面面俱到的文档 
客户合作 胜过 合同谈判 
响应变化 胜过 遵循计划 
并提出了以下遵循的原则： 

我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 
在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 
工作的软件是首要的进度度量标准。 
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 
不断地关注优秀的技能和好的设计会增强敏捷能力。 
简单是最根本的。 
最好的构架、需求和设计出于自组织团队。 
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。