软件开发生命周期(SDLC Software development life cycle)和过程模型是软件开发过程的高级表示。这些模型定义了软件开发所经历的阶段（phase），以及在每个阶段所进行的活动。每个SDLC模型代表一个软件项目、迭代或增量，从构思到该版本的产品完成和/或发布。
软件产品生命周期模型代表了软件产品的生命周期，从构思到产品退役。对于一个成功的软件产品来说，产品生命周期通常包含了多次通过软件开发生命周期或过程模型的过程。
生命周期和过程模型为各个软件开发过程的详细定义提供框架（最高级别的过程架构）。定义好的模型作为开发团队的路线图，确保在软件开发过程中实施所有必要的和经过验证的步骤，以便生产出高质量的产品。遵循预先定义的模型及其相关流程，有助于确认包括提高质量的关键步骤。这些模型描述了主要里程碑、基线和项目交付物之间的相互关系。这些模型可以帮助项目经理和/或团队计划活动和跟踪进度，将开发工作分成几个阶段，每个阶段都有一套确定的活动，包括阶段过渡审查。这些模型还提供了一个一致的框架，用于。

• 收集经验教训
• 实施过程改进
• 比较多个项目的结果
• 建立衡量标准
• 提供有用的组织流程资产，可用于更好地估计和规划未来的开发、维护和收购项目。

这些模型多年来通过经验和研究不断完善。组织可以从这些改进中学习，然后采用和调整自己的生命周期和过程模型，以符合他们的需求、业务领域、文化和软件开发方法。

瀑布模型

瀑布模型

瀑布模型是基于这样一个概念：软件开发可以被认为是简单的阶段序列。每个阶段从开始到结束，然后才开始下一个阶段。瀑布模型中一个阶段产生的工作产品通常是后续阶段的输入。瀑布模型的前提是，一个项目可以在开始之前就进行规划，并通过开发以合理有序的方式进行。在瀑布模型中，在设计开始之前，一组定义明确的需求被指定，在编码开始之前，设计已经完成，产品在建成之后被测试。

在实际项目中，阶段的数量取决于项目的需求和进行项目的组织。有些瀑布模型只包括向下的箭头，描述了活动在开发项目中向下的流动。这个例子还包括向上的箭头，表示在开发活动中允许一些迭代。

许多批评瀑布模型的人说，它已经过时了，不能反映软件开发中的真实情况。然而模型是从一个特定的角度对一个项目或过程的抽象表述。模型是一种简化，旨在表达项目或过程的某些方面的要点，而不提供不必要的细节。模型的目的是使有关人员能够思考和讨论这些基本要素，而不被所有的细节所困扰。在这方面，瀑布模型仍然是一个有用的工具，因为它是一个容易理解和讨论的模型。即使是最不成熟的利益相关者也能理解瀑布模型的基本概念。诚然瀑布模型几乎删除了所有的细节，包括开发过程中通常发生的大部分迭代，但这些细节中的许多可能在模型下的较低级别的过程定义中得到说明。

瀑布模型是第一个定义软件开发的规范化方法的模型，易于理解，定义明确。瀑布模型的优点之一是它与软件开发的可交付成果直接相关，这可以帮助项目管理活动。有许多工具可以支持瀑布模型。

瀑布模型的主要弱点是，大多数（如果不是全部）需求必须在开发之初就知道。瀑布模型不容易适应变化。软件产品在项目完成或接近完成时才可以使用，所以该模型不包括对利益相关者的中间反馈的规定，尽管在基于瀑布的开发过程中可以使用原型来提供早期反馈。
瀑布模型最适合于那些需求是已知的并且预期是稳定的项目，并且开发过程预期会以一种有序的、有纪律的方式进行。例如，瀑布模型可能适合于将现有产品移植到一个新的平台、环境或语言的项目，其中的限制因素是众所周知的。其他的例子可能包括更新软件以符合新的政府法规的增强项目，或者使目前正在手工执行的报告自动化的项目。瀑布式生命周期模型也适用于只有几个有经验的程序员和许多初级程序员的项目，或者是在非常成熟的领域中的新开发项目，即正在建立的另一个软件产品，就像上一个产品。瀑布模型通常不适合于需求模糊或预期具有高波动性的项目，或预期不会以线性方式进展的项目。对于大型的、高风险的项目，更多基于风险的方法，如螺旋模型或增量开发可能比瀑布模型更合适。

V型模型

V型模型是瀑布模型的一个变种，它强调了测试阶段和生命周期早期阶段产生的产品之间的关系，验收测试根据概念阶段定义的利益相关者的需求来评估软件，系统测试根据需求阶段指定的产品级需求来评估软件，以此类推。测试规划和设计可以在相应的早期开发阶段显著完成后立即开始。例如，一旦相当数量的利益相关者的需求（概念，在例子中）被定义，验收测试规划和设计就可以开始了。一旦相当数量的产品级需求被定义，系统测试规划和设计就可以开始了。

