内容发布更新时间 : 2024/4/28 21:35:40星期一 下面是文章的全部内容请认真阅读。

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%，提高了 交付产品的质量。\不过，有些需求不能用敏捷开发来处理。\承认，\敏捷开发\也有局限性，比如对那些不明确、优先权不清楚的需求或处于\较快、较便宜、较优\的三角架构中却不能排列出三者优先级的需 求。此外，他觉得大型项目或有特殊规则的需求的项目，更适宜采用传统的开发方式。尽管描述需求一直是件困难的事，但经过阵痛之后，需求处理流程会让CIO 受益匪浅。

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

?

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

可以工作的软件 胜过 面面俱到的文档 ? 客户合作 胜过 合同谈判 ? 响应变化 胜过 遵循计划

?

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

? ? ? ? ? ? ? ? ? ? ? ?

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

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

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

在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。 在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。

工作的软件是首要的进度度量标准。

敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。

不断地关注优秀的技能和好的设计会增强敏捷能力。 简单是最根本的。

最好的构架、需求和设计出于自组织团队。 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。

MatainFlow:

从无到繁重再到敏捷

多数软件开发仍然是一个显得混乱的活动，即典型的“边写边改” (code and fix)。设计过程充斥着短期的，即时的决定，而无完整的规划。这种模式对小系统开发其实很管用，但是当系统变得越大越复杂时，要想加入新的功能就越来越 困难。同时错误故障越来越多，越来越难于排除。一个典型的标志就是当系统功能完成后有一个很长的测试阶段，有时甚至有遥遥无期之感，从而对项目的完成产生 严重的影响。

我们使用这种开发模式已有很长时间了，不过我们实际上也有另外一种选择，那就是“正规方法”(methodology)。这些方法 对开发过程有着严格而详尽的规定，以期使软件开发更有可预设性并提高效率，这种思路是借鉴了其他工程领域的实践。

这些正规方法已存在了很长时间了，但是并没有取得令人瞩目的成功，甚至就没怎么引起人们的注意。对这些方法最常听见的批评就是 它们的官僚繁琐，

要是按照它的要求来，那有做太多的事情需要做，而延缓整个开发进程。所以它们通常被认为是“繁琐滞重型”方法，或Jim HighSmith 所称的“巨型”(monumental)方法。

作为对这些方法的反叛，在过去几年中出现了一类新方法。尽管它们还没有正式的名称，但是一般被称为“敏捷型”方法。对许多人来 说，这类方法的吸 引之处在于对繁文缛节的官僚过程的反叛。它们在无过程和过于繁琐的过程中达到了一种平衡，使得能以不多的步骤过程获取较满意的结果。

敏捷型与滞重型方法有一些显著的区别。其中一个显而易见的不同反映在文档上。敏捷型不是很面向文档，对于一项任务，它们通常只 要求尽可能少的文档。从许多方面来看，它们更象是“面向源码”(code-oriented)。事实上，它们认为最根本的文档应该是源码。

但是，我并不以为文档方面的特点是敏捷型方法的根本之点。文档减少仅仅是个表象，它其实反映的是更深层的特点：

1 敏捷型方法是“适配性”而非“预设性”。 重型方法试图对一个软件开发项目在很长的时间跨度内作出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其 实，它们的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

2 敏捷型方法是“面向人”的(people-oriented) 而非“面向过程”的 (process-oriented)。 它们试图使软件开发工作顺应人的天性而非逆之。它们强调软件开发应当是一项愉快的活动。

我认为以上两个特点很好的概括了敏捷开发方法的核心思想：适应变化和以人为中心

Ation：