Scrum 解释

引言

Scrum 是一个框架（而不是一个过程），用于产品开发。虽然它在软件开发方面非常有名，但它可以应用于任何需要智力劳动的产品开发。大规模生产元素不需要 Scrum。然而，本文将重点介绍 Scrum 及其在软件开发中的应用。

如上一段所述，Scrum 是一个框架，这意味着：Scrum 告诉你做什么，但不告诉你怎么做。这就是这个框架的力量所在，也是它的弱点所在。你会发现这个框架很容易理解，真的，它很简单。关键在于如何正确地实现它。每当一个团队尝试实现 Scrum 时，他们都会发现很难严格遵守，这主要是由于两个因素：首先，强烈的人际互动和讨论至关重要，而这通常并非易事，尤其是在软件开发者之间；其次：Scrum 会将你面临的问题摆在你面前，却不给你任何解决办法。

瀑布式过程，如CMM，非常依赖文档；其思想是让开发过程尽可能独立于相关人员。因此，这些过程更容易遵循，因为你（团队）被明确告知要做什么。Scrum 采取了相反的方法：它侧重于人——人是开发过程的支柱。在我看来，这是一个巨大的思维模式转变，因为CMM类过程的核心问题之一是它们完全忽略了相关人员，这会导致巨大的问题，例如：无论你写了多少文档，文档都不够；文档内容与代码内容存在大量矛盾，等等。

如前所述，Scrum 会将问题摆在你面前，却不给你解决方案。这很有趣，因为面向纸张的过程隐藏了这些问题，尤其是当它们是与人相关的问题时。每当 Scrum 将这些问题摆在你面前时，你有两个选择：要么承认并面对它们，要么指责你正在遵循的方法论，而忽略了摆在你面前的真正事物。这通常与前面提到的，与人相关的问题有关。也许团队成员合不来，也许你的客户很难打交道，也许 Scrum Master 或 Product Owner 不合格。

尽管执行困难，Scrum 也有一些优势，使其使用非常有价值。它拥抱变化：这是瀑布式过程中的最大问题之一。每当需要更改任何内容时，都必须进行长期分析，修改文档，最后修改产品本身。此外，在这些过程中，变化并不受欢迎——它总是被避免的事情。另一方面，Scrum 拥抱变化，它欢迎变化。Scrum 认识到软件开发中的变化是自然的，这意味着产品正在被使用。

另一个优势是刚才讨论过的：框架向你展示的问题。Scrum 是诊断问题的绝佳工具。诚然，它不告诉你如何解决它，但它肯定会指出你需要解决的问题。

迭代开发和交付也是 Scrum 的一个很好的特点。在 Scrum 框架中，产品不是在完成后才展示给客户，而是不断交付。这样，就可以请求持续的反馈，并将建议的更改很快地纳入产品。

最后，尽管这是一个漫长的介绍，但希望它已经说服你继续阅读本文，以便更好地理解 Scrum 的工作原理。接下来将讨论敏捷宣言，以便你理解 Scrum 的支柱。之后，将概述整个过程。然后，将详细解释框架的每个成员以及 Sprint 的每个部分。最后，将解释主要的产物和杂项概念，并将所有内容与最后的讨论结合起来。

敏捷宣言

《敏捷宣言》有一套 Scrum 所遵循的原则。以下是这些原则，你会注意到其中一些已经在引言中讨论过了。

 

个体和互动高于流程和工具

可工作的软件高于详尽的文档 

客户协作高于合同谈判 

响应变化高于遵循计划

尽管它们相当不言自明，但稍后将进行讨论。

第一个，“个体和互动高于流程和工具”在引言中已经提到。它指出，软件开发应以人为本，而不是以工具和纸质文件为中心。这认识到人是产品成功的关键，而不是创建的纸质文件或使用的工具。在 Scrum 中，这一点贯穿整个框架。在评审会议中，整个团队建议并采取行动来改进整个软件开发。在计划会议中，团队决定如何实现软件，并决定是否可能在 Sprint 中完成所需的工作量。

