为控制 Scrum 成本而追踪时间？

Kevin Krac 有一个问题，是关于在 Scrum 中追踪完成任务所需时间的：

当开发人员 A 把自己的任务搁置一段时间（也许是一整天，甚至两天），以帮助另一位开发人员 B 对其任务做分析或者编码……他们应该如何说明那个故事 / 任务的‘实际工作量’呢？ 应该把总时间摊在他们一起做的那个故事 / 任务上，并乘以 2 吗（因为他们是两个人）？还是只记录花费的总时间，并算在那个负责该任务的开发人员身上？抑或是这无关紧要？

为什么你想追踪每个 Scrum 任务的实际开发时间？一个可能的原因或许是为了控制成本。Charles Bradley不喜欢这个想法：

试图在 Sprint 任务级别做成本核算，是在试图修改 Scrum 让它做一些 Scrum 不应该做的事情。 如果你是出于其他原因去追踪时间，那么你尽管去使用在了解 Scrum 之前所使用的方法就好了，但请不要乱用 Scrum 框架去那么做。此外，不要试图拿耗费的时间（可计费的时间，或者其他什么时间）同在 Scrum 任务上花费的时间做比较。重申一下，我认为这是“滥用”Scrum 框架。

事实上，Ron Jeffries 把这个问题本身看作是一个危险信号：

我认为，控制成本是项目或组织运作不良的主要标志。产出的价值应该会明显高于这种成本，做详尽的成本核算显然是浪费时间。 此外，我碰巧知道在几乎所有的审计工作中，精确的细节并没有价值。这一结论是我多年作为开发经理管理资本项目得出的。

[…]

随着时间的推移，这种成本是团队成本中不可或缺的。我知道，任何业务过程都没有必要了解比这更多的细节。

但是，如果你的团队时间分配给多个同时进行的项目呢？这种情况下，为了控制成本，需要追踪单个任务的时间吗？ Ron 的建议是要彻底避免让团队接手多个同时进行的项目：

别那么做。这会让交付价值变得更慢，对所有客户都会变慢。通常，对于不明智的想法，不会有人先站出来对你说“当心这个歪主意”。

查看英文原文： Time-Tracking For Scrum Cost Control