请确保向您的Scrum Master提出这个障碍，并在回顾中提出。

因为你可能不得不与其共同生活，让我建议两种方法：

1. Be as accurate as possible and give an estimate at the end of the day.
2. Write a front end to the clunky reporting system. Figure out and easy to use and time saving interface, write it, then have it feed the clunky old system.

你对敏捷项目中的时间跟踪有什么想法？

100％浪费：当要求您执行此操作时，您的经理实际上是让您远离真正为产品增加价值的代码编写工作（更不用说您必须使用的应用程序很慢，设计很差，所以看起来实际上更接近200％的浪费）。这真的听起来像是过时的命令和控制方式。ScrumMaster应将此作为障碍来处理。

除非您在ROWE中工作，否则时间应该在某个地方记录，以便支付薪水的人知道钱花在哪里。这有多有用以及可以使用多少可以永远辩论。基于证据的调度可能是您的管理层所拥有的想法，这可能具有潜力并可能会出现严重后果。

我很想看到,管理层是否同意这里的某些内在时间表,以便安排和规划。 试图规划3至4周道路的问题是,今后1-2周发生的情况会严重影响到这一点。 我的建议是,是否可商定一个为期两周的时间表,以便在某个时候规划将近半月。 这是一种妥协的范畴,但假设每个月数据输入的系统将每两周接受一次。 另一种选择是每月进行频率,但可能会造成一些动乱。

时间跟踪可以很有用，如果有信任、诚实和大多数人尊重信息的话。这可能需要很多，因为我想很多人已经被这样的系统所伤害过。管理层是否知道时间跟踪的缓慢和糟糕的设计？例如，如果每天花一个小时记录所有时间，并且您可以解释为什么真的是这种情况，那么可能有机会获得更好的系统。关键在于知道具体问题、为什么它们是问题以及可以提出什么样的建议，虽然我会说时间应该被跟踪，但您可以使用电子表格作为一种相对低技术的方式，可能并不适合管理层，但其中的一部分是接受权衡，我认为。

听起来时间跟踪可能过于细化或者输入方式过于严格。如果他们改为让你在一天中记录你当前在做什么，而不是在结束时输入每个类别的时间，那会怎样呢？因此，你会得到这样的数据：

8:30am - 9:45am: Coding 9:45am - 10:00am: Coding Review

等等。

这是一个棘手的问题。问题在于所使用的时间不会预测未来的工作。这点已经有很充分的证明，许多人都会陷入这个危险的陷阱中。速度可以帮助预测未来的工作，但它会被设计屏蔽小时数。

这种方法存在的问题是：并不是所有的工作时间都相同。捕捉工作时间将工作转变为“理想”时间。未来的工作预测不是由执行工作的团队估算的（而且没有两个团队是完全相同的），而是由管理层使用这些时间来制定一些算法。听起来很熟悉吧？这不是Scrum或敏捷。管理层既不理解Scrum流程，也不信任它。

拥有这种困惑不好。客户认为您正在提供您没有提供的东西，团队成员在错误的假设下工作，管理层也无法提供您真正需要的支持。

所以，你填写的时间可能并不重要…… 很可能过程会回到非敏捷的方式，这种方式的统计准确度就像随机报告制造时间统计准确度一样。冒着听起来很荒谬的风险，你也可以节省时间，随便编造时间。

现在，如果用时间来看你花了多少时间进行面试，那么不使用跟踪系统也很容易确定。

如果时间用于计费，那就是另一回事了。这不是Scrum相关的，而是业务过程的一部分。

I was in a formal testing class, and the lecturer was trying really hard to convince one of the student to use timesheet to track time, because the entire software engineering/project management theory is based on that time sheet to do linear projection. The problem is the reality is nonlinear (depends on the level volatility of the project) Agile process like scrum focus on people not process, but how about people and business. because we mentioned that tracking time was using for billing customer. the problem with tracking time is it may hurt people. for example, you estimate task and do it 10 day, next time you do the similar task and now with 10 days you cannot do it because of some unpredictable reasons, even your scrum master or PO can understand and share with your the feeling of missing the deadline(not entirely your fault)...BUT how about others behind that layer, top managers, other project managers, other developers...they may read it wrong that you had issue with your performance....so for me tracking time should be fine if we have a way to do it completely behind the developers and we then use that data to analyse the root cause and feedback for the team to learn from it. the tricky part is doing without creating bad feeling for the people which I still cannot find any workplace can do this well except rumor said that Google is the place with their fancy style.