Scrum快速指南

---

---

Scrum - 概述

敏捷已成为软件开发行业中流行的术语之一。但敏捷开发究竟是什么？简单来说，敏捷开发是执行软件开发团队和项目的一种不同方式。

为了理解新的方法，让我们回顾一下传统方法。在传统的软件开发中，产品需求在开始开发之前就已经确定。

瀑布模型

具有此特点最常用的软件开发模型是瀑布模型，如下图所示。但是，在大多数情况下，会添加新的功能，并且之前的需求也可能会发生变化。瀑布模型的结构不适合适应需求的持续变化。此外，用户在产品完全可用之前，无法清楚了解产品的功能。

迭代增量模型

在迭代增量模型中，开发始于有限数量的已最终确定和优先排序的需求。交付成果是产品的可运行增量。从需求到代码开发的一系列活动称为迭代。根据增量的功能以及任何或所有新的、修改的、待处理的需求，将下一批需求提供给后续迭代。后续迭代的结果是产品增强的可运行增量。重复此过程，直到产品完成所需的功能。

用户通常不参与开发工作，这可能会导致沟通差距，从而导致功能错误。参与对开发团队来说是积极的，但对团队的时间要求很高，并且可能会导致延误。此外，迭代期间任何非正式的需求变更都可能导致混淆，也可能造成范围蔓延。基于此前提，敏捷开发应运而生。

敏捷开发

敏捷开发基于迭代增量开发，其中需求和解决方案通过团队协作不断发展。它推荐一个时间盒式的迭代方法，并鼓励快速灵活地响应变化。它是一个理论框架，并没有规定开发团队应该遵循的任何特定实践。Scrum是一个具体的敏捷过程框架，它定义了需要遵循的实践。

敏捷方法的早期实现包括Rational Unified Process（1994）、Scrum（1995）、Crystal Clear、极限编程（1996）、自适应软件开发、特性驱动开发（1997）和动态系统开发方法 (DSDM)（1995）。在2001年发布敏捷宣言之后，这些方法现在统称为**敏捷方法**。

敏捷宣言

敏捷宣言由一群软件开发人员于2001年发布，强调需要给予开发团队、适应变化的需求、客户参与的重要性。

敏捷宣言如下：

“我们正在通过实践和帮助他人实践来揭示更好的软件开发方法。通过这项工作，我们已经开始重视：

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

也就是说，虽然右项也具有价值，但是我们更重视左项。”

……敏捷软件开发宣言，作者：Beck，Kent，等人 (2001)

敏捷宣言条目的定义

左侧宣言条目可以描述如下：

敏捷宣言的关键要素是，我们必须信任人们及其协作能力。因此，开发的具体敏捷方法通过强调整个项目生命周期中的团队合作来充分发挥团队成员的能力。

敏捷的关键原则

敏捷宣言基于以下原则：

敏捷方法

动态系统开发方法 (DSDM)

这是一个用于软件项目的敏捷框架。它用于微调传统方法。DSDM 的最新版本称为 DSDM Atern。Atern 这个名字是北极燕鸥 (Arctic Tern) 的缩写——一种可以长途跋涉的海鸟，它代表了该方法的许多特性，这些特性是自然的工作方式，例如优先级排序和协作。

Scrum

这是最流行的敏捷框架，它特别关注如何在基于团队的开发环境中管理任务。Scrum 使用迭代增量开发模型，迭代时间较短。Scrum 相对易于实施，并专注于快速频繁的交付。

极限编程 (XP)

这是一种敏捷软件开发。它提倡在短开发周期中频繁发布，旨在提高生产力并在可以采用新的客户需求的检查点引入检查点。该方法名称来源于这样一个理念：传统软件工程实践的有益元素被提升到极致。(极限编程是一种软件开发规范，它组织人员以更高效地生产更高质量的软件。) XP 以新颖的方法解决分析、开发和测试阶段的问题，这些方法对最终产品的质量产生了重大影响。

测试驱动开发 (TDD)

这是一种软件开发过程，它依赖于非常短的开发周期的重复：首先，开发人员编写一个自动测试用例来定义所需的改进或新功能，然后生成最少的代码来通过该测试，最后将新代码提升到可接受的标准。

精益

这是一种生产实践，它认为将资源用于除为最终客户创造价值以外的任何目标都是浪费，因此是消除的目标。从消费产品或服务的客户的角度来看，“价值”被定义为客户愿意为之付费的任何行动或过程。精益的核心是用更少的工作来保留价值。

看板

这是一个用于改进和保持高水平生产的系统。看板是组织用来控制库存成本的策略——准时制 (JIT)——实现的一种方法。看板成为支持整体运行生产系统的一种有效工具，并证明是促进改进的绝佳方式。

结论

