我在一家位于印度的大型外包公司工作。我在美国，有一个由3名开发人员组成的团队，我们正在使用Scrum实践，并且在我们的方法上取得了巨大成功。时间跟踪和敏捷方法
我的问题是，我们公司要求我们估计每月的活动时间，而我们每周都在进行迭代。该系统提供了45项活动的清单。为了举例说明它的细化程度，我们开展了诸如编码，编码审查，编码返工等活动。
现在我们每天都应该输入实际的时间aginst这些活动。而使事情变得更糟的是，时间跟踪系统的设计很差，速度很慢。
管理层在这个过程背后的基本原理是他们希望使用这个时间记录下来预测未来的工作。但问题是没有任何流程来确保我们输入正确的时间。所以我们最终将任何数字和一天结束。
这影响了团队的生产力和士气，击败了整个目的。
对敏捷项目中的时间跟踪有什么想法？
请确保将它和您的scrum master相提并论，并在您的回顾中提出。
因为你可能要忍受它让我提出两种方法：
那么，scrum的主人是我们的客户，作为一个将我们的客户带到这里的供应商只会让我们看起来效率低下。除此之外，我们的管理层将会对此感到不满。我没有选择，但同意点1，你把:)。在一个拥有10000人的公司中，我无法为时间管理系统创建更好的用户界面。感谢您的建议保罗！ – user176687 2010-02-10 07:02:00
你处境艰难。 我会去第二个建议。我们被迫使用SAP接口在工作中输入数据。我们的程序员之一编写了一个Python程序，可以自动输入所有数据。现在我们都用它并且喜欢它。为你的情况，我想象一个按钮栏上的所有状态。点击状态将启动该类型工作的计时器。这将全部记录到文件中。在一天结束时运行另一个解析该文件并将其上传到笨重系统的程序。 – 2010-02-10 14:32:44
保罗按钮栏是一个很好的主意。跟踪时间不那么痛苦会很好。 – user176687 2010-02-10 16:52:51
听起来像时间跟踪可能有点过于细化，或者过于僵硬。如果不是让你每天在结束的每个类别中输入时间，而是要求你保留一个日志，你可以填写你当前正在做的这一天 - 所以你会得到这样的：
上午8:30 - 9:45 AM：编码 上午9:45 - 10:00：编码审查
等等。
我认为这是一个很好的建议，但它会在个人层面上起作用，以提高个人效率。日志不能用于管理计划。谢谢 ！ – user176687 2010-02-10 07:05:42
一旦项目完成*（或由不在项目中工作的人员），可以汇总日志*。这样，您可以在不中断正常工作的情况下获得团队总数。 – Amber 2010-02-10 09:24:37
谢谢Dav。保罗建议的按钮栏进一步提供了这个想法，并为我提供了一个我们可以实施的解决方案。 – user176687 2010-02-10 17:01:29
您对敏捷项目中的时间跟踪有什么想法？
100％的浪费：问你这样做的时候，你的经理实际上是让你从代码的工作是真正增加价值的产品（甚至未提到的应用程序，您必须唯一使用速度慢，设计不好，因此这看起来实际上接近200％的浪费）。对我来说，这听起来像是过时的命令和控制。这应该由ScrumMaster作为障碍来处理。
谢谢帕斯卡。就像我上面所说的那样，scrum master是我们的客户，作为一个将我们的客户带到这里的供应商只会让我们看起来效率低下。 – user176687 2010-02-10 07:03:31
因此，ScrumMaster无法删除您的经理创建的障碍，因为它们不可见？而ScrumMaster实际上无法屏蔽团队免受外部干扰？听起来很奇怪，如果可能的话，不确定你的Scrum的实现是否是最优的。 – 2010-02-10 07:43:10
我同意，但鉴于客户供应商关系，这是我们项目的现实。时间跟踪是相关的计费，这是一个敏感问题。许多人从事许多活动，但不能为客户收取费用，但他们必须以某种方式“管理”系统中记录的内容。 – user176687 2010-02-10 17:00:25
除非你在ROWE工作，否则应该在某个地方记录时间，以便支付工资的人知道钱花在哪里。这是多么有用，它可以使用多少可以永远辩论。 Evidence-based Scheduling可能是你的管理层有这样的想法，它有可能发挥作用，并有可能发生适得其反的后果。
我会忍不住看是否管理会同意一些插图中的时间表使这里的迭代和规划保持一致。试图规划3-4周的问题是，未来1-2周发生的事情会对此产生巨大影响。我的建议是查看是否可以同意2周的时间表，以便每次计划差不多半个月。这有点妥协，但假定无论月度数据采用什么系统都会接受双周的事情。另一种方法是每月进行一次迭代，尽管这可能会导致我想象的一些动荡。如果没有信任，诚实，最让大家尊重有关信息
时间跟踪是有用的。这可以问很多，因为我可以想象许多这样的系统已经烧毁了。管理层是否知道时间跟踪的缓慢和糟糕的设计？例如，如果每天花一个小时记录所有时间，并且可以解释为什么确实如此，那么可能有机会获得更好的系统。这里的一个关键点是要知道具体是什么问题，为什么他们是问题，以及可以提出什么样的建议，虽然我认为应该跟踪时间，但可以使用电子表格以相对低科技的方式对于管理来说可能不是很好，但其中一部分是接受权衡，IMO。
谢谢。你遇到了一个关于试图规划3-4周的关键点。我们应该每周做一次。我计划建议的一个折衷方案是仅跟踪实际工时5-6个主要组织，例如编码，体系结构，测试和组织规定的主要组织，并且我们可以计划，在另一个工具中估计用户故事，正在使用（拉力赛） – user176687 2010-02-11 07:09:03
这是一个艰难的。问题是使用的时间不会预测未来的工作。这是很好的文件记录和许多陷入危险的陷阱。 Velocity可以帮助预测未来的工作，但它会通过设计隐藏时间。
与方法的问题是：不是所有的时间都是一样的。捕捉小时会变成“理想”时间。未来的工作不是由正在从事这项工作的团队估计的（并且没有两个团队是相同的），但是管理层已经利用这些时间来提出一些算法。听起来有点熟？这不是Scrum或敏捷。管理层既不了解Scrum的过程，也不了解Scrum的过程。
有这种困惑不好。客户认为你提供的不是你的东西，团队成员是在错误的假设下工作的，而且管理层不在那里提供你真正需要的支持。
所以，它真的不会不管你放什么下来小时......很可能在过程中会回落到一个非敏捷方法，这将是统计学上只是做了个小时并随机报告他们准确。冒着可笑的风险，你不妨节省你的时间，并花上数小时。现在
，如果时间来看看你花多少钱做采访，这是不容易的跟踪系统来衡量。
如果时间用于计费，那是不同的故事。这不是与Scrum相关的，而是业务流程的一部分。
我在一个正式的测试课上，讲师很努力地说服学生使用时间表来跟踪时间，因为整个软件工程/项目管理理论都是基于那个时间表来做线性的投影。 问题是现实是非线性的（取决于项目的水平波动） 像Scrum这样的敏捷过程关注的不是人，而是人和业务。 ，因为我们提到跟踪时间用于帐单客户。跟踪时间的问题是它可能会伤害人们。例如，你估计任务并做10天，下次你做类似的任务，现在有10天，因为一些不可预知的原因你不能这样做，即使你的scrum master或PO也能理解和分享你的失落感截止日期（不完全是你的错）......但是那个层面的其他人，高层管理者，其他项目经理，其他开发人员......他们可能会认为你的表现存在问题是错误的。所以对于我来说，如果我们有一种方法可以完全落实开发人员，那么跟踪时间应该没问题，然后我们使用这些数据来分析团队从中学习的根本原因和反馈。棘手的部分是没有给人们造成不好的感觉，我仍然找不到任何工作场所可以做到这一点，除了传闻说谷歌是他们的花哨风格的地方。
马丁福勒：估计既不好也不坏。如果您可以在不估算的情况下有效地工作 ，那么请继续并且 确实没有它。所以我猜想跟踪也是一样。 http://www.thoughtworks-studios.com/sites/default/files/resource/twebook-perspectives-estimation_1.pdf – Quang 2013-06-26 17:01:40
什么是你想要的建议的问题或类型？从下面的评论中可以看出，由于业务的原因，您处于固定位置。除了解决系统问题（自动输入数据或简化时间输入）之外，还不清楚我们如何提供帮助。 – 2010-02-10 12:47:19
嗨吉姆，我不希望这个论坛的解决方案。我只是想从人们的想法中获得想法。例如，我发现Paul提供的一个按钮栏的建议非常有用，这符合您对自动化数据输入的建议。 – user176687 2010-02-10 16:51:23
这个问题似乎无关紧要，因为它涉及管理问题，而不是特定的编程问题。 – 2013-06-26 16:53:54