如何跨多个 Scrum 团队协调测试 [关闭]

Question

我参与了一个使用 Scrum 的新项目，该项目已从一个 Scrum 团队扩大到四个，并且可能会进一步发展。这是一项新技术，因此架构仍在不断发展，因此需要将各个部分作为一个整体进行系统测试。使用汽车类比，我们有底盘、刹车、发动机和转向团队。任何给定的故事都有一个焦点（例如更快的加速）并分配给一个团队（例如引擎）。 done 的定义通常定义了该 scrum 中该部分的标准。然而，仍然需要对“系统”进行一些测试（例如在赛道上驾驶汽车），以确保更改不会破坏系统的其他部分。例如，发动机可能较重，这会影响制动或转向。

Here 指出单独的测试团队不是答案。它在“扩展 Scrum 时的前五个问题”中首先列出了“独立测试团队”。所以“系统”测试必须使用 scrum 结构来处理。

完成的定义（驱动测试标准）应该包括整个系统（因此所有团队都对所有领域进行全面回归测试）还是只包括他们的重点领域（例如刹车团队对其他故事的回归测试是什么发现更换引擎的影响）。重复和覆盖之间似乎存在权衡。我们希望避免 scrumfall（例如添加另一个测试“阶段”），避免重复，但仍能尽快发现问题并尽可能“接近源头”。

随着项目发展到多个 Scrum 团队，系统测试如何扩展？

Answer 1

在敏捷开发中，避免像瘟疫一样的依赖。

在我看来，四个团队中没有一个是靠自己创造价值的。这是您需要解决的最大问题。

如果一个团队没有创造价值，完成是什么意思？当您需要团队同步以完成汽车工作时，您如何确定优先级？

比较 Facebook 的工作方式（例如，据我所知）：

• 一个团队负责聊天
• 一个团队做相册
• 时间线由一个项目完成
• ecc...

他们都部署——即直接产生价值——并且在他们的测试中完全独立。

如果您的团队正在创造价值，那么根据定义就不需要跨团队系统测试。

Answer 2

我认为问题在于，您的 DOD 不包括集成测试。

如果您将 DOD 扩展到此阶段，所有 4 个团队将在早期（在 sprint 期间）将那里的结果整合到一个整合阶段并从那里获得结果。 在 sprint 早期这样做很重要，因为否则这个阶段的错误将无法在同一个 sprint 中修复。然而，在他们发现的 sprint 中修复错误是必须的。错误代码未完成。

对于定期完成 DOD 的团队来说，将 DOD 扩展到另一个阶段也是一个最佳实践。

顺便说一句：扩展 DOD 当然会在开始时影响您的速度。这是正常的，因为你会做更多的事情来完成 DOD。