在过去的10年中，越来越多的成功案例表明，公司通过敏捷实践显著提高了其 IT 开发团队和项目的成功率和绩效。这导致敏捷在各种行业中得到广泛采用，包括媒体和技术、大型公司，甚至政府。

敏捷框架帮助团队从以下方面获益：

• 更快的交付/上市时间
• 减少不确定性和风险
• 通过关注客户价值来提高投资回报率 (ROI)

在这些不同的敏捷方法中，Scrum 在过去的 20 年里在全球范围内被证明是非常成功的。

Scrum - 框架

Scrum 是一个用于开发和维护复杂产品的框架。Ken Schwaber 和 Jeff Sutherland 开发了 Scrum。他们共同支持 Scrum 规则。

Scrum 定义

Scrum 是一种框架，人们可以在其中解决复杂的适应性问题，同时高效且富有创造性地交付具有最高可能价值的产品。

Scrum 是一个流程框架，自 20 世纪 90 年代初以来一直用于管理复杂的产品开发。Scrum 不是构建产品的过程或技术；相反，它是一个框架，您可以在其中使用各种过程和技术。Scrum 使您能够明确产品管理和开发实践的相对有效性，以便您可以改进。

Scrum 框架由 Scrum 团队及其相关的角色、事件、工件和规则组成。框架中的每个组件都有其特定的用途，对于 Scrum 的成功和使用至关重要。

Scrum 的规则将事件、角色和工件结合在一起，管理它们之间的关系和交互。Scrum 的规则将在本教程中详细描述。

注意 - 在整个行业中，存在着一些误解，认为 Scrum 意味着没有文档，Scrum 团队只由开发人员组成，等等。事实并非完全如此；我们将在后面的章节中对此进行澄清。

Scrum 流程框架

在 Scrum 中，规定的事件用于创建规律性。所有事件都是时间盒事件，即每个事件都有最长持续时间。这些事件将在后续章节中更详细地描述。

冲刺

Scrum 的核心是冲刺，这是一个两周或一个月的时限，在此期间会创建一个潜在的可发布产品增量。新的冲刺在之前的冲刺结束后立即开始。冲刺包括冲刺计划、每日站会、开发工作、冲刺评审和冲刺回顾。

• 在冲刺计划中，Scrum 团队会协作规划冲刺中要执行的工作。

• 每日站会是一个 15 分钟的时间盒事件，Scrum 团队可以使用它来同步活动并制定当天的计划。

• 冲刺评审在冲刺结束时举行，以检查增量并在需要时更改产品待办事项。

• 冲刺回顾发生在冲刺评审之后，下一个冲刺计划之前。在这个会议上，Scrum团队需要进行自我检查，并制定一个计划，以便在随后的冲刺中实施改进。

结论

Scrum是一个流程框架，它定义了某些规则、事件和角色来带来规律性。但是，它可以根据需要适应任何组织，前提是不违反基本的Scrum规则。

Scrum - 角色

Scrum团队由三个角色组成，分别是Scrum主管、产品负责人和团队。

Scrum主管

Scrum主管（有时写作Scrum Master，尽管官方术语在“Scrum”之后没有空格）是Scrum流程的维护者。他/她负责：

• 使流程顺利运行
• 消除影响生产力的障碍
• 组织和主持关键会议

产品负责人

产品负责人负责最大限度地提高产品价值和团队的工作价值。如何在不同组织、Scrum团队和个人之间实现这一点可能差异很大。

产品负责人是唯一负责管理产品待办事项的人。产品待办事项管理包括：

• 清晰地表达产品待办事项。

• 对产品待办事项进行排序，以最好地实现目标和任务。

• 优化团队执行工作的价值。

• 确保产品待办事项对所有人可见、透明和清晰，并显示团队将进一步开展的工作。

• 确保团队理解产品待办事项中所需级别的项目。

产品负责人可以自己完成上述工作，也可以让团队完成。但是，产品负责人仍然对这些任务负责。

产品负责人是一个人，而不是一个委员会。产品负责人可以在产品待办事项中代表委员会的愿望，但希望更改产品待办事项优先级的人必须与产品负责人联系。

为了让产品负责人成功，整个组织必须尊重他或她的决定。产品负责人的决定体现在产品待办事项的内容和排序中。任何人都不能告诉团队根据不同的需求集工作，团队也不允许按照其他任何人所说的去做。这是由Scrum主管来确保的。

团队

团队是自组织的和跨职能的。这意味着团队根据项目需要和相关性，由分析师、设计师、开发人员、测试人员等组成。