W-模型

W模型是瀑布模型的另一种变体。W模型有两条路径（或称交叉V），每条路径都代表一个独立的组织或独立团队在开发过程中的生命周期。第一条路径代表开发组织/团队，负责开发需求、设计和代码。第二条路径代表独立的验证和确认（V&V）组织，负责独立分析、审查和测试软件生命周期各阶段的工作成果。

递增/迭代式软件开发生命周期

螺旋模型

螺旋模型最初由Boehm（1988）定义，是一个基于风险的过程模型，它在以前的模型基础上扩展了细节，包括替代方案的探索、原型设计和规划。螺旋模型将软件开发的每个周期细分为四个象限。然后，生命周期的活动以螺旋方式纳入这四个象限，从中间的概念阶段开始。

• 确定目标、备选方案和约束条件。开发团队确定该周期的目标、替代方案和约束条件。例如，在概念阶段，这可能包括探索购买和建造的替代方案，或确定在项目中应该解决哪些业务层面和/或利益相关者层面的要求。
• 识别和解决风险，评估替代方案，并选择方法：评估替代方案，识别和分析风险，并可能进行原型设计，以选择最适合该项目周期的方法。例如，对于概念阶段，这可能包括风险识别和分析购买和建造的选择，对替代方案的成本/效益分析，以及原型设计，以评估选择，以确定在内部建造软件是否是合适的决定。
• 开发和V&V下一层次的产品。开发该阶段的软件产品，并对这些产品进行V&V活动。这也可能包括创建模拟、模型或基准，如果合适的话。例如，对于概念阶段，这可能包括征询、分析和指定业务层面和利益相关者层面的需求，并执行V&V活动来验证这些需求。
• 计划下一个阶段。在这前三项活动中，会做出一些决定并获得一些影响项目计划的额外信息。因此，在螺旋模型的第四个活动中，项目计划被逐步阐述，为后续周期提供更多的细节。这第四步通常以审查和/或其他周期过渡活动结束。例如，对于概念阶段，这可能包括使用概念阶段前三个活动的信息和决定来更新需求阶段和其他后续阶段的项目计划。

然后，这四个象限被重复用于需求周期和高层（架构）设计周期。随着详细设计周期的前两项活动的完成，项目的大部分主要决定已经做出，螺旋模型完成了第三项活动，其中包括详细设计规范和V&V、编码和代码V&V、单元测试、集成和测试、系统测试、验收测试和运营。与其他所有的软件开发生命周期模型一样，螺旋模型可以根据项目和组织的需要进行调整。

螺旋模型将重点从产品开发转移到风险分析和规避上。螺旋模型把注意力集中在早期探索选项上，通过原型设计获得反馈，以验证正确的产品是以最合适的方式建立的。螺旋模型还包括处理变化的机制，通过任何给定的活动或周期的迭代，在进入下一个周期之前，根据需要多次进行。螺旋模型通过强调在获得更多信息时对项目计划的更新，纳入了坚实的项目管理技术。
Boehm（2000）列出了成功应用螺旋模型的六个共同特征。

• "同时而不是按顺序确定工件
• 在每个螺旋循环中考虑主要的螺旋要素。
  • 关键利益相关者的目标和约束
  • 产品和过程的选择
  • 风险识别和解决
  • 利益相关者审查
  • 承诺进行
• 使用风险考虑来确定每个螺旋周期内每个活动的努力程度
• 使用风险考虑因素来确定每个螺旋周期中产生的每个工件的详细程度
• 用三个锚点里程碑来管理利益相关者的生命周期承诺。
  • 生命周期目标(LCO)
  • 生命周期结构(LCA)
  • 初始运行能力（IOC

强调系统和生命周期的活动和工件，而不是软件和初始开发。

螺旋模型是一个复杂的模型，一些利益相关者并不了解或不容易掌握，因此利益相关者可能会发现它难以沟通和使用。螺旋模型需要高水平的风险管理技能和分析技术，这使得它比其他模型更依赖于人。这也意味着，螺旋模型需要一个强大的、熟练的项目经理。螺旋模型的一个弱点是，它不像基于瀑布模型那样与根据合同进行的软件开发的需求相关（例如，与控制、检查点和中间交付的映射）。

螺旋模型适合于那些软件开发方法是非线性的和/或包含多种需要探索的替代方法的项目。对于较小的、低风险的、直接的项目，额外的风险管理、分析和计划步骤可能会增加不必要的额外成本和/或努力。由于螺旋模型具有广泛的灵活性和自由度，固定成本或固定进度的项目可能不适合使用这种模型。螺旋模型也可能不是经验不足的项目的合适选择。

迭代模式

