1

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

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

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

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

4

2 回答 2

4

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

在我看来，这四支球队都没有自己创造价值。这是您需要解决的最大问题。

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

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

  • 一个团队正在聊天
  • 一个团队做相册
  • 一个项目做时间线
  • 抄送...

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

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

于 2013-06-20T23:51:46.350 回答
2

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

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

无论如何，将 DOD 扩展到另一个阶段也是定期完成 DOD 的团队的最佳实践。

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

于 2013-06-21T13:15:34.647 回答