Scrum论坛

基本上有两种选择：

1.您将其视为“发布到生产”，产品所有者联系用户以测试UAT中的功能。

2、你将其视为发展的一部分。然后它应该在Done的定义中，并且应该是产品Backlog项流向“Done”的一部分。

我认为第二个是“更好”的选择：通过让这些测试人员“加入”团队，并给开发人员打电话，他们是工作流程的一部分，负责价值并完成项目。他们的工作应该是“完成”定义的一部分。

组织通常选择选项1，因为它更容易。但这是不正确的：如果没有进行UAT测试，您会真正投入生产吗？不，当然不是。那么，在这种情况下，UAT测试是工作流的一部分，应该在“完成”的定义中。

我同意马里奥的观点，如有必要，UAT应该在每一次冲刺中进行，并且是“完成”定义的一部分。如果UAT不得不等待Scrum团队之外的人，从而阻碍了价值的释放，那么必须做出一些改变。如果Scrum团队已经尽了他们所能来解决外部依赖，那么可能这是Scrum大师应该帮助改变组织的一个障碍。

我认为这里有很多事情，在几个不同的层面上。

我不同意其他人关于UAT走向的看法。由于Scrum团队无法控制执行UAT的用户何时开始流程、何时结束流程或何时提供反馈，因此将UAT的完成放在“完成”的定义范围内对我来说没有意义。Scrum团队对完成的定义应该包括团队可以做的事情，以使UAT能够发生并增加成功UAT的机会，但完成的工作是应该通过UAT完成的。

我还将挑战在投入生产之前完成UAT的需要。UAT应该是用户使用功能的大门，而不是可用的功能。在软件中，您可以使用功能标志（例如）来控制更改的可见性或可访问性。在一篇文章中，皮特·霍奇森写了不同种类的切换以及如何控制它们。这允许您将功能的实现与用户何时开始使用该功能区分开来，允许他们在测试环境中启用功能标志和执行UAT，并等待该功能在生产中启用之前可以接受。

执行UAT的需要应由用户决定。向利益相关者传达产品更改与Scrum中产品负责人的角色关系最为密切，但我认为你不能说拥有产品负责人角色的人总是与执行UAT的人一起工作。与许多事情一样，产品所有者可能会将其委托给其他人，而您的组织可能会有一些人，例如客户经理或客户成功团队，他们与通过产品更改帮助客户和用户更密切相关。

Scrum指南中没有提到用户接受测试，因此没有提供任何指导。“release”一词只使用了两次，这是在描述定期的加薪. 以下是两种说法：

Sprint回顾不应被视为释放价值的大门。

如果产品积压项不符合Done的定义，则无法发布，甚至无法在Sprint评审中展示。相反，它返回产品积压待办事项以供将来考虑。

请注意，这两个版本都没有提及发布到生产环境中。事实上，在Scrum指南中没有任何地方提到发布用于生产的内容。大多数参考文献都是为了向利益相关者提供增量。实现Scrum的人可以决定这意味着什么。

如果您的组织要求在发布到生产环境之前进行用户验收测试，那么您可能应该考虑将发布到用户验收测试环境是Sprint的目标。它减缓了反馈机制，但这可能是你能做的最好的。我曾与这样做的组织合作过。这并不理想，但很有成效。最后，我们总是朝着让利益相关者直接参与Sprint和Sprint评审的解决方案迈进。

很多时候，用户故事需要UAT测试

有例外吗？用户故事曾经如果这些用户不接受它的实现，该怎么办？

在投入生产之前。

我建议在精益和敏捷实践中，工作永远不会推无论在哪里，它都是拉响应明确的需求信号。

现在，如果UAT用户在Scrum团队之外。

如果是这样的话，我们有一个问题。该团队无法产生多恩具有即时可用质量并确保其自身实证结果的作品。

现在的问题是。。。

让我们注意不要对可能存在缺陷的假设提出任何进一步的问题。问题已经够多了。

• Done的定义实际上是否包括所需的UAT？
• 如果是这样，为什么要把工作推到其他地方去实现UAT？
• 为什么团队不能在每次冲刺中进行UAT并与国防部会面？

非常感谢您分享各种观点。

根据我的实时经验，没有必要让UAT用户总是在scrum团队中，这完全取决于团队所做工作的背景和类型。

当你依赖UAT用户时，我认为将其作为国防部的一部分不属于scrum团队的权限。如果我们谈论scrum指南，它说UAT也必须在同一个sprint中完成，但在许多情况下，可行性将不存在。

我觉得发布准备好的故事可以让国防部知道UAT必须完成并且可以发布。

有什么想法吗？

根据我的实际生活，在scrum团队中并不总是需要UAT用户，这完全取决于具体情况。

SM指导团队变得更加自我管理和跨职能。在实现跨职能时，团队应：

• 吸收团队外现有的权威和技能，这样他们就不必在冲刺中放弃工作，自己完成任务
• 吸收目前存在于团队之外的人的原因与上述相同，只要团队规模不太大。
• 与外部相关人员合作，以确保尽量减少或消除切换延迟，从而在冲刺过程中几乎没有障碍。团队外的人员应致力于团队的工作，以便随时可用。
• 意识到这种情况，并与组织领导层合作，使效果透明。

使其透明的一种方法是在每个sprint中创建看板，作为sprint backlog。为您所依赖的任何外部团队设置一个列，并确保在sprint审查期间记录并向利益相关者显示该工作状态（列）的项目老化和周期时间。

这样，你的sprint回顾听起来是这样的：“我们完成了三项，我们选择了五项，但无法完成最后两项。正如你所看到的，第4项和第5项的周转时间是三天，所以当我们把它们拿回来的时候。没有足够的时间继续工作，并在sprint结束时完成它，以满足国防部的要求。”

有时团队没有意识到sprint回顾不仅仅是演示所做的事情，而且是一个与利益相关者分享环境如何影响团队工作能力的机会。

记住这个词：外交。