业内一些人将这个团队称为开发团队。然而，这种说法会导致争议，即团队只能有开发人员而没有其他角色。显然，这只是一个误解。要开发软件产品，我们需要所有角色，这就是Scrum的本质——团队将协同工作。跨职能团队拥有完成工作所需的所有能力，无需依赖团队以外的人，从而可以节省时间和精力。Scrum中的团队模型旨在优化灵活性和创造力以及生产力。

最佳团队规模应足够小，以保持灵活，又足够大，可以在一个冲刺内完成大量工作。如果可能，团队规模应保持在五到九人之间。少于五名团队成员会减少互动，并导致生产力增益较小。超过九名成员需要过多的协调。

Scrum团队每天紧密合作，以确保信息顺利流动并快速解决问题。Scrum团队迭代地和增量地交付产品，最大限度地提高反馈机会。完整产品的增量交付确保始终可以使用潜在有用的工作产品版本。

Scrum - Scrum主管

Scrum主管是一位经过培训的责任人，提供如下服务：

Scrum主管对产品负责人的服务

Scrum主管通过多种方式为产品负责人服务，包括：

• 寻找有效的待办事项管理技术。

• 帮助Scrum团队理解清晰简洁的产品待办事项的需求。

• 理解在经验环境中的产品规划。

• 确保产品负责人知道如何安排产品待办事项以最大化价值。

• 理解和实践敏捷性。

• 根据需要主持Scrum活动。

Scrum主管对Scrum团队的服务

Scrum主管通过多种方式为Scrum团队服务，包括：

• 指导Scrum团队进行自我组织和跨职能工作。

• 帮助Scrum团队创建高价值产品。

• 消除阻碍Scrum团队进展的障碍。

• 根据请求或需要主持Scrum活动。

• 在尚未完全采用和理解Scrum的组织环境中指导Scrum团队。

Scrum主管对组织的服务

Scrum主管通过多种方式为组织服务，包括：

• 领导和指导组织采用Scrum。

• 规划组织内的Scrum实施。

• 帮助员工和利益相关者理解和实施Scrum和经验性产品开发。

• 引起能够提高Scrum团队生产力的变化。

• 与其他Scrum主管合作，提高Scrum在组织中的应用有效性。

结论

Scrum是一个流程框架，它定义了某些规则、事件和角色来带来规律性。但是，它可以根据需要适应任何组织，前提是不违反基本的Scrum规则。

Scrum - 事件

Scrum流程框架可以通过一系列事件和相应的工件来查看。Scrum事件是限时事件。这意味着，在一个项目中，每个Scrum事件都有一个预定义的最大持续时间。这些事件使参与项目的所有人都能够了解项目的进度。Scrum的重要事件包括：

• 冲刺
• 冲刺计划
• 每日站会
• 冲刺评审
• 冲刺回顾

冲刺

在冲刺期间，将开发一个可工作的产品增量。它的持续时间通常为两周或一个月，并且此持续时间对于项目中的所有冲刺保持不变。我们不能让项目中不同冲刺的持续时间不同。在上一个冲刺结束之后，立即开始一个新的冲刺。

冲刺目标是为冲刺设定的目标。它为团队提供指导，说明为什么它要构建增量。它是在冲刺计划会议期间创建的。随着对需求的更多了解，冲刺的范围在产品负责人和团队之间得到澄清和重新协商。因此，每个冲刺都与它相关联，定义了要构建的内容、设计以及将指导构建它的灵活计划、开发工作和最终的产品增量。

如果冲刺目标变得过时，则应取消冲刺。如果组织改变方向，或者市场或技术条件发生变化，则可能会发生这种情况。冲刺只能由产品负责人取消，尽管其他人也会对此产生影响。

由于冲刺的持续时间较短，在冲刺期间取消冲刺很少有意义。由于冲刺取消会消耗资源，以便重新组织到另一个冲刺中，因此它们非常少见。

如果冲刺被取消，并且冲刺期间产生的部分工作可能发布，则产品负责人通常会接受它。所有未完成的冲刺待办事项都将放回产品待办事项中。

冲刺计划

在冲刺计划会议中计划在冲刺中要执行的工作。冲刺计划会议对于两周的冲刺最多持续四个小时，对于一个月的冲刺最多持续八个小时。Scrum主管有责任确保会议举行，并且所有必需的与会者都出席并了解预定会议的目的。Scrum主管主持会议，以监控讨论的持续时间和按时结束。

冲刺计划侧重于以下两个问题：

• 在冲刺增量中需要交付什么以及可以交付什么？
• 如何完成冲刺执行所需的工作？

此会议的输入是：

• 产品待办事项
• 最新的产品增量
• 冲刺期间团队的预计产能
• 团队过去的绩效

Scrum团队讨论在冲刺期间可以开发的功能。产品负责人提供关于产品待办事项的说明。团队从产品待办事项中为冲刺选择项目，因为他们是评估他们在冲刺中可以完成哪些工作的最佳人选。团队由分析师、设计师、开发人员和测试人员组成。工作以协作的方式进行，从而最大限度地减少返工。