“可工作的软件高于详尽的文档”主张，与其分析和描述产品的海量文档，不如更侧重于产品本身及其开发。这并不意味着不应创建任何文档，而是仅创建足够构建产品的文档。在 Scrum 中，每个 Sprint 都必须交付可交付且可发布的最终产品，即使是第一个 Sprint。如果您希望记录任何内容，请在 Sprint 中进行，并在产品开发过程中进行。这当然优先于软件文档。

“客户协作高于合同谈判”指出，与其严格按照合同开发产品，不如基于用户持续的反馈来构建产品，这样它会更有用。这里认识到用户在开始使用软件之前并不知道自己真正想要什么。在互动之后，会提供持续的反馈，开发会根据反馈进行调整。在 Scrum 中，每个 Sprint 结束后都会有交付，以便最终用户可以提供持续的反馈。这显然使最终用户与正在开发的产品进行了大量协作。请注意，可以定义最小范围，以便产品灵魂（如果我这样称呼它）仍然存在。但是，如果同意，甚至不需要这样做。

最后，“响应变化高于遵循计划”讨论了过程的不断变化——没有固定的过程遵循。对于 Scrum，在评审会议中，会讨论和改进过程。假定它从来不是完美的——需要持续改进。因此，这里没有最终计划，永远没有。

概述 

这里将概述整个过程。尽管您可能不熟悉这里的所有术语，但它们将在后面的部分中进行更详细的解释。其目的是让您对整个过程有一个普遍的了解，以便在阅读后续部分时，您能更好地理解每个部分如何融入整个框架。

 

上图是 Scrum 过程的经典表示。首先，定义产品待办事项列表，它基本上是待开发的功能列表。每个 Sprint，产品负责人会选择一组要开发的功能，团队必须同意执行。这一组功能称为 Sprint 待办事项列表。在协商完这些功能后，团队就有了 Sprint 的目标，基本上是他们同意的集合。呈现 Sprint 工作，团队和产品负责人就目标达成一致，并将功能分解为要开发的任务的会议，称为计划会议（团队如何准确地分解和开发任务不属于 Scrum 框架）。

计划会议之后，Sprint 开始，团队成员开发 Sprint 的任务。Sprint 的持续时间因团队而异，没有固定的规则来确定。强烈建议 Sprint 具有相同的持续时间，只要足够即可。在 Sprint 期间，有一个所谓的每日站会，这是一个 15 分钟的会议，团队提供他们的任务状态，并在出现任何障碍时发出警报。与此同时，Scrum Master 负责解决可能出现的任何障碍。

在每个 Sprint 结束时，将功能呈现给产品负责人，产品负责人必须批准或不批准所显示的内容，在称为评审的会议中。最后，在回顾会议中，团队、Scrum Master 和产品负责人讨论在整个过程中应该改进什么。

角色  

Scrum Master  

Scrum Master 负责确保团队理解并遵循 Scrum 框架。他或她还负责解决可能出现的任何障碍。请注意，这并非易事。

Scrum Master 必须解释，更重要的是，说服团队使用 Scrum 过程，而对他们没有任何权威。当然，团队知道他们必须遵循框架，但要做到这一点，他们必须遵循 Scrum Master 的领导，而 Scrum Master 的领导仅基于论证，这很难做到。请注意，Scrum Master 在评审会议中帮助团队改进开发过程和团队应用 Scrum 框架是自然的。

消除障碍更难。这意味着任何阻碍团队或产品负责人完成工作的因素，都必须由 Scrum Master 解决。请注意，这可能是与客户、第三方供应商、其他团队甚至管理者的问题。因此，Scrum Master 必须非常熟练，才能知道如何有效地处理这些不同的领域。这可能是 Scrum Master 最困难的任务，因为他或她可能不得不处理他或她无权干预的情况，因此必须非常有创意地解决问题。

产品负责人 

产品负责人代表客户的声音。这意味着他或她确切地知道客户对要开发的产品有什么要求。在理想世界里，产品负责人就是客户本人，但在现实生活中这几乎是不可能的。

产品负责人完全了解要开发的功能、它们在产品中的优先级，并且必须能够回答有关产品的任何问题；毕竟，他或她代表客户。

产品负责人负责维护所谓的“产品待办事项列表”，这是一个要实现的功能列表。此列表按优先级排序。这些功能如何描述由产品负责人决定，这意味着 Scrum 框架不规定应该如何描述。因此，可以是需求、图纸、用例或用户故事。如今，在 Scrum 中描述这些功能最常用的方法是用户故事。

