他山之石——来自生产制造业的启示

软件开发业的人常喜欢用生产制造业来比喻软件开发业的事情。由于对生产制造业的不熟悉，而是根据臆断和推测来进行的比喻，常常出现错误的结论。为此本文特地就生产制造业的情况和软件行业的类似于不同进行说明。

1. Working Cell
      提起生产制造业，第一印象往往都是生产线。但是生产线已经是在软件业出现之前的事情，如今的生产制造业早已经不是以前那种生产线的时代了。生产制造业以前是采用生产线的方式进行生产，生产线把生产工序分成各个阶段（熟悉吧？），每个阶段生产的产物都是下个阶段的输入。

     生产制造业目前采用的方法叫做Working Cell。Working Cell是把生产人员分成各个工作小组，每个小组负责原来生产线的所有步骤。这么做的主要目的是为了能够避免由于生产线的某个环节出错而导致整个生产线的等待。如果某个工作小组出错了，不会导致整个生产线的停止。

    软件行业早期也是模拟了生产线的方式，把软件的生产过程分成多个工序：需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试....和生产线方式一样，某个环节出现延误则后续环节需要全部延误。这就是软件生产中总是发生延期的原因。和Working Cell一样，软件生产的时候如果采用迭代方式进行开发，则不会由于某个环节的延误而导致其他环节的延误，这也是为什么敏捷开发可以“保证交付”的原因。

2. Cross functional team
      为了能够实现Working Cell需要技术上的支持。技术工人从单一职责的车工钳工等变成具备多种技能的工人，否则他们无法操作各种机器和进行各种加工工作。这种由多种技能的工人组成的团队叫做Cross functional team。

      在软件开发过程中有一种做法：把软件功能分成各个层。
      一种常见的分法：UI层需要Javascript则由前端工程师完成，DB层由SQL专家完成，业务层由Java工程师完成。于是所有人都不熟悉软件的整体结构。由于每个人都只注重自己的部分，导致整个软件开发的时候各个人只关心自己的代码而失去整体观，乃至于很常见的一种情况是软件开发都完成了，还不知道这个软件是干什么用的。另外一个问题是：软件开发人员经过一个项目之后技能上也没有什么成长。

　　在软件开发过程当中，如果也采用Cross functional team，那么情况就不同了。
　　首先，通过每个人对每种技术都要时间这种情况来说，每个人在每种技能上都会得到提升。不必过于担心由于不够深入了解某种技术而带来的开发效率上的损失，因为从长远利益上来说，技术人员在技术上的提升会对开发效率有大幅度改善。

3.Stop the line

     当生产线出现问题的时候，工人伸手拉一下生产线上的拉绳，生产线就立即停止。因为现在生产线上采用了高度的自动化。产品在不停的生产出来。但是当生产线出现问题的时候，如果不尽快停止生产线，那将会不停的生产不合格产品。当生产线停下来，发生问题的原因被清除以后，生产线就可以继续生产合格的产品了。

     软件开发何尝不是如此呢？软件开发过程中，直到测试为止，软件的质量并不清楚。这就好像在生产线上不停的生产不合格的零件一样，最终将质量把关交给了测试环节。

     软件开发如何建立Stop the line机制呢？测试先行。当出现问题的时候禁止签入代码，直到问题被彻底解决为止。

     关于这个我将在《你不知道的配置管理》中详细讲解。

 4.5S

    5S是工厂管理方式的一个重要环节，它是确保产品质量的一个重要方式。
5S分别是：
    Seiri        （整理）
    Seiton     （整顿）
    Seiso      （清扫）
    Seiketsu （清洁）
    Seitsuke （素质）

    很多软件企业也在实行5S，他们规定员工必须整理桌面，使之符合5S的要求。但是软件开发人员更应该将其代码库进行5S。很多无经验的项目中，软件的配置管理一塌糊涂。代码到处乱放（若干个版本或者分支并存），文档没有归类，常常这里和那里都分不清，代码中到处残留垃圾文件以及垃圾代码，代码的签入签出随意性很强，权限胡乱分配。等等问题很多。尽管桌面很干净，这样的企业也无法说其做到了5S。

　　代码库里应该管什么，应该怎么管，分支、标签应该如何用，什么时间应该签入，怎么才可以签出。关于这个我将在《你不知道的配置管理》中详细讲解。   

最后特意向大家推荐《丰田生产方式》。