五、 基于容变过程模型的过程诊断与改进
1     软件过程敏捷性的诊断
SPM-PASS提供了一个对组织过程敏捷性进行诊断的框架，用来挖掘缺陷所在，并帮助组织克服这些缺陷。

SPM-PASS模型的三个层次对于过程的诊断与改善是很重要的。一般的BPR理论以流程的稳定程度、细致程度来划分层次。CMM以能力成熟的时间阶段性来划分层次，但过程自身结构的层次性以SPM-PASS来表示非常清晰。注意过程是基础层次，是组织对变化的适应、反应和反馈的基础过程。这一过程的敏捷性，决定了组织在市场应变能力、组织运行效率和软件产品服务质量的基本能力，以往以瀑布模型为主要参考过程的大多是因为在这一层次上敏捷性太低而造成计划过程的失灵和加工过程的低效。

但过分强调注意过程也产生问题。目前很多组织应用敏捷方法时难以成功的一个原因是过分强调适应、反馈，忽视了计划和加工能力的提高，把开发过程看作一个探索过程，把注意力只集中于客户需求的优先级，这虽然可以抓住一些市场机遇，或快速发现开发中的质量问题，但过程缺少全局和长远的建构过程指导，造成开发代价过高。

不同加工过程使软件开发过程形成不同的视图。从继时性加工角度，开发过程是迭代（Iterative）和增量（Incremental）的，从同时性加工角度，开发过程是演进（Evolutional）的。把加工过程分为同时性加工过程和继时性加工过程使原来混淆的过程性质变得清晰，组织可以从而找到软件过程的缺陷而进行补救。

要保持同时性加工过程与继时性加工过程的平衡。重视继时性加工，如FDD，很难保证所有工作的整体性和同步性，常会造成一个需求的代码和测试已经完成大部分时才发现与整个体系结构或另外一些功能的冲突，或造成过长的接受测试反馈周期。过于强调同时性，容易形成复杂的计划，混乱的标准。如目前很多基于WEB的Open Source开发，使系统混合了太多的标准和版本，影响到非专业用户的应用推广。所以合理的方法组合是必要的，如集成测试+单元测试、结对编程+重构。

计划过程是最高级也是对其他过程影响最大的，忽视全局的严格的计划，一味追求市场需求的机会和挑战，不是一个成熟的开发过程。计划过程是决策中理性的方面，但即便CMM也有计划层次上的一些弱点，如：低效的需求适应性的原因是把需求变化的管理放在配置管理和需求管理的内容中，而没有把关于需求适应的决策过程融入软件项目的全过程中。敏捷方法不迷信计划，但理性决策更多的渗透到注意过程和加工过程，使敏捷方法具备其竞争力。

2     实证案例研究
2001年，PMRC与DFDJ有限公司合作，承担“十五”国家重大技术装备研制项目XXX的子专题研究，为DFDJ开发分厂管理信息系统，DFDJ计算机中心为项目甲方，第一阶段用户确定为焊接分厂。

在项目的调研阶段，PMRC发现项目的目标很模糊，用户的系统需求也很不明确：（1）项目作为“九五”延续项目，希望在原来以生产技术部项目管理为主的应用范围基础上进行延伸，实现对各分厂内部生产作业过程的控制。虽然确定了从焊接分厂入手，但系统的定位很不明确，功能延伸到何种程度也没有清晰的思路。（2）焊接分厂和公司计算机中心对系统目标的理解不同。计算机中心希望在实现网络化管理后降低焊接分厂有纸办公的成本，类似一个OA系统；焊接分厂对系统的希望则很多，希望系统能够实现对计划、生产、调度、行政等多方面的信息化，简化工作，提高效率。（3）总公司已经启动了ERP项目的前期规划，这个系统与设计、工艺、计划、生产、物流各个部门的业务都有紧密的联系，与ERP的功能也有重合，如何处理系统与将来的ERP系统的衔接公司尚未规划。（4）经过了两周的调研和讨论基本确定下来的项目目标还是比较抽象，计算机中心最后方案对系统目标的陈述是：第一、满足和实现DFDJ股份有限公司焊接分厂管理信息化试点全部要求。（保留图纸、技术通知单、工票、质量传递卡、工艺卡五种票证外，其余全部实现无纸化的分厂生产管理、财务核算、库房中心管理、行政管理等）；第二、为DFDJ股份有限公司各分厂管理信息化建设提供应用样板，并在技术上，功能上、平台环境上在其它各分厂应用推广实施。

鉴于系统目标范围的不确定性，PMRC确定采用以XP方法为主的迭代开发方法。由于DFDJ地处四川，而开发地主要是湖南，采用异地开发使XP要求的一些条件不能满足，虽然PMRC对软件过程进行了一些必要调整，但开发中还是出现了一些问题。

1．注意选择问题造成快速迭代方法失灵

