http://blog.csdn.net/Deniz/archive/2009/03/14/3989991.aspx
注：本文纯属个人思想发展路上的一些日记，不正确的部分请在海涵的基础上进行大无畏的批评指正，谢谢！
1 对软件开发的认识软件开发？
全世界绝大多数软件公司把软件开发分为设计、制造、测试三个阶段。认为从编码阶段以前的部分是软件设计阶段，编码属于软件制造阶段。从而产生的瀑布式开发模型以及从建筑行业照搬过来的管理经验和管理流程。
但是，果真如此么？在敏捷开发指导思想来源的《源代码就是设计》论文中，阐述了一个全新的思维：源代码就是设计，而生产制造过程发生在编译器把源代码转换为机器码的时候。如果非要把软件开发与建筑行业进行类比，源代码相当于建筑行业中的设计图纸、施工图纸与模型，是脑力活动的结果；而编译过程才属于建筑行业中的人工体力的过程。
如果此思想是正确的，那么禁止在编码开始后再修改设计就是一种错误的做法了。这也就是为什么瀑布模型对于大多数软件开发项目是不合适的，也是瀑布模型导致软件项目开发失败的真正原因。也是为什么大幅度提高软件质量、降低软件成本的功臣是类似于C++等面向对象语言的发明，而不是严格定义的“先进”开发流程。
2 软件项目更像什么？
软件项目管理是人类历史以来最为复杂之一的管理活动，这是由于软件产品不可视性所导致的开发进度、软件质量的不可视性，以及当前应用环境和未来应用环境的复杂程度所造成的。所以单单照搬建筑行业的管理流程和管理思想是不能根本解决问题的。因为我们是在一个预想的当前环境里面建造一个大概可以运行的看不见摸不到的东西，而且这个看不见摸不到的东西还要神奇地运行在未来的未知环境中。虽然实际上并没有我说的这么恐怖，但是这代表了软件项目的共同特性。相反来说，如果一个软件在开发前就完全已知当前和未来的各种条件，那么这样的开发根本称不上一个软件项目。
那么，如果非要把软件项目和建筑行业进行类比，把她比作为“在一个从未去过的复杂自然条件中修建一座能够自我生长的弹簧桥”显得更合适一些，这个弹簧桥不仅工作正常，还要外形美观，而且要能够抵御复杂多变的自然条件以及人为故意破坏，甚至还要时刻准备着连根拔起放在另一个从未去过的环境当中。这才能满足用户对软件功能、性能、操作性、可移植性、可扩展性、安全性等等的要求。
这也就是科学管理法所进行的软件项目无法有效地灵活解决风险，吸收变化的原因之一吧。
如果把源代码认为是最好的设计书，而那些开发文档只是辅助阅读源代码的说明资料，我们就应该能够明白为什么C++等面向对象语言的出现能够大幅度提高软件的质量，因为面向对象等C++代码比结构化代码如C语言更能够容易让开发人员直接阅读。
如果我们把代码中的设计变更认为是通过不断地改善样板间来改善软件质量的话，我们就能够容忍代码中发现的设计缺陷了。
如果我们能够容忍代码中的设计缺陷，并且准备有时间和预算去修改设计的话，那么采用瀑布式模型显然是个错误，这就是为什么我们本能地不采用瀑布式模型，而不明白其中道理的真正原因吧。
3 对CMM的认识
CMM 规定了的严格的过程，是一种科学管理法，是一种从下到上的汇报制度以及监督制度。虽然开源界比较排斥CMM，认为CMM与敏捷开发、测试驱动开发的开发等模式有冲突，我倒觉得不是这样，CMM只是规定汇报、监督制度，为的是让整个软件开发过程透明化、量化，从而带来项目可预算、责任人明确、可监督这样一个组织管理制度。而CMM并没有规定开发的时候非要使用瀑布模型，还是生长模式。因此，采用瀑布模型不应该是公司当中CMM人员强行规定，也不是开发人员拒绝CMM的理由，我们可以拒绝采用瀑布式模型，但是不能拒绝采用CMM。
另外，CMM所带来的将风险降至最低的做法也必然会带来项目竞争力下降。
另一方面，作为一种管理方法，CMM式的科学管理法已经占据了我们所有的管理思维。但是Eric Raymond提出的大教堂与集市中的集市为我们带来了另一种管理理念，我认为这是一种“能够自我生长的软件”的一种管理模式。
4 什么是自我生长的软件，以及相应的管理模式
我们都知道，农村家养的猪比卖到城里的商品猪好吃，土鸡比肉食鸡好吃，这是为什么呢？就是因为商品猪和肉食鸡的养殖生产打破了自然规律。猪和鸡的自然生长都需要一个大自然规定的周期，人为地通过各种药物来缩短这个周期必然会带来质量上的破坏。
软件开发也是如此，一个优秀软件的形成必然有一个大自然规定的周期，如果从QCD的角度来讲，强行地缩短这个周期D，必然会带来质量Q或者成本C上的损失。
虽然，在商业项目当中，我们不可能采用集市的管理方法，但是，我们应该了解到另一种声音，合理地避免人为强制的因素，在可预算、可控制、可汇报、可监督的前提条件下，承担一定风险的同时，让开发人员有精力、热情地开发出一款高质量的软件。最后带来公司利润、社会责任、员工成就感的三赢结果。
------解决方案--------------------------------------------------------
敏捷与CMMI并不冲突，两者是可以结合起来的
------解决方案--------------------------------------------------------
这次我们两个没有冲突。呵呵
对楼主的一个定义，我这里需要提出一些反面意见：“在敏捷开发指导思想来源的《源代码就是设计》论文中，阐述了一个全新的思维……”
在国外一个十分著名的软件咨询师康斯坦丁的书《人件集》中，对代码及文档提出了明确的反驳。其书中举出了详实的例子来反驳国外在80年代的时候提出的这种观点。
另外，从软件开发的实际设计角度来看，设计和代码所面对的对象是不同的，其对开发者所要求的技能也是有较大差异的。所以，我本人对代码即文档是持反对意见的。
连设计都不愿意做的程序员，更不可能给你写出可以说明问题的代码注释，也就是说明他的代码永远不可能成为有说服力的设计资料。
------解决方案--------------------------------------------------------
软件没有磨损，没有赋值成本 -> 软件没有磨损，没有复制成本
如果我们可以把0、1代码以及存储软件的介质不庸俗地看作软件 --> 如果我们不去可以把0、1代码以及存储软件的介质庸俗地看作软件