迭代模型其中的步骤或活动被重复多次。这样做可能是为了给需求、设计、代码或测试增加更多的细节，也可能是为了实现小块的新功能，一个接一个。有许多不同的迭代模型。例如，上面讨论的螺旋模型可以作为一个迭代模型来实现，下面的敏捷软件开发生命周期小节中描述的测试驱动开发和功能驱动开发方法也是迭代模型。迭代模型中开发周期从短期的、集中的计划开始，它定义了在该迭代中要实现的功能。每个周期包括设计、编写测试、开发代码、执行测试，并将成功开发的代码整合到该周期的 "基线 "中，然后再设计、编写测试，如此循环。这个过程持续进行，在各个环节都有反馈（来自其他开发者、客户、用户和/或其他利益相关者，以及软件本身），直到功能在分配给增量的时间范围内完成。然后，该增量的输出被发布给利益相关者，他们可能会试用并投入运行，或者只是为下一个开发周期（迭代）提供反馈。

迭代模型的好处包括不需要预先知道所有的需求。明确的需求可以在软件中实现，而较模糊的需求正在被调查和/或稳定下来。新的需求可以被添加到未来的迭代中，因为它们被确认。将高风险的产品/项目分解成更小的部分，也有助于减少风险。构建在迭代模型中的连续反馈回路提供了学习的循环，有助于消除类似错误在产品其他部分的传播，并允许以更大的信心在产品中构建质量。

增量开发

增量开发是指通过使用软件开发的多次传递，构建越来越大的软件需求子集的过程。在增量开发中，需求被确定后，它们被优先分配到计划的增量中，每个增量都是软件开发的一个环节。每一个后续的版本/发行都是可用的，但只具有部分功能（除了最后一次交付，它包括所有的需求）。每个增量可以有自己的软件开发生命周期模型（例如，瀑布式、V型、迭代式）。不要求每个增量都使用相同的模型。例如，前两个增量可以使用瀑布模型，而下一个增量可以改用迭代模型。

增量开发可以按顺序进行，即在开始下一个增量之前完成一个增量。这些增量也可以平行进行。

增量开发的主要优势之一是建立较小的子集比建立一个大系统的风险要小。这使得客户/用户可以收到和/或评估产品的早期版本，其中包含他们最优先的操作需求。这提供了比传统瀑布式项目更早的验证和反馈的机会。增量开发也能很好地适应变化。如果在增量的开发过程中发现了新的或变化的需求，它们可以被分配到未来的增量中，而不会扰乱当前开发周期的时间表和计划。然而，如果新的或改变的需求有足够高的优先级，以至于它们必须被添加到当前的版本中，那么要么是优先级较低的未实施的需求可以滑落到下一个增量中，要么是更新的时间表和其他计划可能需要重新协商。

增量开发模式的一个弱点是，大部分的需求仍然必须在前面知道。根据系统和项目所使用的开发方法，可能需要额外的工作来创建一个能够支持整个系统的架构，并且足够开放以接受每一个新的功能增量的加入。每个发布的增量必须是一个完整的工作系统，即使它不包括所有的预期功能。因此，增量开发对如何选择特定增量的内容是很敏感的，如果它是为了发布到运营中。例如，如果在以后的版本中才安排核销库存的功能，那么发布一个允许核销库存的库存控制系统增量是不可行的。递增式开发还将产品的某些部分提前置于配置控制之下，从而要求正式的变更程序，以及相关的增加的开销，提前开始。最后，增量开发的好处之一是能够更快地将高优先级的软件功能送到客户/用户手中，从而更早地获得他们的反馈。然而，这也可能是一个弱点，如果软件的质量不好。换句话说，开发组织可能忙于修复上一个增量中的缺陷，而没有时间为下一个增量进行新的开发。

增量开发不需要迭代产品生命周期，但它们经常被一起使用。术语迭代开发和迭代正在被使用，特别是在敏捷社区，一般是指增量产品生命周期和迭代开发生命周期的结合。例如极限编程的流程原则将迭代开发周期与增量产品开发相结合，一个迭代的输出成为下一个迭代的输入，以此类推。

演进开发

进化开发发生在现有的运行中的软件产品被更新以实现完善性、适应性或预防性维护。演进开发发生在一个软件产品成功的时候。如果客户/用户喜欢这个产品，他们会想继续使用它，但运行环境很少是静态的。技术在变，利益相关者的需求和优先级在变，业务领域在变，标准和法规在变，等等。因此，聪明的组织在规划他们的软件战略时，会考虑到这些潜在的变化，并计划进行进化式开发。

演进开发和增量式开发的主要区别在于，在进化式开发中，包含所有需求的完整系统已经在运行中使用了一段时间。与增量开发一样，演进式开发建立了一系列连续的不同版本的软件。然而，在演进式开发中，所有的原始需求都被建立在发布到运行中的软件的第一次演进中。增量开发技术可以用来建立任何一个使用遗留软件作为输入的软件演化。每个演进都可以使用与其前身演进相同或不同的软件开发模型。