然后，Scrum团队提出冲刺目标。冲刺目标是一个目标，它为团队提供指导，说明为什么它要构建产品增量。然后，团队决定如何在冲刺期间将选定的功能构建到可工作的产品增量中。为本次冲刺选择的待办事项加上交付它们的计划，称为冲刺待办事项。

冲刺期间的工作在冲刺计划期间进行估算，其规模和/或工作量可能不同。在冲刺计划会议结束时，工作被划分为持续时间为一天或更短的任务。这是为了方便工作分配和跟踪完成情况。如果团队意识到工作过多或过少，它可以与产品负责人重新协商选定的产品待办事项。

团队还可以邀请其他人（不是Scrum团队成员）参加冲刺计划会议，以获取技术或领域方面的建议或估算方面的帮助。

每日站会

每日站会是团队的 15 分钟会议，每天举行一次，以快速了解自上次每日站会以来的工作，并为接下来的 24 小时制定计划。此会议也称为每日站立会议。

每日站会每天在同一时间和同一地点举行，以降低复杂性。

在会议期间，每个团队成员都会解释：

• 他昨天做了什么来帮助团队实现冲刺目标？

• 他今天将做什么来帮助团队实现冲刺目标？

• 他是否看到任何障碍阻止他或团队实现冲刺目标？

每日站会被误认为是状态跟踪事件，但实际上它是一个计划事件。

会议的输入应该是团队在实现冲刺目标方面的工作进展情况，而输出应该是优化团队在实现冲刺目标方面的努力的新计划或修改后的计划。

虽然 Scrum 主管协调每日站会并确保会议目标得到满足，但会议由团队负责。

如有必要，团队可在每日站会后立即进行任何详细讨论，或重新规划冲刺剩余的工作。

以下是每日站会的益处：

• 改善团队内部沟通。

• 识别任何障碍，以便及早消除，从而最大限度地减少对冲刺的影响。

• 突出并促进快速决策。

• 提高团队的知识水平。

冲刺评审

冲刺评审在每个冲刺结束时举行。在冲刺评审期间，将审查即将发布的增量的演示。在这个会议上，Scrum团队和利益相关者合作了解在冲刺中完成了什么工作。基于此，以及冲刺期间产品待办事项的任何变更，与会者确定所需的下一步，这些步骤可以优化价值。因此，冲刺评审的目的是获得反馈并团结一致地取得进展。

对于两周的冲刺，冲刺评审通常持续两小时；对于一个月的冲刺，通常持续四小时。

Scrum主管确保：

• 会议按时举行。

• 参与者理解会议目的。

• 会议集中于既定议程，并在规定时间内完成。

冲刺评审包括以下方面：

• 与会者包括Scrum团队和产品负责人邀请的主要利益相关者。

• 产品负责人解释在冲刺期间完成了哪些产品待办事项，以及哪些未完成。

• 团队讨论冲刺期间进展顺利之处、遇到的问题以及如何解决这些问题。

• 团队演示已完成的工作，并解答关于增量的任何问题。

• 然后，全体人员讨论下一步该做什么。因此，冲刺评审为后续冲刺的冲刺计划提供了宝贵的输入。

• 然后，Scrum团队审查产品增量下一次预期发布的时间表、预算、潜在能力和市场。

• 冲刺评审的结果是更新后的产品待办事项，它定义了下一个冲刺可能包含的产品待办事项。

冲刺回顾

冲刺回顾在冲刺评审之后和下一个冲刺计划之前进行。对于两周的冲刺，这通常是一个小时的会议；对于一个月的冲刺，通常是一个三小时的会议。

冲刺回顾的目的是：

• 结合上次冲刺中关于人员、关系、流程和工具的经验教训。

• 确定进展顺利的主要方面和潜在的改进之处。

• 制定实施改进以提高产品质量的计划。

冲刺回顾是Scrum团队进行内省和在Scrum流程框架内改进的机会，以便使下一个冲刺的结果更有效。

参考文献

Scrum指南 © 1991-2013 Ken Schwaber 和 Jeff Sutherland，版权所有。

Scrum - 工件

Scrum工件提供Scrum团队和利益相关者需要了解的关于正在开发的产品、已完成的活动和项目中计划的活动的关键信息。Scrum流程框架中定义了以下工件：

• 产品待办事项
• 冲刺待办事项
• 燃尽图
• 增量

这些是Scrum项目中最低限度需要的工件，项目工件并不仅限于这些。

产品待办事项

产品待办事项是作为最终产品一部分所需功能的有序列表，它是对产品进行任何更改的唯一需求来源。

