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

我想说的不是这样。
需要坦白的是，这个帖子从一开始就是个抛砖贴，我的第一和第二个帖子事实上都不是针对的楼主的帖子，而是因为忽然发现：终于有人讨论Lean了。所以把自己的一些实践经验抛出来，希望能够有些高手出来讨论一下。
公司背景：是一家有接近30年历史的外企，一直使用的是XP方法。今年开始推行Lean。但是Lean这个概念，对于很多人都是陌生的，如何做和怎么做是个问题。
公司现状：XP的基本方法还是做得很好的。至少我提到的“cvs，CI，客户交流这些东西”是做得不错的，其他一些XP方法推行的还是比较彻底的。比较出色的我觉得是客户交流这一块，基本上不会出现因为搞不清客户需求而发蒙的情况。
问题：我的理解Lean相较Agile更注重质量和反应速度。当然XP也有这些东西，比如iteration要保证每个iteration出一个可以release的版本。在最终release过程中如果需要去除某些模块和功能，我们做得也是很好的。
但是能不能更好呢？比如前面提到如何改进项目前松后紧的问题，如何改进和保障Unit Test质量的问题，以及如何进一步的，对团队培训，提高设计能力、代码质量和对测试的理解的问题。
目前我认为，产品质量还是有保障的，这是因为测试Team辛苦工作的结果；但是你应该知道，产品质量不等于软件质量。产品的Feature没有问题不等于Code的质量没有问题。
进一步的，根据我的经验，Unit Test的完善度问题。比如说前面提到的引入bug讨论机制，把已知bug倒入Unit Test（而不仅仅是Regression Test），这样的办法能够有效提高提交代码的水平，减少因为已知bug重复出现而出现反复提交和反复测试的问题。
而更好的代码和Unit Test质量，密切Developer和Tester的协作，也能够进一步降低测试Team的劳动强度，降低成本和风险。
以上说的内容，应该属于管理的范畴，属于开发过程的优化。
而你和楼主一再强调的“协作”、“自管理”，我认为不是Lean优于Agile的地方，这些应该是Agile已经有的东西。
我所关心的是，在Agile Team和Department中，如何引导性的导入这些过程，以及如何评价这些东西带来的结果好坏的问题。

其实你这样的答案是不是也意味着如果Agile实现Lean需要引入更多的管理呢？
而这种分析是否是建立在我前面的开发数据之上的：

而最终分析的方法是否也等同于我所说的：

呢？

其实这样的情况很正常。
早在前几年，当Agile在中国还是个新词，gigix在javaeye上大声疾呼XP，我们要XP的时候，我就说过，XP对于人的要求是很高的，我并不认为所有的团队都适合搞XP。
我的本意是想让它不要那么横空出世地出来，大家不要抱太大的希望。软件开发原本就是一项非常复杂的工作（或者对于gigix这样高智商/高情商/高财商的人不是很复杂，但对于我这样的一般人来说还是很难地）。XP以及Agile根本的优点在于它呼吁我们：实事求是地看待软件开发这项工作，老老实实地做好一些基本工作。如此而已。
现在很多人又开始批Agile了，一副恨铁不成钢的架势。其实不成钢的是我们，而不是Agile。

希望尽早听到你的高论。

我想, 財務分析是從投資角度去分析項目成效, 投資了多少錢, 回報又是如何, 而且是 iterative 的, 涉及的會是 Earned Value Analysis 或者 Incremental Funding Method, 可能是 ROI. 這些應該是些較為宏觀數據, 而不是 cvs checkin 或者 test case 數量之類.

CVS checkin, Story 數量等都感覺像表現考核的東西多於財務分析.

是否更多的管理? 我不肯定, 但我覺得這是自然的發展. 公司都想從財務角度了解營運狀況.

敏捷开发强调只应做满足目前需求的设计,如果你从丰田的JIT和拉动模式去理解就更自然；
敏捷开发中使用卡片来作为讨论备忘，随后作为开发的任务，丰田使用看板来实现拉动和JIT；
敏捷强调自动化的持续集成，丰田有自働化 -- 智能自动化;
敏捷通过自动测试作为看护守卫，丰田有定位停止的工作方式;
敏捷强调迭代小批量提交，丰田同样强调小批量均衡流动；
敏捷的开发是客户价值拉动的，丰田也一样；
敏捷强调代码集体所有，丰田强调多能工；
敏捷强调通过重构持续优化产品质量，丰田强调持续优化；

nod

