这需要多长时间？Git 知道。

作为软件开发者，我们的所有工作都围绕着源代码控制系统，无论是svn、hg还是git。在我们用于项目的每个存储库中，都保存着我们活动的轨迹，并附有注释和时间戳，可供任何人查看。几年前，我开始构建一个工具，它可以让我为某个工作项分配一个“咖啡杯大小”，然后使用我与该工作相关的 git 提交来计算它花费的时间。 我把它叫做GitCup，它目前仍在开发中，但它的目标是帮助我以尽可能少的精力生成更准确的时间估算。

“为什么？”你可能会问。

我记得我所在的团队第一次决定开始使用Scrum来提高“敏捷”水平的时候。我们花了无数个小时争论应该用斐波那契数列还是2的幂（1、2、4、8、16）来表示故事点数。我们反复修改了好几次，但始终无法达成一致。之后，我们又会一遍又一遍地争论一个故事是4点还是8点，这到底意味着什么？难度是翻倍了，还是需要花费两倍的时间？你看，当时我赞成用斐波那契数列（1、2、3、5、8、13）来衡量每个用户故事的“复杂性”。当然，我错了。

几年后，我来到另一家公司，加入另一个团队，发现自己身处一种混合了看板和Scrum风格的“敏捷”模式。不知何时，高层管理人员突然决定，进行“敏捷”改造是迈向新的“数字化转型计划”的第一步。他们聘请了一家咨询公司，我们团队也请了一位“敏捷教练”来指导我们。

毫无意义的故事点

我们开始用计划扑克牌来估算我们的故事。我常常觉得我的5是别人的2。最后，每个人都会同意最资深的人的意见，只是为了避免显得愚蠢。正是在那时，“冒名顶替综合症”这个词开始真正引起我的共鸣。事实证明，复杂性并不是一个非常客观的指标。

我们的敏捷教练最初是我们的Scrum Master。他拥有丰富的实践经验，我们都从他那里学到了很多。我们每天早上都会聚在一起讨论进度，他会鼓励我们修改正在处理的用户故事的估算。这样做的目的是尽早发现那些更具挑战性的故事。如果进展顺利，我们会减少剩余的故事点；如果发现了一些无法预料的问题，导致最初的估算不再有效，我们会增加故事点。

时间很重要

这办法奏效了一段时间，但很快他就跳槽去了另一个团队。我们开始看到2分的故事被拖了好几天，而8分的故事有时一天就能完成。自然而然地，早上的谈话开始涉及到每个故事“剩余时间”的问题，人们开始互相问“今天能完成吗？”。我们之前一直在用Jira作为电子版的看板，所以过了一段时间，我们开始在故事中加入时间估算，我们不是减少分值，而是减少剩余时间。突然之间，分值又被用作时间的近似值。只是现在，我们除了分值之外，还有实际的时间估算。

这让我很困扰。我们在计划期间讨论故事点或争论剩余时间/天数所花费的精力，为了证明花在故事上的时间是合理的而必须每天记录所做的工作，以及每天更新 Jiras 和时间表（是的，我们也有这些），感觉就像是巨大的浪费。别误会我的意思。我并不属于“不做估算”的阵营。我欣赏可靠的估算对于规划项目交付的价值。我只是希望我们没有那么多开销！

那么还有什么其他选择呢？

那时我第一次想到用我们的提交来追踪时间。我们的代码库基于Subversion，这使得跟踪分支合并的提交更加复杂，但原理依然相同：所有历史记录都保存在那里，包括注释、时间戳和实际的代码更改。直觉告诉我，一定有某种方法可以利用所有这些信息对未来的工作进行统计预测。很久以后，我发现了概率预测的概念，它可以用来根据之前工作项目的数据对未来进行预测。

然而，当时我找不到任何开箱即用的工具，也不愿意自己从头开始做。而且我们团队也因为其他原因陷入困境，所以我的调查就此搁浅。又过了几年，Git 仓库才成为主流，我才想出了GitCup。

痒

后来我加入了一个新团队。这次我们没再遵循Scrum。团队规模很小，分散在多个不同的项目上。我们有很多故事，我们会根据优先级排序，然后从列表顶部开始处理。我们仍然会在早上聚在一起，聊聊进展，当然，通常会问这样的问题：

“你认为这需要多长时间？”