想象一下场景，一家企业正在考虑使用 Scrum 方法进行敏捷开发。他们已经为团队系统实施了 Scrum，每个人都对此非常满意。然而，企业希望将他们的开发成本资本化，并要求修改 Scrum 积压工作项模板以包含完成任务所花费的时间。这个想法是他们需要知道开发人员花费了多少时间进行生产性工作，即他们花费了多少时间来添加新功能。
业务中的一些人（包括我自己）遇到的问题是，记录你在某事上花费了多少时间，这违背了 Scrum 的目标。从首席开发人员的角度来看，我只想知道我们有这么多时间来做这么多工作。我们记录了任务还剩下多少时间，我们可以看到我们离实现目标还有多远。
也许我错过了重点？你告诉我。但是，如果有人知道一种我们可以在不记录我们花在做某事上的确切时间的情况下工作的方式，并且仍然取悦投资资金的人，那么您的回答将不胜感激。
作为一名开发经理，我有兴趣确保开发顺利进行（通过 Scrum），并且每个项目都考虑到时间，这样我们就知道我们把钱花在了哪里（时间跟踪）。
因此，在冲刺期间，团队成员被要求更新未完成任务的剩余时间以计算燃尽图。它不应该超过几分钟。由于我们使用 Scrum，团队决定任务，我不在乎谁在做什么，只要我们有燃尽图。
我还要求他们跟踪每个项目的时间，这不是很详细。我不想跟踪他们的每一分钟。此信息用于了解发布版本需要多长时间或开发产品需要多少资金。
由于我们使用 Scrum，时间跟踪非常简单，因为团队的所有成员都在很长一段时间内从事同一个项目。
Scrum 不是死板的，它完全取决于适应性和适合您的需求。
你为什么不以小时而不是故事点来估计故事。我们也面临同样的情况，我们开始在几个小时内进行估算。每天根据估计的时间，开发人员记录他们在一个故事上工作了多少时间。每天可以看到故事需要多少时间，最后可以看到估计和实际花费的时间。我们使用 XPlanner 来跟踪这一点，开发人员每天需要一分钟来记录时间。基于此信息，您始终可以测量有助于下一次迭代的速度。
除了与项目相关的故事外，我们还记录了在其他活动中浪费的时间，例如会议、环境停机、生产支持等。在一段时间内，这些信息为我们提供了很多信息，我们设法减少了很多浪费的时间。
第一个问题是——您是咨询店还是内部 IT 店。如果是前者，那么可能需要实际值才能让他们正确地向客户收费。如果是后者，而你们都是有薪水的，那么原因就不清楚了。我总是怀疑任何想知道“程序员花了多少时间从事生产性工作”的经理。这是一个度量标准，我告诉任何形式的敏捷开发团队的关键之一是，为了团队同意的明确目的，应该捕获度量标准。
我会问“问题背后的问题”是什么——或者管理层真正在寻找什么。为什么他们关心开发人员的生产力？他们是否很难向他们的经理解释发生了什么？是否有可以概括的团队指标？
简而言之——你的经理可以被认为是团队的客户，所以找出你的客户想要什么，并找出最好的方式——作为一个团队——来提供它。
Scrum 和其他敏捷开发方法在双方参与的人员之间存在信任时效果最佳。管理层需要相信开发人员努力工作并且工作良好。开发人员需要相信管理层尊重他们的意见，并要求他们根据业务需求做适当的工作。如果没有这种信任，您的流程将无法正常运行。没有环境是完美的，但在某些时候，信任问题可能会变得非常糟糕，以至于变得不可行。
话虽如此，作为一名开发人员，我必须“仅仅因为”做很多事情。例如，我必须做这种事情，因为这就是整个组织的工作方式——包括开发人员。我可以忍受这一点。我会说跟踪你的时间，但从冲刺开始计划。有意义地记录您的“非生产性”时间——如技术研究、办公任务等——无论它们是什么——以便业务人员明白即使不开发代码，你也始终保持高效。
编辑哦-如果时间跟踪活动特别繁重，例如填写详细的每日日志，请确保您非常清楚地跟踪跟踪时间所花费的时间，以便他们知道活动的成本。
我们已经使用 Agile/SCRUM 大约 2 年了，我们从未记录过实际情况。
似乎时不时地试图让每个人都记录这些信息。这通常是由于糟糕的 sprint 造成的，而责任完全在于糟糕的估计。但是很容易忘记把这些标记下来——尽管我相信只要有足够的“温和的刺激”，它就会成为习惯。
我一次又一次地看到的想法 - 并且我同意的一个 - 是您的速度应该回答您（或产品所有者）需要询问的有关任务进度的任何问题。