软件过程之所以混沌，最简单的原因在于人的本性：人们不愿承认他们对某些事情的无知。当承诺面临行政压力时，为了个人安全和稳妥，你会选择最紧凑的日程。缺乏承诺是混沌行为的普遍原因。除此之外．还存在其他因素。
混沌动因之一：无计划的承诺
无计划的承诺是最危险、也是最难以解决的软件管理问题。如果高级管理者给出错误的目标，最好的做法是将这项工作和他们以往的经验进行对比，让管理者明白为什么这种进度要求是不现实的。他们坚持自己的观点，要求管理者要么调整进度，要么另请高明。当所有高水平的工程师都这样做时，管理者就没有其他选择了，除非管理者自己去做。遗憾的是，很多程序设计人员开始跑步的时候看到的总是自己的跑鞋而不是目标。
微小的承诺同样会带来问题当一个新的需求看上去比较简单时，管理者往往会一口答应下来。软件是一项细致的工作，在看似简单的功能后面常常隐藏着陷阱。如果在作出承诺后才发现这些问题，管理者就会陷于非常不利的境地。通常的结果是不论工作量的大小，配备不足的开发团队都竭尽全力保持进度。
无计划的承诺陷阱无计划的承诺是一个陷阱，它是产生混沌的根源。首先，没有有序的计划意味着没有完成工作所需要的足够时间和资源，这将导致混沌，不花时间把问题想清楚，除了增加工作强度外，别无他法，这样事情往往会变得更糟。
混沌动因之二：英雄
技术奇才可以成为有力的财富。遗憾的是，英雄们有时认为自己永远也不会犯错。他们领导一个小型团队开发出—个优秀软件之后，往往觉得自己无所不能。他们拒绝制定计划，并引用其成功历史来证明白己不败的神话。不幸的是，这种危机来临时，几乎无路可走。英雄们总是靠自己的头脑运作项目，没有任何书面记录，每个人都必须到他们那里接受指导。在爆发点，这种直觉方法也就走到了尽头，走出危机是十分出难的。几周就可以交付的软件可能突然延期几个月，只有那靠不住的英雄知道究竟发生了什么。
混沌动因之三：魔力
人类天生讨厌复杂。历史上，科学家和工程师一直在努力寻求复杂问题的最好的简单解决方案，系统开发人员也个例外。有人认为，对于所有的细节和混沌，一定存在一个强大的解决方案。也许采用的技术不正确，也许是方法不对。可事实并非如此。虽然很多情况下改进的技术会有所帮助，但更需要的是有效的管理。寻找更好的方法和人员不仅可以理解，而且值得考虑。可是，当把希望寄托在具有魔力的结果上时，这种寻求将笼罩神秘的色彩并阻碍理性的思考。相信魔力将忽略所有细节的重要性，重要的工作却要推迟，危险降临了。
混沌动因之四：规模的问题
规模问题的基本原因是很多项目十分庞大。软件大小影响开发过程，是决定成败的重要因素。学会开发小型项目并不足以应付大型项目。可将规模问题概述如下：（1）随着软件产品规模的不断增加，理解难度也不断增大。规模渐进的级别大致如下：
?一个人可以了解项目细节。?一个人可以理解它，但记不住它，所以设计必须形成文档。?一个人理解项目的总体设计，但组件模块的细节由不同的专家掌握。?一个大型软件产品在产品管理层次上被定义和理解，但是由独立的团队掌握软件各个组成部分的特点和设汁。?对于软件系统，由系统管理团队准确定义和理解高层设计，但其每个组件产品仅由相关的产品管理组织掌握。?系统十分庞大并经过多个版本的进化后，没有人可以完全掌握它。(2)随着软件知识的广泛传播：
?准确交流需要通用符号。?标准必须文档化、进行解释并及时更新。?必须发现和解决标准之间的冲突。?标准的变更必须得到控制并分发。(3)对于大规模软件，需要对需求、设计、编码和测试进行控制。(4)随着软件规模的增大，需要采用原型或发布各个版本，因为：
?不能及时实现所有的功能。?没有局部系统的操作经验、就无法理解某些需求。?初步系统建立并运行之前，无法解决某些设计问题。?发布的方法有助于对用户的优先级事项进行分类。?大型软件系统开发没有一次成功的历史。(5)对于发布多个版本，会产生新的复杂性：
?为满足最终用户需要，需求必须划分为不同阶段。?每个软件组件的设计都必须和这些需求—致。?产品的相互作用必须协调，以满足发布功能的先决条件。?根据这种相互作用安排开发和集成计划。?预定早期系统驱动程序，以满足组件测试的要求。?紧张的进度要求在上一版本完成之前就开始下一版本的开发。本文摘自：瓦茨·S·汉弗莱著《软件过程管理》
赞赏
