敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。

考点

  • 敏捷的特点

简介

  敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。敏捷开发（agile development）是一种以人为核心、迭代、循序渐进的开发方法。

敏捷方法的特点

  敏捷型方法主要有两个特点，这也是其区别于其他方法，尤其是重型方法的最主要的特征。
●　敏捷型方法是“适应性”（adaptive）而非“预设性”（predictive）的。重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。
●　敏捷型方法是，“面向人的”（people-oriented）而非“面向过程的”（process-oriented）。它们试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。它们强调软件开发应当是一项愉快的活动。
下面是对上面两点的详细解释：

  1. 适应性和预设性
      传统的软件开发方法的基本思路一般是从其他工程领域借鉴而来的，比如土木工程等。在这类工程实践中，通常非常强调施工前的设计规划。只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利建造，并且可以很方便地把图纸划分为许多更小的部分交给不同的施工人员分别完成。
      但是，软件开发与上面的土木工程有着显著的不同。软件的设计是难以实现的，并且需要昂贵的有创造性的人员。土木工程师在设计时所使用的模型是基于多年的工程实践的，而且一些设计上的关键部分都是建立于坚实的数学分析之上。而在软件设计中，完全没有类似的基础。我们对开发计划所能做的只是请专家审阅。这就使得我们无法将设计和实施分离开来，一些设计错误只能在编码和测试时才能发现。根本无法做出一个交给程序员就能直接编码的软件设计。
    所以，软件过程不可能照搬其他工程领域原有的方法，需要有适应其特点的新的开发方法。
    软件的设计之所以难以实现，问题在于软件需求的不稳定，从而导致软件过程的不可预测。但是传统的控制项目的模式都是针对可预测的环境的，在不可预测的环境下，就无法使用这些方法。
    但是我们必须对这样的过程进行监控，以使得整个过程能向我们期望的目标前进。于是Agile方法引入“适应性”方法，该方法使用反馈机制对不可预测过程进行控制。

  2. 面向人而非面向过程
      传统正规方法的目标之一是发展出这样一种过程，使得一个项目的参与人员成为可替代的部件。这样的一种过程将人看成是一种资源，他们具有不同的角色，如分析员、程序员、测试员及管理人员。个体是不重要的，只有角色才是重要的。这样考虑的一个重要的出发点就是：尽量减少人的因素对开发过程的影响。但是敏捷型方法则正好相反。
      传统方法是让开发人员“服从”一个过程而非“接受”一个过程。但是一个常见的情况是：软件的开发过程是由管理人员决定的，而管理人员已经脱离实际开发活动相当长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。
      敏捷型过程还要求开发人员必须有权作技术方面的所有决定。IT行业和其他行业不同，其技术变化速度非常之快。今天的新技术可能几年后就过时了。只有在第一线的开发人员才能真正掌握和理解开发过程中的技术细节。所以技术方面的决定必须由他们来做出。这样一来，就使得开发人员和管理人员在一个软件项目的领导方面有同等的地位，他们共同对整个开发过程负责。
      敏捷方法特别强调开发中相关人员之间的信息交流。Alistair Cockburn在对数十个项目的案例调查分析后得出一个结论，“项目失败的原因最终都可以追溯到信息没有及时准确地传递到应该接受它的人”。在开发过程中，项目的需求是在不断变化的，管理人员之间、开发人员之间以及管理人员和开发人员之间，都必须不断地了解这些变化，对这些变化做出反应，并实施在随后的开发过程中。敏捷方法还特别提倡直接的面对面交流。Alistair Cockburn认为面对面交流的成本要远远低于文档交流的成本，因此，敏捷方法一般都按照高内聚、松耦合的原则将项目划分为若干小组，以增加沟通，提高敏捷性及应变能力。