产品待办事项列出了所有构成未来版本产品更改的功能、特性、需求、增强功能和修复。产品待办事项具有描述、顺序、估算和价值等属性。这些项目通常被称为用户故事。产品负责人负责产品待办事项，包括其内容、可用性和排序。

产品待办事项是一个不断发展的工件。其最早的版本可能只包含最初已知和最容易理解的需求。随着产品及其使用环境的进步，产品待办事项也会得到发展。产品待办事项不断变化以包含使其有效所需的内容。只要产品存在，其产品待办事项也存在。

随着所构建产品的应用和价值的提升，产品待办事项将成为一个更大、更详尽的列表。业务需求、市场条件或技术的改变会导致产品待办事项的改变，使其成为一个动态的工件。

产品待办事项细化意味着向产品待办事项添加细节、估算和优先级顺序。这是由产品负责人和团队执行的持续过程。Scrum团队决定如何以及何时进行细化。

产品负责人或经产品负责人同意，可以随时更新产品待办事项。

较高顺序的产品待办事项通常比较低顺序的产品待办事项更清晰、更详细。基于更高的清晰度和更详细的信息，可以做出更精确的估计。顺序越低，细节越少。

可能成为即将到来的冲刺的候选需求的产品待办事项会被细化，以便这些项目可以在冲刺期间得到开发。团队可以在一个冲刺内完成开发的产品待办事项被认为已准备好用于冲刺计划会议中进行选择。

冲刺待办事项

冲刺待办事项是为冲刺选择的 Product Backlog 项目的集合，加上交付产品增量和实现冲刺目标的计划。

冲刺待办事项是团队对将在下一个增量中提供的功能以及将该功能交付为可工作的产品增量所需工作的预测。

冲刺待办事项是一个足够详细的计划，团队可以在每日站会中理解并跟踪。团队在整个冲刺过程中修改冲刺待办事项，并且冲刺待办事项在冲刺过程中逐渐形成。这种形成发生在团队完成计划并更多地了解实现冲刺目标所需的工作时。

当需要新的工作时，团队将其添加到冲刺待办事项中。当工作正在执行或完成时，剩余工作的估算会被更新。当计划中的某些元素被认为是不必要的时，它们就会被删除。在冲刺期间，只有团队才能更改其冲刺待办事项。冲刺待办事项是团队计划在冲刺期间完成的工作的清晰可见的实时画面，它完全属于团队。

增量

增量是冲刺期间完成的所有产品待办事项的总和，以及所有先前冲刺的增量的总和。在一个冲刺结束时，新的增量必须是一个可工作的产品，这意味着它必须处于可用的状态。无论产品负责人是否决定实际发布它，它都必须处于可工作状态。

Scrum团队需要就什么是增量达成共识。这在每个Scrum团队中差异很大，但是，团队成员必须对完成工作意味着什么有一个共同的理解。这用于评估产品增量上的工作何时完成。

同样的理解指导团队了解在冲刺计划期间可以选择多少产品待办事项。每个冲刺的目的都是交付潜在可发布功能的增量。

团队每个冲刺都会交付一个产品功能增量。这个增量是可用的，因此产品负责人可以选择立即发布它。如果增量的理解是开发组织的约定、标准或指南的一部分，则所有Scrum团队都必须至少遵循它。如果它不是开发组织的约定，则Scrum团队必须定义适合该产品的增量定义。

每个增量都是对所有先前增量的补充，并且经过彻底测试，确保所有增量都能一起工作。

随着Scrum团队的成熟，预计他们对增量的定义将扩展到包括更严格的更高质量标准。任何一个产品都应该有一个增量定义，作为对其进行的任何工作的标准。

冲刺燃尽图

在冲刺的任何时间点，都可以对冲刺待办事项中剩余的总工作量进行汇总。团队跟踪每次每日站会的剩余总工作量，以预测实现冲刺目标的可能性。通过在整个冲刺期间跟踪剩余的工作，团队可以管理其进度。

冲刺燃尽图是追踪Scrum团队所花费的工作量的实践。这已被证明是监控冲刺朝冲刺目标前进的有用技术。

产品负责人至少在每次冲刺评审时跟踪此剩余总工作量。产品负责人将此数量与先前冲刺评审中剩余的工作量进行比较，以评估在目标所需时间之前完成预计工作的进度。此信息将与所有利益相关者共享。

结论

Scrum的角色、事件、工件和规则是不可避免的。如果只实施Scrum的某些部分，结果就不是Scrum。Scrum需要完整地实施，如果与其他技术、方法和实践相结合，则功能良好。

参考文献

Scrum指南 © 1991-2013 Ken Schwaber 和 Jeff Sutherland，版权所有。

Scrum - 用户故事

