Sprint 工作项 - 敏捷 Scrum [关闭]答案

【问题标题】：Sprint Work Items - Agile Scrum [closed]Sprint 工作项 - 敏捷 Scrum [关闭]
【发布时间】：2010-10-22 12:13:29
【问题描述】：

哪些类型的任务可以作为工作项包含在 Sprint Backlog 中并进行跟踪？

是否可以在 Sprint 积压工作中包含和跟踪（用户故事的）分析、审查和单元测试，或者是否只能包含和跟踪核心编码任务？

基本上，我将用户故事分解为技术任务以更新 Sprint backlog，并想知道是否可以在 sprint backlog 中更新和跟踪具有非编码角色的任务。

【问题讨论】：

我可以建议：area51.stackexchange.com/proposals/9543/…
+1 表示同情您将受到成员的抨击，因为您以这种方式表达您的问题，尤其是最后一段 :)
@gbjbaanb 你可能会建议，但在 SO 上问这个问题并没有错。
这个问题是题外话，因为它不在适用于本网站的问题范围内，如What topics can I ask about here? 中定义的那样，另请参阅：What types of questions should I avoid asking? 您也许可以在 @ 上获得帮助987654324@.
我投票结束这个问题，因为它与编程无关。

标签： agile scrum sprint

【解决方案1】：

您希望将这些任务作为工作项进行跟踪。小心这样做。

为什么？你开始具体化一个过程。这里有一个滑坡。一旦你开始具体化这个过程，你就不再是真正的敏捷，而是开始创建一个僵硬的强制性顺序步骤的瀑布。

如果您认为这些事情非常重要，以至于您必须将它们写下来，否则开发人员会忘记它们，那么您就没有赋予您的开发人员保持敏捷的责任，或者赋予他们做出自己决定的权力。

你认为他们不值得信任。

分析用户故事。无论如何，他们都会这样做。为什么要写下来？他们会忘记吗？重点是理解。不是文档。不是时间管理。
代码审查。你希望他们这样做。你必须创造一种文化，这样做的结果是有益的。

如果代码审查的结果是“您的代码很糟糕，请再做一次”，那么没有人参与，并且除了通过法令之外不会完成。

如果代码审查的结果是“一个新的最佳实践供每个人学习”加上“也许您应该根据其他最佳实践重新考虑这一点”，那么人们可能会参与。
单元测试是冲刺的一部分，无需任何问题或讨论。
事实上，它可能是 sprint 中最重要的部分。单元测试首先出现，几乎在任何其他代码之前。你不需要说这个。事实上，这样说的行为表明您的开发人员不能被信任进行测试。

当你有为程序员写下任务的冲动时，你也必须思考为什么这个问题。

为什么一定要写下来？他们不做什么？

这是重要的部分。

他们为什么不首先这样做？

他们不是在分析吗？为什么不？你让分析变得困难吗？用户不让自己可用吗？

他们不进行代码审查吗？为什么不？代码审查的障碍是什么？不够时间？合作不够？奖励不够？是什么阻止了他们？

他们不是在做单元测试吗？为什么不？测试的障碍是什么？不够时间？灵活性不够？没有足够的积极反馈来先做测试？

为什么您觉得有必要“控制”和“强制”您的开发人员？他们为什么不自己做呢？

【讨论】：

感谢您的回复。我的意思是需求分析、代码审查和对代码进行单元测试。是的，它们不是敏捷意义上的可交付成果，但在我看来对于确保代码质量至关重要，我们将不得不为此付出努力。
@jcs：请更新您的问题，让这一点非常清楚。
+1 我喜欢您将所有内容都表达为问题的方式，很棒的回顾性材料

【解决方案2】：

哪些任务可以作为工作项包含在 Sprint Backlog 中并进行跟踪？

根据 Scrum 指南 ->在计划会议第 2 部分中，团队确定任务。这些任务是将 Product Backlog 转换为工作软件所需的详细工作。任务应该已经分解，因此它们可以在不到一天的时间内完成。此任务列表称为 Sprint Backlog。因此，任何符合上述准则的任务都需要包括在内。

是否可以在 Sprint 积压工作中包含和跟踪（用户故事的）分析、审查和单元测试，或者是否只能包含和跟踪核心编码任务？

