敏捷开发发展和优缺点 1

1 概述

随着软件开发技术的不断发展，现在出现了很多种不同的开发模式，其实敏捷开发已经成为现在很多企业开发应用程序都想要选择的开发方案，那么什么是敏捷开发呢？

1.1 四种开发模式

1.1.1 瀑布式开发

瀑布式开发是一种老旧的，正在过时的计算机软件开发方法，最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况

瀑布式开发是由 WW.Royce 在 1970 年提出的软件开发模型，是一种比较老的计算机软件开发模式， 也是典型的预见性的开发模式。

在瀑布式开发中，开发严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤进行，步骤的成果作为衡量进度的方法，例如需求规格、设计文档、测试计划和代码审阅等， 瀑布式开发最早强调系统开发应有完整的周期，且 必须完整地经历每个周期内的每个开发阶段，井系统化地考量分析所涉及的技术、时间与资源投入等。

优点

有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，从而提高了大型软件项目开发的质量和效率

缺点

开发过程一般不能逆转，否则代价太大；

实际的项目开发很难严格按该模型进行；

客户往往很难清楚地给出所有的需求，而该模型却要求如此。

软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。

使用场景

用户的需求非常清楚全面，且在开发过程中没有或很少变化

开发人员对软件的应用领域很熟悉

用户的使用环境非常稳定

开发工作对用户参与的要求很低

1.1.2 螺旋模型

螺旋模型由巴利·玻姆(Barry Boehm)于1988年提岀，该模型融合了瀑布模型、快速原型模型，它最大的特点是引入了其他模型所忽略的风险分析，如果项目不能排除重大风险，就停止项目从而减小损失，这种模型比较适合开发复杂的大型软件。

螺旋模型将整个项目开发过程划分为几个不同的阶段，每个阶段按部就班地执行，这种划分方式采用了瀑布模型，每个阶段在开始之前都要进行风险评估，如果能消除重大风险则可以开始该阶段任务。

在每个阶段，首先构建软件原型，根据快速原型模型完成这个迭代过程，产出最终完善的产品，然后进入下一个阶段，同样下一个阶段开始之前也要进行风险评估，这样循环往复直到完成所有阶段的任务，螺旋模型的若干个阶段是沿着螺线方式进行的。

在每个螺旋周期内按四个象限，分为四个工作步。

• 第一，制定计划：确定软件目标，选定实施方案，明确项目开发的限制条件；
• 第二，风险分析：分析所选方案，识别风险，通过原型消除风险；

• 第三，开发实施：实施软件开发；
• 第四，客户评估：评价开发工作，提出修正建议，建立下一个周期的计划。

优点

实质上相当于在瀑布模型的每个阶段开始前引入风险分析，并由客户对阶段性产品做出评审，这对保证软件产品质量十分有利；由于引入风险分析等活动，测试活动的确定性增强了；螺旋模型最外层代表维护，开发与维护采用同样方式，使维护得到与开发同样的重视

缺点

主要适合内部开发，否则风险分析必须在签订合同前完成，或者争取客户的最大理解；只适合大型软件项目的开发，否则，每个阶段的风险分析将占用很大一部分资源，增加成本；对开发人员的风险分析能力是极大的考验，否则，模型将退化到瀑布模型，甚至更糟

1.1.3 迭代式开发

迭代式开发也被称作迭代增量式开发或迭代进化式开发，是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率

在迭代开发中，整个开发工作被组织为一系列的短小的，固定的长度(如3周)的小项目，被称为一系列的迭代，每一次迭代都包括了定义、需求分析、设计、实现与测试。

采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或者业务逻辑的开发工作，再通过客户的反馈来细化需求，并开始新一轮的迭代

优点

与传统的瀑布模型相比较，迭代过程具有以下优点

降低了在一个增量上的开发风险，如果某个迭代完成后的软件不符合客户要求，那么损失只是这一个开发有误的迭代的花费

降低了产品无法按照既定进度进入市场的风险，通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙

加快了整个开发工作的进度，因为开发人员清楚问题的焦点所在，他们的工作会更有效率。

由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的，因此，迭代过程这种模式使适应需求的变化会更容易些。

缺点

对产品人员的节奏把控能力（定每周目标，需求优先级剖析，以及临时需求的处理）有较高要求，不然容易陷入每周发版日加班加死的节奏

初期产品用户规模小，性能并不是主要瓶颈

团队里面没有优秀的架构师，优化力不从心。

后端架构优化是个慢活，它不像产品功能层面的迭代那样可以快速被感知，对于强产品驱动而非强技术驱动的公司来说，不够重视。

后端架构优化更是个细活，它也不像产品功能一样有很明显的“产出”，对于不懂技术的领导或者以KPI为导向的公司文化来说，员工去优化后端的意愿并不强烈。

