我在一家位于印度的大型外包公司工作。我在美国，有一个由 3 名开发人员组成的团队，我们正在使用 Scrum 实践，并且我们的方法取得了巨大的成功。
我的问题是我们公司要求我们每月估计活动时间，而我们每周进行迭代。系统提供了 45 个活动的列表。举个例子来说明它的精细程度，我们有一些活动，比如编码、编码审查、编码返工。
现在每天我们都应该在这些活动中输入实际时间。更糟糕的是，时间跟踪系统设计得很差，而且速度很慢。
管理层在此过程背后的基本原理是，他们希望使用记录的这段时间来预测未来的工作。但问题是没有适当的流程来确保我们输入正确的时间。所以我们最终会输入任何数字和一天的结束。
这影响了团队的生产力和士气，并破坏了整个目的。
您对敏捷项目中的时间跟踪有何看法？
您对敏捷项目中的时间跟踪有何看法？
100% 浪费：当要求您这样做时，您的经理实际上是在阻止您编写代码，这是唯一真正为产品增加价值的东西（更不用说您必须使用的应用程序很慢，设计不佳）所以这看起来实际上接近 200% 的浪费）。这对我来说真的听起来像是过时的命令和控制。这应该由 ScrumMaster 作为一个障碍来处理。
确保并把它作为你的 Scrum Master 提出来，也在你的回顾中提出。
因为您可能不得不忍受它，所以我建议两种方法：
除非您在ROWE工作，否则很可能应该将时间记录在某个地方，以便支付薪水的人知道钱花在了哪里。这有多大用处，能用多少，可以永远争论不休。 基于证据的调度可能是你的管理层所拥有的想法，它有可能发挥作用，也有可能适得其反。
我很想看看管理层是否会同意这里的一些中间时间线，以便迭代和计划保持一致。尝试计划未来 3-4 周的问题在于，未来 1-2 周发生的事情会对其产生巨大影响。我的建议是看看是否可以商定 2 周的时间表，以便一次计划近半个月。这有点妥协，但假设每月数据进入的任何系统都会接受每两周一次的数据。另一种方法是每月进行一次迭代，尽管这可能会导致我想象中的一些剧变。
如果有信任、诚实并且大多数人都尊重信息，那么时间跟踪会很有用。这可能会问很多，因为我想很多人已经被这样的系统烧毁了。管理层是否知道时间跟踪的缓慢和糟糕的设计？例如，如果每天需要一个小时来记录所有时间，并且您可以解释为什么会这样，那么可能有机会获得更好的系统。这里的一个关键点是要知道具体是什么问题，为什么会出现问题以及可以提出什么样的建议，虽然我想说应该跟踪时间，但可以使用电子表格作为一种技术含量相对较低的方式，对管理来说可能不是很好，但其中一部分是接受权衡，IMO。
听起来时间跟踪可能有点过于细化，或者在其条目中过于僵化。如果他们不是让您在一天结束时输入每个类别的时间，而是要求您保留一个日志，您可以填写您当前在一天中所做的事情 - 所以您会得到这样的东西：
上午 8:30 - 上午 9:45：编码上午 9:45 - 上午 10:00：编码审查
等等。
这是困难的一个。问题是使用的时间不能预测未来的工作。这是非常有据可查的，也是许多人落入的危险陷阱。速度可以帮助预测未来的工作，但它在设计上掩盖了时间。
这种方法的问题在于：并非所有时间都是一样的。抓紧时间将工作变成“理想”时间。未来的工作不是由正在做这项工作的团队（并且没有两个团队是相同的）估计的，而是由使用这些时间来提出一些算法的管理层估计的。听起来有点熟？这不是 Scrum 或敏捷。管理层既不了解 Scrum 的过程，也没有接受它。
有这种混乱是不好的。客户认为你提供的东西不是你，团队成员在错误的假设下工作，管理层没有提供你真正需要的支持。
所以，你在几个小时内放下什么真的无关紧要......这个过程很可能会退回到一种非敏捷方法，这种方法在统计上将与仅仅弥补几个小时并随机报告它们一样准确。冒着听起来很荒谬的风险，您不妨节省时间并弥补几个小时。
现在，如果用时间来查看您在面试上花费了多少，那么在没有跟踪系统的情况下很容易衡量。
如果将时间用于计费，那就另当别论了。这与 Scrum 无关，而是业务流程的一部分。
我在一个正式的测试课上，讲师非常努力地说服一个学生使用时间表来跟踪时间，因为整个软件工程/项目管理理论都是基于该时间表进行线性投影。问题是现实是非线性的（取决于项目的波动性） 敏捷过程如 scrum 关注的是人而不是流程，而是人和业务如何。因为我们提到跟踪时间用于计费客户。跟踪时间的问题是它可能会伤害到人。比如你估计任务10天做，下次做类似的任务，现在10天因为一些不可预知的原因你不能做，即使是你的scrum master或PO也能理解和分享你的思念截止日期（不完全是你的错）...... 但是该层后面的其他人怎么样，高级经理，其他项目经理，其他开发人员......他们可能会误读你的表现有问题......所以对我来说，如果我们有办法跟踪时间应该没问题完全落后于开发人员，然后我们使用这些数据来分析根本原因和反馈，以便团队从中学习。棘手的部分是在不给人们造成不良感觉的情况下做到这一点，我仍然找不到任何工作场所可以做到这一点，除了谣言说谷歌是他们花哨风格的地方。所以对我来说，如果我们有办法完全落后于开发人员，跟踪时间应该没问题，然后我们使用这些数据分析根本原因和反馈，让团队从中学习。棘手的部分是在不给人们造成不良感觉的情况下做到这一点，我仍然找不到任何工作场所可以做到这一点，除了谣言说谷歌是他们花哨风格的地方。所以对我来说，如果我们有办法完全落后于开发人员，跟踪时间应该没问题，然后我们使用这些数据分析根本原因和反馈，让团队从中学习。棘手的部分是在不给人们造成不良感觉的情况下做到这一点，我仍然找不到任何工作场所可以做到这一点，除了谣言说谷歌是他们花哨风格的地方。