早期软件工程和软件项目管理的探索

我在企业IT这个行业里已经浸泡了很多年了，从普通的程序员到IT高级经理。我刚刚进入这个行业的时候，其实做一个程序员还算一个挺光荣的职业。那个时候的IT项目管理其实还处在传统的软件项目管理方法论上到现代的敏捷软件开发的转变过程中。

早期的软件项目其实非常容易失败。当年在软件工程领域有一本非常著名的书《人月神话》。这本书的作者是Brooks博士，图灵奖获得者，北卡罗莱纳大学计算机科学系创始人，IBM OS/360系统的项目经理。他是最早一批开始研究软件工程的组织和管理的专家，并且进行了不同方向和深度的探索，给出了不少有价值的结论。我们可以看出在Brooks的那个时代，软件开发的工具和方法还是非常有限的，哪怕是简单的源代码管理工具可能都不是每个团队都在采用。软件开发很多时候还是靠天才程序员的超人能力来完成某些功能的开发，哪怕最简单的合作和沟通其实都不是我们现在这样直接和有效，因为很多软件开发的名词那时候都还没有发明呢。那时候的软件项目管理经验直接来源于军工，建筑和科研工程的项目管理经验，传统的瀑布似的项目管理，其实就是来源于建筑和科研项目的管理模式。首先设定一个目标和需求，然后设计好软件的各个功能要求，紧接着拆分成不同的工作项，给每个工作分配时间和人员，然后根据这个估计，开始开发。这本书里面提出了一些方法，基于当时的理念，比如外科手术模式的开发团队，采用面向对象技术，把软件划分不同的模块。同时作者也发现了了采用面向对象语言比如C++，COBOL的复杂性而导致的学习成本的增加。还有对开发效率和软件质量之间的矛盾的分析。程序员往往对软件开发的进度和复杂度过于乐观，而造成成本和时间往往大大超出预算的问题。作者在当时的环境下确实做了很多的探索，是非常有远见的，最后他对软件工程的困难非常清楚，对其未来的发展抱有很大期望。

软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。

后来，大家开始进行软件开发标准化的尝试。如果我们可以把软件开发和IT项目看成是一个工程问题，那其实我们是可以从已经成熟的工业项目管理获得灵感的，比如建筑，制造，化工行业的项目管理。我们可以通过制定一套标准体系来指导成功的项目实施，于是CMMI标准腾空出世。这个标准由美国卡耐基梅隆大学软件工程研究所经过长期的研究总结而推出。曾经很多软件企业为了证明自己软件项目管理能力的成熟度，使尽浑身的解数来通过这个标准。其分为五个等级，分别是：

CMMI一级，执行级。在执行级水平上，软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。但是由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务。项目实施能否成功主要取决于实施人员。

CMMI二级，管理级。在管理级水平上，所有第一级的要求都已经达到，另外，软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行了相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。二级水平的软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。

CMMl三级，明确级。在明确级水平上，所有第二级的要求都已经达到，另外，软件组织能够根据自身的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。这样，软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。科学管理成为软件组织的一种文化，成为软件组织的财富。

CMMI四级，量化级。在量化管理级水平上，所有第三级的要求都已经达到，另外，软件组织的项目管理实现了数字化。通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。

CMMI五级，优化级。在优化级水平上，所有第四级的要求都已经达到，另外，软件组织能够充分利用信息资料，对软件组织在项目实施的过程中可能出现的次品予以预防。能够主动地改善流程，运用新技术，实现流程的优化。

相信很多软件行业的同行都经历过这种为了达到CMMI标准而强行套用各种CMMI要求的规范，流程和文档的开发项目。其实最后往往都流于形式。事实上这种标准最大的问题是忽视了软件行业的生产不同于传统的领域。核心生产力的提高很难通过流程的优化来实现，高质量也没法通过一些标准的执行来达到。每一个软件开发都会遇到不同的问题和困难，而产生产品的是人，而不是通过机器。当然CMM也I并不是一无是处，这个标准的流程至少给出了一个软件项目开发的参考标准模型，并且产生了很多软件工程的术语，比如基线，配置，交付物等等...

1987年出版的《人件》，具有划时代的意义。这是主流软件工程研究第一次直面软件项目管理的真正核心问题--如何管理人，如何有效地发挥开发和测试团队本身的能力，从而达到交付理想的软件和IT系统。而且书中也注意到了不同团队的开发人员之间巨大的生产力差距，其实对于知识工作者的生产力差距，很多人已经发现了。包括彼得德鲁克的管理著作中也提到了如何管理和提高知识工作的效率问题。如何去提高工作效率，给员工提供宽敞和安静的工作环境，团队的凝聚力其实非常重要。

其实作者指出了绝大部分IT项目最主要的问题，其实是团队协作的合作问题，是人的问题。不同水平的程序员生产力差别非常之大。而提高生产力的重要手段是创造弹性和舒适的工作环境和团结向上的团队文化。