正如您所了解的，用户故事通常用于描述产品功能，并将构成Scrum工件的一部分——**产品待办事项**和**冲刺待办事项**。

用户故事

在软件开发中，产品功能起着至关重要的作用。正是这些功能最终用户希望在最终产品中使用的功能。在一般术语中，它们被称为需求。软件开发项目的成功在于准确和适当地理解用户需求，然后在最终产品中实现这些需求。因此，开发项目团队需要充分了解需求或产品功能。

1999年，肯特·贝克提出了“用户故事”来描述产品功能。他指出，用户故事是从用户的角度出发，描述用户想要什么，而不是系统能为他做什么。因此，视角彻底从产品转向了用户，“用户故事”成为了所有敏捷框架中需求的实际标准。

在Scrum项目中，产品待办事项列表是一个用户故事的清单。这些用户故事会被优先级排序，并在冲刺计划会议中纳入冲刺待办事项列表。

估算也基于用户故事，产品规模以用户故事点来估算。

用户故事结构

用户故事的结构如下：

作为一个 <用户类型>，

我想要 <执行某个任务>，

以便 <我可以实现某个目标/好处/价值>。

让我们看看如何为银行客户从ATM取款的场景构建用户故事。

用户故事：客户取款

作为一个 客户，

我想要 从ATM取款，

以便 我不必在银行排队等候

用户故事验收标准

每个用户故事都定义了验收标准，以便通过基于验收标准的验收测试来确认用户故事的实现是否正确。

以下是客户取款用户故事示例的验收标准：

验收标准1

已知账户信用良好

• 并且卡有效
• 并且出钞机中有现金，

当客户请求取款时

则确保账户已扣款

• 并确保现金已发出
• 并确保卡已返回。

验收标准2

已知账户透支

• 并且卡有效

当客户请求取款时

则确保显示拒绝消息

• 并确保未发出现金
• 并确保卡已返回。

编写用户故事

产品负责人负责产品待办事项列表，也负责用户故事。但这并不意味着只有产品负责人才能编写用户故事。Scrum团队中的任何人都可以编写用户故事，并且随着需求的细化和新功能的添加，这项活动可以在整个项目中展开。

用户故事中的非功能性需求

也可以将非功能性需求纳入用户故事。在给定的ATM示例中，ATM需要全天候（24x7，365天）可用是一个非功能性需求，可以用用例来描述。

管理用户故事

用户故事在产品待办事项列表中进行管理。用户故事按优先级排序。优先级最高的用户故事会被细化到粒度级别，而优先级最低的用户故事则保持较低的细节级别。对于每个冲刺，优先级最高，因此粒度也更高的用户故事会被纳入冲刺待办事项列表。如果要向产品待办事项列表添加用户故事，则首先确定其优先级，然后根据其优先级将其放置在相应位置。用户故事可以随时重新排序优先级。如果需要，也可以删除任何用户故事。

用户故事的好处

• 用户故事的主要好处在于其以用户为中心的定义。这是因为最终将使用该产品的是在相关用户场景中使用该产品的用户。它将最终用户与团队成员联系起来。

• 用户故事的语法本身确保捕获用户想要实现的目标、好处或价值。

• 由于验收标准本身就是用户故事的一部分，因此对Scrum团队来说将是一个额外的好处。

• 可以在项目执行过程中更改用户故事。如果用户故事的范围变得很大，则需要将其分解成更小的用户故事。验收标准中的条件也可以更改。

• 由于在每个冲刺结束时都会向用户交付可工作的产品增量，因此Scrum团队可以在冲刺评审会议上获得用户的反馈。这使得能够持续地将反馈纳入产品中。

结论

Scrum的用户故事使用户更贴近Scrum团队，并避免了最后一刻的意外。

Scrum - 燃尽图

冲刺跟踪通常使用燃尽图来完成。燃尽图显示剩余工作量（以每天的小时数表示）。例如，让我们考虑一个为期两周的冲刺：

冲刺时长：2周

每周天数: 5

每天小时数: 6

资源数量: 6

因此，冲刺开始时总剩余工作量为2*5*6*6 = 360小时。

因此，在理想情况下，剩余工作量每天减少36小时，燃尽图如下所示：

如果冲刺工作按计划每天完成，则Scrum进度几乎与理想曲线一致。

如果冲刺工作延误且未达到时间承诺，则燃尽图如下所示：

但是，由于燃尽图是每天绘制的，并且可以尽早发现进度偏差，因此可以采取纠正措施来满足冲刺时间线。假设团队加班以满足时间线，则燃尽图如下所示：

因此，在冲刺中的任何时间点，都可以直观地了解冲刺中剩余的总工作量，并可以提高满足冲刺时间线的可能性。

结论

燃尽图帮助Scrum团队跟踪其进度以及为实现冲刺目标需要做什么。