敏捷方法的核心思想

  敏捷方法的核心思想主要有下面三点：

  1. 敏捷方法是适应型，而非可预测型。与传统方法不同，敏捷方法拥抱变化，也可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。

  2. 敏捷方法是以人为本，而非以过程为本。传统方法以过程为本，强调充分发挥人的特性，不去限制它。并且软件开发在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。

  3. 迭代增量式的开发过程。敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。它根据客户需求的优先级和开发风险，制定版本发行计划，每一发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能需求。

敏捷型方法的含义及其特征

  我们把软件开发过程中拥有大量中间产品（如需求规约、设计模型等）和复杂控制的软件开发方法称为重型方法；由此，我们称中间产品较少的方法为轻型方法。从表象来看，重型方法注重开发文档的完备性和充分性；而敏捷型方法认为最根本的文档应该是源码，而不是繁琐的文档。从实质上说，有如下两方面更深层次的区别：

  1. 敏捷型方法的思想是“自适应”的，而非如“预设”的重型方法试图预先固定需求并拟定详细开发计划；敏捷型方法适应需求的变化，甚至可以说其初衷就是针对变化的需求的。
  2. 敏捷型方法的思考角度是“面向人”的，而非“面向开发过程”的。重型方法在实践原则中总是把开发者看作是一个泛化的生产要素，而忽视了作为决定性因素的人的特殊性；而敏捷型方法则强调以人为本，并贯穿实践始终。由上可知敏捷型方法其实是软件开发方法论从无到重型再进一步发展的成果。

敏捷方法的适用范围

  实际上，满足工程设计标准的唯一文档是源代码清单。“软件项目的设计是一个抽象的概念。它涉及了程序的概括形状（shape）、结构以及每一模块、类和方法的详细形状。”系统设计得到了有关系统的一个清晰的“图像”，这一图像可以保持到首次发布。但随着项目的开发，程序“片段”就可能像不断腐化的“面包碎片”，发出“臭味”，并不断蔓延和积累，使得系统越来越难以维护，以至于不得不要求重新设计。但这样的重新设计是很难成功的。
  因此，与这种传统的方法相比，敏捷方法比较适合需求变化比较大或者开发前期对需求不是很清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在开发团队比较庞大的项目中实施，当然这也不是绝对的。

敏捷方法的主要内容

  敏捷方法的主要内容包括4个核心价值观和12条过程实践规则。4个核心价值观分别为沟通、简单、反馈和勇气。沟通，它强调设计者、开发者和客户三者之间的有效交流是开发成功的关键；简单是设计和编码的指导原则，它强调只满足当前功能需求，不做假想设计，尽量使代码简单化；反馈，强调设计者、开发者和客户之间及时和详尽的意见反馈是开发成功的保证；勇气，是开发适应变化的前提，要求设计者和开发者在必需做出取舍或重构时，勇于抉择，勇于实践。
  依据敏捷方法的4个核心价值观，提出12条过程实践规则，分别为简单设计、测试驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。

主要敏捷方法简介

  手工作坊式的软件生产方式已经被无数次的项目失败证明为低效和应被舍弃的：传统软件开发方法（如ISO9000和CMM）在规范和保证开发进程的同时，由于其繁琐的过程控制和严格的文档要求招致了开发者潜在的抵触；此外，开发人员流动性大于软件的可持续开发之间的矛盾日渐显露，如何保证软件的高可传承性以及尽可能地延长软件生命周期成了摆在开发者和管理者面前的难题。为了应对这种局面，近年来，已经出现很多敏捷型方法，它们有许多的共同特征，但也有一些重要的不同之处。这里就其中影响比较大的几种敏捷方法作一些简单的介绍。

XP（Extreme Programming，极限编程）

  在所有的敏捷型方法中，XP是最引人瞩目的。它源于Smalltalk圈子，特别是Kent Beck和Ward Cunningham在20世纪80年代末的密切合作。XP在一些对费用控制严格的公司中的使用，已经被证明是非常有效的。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期；通过积极的交流、反馈以及其它一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开发过程。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。

极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。

