本文是Joel大侠的新作(对，就是《Joel说软件》的那个Joel) ，以“库存”为类比讨论如何改进软件开发的效益。
想象一下面包作坊：机器中间摆放着一桶桶芝麻、一坨坨面团、一袋袋面粉，还有一箱箱做好但尚未运走的面包。这些都是库存，库存可不是免费的。假如平均每天储备150吨面粉，那要花费多少钞票？库存还有其他成本，面粉可以多放些时日，面包一过24小时就卖不掉了。那为什么需要库存呢？因为“耗尽”也会带来成本。假如订购一批芝麻需要两天时间，一旦芝麻用光，便有两天时间不能做生意了。库存提供了缓冲，防止生产过程的任一环节中断。
可见，库存没有不行，但也不是越多越好。一些现代算法可以计算这一缓冲的最优值。
为何关心起这个来？因为软件生产过程中也有几处主要的“库存”堆积点——在这些节点，事情会堆积起来，浪费大量的时间和金钱。
把你的“想法”想象成原材料。一种想法要经历多个流水环节，如决策、设计、实现、测试、调试、部署等，最终才能作为就绪的特性交付客户。在环节之间，库存会堆积起来。比如，程序员每完成一部分代码便交给测试员检查。在任何时间，总会有一定数量的代码在等待测试，这便是库存。
“库存”代价高昂。有可能长达6~12个月的工作堵在流水线上而没有到达客户手中。而这会导致严重后果，造成的差别就像头前领跑的iPhone和不断追赶的Windows Phone那样。
我们来看看软件开发中最容易堆积库存的三个地方。
特性候选单：产品设计时总会有新想法出现，而实现这些想法的速度永远赶不上把它们想出来的速度。你把它们写下来，它们就成了候选特性。问题在于有90%的候选特性你永远都不会去实现，于是每次你把这些永不实现的特性记录下来，考虑一番，设计一番，甚至集体讨论一番，都是在浪费时间。
Bug数据库：这本来是个好东西，然而在许多公司里，不遗漏任何Bug报告的目标反而导致了“Bug破产”：某天一觉醒来，你发现库中还有3000多个Bug处于开放状态，一些古老的已没有实际意义，还有一些已无法重现，更多的则太小，不值得修正。可是，已有成年累月的工作消磨在这些Bug报告的准备和维护中了。
未部署的特性：这是库存中代价最高的一种。这些特性本来可以为你赚钱，却一直放在货架上没卖出去。马路对面男孩早已在使用另一款产品，里面有完全相同的特性。
本文选自《程序员》杂志2012年08期，未经允许不得转载。如需转载请联系
1065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