产品负责人还负责决定每个 Sprint 的功能是什么。这需要与团队协商，但产品负责人完全了解需要实现什么，并需要确保一切都按要求完成。

在每个 Sprint 结束时，评审会议，产品负责人批准或拒绝实现的功能。他或她还可以根据在评审中看到的内容为后续 Sprint 提供建议。

最后，产品负责人负责规划发布。由于他或她完全了解产品需要什么，因此他或她是该任务的自然选择。

尽管产品负责人对产品的功能负最终责任，但这并不意味着他或她不能与团队讨论产品的功能。相反，强烈建议产品负责人从团队那里获得尽可能多的反馈，因为他们是开发产品的人，可以提供有价值的建议。

团队

团队是一群开发产品的人。他们负责设计、实现、测试和修复正在构建的产品中的错误。有人可能会说，他们是完成工作的人。

这很明显，但他们确实必须遵循 Scrum 过程。请注意，其他两个成员如何融入团队的目的。

 产品负责人向团队提供有关正在开发的产品的信息。产品负责人确保团队遵循正确的路径，并确保最终产品的质量良好（这与代码无关）。

Scrum Master 指导团队尽可能接近其原则地遵循 Scrum 框架。Scrum Master 还主持评审会议，并帮助团队改进开发过程以及团队应用 Scrum 本身。

冲刺

Sprint 是开发的基本单位。如果您希望为软件添加新功能，则必须等待下一个 Sprint。Sprint 包含以下软件开发过程：计划、开发产品、每日站会、评审演示以及回顾讨论哪些方面做得好以及哪些方面可以改进。
 
一个 Sprint 完成后，下一个 Sprint 就开始，直到产品完成。因此，通过将开发过程划分为 Sprint，就可以打开更改请求。当最终用户有反馈要修改已创建的内容，甚至将要开发的内容时，他或她可以请求更改，并且可以在下一个 Sprint 中实现。请注意，这个框架中的内容有多么自然。不会有麻烦，因为不需要进行大量的分析，也不需要处理大量的纸质文件。当然，关于对产品及其代码的影响的分析可能还有空间，但这仅此而已。
 
最难回答的问题之一是：“Sprint 要多长时间？”这是一个很难回答的问题，因为没有明确的答案。有些团队需要一到两周，有些团队需要一个月。所以，关键是，团队必须进行实验，看看需要多长时间。对于来自更传统的软件方法论的人来说，这听起来有些奇怪，但 Scrum 在很大程度上是关于试错的，因为对于一切都没有正确且唯一的答案，这是一个典型的例子：Sprint 大小。因此，为了让团队找出 Sprint 需要多长时间，团队必须尝试几种替代方案。
 
现在您已经了解了 Sprint 的工作原理，接下来的部分将详细描述 Scrum 框架的每个阶段。

 

计划会议  

Sprint 从这里开始。产品负责人从产品待办事项列表中选择要开发的功能集。这里要开发的功能存储在所谓的 Sprint 待办事项列表中。产品负责人将这些功能及其优先级以及 Sprint 目标（稍后详细介绍）呈现给团队，团队同意或不同意开发所有这些活动，以实现当前 Sprint 的既定目标。

关于目标的一致性还有另一个重要观点。团队可能认为提出的要求过于激进，没有足够的时间来完成。发生这种情况时，团队必须向产品负责人解释他们的信念，并且必须就一个可行的目标达成共识。达成之后，计划会议的第二部分开始。

然后，团队估算活动（通常是用户故事），以确定他们是否真的能够做到。如果不能，他们可以再次联系产品负责人，并再次讨论目标，达成新的共识。

现在是时候讨论用户故事和积分估算了。Scrum 不规定功能的描述方式，也不规定它们应该如何估算。在 Scrum 中，通常使用用户故事来描述功能，并使用故事点进行估算。本文将使用它们作为示例来描述 Scrum 框架，但请记住，可以使用任何其他策略。

