在我的公司中，单个任务永远不可能由一个人完成。将有单独的人进行质量检查和代码审查每个任务。这意味着每个人将针对每个任务给出完成所需时间的估计。

问题是，我应该如何处理掉？如果我将小时数汇总在一起，请假设以下估计：

10小时-开发时间

4小时-质量检查

4小时-代码审查。

任务估计= 18小时

在每天结束时，我要求用“剩下多少时间才能完成”来更新任务。但是，每个人通常只考虑自己的部分。他们应该标记剩余的工作量，然后再添加工作量估计吗？你们好吗？

更新

为了澄清一些事情，在我的组织中，一个故事中的每个任务都需要3个人。

1. 有人来制定任务。（进行单元测试等）
2. 负责审核任务的质量检查专家（他们主要进行集成和回归测试）
3. 技术负责人进行代码审查。

我认为没有错误的方法或正确的方法，但这是我们的方法……而且这种情况不会改变。我们会以团队的形式尽可能地完成故事的最小层面。在开发完成之前，您实际上无法测试某些项目是否可行，并且您也无法查看代码的质量……因此，您可以做的最好的事情就是将这些内容分解为较小的逻辑切片，以便可以测试最基本的功能。尽可能早地进行审查。

我对以这种方式工作的人的问题是，当以这种方式设置他们时，如何烧掉“任务”。除非一个任务有它自己的子任务（JIRA不允许）...我不确定每天完成跟踪“剩下的事情”的最佳方法。

那是三项任务，而不是一项。

它可能是一个功能/故事，但它是三个任务。一个人可以在有限的时间内完成一个任务。

TL; DR

您以多种方式错误地使用了燃尽功能。任务和故事已完成或未完成；通过尝试跟踪消耗中基于时间的计划估算值的偏差，您实际上是在重新估算进度，而不是估算剩余的工作产品。

在Scrum中，您应该衡量实现Sprint目标的进度，而不是衡量Sprint的时间范围。这将重点放在团队能力和功能交付上，而不是持续的日程安排调整上。

任务与故事

您正在混合任务和故事。故事包括根据团队的“完成的定义”完成故事所需的所有任务。除非故事的所有任务都完成，否则故事被视为100％不完整。在Scrum中，总是以某种方式估算故事。通常，它们是根据故事点进行估算的。

任务是完成故事所需的步骤或里程碑。尽管每个任务可能都具有依赖性和先决条件，但是您可以肯定地说代码检查是否完成，与其他任务无关。

烧掉

在Scrum中，燃尽图显示了sprint或项目的剩余工作量。实际的燃尽图通常会达到平稳状态。在某些情况下，图表甚至可以上升。例如，在一个为期一周的冲刺中，有两个故事分别得到3分和5分，您的数据点可能看起来像这样：

Mon | Tue | Wed | Thu | Fri
--- | --- | --- | --- | ---
 8  |  5  |  5  |  5  |  0

在这种理想情况下，您将从8个故事点开始。3点故事在星期二下午完成，而5点故事直到星期五才完成。直到故事达到完成的定义时，故事点数才从烧录中扣除。如果您使用理想时间而不是故事时间，那么唯一改变的是比例。

定时装箱

普遍接受的做法是确保您的任务在1/2天到2天之间分解成一口大小的块。每天站立或Sprint待办事项中超过一天的差异应该是不言而喻的；无需执行正式身份拉动。

您还可以在燃尽图上执行统计分析，以确定您的冲刺是否趋势正确。微小的偏差或平稳状态是正常现象，但是如果没有人在日常站立时提高任何障碍物，但您的倦怠感似乎卡住了，则通常表明Sprint Backlog被错误地估计或存在“看不见的工作”需要在您的过程中变得明确。

您可以在质量检查执行任务之前将开发任务定义为“完成”吗？您可以在开发完成之前将代码审查定义为“完成”吗？如果开发人员和代码审查未完成，能否进行质量检查？

我要说的是，您应该将这三个项目汇总到一个任务中，并且三个人应该共同努力。

Scrum并没有说任何项目是任何团队成员的责任。相反，冲刺日志项目是TEAM的责任。如果需要三个人来执行一项任务，那么就是这样。

没关系 只要整个故事相对一致，燃尽图仍将以任何一种方式起作用。使用最自然的方式报告团队。

我的团队实际上进行了某种混合，尽管没有正式协议。如果我们认为一项任务要花一个人两天的时间，那么我们会花16个小时，但是如果两个人最终共同完成一项工作，我们就不会更改它。

初步估算之后，非正式的来说，对我们团队来说，完成的百分比要比剩余的小时数高。如果我们最初认为需要两天时间，但是在一天之后，我们认为它仅完成了25％，那么我们就可以享受原来16个小时的4个小时。从技术上来说，这需要12个小时，因此我们估计需要24个小时，因为我们可能会在剩下的3天内减去4个小时。

最初让我成为一名Scrum管理员感到很恼火，但是看起来很奇怪，这是一种很自然的估算方法，因为开发人员真的不愿意为估算增加时间。所有这些平均下来使燃尽仍然有用，这很重要。

任务剩余时间并不重要：在整个故事完成之前，什么也无法交付。

如果要通过让人们填写任务的剩余时间来跟踪故事剩余的时间（总体），则可以按人分配任务。

说：

• 艰巨的任务可能表明您的故事过大。在这种情况下，最好的解决方案是减小故事的范围和大小，如果减小故事的范围和大小，则跟踪任务的剩余时间不再重要（它们是否已完成-未完成任务的估算总和）足够细）。
• SCRUM鼓励每个人了解需要做的事情。如果您要分配任务给人员（而不是角色），那么即使开发人员无所事事，您也可能无法发布自己的故事，因为QA处于瓶颈。

将任务分为多个任务，并将其输入为任务，每个任务由不同的人处理。

原始任务：修复某些问题

新任务：（原始任务的父项的子项）

• 开发人员A-解决问题
• 开发B-帮助开发A解决问题（例如，配对编程，代码审查）
• 开发人员A-开发人员使用Dataset X测试此修复程序
• 开发人员B-开发人员使用数据集Y测试修复