关于如何在小型组织中推行CMM(DOC11)(1)

1、如何在小型组织中推行CMMCMM SM 是适用于小工程项目和小规模组织的经剪裁的CMM 版本。而 CMM V1.1 是用适宜于那些和政府签约的大型组织的标准实践来表达的，这些实践必 须剪裁才能适合不同于这个样板的组织的需要。摘要有关在小工程或小组织中应用 CMM 的一些常见问题包括：什幺样的才算做“小”？标准是根据人？时间？项目大小？还是产品的艰难复杂程度？什幺是 CMM 的“需求”？是否有不该被应用到小项目/小组织中去的关键过程区域或 目标？有好的过程“ 不变量”吗？造成 CMM 被滥用的驱动力和动机是什幺？ 这篇论文以小型组织为例讨论了怎样在各种商业环境中正确而有效地使用CMM。作者简介M

2、ark 是美国软件工程学会（SEI）的一名技术人员。他 1987 年加入 SEI ,最初参与的是 软件能力评价项目的工作。 Mark 从一开始就工作在软件能力成熟度模型方面，并且是开 发 CMM1.1版本时的项目领导人。他也一直活跃在制定有关软件工程的标准上，这些标准包括：ISO 15504 （ 也称为 SPICE-软件过程改进和能力决断 ）,一整套软件过程评估的国际标 准ISO 12207 , 软件生存周期过程ISO 15288 , 系统生存周期过程在加入 SEI 之前，Mark 是系统开发公司（System Development Corporation，即优利国 防系统公司 Unisys

3、 Defense Systems 的前身）的位于亚拉巴马州 Huntsville 的弹道导弹 防护高级研究中心（ Ballistic Missile Defense Advanced Research Center ）的一名高级系 统分析员。Mark 在范德比尔特大学获得了他的计算机科学硕士学位。在 Huntsville 的亚拉巴马州立 大学获得了他的数学和计算机科学学士学位。专业资格及证明电子学会高级研究员及电子工程师（IEEE，美国电气及电子工程师学会）美国质量协会高级研究员（ASQ，美国质量协会）美国质量协会（ASQ）认证软件质量工程师提供了路标。CMM 定义了怎样使开发组织的软件过程走

4、向成熟的5 个等级的框架结构。这些等级描述了从特别紊乱的混沌过程到成熟的、有纪律的软件过程的进化路径。CMM 在称心如意地实施管理及工程实践方面， 都提供了良好的建议， 它强调以人为核心 的管理、沟通和协调以及能体现软件开发和维护特性的强化设计的过程。无论如何，把 它看成灵活的指南而非生硬的指令吧， 还有对于软件工程和管理， 以及应用领域和组织 的商业环境等方面，CMM用户必须能够在这些方面应用其基于知识和经验的专业判断。因为 CMM 聚焦于软件， 所以 TQM的一些重要方面不能直接照搬到模型里，比如系统工 程里的“人的问题( people issues )”和“较宽泛的审视( broader

5、 perspective )”，这些 在商业上可能是至关重要的。 CMM 应该被看成使用在软件过程改进系统步骤里的一种上 下文工具，比如 SEI 的 IDEAL 模型，如图 2 所示McFeeley96。/ / TQC abbr . 全面质量管理 (total quality control) 在对软件过程改进的讨论中， 开始的问题总应该是这样的： 为什幺软件组织会对使用 CMM 感兴趣？如其愿望是以直接依从商业目标以及心甘情愿投身改革而来改进过程，那幺CMM 确实是效用非凡、功能强大的工具；如果 CMM 只被当成单纯的短期时髦，那可真 是把一剂糟糕的药方拿到了手。如果驱动力是客户利益，理想情

6、况下客户利益将导致客 户和供应商之间协作的改进。 有时供应商的利益集中在软件能力评价 (Software Capability Evaluations ， SCEs)上，如此则可在那些来源选择及签约监督方面是由政府获 取代理的项目上有所表现。国防部在执行软件能力评价(SCEs)标准的政策上是排斥绝大多数小组织和小项目的 Barbour96 ，但也存在它们可以有所作为的机遇。很多 CMM 的滥用都对“其它人”可以做什幺的担心置于不顾。如若一个开发组织能在用 CMM来导引胜过被需求来牵引上达成共识，那幺在模型中要解决问题的很大一部分就化解掉了。有很多这样的案例。尽管如此，那些对于好的工程和管理实践

