项目时间估算的最佳方案：按代码行数估计

💡

众所周知，软件项目管理非常复杂且困难。一个软件项目可能在其生命周期过程中出现各种各样的问题。而更令人头疼的是，不同问题的应对方案甚至可能是相互矛盾的。而这一切的根源往往都是时间估算不准导致的蝴蝶效应。而“估计代码行数”这一实践或将成为软件项目时间估算的一颗银弹，必将解决一切项目管理问题。

为什么要做时间估算

对于开发者来说，往往会有一个错误的认识是：“反正就是那么多工作量，我做不做估计都是那么多工作量。估算并不解决问题”。那么为什么我们还要做时间估算呢？

在考虑功能的优先级的时候，不单单需要考虑这个功能本身的价值，同时也是需要考虑某个功能的成本。甚至有些需要时间太多的功能可以直接移除出项目的范围。

如果单单只是一味的埋头苦干，而不对未来做出估计。往往就会忽略项目的一些重要的外部依赖。当我们对时间进行估算的时候也是在梳理出一个项目的外部依赖。

一个错误的时间估计可能会严重的影响项目的质量。尤其是项目的成本和范围相对比较固定的时候，时间的估计错误可能会迫使项目不得不放弃质量。
反过来，如果时间过于充裕，可能导致过度的追求质量，而出现过度设计的问题。

时间的估计其实也是会对团队的士气产生重要的影响。背水一战不会是常态，也不适合现代商业项目。而一个漫长的、永无止境的项目也会不由的让人散漫起来。

既然是估计，那么其实就是在考虑未来还没有发生的事情。而未来永远是充满了各种不确定性的，这些不确定性就是所谓的未知。

在技术债的影响下，一个简单的功能可能需要巨大的代价。同时在做估算时，人们又很容易忘记技术债。

由于未来永远不如当前那么生动。不同的人由于不同的背景会对同一个描述想到完全不同的东西。而这里一方面可能导致未来实质的需求变更。

做时间估计的时候，不可能将所有的变量全部一一详细分析。但外部环境的变化有时候对项目的处境会产生巨大的影响。
（想想如果电费突然调高1000倍，项目会发生什么）

不论是按照敏捷的估故事点，还是直接估计人天。最终都不可避免地出现估点不准。而且各种不同的估点方式其实也不乏离谱的例子。

因此估计代码行数，虽然并不一定比其他的估计方式更准确，但也并不会比其他的方式更加不准确。

不论何种估计方式，最终始终不可避免地回到“到底什么时候能做完”这样的基本问题。

有些估计方法，在回答这一问题的时候会非常困难。典型的，T恤尺码的估计方法，很难说S到底是几天。
而直接估计人天，看上去更加直接，但又太过于抽象。毕竟时间是看不见摸不着的。

而代码行数的好处在于，介于两个极端之间。既具体，又能够很好的转化为人天。

往往对于外部依赖，项目管理者往往会比开发人员更善于估计。因为排除掉代码之外，往往是和第三方进行沟通合作，甚至讨价还价。而不是具体实现一个已经非常明确的目标。

估计代码行数可以清晰的为外部依赖的估计划清戒线。对于开发人员可以专注于实现所需的时间；对于管理人员可以专注于评估外部支持的情况。
同时，这样也可以确保后期的工作效率，不至于出现开发人员停下来等待外部依赖的问题。

对于质量，我们既要防范缺乏设计，也要避免过度设计。同时质量也还需要考虑项目安全、审计等等一系列的东西。而估计代码行数能有效地实现：

项目依赖管理。代码行数过少往往可能是引入了一个第三方库来快速实现功能。但问题就在于，这些第三方库的往往没有经过审慎的考虑。甚至存在安全问题。因此通过代码行数，可以避免为了一时的方便而随意的变动项目依赖的库。
方便未来审计和反思。最终可以直接根据行数的不同来看最初的估计到底哪个功能多了，哪个功能少了。
避免缺乏设计。代码行数过多，往往就是因为各种重复。而代码行数过少可能就意味着没有考虑各种校验和极端情况。
避免过度设计。代码行数过多，很可能就是代码提供了太多不必要的可扩展性。而行数过少很可能是为了炫技而牺牲了代码的可读性。

所以，对于一个功能，代码行数不失为一个很好的评价方法。

由于开发人员很难按照10分钟20行代码的速度稳定产出。但开发人员总不至于一天连一行代码也写不出来。

在从代码行数转化为人天的时候，我们可以根据开发人员每天提交代码行数的平均值、最高值、最低值进行分析。提前做好后备方案。
纵使出现开发人员消极怠工，那么也可以根据代码行数的异常迅速的识别出来。至于恶意提交，这个属于是故意搞破坏的行为，建议移交司法机关。

虽然上限可能不如其他花哨的方法高，但是要是论下限可以说是远胜其他一切方案。

但说回来，一个商业项目，往往最重要的就是求稳，往往最重要的就是下限高。

因此，按代码行数做项目估算，在绝大多数情况下可以说是最佳实践了。（不会有人真的信了吧？？？）