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

  • 李剑

2008 年 1 月 21 日

话题:敏捷精益架构文化 & 方法

上周六(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 的活动详情,以及相关视频

注:精益的五个原则确定价值——以客户需求来定义产品的价值。



识别价值流——指从原材料转变为成品,并给它赋予价值的全部活动。

流动——精益思想要求创造价值的各个活动 (步骤) 流动起来,强调无间断的流动,将所有的停滞作为企业的浪费。

拉动——让客户的需求拉动生产、决定投入和产出,不把客户不需要的东西强行推给客户。

尽善尽美——不断对整个活动进行修正和完善,追求尽善尽美。
敏捷精益架构文化 & 方法