演进模型的优点之一是，它关注软件的长期成功，因为它改变并适应利益相关者的需求和其他随时间发生的变化。只有当前演化的需求是已知的，但这种方法提供了机会，让客户/用户在交付版本时得到验证和反馈。产品演进可以被出售以资助进一步的开发，并为组织提供利润。事实上，这些演变很多时候是开发组织的 "现金牛"，因为他们为新的和更新的软件提供资金，而不需要从头开始创建一个全新的系统的必要投资。

演进模式的主要弱点可能是时间跨度越长，或者进化的次数越多，有知识的人转到其他项目甚至其他组织的可能性就越大。对于组织在几个月甚至几年内都不知道的需求的长期支持和未来发展需求，努力、费用和其他项目属性可能很难估计。进化的开发只有在强大的客户/用户的参与和投入下才会成功。还有一个风险（和潜在的好处），那就是永无止境的进化。几十年前建立的软件仍然在运行，这并不罕见。在某些时候，可能很难找到具有适当技能的员工，或者找到硬件和其他技术，来支持这些非常老的软件系统。例如，作者知道有一家公司仍在支持一个在20世纪60年代用COBOL编写的旧的遗留工资系统。他们的产品支持团队由程序员组成，他们的年龄从50多岁到80多岁不等，其中许多人正准备退休，或者已经退休并被重新雇用为顾问。这家公司的管理层找不到想要学习COBOL的年轻程序员。当然，解决这个难题的办法是使用新技术将软件重新设计成现代编程语言，这也是管理层现在正在进行的主要投资，以便使软件能够支持到未来。他们目前正在支付两个开发团队的费用，其中一个团队正在支持旧系统，同时将他们的知识传授给建立现代版系统的新一代程序员。

敏捷软件开发的生命周期

应用敏捷生命周期和相关的过程模型，并确定它们的好处以及何时使用。

实际上有很多敏捷方法，包括Scrum、极限编程（XP）、测试驱动开发（TDD）、功能驱动开发（FDD）、Crystal、精益（本书第7章有讨论）、看板等。这些方法中的许多都集中在软件开发的不同方面，是相互补充的。术语 "敏捷 "或 "敏捷开发 "通常用于描述这些方法中的一种，或这些方法中的几种的合并，由一个组织采用和调整以满足其需求，以及其团队、项目和利益相关者的需求。

敏捷宣言，如图9.12所示，是2001年在犹他州雪鸟的一次会议上制定的。这是后来被称为 "敏捷联盟 "的第一次会议。强调 "右边的项目有价值 "这句话很重要，因为有些对敏捷方法的批评让人觉得这种方法拒绝流程、计划、合同和文件。"超过 "这个词是关键。宣言中并没有说 "代替"，而许多批评敏捷方法的人似乎是在暗示。
敏捷联盟（www.agilealliance.com）也定义了以下12条原则来支持敏捷宣言。

• "我们的首要任务是通过早期和持续交付有价值的软件来满足客户。
• 欢迎不断变化的需求，甚至在开发后期。敏捷过程为客户的竞争优势驾驭变化。
• 频繁地交付工作软件，从几周到几个月不等，更倾向于较短的时间范围。
• 业务人员和开发人员必须在整个项目中每天一起工作。
• 围绕积极的个人建立项目。给他们需要的环境和支持，并相信他们能完成工作。
• 向开发团队传达信息以及在开发团队内部传达信息的最有效方法是面对面的交谈。
• 工作软件是衡量进展的主要标准。
• 敏捷过程促进可持续发展。赞助商、开发人员和客户/用户应该能够无限期地保持恒定的速度。
• 持续关注卓越的技术和良好的设计可以增强敏捷性。
• 简洁性，即最大限度地减少未完成的工作的艺术，是至关重要的。
  最好的架构、需求和设计产生于自我组织的团队。
• 每隔一段时间，团队就会反思如何变得更有效，然后相应地调整和调整其行为"。

计划驱动的软件开发方法学侧重于定义程序和方法、人员、工具和设备如何相互作用的 "规则"。在计划驱动的方法论中，通常会强调对过程问题的技术解决方案。

敏捷方法主要关注的是客户、开发者和产品之间的沟通，因为这三者之间的行为非常重要。开发者必须与客户沟通，了解他们的需求以及对这些客户的附加价值。然后，开发人员创建产品，并通过审查和测试与该产品沟通，以验证该产品是否符合其规格。产品通过频繁的原型和建成后的产品演示与客户沟通，这样客户就可以验证产品是否符合其预期用途并按需要工作。然后，客户将任何问题和额外的需求传达给开发人员，反馈继续进行。这种频繁的、高质量的沟通提供了一个持续的反馈回路，以确认正确的产品正在被正确地构建，并在开发周期的早期发现问题，提高最终产品的质量。

