例说精益思想

戴尔电脑在应用了精益之后，2001 年库存周转64 次，比最大的竞争对手多50 次，运营成本则比其降低了一半以上。那些成功应用了精益的软件开发项目，在初期就开始向客户交付可以运行的软件，并使其创造价值，之后每个月都能向客户交付一组可运行的完整功能，软件也更加符合用户的真实需求。

    精益思想是从顾客端开始，由此往回推，把任何不能为顾客创造价值的活动定义为浪费，并以消除浪费为主要手段使成本、质量与交付能力达到最优化。精益不仅是技术的革新或流程的改进过程，更重要的是观念与行为的转变，是对传统思维模式的挑战。

一）精益思想的由来

精益思想起源于丰田公司以“低成本、零缺陷、高质量和人性化生产”为特色的丰田生产系统（Toyota Production System, TPS），于二十世纪五十年代开始发展，它是与大量生产相对的一种生产方式。1990年，美国人沃麦克和琼斯合著的《The Machine That Changed the World》发表，书中对丰田生产系统进行了详尽介绍。1996年，沃麦克和琼斯再度联手合著的《Lean Thinking》问世，该书对丰田具体的生产实践和观点进行升华，并首次给出了Lean Thinking的提法。从上个世纪70、80年代开始，陆续有企业开始实施TPS，到目前世界500强企业当中，100%的制造型企业和50%的服务型企业都不同程度地应用了精益。

精益是为了应对激烈的国际竞争和多变的市场环境而发展起来的，是不断从现有生产中发现和消除浪费的过程，它改变了传统的强调产能的生产方式，而去关注最终用户的价值，努力提供满意的消费。精益思想具有普适性，它在营销、企业管理乃至社会生活的方方面面都为人们提供了新的思考方式。

说到精益，就不能不提敏捷，两者是一致的，它们起源于不同的领域，后来也渗入到对方的领域当中，产生了“精益软件开发”和“敏捷制造”等研究领域。

二）量产时代的后遗症

大量生产方式在很多行业中虽说都已经渐渐退出历史舞台，但它在人们思想中留下的那些“看似合理但实则不然”的思维定势却始终挥之不去。这些后遗症阻碍着我们发现精益的价值，这里列出来供大家思考。

• 批量生产能降低成本

这似乎是显而易见的道理，而且已被数百年的工业历史不断证实了的。针对纯粹的生产环节来说，这个结论也许是正确的，但如果从客户产生需求到满足客户需求这一端到端的过程来看，将持有和管理库存的成本、产品过期废弃的风险、用户需求变化和延长产品交付期的影响考虑进去，这一结论就未必正确了。批量生产方式背后有一个假设，那就是需求是批量和相对稳定的，这是一个危险的假设，更危险的是建立在该假设上的各种企业策略，这为企业造成了很高的系统性风险，很容易让一家市场表现良好的企业在市场的震荡面前失去方向。

• 喜欢大和集中

大而集中往往被认为能够集中优势，提高效率。在工业时代，很多标志性的事件都与发明和应用大型设备有关，一些跨国企业在第三世界国家建立大型工厂实现了降低成本和扩张规模，这其中有什么问题吗？当今市场需求多样且易变，如果考虑到需要投入额外配备和生产准备工作，换产调整迟缓，为保护投资而抵制新需求，为充分利用设备产生多余产能以及由此带来的一系列浪费等等，盲目应用大型设备很可能导致相反的结果。远离消费市场的大型工厂增加了存储、运输和管理的成本，上市时间的延迟和迟钝的市场反应降低了产品的竞争力。在各个领域和行业中，应用大而集中的思想实现快速发展都有一定的适用时期，过后其忽略全局的弊病便会暴露出来。小而灵活所带来的弹性也许在此时会更有价值。

• 以设备和部门为中心

