越来越多的软件开发组织开始努力赶上CMM这趟马车，但是其中大多数最后又还是从这架马车上摔了下去。如果希望从你的软件过程改进活动得到零回报，请遵守以下秘诀：
1. 花费大量的金钱和时间用于过程评估、咨询服务和各种形形色色的CMM培训班；
2. 按照咨询顾问们开给你的软件文档模板，制定一大堆你想得到想不到的过程规范，然后告诉程序员们必须一个不漏地马上开始实施；
3. 接受你的高层领导的指示：“照着CMM说的去做！”；
4. 你辛辛苦苦的收集一大堆数据，而程序员们的工作方式依然照旧。


1 何谓过程改进

过程改进的要义可以用一句话概括：对于效果良好的项目实践要推广应用，对于问题较多的项目实践要变更调整。这就需要对于过去项目的成功之处和不足地方进行如实的内省和仔细的分析。过程改进最大的动机应该是通过改善软件开发和管理的方式来打到企业的某个业务目标。CMM可以作为一个框架来引导你的过程改进活动，但是你的目标却不是简单的满足这个模型的要求。

2 过程改进周期

图1说明了一个完整的SPI生命周期。首先，定义你期望达到的业务目标；然后，通过过程评估了解当前过程的问题，以及实施过程改进的可能结果。有了在评估中获得的对本组织现状的深入了解，以及业界的最佳实践知识（CMM），你可以设定一个现实可达到的改进目标。下一步，选择可以解决当前过程不足的合适的最佳实践，可以是这些最佳实践的一个很小的子集，来接近改进目标的最后实现。确定一到两个项目作为新过程的试点，在取得成功后可以适当调整然后全面推广。

如果对新工作方式的实施作一定计划，无疑能够大大增加成功的可能性。最困难的部分就是实际开始实施一个行动计划，如果这部分工作被忽略了，那么一切努力都相当于白费。新的过程要发挥作用需要一些时间，你应该耐心观察改进行动所针对的问题是否得到了解决或者症状得到了缓解。用定量数据来表示过程改进带来的好处，总是比主观的认识要更有说服力。

如果这一次改进活动成功了，那么再继续这个过程改进的循环，开始解决下一个最紧迫的需求。记住，过程改进没有终点，而是一个不断延续的旅程。

3 集中精力于那些让你头痛的部分

人们日常工作方式中那些让他们头痛和感到麻烦的部分，是促使他们改变现状最强的动机。我在这里指的并不是外部的和假想的痛苦，而是有些时候我们在目前的工作方法里所感觉体会到的实实在在的“痛苦”。许诺一个更美好的将来，可以是鼓励人们作出变更的一个方法。但是，也许更有效的方式是指出他们现在正处于危险之中。

评估可以帮助揭示那些让你感到头痛的部分真正原因所在，也可以揭示项目潜在的巨大风险。评估的形式可以不拘一格，既可以是一个简单的“头脑风暴”会议，所有的小组成员都参与讨论究竟什么阻碍了生产率和质量提高；也可以是一个半正式的邀请外部的咨询顾问参与的评价；还可以是一个严格的参照CMM标准的正式评审。当然，正式的评审需要一定资金投入，但是可以参照一个业界统一的标准对企业当前实际作出彻底的全面评价。

根据我的经验，过程评估很少揭示出特别出人意料的问题。很多开发团队可能已经意识到了他们的问题所在，外部的咨询公司所作出的评估只是使这个问题得到正式的确认。因为，作为外部的第三方，可以置身事外于这个组织的遗留问题、人际纠纷和许多“特殊人物”。评估让你直面那些尴尬的问题情势，而绝对不应该是提供一个对过往问题进行刻意挑剔或者归罪某人的讲坛。

执行评估的另一层作用，就是显示管理层对于过程改进的一种决心和承诺。切记要按照评估所发现的问题和提出的建议进行改进，否则不但对于企业投入评估的金钱和精力是一种损失，而且也在团队成员们的心中失去了信任。这些在评估中花费心血的人们，会认为管理层对于变革实际上并没有严肃对待。

评估经常是确认了一大堆的改进机会，而你不可能一口全部吃下。“聚焦”就是过程改进中要注意的关键之处，因为，设计一个更好的过程并且将其变为团队工作方式的一部分，所花费的时间往往超过你的设想。我曾经遇到一个20人的开发团队，他们雄心勃勃，企图同时在七个领域实施改进活动，虽然精神可嘉，但是收效甚微。

过程改进的目标，应该用所期望的业务成效的术语来叙述。举个例子，目标不应该写成“制定软件构建版本递增规程”，而应该写成“减少从开发阶段传递到系统测试阶段的不正确的构建版本”。SPI的活动其自身并不是目的，而是达到某个目标的方式手段。项目经理应该清楚明白的说明，如果改进活动成功，那么期望开发团队成员的行为方式会有怎样的改变。