回到计划会议，在确定估算后，团队将活动（用户故事）分解为可分配给开发人员的任务。通常一名开发人员负责一项任务，但允许多名开发人员参与一项任务也没有问题。这里的想法是让整个团队了解要开发什么，最重要的是，要如何开发。理论上，团队中的任何成员都可以开发讨论过的任何任务，尽管在现实生活中这可能不成立。总之，想法是让整个团队了解正在发生的事情，并且整个团队尽可能多地了解正在开发的rible代码。

分解完任务后，团队开始工作。

开发

这不完全是一个阶段，这是团队在 Sprint 开发期间应该如何表现。在分解了任务并让整个团队了解要做什么之后，工作就开始了。

在计划会议中，当功能呈现给团队时，它们也被优先排序了。因此，团队必须选择优先级最高 的任务。这有时可能非常难以完成，因为一些团队成员可能自然倾向于从事他们更熟悉的活动，而这些活动不在优先级层级的顶端。然而，在 Scrum 中，想法是首先完成最重要的功能，所以如果有什么遗漏，那就是不太重要的东西。

这就像酒店里有几个房间要打扫的比喻。假设你有九个房间要打扫，五个人来做这项工作。时间非常紧张，可能无法完成。每个人开始打扫自己的房间听起来更自然。但是，如果时间不够，没有人能按时完成，就没有房间可供客人使用。另一方面，如果你把五个工人放在一个房间里，当他们完成时，他们就去下一个房间，你也无法打扫所有房间，但你可能会打扫两到三个房间，这比一个房间都没有要好得多。

这就是 Scrum 的理念，让整个团队致力于一个功能或用户故事，当他们完成后，就转向下一个。当然，可能会出现这种情况，即由于人太多而无法让每个人都参与同一项任务。在这种情况下，应该让一部分人处理优先级最高 的任务，而团队的其余部分应该处理优先级第二高 的任务。

在完成优先级最高 的活动后，团队转向下一个，依此类推。

产品负责人必须随时待命，回答团队的问题，提供建议，并解决他们关于需求的所有疑问和问题。每当出现过程问题或障碍时，团队应联系 Scrum Master，Scrum Master 负责在这方面提供帮助。

团队每天都会召开所谓的每日站会，以提供他们的状态并寻求帮助。想法是让每个人都了解开发状态。从这次会议中出现的问题应稍后在单独的会议中讨论。

在 Sprint 结束时，团队向产品负责人展示已开发的功能，产品负责人批准或拒绝这些功能。最后，团队讨论 Sprint 中哪些方面做得好，哪些方面做得不好，哪些方面可以改进，以便不断完善开发过程。

每日站会  

每日站会，顾名思义，每天都要召开一次会议，团队的每个成员都必须回答以下问题：

1. 从上次每日站会到现在，我做了什么？
2. 在下次每日站会之前，我计划做什么？
3. 我是否有任何障碍（任何类型的障碍）？ 

通过回答这些简单的问题，可以确定许多事情。首先，如果一名团队成员的状态与上次会议相同，则意味着他或她被问题卡住了，因此需要帮助。第三个问题是识别某人遇到麻烦的更直接方式。如果确定了问题，Scrum Master 应帮助该人员解决问题，方法是让其他人提供帮助，或使用任何其他必要手段。这将在另一个会议中进行，因为每日站会仅用于状态目的。

强调会议必须最多进行 15 分钟非常重要。如果超过这个时间，则意味着会议没有正确进行。这可能是因为讨论了超出范围的其他事情，团队成员太多，人们在闲聊等等。因此，请准备好在回顾会议中讨论为什么每日站会花费如此长的时间，因为这在新 Scrum 团队中经常发生。

评审会议 

评审会议是团队通过演示向产品负责人展示所开发内容的会议。然后，产品负责人评估他或她是否批准或拒绝已开发的内容。请注意，即使产品有错误，他或她也可以批准。只要产品是可交付的，产品负责人就可以接受它，并将修正留到后续的 Sprint。

最终客户可能出席评审会议。这非常可取，因为可以立即获得反馈。团队更容易理解客户的需求，这使团队更接近客户。这段关系通常不被重视，但所有有过与客户互动经验的人都知道它对产品开发有多么积极的贡献。