大量生产时代，工厂可以围绕设备组织生产，也可以把不同类型的设备安排到不同的部门中，并期望部门能够优化自己的作业，最大限度地利用设备。当今市场的变化无法容忍大量的半成品在部门间无休止地被存储和运输，部门之间合作效率也成为瓶颈，即使在设备和部门被充分优化的情况下企业也很难满足客户的需求。TPS则采用不同的方式组织设备和工作，它将与某种产品相关的所有设备和人员组织成一个个独立的工作单元，一件一件或小批量地生产完整产品，并在需要的时候及时换产，而不是大批量地加工一种半成品。目前很多软件公司也会根据技能划分员工，形成以职能为中心的各个部门，同时期望各部门能发挥其集中的资源优势，并通过将工作在部门间的传递来一次性地实现客户价值。敏捷企业则将与某一项目相关的全部角色，甚至包括最终用户，组织在一起，一项一项或小批量地实现完整的功能，并及时处理反馈而来的新需求，而不是大批量地一次性分析或编码一组可能的需求。

归根结底，上面这些后遗症都表现了对最终端到端的客户价值的忽视，是局部优化。批量生产未必降低成本，弹性对当代企业更具价值；大和集中不是美，小而灵活才更重要；优化设备和部门的行为未必产生好的结果，着眼整体才是真正关注最终价值。

三）浪费

精益就是发现和消除浪费的技术，对浪费的认识直接反映了精益的价值观。浪费是指从最终用户的角度看，增加了成本但不能增加产品或服务的价值的一切事物。浪费有两种，一种是纯粹的浪费，它对企业和最终用户都没有带来什么好处，比如说运输和等待，这类浪费应彻底消除；另一种是必要的浪费，它虽然没有为最终用户创造价值，但却是我们所知的使企业避免发生问题的最佳工作方式，比如说检测和管理，封闭系统内“熵增”^[1]的自然趋势使得这类浪费不可能被消除。

如果说最终用户需要的是一瓶洗发露，运输和等待的过程增加了这瓶洗发露的成本但并没有增加这瓶洗发露的价值，而检测部门的工作防止次品流入市场，增加了成本但严格来说并没有增加洗发露的价值，管理也如此。

精益强调每一个岗位、工作或流程都以“浪费”的标准来衡量自己的价值，这与传统企业以部门为中心形成的价值观有一定冲突。

四）精益五原则

精益思想有五个原则，它们更像是五个步骤，通过不断循环的过程将最终用户价值带入系统中，并将系统中的浪费一层层逼出来，消灭之。这五个原则分别是：

1. 价值

明确客户所期望产品或服务应提供的价值。以实现此价值为目的审视整个过程中的所有活动，同时帮助识别其中的浪费。

1. 价值流

针对一件产品、一项功能或服务，按时间顺序识别出为实现其价值而进行的所有活动，并确定出其中哪些是有价值的，哪些是浪费。

1. 流动

消除价值流中的浪费，让有价值的活动一个接一个地流动起来。

1. 拉动

确定价值流何时开始流动，因何流动。价值流应由用户的实际需求拉动。

1. 尽善尽美

价值流中浪费的步骤不可能通过一次改善彻底消除，浪费是被不断发现和具体化的。尽善尽美追求在实现客户价值过程中引入最少的浪费，也即通过更精简的步骤、更短的时间和更少的必需信息来实现客户价值。当实现了一个阶段的目标后，根据当前的价值流状况设定一个新的目标，重新开始流动和拉动的过程，发现和消除更多的浪费，不断地持续这一改进过程。

下面以一个简化了的软件项目为例，该项目本来是一个以瀑布方式开发的计划一年的项目，我们将应用精益的五个原则（步骤）虚拟地不断重复开发这一项目，目的是体验一下反复应用这五个步骤进行持续改进的大致过程。

价值，我们考虑根据名称搜索产品这一功能，用户通过这一功能能快速定位到其所关注的产品。

价值流，按时间顺序列出该功能的所有活动（见图）：

<!--[if !vml]--><!--[endif]-->

0.5天需求分析à2个月的等待（瀑布流程中还要同时分析其它功能）à0.5天设计à2个月的排队和等待à2天的编码à4个月的排队和等待à2天的测试à3个月的排队和等待à1天的集成工作à1个月的排队和等待à上线。其中排队和等待都是浪费，一年后，所有积累的工作终于可以被检验，并得到用户的反馈，此时我们也可以判断所有相关工作是否都已经完成。

