软件过程改进经验谈

Scott

ityouke

2005年底CMM光荣退役。CMMI开始闪亮登场的。模型变了，但软件过程改进的核心思想并没有变。现就将从事多年的评估、咨询及辅导企业进行过程改进的经验和容易出的问题及经验总结如下，供那些正在和将要进行软件过程改进的企业及个人分享。
当然我不敢说这些经验完全是正确的，但至少它在我经历过的众多企业中是可行的。我也只期望能够起到抛砖引玉之效果就已满足。

经验1：淡泊名利，练好内功。在CMM/CMMI在中国大地盛行的时候，如果哪家企业没有个CMM或CMMI的头衔总觉得比别人矮了一截。因此，企业也是不惜重金要拿到这个证书。笔者就见过某企业为了取得某大型项目的投标资格而实施CMMI的例子。就企业的商业目标而言，这当然这也无可厚非，企业要生存，要取得市场份额。即使自己不愿去实施CMMI，你的竞争对手也会逼着你去做。通常报着这种态度实施CMM或CMMI的企业通过评估后，如果你问这个企业的员工：通过了评估，你觉得公司有了什么变化或不同么？答案往往都是“没什么感觉”！得到这样的答案也是在我的意料之中。

事实上，企业拿到了证书，只能解决企业的目前问题或实现企业的短期的商业目标。但是当所有的企业都具备了CMM或CMMI资质的时候，你还想拿什么与竞争对手比拼呢？因此，我在为软件企业提供咨询的时候，总会向企业领导及过程改进负责人宣扬这样一个理念：通过评估并不是我们进行过程改进的第一目标，我们是要进行实实在在的过程改进，最后使得“通过评估”成为我们成功地进行过程改进活动的顺带结果。企业要想长久发展，建成一个百年老店，练好内功才是真正的解决之道——我们输给别人，大都不是输在技术上，而是我们能否为客户生产高质量的产品，能否以最快的速度占领市场，能否花费最少的成本开发出最有用的产品。笔者在此提出“淡泊名利”，只是想让企业正确看待证书所带来的商业效应，做个名副其实的证书的主人。我们经常听到这样的新闻，某某企业率先通过了CMM或CMMI的某某级别的评估。笔者不禁要问：当企业通过更高级别的评估后，除了提高企业的外在形象，有可能拿到比以往多一点点的市场份额外，企业还得到了什么——评估过后，软件过程改进活动是否已经融入到了你的企业文化当中？原来定义完美的过程你们还有多少在坚持执行？也难怪现在的咨询行业也划分出了：管理咨询与评估咨询。从这点来看，我倒非常看好，那些“淡泊名利”的企业，这类企业的老总通常都有这样的心声：我们要过级，但我们更看重的是过程改进带来的效果。

经验2：过程改进贵在坚持。无论当前的过程多么缺乏效率，你都不可能在一天之内完成所有的改进工作。因此，我们在进行过程改进之前，考虑一下如何不被自己所面对的众多待改进的问题数量所淹没是非常有必要的。许多企业在进行过程改进时，总能够识别出许多待改进问题——项目计划编制不合理、缺少配置管理过程、项目进展情况不透明等等。此时，企业不可盲目地贪大求全，正确的做法是将这些待改进项逐一列出，然后根据其优先级别（此级别可以根据待改进项的紧急程度或待改进项可以增加的工作价值等等来进行定义）制定出改进计划。根据企业过程改进小组成员的能力来决定一次处理一个或多个待改进项，逐步进行改进，使它成为后续项目的例行实践。根据我的经验如果一个企业能够在一年之内完成2-3个问题域的改进就已经很不错了。

持续的过程改进——其思想在于我们希望在下一个项目中每个人都争取在工作的某些方面做得比上次更出色。已完成的（或已被取消的）项目应该进行明确的因果分析，总结经验。

团队和人个都应该在具体技术领域内设定改进目标，当改进后的过程被学习、应用和固化之后，它就变成了公司自己的标准实践或最佳实践。这时，你就可以继续进行下一个改进领域。一旦解决完所有的主要问题域，你就该回到自己所处理的第一个领域进行新一轮的过程改进。这一点在CMMI模型中的可重复级表现尤为明显。在改进的过程中，不断巩固现有成果，并能够将其应用于公司其他项目中，不断将其优化，最后将其提升为整个公司范围内的共同遵守的过程和标准。

在我几年前编写的一份《过程改进计划》中我这样写道：过程改进是一个永无止境，但却有利可图的旅程。这一原则的核心思想来自于SEI/CMU CMM或CMMI中的IDEAL过程改进模型。     

