由一个软件库存问题想到的

十月 22, 2012

近期产品线出现这样一个“怪现象”：许多已经完成编码并具备提交给测试组的版本没有测试人员对应。测试部那边给出的策略是：按版本优先级从高到低依次测试。这样一来一些重要版本需要到3个月甚至更长时间之后才能开始测试。可以肯定这种现象是生产环节的一个问题，但用什么理论去解释和分析这个问题呢？我想到了“库存” – 软件库存。

《Joel说软件》的那个Joel曾写过一篇名为《软件库存》的文章，也正是看了那篇文章后，我才第一次了解到软件库存这个概念。库存似乎是传统制造业中的一个概念，但软件开发其实也是广义产品生产的一种，虽然有其特殊性，因此有些产品制造方面的理论是可以应用于软件生产过程中的，软件库存就是其中之一。

传统制造业的库存较为容易理解，零件、原材料、半成品以及未卖出去的最终产品这些都可以理解为库存。而软件生产中的库存都包含哪些内容和环节呢？一旦形成库存，利弊又有哪些呢？

* 未纳入开发的需求/特性

这里所说的需求/特性是经过决策后将来要开发的且能带来价值的，而不是为了大而全而滥芋充数的那种。这类需求/特性可理解为已经采购并存放在库中尚未投入生产的原料库存。这类库存如果变得很大，则很可能说明产品市场场景甚好，但也可能是现有的生产能力出现了不足；如果这块库存过小或没有，则会导致后期开工不足，或者说产品的持续成长前景黯淡，市场对其的需求也不乐观了，组织对此情况应做出迅速反应。

* 已经开发完毕但未经测试的半成品

开发人员开始投入，根据需求/特性疯狂编码、单元测试，生产出未经专业测试的半成品。这些半成品因其中潜在的许多缺陷而不能作为最终商品投放市场，因此无法收回成本并赚取利润。一旦这个环节形成库存，则说明后续质量验证环节的生产能力与软件开发环节的生产能力出现了不匹配，这将导致版本中的问题不能尽快地暴露，使得问题流向其他版本或其他系统中，直到测试开始后才能发现，后续要花费更多的工作量做关联的修正。这也是我所在产品线所遇到的棘手问题，唯一的方法就是提高质量验证环节的生产能力，至于如何提高，因地制宜，这里不表。而较小的库存或这个环节无库存，也会导致后续质量验证环节的开工不足，或衔接出现节奏性的问题。

* 未上市或未卖出的成品

当产品顺利通过质量检测部门的测试后，便可正式发布，变成最终产品- 成品，交付到最终用户那里。但如果这个环节出现库存，问题将变得严重得多。要么是前期市场估计过于乐观，要么是行销人员不给力，要么则是生产过剩，没有做好库存管理等等。如果这个环节库存过小，则最终客户依旧无法及时得到产品，不利于保持客户粘性，客户很可能退而求其次，选择其他厂商的产品了。

以上简要分析既提到了不能忽视库存的存在，也说到了无库存的危害。传统制造行业一直在追求着一种“零库存”的概念，所谓“零库存”，是指物料（包括原材料、半成品和产成品等）在采购、生产、销售、配送等一个或几个经营环节中，不以仓库存储的形式存在，而均是处于周转的状态。它并不是指以仓库储存形式的某种或某些物品的储存数量真正为零，而是通过实施特定的库存控制策略，实现库存量的最小化。在软件生产领域也可借鉴这一概念，在各个环节努力维持合理且适当的库存，这对整个生产过程是大有裨益的。

可以看出“零库存”的一个精要就是及时收回产品的投资，获得利润，保持生产过程的持续有效进行。这让我想到了当今软件过程的演化：从最初的瀑布过程到目前流行的迭代和敏捷等过程，以及流行的持续交付等概念，它们似乎都是在追求“零库存”，追求快速回流价值。或者说库存理论潜在地催生了敏捷、持续交付等概念的迅速发展，并让人们看到其中的裨益所在。