瑞士邮政服务的大规模 Scrum

瑞士邮政服务在 7 个团队中使用了大规模 Scrum（scaled Scrum），以实现对旧系统的取代。Ralph Jocham 在 2015 敏捷希腊峰会上在他的演讲中，介绍了他们利用大规模 Scrum 在 7 个团队中实现 10 个月交付 18 个应用的经验——瑞士邮政服务的大规模 Scrum 。

InfoQ 采访了 Jocham，谈论了他们如何扩展 Scrum 以及如何处理历史遗留问题、使用完成的定义、他们如何成功提前三个月交付他们的系统的、以及从该项目中获得的主要经验和教训。

InfoQ:您能描述一下，您是如何在多个团队之间扩展Scrum**** 的？

Jocham: 基于经验主义和自组织的大规模 Scrum 其核心应该还是 Scrum。扩展主要是针对管理依赖问题，以确保正确的消息在正确的时间出现在正确的位置。为了实现这一点，需要不同的团队进行额外的交流，实现对 Scrum 的扩展。最低限度，你需要解决架构问题，横切特性，和质量问题。最重要的是，你需要确保在冲刺阶段的任何特定的时候，拥有一个可发布的增量——只有那样，你才算“完成”并且没有遗留下工作。为了使它成为可能，当持续集成不再削减的时候，你需要努力持续交付。

我们在 Scrum.org 开发的 NEXUS 框架（参见 Scaled Professional Scrum 和 NEXUS ）正好解决了这些问题。在扩展过程中，没有统一的答案，但是不要跟许多扩展方法一样，陷入方法陷阱。即使是大规模，你仍然需要经验，和建立自组织。让正确的方法自己出现。

InfoQ:Scrum**** 是用来替代传统产品的。这是否给团队带来了更多的挑战？

Jocham: 现有的系统越来越跟不上时代了。现有的软件还是一个 WindowsCE 应用，硬件已经不再支持这样的应用了。即使这套系统仍然可以运行，它也不得不被替换。

它是否带来了更多的挑战？好吧，我们必须确保新的产品涵盖了所有需要的功能，并且能够被目前超过 22000 基数的用户群愉快地接受。多年以来，怪癖成为了特性。所以我们必须密切关注易用性。但是，因为我们的服务对象是终端用户，所以这本身并不是一个挑战，并且，在很早的阶段，我们已经要求他们投入精力了。他们也参与了产品待办事项列表中的待办项的初始创建：通过不断地精细化，完成了待办项工作。包括 UI 线框图，和明确的最低验收标准。通过每两周一次的冲刺评审，我们会关闭经验反馈回路。

就个人而言，我不会区别对待旧系统的更换与新产品的开发。最后，所有的一切都是关于实现价值最大化（结果对抗输出）和使客户或者终端用户开心。

InfoQ:您在处理遗留问题时有没有量身定制Scrum?

Jocham: 在 Scrum 指南中，我们是这样描述精细化流程的：“产品待办事项列表精细化是在产品待办事项列表中向待办项添加细节、预算和规则的行为。这是一个持续的过程，在这个过程中需要产品拥有者和开发团队共同合作，处理产品待办事项列表中待办项的细节。”

由于我们邀请了最终的终端用户——邮差——进入精细化环节，所以我们的确改变了 Scrum。但是这是在一个非常详细的层次上进行的。这样做后，通过经验反馈循环，我们的终端用户很快就看到了 Scrum 的优势，并将其拥抱。然而因为精细化不是一个官方的 Scrum 项目, 因此我想简短地回答“不，我们没有量身定制 Scrum”。

但是，我们通过在开发团队之间进行额外的交流（基于 CDE 的研讨会——容器差异交流，其对自组织的影响正如 Glenda H.Eoyang 在 2001 年著作的《Facilitating Organization Change： Lessons from Complexity Science》一书中描述的一样）对 Scrum 进行了扩展。其中对特性、架构和测试依赖的交流正在落实当中。由于 Scrum 是一个框架，因此能够很好并有意识地向其中添加规范和元素。

InfoQ:您能描述一下"完成"的定义吗?

Jocham:“完成”的定义主要是关于质量、可维护性和增强能力。这是一个大型项目，在巅峰时大约有 100 人参与其中。从一开始我们就确保，一旦推出这个设备，那么产品将进入维护模式，我们之后的团队将会继承质量方面的自测试系统，他们是：确认和验证。

我们对所有的业务逻辑功能，并为每个业务模式都进行了 90% 覆盖率的测试，其中业务模式包括在浏览器里实施的基于 Selenium 的 UI 测试和在 Android 设备上的 Appium 测试。事实上，高覆盖率的测试并不能保证质量，但是要想获得高质量通常需要高覆盖率的测试。所有这一切共同使我们能够确切地知道我们的产品是否“完成”与否。

除了上文提到的质量问题，我们也对常规编码标准进行了符合性检查，以及拥有已实现要求的最新文档，测试案例，软件架构和界面。

最后，我们要确保该产品是国际通用的，比如在瑞士，我们不得不用三种语言实现它：德语、法语和意大利语。

InfoQ:您成功实现了提前三个月交付产品。您能解释一下，使这一切成为可能的成功因素是什么？

Jocham: 跟三件事有关:

1. 需求: 我们在实现需求时使用了敏捷。将一个遗留程序分解成许多较小的应用。这种做法允许我们每次专注于一件事，与七个开发团队并行工作，降低特性风险。应用的数量从 20 降低到 30，随后又再次降低到 18，最后以 22 收尾。在这个项目中，为我们添加的特性而进行的交流促进了许多可重用组件的创造。
2. 质量: 从一开始这就是我们的首要任务，而不是马后炮。质量的强制执行是通过自动化测试组件和持续集成实现的，该自动化测试是基于一个强大的构建流水线，而持续集成则是对所有已开发功能的持续集成。在我看来，如果测试在开发之后，甚至更晚，它就不再是质量，而是稳定了。
3. 透明: 透明的确保是通过（接近）无关政治的诚信拼搏实现的。我们不断地对所有重要方面的情况进行评估，并有与之相对应的快速行动降低风险的方法。每两个星期，我们基于我们检查到的数据采取行动。信任是使之成为可能的关键。

InfoQ:您能分享一下从这个项目中学到的经验和教训吗？

Jocham: 没有什么是“完成”的，直到它真正的完成，让这种思想伴随你一路，从 UI 到后端系统的最后一个角落。永远不要相信做出的承诺会起作用。从早期对有所的功能就提出集成的要求。在第一次冲刺的时候就“完成”，直到最后都不要推迟，因为它会一直困扰你的。

InfoQ:如果您不得不重新开始这个项目，您会与之前有什么不同吗？

Jocham: 我们对后端系统确实有一些设想，比如，我们如何连接它们，它们如何工作和执行。 在许多案例下，这些假设都是错误的，成为绊倒我们的电线。幸运的是，我们拥有我们自己的自动化测试，并且多次拯救了我们。在未来的项目中，我将会坚持“完成”同样包括后端系统。我将会尽量在每个开发团队中安置后端开发人员。

查看英文原文： Scaled Scrum at Swiss Postal Services