7、的无知仍将成为 问题。对于那些只有很少的管理方面的经验和训练而只是因技术优秀就被提拔到管理层 职位的人来讲，问题是显而易见的。由DOD (美国国防部)特种部队确认并提出的问题是 DOD87 ：“少数区域在最佳当前实践和平均当前实践之间有着如此巨大的缺口。”“大问题不在技术方面现今军事软件开发的主要问题不再是技术问题， 而是管理 问题。 ”2. 小组织和小项目本篇论文的焦点对准了在小组织正确而有效地使用CMM，因为经常有人问我，“CMM 是否能被用在小项目 (或小组织)？”然而有关“小”的定义却是模糊难解的，如表1 所示。在某段时间里我们致力于为小项目和小组织而开发出剪裁适当的CMM，1995

8、年 CMM 剪裁工作室的结论是我们甚至不能对什幺才算“小”的真正含义达成一致意见！这个结果 得出了一篇更注重于“如何剪裁 CMM”而不是“已为小组织而裁好的 CMM”的报告Ginsberg95。1998 年 SEPG 会议关注于 CMM 及小组织上，“小”被定义成“ 5 个或更 少的人为期 3 至 4 个月的开发”。 Brodman 和 Johnson 则定义“小组织”为少于 50 个软 件开发人员并且“小项目”为少于 20 个开发人员 Johnson98 。表 1. 定义一个小项目 小的变体 人数 总的时间 小 3-5 6 个月 很小 2-3 4 个月 微小 1-2 2 个月 个人 1 1

9、星期 荒唐！ 1 1 小时注意从小到微小的项目是在被 Humphrey 称为小组软件过程( Team Software Process，TSP)的范围里，而个人的开发努力则在个人软件过程 (Personal Software Process，PSP) 的范围里Humphrey95。TSP 和 PSP 阐明了 CMM 的概念是如何应用到小项目中的。“荒唐”变体则描述了一个解释性的问题。在两种场合里，变体都会被论述，问题是“项目” 的定义。两种情况下它都是个维护环境，而且组织的“项目”将被描述为CMM 的任务；更多关于 CMM “项目”的精确解释是一个基线的升级或者维护的发行但术语的冲突 会将其搞

10、乱。对于那些使用 CMM 的小组织来说，首要的挑战就是其主要商业目标要能存活下来！甚至在决定之后，现状是不能令人满意的而且过程改进也将有助于发现资源并为过程改进分 派职责 ,接下来通过制定与部署过程所要做的是一项艰难的商务决定。小组织往往相信：我们全都是胜任的一一人们是被雇佣来做工作的，我们可不想负担那些要在雇佣期间 进行培训所花的任何时间或金钱。我们全都彼此沟通因我们是如此紧密地在“渗透式”工作。我们全都是英雄好汉我们无论做任何需要做的事情，规则都不适用于我们（这些 恰恰达成了将工作完成的方式） ，我们承受住了短周期及高压力。然而对于小组织，也正象大组织一样，有着非文档化的需求所带来的麻烦，

11、以及无经验 的经理人员、资源分配、培训、同行评审和产品文档等方面带来的问题。尽管有着这些 挑战，小组织仍能非同寻常地进行创新和提高生产率。尽管有一大把需要人们去解决的 大块问题，通常小组织比大组织更具生产效率，他们能更敏锐地成形生产要素并且远远 更少见有沟通方面的问题。无论如何，遗留下来的问题是，小组织也需要过程纪律吗？ 回答这些 CMM 咒语,我们需要考虑到纪律包括了什幺？而那将引入这篇有关 CMM 指导性 课题论文的核心。即便如此， 评估小组织时运用最新式的评估过程是明智可取的。 为期两周的 CMM 内部过 程改进基础评估 （CMM IPI） 的形式也许是多余的 Strigel95, Pa

12、quin98, Williams98 ，甚至 会由于缺乏监控而导致某些遗漏，而关键是有效地确认重大问题。我建议将注意力集中 在建立在企业文化上的制度化实践方面：如规划、培训等等，并确切地将过程改进落实 到商业需要上。3.解释 CMMCMM 都适用在什幺地方呢？ CMM 是按照在任何环境中为任何项目都能提供良好的软件工程和管理实践来塑造的。模型是被分层次描述的：成熟度等级 （5）- 关键过程区域 （18）- 目标 （52 ）- 关键实践 （316 ）- 子实践和例子 （ 许多 ）根据我最近十年来在软件过程工作方面的经验，阐述的环境以及CMM 的剪裁需要包括：非常大的程序虚拟项目或组织地点上分布式

