路宁(luning)的博客

	Very Fat - Manager defines waste All what we spend time and resource on are needed, valuable and not waste. Nearly zero waste in out work.
	Fat - Oganization defines waste There may be some waste in our work, like the endless meetings. We admit 15% of our work is waste.
	Lean - Customer defines waste We generally treat what a reasonable customer doesn't want to pay for as waste. A reasonable customer understands why we spend time on testing and refactoring, and is willing to pay for it. Over documentation, unused features, efforts on defects and work in progress are all waste. There is always new waste identified from time to time.
	Very Lean - Critical customer defines waste We treat what a critical customer don't want to pay for as waste. Management, test, integration, refactoring and estimation are unfortunately on the list. They are necessory waste to prevent bigger waste. Doing them frequently, in small pieces, automaticly, early and with shared responsibility are pretty much the guidlines we rely on to minimize them. Sometime we cann't resist challenging everything and feel crazy, maybe we need a doctor at this time.

When people talk about a software project, they usually think of a car as the analogy in manufacturing industry. With this analogy, somebody believe that it makes no sense to 'translate' practices/ideas from manufactoring world because there are so many obvious differences/gaps between them. This thought also limits us from learning more from TPS(Toyota Production System) practices.

This is a misleading analogy. It's a group of cars designed, manufactured and delivered for a particular market within a period, which are compared to a software project, not just a single car. Below are more analogies:

Software Concept	Misleading Analogy in Manufacturing	Proper Analogy in Manufacturing
a software project	a car	a group of cars designed, manufactured and delivered for a particular market within a period. They may end up with great variety.
a software feature	a feature/part of a car	a car satisfying a customer
the lifecycle of a software project	the manufacturing stage of a car	a loop including steps of design, manufacture, deliver, after service, feedback, refine design, ...

Given the proper anology above, most TPS practices/ideas become inspiring and meaningful for software development.

And, it is meaningless to compare standard parts with standard software components in context of standard, the two industries share the same pursuit of the standard/better ways of adding values and solving problems in fact.

书的全名是《丰田现场管理方式 - 丰田巨额利润的秘密》，日文翻译的，1978年出版，整整30年了。阅读过程中确实能感受到那个年代的“朴素”，而现代介绍精益生产的书则充满了“提炼与升华”。

该本介绍了丰田生产方式的方方面面，浅显易懂，而且介绍了很多工厂的具体实践，会把你带入生产第一线。照例，下面我把书中一些有意思的地方摘录下来。

• 商业活动中，购入物品被加上差价，形成销售价，...，企业收益并非来自于对消费者有意义的增值活动，而是把负担转嫁到消费者身上。这是一种反社会的现象。...

书的全名是《系统思考 - 学习型组织必备读本》（<Seeing the Forest for the Trees - a Manager's Guide to Applying Systems Thinking>）

系统思考简言之就是强调从整体、长期、动态和连续的角度认识事物和解决问题，而不是反应式地，局部地、短期和静态地思考问题。它专长于认识和把握复杂系统，揭示和分享团队成员的心智模式。

之所以看这本书是因为我认为“系统思考”（systems thinking）以及“系统动力学”是精益思想（lean thinking）背后的理论支持和思考工具。在这里把阅读过程中发现的一些“亮点”摘录下来备个忘：

• 系统思考即整体思考，比较接近中国传统思考方式。在中国人的社会里，当你拿到一个物品时，大多问这是哪里来的；而在西方人的文化里，他们会问这是由什么组成的。
   
• 企业被分为几个独立部门，高级主管们整天关在会议室里......，技术部门......，质量部门......，各职能部门相互扯皮......“各司其职”的“后遗症”使我们几乎丧失了关照整体的能力，“过度分工”的结果是工作越努力，公司的利润就越低！
   
• 很多人存在这样一个逻辑，即认为只要每个人、每个部门都把目标达成，整个公司的目标就会达成。所以，只要公司目标没有达到，人们就会自然而然地反推一定是某个部门或某个人没有做好，只要将这个“害群之马”揪出来换掉，问题就会迎刃而解。只是真正的害群之马很难找到。扯淡！造成问题的关键是人们把整体简单当成部分的总和了，并由此导致对部门间互动和关系的忽略。
   