敏捷方法强调社会学解决方案。敏捷社区认为，"关注技能、沟通和社区可以使项目更有效、更敏捷。"敏捷软件开发使用的不是以技术为导向的规则，而是 "轻松但充分的项目行为规则 "和 "以人和沟通为导向的规则"（Cockburn 2002）。然后，这些解决方案与适当的技术搭配，以提高效率（例如，促进测试自动化的工具，持续部署，等等）。

敏捷方法适用于 "不确定的需求和不可预测的实施风险 "的软件开发工作。如果开发工作 "依赖于知识创造和协作"，敏捷方法可能比计划驱动的方法更合适（James 2012）。

两种最广为人知和使用的敏捷方法是Scrum和XP（如下所述）。Scrum主要专注于软件开发的计划和监控方面，而XP则专注于技术实施技巧。正因为如此，许多组织将Scrum和XP方法结合起来，因为它们可以很好地互补。

Scrum

Scrum这个词最初来源于橄榄球比赛中的一种策略，它表示通过团队合作 "让一个失去比赛的球回到比赛中"（Schwaber 2002）。Scrum是一个软件开发框架，它定义了一个角色、会议、工作产品和规则的结构。Scrum使用一个短的（例如，两周或四周）增量开发周期，称为冲刺。每个冲刺的目标是在冲刺结束时开发一个完整的可交付产品功能的增量。Scrum定义了三个具体的角色和责任。

• 产品负责人负责建立整体的产品愿景，并负责软件开发工作的投资回报率（ROI）。其他产品负责人的职责包括。
  • 为产品的开发获取初始和持续的资金
  • 代表其他利益相关者，充当需求问题、决策和优先级的最终仲裁者
  • 管理、控制并使产品积压可见，以便每个迭代都能解决产品积压中最有价值的需求。
  • 接受或拒绝每个冲刺阶段所完成的软件版本，并决定产品的交付时间。
  • 规划长期的发布策略
  • 决定何时终止开发
• Scrum团队，也叫Scrum开发团队，是一个自我管理、自我组织的协作团队，有权做出决定并采取必要的行动来实现每个冲刺的目标。Scrum团队是跨职能的、多样化的。该团队必须包括具有实现软件所需的所有技能的成员--需求、设计、代码、技术出版物、白盒和黑盒测试、质量、配置管理、领域和/或法规专业知识等等。除了这些活动，Scrum团队还参与了。
  • 估算工作量
  • 创建冲刺积木
  • 帮助产品所有者审查和确定产品积压的优先次序
  • 识别阻碍开发工作的因素

理想的Scrum团队规模是5到9名成员。对于需要更多人参与的大规模开发工作，Scrum方法论建议组建多个Scrum团队，并使用Scrum of Scrums，由各个Scrum团队的代表组成，以实现团队间的协调。
Scrum主管负责确保开发工作是按照Scrum的实践、价值和规则进行的，并确保开发工作按计划进行。Scrum主管与Scrum团队、产品所有者和其他利益相关者进行互动，以。

• 传授Scrum流程，并充当敏捷教练
• 保护Scrum团队不受外界干扰和干涉
• 帮助获取资源和消除障碍
• 帮助采用、调整和持续改进Scrum流程，以满足Scrum团队和组织的需求
• 主持冲刺计划会议、日常Scrum会议、冲刺回顾会议和冲刺回顾会议
• 促进团队协议的收集，包括关于他们将如何开展工作的协议
• 在每个冲刺期间，捕捉经验数据以跟踪进度并确定Scrum团队的速度（团队交付工作的总体能力）。

在Scrum中，虽然Scrum团队是自我管理的，但管理层负责最终决策，并制定项目必须遵循的章程、标准和惯例。管理层也参与制定项目的目标、目的和要求。管理层参与选择产品负责人，衡量进度，并减少产品积压。

客户、用户和其他利益相关者参与到为正在开发或增强的系统确定产品积压项目的相关工作中。客户和用户收到交付的软件并向Scrum团队提供反馈。客户也可能参与选择产品负责人。

产品积压定义了所有尚未在软件中实现的、打算成为最终产品一部分的已知特性（功能和非功能要求）。产品积压包括对正在建立或增强的系统的业务和技术要求的优先级和持续更新的列表，通常被表述为用户故事。产品积压项目可以包括期望的特性、功能、错误修正、缺陷、要求的增强和技术升级。产品积压也可以包括流程改进。

Scrum过程以愿景开始，包括预期的投资回报率、发布和里程碑。最初的产品积压包含一个优先考虑的产品需求列表（例如，用户故事、用例或功能）。随着时间的推移，会有更多的需求出现，并被优先考虑，添加到产品积压中。

