Windows平台上的5种敏捷软件开发(过程)模型

我是荔园微风，作为一名在IT界整整25年的老兵，今天总结一下Windows平台上的5种敏捷软件开发(过程)模型。

说到这个问题，你必须先知道除了敏捷模型还有没有其他什么模型？同时要比较模型的区别，首先还要看看什么叫软件开发。

软件开发是一项包括版本计划、需求捕捉、需求分析、设计到代码编写、调试、维护的一系列过程。软件开发不仅仅是编程。而对于软件研发顾名思义就是包括了软件开发，并利用系统模型进行研究开发的过程。不止是开发，是从接到用户原始需求开始，到需求澄清、版本设计、软件开发、测试的过程。

你首先必须明白什么叫瀑布模型、迭代模型、敏捷开发。

瀑布模型（Waterfall Model）是一种比较老旧的软件开发模型，1970年温斯顿·罗伊斯提出了著名的“瀑布模型”，直到80年代都还是一直被广泛采用的模型。瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。瀑布模型优点是严格遵循预先计划的步骤顺序进行，一切按部就班比较严谨。瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
　　1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
　　2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
　　3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
　　4） 各个软件生命周期衔接花费时间较长，团队人员交流成本大。
　　5） 瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

迭代模型（stagewise model）（也被称作迭代增量式开发或迭代进化式开发），是一种与传统的瀑布式开发相反的软件开发过程，它弥补了传统开发方式中的一些弱点，具有更高的成功率和生产率。在迭代式开发方法中，整个开发工作被组织为一系列的短小的、固定长度（如几个星期内开发的项目）的小项目，被称为一系列的迭代。每一次迭代都包括了需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。教学中，对迭代和版本的区别，可理解如下： 迭代一般指某版本的生产过程，包括从需求分析到测试完成； 版本一般指某阶段软件开发的结果，一个可交付使用的产品。
　　与传统的瀑布模型相比较，迭代过程具有以下优点：
　　1）降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
　　2）降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期赶工。
　　3）加快了整个开发工作的进度。因为开发人员清楚问题所在，他们的工作会更有效率。
　　4）由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。因此复用性更高。

敏捷软件开发 (Agile development)是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果，关注业务优先级，检查与调整。敏捷软件开发要注意项目规模，规模增长，团队交流成本就上去了，因此敏捷软件开发暂时适合不是特别大的团队开发，比较适合一个组的团队使用。敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。 敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。 适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
 

好，比较完这三者的不同。我们下面来重点说说敏捷软件开发。

敏捷开发的定义

2001年，由Martin Fowler，Jim Highsmith等17位软件开发专家在美国犹他州召开了会议，会议上正式提出了敏捷开发概念，并共同签署了敏捷宣言，敏捷联盟成立。敏捷开发不是具体的指导性方法，它是一种观点和价值观，敏捷开发提供了一种思维方法，但真正的敏捷开发并不告诉大家怎么做。这就是很多人买了一本敏捷开发的书，看了半天也不知道该从哪里入手的关键原因，因为这只是一种思维方法。

敏捷开发以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。它强调适应性而非预测性，强调以人为中心，而不是以流程为中心。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果经过测试，都具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。开发宣言如下：

 个体和交互胜过过程和工具。
 可以工作的软件胜过面面俱到的文档。
 客户合作胜过合同谈判。
响应变化胜过遵循计划。

现代软件开发有需求变化大，人员流动大等特点，传统的软件生存周期模型难以很好的交付软件。所以，针对现代软件开发的特点，有工程师就总结出了敏捷软件开发的思想和方法。

我们通过图再来比较一下传统开发与敏捷开发：

传统开发：

 

 敏捷开发：

传统软件开发模式下，现代软件开发难以交付软件，即是交付软件，也难以保证软件的价值。具体来讲，软件开发具有如下4个特点：

1. 需求变化频繁
2. 技术变化过快
3. 人员变动频繁
4. 工程进度紧张

再来看看敏捷原则12条：

1.最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。主要指的是尽早让软件和客户见面，这样能及早地获得用户反馈。当然，为了快速，我们的功能可以相对少一点，可以通过得到每一次反馈之后，继续开发软件，然后又和客户见面（持续性）。