• 整体大于局部之和。
   
• 从根本上讲，管理只有两项工作：“踩下油门”（成长引擎）和“松开刹车”（消除障碍）。
   
• 对于很多团队而言，“我们可以一起唱歌、一起跳舞，却不能一起思考”。
   
• 系统的关键特征：
  1. 涌现：系统作为整体表现出来的个体不具备的特性。
  2. 自组织：动态的，高度有序的，开放的。
  3. 反馈：大量内部反馈机制。
  4. 能量流：做为开放系统需要持续注入能量，能量流过整个系统。
  5. 自修正：大量反馈回路的交互作用保证系统一定程度上免受外部冲击影响。

    飞行的鸟群、骑车人和自行车构成的系统、人本身、地球、合格的团队都是系统的例子。

• 系统的精髓就是它的组件之间的连接，而不是作为独立个体呈现出来的各种特性。
   

• 每位经理都尽职尽责地管理好自己的“一亩三分地”，然而，所有人都成功管理好自己分内的事情的结果，却通常是局部最优化。在大多数组织中，这通常都是组织结构和局部绩效评价措施的必然结果。......工厂经理们受到提高生产效率的激励，把车间填满成品，从而使之变成“市场销售的问题”。
   
• 理解动态复杂性并清楚地认识到其背后的模式及因果关系非常困难。从某种意义上说，人的思想确实更适合处理细节复杂性，即对某一时间某一地点的系统进行理解，尽管这时的系统由很多元素组成。
   
• 系统思考和系统循环图帮助你看到复杂现象背后的简单因果回路。
   
• 有时候“治标”确实比“治本”更有诱惑力。
   
• 在系统循环图中，是事实在说话，而不是我们的测量能力在说话。因此，只要它确实存在，就把它捕获并记录下来，尽管它可能是一个像“士气”这样的“模糊变量”。
   
• 就业务中的事务这一层次进行交流，无法达到创建高绩效团队的目的。我们必须进行更深层次的交流 - 必须在心智模式的层次上交流。系统循环图是实现这一层次交流的重要工具。
   
• 从个人风格和信念两个角度对计划方式作一个划分：
  
  
  
  
  1. 那些相信自己可以预测并控制未来的人是“上帝”。他们踌躇满志，知道一切问题的答案。他们根本不需要任何计划方法--他们就是有决断力。
  2. 那些希望授权但认为他们能够预测未来的人是“赌徒”。他们明白自己必会每注必赢，因此他们希望了解成功的机会有多大。赌徒们很欣赏财务分析。
  3. 那些希望授权但认为他们能够预测未来的人是“学究”。他们偏爱分析、方法、数据和技术，他们总在寻找“正确的”答案。他们是受欢迎的咨询顾问，总会有人愿意为最新的“管理潮流”买单。
  4. 最后一角留给“向导”。和学究不同，他们不相信仅仅因为掌握了正确的技术就能自然地发现“正确的”答案、相反，他们知道未来无法预测，他们试图引导自己的组织在各种不确定性间穿行。

 

前些天，客户的一个经理问我，来到ThoughtWorks前后自己有什么变化，当时说的都是和工作相关的，今天突然想记录一下自己在日常生活中观点的变化，这些都直接或间接地受到敏捷和精益思想的影响。

• 以前习惯每周坐车去大超市买一大堆吃的回家，买的时候都挺新鲜，吃得时候要留意一下是否已经烂了。现在更多是在楼下的小超市买东西，哪怕会有点贵。
   
• 以前溜达到超市库房，看到工人们忙碌在堆积如山的商品前装卸，觉得挺有意思。现在心里却想，老子付的账还要给这库房买单，还要给“装箱”、“拆箱”这类无聊的动作买单，心里不甘。
   