每个冲刺阶段都会有一个由Scrum主管主持的冲刺计划会议。这个会议实际上是两个背对背举行的会议，但许多组织将这两个会议合并为一个会议。在冲刺计划会议的第一部分，Scrum团队和Scrum主管与产品所有者会面，以。

• 确定一个冲刺 "目标"，这是一个对冲刺期间要实现的整体工作的简短描述。这个目标被用来集中精力，并在概念上将冲刺联系在一起。
  根据新的信息，或者自上个冲刺阶段以来添加或返回到产品积压中的任何项目，重新确定产品积压中剩余项目的优先次序。
• 对于Scrum团队就产品积压中的项目提出的任何问题，包括关于内容、目的、意义和意图的问题，从产品所有者那里获得答案。
• 从产品积压中选择Scrum团队认为在冲刺结束前可以转化为可交付产品功能的完整增量的项目--创建冲刺积压。
• Scrum团队使用故事点或努力来估计选定的用户故事。团队将估计的总数与他们在过去冲刺期间的表现进行比较，以此来衡量他们在冲刺期间的工作投入是否过多或过少。估算和速度在第15章中讨论）。
• Scrum团队向产品所有者承诺，他们将尽最大努力交付这些选定的项目。

在冲刺计划会议的第二部分，冲刺活动是通过将每个选定的产品积压项目转化为实施该项目所需的初步任务集来计划的。根据需要，也可以增加额外的任务来进行冲刺。团队可能不会预先知道所有的任务，随着冲刺的进行，额外的任务可能会被添加到列表中。

在冲刺期间，Scrum团队通过执行将冲刺积压项目转化为一个或多个软件产品（软件构建、用户文档等）的任务，将选定的产品积压变成功能的增量。在冲刺期间，Scrum团队还举行简短的每日会议，称为Scrums或每日站立会议。在这些每日Scrums中，每个Scrum团队成员都要回答三个问题。

• 自从上次Scrum会议以来，我已经做了什么工作？
• 在下一次Scrum会议之前，我将做什么工作？
• 我有哪些障碍（问题或难题）？

每个冲刺的主要产出是 "一个潜在的可发货的产品增量"（Schwaber 2007），这是一个工作软件（根据商定的 "完成 "的定义进行测试和完成），其质量足以发货，尽管它可能不具备所有需要实际发货的功能。当Scrum团队在冲刺结束时交付新功能时，交付过程包括。

与产品所有者和其他感兴趣的利益相关者举行冲刺回顾会议，以展示新功能并获得反馈，然后决定是否发布产品（或者在第28章讨论的发布管理计划中作出这一决定）。

• 冲刺回顾，Scrum主管和Scrum团队对上一个冲刺的执行情况进行评估，并根据需要调整团队的流程和工作协议，以便为下一个冲刺进行改进。
• 在每个Scrum结束时，产品所有者决定产品积压上是否有足够的价值继续进行下一个冲刺。

在冲刺期间或冲刺结束时，可能会根据利益相关者的反馈或其他利益相关者的需求来确定新的需求。此外，在刚刚结束的冲刺阶段，可能还有不完整的冲刺积压项目。这些需求将被优先考虑并添加到产品积压中。然后召开下一次冲刺计划会议，再次开始这个循环，重复这个循环，直到所有的功能都被实现，或者产品所有者决定终止开发工作。

积压改进会议不是Scrum的正式会议之一。然而，许多组织发现这些会议对于为下一次冲刺计划会议准备产品积压中的项目很有用。

• 将大的故事/功能或史诗（一个故事太大，无法在一个冲刺阶段实现）分解成小的故事/功能
• 更清楚地定义不容易理解或模糊的故事/功能
• 与利益相关者进行额外的对话，以确定故事的接受标准
• 重新确定新增或改进项目的优先次序

极限编程

极限编程（XP）是一种敏捷的迭代开发方法，它将敏捷开发的思想带到了极致。XP包括测试驱动开发（TDD）技术，开发人员首先编写一个当前软件无法通过的测试，因为他们还没有编写相应的代码，然后编写能够通过该测试的代码。使用重构，开发人员然后改善该代码的质量，消除任何重复的、复杂的或笨拙的结构。这就建立了Beck（2005）所说的测试--代码--重构，测试--代码--重构的自然和有效的 "节奏"。

XP基于以下价值观，其中许多是整个敏捷社区共有的。

• 沟通。XP强调沟通。根据Beck（2005），"在团队软件开发中最重要的是沟通"。

