ais摆脱过程改进“黑暗面”的诱惑 邓 辉
本书已经有了三位软件方法学方面的世界级大师所做的序言，作为译者，实在是没有必要在此班门弄斧。但是作为中国软件从业者中的一员，当我看到国内软件企业在过程改进方面的一些所作所为时，我无法保持沉默。
国内软件企业在过程改进方面采用得最多的方法是 CMM( 能力成熟度模型 ) ，正如 Arthur Pyster 为本书写的序所说，基于 CMM 的过程改进方法如果被正确应用，可以在生产力、可预见性、质量，以及成本方面取得巨大的进步，但如果被误用，则会产生出令人窒息的过程。遗憾的是，国内有许多软件企业在推行 CMM 时，存在着相当程度的误用。造成误用的原因主要有两个。
首先，像 CMM 、 RUP 这样的大型方法的提出者，为了做到方法的完备性，所制定的过程框架往往涵盖了各种情形，并尽量做到一般化。要想这些方法发挥效用，必须根据自己项目的实际情况进行裁剪。糟糕的是，缺少经验和自信的开发者、客户和管理者往往把全套的计划、规格说明以及标准看作是一种安全保障，从而僵化地全套照搬。这样，那些面面俱到却无人问津的过程制品，就在这些“官僚化”的实施者的头脑中制造了一种安全假象：我们已经遵循了确保项目可预见、可控制的最佳实践。其后果是可想而知的。
其次，过程改进“黑暗面”的诱惑力是巨大的，过程改进的实施者们很容易陷入“黑暗面”的深渊之中。 CMM 等级所描绘的美好前景如此诱人，实施者们很容易受其诱惑而陷入只追求表面文章的等级的“黑暗面”之中。他们在应用方法时只是为了满足标准，而不是为了项目更好的运作；他们仅仅考虑认证、评分方面的事情，从而陷入了为评分而评分的境地；他们在面对真正具有挑战性的项目时，畏缩不前。难怪汤姆·迪马可会说， CMM 等级是软件企业的耻辱符，等级越高，标志着企业越没有创造力。
同样，敏捷方法也存在被误用的情况。很多软件从业者片面地认为，敏捷就是规范不严格、随意的方法，甚至把敏捷和“ code-and-fix ”等同起来。这种错误认识源于对敏捷的核心哲学的误解。敏捷方法认为：软件开发的根本问题之一就是所处环境变化多端这一本质。不同类型的系统经受着不同的压力和约束力，这些不同导致我们很难得到一个足以涵盖所有变更的严格的定义。软件开发面向人的本质，以及人的不一致性和多变的本质，使这个问题进一步复杂化。因此，这种试图把软件开发绑定到一个严格过程上的做法是低效的，因为它忽视了执行这个过程的首要部件 ( 人 ) 的本性。
基于这个核心哲学，敏捷方法的重点不在于如何制定出一套可用来测量的、严格、精密的过程，而是把这种严格性放在提高软件从业者职业技能上，这些技能包括：沟通合作、优秀的软件开发实践和方法、价值观念权衡以及期望管理等等。敏捷方法对这方面的要求甚至可以说是非常苛刻的 (XP ，即极限编程，是其中的典型代表 ) 。敏捷方法在根本上希望团队自行决定应该遵循的过程，敏捷方法更希望团队主动地并且定期地改变其过程。任何为了能检查一致性而定义严格过程的做法，都违背了这个核心哲学。
本书的作者在软件开发的实践和研究方面，功力深厚。在本书中，他们对方法被误用的根源进行了生动、深刻的剖析，并且为了加深读者的理解，还提供了两个来自真实项目的案例。更为重要的是，作者对在方法应用方面最为重要的一个关注点：“风险驱动”进行了详尽的阐述，并提供了一种基于风险的方法和分析技术。这种技术并非“只是另一种方法”，而是描绘了一种方式，当你在自己的实际环境内部平衡规范方法和敏捷方法时，这种方式可以组织你的思想，发挥你的个人洞察力。
正如本书中所阐述的那样，在建立最适合自己项目的过程方法方面，项目直接参与者的作用是最重要的，而那些通用的方法、原则仅仅起到辅助参考的作用。因为只有项目的直接参与者才能准确地觉察到项目的真实状况，进而做出最合适的决策。当然，决策的正确与否直接取决于决策者本身的能力。本书中所给出的基于风险的方法是非常注重实效的，如果过程方法的实施者能够在它的指导下，结合自己项目的实际情况进行思考和判断，完全能够成为胜任的过程改进者。
真心希望本书能够使国内的软件从业者们摆脱过程改进“黑暗面”的诱惑，在过程改进的工作中能够注重实效，逐步建立起最适合自己项目的过程方法，从而真正实现这些过程方法所描绘的美好目标。
