13.敲定第三个改进

在项目例会上，这次是老刘跟大家说这个事儿。因为没有承诺，所以项目计划暂时还按现在的情况定，但是大家都答应，就像前两次改进一样，如果两个开发任务间的等待时间真的缩短了，那么就依此来调整各开发组的工作安排，争取尽早完成项目。

大家大都感谢晓川愿意尝试每周集成。但是有一位领导提醒说，这样会增大程序员的工作量。比如，程序员在按过去的频率不做集成的那周的周五完成了工作。照以前的做法，在下周一提交前，他们需要把上周出的基线合并到他们的任务分支上，然后再构建。上周的基线，内容是截止到上周初大家的提交。而现在，在下周一提交前，他们需要把这周出的基线合并到他们的分支上，然后再构建。这周的基线，内容连截止到这周初大家的提交也包括进去了。也就是说，要合并的内容变多了。

以过去开会的经验，这类问题很容易问到。所以晓川这次在开会前，仔细分析了程序员那边工作量的变化。他的结论是，在统计意义上，程序员的工作量不会变化。不过这需要一些数学知识。简单起见，晓川在会上试着说：“您说得对，由于集成变频繁后，可能会有更多的提交进入到更新的基线，因此程序员向自己任务分支合并的工作量会变大。不过好在另一方面，集成变频繁后，程序员在任务开始时，所基于的基线，也有可能会变得更新了。里外里，就抵消了。”

“里外里就抵消了吗？我仔细想想……”那位领导说。

老刘看看大家，说：“这样吧，你们俩会下再仔细讨论。我的意见是，即便是程序员的工作量增加一点，也值。因为集成现在是我们的瓶颈。以前的两个改进，都让程序员的工作量增加了一点儿。我看效果就挺好。”

晓川想说，“也未必。其实等集成遇到问题再去找程序员，他们更烦。他们还不如保证质量再提交呢。”不过话到嘴边儿，晓川犹豫了一下，觉得有点儿不妥。正在这当儿，老刘已经开始谈下一个话题了。

会后，那位领导又来找晓川。请晓川认真讲解为什么“里外里就抵消了”。领导说，这种分析方法有点儿意思。晓川兴致所致，干脆把集成工程师这边的总的工作量也会降低这个猜测给说了。

“也就是说，你的工作量降低了，而程序员的工作量也没增加？”领导问。

“Yes， Sir.”

“那这部分工作量去哪儿了？跑到谁头上去了？”

“没转移。它就是消失了。”

领导拍拍晓川的肩膀，没说啥，走了。