请注意，Sprint 可能会失败，原因可能是产品负责人不喜欢所展示的内容，或者没有足够的时间来开发所有已同意的内容。这听起来可能有些奇怪，但在项目刚开始时经常发生，因为团队不知道开发一组功能需要多长时间。因此，当这种情况发生时，团队必须意识到失败并尽最大努力在下一个 Sprint 中改进。如果所有 Sprint 都失败了，并且没有做出任何相关的纠正，这就成了一个问题。

评审会议之后是回顾会议，接下来将进行描述。

回顾会议 

这是有时会发生激烈讨论的地方。团队成员与 Scrum Master 一起讨论如何改进当前的开发过程。产品负责人可以出席，但他的出席不是强制性的。同样，每个人都必须回答三个问题：

1. 与上次 Sprint 相比，我们改进了什么？也就是说，我们应该继续做什么？
2. 下一轮我们能改进什么？
3. 我们应该停止做什么？

通过回答这三个基本问题，团队就能大致了解如何改进软件开发过程。在此会议中，有时会发生很多指责和推卸责任的情况，应由 Scrum Master 控制，因此请注意。

这是持续改进的基础。如果会议成功举行，团队将不断改进其开发过程。如果他们认为总有需要改进的地方，那么这次会议将是永无止境的需求；尽管完美是不可能的，但在整个产品开发过程中将取得显著的改进。

产物 

这里将介绍本文中提到的产物，以及一些未提及的产物。

产品待办事项列表  

 

产品待办事项列表是一个按优先级排序的待开发软件功能列表。产品负责人负责创建和维护此文档。请注意，随着最终用户在 Sprint 中不断提供反馈，此列表的内容和优先级都会发生变化。最终用户可能会注意到他或她希望为某些任务赋予更高的优先级，拥有不同的功能，甚至放弃最初认为必要但随着最终用户体验产品而发现它们并不需要的功能。

产品待办事项列表中优先级最高的功能是进入 Sprint 待办事项列表（下一节讨论）的功能。

通常，产品和 Sprint 待办事项列表中的功能被描述为用户故事，但它们也可以是任何内容。此外，功能的优先级越高，其描述就越详细。请注意，如果一个功能优先级较低，则无需详细描述，因为它甚至可能不会被实现。

最后，请注意，产品待办事项列表是一个动态文档。每个 Sprint 结束时，根据最终用户的输入，此文档可能会发生一些变化。

Sprint 待办事项列表 

 

此文档包含在特定 Sprint 中要开发的功能列表（用户故事），当团队和产品负责人就当前 Sprint 将实现的功能达成一致时。这些功能被放置在一个有序列表中，称为 Sprint 待办事项列表。此列表将由团队攻克并实现，按顺序完成优先级最高的功能。

请注意，Sprint 待办事项列表还包含团队分解的任务。因此，它可以完整地描述要开发的内容。还可以向此文档添加估算和完成百分比，以便轻松可视化进度。

燃尽图 

查看 Sprint 进度的常用工具是所谓的燃尽图。该图基于从以前 Sprint 中提取的平均开发速度，显示了团队在目标方面的进展。

上图描绘了燃尽图。蓝线显示了团队在开发用户故事方面的进展，而绿线显示了预期，即基于以前 Sprint 的速度。

速度之前没有讨论过，所以这里是它的意思。每个 Sprint 都会估算用户故事。基于此，可以测量速度，即完成的用户故事点数除以 Sprint 的天数。此度量提供了 Sprint 中每天要开发的内容（速度）。Sprint 越多，此度量越准确，因为对于每个 Sprint，我们可以使 Sprint 速度更精确。关于“用户故事估算”的内容将更多地讨论。

杂项

这里将讨论几个之前未触及但与 Scrum 主题高度相关的内容。

就绪定义

就绪定义收集了当前 Sprint 中用户故事要开发的必要条件。换句话说，要使用户故事被认为是就绪的，它必须满足一组条件，表明它已准备好开发。这些条件应在团队、Scrum Master 和产品负责人之间定义。以下是一些条件示例（同样，它们不是强制性的，必须符合项目的需要）：

• 必须有关于如何测试用户故事的描述。
• 团队成员应该阅读用户故事并完全理解它。
• 对于用户故事，必须定义完成概念（下一章）。