• 以前心理想着“十年磨一剑”，等我牛了之后吓死你们。现在琢磨出点东西就想到处去显摆。
   
• 大学四年，尽管大部分知识在工作上都用不上，但觉得这些知识对我应该是有些潜移默化的影响的。现在看来，这种想法就是扯淡，是给目前的高等教育找借口，学习本来就是一辈子的事，需要啥就学啥，用不上的东西就是浪费。
   
• 以前喜欢用大钱包，有用没用的都往里装。现在用一个极小的钱包，除了钱，只有两张卡和一个省份证。
   
• 以前攒一周的脏衣服，周末一起洗，现在天天都想洗，只是后悔买了那个5.5升的洗衣机，太费水了，很多只能手洗了。如果能有一个小的洗衣机，然后和邻居共用一个大的就完美了。
   
• 以前搬家的时候这个不舍得扔那个不舍得丢。最近一次搬家，东西扔的真痛快。去年春节回老家，真想把家里的“垃圾”都扔了，可是没法说服父母。我爸连我小学时候用的课本都不肯扔，说是要留给我未来的儿子用，汗。
   
• 以前到银行，在超市，深信“排队”是一种美德，现在更多的时候是在想“为什么还要让我排队啊”。
   
• 以前总觉得北京这三环四环不够宽。现在感觉很多路根本没利用上，很多“大院”、“小区”对公共交通一点贡献都没有。
   
• 以前感觉有个××商业中心、××展览中心和××CBD挺好。现在听到“中心”、“集中”这样的字眼心里就烦，好好的交通就坏在这些中心上了。

 

我说上面这些变化都和敏捷和精益有关，你信么？

    前些天在InfoQ中文站上发表了《软件开发中的准时化生产》一文，它是在我的一篇同名博文基础上修改而成的。李剑指出了原文中的很多问题，并给了我不少建议，新文章在内容、结构和语言上有了不少改进。

    文章简介：

• 在软件开发过程中进行频繁的交付，以此减少库存（部分完成的工作），暴露并消除浪费，加快价值的流动。
• 通过客户来拉动开发过程，确保每一时刻团队成员都在围绕客户认为最重要的软件功能展开工作。
• 在第一时间、第一现场发现问题，并从根本上解决问题，以此将质量内建在分析、设计和开发的过程中，而非依赖后期检测来保证质量。
• 将与项目相关的所有人组成高度授权的团队，通过可视化地向团队成员全面展示项目信息来支持自我决策。
• 当改进流程和实践时，要以快速交付和高质量为首要目标，而成本则要端到端地考量，低成本往往是实现快速交付与高质量的自然结果。

精益思维	传统思维
是流程的问题。	是员工的问题。
系统思考，优化整体。	各个部门优化自己的工作。
快速交付和高质量是相互促进的两个因素。	快速交付和高质量是一对矛盾，而且很难做到。
流程应该“脆弱”一些，小问题会因其破坏性而被及时处理，最终无处藏身。	流程应该“强壮”一些，多设置一些“缓冲”和“保险”，让小问题被吸收掉。
针对流程进行考核。	针对个人进行考核。
清除员工面临的障碍并开发员工的潜力。	激励并管理员工。
是什么让错误发生了？	这是谁犯的错误？
更频繁的预测是改进预测可靠性的有效办法。	做更加全面细致的分析是改进预测可靠性的有效办法。
小而灵活才是美。	大而集中能提高效率。
少做那些没有价值的工作。	加速做那些能产生价值的工作。
我的工作要如何配合其它工作将事情最终搞定。	要了解并做好你自己的工作。
只要理论上可行，我们就试试看会有什么结果。	在有实事和数据证明其可行性之后再动手。