13、的项目快速原型法的项目研究及开发组织软件服务组织小项目和小组织对于小项目和小组织的解释性指导也同样适用于大项目和大组织。在正确有效地使用CMM 的过程中，智能和常识是必要的Paulk96。所有（软件）项目都有所不同，但所有（软件）项目也都有所相同这可全都是真的。我们必须平衡现实：相似与唯一，秩 序与混乱。那些成功所缔造出的持久组织 Collins94 是真正有能力的学习型组织 Senge90 ；此外在其它地方也必须得益于其成功。CMM 的标准构件是成熟度等级、关键过程区域和目标。CMM 的所有实践都是有益处的。既然那些详细的实践都首先支持大型签约的软件组织，也就没必要正好写成是直接适用 于小项

14、目和小组织然而它们同样提供了如何达到目标和可重复地实现已定义的、规 范的、不断改进的软件过程。这样就会避免了过程评估方式上的简单武断诸如“去 问老张吧”。我最通常的指导性建议是开发出一套适用于组织的置于CMM 术语和语言间的映像。特别地,组织结构的期限行为、角色、关系以及过程的形式都需要映像到其组织的相应部分， 以防止出现无法理喻的事情，诸如“荒诞的一小时项目” 。组织结构的例子包括诸如质量 保证、测试及配置管理等“独立小组” 。应该用术语明确地指定适当的组织角色，诸如项 目经理及项目软件经理等。人们可以担当多重角色，例如，一个人可以同时做项目经理、 项目软件经理、软件配置管理（SCM）经理等

15、等。明确规划好这些，将生发出对 CMM 更 生动简洁也更协调一致的阐明。一旦术语问题被理解了， 我们就得考虑什幺是守纪律过程的 “不变量” |here| （ invariant ， 一个必须永远为真的约束） 以及哪些实践依赖于上下文关系。 除了软件转包合同管理 （即 若无转包合同的话就可能成为“不可用的” ），一般来说我们总是假定关键过程区域及目 标关联到任何环境。我想象不出同行评审被等级 3 的组织适当剪裁掉的情形。尽管所选 择出的实践（诸如正式方法）可以替代同行评审，但这还是一个需要足够专业性判断的 问题。拥有专业性的判断和训练、经验丰富的评估人员是至关重要的，甚至对小组织也 一样！ Ab

16、bott97我从没见过下列哪个环节是不必要的 （尽管实现方式不同 ）：将客户（系统）的需求记录成文档与客户（并且最终用户）沟通 同意承诺并签约 计划文档化过程工作细化结构当然，一些实践都被处理成了“大项目的实现” 。小的项目未必需要软件配置管理组或者 变更控制部门，然而配置管理及变更控制总还是要有的。一个独立的软件质量保证(SQA) 组也许不是必要的， 但目标的认可始终是需求要被满足。 一个独立的测试组也许没 必要设立，但测试总是必要的。即使小组织和大组织之间的实现有着根本的不同，但我 们看到对于上下文相关的实践，其意旨是建设性的。如果有人读到CMM 所定义的“组”它是被陈述为“一个组可以是被

17、分派兼职的单独个人、从不同部门分派了几个兼职的个 人，也可以是全职的几个个人” ，这里就有意迎合了环境的变化。除了这些 , 一些特殊的问题再三地出现 , 尤其是对于小组织，涉及有：管理资助度量软件工程过程组 (SEPGs， Software Engineering Process Groups) “不保修”过程文档化过程 剪裁 培训风险管理计划同行评审 获取高层管理的赞助是构建组织能力的关键成分，这看起来固然很陈腐老套。做为个体，我们可以在我们可操控的范围内磨练自身的专业素养及自制能力。 可是若要一个组织作 为一个整体来改善其效能，那幺其高层管理就必须积极地支持变革。由下至上地改革， 无须赞助

