西行漫记（11）：数字化敏捷

今天做案例分析，分组讨论。一个问题是说，有个大项目第三期工程，时间大概是20个月。由于第二期狂赶进度，拉下很多技术债：糟糕的设计，重复代码，等等。现在要考虑，第三期要不要重新做架构，还是在第二期的基础上接着往上堆。

这种类似的问题在国内的论坛就已经讨论过很多次。主张继续堆的说，时间紧任务重，抓紧完成功能交货收钱是要紧；主张重新架构的说，勿在浮沙筑高台，深挖洞才好广积粮，更何况架构改好了代码重构了，开发效率也会提高，消耗的时间也能赶回来。双方都有理，谁也说服不了谁，架都是这么吵起来的。

今天的讨论，我们得到了一个数学模型。设第三期时间总长T，重新架构需要时间t，重新架构之前开发平均速率V1，重新架构之后平均速率V2。在最坏的情况下，重新架构会要求整个团队停下来等待，于是有：

T / (T-t) < V2 / V1

通俗的解释是，如果速率的提升能把耗费的时间找补回来，那么就值得重新架构。这个道理每个人都明白，但有了这个方程之后我们就可以代入变量去计算。现在已经知道T=20个月，那么如果我们花两个月重新架构，代入计算就是：

20 / (20-2) < V2 / V1
=> V2 / V1 > 10 / 9

也就是说，如果两个月的重新架构能换来超过11%的速率提升，就值得去做。11%的速率提升是什么概念呢？就是每天少用50分钟来奋战、调试、改bug等等。这个提升看起来比较合理，不过还是觉得有些偏高，那么一个月的重新架构换来每天30分钟的提升，我觉得就是比较合理的。同学问我，你怎么就知道这个合理呢？我没有证据，凭感觉猜的。但区别在于，我不是在猜20个月会怎么样，而是在猜1天能不能节约半小时，相比之下这个难度低得多了。

所以，我觉得自己学到两点。第一，像“重新架构”这种事情并不是非黑即白的，整条坐标轴上的任意一点都是可能的选项。第二，直觉很重要，但量化统计和计算可以缩小直觉的责任范围，让直觉更准确。敏捷方法之所以强调快速迭代和反馈，也是为了让客观数据多一些再多一些，让直觉判断准确一些再准确一些。