流动，不难看出其中有价值的工作只有6天，剩下近一年的时间都是排队和等待，如何消除这些浪费，让有价值的工作一个接一个流动起来呢？如果有机会让项目重新来过，我们可能会想先安排这6天来集中做登录功能，这样就没有浪费了，但在这样一个组织里面，这样做相当于给项目添乱。我们不如先设定一个目标，将浪费由近一年减少到4个月。

重新开始项目后，很快你会发现，现有的流程无法保证4个月后的交付，很多问题暴露出来了。其中文档撰写繁冗耗时、部门之间沟通反馈周期长是阻碍价值顺畅流动的最大问题，造成了大量的排队和等待。这些文档中的大部分都是耗费成本却对用户价值（快速定位到用户所关注的产品）没有贡献的，是浪费，部门沟通过程中的等待更是不折不扣的浪费。这时我们可以尝试重新安排组织结构，将与项目相关的所有人从原来的市场、开发和测试等部门调到针对该项目组建的项目组中。将为同一目标而联系密切的人安排到一起，促进了及时的沟通，减少了撰写部分文档的必要性，使4个月一次的交付变得更加可行。

拉动，当交付周期缩短了以后，就可以比较从容地引入拉动机制，在需求真正变得清晰时才及时拉动针对这一需求的各项工作，而不是强调通过在项目前期一次性地通过高级的需求获取技术将客户头脑中的想法引导出来，并将这些需求引入复杂的开发计划中。“清晰的新需求à验收测试à单元测试à编码实现”的过程也是一种由需求拉动的过程。

尽善尽美，上面价值流的目标是将1年的浪费减少到4个月的水平，我们可以尝试再将目标设为2个月，重新开始价值流分析、流动和拉动的过程。你很快会发现，交付前测试阶段经常延期，质量难以保证，类似的Bug重复出现。经过分析得知，人工测试过程中的大量重复，测试产能与开发产能的不平衡，开发完成到测试之间的等待，这些都是这一时期急需消除的浪费。可以通过引入在持续集成框架下的自动化验收测试来消除重复的人工测试浪费，以实现测试产能与开发产能的平衡，在交付期间内引入几次迭代，缩小团队同时面对的需求数量，这在很大程度上进一步消除了开发与测试之间等待的浪费。这样一来，针对某一功能的测试紧跟开发过程，价值流迅速流动起来，而不是等到快要交付之前才集中测试。

再把交付周期减少到1个月呢？这样会让更多的浪费现出原形，你可能发现你需要用上所有敏捷的实践和原则才能将它们一一消除。可见，这一过程就是不断发现问题和浪费并消除它们的过程。

在价值流这一环节之所以以一件产品、一项功能或服务为出发点是因为客户的需求本是伴随着反馈和认识的不断深入而持续流出的。这样做价值流分析能适应需求的产生和变化过程，所以在上述例子中，我们为适应需求的这个特点而采用了持续的软件交付方式。

五）识别浪费

在参观Yazaki天津工厂（Toyota的供应商，应用丰田生产方式多年）的过程中，负责质量改进的工作人员对我们说，培养“发现浪费的眼光”是他们的重要技能。识别浪费是持续改善的重要一环。从现象上观察，浪费常常伴随着相似的表现，这些表现则可以帮助我们识别浪费。浪费的表现如下：

• 库存

生产企业为避免供应不足建立库存，却同时增加了成本，减弱了企业对市场的敏感性，隐藏了企业内部各种各样的问题。在市场稍有风吹草动的时候，库存商品就变为滞销品，同时还造成了供应不足的尴尬局面。广义上讲，库存还包括那些不可见的、还没有产生结果就已经停滞了的工作，它们表明价值流已经发生了停滞。库存在我们的生活和工作中可谓无处不在，比如书架中不知道何时才会被翻阅的书、Jira上数不清的任务还有目前的高等教育体制等等。

