-1

我的公司实施了一个新流程，让团队负责在 sprint 中定义完成。

在 Sprint Review 会议上，PO 第一次展示了工作，他们在团队面前处理了每个问题，然后对问题发表评论，例如“它是否按预期工作。如果没有，如何？缺陷创建.. 。”

读了很多关于 Scrum 的文章，这似乎不是“Scrum”要做的事情，实际上很多资源都明确表示，将评审会议作为验收会议是一件坏事，应该是关于反馈的。

问题是 PO 什么时候应该看到工作？我们什么时候接受/拒绝冲刺？

由于以下几个原因，我们目前没有在 sprint 中进行 PO 测试：

  • 如果 PO 在 sprint 期间进行测试，那么确保问题被理解的所有权不在团队中，他们可以理解一半并实施一些东西，然后在向他们展示之后从 PO 那里得到解释。
  • 团队也不需要测试他们自己的工作，因为他们有 PO 来抓东西。
  • PO 在 sprint 期间有很多事情要做，例如 Backlog 梳理、会见客户，如果我们在 sprint 期间添加测试，那么可能有太多事情要做。

同样，这些都是我们所做的假设，因此对这些的任何想法都会非常有帮助。

4

1 回答 1

2

Sprint Review 是团队向更广泛的受众（通常是利益相关者）展示已完成工作的机会。我们召开这次会议的原因是，并非所有对这项工作感兴趣的人都有时间在冲刺期间不断地审查它。对他们来说，参加 Sprint Review 并在会议期间提供反馈通常很方便。

我希望产品负责人在 Sprint Review 之前已经看到了所有功能。事实上，我与产品负责人合作过的很多团队都是在 Sprint Review 中领导演示的人。实际上，他们正在向更广泛的受众展示他们要求开发的内容。

产品负责人在冲刺期间审查故事。我首选的方法是让开发人员尽早向产品负责人展示故事的功能，有时甚至在他们仍在开发的时候。产品负责人越早看到故事的实际效果，他们就会越早提供反馈。早期反馈对于团队有效工作至关重要。

请注意，他们正在审查而不是测试。尽管如果产品负责人团队和产品负责人发现它有价值，那么他们进行一些测试是没有害处的。

正如您正确指出的那样，产品负责人在冲刺期间有很多事情要做。由整个 Scrum 团队来讨论如何最好地利用产品负责人的时间。就我个人而言，我会说在 sprint 期间审查故事是产品负责人的重中之重，因为它可以节省效率。

于 2016-02-11T13:36:22.713 回答