是的，如果这样做会导致将待办事项列表转换为工作软件，则可以并且应该包含它们。 Scrum 从不建议在 Sprint Backlog 中只包含编码任务。事实上，Scrum 要求团队跨职能。

基本上，我将用户故事分解为更新 Sprint backlog 的技术任务，并想知道是否可以在 sprint backlog 中更新和跟踪具有非编码角色的任务。

这对我来说听起来很可疑。分解任务的只是“你”吗？应该是整个团队在计划会议的第二部分分解任务。同样，非编码任务可以包含在 Sprint 中。只是给你一个现实的例子：在我的 Web 开发团队中，一个典型的 Backlog 有以下任务。 1. 定义和发现 2. 设计和创建测试矩阵 3. 编写单元测试来测试矩阵 3. 使单元测试通过的代码 4. 测试 5.回归测试 6.调试 7. 浏览“与 PO 一起工作的软件（如果需要确保这是 PO 想要的）

编辑

关于任务分配的另一点。计划期间添加的任务应在必要时不断分解/更新/重命名。这样做的全部目的是添加一组透明的分解的事情要做，当完全完成时，最终导致工作软件遵循 QA 标准，最有效和最有效。这些任务应该跨职能地接手和工作，而不应该在团队成员之间被阻止。

希望这会有所帮助！

【讨论】：

【解决方案3】：

简短的回答是 - 最适合您的团队和相关用户故事的方法。

例如，如果我们正在重构一段代码作为用户故事的一部分，我们可能会分出一个单独的任务来处理首先对其进行测试。但如果它是新开发的，我们推断它将在我们的流程中进行测试（通常使用 TDD 完成）。

其他示例包括有时分出一项单独的任务，以涵盖协调与编码所花费的时间、与外部供应商的集成测试等 - 基本上，任何有助于构成特定故事的谨慎且可衡量的任务（包括一些您在上面包含的示例）。

底线是每个故事应该有什么没有固定的公式，而是根据每个故事的个人需求定制任务（即使这些任务与代码无关）。

【讨论】：

谢谢。感谢您的回复。

【解决方案4】：

如果您在每个用户故事中为分析、编码、审查、测试等创建任务，您将接近称为 Scrumfall 的东西（每个迭代都分为瀑布阶段）。这是 Scrum 的气味之一。基本上，此类活动应包含在单个任务中：“做某事”意味着完成“某事”所需的一切=您是专业开发人员并且您知道（或政策规定）完成任务必须做什么。

这是一般情况。有时您确实需要将任务划分为“活动”，但首先您应该从通用流程开始，并且只有在您有真正原因的情况下才使用此工具 - 例如在一次迭代中增加任务，在第二次迭代中执行实际任务。

编辑：我曾经将任务划分为活动。我们没有做 TDD，但在完成任务后编写了测试。因此，每个开发任务都与测试任务配对，以表明它可以由另一个开发人员完成，有时与开发并行。但是由其他开发人员进行测试的责任是团队决定，对于复杂的任务，他们确实这样做了。

【讨论】：

我只同意您暗示每个待办事项不应遵循模板形式的任务。但有时，积压工作实际上可能需要分析、编码、测试，而且这并没有什么可怕的。我的理由？在瀑布中——整个组织结构是不同的——分析团队、编码团队、质量保证团队，都是孤立的。在 scrum 中，团队是跨职能的，理想情况下每个人都参与到从 backlog 开始到结束的每个阶段。
只有当任务在团队内被其他团队成员阻止并且没有保持对所有人透明的情况下，它才能被称为 Scrum 气味。我可以举出真实的例子来说明实现与瀑布的不同之处。它当然不能称为 Scrumfall 或迷你瀑布。
@sjt：我没有写他正在做 Scrumfall，我写他正在接近。但是非常好的一点，因为问题没有提到每个任务是否可以由任何成员或特定成员完成。我的回答只是关于主要的敏捷原则之一 = 赋予人们权力。创建高级任务并将选择活动的责任交给执行任务的人。

【解决方案5】：

如果您将用于任务跟踪的所有精力都集中在将故事拆分得更小（1-3 分），那么您将努力变得更加敏捷。小故事几乎不需要任务级别的估计或跟踪。您的 PO 受益于能够优先考虑较小的功能集，并且您可以专注于交付价值，而不是重复记录明显的步骤。当然，按每个故事的小时来跟踪团队商定的标准做法根本没有用。

【讨论】：