极限编程方法的基本特征是：

极限编程也有其被争论的一面：

绝大多数设计活动都匆匆而过，并渐进式的，开始一个“最简单的可能工作的东西”并当其需要时（测试失败）才增加复杂性。单元测试促成为了设计纪律。

Cockburn的水晶系列方法

  水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

开放式源码（Open Source）

  这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障（debug）的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。

SCRUM

  SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。Scrum是用于开发、交付和维持错综复杂产品 (complex products) 的敏捷框架 (framework) [1] 。最初着重于软件开发，之后已被用应用于其他领域，包括研究、销售、营销和其他先进技术领域。 一个 Scrum 团队建议为十名成员的团队而设计的，他们以迭代[2] (iterative) 与增量[3] (incremental) 式的方式交付工作，每个迭代称作 Sprint。一个 Sprint 的时间不超过一个月，通常是两星期。Scrum 团队在每个 Sprint 都专注在唯一一个共同的目标 (Sprint Goal)，每天的 Daily Scrum 团队中的开发人员 (Developers) 都检视朝向这共同目标的进度，和调适当下的计划。在 Sprint 结束时，团队会进行 Sprint 审查 (Sprint Review) 跟利害关系人 (Stakeholders) 一起检视当下的结果与调适计划，这是互相资讯交流的机会。最后，团队会进行 Sprint 回顾 (Sprint Retrospective) 来持续改善。

Scrum 的特性

Scrum是一个包括了一系列实践和预定义角色的过程骨架。 Scrum中的主要角色包括：

  1. Scrum Master是Scrum教练和团队带头人，确保团队合理的运作Scrum，并帮助团队扫除实施中的障碍；
  2. 产品负责人，确定产品的方向和愿景，定义产品发布的内容、优先级及交付时间，为产品投资报酬率负责；
  3. 开发团队，一个跨职能的小团队，人数5-9人，团队拥有交付可用软件需要的各种技能。

在每一次冲刺或迭代（一个15到30天的周期，其长度由开发团队决定）当中，开发团队创建可用的（可以随时推出）软件的一个增量。每一个迭代所要实现的功能来自产品订单。产品订单按照优先级排列工作需求。在迭代计划会议中，产品负责人告诉开发团队需要完成产品订单中的哪些订单项。开发团队决定在下一次迭代中他们能够承诺完成多少订单项。在迭代的过程中，没有人能够变更迭代订单，这意味着在一个迭代中需求是被冻结的。

管理Scrum过程有很多实施方法，如即时贴、白板、甚至软件包。 Scrum最大的好处之一是它非常容易学习，而且启动Scrum应用并不需要太多的投入。

Scrum 中的角色

Scrum当中定义了许多角色。按照对开发过程的参与情况，这些角色被分为两组，即猪组和鸡组。这个分组方法的由来是一个关于猪和鸡合伙开餐馆的笑话[16]：

一天，一头猪和一只鸡在路上散步。
鸡对猪说：“嗨，我们合伙开一家餐馆怎么样？”
猪回头看了一下鸡说：“好主意，那你准备给餐馆起什么名字呢？”
鸡想了想说：“叫‘火腿和鸡蛋’怎么样？”
“那可不行”，猪说：“我把自己全搭进去了，而你只是参与而已。”

猪组的成员

猪是在Scrum过程中全身投入专案的各种人物，他们在专案中承担实际工作。他们有些像上边那个笑话里的猪，要把自己身上的肉贡献出来。

  • 产品负责人（product owner）

    产品负责人代表了客户的意愿。这保证了Scrum团队在做从业务角度来说正确的事情。产品负责人编写用户故事，排出优先级，并放入产品订单。

  • Scrum主管（或促进者）（scrum master）

    Scrum主管促进 Scrum过程，他的主要工作是去除那些影响团队交付冲刺目标的障碍。 Scrum主管并非团队的领导（因为团队是自我组织的），而是一个负责屏蔽外界对开发团队的干扰的角色。 Scrum主管确保Scrum过程被按照初衷使用。 Scrum主管是规则的执行者。

  • 开发团队（dev team）

    负责交付产品的团队。一个团队通常由5至9名具有跨职能技能的人（设计者，开发者等）组成，承担实际的开发工作。