经验3：过程改进困难重重，做好团队及个人激励，减少改进阻力。要实现真正的过程改进，企业和个人都必须为此改变。过程包含企业文化，也包含个人行为。在一个致力于过程改进的公司里，每个人都肩负着改进的职责——或执行、或参与、或配合、或兼而有之。因此，争取企业内所有成员的投入，是成功实施过程改进的先决条件。如果企业内部不能够取得所有人对于过程改进的一致同意，那么企业的领导者不妨先试着与经理们达成一致意见，并制定出“最低的过程改进执行标准”，大家共同遵守、执行。历史文化价值深入骨髓的大企业往往会对“最低公共认可水平”孜孜以求。经理们不得不通过沟通、设定方向和定义远大的目标来行使领导权利，让改变发生。人们天生都拒绝改变，尤其是那些资深的软件工程师要让他们改变已经使用了多少年的编程方法或习惯，简直比登天还难，改进的阻力也由此产生。他们往往会有这样的说词：我现在的编程方法已经很好了，我的程序设计已经很合理了，我为什么还要改变？此时，执行改进的领导者必须学会如何引导和鼓励团队向新工作方式转变的过程。

为了有效的完成过程改进，企业的领导者有几个责任：
·培养员工，使他们理解为什么企业成功需要改变。
·寻找和理解存在阻力的真正原因。
·通过说服去赢得大多数员工的支持。
·为预期的改变提供恰当支持，其中包括成功实施新实践所需要的时间、培训和工具。
·调整项目进度，为团队成员提供实施改变所需的时间，从而表明确实重视变更的重要性。
·使高级管理层理解改变的必要性，并提供所能（和所必须）给予的支持。

我曾经的一个客户在激励方面做的比较到位。这个客户是福建省的一个大型企业，该公司的领导就曾做出这样的举措：在公司开辟关于过程改进的论坛，并按照参与过程改进员工提出建议及被接受的建议情况以及该建议达到的效果来给予奖励。组织级的改变涉及到的是优化现有的工作流程和定义新的工作流程，而个人的改变则是提高对过程改进的认识以及如何适应公司既定的开发和管理流程。在此我想再对组织级的过程定义说说我的看法。就我个人的经验而言，过程定义我更推崇的“自底向上”改进方法，这是种方法可以获取公司员工最广泛的支持，由于得到了员工的充分参与，就更贴近于他们的工作实际，他们也乐于接受和改变。同时，我们也需要让项目经理、技术骨干及中层领导参与过程定义。因为，一个公司过程执行不下去阻力也往往来自于这个层面。

此外，企业在过程定义的时候一定要做到过程的简单及可行性。如果你的企业不急于通过某些评估的话，请尽量使用这种方法。这样可以有效地避免员工“有法不依”现象发生。如果你是新员工，在就职的时候，EPG负责人就给你一套厚厚过程文档，然后丢下一句话：先学习一下这个再说。那我劝你趁早离开，因为他们的过程改进并未做到实处。一个过程改进做得好的公司，它会在新员工就职前或员工岗位调换的时候，根据公司定义好的岗位职责来识别你的差距，并根据差距分析的结果为你提供相应的过程使用、管理及技术方面的培训。让你感觉不到公司在做CMMI或ISO。因为公司已将这些思想溶合在员工的日常工作流程中。

经验4：过程改进要面向目标，用数据说话。为了改变而改变不会得到很多的拥护者。恰恰相反，你应该找出自己所期望的特定结果，它将为你指出那些为了实现这些目标而必须进行的变更。虽然最高管理层有可能设定整个企业的目标，但一线和二线经理应该负责让项目目标与企业目标保持一致。千万不要等到手中的定量数据能够证明每一点，并对全部工作论证之后才开始进行软件过程改进；如果那样，那你永远也不会开始。

你需要建立度量程序以量化当前问题域以及评估过程改变所带来的影响。如果每个目标都阐述清晰并且可以量化，你就应该能够断定自己何时达到了目标。例如，“减少交付给客户的错误修复数量”是一个有意义的目标，而且你很可能想出那些能够在你的环境中解决此问题的过程改变，但是这个目标并没有指明期望减少多少或希望何时达到这个目标。为了评估是否达到了这个目标，你需要测量当前的错误修复频率以建立一条基线，启动那些你认为将会生效的过程改变，并且跟踪新的错误修复频率以判断是否获得了成功。如果一次性对多个实践进行改进，你将很难分离出单个过程修改的效果。然而，如果你通过说类似“我们的项目跟踪是如此糟糕…”的话语来启动一个过程变更活动，团队成员就会齐声回答，“有多糟糕？”——你最好能有一个基于数据的答案。

避免在改进活动中采用教条化的方法并不意味着开发者可以完全自由地使用自己所选择的任何方法。在面向质量的文化中，最佳实践被所有的团队成员作为惯例接受下来并加以应用。有这样一个公开的规定；大家都必须使用那些获得一致同意的过程，任何希望例外的人都必须有非常充分的理由。

