路宁谈精益思想——2008北京Open Party摘录

上周六（1月19日），InfoQ中文站与ThoughtWorks、BJUG、AgileChina、BPUG等社区共同举办了一场Open Party活动，场地设在ThoughtWorks北京办公室，大约四十多人参加了本次聚会。来自ThoughtWorks的咨询师路宁为参会者献上了一 场精彩演讲：Lean Thinking With Examples，详细分析了实施精益或者敏捷过程中最大的阻力，以及如何识别和消除浪费。

活动从一个简单的Stand-up meeting（站立会议）开始，之后是半个多小时的沟通交流和所有主题的票选。当天的主题包括了开源社区发展、GPE、Mingle和Erlang等众 多精彩内容。在进行分会场会议时还发生了一个有趣的小插曲，Matrix的clever pig（刘丹）和Peter Cheng（程勇）的“开源社区发展”吸引了大多数人的注意，从而导致其他两个同时进行的主题因为人数过少被迫暂时中止。

之后，路宁在分会场进行了题为“Lean Thinking With Examples”的演讲（ 演讲PDF文件下载）。他从丰田生产系统（Toyota Production System）和精益（Lean）的历史谈起，分析了在企业或公司实施精益或敏捷的最大阻力——大规模生产时代在人们思想中形成的那些“看似合理但实则不 然”的思维定势（量产时代后遗症）。他还谈到了丰田如何扭转思维，大刀阔斧地探索自己独特的生产体系，最终在国际竞争中脱颖而出的故事。他说道：

Lean就是识别和消除浪费（不产生附加价值的活动）的技术。

随后，他举例说明了如何利用精益的5个原则（ 注：见新闻底部附注）来识别和消除浪费，同时还列出了几个常常与浪费结对出现的典型现象：

• 库存——库存在避免供应不足的同时增加了成本，减弱了企业对市场的敏感性，隐藏了企业中各式各样的问题，在市场稍有风吹草动的时候就可能使库存商 品变为滞销品，同时还造成了供应不足的尴尬局面。库存在我们的生活和工作中可谓无处不在，想想自家的书架、冰箱、工作中还没有结果但已经停滞的工作、当 然，还包括“高等教育”。
• 批量和排队（等待）——有的银行规定在每月的固定几天内处理企业发放工资，此时批量和排队就产生了，由此引发的等待和不均衡的工作负荷会带来浪费。还有城市内那些被过分依赖的交通枢纽，“等待”是司机开车到这里后常常要体验的事情。
• 不均衡（周期性）——比如销售淡季与旺季，五一、十一黄金周。
• 复杂和繁琐——如果事情比你想象的要复杂和繁琐的多，相信自己，这里很可能有浪费产生了，繁冗的文档和流程就是一个不错的例子。
• 强调符合原则和规定——并不是所有的规定和原则的背后都有像样的理由，即使有理由，也未必都是对最终用户有价值的。

路宁着重强调说：

未完成的工作都涉嫌浪费。精益或敏捷就是将未完成的工作（浪费）减少到最小的技术。

按照这个说法，就连所有正在编写的代码都属于浪费。乍一听真的匪夷所思，如果不编写代码，我们拿什么东西给客户交付？价值又从何而来？这又怎么能说成浪费呢？

实 际上，还没有为用户创造价值的代码，就连用户自己也不能保证这就是他需要的。上面那句话并不是鼓励大家停止编码，而是督促我们尽快把手头的工作变为可运行 的软件，并在生产环境中运行，用户会反馈给我们结果和进一步的实际需求，此时我们才知道那个工作到底完成了没有。未完成的工作越多，自己和客户的风险就越 大，可能的浪费就越多，相反，未完成的工作越少，应对变化的能力就越强，那些只有少数人能够掌握的“需求获取技术”此时也变得没那个必要了。

假设我们在这一点上统一了认识，接下来的任务该就是寻找解决方案，减少浪费。那该怎样做呢？精益的5个原则给了我们一个清晰的、循序渐进的思路；具体到软件开发领域，众多敏捷实践则组成了一个实用的工具箱，帮助解决在履行精益原则的过程中被暴露出来的一个个具体问题。

要 减少写完代码到代码被成功测试和集成的时间，就要小步前进，频繁check-in和持续集成（Continuous Integration）。要减少完成功能到功能为客户创造价值之间的时间，就要频繁交付（Frequent Delivery）。可以看到，在这一点上精益思想和敏捷开发实践得到了完美结合！

上个月在InfoQ中文站一篇名为“抛砖引玉——重构是必要的浪费”的新闻中，Amr Elssamadisy提到过：

精益定义了两种类型的 浪费：“纯粹的浪费”和“必要的浪费”。“纯粹的浪费”指的是那种既不能给开发团队也不能给客户带来好处的做法。“必要的浪费”是指某些行为，即便它不能给客户创造价值，但也是在我们所知的范围内完成一项工作的最佳方式。

路宁在演讲时也针对精益所定义的浪费进行了重点论述，并且对后者进行了更为详尽的说明：在软件开发中，测试、集成、重构和管理都属于这种浪费。他还总结了为减少这种无可避免的浪费常常应用的几个有趣的Pattern：

• 积极对待，配备少而精的人——敏捷团队非常重视上面提到的几种浪费，团队中的管理人员和测试人员要比传统团队数量少而且要求高一些。
• 由个人的任务变为团队的任务——赋予团队成员清晰简单的目标，实现自我管理。团队中几乎所有人都参与到设计、测试和部分集成的工作。代码所有权共享。
• 将工作自动化，区分人和机器的职责——人工测试和自动化测试相区分，持续集成。
• 工作提前做，频繁做——测试驱动开发，在早期开始频繁的单元测试、重构和集成。早期就赋予团队成员目标，并通过各种方式确保他们及时了解项目状态。

ThoughtWorks的咨询师熊节和郑晔也曾分别撰文描述过精益、敏捷与浪费之间的关系： 敏捷的核心：消除浪费，走向精益和 消除浪费的敏捷。对此你有什么看法呢？你是否曾经尝试种种做法，去尽力消除纯粹的浪费，减少必要的浪费？欢迎留下你的宝贵意见，与我们，与其他读者分享。

这里是2008北京Open Party的 活动详情，以及 相关视频。

注：精益的五个原则
确定价值——以客户需求来定义产品的价值。
识别价值流——指从原材料转变为成品，并给它赋予价值的全部活动。
流动——精益思想要求创造价值的各个活动(步骤)流动起来，强调无间断的流动，将所有的停滞作为企业的浪费。
拉动——让客户的需求拉动生产、决定投入和产出，不把客户不需要的东西强行推给客户。
尽善尽美——不断对整个活动进行修正和完善，追求尽善尽美。