• 批量和排队

批量和排队的同时会有等待，会减弱价值流的流动性。有的银行规定在每月的固定几天内处理企业发放工资，此时批量和排队就产生了，由此引发的排队现象以及企业和银行间周期性的工作负荷不均衡现象会带来浪费。在瀑布式开发中，工作在部门间以批量和排队的方式被传递，针对某一功能的工作在流向下一部门前要等很久。这种现象配合文档的暗示作用和部门内考核标准的指导作用，会给上游部门造成一种工作已经完成的假象，最终导致下游部门得不到上游部门有力的支持，下游部门的疑惑或新发现的知识也找不到合适的人反馈，只能自己做主了。

• 不均衡和不平衡

不均衡常常伴随着波动、批量和排队的现象，会带来资源的闲置和过度利用交替出现的情况。年末电器促销是一种不均衡的情况，为准备促销，企业提前几个月加班生产，资源过度利用，管理成本和次品率增加，库存成本增加。促销结束后，需求减少，库存成了滞销品，销售压力增加，生产进入淡季，生产资源未能充分利用。这种由行业造成的销售周期并没有反应用户真实需求的变化（用户的需求是相对稳定的，并不会在年末激增），从企业角度看，这并不利于其利益的最大化和服务水平的提高，从用户角度看，他们滞后或提前了消费时间，这可能导致购买了不合适的、甚至是多余的产品。

在瀑布式软件开发中，整个过程被分为需求分析和设计等不同阶段，各部分工作被集中处理，而不是相对均衡地分布在整个过程中。真实需求的发现本是持续和渐进的，实现需求的各项活动也可以均衡分布在整个开发阶段。

• 复杂和繁琐

如果事情表现出异常复杂和繁琐的一面，很可能是出了什么问题。繁冗的文档和流程背后往往有保护局部和损害整体的影子。

生产一件产品过程中重复的加工步骤、重复的动作等等都增加了加工过程的复杂性，是浪费。但由于是生产有形的产品，这些浪费比较容易通过肉眼观察出来。软件则不同，软件的开发过程和运行过程都不太容易观察，复杂和繁琐常常表现为难于应付的棘手问题，还有系统间复杂的交互过程、程序中重复的代码逻辑等等。有时复杂性可能源于试图通过软件对异常复杂的业务逻辑进行自动化，这些业务逻辑中的复杂性对客户很可能是没有价值甚至是有反作用的，这种情况并不鲜见。

• 僵化

僵化表现为对需求变化反应迟钝。这是一种障碍，它使企业无法满足客户的真实需求，这种障碍囤积着浪费，但其是不需要发生额外成本就能克服的。瀑布式开发过程中，等待需求变化的常常是繁琐的需求变更流程，繁琐到了连客户自己都不愿提出发现的需求。这种对所发现的更有价值知识的僵化态度不断提醒着我们，它背后有浪费。它使得软件与实际需求拉开了距离，反过来还鼓励客户在一开始绞尽脑汁将需要和不需要的东西一并提出需求来，为客户自己和项目组埋下浪费的种子。

从上面的各种表现中我们不难看出量产后遗症的影子。

总之，未完成的工作都涉嫌浪费，所谓“未完成的工作”就是指已经开始了的、但尚未交付给客户的工作，更进一步讲，是所有尚未给客户创造价值的工作。上面所有的现象背后都是一种阻碍工作迅速完成（阻碍价值迅速流动）的结构或力量。有的表现为工作的停滞，有的表现为加入一些多余的内容，拖延了工作的进展。

考虑软件开发过程，狭义地讲，未完成的工作就是还没有Check In的代码。广义上讲，所有尚未给客户创造价值的工作，这包括在开发功能牵涉到的分析、设计、编码和测试等工作，包括某一严重Bug所对应功能的全部分析、设计、编码和测试等工作，还有为维护Jira上任务列表所进行了的各项工作等等。它们都是未完成的工作，都是潜在的浪费，认识这一点的价值在于鼓励我们积极面对市场的变化，采用能够让价值迅速流动起来的的交付方式，并努力清除妨碍工作迅速完成的一切障碍。

