我参与了一个使用scrum的新项目，并从一个scrum团队扩展到四个，并且可能会进一步发展。这是一项新技术，因此架构仍在不断发展，因此需要对整个系统进行系统测试。使用汽车类比，我们拥有底盘，制动器，发动机和转向系统。任何给定的故事都有焦点（例如加速更快）并被分配给一个团队（例如引擎）。完成的定义通常定义该scrum中的那个标准。然而，仍然需要对“系统”进行一些测试（例如，在赛道周围驾驶汽车）以确保更改不会破坏系统的其他部分。例如，发动机可能更重，这会影响制动或转向。
Here指出单独的测试团队不是答案。它在“缩放scrum”的“前五大问题”中首先列出了“独立测试团队”。所以'系统'测试必须用scrum结构来处理。
完成的定义（驱动测试标准）是否包括整个系统（因此所有团队都对所有区域进行完全回归测试）或仅仅是他们的重点区域（例如制动团队对其他故事的回归测试是什么发现改变引擎的影响）。重复和覆盖之间似乎存在权衡。我们希望避免scrumfall（例如添加另一个'阶段'的测试），避免重复，但仍然尽可能快地发现问题并且“接近来源”。
当项目成长为多个Scrum团队时，系统测试如何扩展？
答案 0 :(得分：4)
在敏捷开发中，避免像瘟疫这样的依赖。
在我看来，这四支球队中没有一支球队自己产生价值。这是您需要解决的最大问题。
如果某个团队不产生价值，那么完成意味着什么？当您需要团队同步以完成汽车时，您如何确定优先顺序？
比较Facebook的运作方式（例如，据我所知）：
它们全部部署 - 即直接产生价值 - 并且在测试中完全独立。
如果您的团队正在创造价值，那么按照定义就不需要进行跨团队系统测试。
答案 1 :(得分：2)
我认为问题是，您的DOD不包括集成测试。
如果你将国防部扩展到这个阶段，那么所有4个团队都会在冲刺期间尽早将结果集成到整合阶段并从那里获得结果。 在sprint的早期执行此操作非常重要，因为否则此阶段的错误将导致在同一sprint中修复。然而，修复它们所确定的冲刺中的错误是必须的。越野车代码没有完成。
将DOD扩展到另一个阶段对于那些定期在DOD中实现DOD的团队来说也是最佳做法。
顺便说一句：延长国防部当然会影响你的速度。这是正常的，因为你会做更多的事情来完成国防部。