敏捷开发总结要点.doc

Intro: 简单的说，敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试， 具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷开发是由一些业界专家针对一些企业现状提出了一些让软件开发团队具有快速工作、响应变化能力的价值观和原则，并于2001初成立了敏捷联盟。他们正在 通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。 　　敏捷开发(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 初成立了敏捷联盟。他们正在通过亲身实践以及帮助他人实践，揭示更好的软件开发方法。通过这项工作，他们认为： 　　个体和交互???? 胜过 过程和工具 　　可以工作的软件 胜过 面面俱到的文档 　　客户合作?????? 胜过 合同谈判 　　响应变化?????? 胜过 遵循计划 　　并提出了以下遵循的原则： 　　我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。 　　即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。 　　经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。 　　在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 　　围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 　　在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。 　　工作的软件是首要的进度度量标准。 　　敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。 　　不断地关注优秀的技能和好的设计会增强敏捷能力。 　　简单是最根本的。 　　最好的构架、需求和设计出于自组织团队。 　　每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。 从无到繁重再到敏捷 　　多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” (code and fix)。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越 困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生 严重的影响。 我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”(methodology)。这些方法 对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。 　　这些正规方法