从优先级比较高的那些目标中，一开始仅仅选择两到三个实施改进。如果你很快的完成了这几个目标，很好；再从评估报告中选取下两个目标继续改进。每次步子不要迈得太大，不要在刚刚起步时尝试太多事情。大型开发组织可以一次在多个项目中同时进行若干领域的改进，但是，对于每个单独的项目仍然应该一次集中精力做好一件事。

4 沟通极端重要

当要求人们变更他们熟悉的工作方式，他们通常感到不情愿，因为对于熟悉的方式（哪怕效率不高），人们总是能感觉到某种舒适，而对于未知总是感到不安。同时，对于过程改进可能带来的一些额外的程序化的工作量，人们也普遍担心这会影响到创造性的发挥和软件的按时发布。但是，这种担心经常是不现实的。团队成员也许会有一种挫折感，因为哪怕他们已经尽了最大努力，评估结果仍然表明过程有不足之处。客户会认为过程改进活动给他们平添了不少障碍，使他们的需求不容易达到程序员。

要解决上述问题，沟通应该贯穿于过程改进的全过程。应该明确的说明当前过程的不足之处所造成的代价：包括不断推迟的进度表、功能的缺失、经常性的超时工作，超额的产品支持费用、客户的不满意、和士气的低下等；应该给那些怀疑论者们细致的解释过程改进对于个人、团队、公司和客户的好处；有人可能会担心变更接踵而至、疲于应付，应该强调新的过程是经过深思熟虑选择的，是团队成员共同创建的，也是循序渐进、逐步推广应用的；应该积极寻找那些愿意尝试新的过程和新的文档模板的支持者，提供反馈，为成功的变革奠定基础；应该公开的表扬对于每个成功的过程变更作出贡献的人员，来传达一个信息：建设性的参与过程改进活动是企业所期许的；应该仔细分析不成功的过程变更，查明为什么无法坚持定义的过程，最后不得不改变目标。

过程改进的一个关键的运作原则是，“平缓而持续的施加压力，尽一切努力来应用”。应该保持过程改进的目标和状态始终清晰，强调改进目标与企业的业务目标是如何统一的。应该在小组会议上留出时间来检查改进活动的进展，阶段性的向管理层报告改进工作取得的成功以获得他们的支持。

我们经常看到，有的开发团队在年初对过程改进工作满腔激情，而在整个一年中却不再提及，直到年底开始检查是否达到当时定下的目标，结果当然是失败。对大多数团队成员而言，具体的开发工作总是比投入过程改进更加重要。项目经理应该经常提醒和强调，过程改进工作是重要的和有价值的。

5 要有和过程改进相应的组织机构设置

认真对待过程改进的企业，通常设置一个三层的组织架构来确保过程改进工作的成功。不同的企业可能要根据实际情况作出调整，总的原则是不必过于复杂，够用就行。”够用“的标准是，有形的改进活动可以被有效的识别、启动和实施。管理层决策委员会（MSC），设定过程改进的方向，优先级和保证改进活动所需资源。它某些时候会为每个改进领域制定一个”过程负责人“，保证改进目标的达到和团队的稳定性。一般来说，管理层决策委员会的成员包括企业的高级经理（首席执行官或技术总监），过程改进经理，各改进领域的过程负责人，部分慎重选择的项目经理和部门经理。管理层的各个级别积极参与到MSC中，表明组织对于改进工作的重视态度。

MSC的职责包括：
（1）设定过程改进领域的优先级；
（2）为特定改进领域的工作组建立章程；
（3）监控改进活动与状态；
（4）及时评估以完成的改进活动的影响；
（5）管理过程改进风险和消除障碍。

软件工程过程小组（SEPG，发音为"S-E-P—G”，或者“sep-gee”，或者“see-peg”），协调各种过程改进活动。SEPG相当于管理层的代表，负责过程改进活动的实施。一个大型组织的SEPG应该有一个全职经理，一些过程改进专职人员，一些每年轮换的兼职参与人员。过程改进专职人员经常来自测试和质保人员，但是至少应有部分过程改进专职人员有丰富的开发经验，项目管理经验也同样重要。这些资格保证了SEPG成员比单纯的缺乏开发实践经验的理论专家更具可信度。SEPG成员应该掌握大量的关于过程评估、过程改进框架、过程和规范文档的书写、如何影响变更的知识。人员和组织因素方面的变更管理至少和过程改进的技术特征同等重要。工作富有成效的SEPG成员应该是有组织性、有耐心、适应能力强的有效沟通者。他们可以根据沟通对象的不同个性来调整沟通方式，他们是富于技巧的促进者，能够在敏感问题上引导不同的参与者通过讨论得到预期结果，而这些参与者可能最初反对过程改进或者不要参与过程改进活动。SEPG对于过程改进活动的所有相关人员而言，都是一个巨大的资源。他们的专业技能，人际关系都能够促进变更的发生，因为过程改进活动的参与者知道在遇到问题时应该到何处寻求帮助。

