Scrum团队在发布Sprint期间做什么?
- 在发布冲刺或强化冲刺期间，Scrum交付团队要做什么?
- 系统测试或集成团队在开发冲刺期间做了什么？
- Scrum团队应该在支持集成团队的发布级活动和计划下一个发布之间分配多少时间?
- 我们不应该错开我们的产品版本，以便每组忙碌？
许多组织都有一个系统测试团队或集成团队，与Scrum交付团队分开。有时，一旦他们开始考虑采用敏捷方法，我就可以获得与组织的上面的问题就像上面的问题。特别是，这个问题通常来自大型组织，必须整合多个团队的工作。我会回答这些问题，但让我先给你一些定义。
定义
系统测试团队:
你可能知道这支队伍的另一个名字。这支队伍可能被称为:
- 独立的验证和验证团队
- 集成和回归测试团队
- 版本集成团队。
无论名称如何，这个团队负责跨团队的持续集成和回归测试的执行，并通过向交付团队提供缺陷来管理问题的解决。他们与系统团队密切合作，以继续改进持续集成和测试功能。
系统团队:
这支球队也有几个不同的名字。:
- 支持团队
- 建立作为服务团队
该团队负责构建支持持续集成、测试环境和测试数据管理所需的一切。他们开发工具并支持自动化。这通常是一个非常小的团队——小到一个人，或者可能只有几个人。只有当测试需要集成多个团队的输出进行测试时，您才需要这样做。
现在有关问题的答案。
首先，看看丹尼斯·史蒂文斯的博客团队可以做的六件事比写作无法测试的代码更好．在发布Sprint期间，交付团队可以学习、减少技术债务、改进单元测试、特性级别验证、重构或为下一个发布做准备。它们应该立即可用来支持在强化或发布sprint中发现的任何缺陷。或者，至少直接参与测试。无论剩下的时间是多少，都应该花在提高他们的能力和准备下一个版本上。
在开发冲刺期间，释放级集成团队或系统测试团队可能正在进行集成和验证先前Sprint中交付的所有内容。他们还应该准备好测试下一个即将到来的东西。这意味着合作以优化验收标准或定义工作的测试，以便去交付团队。他们应该改善自动化，并努力了解或批判交付团队的单位测试覆盖范围。此外，他们应该提高他们的能力。
Sprint发布反模式
避免后期测试反模式是很重要的。
反模式:
交付团队没有有效地验证产品并将垃圾扔到系统测试团队。
反模式二:
团队在整个发布过程中没有完成特性(最终需要作为一个单元一起测试的一组相关的故事)，这样直到发布结束之前没有任何东西是可测试的。
反模式三:
延迟任何数量的集成和回归测试，直到一切都完成。
结论
我们的目标是在整个发布过程中尽可能多地进行测试，很少延迟到最后。这意味着交付团队在每个sprint中交付经过验证的、技术上优秀的特性。在这方面臻于完美之前，他们还需要努力改进。这意味着系统测试团队经常(持续地)集成、验证和验证。在他们有能力做到这一点之前，他们还有改进的余地。
如果你在寻找一个简单的公式，你会失望的:没有一个简单的时间百分比公式。查看你所处的位置，与所有相关团队协调，提高你最小化未测试代码的能力，确保在开发前做好准备，最大化系统中经过验证的产品的流程。
* Credit:我收到了来自丹尼斯然后写进了这篇博客。