时间跟踪和敏捷方法论

Question

我在印度的一家大型外包公司工作。我在美国，拥有一个由3名开发人员组成的团队，我们正在使用scrum实践，并且在我们的方法上取得了巨大的成功。

我的问题是我们公司要求我们每月估算活动时间，而我们则每周进行一次迭代。该系统提供了45个活动的清单。为了举例说明它的粒度，我们有Coding，Coding Review，Coding Rework等活动。

现在我们每天都要进入这些活动的实际时间。更糟糕的是，时间跟踪系统的设计非常糟糕且非常慢。

管理层在这个过程背后的理由是他们希望利用这段时间记录到未来的预测工作中。但问题是没有适当的流程来确保我们输入正确的时间。所以我们最终会把任何数字和当天结束。

这会影响团队的生产力和士气，并且会影响整个目标。

您对敏捷项目中的时间跟踪有何看法？

Answer 1

  

您对敏捷项目中的时间跟踪有何看法？

100％浪费：当您要求执行此操作时，您的经理实际上是让您无法处理代码，这是唯一真正为产品增加价值的东西（甚至没有提到您必须使用的应用程序很慢） ，设计不佳，所以这看起来更接近200％的浪费）。这对我来说听起来像是过时的命令和控制。这应该由ScrumMaster处理，作为障碍。

Answer 2

确保并将其作为你的scrum大师的誓言和誓言，并在你的回顾中提出。

因为你可能不得不忍受它让我提出两种方法：

1. 尽可能准确，并在当天结束时进行估算。
2. 将前端写入笨重的报告系统。弄清楚易于使用和节省时间的界面，编写它，然后让它喂养笨重的旧系统。

Answer 3

除非你在ROWE工作，否则很可能应该把时间记录在某个地方，这样任何支付工资的人都知道钱花在哪里。这是多么有用以及它可以使用多少可以永远辩论。 Evidence-based Scheduling可能是您的管理层的想法，它有可能发挥作用，并且可能会适得其反。

我很想知道管理层是否会同意这里的时间线，以便迭代和计划一致。尝试计划3-4周的问题是，在接下来的1-2周内发生的事情会对此产生重大影响。我的建议是看是否可以商定一个为期两周的时间表，以便一次计划将近半个月。这是一个妥协，但假设每月数据进入的任何系统将接受两周一次的事情。另一种方法是每月迭代，但这可能会导致我想象的一些剧变。

如果有信任，诚实，并且大多数人都尊重这些信息，那么时间跟踪会非常有用。这可能是一个很大的问题，因为我想这些系统已经烧毁了很多。管理层是否知道时间跟踪的缓慢和糟糕的设计？例如，如果每天花费一个小时来记录所有时间，并且您可以解释为什么会出现这种情况，那么可能有机会获得更好的系统。这里的一个关键点是要知道具体是什么问题，为什么它们是问题以及可以提出什么样的建议，因为当我说应该跟踪时间时，可以使用电子表格以相对低技术的方式可能不太适合管理层，但部分原因是接受权衡，IMO。

Answer 4

听起来时间跟踪可能有点过于细化，或者过于严格。如果您没有在当天的 end 中为每个类别输入时间，而是要求您保留一份日志，而不是在当前正在执行期间 / em>那天 - 所以你会得到这样的东西：

上午8:30 - 上午9:45：编码 上午9:45 - 上午10:00：编码审核

等等。

Answer 5

这是一个艰难的。问题是所用的时间不会预测未来的工作。这是非常好的记录和许多陷入危险的陷阱。 Velocity可以帮助预测未来的工作，但它会模糊设计的时间。

这种方法的问题是：并非所有时间都相同。捕获小时将工作转变为“理想”时间。未来的工作估计不是由正在开展工作的团队（并且没有2个团队是相同的），而是由管理层使用这些时间来提出一些算法。听起来有点熟？这不是Scrum或敏捷。管理层既不了解Scrum的流程，也不了解Scrum的流程。

有这种困惑并不好。客户认为你提供的是你不是的东西，团队成员在错误的假设下工作，管理层不能提供你真正需要的支持。

所以，你放下几个小时真的无关紧要......这个过程很可能会回归到一种非敏捷的方法，这种方法在统计上就像只是花费数小时并随机报告一样准确。冒着听起来很荒谬的风险，你可以节省你的时间，只需要花费数小时。

现在，如果时间用于了解您在采访中花了多少钱，那么在没有跟踪系统的情况下很容易衡量。

如果时间用于结算，那就是另一个故事。这不是与Scrum相关的，而是业务流程的一部分。

Answer 6

我正在参加一个正式的测试课，讲师正在努力说服其中一个学生使用时间表来跟踪时间，因为整个软件工程/项目管理理论都是基于该时间表进行线性投影。 问题是现实是非线性的（取决于项目的水平波动性） 像scrum这样的敏捷流程专注于人们不会处理，而是关注人和业务。 因为我们提到跟踪时间用于计费客户。追踪时间的问题是它可能会伤害到人。例如，你估计任务并做10天，下次你做类似的任务，现在有10天由于一些不可预测的原因你不能这样做，即使你的scrum主人或PO可以理解和分享你的失踪的感觉截止日期（不完全是你的错）......但是那个层面的其他人，高层管理人员，其他项目经理，其他开发人员......他们可能会错误地认为你的表现有问题......所以对我而言如果我们有一种方法可以完全支持开发人员，那么跟踪时间应该没问题，然后我们使用这些数据来分析根本原因和反馈，以便团队从中学习。这个棘手的部分是没有给人们带来不好的感觉，我仍然无法找到任何工作场所可以做得很好，除了谣言说谷歌是他们喜欢的风格的地方。