Sprint Backlog中可以包含和跟踪哪些类型的任务作为工作项？
是否可以包含（用户故事的）分析，审核和单元测试，或者只能在Sprint积压中包含和跟踪核心编码任务？
基本上我将用户故事分解为技术任务以更新Sprint积压，并想知道是否可以在sprint积压中更新和跟踪具有非编码角色的任务。
答案 0 :(得分：6)
您要将这些任务作为工作项进行跟踪。小心这样做。
为什么呢？你开始具体化一个过程。这里有一个滑坡。一旦你开始具体化这个过程，你就会停止实际上敏捷，并开始创建一个不可弯曲的强制性顺序步骤瀑布。
如果您认为这些事情非常重要，以至于您必须将它们写下来，或者开发人员会忘记它们，那么您就不会让开发人员有责任保持敏捷，或者有权做出自己的决定。
你认为他们不值得信任。
分析用户故事。他们无论如何都会这样做。为什么写下来？他们会忘记吗？重点是理解。不是文件。不是时间管理。
审核代码。你希望他们这样做。您必须创建完成此过程的文化，结果奖励。
如果代码审查的结果是“你的代码很糟糕，再做一次”，那么没有人参与，除非通过命令，否则不会完成。
如果代码审查的结果是“每个人都可以学习的新的最佳做法”加上“也许你应该根据其他最佳做法重新考虑”，也许人们会参与。
单元测试是sprint的一部分，没有任何问题或讨论 实际上，它可能是冲刺中最重要部分。在几乎任何其他代码之前，单元测试首先出现。你不需要说这个。事实上，说它的行为声称你的开发人员不能被信任进行测试。
当你感到有为程序员写下任务的冲动时，你还必须仔细思考这个问题。
你为什么要把它写下来？他们不在做什么？
这是重要的部分。
他们为什么不首先这样做？
他们没有分析？为什么不？你难以分析吗？用户是不是自己可用吗？
他们没有进行代码审查吗？为什么不？代码审查的障碍是什么？不够时间？没有足够的合作？没有足够的奖励？是什么阻止了他们？
他们没有进行单元测试吗？为什么不？测试的障碍是什么？不够时间？灵活性不够？没有足够的积极反馈进行测试？
为什么你觉得需要“控制”和“胁迫”你的开发者？他们为什么不自己这样做？
答案 1 :(得分：4)
可以在Sprint Backlog中作为工作项包含和跟踪哪些任务？
根据Scrum指南 - ＆gt;在计划会议第2部分中，团队识别任务。这些任务是将产品Backlog转换为工作软件所需的详细工作。任务应该已经分解，因此可以在不到一天的时间内完成。此任务列表称为Sprint Backlog。 因此，无论满足上述指南的任何任务都需要包括在内。
是否可以包含（用户故事的）分析，审核和单元测试，或者只能在Sprint积压中包含和跟踪核心编码任务？
是的，他们可以而且应该被包括在内，如果这样做会导致Backlog转换为工作软件。 Scrum NEVER建议仅在Sprint Backlog中包含编码任务。事实上，Scrum要求团队实现跨职能。
基本上我将用户故事分解为更新Sprint积压的技术任务，并想知道是否可以在sprint积压中更新和跟踪具有非编码角色的任务。
这听起来很可疑。只是'你'谁打破了任务？应该是整个团队在计划会议的第二部分中分解任务。同样，非编码任务可以包含在Sprint中。 只是为了给你一个现实的例子：在我的Web开发团队中，典型的Backlog具有以下任务。 1.定义和发现 2.设计和创建测试矩阵 3.将单元测试写入测试矩阵 3.使单元测试通过的代码 4.测试 5.回归测试 6.调试 7.查看'使用PO的工作软件（如果需要确保这是PO想要的那样）
修改
关于任务的另一点。 计划期间添加的任务应在必要时不断分解/更新/重命名。这一点的重点是添加一组透明的分解事件，完成后，最终会导致按照QA标准运行的软件，最有效和最有效。这些任务应该被选中并在跨职能上进行，不应该在团队成员之间阻止。
希望这有帮助！
答案 2 :(得分：1)
简短的回答是 - 无论哪种方式最适合您的团队和相关的用户故事。
例如，如果我们正在努力将一段代码重构为用户故事的一部分，我们可能会分出一个单独的任务来处理它首先进行测试。但如果它是新开发者，我们推断它将在我们的过程中进行测试（通常使用TDD）。
其他示例包括有时会分开一项单独的任务，以涵盖协调与编码所花费的时间，与外部供应商的集成测试等等。 - 基本上，任何有助于弥补特定故事的谨慎和可衡量的任务（包括一些你上面列举的例子。）
一句话是，每个故事都没有设定公式，而是根据每个故事的个别需求定制任务（即使这些任务与代码无关）。
答案 3 :(得分：1)
如果您在每个用户故事中创建分析，编码，审查，测试等任务，您将接近称为Scrumfall的东西（每次迭代分为瀑布阶段）。这是Scrum的一种气味。基本上这些活动应该包含在单个任务中：“做某事”意味着做你需要的所有事情来完成“某事”=你是专业的开发人员，你知道（或政策说）完成任务需要做些什么。 / p>
这是一般情况。有时你确实需要将任务划分为“活动”，但首先你应该从普通过程开始，只有当你有真正的理由时才使用这个工具 - 例如一次迭代中的尖峰任务和第二次迭代中的真实任务。
编辑：我曾将任务划分为一次。我们没有做TDD，但测试是在完成任务后编写的。因此，每个开发任务都与测试任务配对，以表明它可以由另一个开发人员完成，有时与开发并行。但是，另一个开发人员测试的责任是团队决策，对于复杂的任务，他们确实这样做了。
答案 4 :(得分：0)
如果您专注于应用于任务跟踪的所有工作，将您的故事分成更小（1-3分），那么您将努力变得更加敏捷。小故事几乎不需要任务级别估计或跟踪。您的PO的优势在于能够优先处理较小的功能集，并且您可以专注于提供价值，而不是重复记录明显的步骤。当然，按照每个小时的小时跟踪一个团队商定的标准做法并不是很有用。