强制执行仅在用户故事被认为是就绪时才实现的策略有一些优点。首先，它避免了用户故事开始开发，几天后由于需要信息来完成而停止。请注意，这会浪费团队的时间，并大大增加了 Sprint 失败的可能性。其次，团队有权拒绝用户故事（如果它尚未就绪）。这迫使产品负责人只推送真正就绪的用户故事，并且同样，团队的时间不会被浪费。

完成概念

完成概念是定义用户故事完全实现所需的内容。这非常重要，因为团队必须就此达成共识，否则一个人可能认为用户故事已实现，而另一个人可能认为用户故事已完成，代码已审查，并且由其他开发人员完全测试。

请注意，当这个概念被正确定义并且整个团队遵循它时，用户故事就会开始具有更好的标准和恒定的质量水平，因为每个人对用户故事实现的就绪程度都有相同的理解。

另外，这一点非常重要，用户故事要就绪，必须能够交付给最终用户。因此，至关重要的是，团队认为适用的所有良好实践都必须包含在完成概念中。

Sprint 目标 

目标是团队为当前 Sprint 要开发的；目标说明了当前 Sprint 将向产品添加什么。即使团队不开发所有活动，也可能实现目标。此外，即使产品存在要修复的错误，也可以实现目标。由产品负责人决定目标是否已实现。以下是一些目标示例：

• 向软件添加创建和列出用户、客户和产品的功能。
• 使客户创建界面更加用户友好。此外，添加产品注册能力，并修复系统中管理屏幕中的 CSS 错误。

请注意，目标非常直接，是面向功能的声明。它们确实代表要添加到软件的功能或要修复的内容。

用户故事中的估算  

在传统的瀑布式过程中，估算通常以小时、天、周等为单位。用户故事估算采取了另一种方法。它们使用比较来完成。这种方法的思想如下：人类不擅长精确地说出事物的尺寸或时间。例如，如果你给某人看一支笔，他或她将很难说出它的尺寸。但是，如果你给某人看一支笔和一支铅笔，他或她会很容易分辨出哪个更大。因此，尽管人类不擅长给出绝对估算，但他们非常善于比较度量——很容易看出哪个更大。功能大小也是如此。要说明创建用户注册 UI 需要多长时间可能很困难。但说这个 UI 比创建一个仅显示弹出消息的屏幕花费的时间要长得多，这要容易得多。

所以，对于用户故事，你定义一个故事作为一个默认故事，并任意设置它的值。值应该是斐波那契数列：1、3、5、8、13、21、34、55……无穷大（Scrum Poker 卡片的值略有不同，用于近似）。如果你选择，例如 8 作为一个默认故事，当估算下一个故事时，你的问题应该是：这个任务比默认故事大还是小？如果更大，大多少？两倍，四倍？如果是两倍，你应该设为 13，如果是大约一半的大小：3。请注意，斐波那契数列并没有给出确切的数字来表示两倍或一半的大小，这是好的——这种不完善性可以调整估算以适应我们自己的估算错误。

要进行此类估算，通常团队中的每个成员都有所谓的扑克牌——带有估算斐波那契数的卡片，如下所示。每当要估算一个故事时，每个人都会展示他们认为正确的估算，而事先不让任何人知道。如果猜测相等，则无需讨论，否则团队达成共识，确定最佳估算。

 

估算完所有故事后，如果 Sprint 成功，您可以使用完成的故事点数总和除以 Sprint 天数来计算 Sprint 速度或燃尽。您可以为每个 Sprint 执行此操作，并通过计算平均值来获得 Sprint 速度的平均值。此速度或燃尽用于燃尽图，如前所述。

总结 

冒着听起来过于重复的风险，在详细了解了所有主要概念后，请再看看 Scrum 的样子。

一切都始于产品负责人收集新产品开发的信息。然后他创建产品待办事项列表，其中包含要开发的、已排序的用户故事。他计划 Sprint，并将第一个 Sprint 呈现给团队。

团队和产品负责人将在计划会议中就目标达成一致。之后，团队估算用户故事并将其分解为任务。如果团队在探索用户故事后认为他们无法达到目标，他们可以重新审查目标并与产品负责人进行协商。

之后，团队开始处理任务，遵循用户故事的优先级。他们每天都会举行会议来跟进他们的状态（每日站会）。如果在这次会议期间或任何其他时间出现任何问题，Scrum Master 将帮助团队解决问题。此外，Scrum Master 帮助团队遵循 Scrum 框架并解决可能出现的任何障碍。