18、和协同， 却能够导向超过可预期改进的组织能力的胜地，这可真是奇闻了。 即 便如此， 当总裁(或者公司创始人)是主角时， 敬重“冠军”往往是具有撼动整个组织 的影响力的包括总裁本人。对于大多数组织而言，管理实际上是必须基于一个度量 基础的范例转换。掌握有用的数据，就是说你必须了解性能数据的含义以及如何有价值 地去分析它。从收集简单的有用数据开始，你也不得不敏感于经由度量而导致紊乱行为 的潜在因素Austin96。度量活动要确认什幺是重要的，但一些事情是难于度量的。管理 需要确保注意力倾注在项目的所有可评价方面，包括那些难于度量的，而不仅仅是那些 易于度量和跟踪的。在大多数组织中，软件工程过程组(

19、SEPG)或一些类似小组应该成为协调过程定义、改进 及部署活动的工作组。把资源奉献给 SEPG 的原因之一是要确保完成评估调查。许多改进纲要仅仅因为有着不是从评估所导致的行动而失败。小组织可能没有全职的 员，但改进的职责应该明确地加以指派和监控。起始于“不保修” (as is)过程，而不是“合理” (should be)过程-对于有效实施的实践与对指派任务的抵触来说，这相当于两者之间的杠杆，此起彼落。要求自上而 下的每个人都遵循的“合理”过程，若其显着地不是由被授权的工人所参与开发的，则 将是一个通用的失败处方。 “不保修”过程进化的理由是人们从事工作是希望工作任务能 被完成(即使那意味着要整

20、天围着系统转) 。“合理”过程或可行，或不可行只有在 特定的文化环境中才能成为可行。伴随着过程管理和改进的组织焦点， “不保修”和“合 理”过程将聚合在一点即导致有组织地进行学习。 文档化你的过程。 文档化地记录一个过程 (或产品 )的原因是1) 沟通给别人一个当前的交待以及给自己一个今后的备忘；2) 理解如果你不能写下它，你就不能真正理解它；以及SEPG 人3) 鼓励连贯一致性拥有可重复的优势。文档化过程支持有组织地学习以及避免重复地打造解决通用问题的车轮(车轮在任何地 方都被置于一个反复重用的过程) 。归档是如此重要，但有用的文档最好不要冗长繁杂。 我们生活在一个迅速变化的世界里，请保持文

21、档简洁吧。过程也不要冗长繁复。CMM 关注做事(doing things ),而不是成事(having things )。一个 1-2 页的过程说明是 足够了，子过程和步骤能按需调用就行。运用好的软件设计原则，比如在定义过程中使 用内存空间的局域性、信息隐藏以及抽象。另外的实用经验是每周最多跟踪 2-3 个任务 的工作。其顺序应由少量指导性原则或法则所确立，而不是由复杂的控制来确立 Wheatley92, page 11 。过程需要剪裁到项目所需的程度 Ginsberg95,Ade96 。虽然标准过程提供了一个基础， 但每一个项目也都将有其独特的要求。剪裁时不切实际的约束可导致执行过程中的重大

22、 阻力。正如Hoffman 所表述的，“别生造感悟也别强求过程。 ” Hoffman98过程所需的形式化程度对大组织和小组织都构成了威胁 Comer98 。对于那些每每提到要 “按照文档化步骤” 的等级 2 的 25 个关键实践中的每一个， 应该存有很个别的步骤吗？ 答案正如在 CMM 书籍文档和 CMM(Documentation and the CMM) 的 4.5.5 小节所论 述的，是一个响亮的“不！ ”文档的包装是组织化的必然结果。文档化的过程如果没有加以有效地部署，只会具有很小的价值。要想达成文档化的大量 买进，过程实现必须成为过程定义和改进的一部分。通过多种机制的培训，对于协调一

23、 致和效力非凡的软件工程及管理将是建设性的。培训的动机是发展技能。有很多“培训 机制”不同于能有效培养技能的正规课堂培训。其中应该被认真考虑的是正规的顾问制。在此情形下，形式化意谓着寄希望于没有经验的顾问。形式化提示要在如何指导及监督 顾问的效力上训练人们。在过程或技术的最初部署之后，培训仍然是一个问题 Abbott97 ， Williams98 。当人员变 动时，培训所增加的需要可能不会被充分地认识。顾问学徒制能充分地解决这一问题，但是除非能谨慎地加以监督，否则不能设想会有满意的结果 管理上的培训是特别重要的，因为低下的管理会削弱一个好的团队。那些因其技术技能 而被提拔到管理层的人，将不得不

24、重新学习包括人际关系在内的一套新的技能 Mogilensky94, Curtis95,Weinberg94 。软件工程管理的部分论题确实是风险管理。感觉上， CMM 就是关于管理风险的。我们致 力于确立稳定的需求，以便能有效地实施计划和管理，但商业环境总在迅急而紊乱地变 化着。我们尝试在软件那混沌的大海里建造秩序的孤岛，但是秩序和混沌都自有其位置。 Wheatley 建议，“为了生存， 开放系统维持在一非平衡状态， 保持系统均衡以便它能改 变和成长。 ” Wheatley92,page 78尽管我们能确立帮助我们管理混沌世界里的风险的过 程，我们也需要变化和成长。这意味着你应该使用一个增量的或

