【软件测试基础理论知识】1.3软件开发模型之—敏捷开发（敏捷模型）

一. 什么是敏捷开发

1.1 敏捷开发的定义

2001年，由Martin Fowler，Jim Highsmith等17位软件开发专家在美国犹他州召开了雪鸟会议，会议上正式提出了敏捷开发概念，并共同签署了敏捷宣言，敏捷联盟成立。
敏捷开发不是具体的指导性方法，它是一种观点和价值观，敏捷开发提供了一种思维方法，但真正的敏捷开发并不告诉大家怎么做。

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

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

1.2 敏捷开发的原则

1. 通过早期和持续交付有价值的软件，实现客户满意度。
2. 欢迎不断变化的需求，即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
3. 不断交付可用的软件，周期通常是几周，越短越好。
4. 项目过程中，业务人员与开发人员必须在一起工作。
5. 项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
6. 面对面交谈是最好的沟通方式。
7. 可用性是衡量进度的主要指标。
8. 提倡可持续的开发，保持稳定的进展速度。
9. 不断关注技术是否优秀，设计是否良好。
10. 简单性至关重要，尽最大可能减少不必要的工作。
11. 最好的架构、要求和设计，来自团队内部自发的认识。
12. 团队要定期反思如何更有效，并相应地进行调整。

1.3 敏捷开发的特点

敏捷开发用于软件开发工作时，主张最简单的解决方案就是最好的解决方案，其特点是：

• 1.快速迭代

采用复杂问题分解方法，对于小版本的需求、开发和测试更加简单快速。

• 2.让测试人员和开发者参与需求讨论

需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员和开发者，这样可以更加轻松地定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

• 3.编写可测试的需求文档
  开始就要用“用户故事”（user story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早地提及技术实施方案，会降低对需求的注意力。

• 4.多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。良好的沟通是敏捷开发的先决条件，强调高效沟通的重要性。团队要确保日常的交流，面对面沟通比邮件更有效。强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

• 5.响应变更胜过遵循计划

在敏捷方法开发软件过程中，接收需求变更，预料系统需求的变更，并快速响应变更，设计系统使之适应变更。主动适应变化，而不是预测

• 6.及早考虑测试

及早考虑测试在敏捷开发中很重要。传统软件开发中，测试用例大多都是最后才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。若较早地开始编写测试用例，在需求完成时，可以接受的测试用例也基本同时完成。

1.4 传统的开发模式和敏捷开发模式的对比

• 在采用瀑布研发模式时:
  （1）以过程为中心，流水线工作方式
  （2）重视和强调过程文档，主要通过文档来进行沟通
  （3）线性模式，缺少迭代与反馈
  （3）用户直到产品发布才能看到是不是自己想要的，最终成品与需求的偏差率相对较大。
• 在采用敏捷研发模式时
  （1）以人为中心，以客户需求为导向
  （2）强调软件，而不是文档，减少不必要的文档。
  （3）采用迭代方法
  （3）用户能持续看到阶段性可用的产品，并能及时提出改进反馈，最终成品与需求的偏差率相对较小。

瀑布模型：

敏捷开发模型：

当前的软件研发所面临的环节是不断快速变化的动态环境，包括新的机遇和市场、不断变化的经济条件、出现的新的竞争产品和服务。软件几乎是所有业务运行中的一部分，所以非常重要的一点是新的软件要迅速开发出来以抓住新的机遇，应对竞争和压力。在这种背景下，研发者许多时候宁愿牺牲一些软件质量、降低某些需求来赢得快速软件的交付。

传统软件研发建立在对需求描述，然后进行设计、构造，最后再进行测试的完整计划上的软件开发过程是不适应快速软件开发的。当需求发生改变，或者是当需求出现问题时，系统设计和实现不得不返工和重新进行测试。其结果是，传统的瀑布模型或基于描述的过程总是拖延，最后的软件交付给客户的时间远远晚于最初的规定。而敏捷软件开发方法允许开发团队将主要精力集中在软件本身而不是在设计和编制文档上。敏捷方法普遍依赖迭代方法来完成软件研发，其目标是减少开发过程中烦琐多余的部分，通过避免那些从长远看未必有用的工作和减少可能永远都不会被用到的文档的方法达到目的。

1.5 敏捷开发的分类

敏捷开发(Agile Development)本身是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，

