三、我们的对策
针对国内软件过程改进的现实，我们应该采取什么对策？本文试图提出一种初步的解决方案。
1. 选择正确的生命周期模型
首先，选择一个合适的生命周期模型对于任何软件项目的成功都是至关重要的。大量项目严重拖延、产品迟迟不能交付，究其根本原因往往是与错误运用了存在明显缺陷的瀑布模型有关，所以现代过程方法论，不论轻型、重型， XP、RUP或TSP，无一例外地都推荐、主张采用能显著减少风险的迭代演进式生命周期模型。早在1994年美国国防部就作出了一个重大决定，用新的软件开发标准MIL-STD-498取代旧标准DoD-STD-2167A，而在498所要解决的20个关键问题中就包括：去除隐含的对瀑布型开发过程的偏好，改进与递增演进式开发方法的兼容性以及改进与Ada等其他OO方法的兼容性 [8] 。这一态度的明显转变为我们提供了重要信息。
然而，由于种种原因，上世纪 70年代提出的瀑布模型多年来一直被我们的软件工程教育奉为经典来传授。而在实践中，我们采用的许多生命周期模型却不伦不类地介乎瀑布模型和正确的迭代模型之间，毫无规律性可言，从而为软件开发的成功埋下了严重隐患。应该说这是一个历史性错误，可惜国内许多客户和开发商对该问题的重要性长期没有引起足够的重视，美国人已经为此付出了惨痛的代价，却不知道我们有多少人现在还蒙在鼓里，愿意继续支付学费。
迭代是 OO开发的本性（Grady Booch）。正确做到迭代开发远比字面理解要难得多。世界领先的软件组织其项目迭代开发周期往往呈现图1的形态，每个迭代开发的内容、速度和质量都很稳定，这也是RUP、XP团队所能达到的理想状态（参见《软件架构》节奏原则一章 [3] ）。如果度量我们许多组织的开发工作，结果可能都会表现为类似图2的形状：迭代速度不均，每次交付的内容忽多忽少，而且往往迫于外部压力而牺牲质量。时常见到，开发人员加班随意而频繁，问题却始终层出不穷，进度也总是无法保证。可悲的是类似的现象屡见不鲜，反而让我们认为开发节奏紊乱是一种正常态。
2. 适度度量
CMM/PSP/TSP度量体现的是一切用数字和文档说话。企业要转变粗放式管理，提高效益，就应该注意对度量数据和实践经验的积累。有了历史与今天的对比，才谈得上明天的进步。另一方面，SEI开发CMM/PSP/TSP的主要目的就是为了评估美国军用软件承包商的过程能力。在巨额国防经费的驱动下，显然保证软件的可靠性和质量、过程可预测可度量往往是军用软件项目应该满足的首要目标，甚至可以为之不惜代价，提高生产率和降低成本则在其次。PSP/TSP基于历史统计数据的收集分析对过程进行预测、管理、控制、评估和改进，这必然需要长期积累，而大量样本、数据的收集、维护相对成本很高，如果没有自动化工具支持、严格的纪律保障和在基础设施上大量投入，全面度量的实效将难以保证。这种度量强度适合于组织内外环境和需求相对稳定，综合实力强、开发生命关键或可靠性要求高的大中型软件组织，以及那些需要对过程能力作出客观预测和评价的大型工程、异地外包项目。
图 3 、 TSP 周期 [4]
任何过程的成熟度都应该以最终交付产品 /服务的质量和ROI为最高评判标准。在民用商业软件开发环境中，及时推出满足客户和市场需求、适用的产品是第1位的，速度常常比尽善尽美更为重要。因此，RUP、XP与倡导统计过程控制的PSP/TSP在度量的范围和强度上有着较大差别，但这不意味着RUP、XP不需要度量，不能在敏捷、统一过程的框架中引入必要的度量机制。度量产品本身与度量开发产品的过程有所不同（如图3）。在测试水平还较低、质量保证相对薄弱的国内软件组织中，加强产品度量也尤其重要。我们不应为了追求过程成熟度而使度量面面俱到，应该在敏捷思想的指导下实现适度（按需）度量。
3. 建立 AUPF
是否一定要采用类似 XP那样极限的做法项目才能取得成功？答案显然是否定的。实施过程改进以达到SW-CMM目标，是否只有走PSP/TSP一条道路呢？相信答案也是否定的。组织一旦选定某种过程方法论，就在所有项目上一成不变地照搬执行，排斥其他方法，是不明智的。Alistair Cockburn指出，“不同的项目需要不同的方法论，一个项目的非常好的过程是这个项目所能负担的最小过程”，选择过程的原则：1）越大的团体需要越大的方法论；2）越关键的系统在构建的正确性方面需要越多的透明度/更大的密度；3）在方法论体积或密度上相对小的增加会导致项目成本相对大的增长；4）最有效的沟通方式是面对面的互动。
图 4 、软件过程计划谱系
Barry Boehm根据几种过程模型计划性的强弱，描绘了它们在计划谱系中的相对位置 [1] 。可以看到，里程碑风险驱动的RUP位于最极端的敏捷过程XP和里程碑计划驱动的TSP之间。Mark Paulk建议，“应该在组织业务环境中恰当的地方仔细考虑采纳敏捷运动的想法。” [5] CMM、XP是互补的，RUP可以和PSP、 XP集成，XP、ASD与Scrum也天然地相吻合，这些事实都说明重型、轻型过程方法论之间并不存在根本性的矛盾冲突。把这些互补方法论拼在一起，恰好可以发现整个软件过程体系全貌的一部分，可能这就是事物复杂性的原本反映吧。
