别瞧不起制造业，软件其实一直在向制造业学习

wxsunhao

别瞧不起制造业，软件其实一直在向制造业学习

原创： 宋荆汉 质量与创新 今天

现在科技界的热点几乎都被“软件“给占据了，而且软件工程方法论在研发管理领域非常的活跃，敏捷过后，精益仿佛又成为新的热点。“软件定义网络，软件定义芯片，软件定义制造，软件定义世界“，在这个软件被提高到如此之高层面的时代，学软件的同学难免生出天生的优越感与自豪感。在一次软件研发方法大会上，主持人问了一个问题：请问多少是来自于传统行业的？。我当时也愣了一下，作为IC设计企业，是否当属传统行业呢？想想好像也算哦，制造业的嘛！但是，软件工程的很多方法与实践，如果我们寻根朔源其实很多就是来自与传统的制造行业，甚至是一线的生产管理现场。

        《人月神话》一书中预言：“没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。“该书出版至今已经远超十年了，但至今看来这个结论依然 成立。反观制造业，至流水线与专业分工模式出现后，生产率得以成数量级的进步，世界人民的物质生活得以极大的满足，但时至今日也生产率提升也很是艰难了更别提数量级的进步了。远的瀑布模型就来自制造业中，分工与流水线工业生产的思想。近段时间的敏捷与精益又何尝不是？以下我们可以做个类比

1. 敏捷团队中的全功能团队与生产的Working Cell

      提起生产制造业，第一印象往往都是流水生产线，生产线把生产工序分成各个阶段，每个阶段生产的产物都是下个阶段的输入。但现在管理先进的制造商早已不是如此了。

     生产制造业目前采用的方法叫做Working Cell。单元生产是精益生产方式中最主要的组成部分，CELL由生产流程中按工序排列的人力、设备以及工作站等组成﹐所有这些都是为了完成流程或流程的一段完整交付所要求的。譬如：如果某个特殊的产品需要在钻孔和最终完成前进行切割，CELL化就包含着完成按照此顺序安排的设备。Working Cell是把生产人员分成各个工作小组，每个小组负责原来生产线的所有步骤。这么做的主要目的是为了能够避免由于生产线的某个环节出错而导致整个生产线的等待。如果某个工作小组出错了，不会导致整个生产线的停止。

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

2. 全栈工程师与Cross functional team
( i2 D* k- I7 }: s      为了能够做到单元生产，工人从单一职责的车工钳工等变成具备多种技能的工人，否则他们无法操作各种机器和进行各种加工工作。这种由多种技能的工人组成的团队叫做Cross functional team。

      在软件开发过程中，会按照功能分层的方式来进行开发。比如，IC的SDK平台开发

       BSP软件，由一部分专业组人员负责；

       上层OS android系统定制，由另一组人负责；

       中间件，再由一组人负责；

      定制 APP应用，再由一组人负责；

    于是所有人都不熟悉软件的整体结构。由于每个人都只注重自己的部分，导致整个软件开发的时候各个人只关心自己的代码而失去整体观，乃至于很常见的一种情况是软件开发都完成了，还不知道这个软件是干什么用的。还有，当系统出现稳定性问题时，定位就及其复杂，到底是哪个环节出的问题，需要纠集一大批各部门的高手来分析定位，花好长时间才能搞定。当然另外还带来一个附加问题：软件开发人员经过一段时间后技能上也没有什么成长，由于组织的划分想学习整个系统的技能又没有机会。有人会说，专业要做精深才能保证质量、速度，但具体做研发同事其实知道，做到一定程度其实都成体力活了，哪里还能找到成就感啊和激情啊。还有一个问题，团队中如果某个技能人员出状况，其他人根本没法顶替。

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

3.测试驱动开发与Andon

     Andon安灯系统来源于丰田-生产方式，基于其“建立立即暂停制度以解决问题，从一开始就重视品质管理的文化”的生产原则。

0 m! D3 s# F4 t% s

丰田公司特别制定下面两条质量预防原则:

一是发现质量缺陷和异常情况必须立刻停止生产;

二是必须立刻查清产生质量缺陷和异常情况的原因，并彻底纠正，使之不再发生。

而安灯系统正式这一预防原则的实践。

　1．当生产工序的人员发现质量有关的问题，他就拉下吊绳或用遥控器，激活Andon系统，该信息通过操作工位信号灯、Andon看板、广播将信息发布出去，提醒所有人注意。

　　2．班组长响应质量要求，与操作工一同确定问题。如果班组长可以解决问题，重新拉下吊绳，系统恢复正常。如果确定的问题必须向其它部门求助解决，则班组长通过设置在区域集中呼叫台进行呼叫，将信息类型、呼叫内容再次通过Andon看板、广播将信息发布出去。

  本质就是要求质量在过程中构建，而不是等到最后环节才去检验。其实 软件开发何尝不是如此呢？采用瀑布模式软件开发过程中，直到测试环节，软件的质量都无法可视化。这就好像在生产线上不停的生产不合格的零件一样，最终将质量把关交给了测试环节。

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

        其他，目前比较热门的敏捷精益开发，其精益思想更是直接来源于生产制造业的实践与思想哲学。丰田汽车公司2004年财政第一季度的净利润是美国通用和福特的总和。积蓄了40多年的日本汽车公司终于用“精益生产方式”打败了底特律，打败了底特律引以为豪的大批量流水线生产方式。而上面提到的实践，都是在丰田公司得以坚决贯彻与落实的生产一线实践。其实践起源甚至可以追溯到前苏联50年代中期由斯·帕·米特洛凡诺夫提出的成组技术（Group Technology），欧美早在20世纪50年代末期就开始研究，60年代开始应用推行。日本上世纪80年代开始这方面的研究，但当时实际生产中运用的不多，直至日本早川先生创造性地在SONY大范围的成功运用，局面才得以改观。

        从历史沿革来看，无论是软件工程开始的瀑布模型，到后来的迭代开发模型，到近段时间的敏捷精益，无非都是学习制造业的成果。因此，软件的同学我们没理由瞧不起制造业哦。