敏捷开发过程主要包括：SCRUM，Crystal，特征驱动软件开发（FDD），自适应软件开发（ASD）及极限编程（XP）等。
（1）XP（极限编程eXtreme Programming，简称XP），是一个轻量级的、灵巧的软件开发方法，同时也是一个严谨和周密的方法。XP的基础和价值观是交流、朴素、反馈和勇气，即任何一个软件项目都可以从四方面入手进行改善，加强交流；从简单做起；寻求反馈；勇于实事求是。XP是一种近似螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极交流、反馈以及其他一系列方法，开发者和客户都能够非常清楚开发的进度、变化、待解决的问题和潜在困难，等等，并根据实际情况及时地调整开发过程。XP无需开发人员在软件开发初期就制作出很多文档，以适应计划的不断改变。XP提倡测试先行，这是为了将后期出现bug的概率降到最低。XP将项目的所有参与者视为同一团队成员（开发人员、客户、测试人员等），并一起工作在开放场所中。
**（2）SCRUM。SCRUM是一种迭代的增量化过程，**用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。该方法的核心是旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。
**（3）Crystal Methods（水晶方法族）。**它是一个系列，因为不同类型的项目需要不同的方法。虽然“水晶系列”不如XP有那样高的产出效率，但有不少开发者接受并遵循这一开发方法。
**（4）FDD（Feature-Driven Development，特性驱动开发）。**这是一套针对中小型软件项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调简化、实用、易于被开发团队接受，适用于需求经常变动的项目。
（5）ASD（Adaptive Software Development，自适应软件开发）。ASD强调开发方法的适应性，这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。
**（6）DSDM（动态系统开发方法）也是敏捷开发方法中的一种，**它倡导以业务为核心，快速而有效地进行系统开发。实践证明DSDM是成功的敏捷开发方法之一。在英国，由于其在各种规模的软件组织中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM方法不但遵循了敏捷方法的原理，而且也适合那些相对成熟传统开发方法具有坚实基础的软件组织。
**（7）轻量型RUP。RUP本质上是一个过程框架，**可以包容许多不同类型的过程，一些软件专家极力主张以敏捷方式来使用RUP，并认为如此推进敏捷方法，是因为开发者广泛把RUP当做面向对象开发方法的主流。
敏捷方法将开发与测试过程融为一体。在敏捷方法中，测试以很多不同的方法扮演着同样的角色，而不同的测试种类扮演着不同的角色。大家知道，测试大体上可分为手工测试和自动化测试。根据敏捷原则，要确保能用自动化测试的事情绝不要用手工测试，同时要做到适于手工测试的内容绝不花高昂成本做自动化测试。另外，不因为某方面不能实现自动化测试而不去做测试。敏捷开发中，如何运用手工测试和自动化测试？如何设计测试用例？这些是敏捷测试面临的挑战。

1.5 Scrum

（1）敏捷软件开发是一种以用户的需求进化为核心、迭代、循序渐进的开发方法。
（2）Scrum是一种迭代式增量软件开发模型，通常用于敏捷软件开发。
（3）XP，又叫极限编程，也是一种敏捷软件开发的模型，它以代码为核心，且由4部分组成：交流、简化、反馈、勇气，我们常说的结对编程就是其中一种模式。

在国内，我们听到最多的是Scrum，那是因为经过很多项目和团队的实践，证明了它有效、简单、持续交付的能力，所以很多初创型企业或小规模团队都比较青睐它。
我们通过一段对话来了解一下Scrum模型中的角色投入程度。
鸡跟猪说：“我们一起开一家餐馆吧。”
猪问鸡道：“餐馆起什么名字呢？”
鸡跟猪说：“就叫‘火腿与鸡蛋’吧。”
猪跟鸡说：“谢谢！还是算了吧。我是全身心投入的，而你只是部分参与而已。”
从上面“猪”和“鸡”的对话中我们不难看出，在Scrum中有以下两种角色：
（1）内部角色（全身心投入的成员），如产品负责人、敏捷教练、研发团队。
（2）外部角色（部分投入的成员），如用户、管理层、其他利益相关者。
最后，我们通过一张图来快速了解一下Scrum中主要的角色、产物、会议和流程。

4个角色：
Product Owner:PO，产品负责人，团队的掌舵人，引领团队朝着正确的方向前进。
Scrum Master:SM，敏捷教练（这是我个人最喜欢的，也是认为最贴切的中文翻译）。
Team：由开发和测试等相关人员组成的团队，每个迭代周期内所有任务的完成者。
利益相关人：在敏捷里，利益相关人指的是被项目过程和最终产物所影响到的角色，比如管理者、客户和用户。
5个产物：
Product Backlog：产品清单。
Sprint Goal：迭代目标，也叫冲刺目标。
Sprint Backlog：迭代清单，也叫冲刺清单。
Task List：任务列表。
Increment Product：增量产品。
4个会议：
Planning Meeting：计划会议。
Daily Scrum Meeting：每日站会，传说中的15分钟，“站”只是多种形式中效率最高的一种。
Review Meeting：评审会议，也叫验收会议。
Retrospective Meeting：反思会议。我认为，这是所有会议里最重要的一个，因为敏捷思想的核心就是持续改进，而持续改进来源于持续总结和反思。
流程：
（1）团队在产品负责人的主持下，通过计划会议、产品清单和冲刺目标产出冲刺清单。
（2）团队在敏捷教练的指导下，通过冲刺清单、任务列表和每日站会，在一个迭代周期（图中是30天）内产出增量产品。
（3）产品负责人和团队通过评审会议，验收每个迭代周期产出的增量产品。
（4）敏捷教练和团队通过反思会议，反思每个迭代周期里做得好和做得不好的地方，持续总结和改进，以此来提高每个迭代周期的战斗力。

最后附上一些相关的概念。
User Story：用户故事，从用户的角度来描述用户渴望得到的功能。
Task Board：任务墙，将Scrum过程中的各项事务放大并进行可视化展示的各种类型的载体。
Burn Down Chart：燃尽图，在迭代周期内用于跟踪任务进度的可视化图形。

任务墙：

燃尽图：

本节来源《软件测试进阶之路：测试路上你问我答》—何飞