敏捷团队中的成员，强烈希望迅速看到自己的工作成果，看到下一环节乃至最终用户的反馈。团队中每一个角色的每一项工作都被最终用户的一个明确需求牵引着，为了不让这个需求目标被淡忘，避免由于目标含糊不清而产生的浪费，敏捷团队通过短期迭代和频繁交付努力压缩着未完成的工作。

精益或敏捷就是将未完成的工作（浪费）减少到最小的观念和行为。

精益的5个原则（步骤）给了我们一个清晰的、循序渐进的思路来压缩未完成的工作。具体到软件开发领域，众多敏捷实践则组成了一个实用的工具箱，帮助解决在履行精益原则的过程中暴露出来的具体问题。

六）消除浪费

浪费往往是通过价值流的流动和拉动过程使其浮出水面的，各行各业都有不同的办法来消除浪费，有趣的是，不同行业采用的方法出奇地相似。TPS中有“单件流生产方式”，敏捷有“迭代式开发”；TPS中有“看板”，敏捷中有“故事卡”；TPS中有“人性的自动化”，敏捷中有“持续集成”；TPS和敏捷都强调全能小团队……

前面提到浪费划分为“纯粹的浪费”和“必要的浪费”。前者要彻底消除。后者要认真对待、尽量减少。在软件开发中，测试、集成、重构和管理等都属于这类浪费。下面列出了四个启发模式，帮助我们处理“必要的浪费”：

• 积极对待，配备少而精的人

敏捷团队非常重视上面提到的几种浪费，团队中的管理人员和测试人员要比传统团队数量少而且要求更高。

• 由个人的任务变为团队的任务

赋予团队成员清晰简单的目标，实现自我管理。团队中几乎所有人都参与到设计、测试和部分集成的工作。代码所有权也被共享。

• 将工作自动化，区分人和机器的职责

人工测试和自动化测试相区分，应用持续集成。

• 工作提前做，频繁做

测试驱动开发，在早期开始频繁的单元测试、重构和集成。早期就赋予团队成员目标，并通过各种方式确保他们及时了解项目状态。

消除浪费的方法是仁者见仁，智者见智。对于软件开发领域，敏捷已经提供了一整套对付浪费的实践。但要注意的是，像在精益五原则一节中的例子提到的那样，敏捷开发的众多实践是消除浪费的工具，而不是让一个开发团队变得更敏捷的全部。一个敏捷的开发团队未必要一一地执行这些实践，团队也可以发明适合自己的新实践。有些实践非常基础，需要一开始就采用，而有些实践只需要在它能够对目前消除浪费的目标有贡献时才必要。

改变组织交付软件的方式（迭代式地频繁交付），改进管理架构以适应这种交付方式，同时培养精益或敏捷的观念和行为习惯是一个软件开发组织步向精益或敏捷的三个重要方面。

不知看到这里，读者是否对精益有了一些感性的认识。归根结底，精益的目标是通过坚决消除浪费，努力在尽可能短的时间内把价值奉献给客户。敏捷开发和丰田生产方式是同一层次的概念，都是针对某一领域的一组价值观、原则和实践，精益则是对它们的总结和升华。精益的背后是“系统思考” ^[2]这一看问题的方式，它强调从整体、长期、动态和连续的角度认识事物和解决问题，并努力发现传统解决方案背后隐藏的假设，而不是直觉地、习惯性地着眼于对问题局部、短期、静态和片断的认识。

 

^[1] 熵来源于热力学的概念，可理解为对系统混乱和无序程度的度量。越无序，熵值越大，智慧、知识和软件都是高度有序的，是负熵的。封闭系统任由其自己发展，其熵值会随时间而增加。“必要的浪费”通过引入负熵抑制熵增的趋势，这些负熵并未直接流入产品或服务。只有在理想的、没有任何干扰的环境中“必要的浪费”才可能被彻底消除。

^[2] 系统思考在《第五项修炼 – 学习型组织的艺术与务实》一书中有详尽的描述。