作者：任甲林
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
术以载道——软件过程改进实践指南试读：
前言
本书写作的目的
本书总结了我12年的软件开发与管理经验、8年多的过程改进咨询经验，记录了我所做、所思、所见与所闻，希望本书能够给从事软件过程改进、软件企业管理咨询、软件项目管理、软件开发的人士提供一些具体实践的借鉴与参考。
本书读者对象
● 过程改进与质量管理人员。
● 项目经理。
● 软件企业的中高层经理。
● 软件开发人员。
如何阅读本书
本书共13章，每一章的主要内容与适用的读者如下表。续表
本书编写体例说明
正文中重点强调的文字采用了黑体字。
所有的案例全部加框并用楷体排版。
致谢
感谢我的计算机启蒙老师吕云龙先生。从1986年高中入学时，就跟着您在Apple及中华学习机上学习Basic语言，您带领我参加信息学竞赛，训练了我的逻辑思维能力。和您一起在泰安、长岛度过了2个愉快的假期，情景历历大目。
感谢我的大学母校山东师范大学。为我大学 4 年提供了宽松的上机学习环境，在机房上机的日日夜夜，极大地提高了我的动手能力。感谢我的指导教师刘芳爱老师，在您的指导下我在大学里完成了编辑器软件的开发。
感谢对我一生的做事风格影响最大的王虎老师。从1993年到2004年，11年的时间里从您这里我学到了做人、做事的方法，您对我的教诲与爱护让我受益终生。
感谢在1998年指导我做过程改进的郑玉林老师。您的认真让我感慨至今。
感谢 2004 年引导我进入 CMMI 咨询行业的周伯生老师。和周老一起做评估，是我最快乐的日子，周老的睿智、对问题的敏感，周老的软件工程经验、不懈的奋斗精神，一直是我奋斗的标杆。
感谢以长虹集团、富士康集团、TCL、大连飞创、北京体彩、山东中创、南京润和、中海信息、浙江中控、深圳酷派、天源迪科、厦门联想等为代表的忠诚的客户。通过和大家一起成长，我学到了很多最佳实践，激发了我的灵感，积累了大量的案例。
感谢我的同事吕英杰、周伟、刘军、徐栋哲、Bruce、王婉荣、徐浩伟、洪艳艳、王新华、柯能江、关钦杰、雍迪、温丽莎等。大家任劳任怨地帮我做了很多工作，在和各位的沟通交流中，校正了很多我的错误观念。
感谢我的家人。你们承担了所有的家庭事务，在我“有工作，没生活”的状态下，帮我消除所有的后顾之忧。
谢谢你们！
关于勘误
尽管我花了很多时间和精力去核对书中的文字，但是因为时间仓促和水平有限，可能对某些错误熟视无睹，本书仍难免会有一些纰漏。如果大家发现什么问题，恳请反馈，相关信息可发到我的邮箱renjialin@measures.net.cn。
对于本书中的任何疑问或想与我探讨，可以访问我的个人博客：http://blog.csdn.net/dylanren或者直接在我公司的网站上进行实时沟通：www.measures.net.cn。第1章CMMI 实施精要1.1 对CMMI 的基本认识1.1.1 CMMI 是什么
CMMI 是Capability Maturity Model Integration 的缩写，译成中文称为能力成熟度集成模型，或者更通俗地称为集成的能力成熟度模型。CMMI 的前身是SW-CMM（SoftWare Capability Maturity Model），SW-CMM 是美国国防部委托卡内基梅隆大学软件工程研究所（SEI-CMU）开发的用于评价软件开发组织过程能力的模型。SW-CMM 1.0 版本发表于1991 年，两年后发布了SW-CMM 1.1 版本，该版本成为CMM 历史上最经典的一个版本，长达13 年的生命力，直至2006 年，SEI 宣布CMM 1.1 版本“太阳下山”。2000年12月SEI 发布了CMMI 1.0版本，随后CMMI 1.1 版本也成为一个影响巨大的版本，CMMI 1.1 是集成了SW-CMM，SE-CMM（系统工程能力成熟度模型）、IPD-CMM（集成产品开发能力成熟度模型）之后发展而成的一个版本，在CMMI 1.2版本之后又划分为 CMMI -DEV+IPPD、CMMI -ACQ、CMMI -SVC三个系列，分别应用于开发类（包括集成产品类）、采购类、服务类组织。2010 年11 月发布了CMMI 1.3版本。相对于CMMI 1.2版本，1.3版本增加了对于敏捷方法和产品线管理等新技术的描述，吸收了很多敏捷的实践，并且对于高成熟度的实践进行了细化说明。
CMMI 是一个过程框架，给出了一组管理企业的最佳实践。何谓框架？比如我们走在马路上看到一幢正在建设中的高楼，建筑者浇灌了水泥，搭筑了整个大楼的基本结构，我们看到了整座楼面的概貌与主体，但并不是一幢装修完整的楼，在这个框架基础上，我们可以进行后续的加工定制，使其成为各式各样的漂亮的楼。
在CMMI 中定义了一个企业（注：为通俗起见，本书中以企业指代各种组织，如公司、研究所、技术中心等之类）要管理的各个过程域，正如我们定义一幢楼的各个子系统一样，比如一幢楼有电梯系统、照明系统、供水系统等等。CMMI 中也定义了每个过程的核心实践，正如我们定义了建设照明系统的最佳实践一样。
何谓最佳实践？就是得到业内认可的、多家成功企业的成功做法。
为什么判定这些实践是最佳的呢？因为多家成功的企业都是那么做的，并且获得了成功的。前车之鉴，后车之师。
是否存在你认为是最佳实践，而我认为不是最佳实践呢？CMMI 中的最佳实践是美国卡内基梅隆大学软件工程研究所（全球最好的软件工程科研机构之一，自2013年1月1日起专门成立了CMMI 研究所）组织了很多来自工程界与理论界的高手一起讨论总结出来的，是经过了多次评审得到的共识。如果你有证据表明确实有更好的实践，你可以认为它们不是最佳实践。
是否高手们认可的最佳实践就适合我们的企业呢？未必，但是应该基本适合。之所以说未必，是因为每个企业有每个企业的特点，别人的成功实践在你的公司未必能够完全对症。之所以说是基本适合，是因为这些实践是抽取了成功企业的共同点、共同实践而得到的，应该能够以很大的概率适合你们公司的情况。
如果不适合你的企业怎么办？裁剪！只有适合你的才是最好的！
如果裁剪了就不能满足CMMI 模型的要求，怎么办？CMMI 模型中的要求分成三种严格程度。（1）必需的。目标是必需的，即无论你如何做，只要满足目标即可。怎么判断呢？经验判断！谁来判断？评估时的评估组成员！评估组成员累计的工程经验（除主任评估师以外）要超过25年才可以。在评估时只要有评估组成员都一致同意才可以（都同意或大部分同意、有个别人保持中立，没有人反对）。灵活吧？CMMI 不是死的，不是刻板的，做得刻板了不是CMMI 的错，是你没有理解CMMI 的要求，不能因为你刻板，而说CMMI 不好，这是社会上很多人常犯的错误。如果主任评估师不同意怎么办呢，讨论啊。主任评估师也是有经验的人，是懂工程实践的人，是经过严格选拔与培训的，是讲道理的。如果真不认可你的做法，要么你的实践确实有问题，要么你被冤枉了，这是小概率事件，哪个庙里都有冤死的鬼。（2）期望的。实践是期望的，所谓期望，是说你最好那么做，你不那么做也可以，但是你要证明你的替换做法是可以满足目标要求的。怎么判定是否满足了目标要求？同样也是由评估组成员进行经验判断。（3）参考的。子实践、实践的名字、目的描述、对目标与实践的解释说明、文档案例、注释、参考、共性实践的细化说明、其他案例等，都是参考的说明，是解释性的资料。但是，需要注意的是，SEI 认为很多企业没有理解模型的要求，是因为没有关注CMMI 中这些参考的解释性说明。
CMMI 模型每 3～5 年就会发布新的版本，为什么？与时俱进！最佳实践在今年是最佳，明年就可能不是最佳了，出现了更好的实践，也需要吸收进来。
以上是解释最佳实践的相关含义。再返回来说说框架的含义。如图1-1所示，在这个框架中，还有很多东西都是空的，等待补充、等待装修，模型应用到每个企业后需要各个企业补充完善那些空白。用什么去补充完善呢？用你们公司的实际做法，用你们公司能做到的做法，用敏捷的方法，用ISO，用什么都可以，只要你能满足“必需的”！CMMI 并不排斥其他的最佳实践，在满足“必需的”前提下，什么都可以！还是那句话，CMMI 是活的，不是刻板的。有最低要求，有可变通的要求。图1-1 现实中的框架1.1.2 CMMI 里有什么
CMMI 模型分为三个分支。
适用于供方、乙方的模型如下：
CMMI -DEV：主要是针对开发类组织；
CMMI -SVC：主要是针对服务类组织；
适用于需方、甲方的模型如下：
CMMI -ACQ：主要是针对采购类组织。
CMMI -DEV 提到的开发，是包括了软件、硬件等类型的开发。CMMI -DEV 模型还可以适用于复杂多学科产品开发的IPD模式，在CMMI 之外称为IPD，在CMMI 之内称为IPPD。IPPD并没有涉及市场、财务等。多出来的一个P代表过程，IPD中包含了市场与财务，所以IPD与IPPD是有一定差别的。IPPD有其适用范围，IPD也是同理。国内有些企业盲目追随华为实施IPD，成功者少，失败者众。为什么呢？没有注意IPD的适用范围。IPD适用于以下范围。（1）复杂产品的开发，需要多学科配合协同的产品开发。（2）市场驱动的产品开发，产品需要随时判断是否满足市场需求，投入产出是否合适，如果不可以，需要随时终止产品的开发。（3）项目团队规模比较大，需要划分为多个小组进行协同工作。小组之间的沟通是项目成功的一个制约因素。
CMMI 模型在1.1 版本中对IPD 的支持包含了 2.5个过程域，在1.2 版本中是通过描述的附件来支持，在1.3版本中则直接融合到了OPD和IPM这2个过程域中。
CMMI -DEV 包含了22个过程域。何谓过程域（Process Area，缩写为PA）？过程域是一类最佳实践的集合，这些最佳实践属于同一类过程。CMMI 中有167条特定实践，264条共性实践，需要将它们分类管理，以便于实施，便于记忆。分类方法是人们分析、认识问题的一种主要的方法。CMMI 将所有的实践划分成了22类，每一类包含的特定实践个数从4个到 14个不等。这种分类是否就完全合理呢？仁者见仁，智者见智，没有绝对的合理，有的实践放在某个PA中很自然，有的就有点牵强，CMMI 就那么划分了，你就那么记忆吧。
要注意过程域与过程的概念不同，过程域是实践的集合。何谓集合？集合中的元素是没有严格的先后顺序，是一个堆（堆是数据结构中的专业术语）。过程是活动的偏序集（偏序关系是离散数学中的专业术语），活动之间是存在先后顺序的。不要搞混了这两个概念，否则是很囧的。
22个过程域分成4大类，项目管理类、过程管理类、工程类、支持类，其核心内容见表1-1。表1-1 4类过程域续表
通过表 1-1 我们可以看到，CMMI 模型中包括了很多开发活动。没有包括什么呢？没有包括考核，没有包括市场，没有包括财务、行政、人事等其他非开发管理活动。对于开发活动是否都包含全面了呢？项目立项、技术预研、系统维护等活动并没有描述在里面。没关系，立项、预研、维护的活动都可以分解为上述PA中的活动，也可以认为是含在里面了。
每个过程域有其名称与简写，一般我们都称呼其简写，比如一说REQM就知道是需求管理过程域，一提DAR就代表了决策与解决方案过程域。不一定要刻意去背诵它，知道每个缩写代表的英文单词，自然就记住了。1.1.3 CMMI 的构件
CMMI 的内容是按照成熟度等级或过程域类别、过程域、目标、实践、子实践的方法进行分类管理的，这些概念之间的整体与部分关系可以参见图1-2。图1-2 CMMI 构件整体与部分的关系
每个过程域（PA）都有一个目的，在英文里明确区分了Purpose与Goal这两个单词，我们翻译为目的与目标。在中文里这两个单词并没有特别明显的区别。Purpose是一种抽象的、宏观的期望，Goal是一种具体的、微观的期望。
PA之间有一定的关联性，互相影响，比如RD的输出为TS的输入；TS的输出又影响了RD的输出，如此交织在一起。在CMMI 模型中有多张图描述了各个PA之间的关联关系，也仅仅是一个概念的视图，不能全面描述复杂的交织关系，参考而已。
在每个过程域里对实践进行了细分类，即又分为多个目标，目标是对实践的一种分类方式。目标又分为特定目标与共性目标，所谓特定目标是指某个PA所特有的，即这个PA有其他PA没有。所谓共性目标是指每个PA都有的，你有我有他也有。目标是CMMI 模型中必需的构件，是不可以裁剪的，是评估时必须考察、必须满足的。
对应于每个目标有能够满足此目标的实践。特定目标有对应的特定实践，共性目标有对应的共性实践。实践是期望的模型构件，所谓期望即最好这么做，如果不那么做，你可以替换这些实践，但替换后必须满足目标的要求。每个目标对应的实践之间没有严格的先后顺序关系。比如需求管理过程域对应的5条特定实践：
SP1.1 与需求提供者对需求达成一致的理解；
SP1.2 获得需求实现者对需求的承诺；
SP1.3 管理需求的变更；
SP1.4 建立与维护需求的双向可跟踪性；
SP1.5 识别需求与工作产品间的不一致。
这 5条特定实践之间没有严格的先后顺序关系。在管理需求的变更之前，我们已经建立了需求跟踪矩阵，根据需求跟踪矩阵进行了需求变更波及范围的分析，所以不能认为 SP1.3与SP1.4之间存在严格的先后关系。
每条实践都有一个编号，如前所述，SP代表的是特定实践，GP代表的是共性实践，1.2代表第1个目标的第2条实践。比如SP1.2代表第1个特定目标的第2条实践，GP2.3代表第2个共性目标的第2条实践。
在CMMI 模型中绝大部分实践都列举了工作产品的样例，这些工作产品样例并非都是必需的，而是可选的，只要你能证明你的工作产品满足了这条实践的要求即可，不必从文档名字、文档个数等方面和模型保持一致。
每条实践都可能有子实践，这些子实践是对实践的细化描述，是对实践的解释说明，可以根据企业的实际情况选择适用的子实践。我也曾经看到有的企业在做CMMI 时，把每条子实践都定义在体系中。如果真有用，还可以理解；如果不是这样，就太机械了。
对于过程域、实践、子实践都有一些解释性的说明，这些解释性的说明在正式评估时是供参考的，对我们准确理解模型的要求有一定的帮助。
对于CMMI 的构件一定要注意“必需的”、“期望的”、“解释说明”三种严格程度之间的区别，不要把后两种上升为“必需的”，这是很多公司常犯的错误，切记切记。
为了加深对过程域中各个构件分布的理解，我对CMMI -DEV 1.3 版本中的特定目标与特定实践的分布做了统计分析，如表1-2、表1-3、表1-4和图1-3所示。表1-2 按过程域类别统计分析表1-3 特定实践按过程域类别的分析续表图1-3 特定实践按过程域类别的分布表1-4 按成熟度等级的统计分析1.1.4 CMMI 的表示方法
CMMI 分为两种表示方法：一种称为阶段式表示方法；另一种称为连续式表示方法，如图1-4所示。
我们可以从以下几个方面来理解这两种表示方法的区别与联系。
1．包含的过程域相同，但是过程域分类的维度不同。图1-4 CMMI 的两种表示方法
阶段式表示方法为我们所熟悉，我们通常说的过了2级、过了3级都是针对阶段式表示方法而言的。在CMMI -DEV V1.3 中，阶段式表示方法将22个过程域分别放置在4个等级中，其中2级7个过程域、3级11个过程域、4级2个过程域、5级2个过程域；在连续式表示方法中将22个过程域分成了四类，其中工程类5个过程域、项目管理类7个过程域、支持类5个过程域、过程管理类5个过程域。
2．改进的路线图不同。
阶段式表示方法给出了固定的路线图，即必须先是2级的7个过程域，然后是3级的11个过程域，依此类推，在实施高等级时也必须实施通过低等级的过程域。而在连续式表示方法中，企业可以自己选择你想改进的过程域，可以针对自己企业的弱点进行针对性的改进，可以灵活选择改进点。在CMMI 模型中项目管理类、支持类与过程管理类的过程域又区分了低级和高级的PA，比如对于过程管理类的过程域，OPF、OPD、OT是低级的PA，OPP、OPM是高级的PA。按照连续式表示方法改进时，建议先从低级的过程域开始改进。
3．评估级别的评定维度不同。
在评估时，阶段式表示方法是针对整个组织进行统一评级，即评价组织的成熟度等级为2级或3级等，简写为ML2或ML3。连续式表示方法是针对整个组织的某些过程域评级，即评价组织的某个PA的能力等级为2级或3级，简写为CL2或CL3。注意两种表示方法对管理水平等级称呼的区别：阶段式称为组织成熟度等级（简写为ML），连续式称为过程能力等级（简写为CL）。成熟度等级是从1到5计数，能力等级是从0到3计数。
两种表示方法之间的等级有如下的换算关系。（1）ML2级的7个PA都达到了或超过了CL2级，则可以评价为ML2。（2）ML2和ML3的18个PA都达到了CL3，则可以评价为ML3。（3）ML2、ML3和ML4的20个PA都达到了CL3，则可以评价为ML4。（4）ML2、ML3、ML4和ML5的22个PA都达到了CL3，则可以评价为ML5。
注：在22个过程域中，SAM是唯一一个可以在评估时裁剪的过程域。
4．满足的商务需求不同。
根据上面的描述我们可以发现，连续式表示方法为企业的改进提供了灵活的方法，更加实用。可是为什么很多企业选择了阶段式表示方法呢？我认为主要的原因是对外宣传的简洁性，以及政府补助驱动的作用。
那么到底应该选择哪种表示方法实施改进呢？
如果你只要证书，当然选择阶段式。但是，记住了，不要找我们咨询。
如果你要实效，不要证书，你就选择连续式。这是我最喜欢咨询的企业。
如果二者都要，你可以先选择连续式，再选择阶段式。鱼和熊掌兼得，需要好好平衡一下。1.1.5 CMMI 成熟度等级的比较
了解CMMI 的人都知道，CMMI 的阶段式表示方法有5个等级，但是要将5个等级的区别真正说明白、说透彻，不太容易。下面我们用一个表格概括之。如表 1-5 所示，表格中并没有1级，1级在CMMI 的阶段式表示方法中没有对应的过程域，是起始级，所以不加描述。表1-5 CMMI 成熟度等级及其比较续表
表中比较内容解释如下。
1．过程改进的侧重点
CMMI 的2级是已管理级，是项目组对自己的过程实施了基本的管理，并不一定是组织级统一的管理规范。项目组可以自己管理自己的流程，也可以由组织级统一定义流程。3 级是由组织级统一发起过程改进活动，统一定义流程，项目组基于组织级的标准流程进行裁剪。而4级则要求在组织级对度量数据进行统一的分析，发现规律，建立组织级的过程性能目标、过程性能基线与过程性能模型。5 级则要紧紧围绕企业的商业目标实施过程改进，解决过程改进的实际商业收益问题。
2．管理制度的复杂度
CMMI 的2级包含了7个过程域，3级包含了11个过程域。2级是基本的管理过程，是从无到有的过程；3级是逐步完善、提升、统一的过程，达到3级时，企业的过程覆盖了18个过程域；4、5级分别包含了2个过程域。是否意味着在4、5级增加了过程域，过程定义就更加复杂了呢？不是的！4、5级的核心是解决了量化地刻画了过程的性能，围绕商业目标优化过程！所谓优化并非是指越优化越复杂，而是指越优化越经济！做最少的事情满足目标，取得投入与产出的最好平衡。
3．过程能力
过程能力指的是过程持续稳定实现过程目标的能力。
我们可以用职业运动员与业余运动员的水平差别进行比喻。比如职业的射击运动员，他每次出枪总能命中9环左右，而业余选手可能有时打飞，有时打中10环，当他抬手射击时我们无法预料他下一枪究竟多大的概率命中9环以内，也就是说我们可以从稳与准两个维度判断其水平的高低。
稳：每次射击的命中环数很接近，没有大起大落的现象，这样才可以预测。即使你每枪都脱靶，我们也可以认为你过程很稳定啊（必须脱靶在相近的位置）。为什么呢？因为我们可以预料到你下一枪还会脱靶。
准：每次射击的命中环数接近靶心，是我们期望的结果，这样才可以说你水平高，可以参加世界级的比赛。
CMMI 的2级和3级对过程没有稳与准的要求，而4级要求稳定，消除过程偏差的特殊原因，5级要求又稳又准，持续优化，优化过程偏差的一般原因。2级的过程由项目经理自己掌握，只要满足了CMMI 2 级7个PA 的要求即可，3 级要求组织级必须定义标准过程，项目组进行裁剪，过程基本统一即可。这也是2级称为已管理级与3级称为已定义级的由来，已管理级即项目组已经实施了基本的管理；已定义级指组织已经定义了标准过程。
4．过程定义的可行性
过程定义指的是过程设计。做一个项目，我们拿到需求后会在技术上进行设计，考虑需求在技术上如何实现，从管理上也需要进行设计，考虑这个项目在管理上如何实现，管理上的设计主要是过程的设计，两者的对比关系参见图 1-5。过程设计在CMMI 模型中描述了3个层次。图1-5 技术设计和管理设计两者的对比
层次1：生命周期模型的选择与项目阶段的划分，这是2级PP过程域的要求。
层次2：组织级标准过程的裁剪，这是3级IPM过程域的要求；
层次3：子过程的裁剪及验证过程或子过程对目标的可实现性，这是4级QPM过程域的要求；
层次1的要点是阶段设计，层次2的要点是过程设计，层次3的要点是子过程设计，要求是逐步深入，过程设计的颗粒度越来越细化。
5．管理的前瞻性
项目管理类的过程域在2级中有4个：项目策划（PP）、项目监督与控制（PMC）、供应商子合同管理（SAM）、需求管理（REQM）。在3级中有2个PA：集成项目管理（IPM）、风险管理（RSKM）；在4级中有 1个PA量化项目管理（QPM）。3级的IPM与RSKM是在2级的 3个过程域（PP、PMC、SAM）基础上更高的管理要求，尤其是IPM过程域。PP要求做计划，PMC要求在计划执行过程中进行事中与事后的监督与控制，而IPM强调了事前对照计划的管理活动，强调了计划的合理性、可行性，强调了过程与人员的协调一致问题，而4级的QPM则要求对过程定义的可行性、项目目标的可实现性进行量化的预测与管理。从2级到4级项目管理的变化，是一个从无到有，从简单到完备，从经验到量化，从事中、事后的反应式管理到事前的预测式管理的变化过程。
6．目标的可度量性
CMMI 2 级和 3 级并没有对项目目标提出要求，即项目组可以定义也可以不定义项目的质量与过程性能目标，即使定义了也不需要证明目标的可实现性，可以凭经验定义目标。而在4级和5级则明确提出，项目必须定义质量与过程性能目标，并且要求目标应该是文档化的、量化的、可以实现的，目标要符合SMART原则。
● Specific：文档化，明确。
● Measurable：可度量。
● Attainable：可实现。
● Relevant：和商务目标的相关性。
● Time-bound：在规定的时间。
目标的可实现性是需要重点解决的问题。怎么保证目标是可以实现的呢？（1）目标是基于历史的性能制定的，不能与历史偏差太大，如果偏差很大，必须有充分的理由证明之。（2）可以采用过程性能模型预测目标实现的可能性，即在什么样的投入下，这个目标是可以实现的，实现的概率多大。如果是小概率事件，则认为目标是不可实现的。
7．度量数据的完备性
CMMI 的2级有MA过程域要求进行度量分析，但是此PA仅要求每个项目组按自己的需求定义、收集、分析、存储度量数据，并没有要求在组织级统一定义度量元。而在3级中则要求建立组织级度量库，组织级统一定义需要采集的度量元。在4级中要建立组织级的过程性能基线与过程性能模型。过程性能基线的建立需要对组织级统一定义的度量元进行数据分布的分析，以求得历史数据的位置与离散程度。过程性能模型的建立则要求建立过程的输出与过程输入、属性之间的关系，既要度量Y也要度量x，x即为过程的输入与属性，度量数据的采集范围要比原来广泛了。图1-6 评估度量
8．度量的服务对象
CMMI 2 级采集哪些度量数据是由项目经理来确定的。3 级采集哪些度量数据是由组织级统一定义的。项目组可以裁剪。2级和3级采集的度量数据主要是为了监督项目过程的性能，而 4 级采集度量数据是为了建立过程性能基线与过程性能模型，不但要对过程的输出采集度量数据，也要对过程输入、过程的属性采集度量数据，采集的度量元相比2级和3级更多了。5级的度量数据是围绕改进组织级的商业目标来采集的。
9．管理技术的客观性
管理技术的客观性是指是是否采用了统计技术对项目实施了量化管理。
这里说的统计技术不仅仅是指度量了数据，对数据画了饼图或其他图形的分析。统计技术包含了 2个方面：统计描述技术与统计推断技术。对于一组数据计算了平均值、标准差等称为统计描述。统计推断技术是指根据样本的统计量可以推断出总体的统计量，发现统计的规律，比如根据3000个家庭父母的身高、孩子的身高得出一个计算孩子身高的回归方程。
基于统计的技术非基于经验识别过程的异常、识别管理中的问题，这正如中医与西医看病的区别。中医看病是凭经验，经验好的大夫看病比较准，经验差的大夫看病水平则比较低，同一种病，不同的中医大夫诊断，结论可能相差很大。西医看病是基于各种检测指标，如血压、血小板的含量等等，是客观的决策，同一种病，不同的西医的结论差别不大。
上述的区别是我在咨询中对这4个等级的体会，不代表CMMI 研究所的官方解释。每个人也许有每个人的感悟，各有道理吧。1.1.6 如何学习CMMI
在建立体系之前需要研究CMMI 模型的要求以建立理论基础。那么，究竟如何学习CMMI 呢？我的体会如下。（1）通读模型
模型是众多专家总结的最佳实践，历时多年，讨论了许多遍才写成的。模型里包含的信息量很大，描述得很完备，需要全面地通读模型。比如，有朋友问我，开发工具是否要识别为配置项？其实这个问题在模型里有明确的答案，只要去读CM SP1.1 的描述就可以了，模®型的原文如下（CMMI for Development, Version 1.3, CMU/SEI-2010-TR-033，P140）。
Configuration identification is the selection and specification of the following：
● Products delivered to the customer
● Designated internal work products
● Acquired products
● Tools and other capital assets of the project,s work environment
● Other items used in creating and describing these work products
<参考译文>
配置识别是选择和刻画：
● 交付给客户的产品；
● 指定的内部工作产品；
● 采购的产品；
● 项目工作环境的工具和其他重要的资产；
● 用来创建和描述这些工作产品的其他物品。
再比如，对于CM SP1.2 建立配置管理系统，有的企业仅把实际应用的配置管理工具视为证据，其实仔细去读模型的原文（A configuration management system includes the storage media, the procedures, and the tools for accessing the configuration system）就会发现：存储的介质、规程与工具三者结合起来构成了配置管理系统，因此物理的配置项、配置管理工具及配置管理规程都是该实践的物证。
需要注意，应尽可能通读模型原文，尽管已有中文版的模型可以下载，但是翻译后的资料与原文还是有些差异，可能丢掉了原文里的很多含义。（2） 咀嚼模型
模型不但描述得完备，而且简练，很多思想蕴含在平淡的叙述之中，因此需要仔细体会模型里的每一句话，要反复地阅读模型。比如®对DAR SG1：评价候选方案。模型中该目标的原文如下（CMMI for Development, Version 1.3, CMU/SEI-2010-TR-033-P151）：
Issues requiring a formal evaluation process may be identified at any time. The objective should be to identify issues as early as possible to maximize the time available to resolve them.
<参考译文：在任何时间都可以识别需要执行正式评价过程的问题。目的是尽早地识别出这些问题以预留出尽可能多的时间用以解决这些问题。>
仔细体会这段话，传达了以下这样几个含义。
● 在任何时候都可以采用 DAR，比如项目的初期、中期、后期。项目的初期会有哪些决策呢？开发方法的选择、技术路线的选择、开发工具的选择、需求的裁剪、供应商的选择等等。中期呢？深思之。
● 应该尽可能早地识别出需要执行DAR 的问题，以留出足够的时间解决问题。在项目进展的早期应该尽可能多地识别出需要执行DAR的问题，这样能够考虑得更加完备。
再比如，对于PP SP1.1 估计项目的范围。模型中该实践的正文®为（CMMI for Development, Version 1.3, CMU/SEI-2010-TR-033。P283）：Establish a top-level work breakdown structure（WBS ） to estimate the scope of the project.<参考译文：建立高层的任务分解结构以估计项目的范围>
top-level是第几层呢？仔细读该实践的第2条子实践：
Identify the work packages in sufficient detail to specify estimates of project tasks, responsibilities, and schedule。<参考译文：详细地识别任务包，以明确估计项目的任务、责任和进度>
据此可以推理出：这里所说的 top-level 的 WBS 就是分解到工作包级，基于工作包做估计、分配责任及安排进度。如果仅仅从字面的含义认为top-level就是第1层的WBS ，那就是笑话了。第1层只有1个节点，没有实质性的意义。
书读百遍，其义自现！（3） 参考其他模型
CMMI 是融合SW-CMM、SE-CMM、IPD-CMM等几个模型而来，为了保证能够适合于多种学科，在术语上往往比较抽象，因此当对某些实践无法读懂时，就要相应地去参考其他模型。比如对PI SP1.1 确定集成顺序，对于软件系统的集成，当系统的规模不大时，其实开发顺序在很大程度上决定了集成顺序。为了加深理解该实践，在实际执行过程中很好地裁剪该实践，可以参考SE-CMM 的BP05.08等实践，在SE-CMM的BP05.08中有如下的描述。
The larger or more complex the system or the more delicate its elements, the more critical the proper sequence becomes, as small changes can cause large impacts on project results.
The optimal sequence of assembly is built from the bottom up as components become subelements, elements, and subsystems, each of which must be checked prior to fitting into the next higher assembly. The sequence will encompass any effort needed to establish and equip the assembly facilities (e.g., raised floor, hoists, jigs, test equipment, I/O, and power connections). Once established, the sequence must be periodically reviewed to ensure that variations in production and delivery schedules have not had an adverse impact on the sequence or compromised the factors on which earlier decisions were made.
<参考译文：
系统越大、越复杂或元素越易损的，正确的顺序就越关键，因为小的变动就可能对项目的结果带来很大的影响。
最佳的集成顺序是进行由底向上的集成：当部件集成为子元素、子元素集成为元素、元素集成为子系统时，每个层次在集成到更高的层次之前都要进行检查。集成顺序中也包含了所有建立和配备集成工具的活动（例如：活动地板、基座、起重机、夹具、测试设备、I/O、电力连接线等）。一旦建立了集成顺序，则必须周期性地评审以确保生产和交付工期的变化对集成顺序没有负面影响或者对早期的决策进行折中调整。>
在阅读 CMMI 时可以参考的资料包括：SW-CMM、SE-CMM、IPD-CMM、PMBOK、ISO15504、TSP、PSP等。（4）映射到本企业的实际情况
CMMI 模型既适合于软件开发企业，也适合于硬件生产企业，既适合于软件产品的开发，也适合于外包类的软件企业，不同类型的企业对于模型的每条实践解释是不同的，需要结合企业自己的实际情况解释模型。
CMMI 模型是基于实践提出的，不是理论推导出来的。模型里的实践或多或少都可以在本企业的实践中找到映射。“做没做”、“做得好不好”，是在和企业的实践进行映射时必须考虑的问题，通过这种映射可以加深对模型的理解。
比如，对TS SP1.1 开发候选解决方案与选择准则，在企业里候选方案的开发与选择可能发生于投标阶段、立项阶段、设计阶段，企业的这些不同阶段的实践都可以映射过来，在投标或立项时可能是涉及对总体方案的选择，在设计阶段可能涉及对具体某个产品构件的解决方案的选择。通过与企业的实践进行映射就可以发现，这里提到的解决方案实际上是泛泛而言，并非仅仅针对总体技术路线的选择，某个具体的构件的解决方案的选择也适合。
判断“做没做”仅仅是最基本的映射，判断“做得好不好”才是更高层次的映射。在CMMI 模型里，因为模型里的实践是可以替换的，所以只要达成了模型里每个PA的目标的实践都被认可就可以了。（5）与多个人讨论模型
一个人的视角是有局限的，通过与其他人的沟通，可以从不同的人员那里获得不同的信息，从而对实践理解得更加全面与深入。即使别人的观点未必是正确的，也可以在讨论中受到启发，也可能激发自己更多的想法。组织应该建立定期讨论的制度，通过一种制度化的沟通来确保大家关注过程改进工作，真正地投入时间去考虑如何改进。在我咨询的一个客户中，有一个项目组每周都定期抽出一定的时间大家一起研读模型，这种沟通与讨论对理解模型、识别组织的优势与劣势很有帮助。不要仅仅限于与组织内部的同事进行讨论，与其他组织的同行进行沟通帮助可能更大。
我建立了一个QQ群：133986886，我的很多客户都参与了该过程改进的讨论群，大家可以在这个群里进行模型相关的讨论。1.2 EPG 的工作指南
EPG 是工程过程组（Engineering Process Group）的简写，EPG 是企业内的立法机构，负责制定与推广管理规范与过程财富。1.2.1 EPG 成员选择四要素
选择什么样的EPG 成员才合适？基于我的所见所闻所思，总结了4个选人的要素。（1）知识
知识是基础的要求，应该具有基本的软件工程知识，而不是白纸一张，这样才能容易沟通，知识可以通过学习来获得，有无知识是相对的；知识可以通过是否学习过哪些课程，接受过哪些培训、读过哪些书籍来衡量。
实践出真知。知识经过实践的锤炼才能真正成为自己的知识，对知识与经验进行了再加工、创造出新的理念才是对知识与经验的升华。
无知并不可怕，可怕的是不知道自己无知。很多自以为是的人都不认为自己无知。（2）经验
软件工程是一门实践型的学科，缺乏足够的经验就很难理解模型里的各个实践，否则即使读了模型，也无法引起共鸣，文字都认识，但是文字的真正含义却无法透彻地理解。古人云：读万卷书，行万里路，讲的就是知识和经验的重要性。在实践中有很多事情是无法靠知识来解决的，而是要靠经验。
经验是要积累的，积累需要时间，悟性高的人可以更快地积累经验教训，有执行力的人可以积累真正实用的经验。（3）悟性
悟性是举一反三的能力，是知微见著的能力，是自我学习、自我进步的能力。有悟性的人才能循序渐进地改进自己，也才能循序渐进地发现组织的缺陷，才能改进组织的标准过程。
悟性难以通过学习来获得，在很大程度上是天生的，悟性决定了一个人在某个领域可以达到的层次。
知识与经验是悟性的源泉，没有知识与经验，悟性就无法产生新的思想。
试读结束[说明：试读内容隐藏了图片]