将工作项拆分为原型和主工作项？

Question

在培训过程中，我们通常会根据团队对需要做什么的理解而获得批准的工作项目？产品负责人不讨论将如何完成任务的细节，并在团队尝试时停止讨论。这适用于所有工作项(新UI、新API或对现有UI/API的更改)。产品负责人的理由是，深入到细节(包括技术和功能)将如何做是需要发生的事情，在冲刺和讨论它在梳理是不正确的。工作量估算也是基于这一讨论进行的。

但是在sprint计划期间，已批准的项目被视为sprint，并且期望如果工作项被批准，团队应该知道解决方案的所有细节，并且应该能够在sprint中完成该项。所发生的事情是团队首先花费2-3天进行研究，并获得PO对解决方案的批准(UI设计，关键业务逻辑澄清)。除非分析结果在工作量估计上有很大差异，否则要求团队完成这项功能。这种情况在每次冲刺中都会发生。

我在完成工作项目时投入额外的精力是没有问题的。我的问题是关于这个过程。

1. 团队在批准该项目时是否应该拒绝，除非团队理解解决方案的样子？
2. 应否将工作项目分成研究/分析，以便向PO提出解决方案原型？一旦PO批准了原型，主工作项将被标记为已批准。
3. 关于如何更好地处理这一问题，还有其他建议吗？

Answer 1

规划会议的细节程度，在很大程度上取决于专业人员的个性和专长。

以用户界面为例:一些产品所有者拥有强大的UX技能，或者在团队之外使用UX专家。这些PO最好带一个粗略的UX规范来参加计划会议。在其他情况下，这种技能更多地体现在团队中。这些团队将UX设计作为实现的一部分来处理。如果PO对UI有强烈的意见，但未能事先交流他想要的内容，问题就会出现。这对球队是不公平的。

简而言之，如果它影响了工作项目的接受，那么PO就不应该在计划会议上回避这个问题。

另一方面，你不能期望他准备好所有的答案，球队也必须积极思考，给他一些选择。

在规划会议上处理这一问题的一个好办法是，将问题写成“如果.你会接受这个故事”。

回到你的问题：

团队在批准该项目时是否应该拒绝，除非团队理解解决方案的样子？

是的，如果邮递员不能清楚说明他会接受什么，什么不能接受。

应否将工作项目分成研究/分析，以便向PO提出解决方案原型？一旦PO批准了原型，主工作项将被标记为已批准。

如果对于某个工作项，您都认为迭代方法最好(“让我们看看它是如何工作的，然后决定它是否需要更改”)。那么最好把它分成两项。但是，不要将步骤1看作一个原型，根据当前对团队和PO的理解，使其“具有可移植性”。PO始终可以定义工作项以在以后进行改进。

关于如何更好地处理这一问题，还有其他建议吗？

一些团队或PO将在计划会议前准备粗略的UX规格(线框)：目标是早期失败。就能达成一致了。这样，当团队提交到工作项时，范围已经被预先澄清了。

Answer 2

另一种方法是将会话分成两部分。

在第一个版本中，Product进入了团队理解需求所需的详细级别。在这一部分中，将不进行任何努力估计。然后PO离开房间，团队从评估过程开始，包括“如何完成”。

PO应该可以回答将会出现的问题。这是sprint计划的一个重要部分，您可以在其中包括规划扑克或任何其他评估技术。重要的是，计划不会永远持续，你应该有一个结束的时间，你的会议结束。

任何团队认为重要的事情都应该在计划会议期间讨论。这是很好的练习。如果团队离开房间，有很多问题，那是不可能有效率的。如果有太多未知的因素，那么您可以开始研究一个概念和/或创建一个简单的原型。但这应该是例外，而不是规则。

Answer 3

团队在批准该项目时是否应该拒绝，除非团队理解解决方案的样子？

不，当然没有。不知道实现细节给团队留下了找到最简单的解决方案的余地。这并不意味着讨论应该被阻止，但它肯定应该受到限制。

例如，假设在计划会议上决定以某种方式播放一个故事。在冲刺过程中，团队应该被迫使用这种设计吗？这与敏捷宣言是背道而驰的。

应否将工作项目分成研究/分析，以便向PO提出解决方案原型？一旦PO批准了原型，主工作项将被标记为已批准。

不，这无助于团队，因为原型对您的用户没有价值，因此根据Scrum应该具有最低的优先级。你只应该做原型，如果需要，一旦你承诺的故事，而不是之前。

关于如何更好地处理这一问题，还有其他建议吗？

我有几个：

1. 为什么你的产品负责人扮演一个Scrum大师？角色实际上应该是分开的，否则通常是个坏主意，™
2. 你为什么要估计你的故事两次？这是不应该发生的。你估计他们一次，不准确，以获得一个概念，什么适合在一个冲刺。任何人都不应该在意超过这一点--衡量成为你真正做到的。当然，可以有任务估计，但它们是有目的的，在一个单独的单元中，因为它们永远不应该用于估计什么适合一个sprint，而只用于估计还剩下多少工作。
3. 在sprint过程中，您似乎在与PO合作方面遇到了问题。例如，你说“团队在前2-3天做研究并获得PO批准解决方案的努力”。这对我来说毫无意义。PO应该关注用户的最终结果，而不是特定的解决方案。他们需要事先指定一些端到端的验收测试，但通过测试的一切都是公平的--其他任何事情都应该是一个新的故事。
4. 您关于建立一个原型->故事管道的建议有悖于协作和角色分离。相反，你真正需要的是让PO和团队在整个sprint过程中进行协作，并相互交谈。故事在完成之前不应该被设计出来。你所说的“原型”应该是真正的故事。