SEPG小组的职责通常包括：
（1）制定过程改进的战略计划和战术计划；
（2）领导或参与过程评估；
（3）协调促进各工作组；
（4）收集业界最佳实践的资料和著作；
（5）积累组织的过程财富，如规程、模板、检查清单、工作样品，并在组织范围内共享；
（6）评审工作组创建的新过程、规程和模板；
（7）领导组织范围内的过程改进活动，如度量和培训。

并不推荐SEPG小组定义所有的新规程，然后强加给项目组执行。这样一种典型的“隔墙扔物，砸中行人”的方式，总是不可避免的最后要失败。推荐的方式是，由与规程定义相关人员组成工作组（“过程行动小组”或者“过程改进小组”）来制定规程。一个工作组由一群项目组代表临时组成，通常是3－6人，负责一个特定的改进领域。他们工作的可交付成果一般包括该领域当前过程的描述，新过程的定义以及其他的过程财富。工作组的努力也许仅仅包括对一个项目实施新过程，也许是为整个组织定义新的过程。
工作组的工作范围应该限制在三个月可以完成的工作量以内。如果延续时间太长，那么工作成员们会逐渐失去热情，有可能出现反复。在每一轮新的改进活动中，工作组可以重新组建或者再度召集原班人马。尽量让所有的项目成员和项目经理都有机会在某个时候参与到工作组来，当然不必在一次完成，这样让他们对于新过程有一种拥有感。SEPG小组成员可以建立工作组并负责工作组的第一次会议，但是，项目开发小组应该在SEPG小组的培训阶段结束后，自主管理过程改进活动并保证工作组的持续性。

6 计划过程改进的行动

一切工作皆项目，软件过程改进活动也应该按照项目的方式来运作，应该与任何开发项目一视同仁，提供同样的资源和结构。一个整体的过程改进战略计划，和每个工作组的过程改进战术计划，都是十分必要的。有些人不乐意作计划，将这看成浪费时间的文牍主义和额外的负担。然而，写计划本身并不困难，困难的是制定计划中的思考、询问、聆听、理解和协调等等步骤。实际上，写计划只是抄写而已。即使是对于最简单的项目，计划也能够保持项目按预期路线执行，并且提供了可以用以跟踪进度的参照。

过程改进战略计划对组织的长期过程改进活动给出了指导，组织的过程改进经理通常是战略计划的主要作者，而SEPG成员和其他高层经理评审并且批准战略计划。

每个工作组应该按照标准的模板来编制行动计划，描述工作组的待实现目标以及如何实现的思路。行动计划应该确认：
（1）验证过程变更是否达到预期目的的度量标准；
（2）过程变更在组织内的应用范围；
（3）参与者的角色和他们承诺投入的时间；
（4）工作组何时向何人报告；
（5）外部依赖或者风险；
（6）所有活动结束的目标日期；
（7）行动条目的列表，对每项行动条目指明负责人、截止日期、目的、资源和交付成果等。

每个过程改进战术计划的行动条目限制在9条以内，并且每条都应该是特定的、小规模的。这样，可以帮助控制工作组的工作量在3个月内，而不是对于参与者来说是遥遥无期。

过程改进的领导者应该担负决策的功能，引导着组织首先承认需要更好的实践方式，然后成功的实施新实践。这种决策要求对于目标坚定不移，清楚知道自己的目的所在。不断改变的目标会使参与者们感到困惑，他们会最后拒绝行动：“等你拿定主意后，我们再干吧。”避免被CMM更高级别的目标所吸引分心，而集中精力于如何提升业务成效，集中精力于有选择的创造性的应用当前CMM级别所提供的指导。认真的对待过程改进活动，并且保证所需的资源提供。一个组织，如果在软件过程改进上投入的资金只占总预算的3％－4％（包括培训、评估、咨询、SEPG人员支出、工作组经费等），那么它的所谓SPI只不过是随便试试、浅尝辄止。如果资金投入比例达到7％－8％，那么该企业对于SPI就是严肃对待的；而10％的比例就意味着企业对于SPI“只许成功，不许失败”的一种承诺。跟踪实际花费的时间，确定计划的工作是否如期完成，现有的资源是否能够满足改进活动目标的需求。承认学习曲线存在的现实，短期内工作绩效有可能下降，因为你需要学习新的方法，并且将新方法和个人的工作过程结合起来。对于个人而言，要把新的更好的工作方式真正吸收掌握需要时间；同样，对于组织而言，要把新的实践制度化并且成为企业的例行工作也需要时间。你在SPI上花费的时间和金钱都是一种长期的为组织成功的战略投资，那些被占用的资源也不能在当前的项目中使用。对于每个小的进步都应该感到高兴，并且应该保持下去，让明天的工作始终比今天做的更好。这就是过程改进的全部。