Karl E. Wiegers
许多软件开发组织正在赶上CMM软件过程改进的游行彩车， 但是太多的组织又掉了下来。如果你希望从你的软件过程改进投入中得到零回报，请遵循以下程序：
1. 在过程评估、咨询服务和培训研究班上花费大量的金钱和时间。
2. 创建一个包含各种规程大夹子，然后告诉团队成员他们必须马上开始遵守所有的规程；
3. 接受高层领导的指示：“照着去做！”；
4. 看着规程文件的大夹子落满了尘土，而团队成员根本没有改变他们工作的方式。
本文介绍从过程改进工作中的吸取的教训，以避免无用的工作，提供关于如何进行软件过程改进的实用技巧，以及基本过程改进的步骤描述。补充资料列出了一些资源和参考。
什么是过程改进
从本质来讲，过程改进很简单：始终如一地应用那些带来好效果的实践， 改变那些导致问题产生的实践。这就需要坦率的内省和仔细的分析以前项目成功的地方和不足的地方背后的原因。你主要的动机应该是通过寻找的更好的软件开发方法和管理方法以达到特定的经营成果。你可以使用已制定的软件过程框架，如SEI的软件过程成熟度模型（CMM），来指导软件改进工作。但是需要记住的是你的目标决不是简单地的满足模型的要求。
过程改进周期
图1说明了一个总体的SPI周期。定义你期望达到的商业目标后，通过过程评估来评价当前的过程，问题，以及项目成果。具备了评估的见识以及关于软件产业最佳实践的知识，你可以设定一个现实的改进目标。选择能够解决当前过程缺点并向目标前进的实践的一小部分。确定一到两个项目作为新的过程的试点并在正式推出之前进行调整。
评定
当前实践
计划
改进行动
建立、试验
并实施过程
评估
结果
新的过程达到了预期的目标吗？
行动策划工作执行的好吗？
发现的问题和建议
行动
新的过程
试验结果
计划下一
改进周期
试验和实施平稳吗？
图 1 软件过程改进生命周期
为实施新的工作方法进行策划，将大大增加你成功的可能性。最艰苦的部分就是实际上实施一个行动计划； 如果你不做这部分工作，什么都不会真正改变。给新的过程一些时间，然后观察行动计划所致力于解决的问题是否有所减轻。关于过程好处的硬数据比主观感觉更有说服力。然后继续过程改进生命周期来解决下一个最紧迫的需要。过程改进是一个旅程，而不是终点。
关注于痛苦
痛苦是改变人们工作方法的最好的动机。我说的并不是外部的和人为引发的痛苦， 而是在我们现在的工作方法中遭遇的非常真切的痛苦。告诉人们变革会带来一个美好的未来，是鼓励人们变革的一个方法。更有说服力的方法是告诉人们，如果不变革，马上就要处于危险之中。
评估可以帮助揭示痛苦的地方和项目面临的主要风险。评估可以采用一个简单的头脑风暴会议，你的团队成员可以找出影响提高生产率和质量的障碍。或者呢，可以花钱请外部的咨询顾问来进行半正式的评估， 还可以按照已有的过程模型（如CMM），进行严格的正式过程评估。当然，正式的评审需要花钱而且耗费时间，但是他们可以对比者过程标准来彻底地当前的过程实践。
根据我的经验，过程评估很少揭示出特别出乎意料的问题。很多开发组可能已经觉察到了他们的问题和习性，由外部人员进行评估只不过正式的揭示这个问题。因为外部人员远离开发组织的办公室政治， 历史上的矛盾和特别人物。评估会让你直接面对不安的问题情形。 评估绝对不应成为寻找过去问题的过错和责备个人的论坛。
进行评估可以表明管理层对于过程改进的一种决心和承诺。切记，要对评估所发现的问题和建议进行到底，否则，你就在浪费评估上投入的金钱和时间，并失去挫败的团队成员们的信任，他们会得出结论管理层对进行变革根本不认真。
评估通常识别了一大堆的改进机会，比你能够着手解决的要多的多。“焦点”就是过程改进中最关键的词汇。设计一个更好的过程并且将其变为团队日常工作方式的一部分所花费的时间比你想象的时间要长的多。我曾经遇到一个斗志昂扬的由20人组成的项目团队，在七个改进领域里同时推进改进。资源平均地分配在七个领域中，没有清晰的优先级，尽管很狂热， 但几乎没有成效。
按照你期望的经营成果来陈述过程改进的目标， 比如说，目标可能是“消除从开发阶段传递到系统测试阶段的不正确的构造版本”，而不是写成“软件构造版本递增规程”。SPI活动
而是达到某个目标的手段， 而不是以SPI本身为目的。你的经理应该能够清楚的表达，希望从SPI计划的成功中，看到小组成员的行为和结果发生什么样的改变。
对于那些最高优先级的目标，开始先选择两到三个目标进行改进。如果你很快地完成了这几个目标，很好，在从评估报告中选取下一步改进的领域。一次步子不要迈得太大，不要在刚刚起步时尝试太多事情。大的开发组织可以在多个项目中同时进行若干领域的改进，但是每个项目一次仅关注于很少的领域。
沟通，沟通，沟通当要求人们变更他们熟悉的工作方式，他们通常感到不情愿，因为对于熟悉的方式（即使效率不高）感觉到舒适，而对于未知感到担心。考虑到繁重的过程负担会影响到创造性和和软件的按时发布也是普遍的，但是，这种担心常常超过了现实所带来的。你的团队成员也许会有一种挫折感，即使他们已经尽了最大努力，评估结果还是找出了过程的不足之处。客户和其他外部组也会认为SPI计划给他们从程序员那里获取所需要的东西增添了障碍。
要解决上述问题，沟通应该贯穿于过程改进活动。应该清楚有力地说明当前过程的不足所付出的代价。 代价可能包括：包括膨胀的进度表、功能的遗失、大量的加班，高的产品支持成本、不高兴的客户、和士气低下等；向怀疑论者们解释过程改进活动对于个人、项目团队、公司和客户有什么好处。为了减轻对势不可挡的变革的担心, 强调新的过程将被深思熟虑地挑选，是由团队成员自己创建的，并将循序渐进地推行的，寻找那些愿意尝试新的规程和文件模板并提供信息反馈的“同盟军”，帮助为成功变革作基础工作。
向团队成员和相关人员宣扬取得的成就。公开的承认对每一个成功变革做出贡献的人，表明建设性的参与SPI计划是一个期望的行为。分析不成功的变革尝试来理解为什么很艰难并调整你的做法。
一个关键SPI操作原则是，“温和而持续不懈的压力”。保持过程改进的目标和状态对整个团队可见。强调改进目标如何与企业的业务目标统一的。在小组会议上留出时间来评审改进活动的进展，阶段性地向管理层报告改进工作取得的成功以获得他们的对工作的支持。
灾难的事情是，在年初虚张声势地启动过程改进计划，却再也不提起，直到年底时检查是否达到了目标。当然没有达到目标。对于大多数项目成员来说，在项目活动中工作总是比为过程改进作贡献更加重要。经理应当不断向团队强调过程改进工作是重要的和有价值的。
为过程改进建立组织保证
认真对待过程改进的组织，通常设置一个三层的组织架构来确保过程改进工作的成功（图2）。但是你应当根据你的组织的情况调整这个思想，组织结构不应过于复杂。只要能够保证知道的改进行动被识别、启动、实施和取得效果。管理指导委员会（MSC）提供资源并且设定方向和优先级。它也可能为每一个过程改进领域识别出一个“过程的所有者”， 一个负责达成过程改进并在工作组更迭时提供连贯性。
通常管理指导委员会的成员包括组织的高级经理，过程改进经理，领导SPI工作的个人，挑选的的项目经理和部门经理。管理层的不同级别积极参与到MSC中，表明组织对于改进工作的非常认真。MSC的职责包括：
l 设定改进领域的优先级；
l 特许设立工作组从事与特定改进领域；
l 监控改进活动与状态；
l 评估已完成的改进活动的影响；
l 管理过程改进风险和消除障碍。
图 2 典型的软件改进组织结构
软件工程过程小组或SEPG（发音为“S-E-P-G”，“sep-gee”或“see-peg”），协调各种过程改进活动。SEPG担当管理层的代理来实施过程改计划。一个大型组织的SEPG应当有一个全职经理，一些专职的软件过程专家，一些轮换地参加的兼职人员。
过程专家经常来自测试和质量保证人员，但是至少有几个SEPG成员应当具备坚实的开发经验。项目管理经验也是需要。相对于一帮不知道真正的软件是怎么开发的理论家，这些资格提供SEPG更多的可信度给开发人员和管理人员。
SEPG学会了大量关于评估，过程改进框架，如何编写好的过程和规程文件，如何影响变革的知识。变更管理的人性和组织方面至少和过程改进的技术方面一样重要。有效的SEPG成员应是有条理的, 耐心的, 灵活和有效的沟通者， 他们可以根据个人情况改变他们的方法。他们是娴熟的促成者，能够和不同的参与者，一些参与者可能根本不信SPI和不愿参与，在敏感话题上引导有成效的讨论，。
对于所有过程改进计划有关的人员来说，SEPG是一个资源。他们的专长，资源和外部关系加速变革活动，因为参加过程改进的人知道有一个可以寻求帮助的地方。SEPG成员通常履行以下职能：
l 开发战略的和战术的过程改进的计划；
l 领导或参与过程评估；
l 协调和促进各个过程改进工作组；
l 收集业界最佳实践的信息和文献；
l 积累组织的过程财富，如规程、模板、检查清单、工作产品范例，并在组织范围内共享；
l 评审工作组制定的新的过程、规程和模板；
l 领导整个组织范围内的过程改进活动，如度量和培训计划。
SEPG小组编写所有的新规程，然后强加给项目组的做法不是一个好主意。这样一种典型的“隔墙扔物，殃及他人”的方式，总是要失败。通过专业人员参加工作组（过程改进工作组或过程行动团队）的方法参与到现实可行的新的规程中。推荐的方式是，由与规程定义相关人员组成过程改进工作组（也称为“过程行动团队”或者“过程改进团队”）来制定规程。
一个工作组由3到6名项目代表组成的特别小组，负责一个特定的改进领域。他们的可交付成果一般包括该领域当前过程的描述，新制定的过程以及过程财富。工作组的工作也许仅仅包括为一个项目实施新的过程，也许是为整个组织定义新的过程。
认真细致的研究工作组目标的范围，以便三个月内可以完成。如果延续时间太长，那么工作成员们会失去热情，人员也会有更迭。你可以重新授权给工作组，也可以召集一个新的小组进行下一轮的改进活动。尽量让所有的项目成员和项目经理都在某个时候参与到一个工作组来（当然不必在一次完成），这将有助于给所有的团队成员对新的过程的拥有感。SEPG成员可以发起每一个并促进工作组的首次会议。 然而, 成为过程改进计划的主人并在SEPG撤走培训动力后维持工作组成就，对于软件开发组织来说是非常重要的。
策划行动
把你的SPI计划看作一个项目， 提供组织结构，资源，和其他开发项目一样的需求。两个有用的策划成分，总体的战略软件过程改进计划和每个工作组的战术上的行动计划。有些人不乐意作计划，把制定计划看作无用的繁文缛节和负担。然而，制定计划本身并不困难，困难的是思考、提问、聆听、理解和磋商等工作。实际上，制定计划只是不过是把你思考的内容抄写下来。即使简单项目，计划也能够帮助项目按照规定的过程执行，并且提供了可以用以跟踪进度的参照。
图3提供了战略SPI计划的模板，战略SPI计划指导组织的长期过程改进。组织的过程改进经理通常是战略SPI计划的主要作者，而SEPG成员和关键经理应当评审并批准战略SPI计划。使用这个模板为你的SPI策划所用。
每个工作组应该使用标准的模板来编制行动计划，描述工作组的要实现目标以及如何实现这些目标。行动计划应该识别：
l 需要完成的商业和技术目标， 这些目标将与写在战略SPI计划中的整体目标进行对比跟踪
l 对过程变更是否达到预期效果的测量项
l 过程变更的组织范围
l 参与者，他们的角色和承诺投入的时间
l 工作组报告状态，结果和问题的报告机制
l 外部依赖或风险
l 所有活动完成的日期目标
l 行动条目的列表，对每项行动条目指明负责人、截止日期、目的、活动、交付成果和所需的资源等。
把每一个过程改进战术计划的行动条目限制在9条具体的、相当小的行动。这将帮助控制工作组的工作量在几个月内，而不是对于参与者来说遥遥无期。
1. 目的
1.1. 首字母缩写词
1.2. 参考文档
2. 概述
3. 执行概要
4. SPI启动的商业情况
4.1. 商业基本原理
4.2. 指导原则
5. 过程改进目标
5.1. 短期目标
5.2. 长期目标
6. 假定、风险与障碍
7. 过程改进相关的组织机构
7.1. 组织范围
7.2. 管理层决策委员会
7.3. 软件过程改进经理
7.4. 软件工程过程小组
7.5. 工作组
7.6. 过程所有者
7.7. SPI顾问
8. 成功准则
9. 改进议程
9.1. SPI活动的选择
9.2. 当前SPI活动
9.3. 过程改进路图
图 3战略性过程改进计划模板
向成功前进
过程改进的领导者是领路人，引导着组织首先认可需要更好的实践，然后成功地实施新的实践。这种指引要求稳定的目标和坚定不移的决心，不断改变的目标会使得参与者感到困惑和沮丧，他们会撒手不干，说“等你想清楚你真正想要什么，再告诉我”。避免被追求更高的CMM级别而分心，而是专注于提升经营成果，通过选择性和创造性地应用现有框架（如CMM）所提供的指导。
决定你对SPI的热衷的程度并按此分配资源。一个组织，如果在软件过程改进上投入的资金只占总预算的3%－4%（包括培训、评估、咨询、SEPG人员支出、工作组人员等），那么它的所谓SPI只不过是随便试一试。如果资金投入比例达到7%－8%，那么该企业对于SPI就是相当认真的；而10%的比例就意味着企业对于SPI巨大的投入。通过跟踪花费在SPI活动上的时间，确定计划的工作是否完成以及你当前的资源投入是否与你的目标相一致。
生产率
初始状态
过程改进开始
改进的未来状态
不要在这里退出
学习曲线
时间
图 4 过程改进的学习曲线
认识到学习曲线存在的现实，短期的绩效下降是因为你学习新的工作方法，并且和每人的个人过程结合起来。对于个人而言，吸收新的更好的工作方式会花费时间；对于组织而言，作为一个整体来，使好的工作方法制度化为操作规程也需要花费时间。你花在SPI上的时间和金钱都是在组织长期成功方面的战略投资，那些资源也不能在当前的项目中所用。在小的胜利上感觉高兴，并庆祝你的成功。不断尝试让你明天的项目工作做的比昨天做的更好，
对于每个小的进步都应该感到高兴，并且应该保持下去，让明天的工作始终比今天做的更好，最终你将在竞争中领先。这就是过程改进的真正所在。
本文地址：http://com.8s8s.com/it/it33638.htm