• 简洁性。为了避免对模糊理解的需求和结构的承诺，XP要求设计保持在最基本的东西上，可以在下一次交付/迭代的时间范围内提供所需的功能。一个直截了当的、被广泛沟通和理解的软件结构意味着人们需要正式 "沟通 "的东西会减少。这有助于消除可能混淆有效沟通的含糊不清之处。XP创造了一个缩写YAGNI，"你不需要它"，以强调不要添加当前（已知）功能不需要/不会需要的结构和设计。如果你认为你将来可能需要它，那就等到将来再添加它（基于Succi 2001）。然而，YAGNI并不意味着你不能拥有复杂的软件。YAGNI只是意味着软件应该尽可能的简单，并且仍然满足客户的需求。

• 反馈。XP实践者认为，因为事情会发生变化，所以必须缩短反馈周期，从几周或几个月，缩短到几分钟或几小时。XP团队不断努力获得并利用尽可能多的反馈。

• 勇气。勇气有时会表现为一个人在遇到障碍时愿意去做或尝试一些事情，犯错误，从错误中学习，抛弃不可行的东西，重新开始。在其他时候，勇气可能意味着等待、倾听和学习，直到一个更好的、更简单的解决方案出现。XP实践者必须有勇气说出真相，承认真正存在的东西并处理它。

• 尊重。如果任何一个人的贡献不被其他成员所重视，那么这个团队就不可能像它应该/可以的那样有效。团队还必须有强烈的成功动机和对工作环境的热情。为了达到这个目的，团队成员必须互相尊重，尊重项目，以建立信任和集体责任。

XP提倡以下原则，其中许多也是整个敏捷社区共有的。

• 经济性。XP方法通过以下方式关注经济性。
  • 推迟成本。鼓励项目在做出设计/开发承诺之前，"等到最后的责任时刻"。
  • 赚取报酬。承诺尽快交付有价值的、可运行的软件，并在此后经常交付，这意味着客户将获得软件的好处，而开发组织将更快收到付款。
  • 软件再利用。创建用于重复使用的软件意味着它的价值可以被反复实现，而不是仅仅一次。
  • 业务调整。强调与客户的互动和反馈，创造出的软件产品更有可能具有商业价值，与商业目标和目的相一致，并满足企业的需求。
• 互利：互利意味着关注那些现在为利益相关者、现在为开发者、以及以后为利益相关者和开发者提供价值的活动和产品。
• 接受的责任：XP团队成员 "签署 "实施任务。也就是说，一旦下一次迭代的需求清单被定义、优先级被确定，并被分解为实现这些功能所需的任务，开发人员就会自行分配这些任务。
• 冗余：这意味着使用目标相似的冗余活动，只要它们能增加价值。例如，在使用结对编程后进行测试是多余的，因为这两种活动都是为了消除缺陷--然而，在实践中，测试通常会发现在开发中没有发现的额外缺陷，所以测试是增值的。
• 自我相似性：寻找有效的模式并在其他地方重复它们。寻找能帮助你用昨天的解决方案解决今天的问题的模式。除非是唯一的选择，否则不要去用独特的解决方案来解决管理或流程问题，也不要用需求、设计或代码解决方案。
• 质量。质量必须建立在软件中。引用Beck（2005）的话。
  • "把质量推得更高，往往会导致更快的交付；而降低质量标准，往往会导致更晚、更难预测的交付。"
  • "质量的好处没有明显的限制，只有我们理解如何实现质量的能力的限制。"
  • "质量不是一个纯粹的经济因素。人们需要做他们感到自豪的工作。"
• 流程：XP认为软件开发是一个从一个迭代到下一个迭代的连续流程，而不是一组离散的阶段。
• 失败。失败不是浪费，它使我们能够从错误中学习。试验和错误可能是发现什么是有效的最便宜的方法。
• 机会。学会把问题看作是机会。
  • 改进我们做事的方式
  • 创造更好的软件
  • 建立人际关系
  • 拓展我们的个人知识和技能组合
  • 团队和组织学习
• 反思：改进来自于对问题（或潜在问题）原因的学习，以及找到纠正（或避免）问题的解决方案。XP要求团队不断思考他们在做什么和为什么。这提供了输入和反馈，允许立即重用好的想法和快速消除问题。我们不应该隐藏我们的错误。我们应该暴露它们并从中学习。
• 人性化：XP增加了对人的问题的关注，以便人们和团队能够紧密合作。这种关注对那些习惯于作为个人贡献者工作的人来说可能是新的，甚至是不舒服的。
• 改进：敏捷方法和计划驱动方法都认为，持续改进是有效和高效地实现更高质量和增值的软件的最佳途径。
• 小步走。XP强调以小步快跑的方式做出改变。团队应该寻找最起码的方向，然后对变化进行优先排序，并逐步实施，这样可以减少开销和风险。
• 多样性：在团队中拥有多样性可以帮助产生积极的冲突（新的想法、不同的意见、替代的方法）。

为了将其价值和原则落实到软件开发的日常工作中，XP包括一套主要和必然的实践。XP的主要实践包括。