鸡组的成员

鸡并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的实践。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。

  • 用户

    软件是为了人而开发的。有人说，“假如森林里有一棵树倒下了，但没有被人听到，那么它算是发出了声音吗？”同样地，人们可以说，“假如软件没有被使用，那么它算是被开发出来了么？”

  • 利益相关者（客户，提供商）

    影响项目成功的人，但只直接参与冲刺评审过程。

  • 经理

    为产品开发团体搭建环境的人。

Scrum 会议

在冲刺中，每一天都会举行项目状况会议，被称为“scrum”或“每日站立会议”。每日站立会议有一些具体的指导原则：

  • 会议准时开始。
  • 欢迎所有人参加，但只有“猪”可以发言。
  • 不论团队规模大小，会议被限制在15分钟。
  • 所有出席者都应站立。（有助于保持会议简短）
  • 会议应在固定地点和每天的同一时间举行。

在会议上，每个团队成员需要回答三个问题：

  1. 昨天你完成了那些工作？
  2. 今天你打算做什么？
  3. 完成你的目标是否存在什么障碍？（Scrum主管需要记下这些障碍）

每一个冲刺完成后，都会举行一次冲刺回顾会议，在会议上所有团队成员都要反思这个冲刺。举行冲刺回顾会议是为了进行持续过程改进。会议的时间限制在4小时。

Scrum提倡所有团队成员坐在一起工作，进行口头交流，以及强调项目有关的规范（disciplines），这些有助于创造自我组织的团队。

Scrum的一个关键原则是承认客户可以在项目过程中改变主意，变更他们的需求，而预测式和计划式的方法并不能轻易地解决这种不可预见的需求变化。同样，Scrum采用了经验方法– 承认问题无法完全理解或定义，而是关注于如何使得开发团队快速推出和响应不断出现的需求的能力最大化。

Scrum会议一共包含以下四种：

  1. 冲刺计划会议
  2. 每日站立会议
  3. 评审会议
  4. 回顾会议。

文档

产品订单

产品订单（product backlog）是整个专案的概要文档。产品订单包括所有所需特性的粗略的描述。产品订单是关于将要生产什么样的产品。产品订单是开放的，每个人都可以编辑。产品订单包括粗略的估算，通常以天为单位。估算将帮助产品负责人衡量时程表和优先级（例如，如果"增加拼写检查"特性的估计需要花3天或3个月，将影响产品负责人对该特性的渴望）。

冲刺订单

冲刺订单（sprint backlog）是大大细化了的文档，包含团队如何实现下一个冲刺的需求的信息。任务被分解为以小时为单位，没有任务可以超过16个小时。如果一个任务超过16个小时，那么它就应该被进一步分解。冲刺订单上的任务不会被分派，而是由团队成员签名认领他们喜爱的任务。

燃尽图

燃尽图（burn down chart）是一个公开展示的图表，显示当前冲刺中未完成的任务数目，或在冲刺订单上未完成的订单项的数目。不要把燃尽图与挣值图相混淆。燃尽图可能在一次冲刺的大部分时间内都维持平坦，但计划仍然可以按照既定时间进行。

功用驱动开发方法（Feature Driven Development, FDD）

  FDD是由Jeff De Luca和大师Peter Coad提出来的。像其他方法一样，它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期一般是两周。
  在FDD中，编程开发人员分成两类：首席程序员和“类”程序员（class owner）。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序员则主要做源码编写。

自适应软件开发（ASD）

  ASD（Adaptive Software Development）方法由Jim Highsmith提出，其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。

参考文献

相关文章

Q.E.D.