对比丰田生产方式，敏捷原则和实践还太嫩

just in time(JIT) -- 只在需要的时候，按需要的量，生产所需的产品

自働化 -- 智能自动化

看板操作六个使用规则

没有看板不能生产也不能搬运，
看板只能来自后工序，
前工序只能生产取走的部分，
前工序按收到看板的顺序进行生产，
看板必须和实物一起，
不把不良品交给后工序。

当思考同敏捷方法的关系时，忽然感到，很多敏捷原则和实践，都没有丰田生产方式来得深刻。

目前感觉，看板并不适合贴在墙上或白板，更有效的做法是在开发人员的手里......

现在炒作的Lean，就是来自Toyota吧。
个人理解:Agile是解决基础的团队协作/能力问题；Lean是在其上（也可以不基于Agile）提高效率和效益的管理问题。
Agile强调了太多团队的主观能动性和工程师的经验；Lean要往回退一点，让大家认识到：计划和管理也重要。
实际上还是要看公司文化和团队执行力。能够很好地实现Agile的协作，客户交流，有效率地开发，再加上Lean也不是太难吧。
相反，如果在执行Agile的时候就遇到很多问题，说什么Lean和JIT，恐怕也是抱薪救火，又会走到传统开发的老路上，TQM（Total Quality Management）怕会变成Total Planning Management吧（虽然Lean也并不是TQM）。

Lean在不在Agile之上，我不太清楚。
但就洞透力来说，Agile还不能给人有整体的观感。
另外，实行JIT并不需要预备条件，而且收效会立杆见影。说不定还能解决已经存在的问题呢。

Agile是团队开发实践，Lean更多关注的是质量、生产目标这些管理因素。上面说的已经很清楚了。


“不需要预备条件”显然是不可能的。
借用CMM的说法，软件过程首先要是可记录的，然后是可控制的，最后才是可优化的。
如果前两点不满足，不可能实行“优化”这一步。而Lean恰巧在这一层次上。
Lean不一定基于Agile，但一定基于某种可记录和可控制的软件实践。
不满足这样的条件，不但不可能“立杆见影”，反而会添乱。
对于多数软件企业来说，还是扎扎实实把cvs，CI，客户交流这些东西搞好才是王道。没有这样的基础，Lean就是大词，空词，是企业内部斗争的大棒。

其實已經有人提出過 Lean 概念在軟件開發上的應用呢:
http://www.poppendieck.com/publications.htm

文章太多, 很多都很可讀的.

推荐一本书，大野研一的《丰田生产方式》，很薄，可以带着反复看。然后找本
现场管理的书，很有趣。

有时间想研究Lean的，可以看看《改变世界的机器》、《精益思想》、《21世纪汽车》。

CMM的东西你都敢借？
所以你就认为优化不可能在任何层次，任何阶段？你确实实践过不行么？
原先需要配置的地方，现在发现可以通过一个方面解决，这是优化。
今天我发现程序的发布阶段会化很长时间是由于不同分支的SQL没有管理好，明天我找到了解决方法，我就优化了发布过程。
一个新需求平均提交给客户的时间以前如果是一个月，现在可以做到3个星期，这也是优化。
甚至就是请大家吃一顿比萨，也可以看作优化，因为大家一起吃比萨心情很愉快。

是的，我认为任何对敏捷和精益方法有兴趣的人，都该读大野耐一的这本书。丰田之所以成功，一定做了某些别人不同的事情。

这个问题很有趣，我早就思考过这个问题，但是没啥像样的答案。
首先丰田模式归根结底强调的是以销售终端定生产，或者叫以用户价值指导开发。而显然软件开发是首先要以用户需求为开发线索，并以用户需求为开发的指导。但是这里有一个问题，丰田模式是否是以用户价值确定生产方式的呢？这点基本可以肯定的说是。也就是说生产和经营的流程应该以用户价值增值为核心进行组合和优化。而软件开发在这里显然存在几种情况，至少有很多的流程跟用户的价值关系不大，而更多的是为了满足软件开发者自身管理的需要。
其次我们还可以发现，在机械话的实物生产过程中，数据大量的存在，并且对数据的认识以及数据的意义基本不会存在异议。而为了获得这些数据，基本上不需要付出成本，并且对于这些数据的分析也很容易的在优化过程中收回成本。但是在软件开发过程中，数据的获得和对数据的解读一直不是一件简单的事情。如果数据的收集依靠人的手工记录，那么成本就会很高。而对这些数据的解读和分析，也十分消耗成本。原因在于没有一个合适的模型可以恰当的反应人的智力活动的成效和成本。并且也很难保证付出的这些成本能够在优化流程的过程中得到收回。我认为这里的关键还是在于如何能够自动化的收集数据，并确定收集的数据可以是能够容易理解，并且容易被计算的。这里是难点所在，也是cmm之类的方法一直没有从根本上解决的难点。而实际上现在普遍存在的cmm高级别企业过程失败的例子，绝大多数都是可以在这里找到源头的。这就好比你做cmm首先需要付出一个大成本，但是这个成本是不是能够马上在这个项目中收回就十分难说。归根结底软件是一种智力产品，拷贝的成本基本为零，从而造成了可比较性和可对照性都比较差，是这个问题的根源。

我说得很清楚了，只是借用它的一个说法。CMM的几个阶段中，过程“可优化”的含义究竟是什么，楼主还需要搞搞清楚。软件名词最怕这样的望文生义。

吃皮萨很好，我也喜欢。但是要分什么时候吃，跟谁吃。是否能够建立一个“吃皮萨”的软件过程，把它引入到我们的开发实践中呢？显然这里面也是有讲究的。比如，通常在会议结束之后，会议参与者，在一种自由、和平、友好的气氛下吃皮萨。你看，这样简单的一个过程，也是需要讲究的，是一种经验的产物。天天吃是不行的，下午的会议结束后吃通常也是不行的。
科普一下.关于前面两个例子是否属于过程“可优化”的范畴，首先要看你是否已经引入了过程。如果引入了,就说明你已经符合了我前面定义的"可记录,可控制"的定义,那么它就是过程可优化.否则就不是.举个极端的例子说，有些牛人开发是不需要cvs，UnitTest，debugger之类的工具的，这不妨碍他们开发高质量的软件产品。他们自身必然有一套保证产品质量的东西，比如说，他们异乎常人的大脑。但是,"牛人的大脑"不是软件过程,因为它是不可复制的.