2. 即使在开发后期，也欢迎需求改变。敏捷过程利用变化来为客户创造竞争优势。现代软件开发的特点就是需求变化大，所以要拥抱变化，当然，这样的需求变化也有利于团队的构建和团队成员能力的提升。

3.经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。这里强调的是可工作的软件，这有利于人去理解软件。强调间隔时间短，主要指的是时间短，变化就小，并且能及时得到用户反馈。

4.在整个项目开发期间，业务人员和开发人员必须天天在一起工作。便于交流，及时得到软件需求。

5.围绕有积极性的个人构建项目团队。为他们提供所需的环境和支持，并信任他们 能够完成工作。高效团队和友好环境有利于软件开发。

6.在团队内部，最有效果并富有效率的信息传递方法是面对面的交流。面对面交流有利于达成共识，及时获得反馈。

7.可运行的软件是首要的进度度量标准。不从开发阶段看进度（开发者），而是从客户角度（工作软件功能完成度）看进度。

8.敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期 的、稳定的开发速度。这有利于客户进行项目规划和控制，有利于开发团队保持旺盛战斗力

9.持续关注优秀的技能和好的设计，增强敏捷能力。通过敏捷软件开发，每一个人都可以担任各种角色 ，多面手，获得能力的提升。

10.简单（是不必做的工作最大化的艺术）是必要的。敏捷开发不强调对明天问题预测 ，强调当下 ，不扩大今天的工作。简单才能专注。此外，把复杂问题简单化。

11.最好的架构、需求和设计出自于自组织的团队。高效团队有利于软件开发。

12.每隔一段时间，团队应反省如何才能有效地工作，并相应地调整自身的行为。是自组织的表现。团队是一个整体，反省有利于构建一个高效的团队。

总结：敏捷原则其实大部分看重的是组织管理，如如何构建一个高效团队，如何提升个人能力，如何和用户交流。另外一部分是针对技术需求，如尽早交付软件，拥抱变化等等。敏捷软件开发，基础是拥抱变化，以及围绕基础如何快速开发软件。其实归根起来，是人和技术。人：如开发团队要积极，客户要配合。技术：如快速交付软件获取需求，可视化软件等等。

本文的最后来看五种敏捷开发模型。敏捷开发的总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念（敏捷宣言）。

1.极限编程(XP)

XP是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为 4 个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4大价值观：沟通、简单性、反馈和勇气。

5个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

12个最佳实践：计划游戏（快速制定计划、随着细节的不断变化而完善)、小型发布(系统的设计要能够尽可能早地交付)、隐喻(找到合适的比喻传达信息)、简单设计(只处理当前的需求,使设计保持简单)，测试先行(先写测试代码,然后再编写程序)，重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本)，每周工作 40 个小时、现场客户和编码标准。

2.水晶法(Crystal)

水晶法认为每一个不同的项目都需要一套不同的策略、约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。

3.并列争求法（Scrum）

并列争求法使用迭代的方法，其中，把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。

4.自适应软件开发（ASD）

自适应软件开发有6个基本的原则：有一个使命作为指导；特征被视为客户价值的关键点；过程中的等待是很重要的，因此“重做”与“做”同样关键；变化不被视为改正，而是被视为对软件开发实际情况的调整；确定的交付时间迫使开发人员认真考虑每一个生产的版本的关键需求；风险也包含其中。

5.敏捷统一过程（AUP）

敏捷统一过程（Agile Unified Process，AUP）采用“在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的 UP 阶段性活动（初始、精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个 AUP 迭代执行以下活动:

建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进。实现。将模型翻译成源代码。测试。像 XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。部署。对软件增量的交付以及获取最终用户的反馈。配置及项目管理。着眼于变更管理、风险管理以及对团队的任一制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。

作者简介：荔园微风，1981年生，高级工程师，浙大工学硕士，软件工程项目主管，做过程序员、软件设计师、系统架构师，早期的Windows程序员，Visual Studio忠实用户，C/C++使用者，是一位在计算机界学习、拼搏、奋斗了25年的老将，经历了UNIX时代、桌面WIN32时代、Web应用时代、云计算时代、手机安卓时代、大数据时代、ICT时代、AI深度学习时代、智能机器时代，我不知道未来还会有什么时代，只记得这一路走来，充满着艰辛与收获，愿同大家一起走下去，充满希望的走下去。