11

Sprint Backlog 中可以包含和跟踪哪些类型的任务作为工作项?

Sprint backlog 中是否可以包括分析、审查和单元测试(用户故事),或者只能包括和跟踪核心编码任务?

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

4

5 回答 5

7

您有这些要作为工作项进行跟踪的任务。小心这样做。

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

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

你把他们当作不值得信赖的人。

  1. 分析用户故事。无论如何,他们都会这样做。为什么要写下来?他们会忘记吗?重点是理解。不是文档。不是时间管理。

  2. 代码审查。你希望他们这样做。你必须创造这样的文化,并且结果是有益的。

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

    如果代码审查的结果是“每个人都可以学习的新的最佳实践”加上“也许您应该根据其他最佳实践重新考虑这一点”,那么也许人们会参与。

  3. 单元测试是冲刺的一部分,没有任何问题或讨论。
    事实上,它——也许——是冲刺中重要的部分。单元测试首先出现,几乎在任何其他代码之前。你不需要说这个。事实上,这样说的行为表明您的开发人员不能被信任进行测试。

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

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

这是重要的部分。

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

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

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

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

为什么你觉得有必要“控制”和“胁迫”你的开发者?他们为什么不自己做这件事?

于 2010-10-22T12:23:38.023 回答
4

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

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

Sprint backlog 中是否可以包括分析、审查和单元测试(用户故事),或者只能包括和跟踪核心编码任务?

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

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

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

编辑

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

希望这可以帮助!

于 2010-10-22T16:05:32.227 回答
1

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

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

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

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

于 2010-10-22T12:26:12.980 回答
1

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

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

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

于 2010-10-22T15:57:59.487 回答
0

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

于 2010-10-22T19:20:18.967 回答