其实你们说得也不矛盾啊，你讨论的是优化层次，他说得是优化方法，优化从方法论的角度上讲步骤肯定是：设定几个你关注的指标，然后看看优化前这些指标的值，然后优化，再看看这些指标是不是向好的方向发展，是的话，才能说优化了。而且这要求是一个科学的过程，需要设计实验验证的。比如利率的提高可能是会降低而不是增加银行的预期收益，保险公司不能提高保费以应对更大的风险，二手车市场的劣胜优汰等等，都是违反正常思维的，所以想当然是不行的。

实际上在国内由于历史原因，具有一种天生的喜欢做官的民族习惯，造就出一种总是希望做“管理”而不去做实事的“人才”。如果能抛开这个问题，专门的对管理和计划进行讨论无疑才是理想化的途径。但是可惜的是，离开这个大背景我们的讨论很可能就成了纸上谈兵。
而就XP来说，它并不是一种完全化的软件工程方法，很多开发过程中的问题并没有涉及，这也是为什么当初搞XP的那些人后来又去搞scrum的一个内在原因。也就是他们现在需要使用scrum在组织和管理方法方面于XP相协调配合。而实际上我们考察现在几乎所有的软件方法，除了RUP，即便是PSP、TSP这样的大家伙，也并没有将所有的方面都包括在内。也就是说你在实施这些方法的时候，总是要找一些这些方法外的东西将这些地方补充起来。
但是就是丰田方法来说其思想和语言同普通的管理方法是很不同的，比如它说说的质量同我们平时说的质量的概念就差别很大。但是他终究是一种组织和管理方面的方法论，自然比XP在管理和组织方面阐述的问题更多。但是说他对管理和组织就更加重视我看也谈不上。实际上丰田方法，最核心的实践是现场管理，这一点倒是和XP很类似。

我再来说说财务分析的问题，这个问题十分重要，但是我却不能充分的阐述清楚，毕竟我也才对这个问题思考和研究了一年多的时间。
引入财务分析首先并不是对公司内部的开发细节进行的，而是应该首先应用财务分析的方法去对需求和领域进行分析。比如对于项目的规划，版本发布的规划，客户协调和资源调配的规划，客户利益的预估，等方面进行财物的分析。这个分析对客户，毋庸置疑是很重要的。而通过这个分析，也可以叫开发者能够更好的理解领域和需求，更加好的衡量需求的重要性。特别是可以叫开发者，能够从各种相互矛盾的需求中选择合适的入手点。而有了这个基础，也可以事后将开发的结果进行量化分析，从而确定其开发的成果究竟如何。只有在做好这个的前提下，才谈的上去对开发流程内部进行量化和分析。
实际上在这个方式下，客户需要提出要求是战略目标和战术策略，而对于具体的需求仅仅提供的是一种参考实现。开发者做的是依据客户提出的战略目标，使用他们制定的战术策略，去分析和评估他们的具体需求实现。也就是说这个事后，需求并不是来着客户，而是来自客户定义、由开发者实现的一个判断系统。这点同传统的软件开发方式有十分重大的区别。
具体的实例可以参考http://www.douban.com/subject/1239617/ 《价值驱动的软件开发》。当然这本书说的内容仅仅是我要表达的内容的一个部分。
在此基础上，下一个环节是对开发流程的财务分析。其使用的方法，也是价值链的方法，这一点同丰田方法一致。也就是以最终提交客户的产物为参照，首先确定价值增值流程，然后确定辅助流程。并以此我基础，对各个流程进行整体分析，从而寻找价值流程最大化的途径，消除在辅助流程上的浪费。
最终我们将进入价值增值流程，对流程内部进行细分，优化环节链接，改善价值流转。也仅仅是在这个时候，那些开发团体内部产生的类似bug数之类的数据才产生效果。
当然这现在仅仅是我的一个想法，还没有应用到实际的操作中去。这是因为这个方法要求的东西太多，操作起来需求分的步骤也多。当然每一个步骤并不是复杂，只是反馈和负反馈比较多而已。
我希望我的这个答复能够叫大家能概要的明白，我最近很多言论的动机和背后的思考问题的方法。

一点感受：

是的，完全同意。也因此很多好的开发方式不能真正实施。而对已有的管理模式进行改进时，各方面的感受也必须考虑清楚。

基于上面的原因，scrum在国内的环境下有些理想化。那么，怎样的管理组织方式/办公室政治更为适合呢？这是一个问题。


是否可以得出结论，我所要的答案，还是只能从团队建设和培训的方面来追求？“自我管理”和“自我完善、自我提高”。
有点像武侠小说，郭靖学了全真的内功，再学七怪的武功就事半功倍。
管理层在这个过程中应该只起引导和催化作用。——马钰只要和郭靖一起爬爬山，睡睡觉，就万事大吉了。

所以这应该是比较高层的方法，而且分析过程很可能是和开发人员无关的。