为快速明确重点，PMRC以快速提交迭代版本的方式来加快对功能范围的确定。开发团队通过分析，把重点首先确定在生产作业基本技术资料数据结构的确定上。在项目启动半个月内向DFDJ提交了第一个迭代版本——数据录入模块。但其后的一个多月，开发团队陷入了困境，因为发出的迭代版本并没有得到用户积极的回应，下个迭代版本的开发开始迷失方向了。

快速开发（RAD）和快速迭代发布（RIR）是保证软件开发注意焦点选择正确性和保持注意力持续性的基本方法，方法失灵说明过程在注意力层次存在缺陷，PMRC很快找到了问题：（1）用户没有理解软件过程，没有理解提交的软件模块对整个软件项目生命周期的作用，如用户向PMRC提出：系统还没有，为什么要录入数据？如果系统有了，找两三个录入员，一个星期就能完成所有数据的输入工作，为什么着急？（2）开发团队确定的开发焦点并不是用户最关心的功能点，两者对关键问题的优先级排序没有统一。软件过程的注意力是一个集成的概念，不只是使开发者将主要精力集中于关键的软件开发问题，更重要的是要持续地引导和保持客户的注意力于关键的功能设计上。

根据以上的诊断，PMRC提交了第二个迭代版本——基于Web的作业管理系统原型，以很有限的功能演示了未来系统的主要功能框架和操作风格。同时，PMRC还向甲方详细说明了所使用的基本软件开发过程，获得了甲方的认同和配合。此后的迭代过程便比较顺利了。

2．批量问题处理造成过程注意持续性问题

由于进行异地开发，对项目双方的沟通形成了很多阻碍，影响到开发过程。甲方强调让PMRC派两个主要开发人员去现场，PMRC也按要求在问题积累到一定数量时，派主要开发人员去现场解决一些问题，由于开发环境、时间等问题，开发人员往往只能做些修修补补，糟糕的是甲方逐渐开始依赖这种定期来人批量解决问题的方式，开发过程变得不连续，往往派出人员刚回来，用户的想法又变了。

问题积累到一定程度后，新的迭代版本开发周期被打乱了。批量处理的沟通方式影响了开发过程的连续性，开发过程不连续造成过程注意力的分散，失去持续性，无法吸引项目参与者的注意力，锁定客户和产品。

PMRC在认识到项目焦点迷失的状态后，采用了新的过程，如：在每天下午下班前，PMRC代表与甲方代表进行半小时的电话会议，会议内容包括：当天的功能成果，用户对已提交的功能点的使用反馈，用户新的功能需求，及对当天提交功能和解决问题的说明。这样，项目过程由迭代版本发布转变为持续集成的日创建方式，一周后，新过程的效果明显的体现出来了，因为问题不是成批提交而是分散提交的，甲方也没有再要求定期派人解决问题。由于每天的例会对开发者和客户都形成一种无形的压力，使双方每天都在关注于最主要的功能实现，并且每天都要互相提供可见成果，开发速度大幅度加快，在之后的一个多月，系统的主要功能基本实现了。

3．过程加工能力缺陷造成“烟囱功能”问题

项目通过持续集成和迭代发布实现了快速的功能实现和问题处理，这体现了软件过程的继时加工能力——开发团队对于客户持续激增的功能需求建立了逻辑顺序上的优先级，逐步递增地实现客户迫切需要的功能点，并即时处理了影响重要功能实现的BUG。但是，在这个过程中，加工能力的不平衡产生了新的问题。

由于焦点过多的关注于生产计划模块的一些常用功能点，项目的迭代计划很长一段时间集中在计划调度一小块功能开发上，甚至一两个星期限制在一个动态页面，客户虽然对这块功能很满意，但经过两个迭代周期后，PMRC发现系统的体系结构的问题——其他模块的开发设计远远落在了这一模块的后面，体系结构为该模块功能增加了许多特别处理而忽视了与其他模块之间的关联，造成其他模块功能扩展上的困难，系统成了一个结构失衡的“烟囱工程”。

PMRC认识到，出现“烟囱功能”的问题在于过程同时性加工能力的缺陷，因为系统为了即时满足用户要求，忽视了系统功能的全面视图和开发方法的全面视图，过程同时加工能力与继时加工能力失去平衡。过程的同时性加工能力体现在开发过程中，当前系统和未来系统始终有一个完整的体系结构，开发团队能够持续的维护系统各模块之间的合理关联和并行开发，建立一个高内聚、松偶合的系统。为了改变过程加工能力的失衡状态，PMRC即时引入了重构技术。

重构技术能够在不改变系统功能接口的前提下对软件的内部结构进行重新设计和调整，PMRC在经过了几个迭代版本之后对系统进行了一次大的重构，设计了新的数据访问机制，重构了所有的数据访问组件，在计划功能需求基本稳定之后，进行了第二次重构，构造了新的动态网页生成逻辑和页面转换状态机。其后的重构则更加小而且频繁，如对文章管理模块的重构、对打印格式输出组件的重构等，重构过程与集成过程平衡的持续进行，基本消除了“烟囱功能”的问题。