最后，当 Sprint 结束时，所有故事都已完成并准备好部署，团队将产品演示给产品负责人，产品负责人可以批准或拒绝 Sprint。此外，最终用户可以参加会议，最终用户和产品负责人都可以就产品提供反馈。之后，将举行评审会议，团队和 Scrum Master 在会上讨论如何改进他们的软件开发过程。

之后，另一个 Sprint 以计划会议开始，所有一切都重复进行。

请注意，每次评审后，产品负责人和最终用户都可以改变他们对未来 Sprint 的看法，以确定什么更重要。由于他们拥有可发布的软件，他们可以开始使用它并了解他们的需求，因此此处可以进行持续更改。

讨论  

现在希望您对 Scrum 有了更好的理解。显然，这里并未涵盖所有内容，因为有专门介绍 Scrum 的书籍。

现在，这里将讨论一些相关主题。

为最终用户创造价值 

Scrum 的主要优势之一是自第一个 Sprint 起就开始为最终用户交付有价值的东西。这意味着最终用户可以更早地开始使用产品，因此可以尽早提供反馈，从而避免开发无用的功能。这与瀑布式过程相比，Scrum 具有根本性优势，瀑布式过程最终为最终用户提供了许多他们不需要的东西。

事实上，软件用户，即使是开发人员，在开始使用产品时才完全了解他们的需求。只有那时他们才能理解什么相关或不相关，什么有用或无用。不幸的是，人类无法预见他们的需求，而软件开发人员必须接受这一事实。在开始使用软件之前，不可能强迫最终用户了解他们将需要什么。因此，给他们一些东西来使用，他们就会告诉你他们真正想要什么。

持续变化 

由于每个 Sprint 都会对产品进行评审，因此有机会获得持续的反馈，从而允许未来需求被更改和重新排序。这是 Scrum 在持续变化方面的魔力。

持续过程改进 

评审会议允许对软件开发过程进行持续的回顾和改进。这从 Scrum 框架问题到纯粹的软件开发问题，例如测试。

根据我的经验，持续过程改进涉及大量的测试改进。首先，会发现测试效率不高。之后，手动测试得到改进，但由于需要持续改进，因此出现了自动化测试。如果整个团队都不断进步，在测试策略方面将看到巨大的改进，因为团队希望以更高的质量测试更少的内容。自动化和单元测试，尽管要成功实现非常棘手，通常需要通过反复试验来实施。

代码是另一个因持续改进的特性而随时间改进的东西。团队意识到，如果代码质量差，会出现太多错误，产品维护会变得更困难。因此，会努力改进代码。诸如同行评审和静态代码分析之类的活动确实可以提高整体代码质量（如果应用得当）。诸如指导年轻开发人员之类的其他措施也取得了良好成果。

客户承诺

如果客户不提供持续反馈，使用 Scrum 没有意义。如果客户不参与创建的产品，Scrum 与任何其他瀑布式过程一样好，因为没有 Scrum 所允许的持续反馈和变化，使用 Scrum 的优势并不大。

众所周知，有时很难获得客户的承诺——他们只是希望他们的想法被读懂，并且软件能在约定的截止日期前完成。然而，产品负责人的职责是说服他们接受。

Scrum 适合所有人吗？ 

绝对不是。有些人太习惯于他们自己的工作方式，这可能也很好。如果你的工作效果很好，那么可能没有理由改变过程。但是，如果你发现需求没有得到满足，最终产品对客户来说没有用，你可能需要更多地考虑使用 Scrum。

何时不使用 Scrum？

Scrum 不应用于小团队，最多三个人。在这种情况下，经验表明，该框架不太有用，原因有几个。团队成员可能一直在互相交流，使每日站会变得毫无意义。此外，由于团队很小，改进很容易被发现，并且通常在识别后立即实施。然而，这并不意味着不应使用良好的敏捷开发实践。它只是意味着整个 Scrum 框架是不必要的。

Scrum 可能不需要的另一种情况是，当产品范围是众所周知的，并且几乎肯定不会改变。此外，团队精通所使用的技术，因此由于不确定性不会出现意外。正如你所观察到的，这种情况很少见。然而，在这种特定情况下，不需要持续反馈、持续过程改进或优先级更改，因为一切都已确定。