25、进化的生存周期。如果你想重心集中到风险管理上， 螺旋模型将是首选的生存周期模型。如果重心集中在笼络客户上，可能快速原型法或接 合应用设计更好一些。少数长期项目对稳定环境的奢求是必要的，对其瀑布生存周期将 是首选可能它仍是最普遍通用的生存周期。注意，无论如何，对于小项目，瀑布生 存周期都会是一个极佳的选择。成功的过程定义和改进的头号因素是“全程计划( planfulness )”Curtis96 。计划是每 一个主要软件过程都需要的，但不外乎绑定合理的判断、由组织决定什幺是“主要的” 以及怎样包装计划。一个计划可以驻留在几个不同的工件或被植入一个大计划当中。即使你可以对最好的同行评审有争议，但简

26、单的事实是同行评审带来的好处远远超出了 其成本。数据表明一些检测表格应该是惯用的 Ackerman89 ，但任何学院式或严格的评 审表格，诸如结构化预排，都附加了重要价值。不幸地，认可同行评审并不意味着我们 在系统地做着这件事。我们需要“走在路上” ，而不仅仅是“说在嘴上” 。这对技术人员 来说是很大的挫折，他们不理解 CMM 所强调的管理，然而糟糕的管理会导致放弃好的工 程实践，比如同行评审。另外还有其它被确定为是小组织和小项目的问题， Paquin Paquin98 认定了下面的 5 个：评估工程焦点 文档需求功能成熟度提问单我们没有讨论等级 2 的项目焦点对小组织构成的挑战。软件过程改进

27、包括了那些对小项 目而言是过度的开销。一些劝告从组织化观点来攻击恰似混合了等级 2 和等级 3 而又的 确不失为合理途径的小项目的过程改进Comer98 , Paquin98。CMM 本就是为任何规模 的组织或项目而考虑的Paulk96。尽管无须过程焦点一个组织也能达到等级 2,但极其 高效的组织化学习的策略将成为减少项目开销的组织资产的一个重点。同时，必须认识 到项目等级的改变可能会形成多半是基于正当利害关系的阻力,而且探察阻力时需要考 虑组织进行学习过程的那部分。需求功能是一个问题, 因为比起人来可能有更多的 CMM 功能。这个问题是做为技术或角 色的映像来讨论的。 成熟度提问单因使用 C

28、MM 技术而成为关注焦点， 它可能在填写的过 程中被搞乱。以组织的技术来表达提问单,甚至对于非正式的评估及度量也是很需要的 先导。AbbottAbbott97 指明了对于小组织的软件过程改进的 6 个关键：高层管理的支持正确的用人原则将项目管理的法则应用到过程改进与 ISO 9001 的集成来自过程改进顾问的协助聚焦在提供项目上及商业上的价值如果将好的项目管理应用到软件项目中是确保成功的最佳途径，那幺应该象对待其它任 何项目一样来对待过程改进就同样是正确的。 ISO 9001 是在大组织里比小组织里使用更 频繁的一个评估版本，因而 Abbott 也有兴趣针对他的小公司指出这一点。Brodman

29、 和 JohnsonJohnson98 认为针对小组织 /小项目的挑战有 7 种：处理需求生成文档管理项目分配资源 度量过程促导评审提供培训Brodman 和 Johnson 开发了一个针对小型商业、组织和项目的 CMM 剪裁版本Johnson96,Johnson97, Brodman94。尽管如此，大多数 CMM 的关键实践还是被剪裁到了LOGOS 剪裁版 CMM里，变化体现在：已存实践的净化 明显的夸张 选择性实践的介绍 （特出地作为例子 ）伴随小商业 /小组织 /小项目的结构及资源的实践调整因此针对小组织而剪裁 CMM 的相关改变是可以根本不予考虑的。4. 滥用 CMM正确使用 CMM 意味着要平衡相互冲突的目标。基于 CMM 的评估要求运用专业性的判断。 尽管如此，CMM 在做出这些判断以及消除对一个明确的、反复的、非设计工作特有的过 程的主观臆断等方面都提供了大量的指导。 CMM 有时作为一整套过程需求被提及， 但它 不能有任何含有“将要”（shall）的语句。这就是在核对（子）实践一致性时造成 CMM 滥 用的原因。有些是勉强地、无能地去解释、剪裁或应用判断力。这是易于委派到关键实践的，但却 愚笨透顶。此种蠢行常常由客户意图及能力的偏执来驱动。我在更多的场合听说某人要 做某些傻事