Scrum - 估算

在Scrum项目中，估算由整个团队在冲刺计划会议期间完成。估算的目标是根据优先级和团队在冲刺时间框内交付的能力来考虑冲刺的用户故事。

产品负责人确保优先级高的用户故事清晰明了，可以进行估算，并将它们放在产品待办事项列表的开头。

由于Scrum团队整体负责交付产品增量，因此会注意根据产品增量的规模和所需的工作量来选择冲刺的用户故事。

产品增量的规模以用户故事点来估算。一旦确定了规模，就可以通过过去的数据（即每个用户故事点的努力，称为生产力）来估算工作量。

Scrum估算技术

Scrum对用户故事的估算以每个用户故事的难度程度为基础。为了评估难度程度，使用特定的量表。

Scrum估算中使用了几种类型的量表。以下是一些示例：

• 数值大小（1到10）
• T恤尺寸（XS、S、M、L、XL、XXL、XXXL）
• 斐波那契数列（1、2、3、5、8、13、21、34，等等）
• 犬种（吉娃娃……大丹犬）

通常选择估算技术的方式是使整个Scrum团队熟悉并习惯于量表的值。最常用和最流行的技术是基于斐波那契数列的计划扑克。

计划扑克技术

在计划扑克估算技术中，通过玩计划扑克来获得用户故事的估算值。整个Scrum团队都参与其中，这使得估算速度快且可靠。

计划扑克使用一副牌进行。由于使用斐波那契数列，因此牌上的数字为1、2、3、5、8、13、21、34等。这些数字代表故事点。每个估算者都有一副牌。当团队成员举起一张牌时，牌上的数字应该足够大，以便所有团队成员都能看到。

团队成员中的一位被选为主持人。主持人阅读正在进行估算的用户故事的描述。如果估算者有任何疑问，产品负责人将回答。

每个估算者私下选择一张代表其估算值的牌。在所有估算者都做出选择之前，不显示牌。那时，所有牌同时翻转并举起，以便所有团队成员都能看到每个估算值。

在第一轮中，估算值很可能会有差异。估算值最高和最低的估算者解释其估算值的原因。应注意，所有讨论都仅用于理解，任何内容都不应被个人化。主持人必须确保这一点。

团队可以讨论故事及其估算值几分钟。

主持人可以记录讨论内容，这在开发特定故事时会有所帮助。讨论结束后，每个估算者通过再次选择一张牌来重新估算。牌再次保密，直到每个人都估算完毕，然后同时翻转。

重复此过程，直到估算值收敛到可以用于故事的单个估算值。估算轮数可能因用户故事而异。

计划扑克估算的好处

计划扑克结合了三种估算方法：

专家意见：在基于专家意见的估算方法中，会询问专家某项工作需要多长时间或规模有多大。专家根据其经验、直觉或直觉提供估算值。

专家意见估算通常不需要花费太多时间，并且与某些分析方法相比更准确。

类比：类比估算使用用户故事的比较。待估算的用户故事与之前实现的类似用户故事进行比较。由于估算基于已验证的数据，因此会产生准确的结果。

分解：分解估算通过将用户故事分解成更小、更容易估算的用户故事来完成。包含在一个冲刺中的用户故事通常需要两到五天时间来开发。因此，可能需要较长时间的用户故事需要分解成更小的用例。这种方法还确保会有许多可比较的故事。

结论

计划扑克是一种令人愉快且高效的估算方法。由于在得出最终估算值之前会议是开放讨论的，因此团队很容易达成共识，并对所处理的用户故事的实现有一个广泛的了解。

Scrum - 工具

Scrum工具有助于Scrum项目的计划和跟踪。它们提供了一个集中管理产品待办事项列表、冲刺待办事项列表、计划和跟踪冲刺、显示燃尽图、进行每日Scrum会议和进行Scrum回顾的地方。

有许多不同类型的Scrum工具可用。有些是免费的（开源），有些是付费的，还有一些可以获得工具的精简版。但是，要获得所有功能和可扩展性，则需要购买完整版。

可用的Scrum工具

以下是截至目前市场上一些Scrum工具的列表。开源工具用星号(*)标记。

结论

敏捷方法总体上，Scrum方法具体上，并不意味着没有文档工作。Scrum工件已被定义，Scrum规划和跟踪也已完善。

Scrum工具有助于捕获和跟踪有关Scrum项目的信息。工具的选择取决于组织所需的功能，以及对任何其他工具的需求。

Scrum - 优势

Scrum支持客户、团队成员和相关利益干系人之间的持续协作。其时间盒方法和来自产品负责人的持续反馈确保始终提供具有基本功能的可用产品。此外，Scrum为项目中的不同角色提供了不同的益处。

客户收益

