文/路宁
精益对敏捷软件开发起着补充作用：
（1）精益理论体系完备、不落俗套、而且并不复杂，它从另一个独特的视角解释了敏捷实践和原则，让人耳目一新，也适合指导各项工作。
（2）丰田生产方式和精益中的很多工具和概念可以很好地应用到软件开发领域，补充敏捷的工具集。比如看板，其“控制在制品数量”和“拉动”的特性就非常值得敏捷的“故事墙”借鉴，可以有效地加强故事墙暴露问题的能力。价值流分析方法对于发现软件开发过程中的浪费和改进点很有帮助。PDCA（Plan-Do-Check-Act）改进循环和A3报告对于开展一个个的改进活动是个不错的指导思路。“内建质量”、“停止生产线”的做法和敏捷的测试驱动和持续集成不谋而合。“现场管理”和“自组织多功能团队”也正是敏捷推荐的做法。如此种种，举不胜举。
（3）精益被应用的范围要广的多，尤其是其在部门、组织及产业链上推广的思路有助于敏捷向部门、组织及合作伙伴间推广时借鉴。
采用精益是因为Scrum等方法已经被说得过多，作为一种新的管理风尚而吸引眼球？
精益确有此用法，尤其是当它被简单理解为一组抽象了N层的真理型原则之后。既然是“真理”，自己的观点怎么都能和它沾点儿边，不需要改变什么就可以标榜时尚了，这是“浮躁”的表现。敏捷也遭遇了类似的命运，被拿来代指其他观点，便于当事人充满信心地推行自己的想法，尽管这些想法与敏捷可能相悖。
精益有自己独立的意义，它从另一个角度更加系统地解释了敏捷各项实践背后的原因；一些丰田生产方式的实践甚至可以直接引入来指导软件开发，补充和扩展敏捷实践；为敏捷的深度推广提示了思路和路线图。
精益从丰田生产方式而来，后来经过精益制造、精益企业等几层升华，又在其他行业应用中演变。再遇到精益的人是否能够接触到本质内容已经很难说了，为了避免精益仅被利用来玩一把时尚，研究学习丰田生产方式是必须的。
实施精益即是一系列工具，就要实行看板拉动吗？
从客户角度出发进行拉动，运用看板来实现拉动，这一流程设计思路在很多行业均被证实卓有成效，是实施精益的重要步骤之一。但即使如此，把实施精益看做应用一系列工具是片面甚至危险的。精益意味着交付方式的变革，很多公司在尝试精益的时候都没有准备好按需调整自己的组织架构、管理方法和行为习惯，甚至认为这些是不可动摇的，搞不清它们和交付方式之间谁为主导，谁为支持。这也是早期大部分的精益变革被认为“不适合我们”、“应用场景局限”、“太过理想”，并以失败告终的重要原因。实施精益是项系统工程，而且最终会反映到个体和团队能力与观念的改变上来，工具始终只是工具。
看板开发不就是敏捷中的故事墙吗？
看板和故事墙总得来说是服务一个目的。但看板无论从形式和用法上，或是承载的功能和其背后拉动生产的思想上，都让敏捷实践者眼前一亮，灵感迸发，大刀阔斧地把故事墙改进一番，加上其他方面的一些改进，称作看板开发。总的来说有几点改进：
（1）给故事附加了一些元信息，把以前项目经理关心的一些额外信息也可视化出来。
（2）强调限制“在制品数量”，也就是各个“泳道”中故事的数量，让瓶颈更容易暴露出来。
（3）引入拉动概念，只有一个卡（故事）被验收（或集成了）才可以依次移动前面的卡，让一个卡在流动过程中的“阻塞现象”成为要解决的大问题。
（4）没有清晰的迭代概念了，以前的“迭代启动会议”按需召开，会议的时间也大大压缩。由围绕“一组故事”进行的迭代开发变为围绕“一个个故事”的持续流开发。这消灭了迭代开发中的各种“不均衡”现象，比如前松后紧，迭代快结束时为了完成更多故事，项目经理积极“干预”，确保开发人员没做故事之外的内容，重要的Bug能被修正，甚至还会执行不同的标准。
（5）大小尽量一致的故事，简化了评估的工作。
精益是否更适合流水线作业？
精益生产或许总量很大，但却是小批量甚至是单件交付的，这与以集中交付为特点的大规模生产（大批量生产）是相对的，因此总产量大小不是关键。精益的交付方式使得小批量频繁订货被鼓励，每次订货都可以根据市场调整需求，增加了客户和自己应对市场需求变化的能力。敏捷软件开发同样也是通过快速增量交付来适应变化的。
流水线只是一种生产组织形式，被各类生产模式广泛采用。精益生产倾向于使用小型的通用设备，将某产品相关的各种设备排进一个生产单元（流水线），并培养能够操作多种设备的各类人员（含检测人员）组成全能小团队，同时授权团队对生产过程做持续改进。大规模生产倾向于用大型专用设备，按设备的类型组织部门，工人仅熟悉一种设备，一个部门缺乏从全局出发进行改进的环境，往往做些局部优化，此时整个系统依赖于管理层的精心设计来确保效率。上面的对比关系在敏捷/精益软件开发与瀑布式开发之前也生动地存在着。
精益方法不喜欢采用计算机和IT解决吗？
与其说是不喜欢采用计算机和IT解决，不如说是扎根现场，勇于采用更实用的方法，尽管有时候看起来有点儿土。
一些工厂使用资源计划管理软件系统，根据订单生成各个生产单位的资源安排和生产计划，一旦需求调整、资源变化或库存与电脑记录不符，这种“推动”的系统便难以应付，生产也容易陷入混乱。精益将客户需求转化为一组组交付信号，也就是组装信号，进而拉动上游生产环节甚至供应商的生产。看板是这一拉动系统的支持工具，尽管算不上什么高科技，但却简单实用，而且有可视化、便携、容易暴露问题等优点。因此重点是实用与否，而非是否体面。
精益来源于制造业，对于知识密集型的软件业能有帮助吗？
是否有帮助首先取决于是否真正了解。类似地，精益在被引入服务业、零售业、银行、医疗卫生以及教育产业时也被无数次地质疑过。我认为，之所以会有这样的疑问，一个重要原因在于做了不合适的类比，认为汽车生产是机械的重复过程，怎能被软件项目借鉴，自己是“知识工作者”，和那些工人有什么可学的，等等。希望下表能帮助澄清误解：
规模生产方式下的工人技能单一，精益生产方式下的工人能操作多类设备，能按需停止生产线，成为团队一员发起改进活动。采用合适的类比，丰田生产方式的实践和原则对软件开发领域就显得有启发性和实际意义，很多做法在敏捷中也有对应的实践。
采用精益的目的只是为了降低成本，消除浪费吗？
消除浪费、降低成本可以说是各类改进方法的主要目的之一。但对精益来说，它们并不是首要的出发点。精益通过变革交付方式来适应市场需求，排在第一位的目标是缩短交付周期，手段是消除浪费，成本的降低甚至被认为是必然的副产品。缩短交付周期是改进的出发点和首要考量标准，这是精益有别于其他方法的独到之处。
对那些对精益感兴趣的读者有什么建议？
（1）融入到国际和国内社区中，探讨、学习和跟进精益和看板开发方面最新的进展。
（2）从丰田生产方式TPS着手，扎扎实实地研究精益在制造业中原汁原味的做法，学习他们如何做“改进”，不要满足于别人总结出来的抽象原则。相信学习的过程会给你深刻的启发，即使是敏捷的成熟实践，比起TPS的一些做法来讲也只能算是“保守派”。
（3）在实施敏捷的过程中不要习惯性地降低标准，觉得这个不适合，那个做不了。敏捷做不好，精益也没法做好。不少公司是在瀑布思维下做敏捷，原则和实践忽略的忽略，裁剪的裁剪，更没想过去挑战现有组织架构和管理思维，长期停留在初级阶段，自我感觉良好，难以实现突破。
相关文章
