估算是软件开发中还没有很好的解决的一个问题,因此争论也很多,水平也参差不齐. 我无法给出更好的估算技术,只是想抛出几个问题和观点

1. 单一职责和问题优先

让我们从几个常见的问题开始:

• 估实际工作量(人天)还是相对大小?
• 如果两个类似的Story有一部分实现代码是可以彼此复用的,那么它们的估算应该是一样的还是不一样的? 还是把复用的那部分拆出来单独估?
• 修复Bug的工作量要不要估算? 要不要算进每个迭代的"速度"里?
• Team一起估还是找一个人来估?
• 做了一段时间后,要不要重估?

这些问题通常会引起争论. 每种观点都有自己合理的一面,这也是争论的前提之一. 但真正导致争论的,是大家都忘了自己估算的目的,忘了谁如何消费这个估算:

• 有时我们为了投标报价
• 有时为了跟客户讨价还价
• 有时为了team自己收集数据发现问题
• 有时需要在两种实现方案之间做取舍
• ...

这么多目的,怎么可能有一种方法满足所有的需求呢? 就算有,那么这种通用的方法在某一个目的上也有可能不如专为这个目的而生的估算方法准确

我的观点是估算方法要与估算目的结合,而估算本身要与目的分开:

• 单一职责原则: 一个数,不要赋予它太多含义. 它应该是明确的,比如就是某对Pair要做多少天,比如就是需要多少行代码,比如就是相对复杂度是什么,而不需要关心你拿这些数去做什么
• 问题决定方案: 而你拿这些数来用的时候,要为不同的目的选择不同的数,不同的方法,做些计算,把整理后的结果呈现给受众,原始的估算要不要暴露出来完全取决于当时的场景.

但这不妨碍人们去追求一种通用的估算方法满足大多数情况下的需求. 这没问题,不过我们也可以从另外一个角度来解决估算问题

2. 消除估算的必要

因为估算始终是不准的,大量的精力花在这上面,不如想办法尽可能绕开它,让真实的进度,成本来说话. 所以一个思路就是消除不必要的估算需求.

敏捷方法? 持续交付?

这是有帮助的,尤其有助于消除对长期估算的准确度的需求. 你依然需要对整个项目的工期有个整体的把握,但不必太精确,当实际进度偏离的时候你能及时发现. 或许你还需要迭代级别的估算,但因为任务比较具体,此时的估算无论何种方法都可以,因为所需的信息都相对明确