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

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

为什么要做时间估算

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

项目优先级和项目范围

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

项目依赖识别

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

项目质量管理

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

团队士气

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

项目时间估算的难点

未知的东西多

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

技术债堆积

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

需求变更、需求不清

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

外部环境变化

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

为什么要估计行数

并不会更不准确

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

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

换算方便

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

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

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

更清晰的依赖

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

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

可控的质量

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

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

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

已知的最坏情况

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

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

结论

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

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

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

展示评论