经验5：如果企业不想让过程改进失败，那就为其分配足够的资源。我们经常能够看到关于将过程改进需当成小型项目来对待的文章。这的确有它的道理，将过程改进活动当成一个小型项目来对待有以下几点好处：第一、可以明确职责。我常常会这样建议软件企业，成立专门负责过程改进的小组，并至少有一个专职人员作为该组的组长，全权负责软件过程改进活动。正如所有其他软件项目一样，每个项目组都有一个项目经理来为整个项目的成败负责，过程改进

如果管理层的参与仅限于说一句“就那么干吧”，改进努力极有可能会失败。过程变更是对组织的长期健康进行的一种投资。最终的回报有可能虽然达到8倍或更多，但过程变更并不是免费的。简单地要求员工把过程变更挤到工作日程中，但同时却不调整他们的其他工作是不现实的。像所有其他项目一样，改进的小型项目也应该以成功为目标来编制计划和安排人员。它们应该有确定的进度、明确的交付品、个人责任、中间状态报告以及团队奖励。在软件工程文化中，组织中的每个成员都会参与过程改进的小型项目。如果没有把它当成小型项目看待，并分配必要的资源，改进活动注定将以失败而告终。

如果你也很赞成软件过程改进，但是却为这样的理由所阻挡——“我们的团队没有任何多余的时间去做过程改进工作。现在我们正为了生存而竭尽所能。如果再进行过程创造活动，我们就不得不为赶上项目进度而加更多的班。”如果你也想把自己的企业做成像IBM那样的百年老店，那么我建议您不妨参考一下软件过程改进的这四条原则，并从现在就开始行动。对于软件企业来说，过程改进是为实现长期成功和生存而进行的投资。正如任何其他类型的投资，这种投资也存在风险，投资所占用的资本（时间、资金和人力）也无法再用作其他用途。只要进行这种投资，仅需把5%的精力投入到提高质量和生产力的活动中，软件组就能够得到数倍的投资回报。

如果你的企业正在为落后的项目进度、低劣的产品质量和高额的开发和维护成本而大伤脑筋，那就有进行过程改进的必要了。的确，当你的团队将一些时间用于培训和开发更好的过程时，你将不得不在项目进度方面做出一些短期的牺牲。但如果不进行这种投资，软件过程能力的质量和生产率的提升就只能非常缓慢。过程变更能帮助你避免折磨着很多软件企业由于进度滞后和交付错误组成的恶性循环。

记住：每个软件企业都有可改进之处。除非你的企业一直都生产着满足客户需求的无缺陷软件、总是能跟上进度、从来都不超出预算。


上一篇：同级评审的陷阱
下一篇：QA活动的理解与实施

Scott

steplv

谢谢分享，确实是这样，企业需要改进的地方很多，有文化方面的、有销售方面的、有战略方面的、有商务方面的、有行政方面的、有财务方面的……等等。

也就是说：我们不仅仅从研发这条线去动脑筋，更要从全面的角度来思考，要有全局观、整体观。当只有把软件过程的改进与企业其他方面的改进很好的结合在一起的时候，那就是我们企业开始走向成熟的时候。

我们一起超这些方向来努力，相信，总有一天，我们每个人都是高成熟度的，我们的企业也是高成熟度的。

冰封伯爵

这些经验真的很有用，我现在做过程改中碰到一问题，就是上面所提到的“自底向上”的问题，公司除了老总外，公司其它成员对过程改进默不关心，不配合，高层发话，也都是一拖再拖，最后不了了知，现在老总和我都比较烦，不知该如何办，希望大家能帮忙解决，如果能给出比较的方案，将万分感激。

iamredeye

答案很简单，做起来很复杂。想要bottom up的话就不能总是有领导层把答案抛给大家，要引导大家一起找到答案。

haiyun0312

赞成，定义过程一定要简单可行，这样才容易成为惯例，容易坚持下来

iamredeye

原帖由 冰封伯爵 于 2008-4-16 14:50 发表
这些经验真的很有用，我现在做过程改中碰到一问题，就是上面所提到的“自底向上”的问题，公司除了老总外，公司其它成员对过程改进默不关心，不配合，高层发话，也都是一拖再拖，最后不了了知，现在老总和我都比较烦 ...

在这种情况下，你们公司的SQA肯定是使不上劲的。我发的帖子“砸场子的来了～：SQA有啥用？ ”其实很大程度上也是针对这种项目成员对“流程”或“质量”话题不感冒的公司。http://www.step365.com/bbs/thread-486-1-1.html

hejunxieping

我也有同感，觉得CMMI在公司实施起来是比较困难的

qkmmmm

学习学习，这两天正在做过程改进，完全没有头绪，这些经验真的很有用。

童心小镜子

很有见地的探讨，先收藏着~

东方聊天

很有借鉴意义，先收藏了，谢谢楼主。

一个芣咋

我是个凑数的。。。

地势坤

我是个凑数的。。。