一些思考和大家交流：关于软件开发管理本质与CMM的一些杂乱思绪

[Deniz]

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上的损失。

虽然，在商业项目当中，我们不可能采用集市的管理方法，但是，我们应该了解到另一种声音，合理地避免人为强制的因素，在可预算、可控制、可汇报、可监督的前提条件下，承担一定风险的同时，让开发人员有精力、热情地开发出一款高质量的软件。最后带来公司利润、社会责任、员工成就感的三赢结果。

[cmm2cmmi]

敏捷与CMMI并不冲突，两者是可以结合起来的

[青润]

[Quote=引用 1 楼 CMM2CMMI 的回复:]
敏捷与CMMI并不冲突，两者是可以结合起来的
[/Quote]
这次我们两个没有冲突。呵呵

对楼主的一个定义，我这里需要提出一些反面意见：“在敏捷开发指导思想来源的《源代码就是设计》论文中，阐述了一个全新的思维……”
在国外一个十分著名的软件咨询师康斯坦丁的书《人件集》中，对代码及文档提出了明确的反驳。其书中举出了详实的例子来反驳国外在80年代的时候提出的这种观点。
另外，从软件开发的实际设计角度来看，设计和代码所面对的对象是不同的，其对开发者所要求的技能也是有较大差异的。所以，我本人对代码即文档是持反对意见的。
连设计都不愿意做的程序员，更不可能给你写出可以说明问题的代码注释，也就是说明他的代码永远不可能成为有说服力的设计资料。

[Deniz]

谢谢两位指点，我一定去看看《人件集》。
另外，虽然我也反对连设计都不愿意做的程序员，但是我觉得以代码为核心，随之配以简要的文档可以有效地防止信息重复的所造成的修改一点而牵动一片的软件腐烂现象。
我倒是觉得以代码为核心并不是强调设计和设计文档没有用。设计必须要有，但是不一定非要详细的连函数的流程图都要画在字面上。这种做法第一次是很好，但是随着系统的修改，反而降低了整个软件的可信度，最后造成整个软件和文档的脱钩，没人愿意承认文档是正确的。如果每次修改都可以让文档去真实地反映代码倒也是可行，但是势必花费大量时间延迟交付，结果就是虽然降低了软件风险，但是失去了竞争力。

说了这么多，我的回复主要想说的是“太过迷信文档的也不好，文档记载的详细程度需要权衡，不是越详细越好”。

[以专业开发人员为伍]

看了你的“思绪”，随便联想到：

软件开发是知识产品开发创造过程，而不是一个材料固定、图纸固定、成本基本固定的重复性生产过程。软件没有磨损，没有赋值成本。软件可以以“软”的方式替换更新，而对硬件没有浪费。软件，如果我们可以把0、1代码以及存储软件的介质不庸俗地看作软件，那么什么是软件呢？是一种人工的智能的可执行的文档，而不是简单地一个艺术品式的文档。

形式逻辑既可以给人使用也可以给机器使用，但是作为这种代表吴的开发工具终究是给人使用的，没有人拒绝学习别人的智能产品。我们的智能发展到什么样的抽象水平，软件工具就会提高到什么程度，解决复杂多元问题的解法也许会从耗费100年一下子缩短到1年，就是因为抽象程度提高了。

软件开发不可能靠过程的一元因素的持续改进，那样是僵化的，没有前途的。往往会有抛弃原来的过程而重新构造初始技术方法、重新开始研究新的过程。

[以专业开发人员为伍]

软件没有磨损，没有赋值成本 -> 软件没有磨损，没有复制成本

如果我们可以把0、1代码以及存储软件的介质不庸俗地看作软件 --> 如果我们不去可以把0、1代码以及存储软件的介质庸俗地看作软件