Scrum 是完美的，是万能药吗？  

绝对不是。如前所述，由于可能出现的人际交往问题，Scrum 很难付诸实践。此外，组织可能不愿意接受遵循 Scrum 所需的一切。

此外，Scrum 并没有解决长期估算的问题。要精确估算一个长项目仍然非常困难，这对于需要推销产品的经理来说仍然是一个问题。

如何开始使用 Scrum？ 

我的最好建议是：循序渐进——从小项目开始，最好与熟悉 Scrum 的成员一起。也许可以从 Sprint、每日站会开始，然后添加评审。这些很可能会暴露您项目中的问题，例如沟通不畅以及已有功能却出现过多错误。此外，每日站会可能不会像预期的那样简短，所以这是需要修复的。

稍后，引入回顾会议，在其中将改进过程。在团队习惯了遵循所有 Scrum 例会后，软件本身可能会更好。然而，您会注意到仍有改进的空间，例如自动化测试、更好的编码和更少的错误。

不要自欺欺人：这不会容易——思维模式的改变是巨大的，有些人根本无法适应。因此，如果您认为 Scrum 有价值，请不要气馁，并努力实施 Scrum。

另外，请记住，不采用整个 Scrum 框架并不是坏事。对您有用的是好的！也许在您的公司，所有权对一个人来说比对团队更好。或者 Sprint 的时间框架可能需要不同。重要的是使用 Scrum 提供的工具来改进您的软件开发过程，并使您的团队敏捷。

瀑布式过程毫无用处吗？

绝对不是。不要忘记瀑布式过程，特别是与CMM相关的过程，已经存在很长时间了。尽管它们确实存在问题，如本文所广泛讨论的，但许多公司通过它们取得了巨大的成功，而且相当一部分公司至今仍然如此。此外，请记住，在它们出现之前，没有什么可以组织软件开发，所以它们是一个巨大的突破，因为CMM类过程首次提供了软件开发的 منهج。    

这些方法论允许在实现软件之前对需求进行思考和讨论，而不是像之前那样绝对的混乱。此外，在我看来，最大的优势：允许软件架构和设计的时间，这大大提高了软件质量。此外，设计和架构允许开发和使用设计模式和良好实践，这再次极大地提高了软件质量。

除此之外，还开发了测试策略，以及自动化和单元测试，这再次为软件改进做出了贡献。

因此，这里的消息是：不要轻视老派软件方法论，因为它们为我们提供了良好的软件开发理念。此外：架构、自动化测试、设计模式等，在敏捷方法论中仍然非常适用。

将敏捷方法论视为软件开发朝着正确方向迈出的一步。最后，不要误解，总有一天我们会开始看到敏捷方法论的缺点，并且希望会有更好的东西出现。然后，在那之后，问题会出现，并且周期将永远继续。 

参考文献

以下是本文图片使用的参考。我想感谢托管这些图片的网站。

1. Scrum Life-Cycle image: http://www.mountaingoatsoftware.com/agile/scrum/overview
2. Scrum Product Backlog image: http://agilesoftwaredevelopment.com/scrum/simple-product-backlog
3. Sprint Backlog image: http://www.mountaingoatsoftware.com/agile/scrum/sprint-backlog/
4. Burn Down image: http://maymay.net/blog/2008/09/06/scrum-style-burn-down-chart-in-iwork-08-numbersapp/
5. Scrum Planning Poker image: http://apps.microsoft.com/windows/pt-br/app/agile-planning-poker/fd84a52b-d0ce-478f-97e7-a82021a8fa6a

历史

1. First version.
2. 在杂项部分添加了关于代码质量的“持续过程改进”的另一个主题。
3. 添加了关于瀑布式过程有用性的讨论。
4. 添加了关于如何开始使用 Scrum 的讨论。
5. 添加了本文图片使用的参考文献。
6. 添加了就绪定义。
7. 将 SCRUM 替换为 Scrum。
8. 在“讨论”主题中添加了“不使用 Scrum 的情况？”部分。此外，对文本进行了一些更正。
9. 更正了一些拼写和语法错误。
10. 更正了语法问题，感谢慷慨的贡献者 JPaula。