• 团队共处：软件应该在一个足够大的工作空间里开发，以便整个团队，包括客户，都能在一个空间里一起工作。
• 整个团队。在实施XP项目时，整个跨职能、自我指导的XP团队作为一个单位工作，以完成其目标。
• 信息化的工作空间: XP团队利用工作空间的墙壁来传达重要的、活跃的信息。一目了然，人们应该能够感受到项目的进展情况，并能够仅仅通过查看工作区周围张贴的信息就能发现当前或潜在的问题。
• 有活力的工作：XP强调在可持续的节奏下，从业者只需工作尽可能多的时间就能有成效（每天8小时，每周40小时，不生病来上班）。- XP也鼓励在工作时有合理的玩耍时间，以使个人恢复活力并激发创造力。
• 故事: 开发人员通过要求他们的利益相关者讲述关于谁将使用该系统，如何使用该系统，以及为什么使用的故事来创建系统的需求。这些故事被记录下来，成为第一层次的优先需求，只有在选择实施时才会充实到更多细节。
• 季度周期。以季度为周期，计划（Beck 2005）。
  • "识别瓶颈--特别是那些在团队之外控制的瓶颈
  • 专注于大局--项目在组织中的位置
  • 启动修复
  • 计划本季度的主题
  • 挑选一个季度的故事来解决这些主题"
• 每周的周期。团队的工作是编写测试用例，并在接下来的五天内让它们运行。召开每周计划会议，以。
  • 审查实际进展与预期进展的匹配情况
  • 选择该周要实施的客户故事
  • 根据需要，进一步重新定义每个故事的要求和接受标准
  • 估计实施每个故事所需的工作时间
  • 将故事划分为任务
  • 让每个团队成员自行选择他们负责执行的任务
• 松弛：理想情况下，团队将在所需的时间内完成所有承诺的工作，但在每周的时间表中留有一些松弛，以便在每周的周期内弥补任何不可预见的事件。
• 结对编程：结对编程涉及两个人，其中一个人不断审查另一个人正在开发的东西。关于结对编程的更多细节见第22章）。
• 测试驱动的开发（TDD）：TDD主张在编写代码之前，先编写代码必须通过的测试用例。
• 渐进式设计。一般来说，敏捷方法，特别是XP，不写一些所谓的大设计在前面（BDUF）。也就是说，设计是随着时间的推移而出现的，通过逐步的、持续的努力，致力于反思系统中已经存在的东西和接下来需要的东西。
• 持续集成：XP实践在持续的基础上将每一块改变的（或新的）软件代码集成到系统中，在代码改变的几个小时内创建并测试一个新的构建。这是与传统的瀑布式生命周期行为相反的一端，所有（或大部分）的软件代码在集成开始前就已经写好。
• 10分钟的构建。要想在XP项目中频繁地进行集成，必须能够非常快速地构建系统和运行测试。10分钟构建所代表的目标就是要使之成为可能。

XP的必然做法包括。

• 团队的连续性：高绩效的团队应该长期保持在一起。
• 真正的客户参与。Martin (2003)说，客户是 "定义和优先考虑功能的人或团体"。客户需要与开发团队保持密切联系（如果不是团队的实际成员），并通过积极参与软件的定义和验证（编写测试用例，甚至可能执行测试用例）来对软件负责。
• 协商范围：XP哲学说，如果在一个给定的增量中，有什么东西必须 "滑落"，那应该是范围（功能），而不是操纵成本、进度或质量。由于范围缩小而错过的功能被移到下一个增量。
• 单一代码库：正如前面讨论持续集成时指出的，保持单一代码基线是非常理想的。然而，分支可以在短时间内出现，然后通过频繁的集成将其重新整合在一起，至少每天都要做。
• 共享代码。在团队有了集体责任感之后，团队中的任何人都可以在任何时候改进系统的任何部分（Beck 2005）。这需要采用全团队的编码标准。"如果需要进行改变，处于最佳状态的人（看到立即需要改变的开发者）可以进行改变"（Astels 2002）。
• 代码和测试。XP的 "最小化 "文档方法表明，代码和测试应该是任何其他文档的基础，而不是相反。无论好坏，产品就是软件的作用，所以软件代码和测试是记录产品能力的最终权威。
• 渐进式部署。通过在项目的早期和之后经常递增地部署软件，项目可以定期地展示有形的工作成果。这使得客户也能经常提供有用的反馈，因此，在完成工作和反映工作之间几乎没有时间间隔。对小增量的审查允许经常调整项目方向和快速识别缺陷。对每个小增量的规划也更准确。
• 每日部署。XP的理想是每天把工作的软件送到客户的手中。除了在小的情况下，由于各种原因，这可能是不实际的。然而，重要的是要认识到，软件不被积极使用的时间越长，开发就越有可能偏离客户的最终需求（即使它符合客户最初认为有意义的方向）。