产品交付进度压力比较大，没有时间去思考架构的优化，精力都在聚焦怎么实现功能上面

1.1.4 敏捷开发

敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法，在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本，然后在后续的生产周期内，按照新需求不断迭代升级，完善产品

优点

敏捷确实使得项目进入实质开发迭代阶段，用户很快可以看到一个基线架构版的产品，敏捷注重市场快速反应能力，也即具体应对能力，客户前期满意度高。

缺点

但敏捷注重人员的沟通，忽略文档的重要性，若项目人员流动大太，又给维护带来不少难度，特别项目存在新手比较多时，老员工比较累。

1.2 开发模式对比

2 敏捷开发

敏捷是世界上使用最广泛，最受认可的软件开发框架之一，大多数组织已经以某种形式采用了它，但是在采用计划的成熟度方面还有很长的路要走

敏捷软件开发是基于敏捷宣言定义的价值观《敏捷软件开发宣言》和原则《敏捷软件的十二条原则》的一系列方法和实践的总称。

自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案，换句话说敏捷开发是一种应对快速变化的需求的一种软件开发能力，只要在符合价值观和原则的基础上能让开发团队拥有应对快速变化需求的能力，这就叫做敏捷开发。

2.1 敏捷宣言

在2001年，17位敏捷方法论的拥护者和倡议者聚集在犹他州的雪鸟滑雪场，起草了一份陈述敏捷组织原则的文件，这份文件基本上代表了不同敏捷方法论的共同点。

当你读到这个宣言，你会发现它具有最高原则性，因为敏捷方法论在最高层面上是一致的，但到具体细节上每种方法都会不同。

参与者们分享了互相竞争的几种方式：极限编程（XP）；透明化；自适应软件开发（ASD）；特征驱动开发（FDD）；动态系统开发方法（DSDM），所有这些方式都是“轻量版”的框架，因为这些方法使用更少，更简单的规则来适应快速变化的环境，不少与会者都觉得“轻量”这个术语非常适用。

经过为期三天的讨论，他们在价值观和原则层面上达成共识，选择了 Agile 一词并为其赋予了特殊的意义，制定并发布了软件行业历史上最为重要的文件之一：敏捷宣言。

参会者将自己命名为“敏捷联盟（ The Agile Alliance ）”，**希望能够帮助软件行业中的其他人以新的、更敏捷的方式思考软件开发、方法和组织。**而“敏捷宣言”则被展示在一个网站上（ https://agilemanifesto.org/ ） ，到目前已被翻译成了60多种语言，并作为一种信仰被推广至全球以及非软件行业。

2.1.1 敏捷宣言解读

我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人，由此我们建立了如下价值观：

个体和互动 高于 流程和工具；（个体与交互：团队各个成员的能力与团队间的沟通）

工作的软件 高于 详尽的文档；(以结果为导向）

客户合作 高于 合同谈判；（注重客户参与）

响应变化 高于 遵循计划；( 敏捷 要求有开放的工作环境，确保团队及时高效地进行沟通）

也就是说，尽管右项有价值，我们更重视左项的价值。

2.1.2 敏捷宣言价值观

个体和互动高于流程和工具

项目是通过人来完成的，流程和工具可以帮助人，但绝不能自行完成工作。

虽然，过程和工具都是好东西，但是它们有时也会成为障碍，面对面的直接沟通，比一些流程性的文件和工具沟通，效率要高出很多，当然最好的是，在沟通后就多方达成的共识形成一个简要性的文档备录。

工作的软件高于详尽的文档

可用软件的价值是很重要的，因为软件是为业务目标提供支持的，是可用软件(而不是文档)为客户传递了高价值

一般来说，一个敏捷项目的进展情况是由开发了多少可用软件来跟踪和报告的，但不是说文档一无是处，适量的文档在绝大多数的项目中是有益的和必要的，敏捷通过寻求“刚好足够”的文档来避免这种情况，其中的原则是任何文件的创建都应与为客户创造的价值直接挂钩，且不论该价值体现在现状还是将来。

客户合作高于合同谈判

这对价值观的核心是越接近你的客户越好。

客户最清楚他想要什么，即使在需求明确过程中也会包含一些试验和错误，在合同谈判期间，试图避免所有的尝试和错误不发生是不现实的，也是徒劳的，定位你与客户的关系很重要，你是选择对抗你的客户还是选择与你的客户一起为接近方案努力而使每个人都受益？敏捷团队更愿意和客户在同一方向一起使劲而不是把力气花在背离客户的方向。

响应变化高于遵循计划

任何一个曾在软件项目工作过的人都知道这些项目的本质就是变化。

即使底层的技术也在快速变化，新的途径和可能性在不断的被打开，对变化响应的速度就决定你在市场上的灵活性，循规蹈矩的做事将被市场甩在后面，永远慢市场半拍，慢慢你的市场会被蚕食掉。