Sprint持续时间较短，每次Sprint计划都会优先处理用户故事。它确保每次Sprint交付时都包含客户立即需要的功能。此外，如果客户提出任何变更请求，它将被吸收到当前Sprint中，或包含在下一个Sprint中。因此，开发团队能够快速响应客户的需求。

组织收益

组织可以专注于开发优先级用户故事所需的工作，从而减少额外开销和返工。由于Scrum为客户带来的特定好处，开发团队效率提高，客户满意度提高，因此可以实现客户留存和客户推荐。它增加了组织的市场潜力。

产品经理收益

产品经理在项目中扮演产品负责人的角色。产品负责人的职责是确保客户满意度。由于Scrum促进了快速响应、工作优先级排序和吸收变更，产品经理可以轻松确保工作符合客户需求，进而确保客户满意度。

项目经理收益

项目经理在项目中扮演Scrum Master的角色。Scrum的协作性质促进了轻松而具体的规划和跟踪。使用燃尽图来了解剩余工作，以及每日Scrum会议让项目经理始终了解项目的进度。这种意识对于监控项目以及快速发现和解决问题至关重要。

开发团队收益

由于Sprint的时间盒性质以及在每个Sprint结束时交付可工作的产品增量，开发团队会热情地看到他们的工作立即得到应用。内置的团队协作使团队享受他们所做的工作。由于每个Sprint的用户故事都基于客户优先级，团队也了解他们的工作是有价值的。

Scrum - 认证

Scrum认证由Scrum联盟提供。提供的认证包括：

• 认证Scrum Master (CSM)
• 认证Scrum产品负责人 (CSPO)
• 认证Scrum从业者 (CSP)
• 认证Scrum教练 (CSC)
• 认证Scrum培训师 (CST)

认证Scrum Master (CSM)

认证Scrum Master是成为Scrum联盟成员、扮演Scrum Master角色以及获得其他认证的基础认证。该认证需要参加CSM课程。之后，候选人会收到一封电子邮件，其中详细说明Scrum会员资格和CSM在线考试的详细信息。参加考试后，候选人将获得认证Scrum Master (CSM) 认证。

认证Scrum产品负责人 (CSPO)

认证Scrum产品负责人是成为Scrum联盟成员、扮演产品负责人角色以及获得其他认证的基础认证。

认证Scrum从业者 (CSP)

认证Scrum从业者是面向经验丰富的Scrum Master和产品负责人的认证。候选人应至少担任一年Scrum Master或产品负责人。候选人必须提交一份申请，其中包含对其在指定角色中所做工作的详细描述。

如果候选人积极从事Scrum Master角色或产品负责人角色达规定时间，则可以在获得CSM认证或CSPO认证后立即获得CSP认证。

认证Scrum教练 (CSC)

认证Scrum教练是面向专注于教练的人员的认证。该认证要求候选人在过去5年中至少指导Scrum团队采用和掌握Scrum 1500小时。

认证Scrum培训师 (CST)

认证Scrum培训师是面向想要教授CSM或CSPO课程的人员的认证。申请人必须拥有CSM或CSPO认证，并且在申请前至少担任一年CSP。

Scrum - 常见问题

以下是关于Scrum的一些常见问题：

问题：Scrum和敏捷开发有什么区别？

答案：敏捷开发是一种软件方法，而Scrum是遵循敏捷的一种流程框架。

问题：Sprint和迭代是一样的吗？

答案：Scrum的Sprint和迭代增量模型的迭代都会交付可工作的产品增量。但是，它们的区别在于：

• Sprint和迭代的生命周期不同。
• Sprint是时间盒的，而迭代不是。
• Sprint的持续时间比迭代的持续时间短得多。

问题：Scrum Master是一个职位名称，还是一个现有职位的人员担任的角色？

答案：Scrum Master是一个现有职位的人员担任的角色。通常的做法是，担任项目经理角色的人也担任Scrum Master的角色。

问题：产品负责人和Scrum Master的角色可以由同一个人担任吗？

答案：不可以，因为所有权不同。产品负责人负责产品待办事项、用户故事的优先级排序以及使用分配给Sprint的用户故事验证可工作的产品增量。

问题：Scrum项目不需要任何文档吗？

答案：不是的。Scrum项目，像任何其他项目一样，需要文档，例如用户故事、设计、测试用例等。

结论

敏捷和Scrum并不相同。Scrum是采用敏捷的一种流程框架。建议经验丰富的团队成员使用Scrum，因为该框架需要大量的协作和自我组织。如果严格遵守Scrum规则，项目可能会失败。因此，整个团队必须充分理解Scrum的概念。由于Sprint持续时间短且是时间盒的，即使Scrum Master持续监控项目，也没有时间在工作中学习Scrum的细节。