如何使过程改进发挥作用ProcessImprovementthat.doc

发挥作用的过程改进(Process Improvement that Works） Karl E. Wiegers 许多软件开发组织正在赶上CMM软件过程改进的游行彩车， 但是太多的组织又掉了下来。如果你希望从你的软件过程改进投入中得到零回报，请遵循以下程序： 1. 在过程评估、咨询服务和培训研究班上花费大量的金钱和时间。 2. 创建一个包含各种规程大夹子，然后告诉团队成员他们必须马上开始遵守所有的规程； 3. 接受高层领导的指示：“照着去做！”； 4. 看着规程文件的大夹子落满了尘土，而团队成员根本没有改变他们工作的方式。 本文介绍从过程改进工作中的吸取的教训，以避免无用的工作，提供关于如何进行软件过程改进的实用技巧，以及基本过程改进的步骤描述。补充资料列出了一些资源和参考。 什么是过程改进 从本质来讲，过程改进很简单：始终如一地应用那些带来好效果的实践， 改变那些导致问题产生的实践。这就需要坦率的内省和仔细的分析以前项目成功的地方和不足的地方背后的原因。你主要的动机应该是通过寻找的更好的软件开发方法和管理方法以达到特定的经营成果。你可以使用已制定的软件过程框架，如SEI的软件过程成熟度模型（CMM），来指导软件改进工作。但是需要记住的是你的目标决不是简单地的满足模型的要求。 过程改进周期 图1说明了一个总体的SPI周期。定义你期望达到的商业目标后，通过过程评估来评价当前的过程，问题，以及项目成果。具备了评估的见识以及关于软件产业最佳实践的知识，你可以设定一个现实的改进目标。选择能够解决当前过程缺点并向目标前进的实践的一小部分。确定一到两个项目作为新的过程的试点并在正式推出之前进行调整。 图 1 软件过程改进生命周期 为实施新的工作方法进行策划，将大大增加你成功的可能性。最艰苦的部分就是实际上实施一个行动计划； 如果你不做这部分工作，什么都不会真正改变。给新的过程一些时间，然后观察行动计划所致力于解决的问题是否有所减轻。关于过程好处的硬数据比主观感觉更有说服力。然后继续过程改进生命周期来解决下一个最紧迫的需要。过程改进是一个旅程，而不是终点。 关注于痛苦 痛苦是改变人们工作方法的最好的动机。我说的并不是外部的和人为引发的痛苦， 而是在我们现在的工作方法中遭遇的非常真切的痛苦。告诉人们变革会带来一个美好的未来，是鼓励人们变革的一个方法。更有说服力的方法是告诉人们，如果不变革，马上就要处于危险之中。 评估可以帮助揭示痛苦的地方和项目面临的主要风险。评估可以采用一个简单的头脑风暴会议，你的团队成员可以找出影响提高生产率和质量的障碍。或者呢，可以花钱请外部的咨询顾问来进行半正式的评估， 还可以按照已有的过程模型（如CMM），进行严格的正式过程评估。当然，正式的评审需要花钱而且耗费时间，但是他们可以对比者过程标准来彻底地当前的过程实践。 根据我的经验，过程评估很少揭示出特别出乎意料的问题。很多开发组可能已经觉察到了他们的问题和习性，由外部人员进行评估只不过正式的揭示这个问题。因为外部人员远离开发组织的办公室政治， 历史上的矛盾和特别人物。评估会让你直接面对不安的问题情形。 评估绝对不应成为寻找过去问题的过错和责备个人的论坛。 进行评估可以表明管理层对于过程改进的一种决心和承诺。切记，要对评估所发现的问题和建议进行到底，否则，你就在浪费评估上投入的金钱和时间，并失去挫败的团队成员们的信任，他们会得出结论管理层对进行变革根本不认真。 评估通常识别了一大堆的改进机会，比你能够着手解决的要多的多。“焦点”就是过程改进中最关键的词汇。设计一个更好的过程并且将其变为团队日常工作方式的一部分所花费的时间比你想象的时间要长的多。我曾经遇到一个斗志昂扬的由20人组成的项目团队，在七个改进领域里同时推进改进。资源平均地分配在七个领域中，没有清晰的优先级，尽管很狂热， 但几乎没有成效。 按照你期望的经营成果来陈述过程改进的目标， 比如说，目标可能是“消除从开发阶段传递到系统测试阶段的不正确的构造版本”，而不是写成“软件构造版本递增规程”。SPI活动 而是达到某个目标的手段， 而不是以SPI本身为目的。你的经理应该能够清楚的表达，希望从SPI计划的成功中，看到小组成员的行为和结果发生什么样的改变。 对于那些最高优先级的目标，开始先选择两到三个目标进行改进。如果你很快地完成了这几个目标，很好，在从评估报告中选取下一步改进的领域。一次步子不要迈得太大，不要在刚刚起步时尝试太多事情。大的开发组织可以在多个项目中同时进行若干领域的改进，但是每个项目一次仅关注于很少的领域。 沟通，沟通，沟通 当要求人们变更他们熟悉的工作方式，他们通常感到不情愿，因为对于熟悉的方式（即使效率不高）感觉到舒适，而对于未知感到担心。考虑到繁重的过程负担会影响到创造性和和软件的按时发布也是普