Lean Thinking	Traditional Thinking
The process is the problem.	Employees are always the problem.
System thinking and optimize the whole.	Optimize functional departments.
Fast delivery and high quality accelerate each other.	Fast delivery and high quality are expensive.
Process should be BRITTLE and easily broken by small problems.	Process should be STRONG with all safety switches turned on.
Measure the process.	Measure the individual.
Remove barriers and develop people.	Motivate and manage the employee.
What allowed the error to occur?	Who made the error?
Forecast more frequently to improve reliability of the forecast.	Make a comprehensive analysis to get a better forecast.
Being small and flexible is beautiful.	Being big and centralized is efficient.
Reduce none value-added work.	Speed up value-added work.
How your job fits in the process and get the things done.	Focus on your job and just do it.
Let us try and see what will happen if it is feasible in theory.	Start changing after we prove that it will win with fact and data.

    准时化生产（Just In Time）是精益生产（Lean Production）和丰田生产系统（Toyota Production System）中的概念，其目的是在合适的时间生产合适数量的满足客户需求的产品。它充分体现了从客户价值出发组织生产运营系统的观点，是一种先进的生产方式，为包括丰田、戴尔等众多世界500强企业的成功奠定了基础。
    软件开发组织从一开始就在向制造业借鉴和学习，并形成了各种不同的开发方...

    有两种浪费，纯粹的浪费和必要的浪费，后者往往被引入来避免更严重的后果或更多的浪费。必要的浪费仅在绝对理想的环境中才能消除，而纯粹的浪费在正常工作环境下就应该彻底消灭。

    比如软件开发中的测试工作就是必要的浪费，测试工作并没有直接为软件增加任何对用户有意义的价值，而只是确保本应产生价值的代码能够正常工作，是避免更大失误的产生。在绝对理想的环境下大家不犯错误，就可以不用测试了。

&nbs...

    量产后遗症中的“以设备和部门为中心”，泛指没有从满足客户最终需求这一目的出发，而过于强调和优化技术手段、设备或部门等，这种局部优化很可能导致破坏整体和最终目标的结果。
    下面是2个通过重组克服这一后遗症的例子：

   * 交通运输部重组


    两会期间公布的《国务院机构改革方案》中提出...

    强调以根据职能或功能划分的部门为中心（量产后遗症之以设备和部门为中心），结果损害整体利益的事例比比皆是。

    前段时间有一个不愉快的消费经历，这让我考虑了一下处理客户投诉的部门该如何考核绩效的问题。

    如果抱着以部门为中心的想法，投诉部门经理可能认为部门的人越多自己越有地位，看到大家都忙着接电话处理问题就感觉部门的工作状态很好，他也很可能制定出以处理...

从敏捷软件开发的角度分析丰田生产系统的各种实践。

[本文发表于《程序员》杂志2008年第3期] 

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

    精益思想是从顾客端开始，由此往回推，把任何不能为顾客创造价值的活动定义为浪费，并以消除浪费为主要手段使成本、...

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

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

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

流...

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

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

库存 生 产企业为避免供应不足建立库存，却同时增加了成本，减弱了企业对市场的敏感性，隐藏了企业内部各种各样的问题。在市场稍有风吹草动的时候，库存商品就变...

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

如果说最终...

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

批量生产能降低成本 这 似乎是显而易见的道理，而且已被数百年的工业历史不断证实了的。针对纯粹的生产环节来说，这个结论也许是正确的，但如果从客户产生需求到满足客户需求这一 端到端的过程来看，将持有和管理库存的成本、产品...

从软件开发的角度介绍精益思想

    下面这个PPT是后来在公司做关于这次活动Session时用的。
    http://luning12.blogbus.com/files/12068109222.ppt
    上周六，和公司同事一行8人去了塘沽Yazaki工厂参观。Yazaki天津工厂是生产汽车线束的，它是Toyota的供应商，应用丰田生产方式已经很多年了，这次去主要是学习和现场体验精益生产。  &...

     前几天在公司做了一个"Lean Thinking With Examples"的Session，马同学在香港，没听着，下面是他回北京看了PPT后和我在IM上的一段对话，讨论到了关于库存和浪费的话题：   Ma Bo: 你说书架也是浪费是啥意思？
Lu Ning: 是库存
Lu Ning: 库存是指那些还没有产生价值但已经停滞的东西
Ma Bo: 那书架上的书不读也是浪费？
Ma...