CMMI认证
IT企业在追逐CMMI认证等级的时候如何跳出CMMI评估陷阱
更新日期：2022-01-14 09:40:25 已浏览：1799次
在CMMI主任评估师圈子里有个让大家一直头疼的问题：如果一个组织既要CMMI的级别但又不愿意做一些模型中对自己无价值的实践时，该怎么办？几乎所有评估师的倾向是：如果你要级别证书，不得不做一些对组织无价值的事情是必须跳进去的评估陷阱。
一位我们认识多年资历颇深的CMMI评估师是这样说的，“当你决定要追逐成熟度级别时，你已经没有选择了，会导入并实施一些对组织无价值的实践。在这种情况下，你会定义一些不会带来业务价值的过程，它们唯一目的就是为评估提供一些文档证据。”
我们一直不太能接受这个论调，总感觉它有点在鼓励评估变成游戏，也很难想象这些过程在没有参加评估的项目里会被使用。逼着一群高智商的人做无价值的事情，不应该是Humphrey的初衷。
如何正确打开CMMI开发模型？它给出的是产品开发全过程的重要考虑点以及提升过程能力的通道，模型中的每一条实践都有其目的：或者要规避一些潜在问题，或者要强化一些对实现高效、高质量开发有意义的活动。由于各个组织有不同的场景，在建立实现这些目的的过程时，一定会有性价比的考虑，很有可能有些要规避的问题在某个组织内不是大问题，而有些强化活动同样意义也不是很大，如果评估组不能很好的区分模型要求（意图和价值）和实施选择，带着一套预期的“实践做法”参加评估，就会掉入了CMMI的评估陷阱，逼着企业披上两张皮。
这真的是个跳不出来的CMMI评估陷阱吗？我们不这么认为。当年Humphrey规定的，今天我们们还在遵循的一条评估准则是：评估准备阶段评估组必须充分了解评估组织的context（场景），其目的就是要理解组织的特殊性，理解一些特殊做法的合理性，从而完成一场有价值的评估。这就是说，因为场景不同，同样一条实践意图的实现方式是可以多种多样的。
从我们开始做CMM评估师开始，就一直努力摸索破解这个评估陷阱之法。这确实不是一件容易的事，但20年的时间也积累了一些思路。
首先，真正理解模型中实践的意图价值是基础，确定这个意图价值在具体企业中的体现则需要站在他们角度看问题，只有这样才能对无明显价值实践找出替代实践。
比如说，一些CMMI五级的对日外包组织，他们的项目范围仅仅是V模型的下半身，团队只和日方技术团队沟通，工作范围可能仅覆盖详细设计到单体-部件测试，他们没有机会面对真正用户或客户。那么我们们如何实施RDM中操作场景的要求呢（RDM3.2）？如何确认需求在目标环境下实现客户要求呢（RDM3.7）？显然用传统僵化模式的话，我们们只能跳入CMMI评估陷阱了，做一些脱离场景的评估怪事了。但是如果我们们真正理解3.2和3.7的意图，真正理解外包场景，那么找出价值的替代做法也不是一件难事。比如可以通过Q&A票确保团队理解日方提出的输入，同时让日方明确确认我们们的编程、测试思路。成熟的日本客户往往也会要求你这样做，这些替代做法形成的过程既有价值，也实现了RDM相关实践在外包场景的目的。
“以需求为例，它是让众多软件组织头疼的问题，CMMI给出了14条实践帮助大家破解需求难题。但是不同的项目有不同需求问题，随便举几个场景：一些研发项目需求十分模糊，连客户也说不出个道道；有些升级项目需求则包含了客户、开发一致认为应该完善之处，所以十分明确；有些对日外包项目需求就是一些描述清晰的任务包；有些新技术、新领域（如环保）的项目客户根本不熟悉，也不知道如何引入；有些财大气粗、但不了解技术局限的客户对需求会狮子大开口；有些项目跨越多产品，牵扯多接口，多团队；有些项目仅覆盖单系统、单团队。如果做个问题接龙游戏，相信我们们可以玩几个小时。
那么如何用CMMI给出的14条破解之术呢？显然大而空的标准会处处碰壁，最终一定是评估花瓶项目的点缀，不参加评估的项目会各行其是。以之“道”模式打开：先了解14条实践覆盖的点；逐步悟出其中之意，经验决定悟性；根据具体场景，不拘泥固有模式，当繁则繁，当简则简，当无则无，当变则变，无有固有，随机应变，时刻抓住重点，见招拆招，在约束范围内，争取最大价值。
所以学习CMMI也应由繁入简，最终只存其意。当然做到这一点，需要不断的实践，需要谦逊的请教，需要发挥自己的悟性，需要一点创新的精神。每家IT组织都有自己的痛点，每个项目都有不同的场景，每个具体成功的CMMI落地都有其独特之处，CMMI应用之妙，必然是无招胜有招。面对几百条实践，我们们这些CMMI传播者更应该从“器”悟“道”，方得精髓。”
我们观察到不少CMMI评估组没有真正理解一些重要的评估规则，比如，五级评估不是所有项目都要做到五级；不是有一些弱项实践要求就一定没有实现，我们们还要看在评估场景下，弱项带来的危害是否比较大。这里我们也呼吁下，更加明确模型覆盖要求，鼓励CMMI的用户追逐价值，do more with less, 远离CMMI评估陷阱。
一位我们认识多年资历颇深的CMMI评估师是这样说的，“当你决定要追逐成熟度级别时，你已经没有选择了，会导入并实施一些对组织无价值的实践。在这种情况下，你会定义一些不会带来业务价值的过程，它们唯一目的就是为评估提供一些文档证据。”
我们一直不太能接受这个论调，总感觉它有点在鼓励评估变成游戏，也很难想象这些过程在没有参加评估的项目里会被使用。逼着一群高智商的人做无价值的事情，不应该是Humphrey的初衷。
如何正确打开CMMI开发模型？它给出的是产品开发全过程的重要考虑点以及提升过程能力的通道，模型中的每一条实践都有其目的：或者要规避一些潜在问题，或者要强化一些对实现高效、高质量开发有意义的活动。由于各个组织有不同的场景，在建立实现这些目的的过程时，一定会有性价比的考虑，很有可能有些要规避的问题在某个组织内不是大问题，而有些强化活动同样意义也不是很大，如果评估组不能很好的区分模型要求（意图和价值）和实施选择，带着一套预期的“实践做法”参加评估，就会掉入了CMMI的评估陷阱，逼着企业披上两张皮。
这真的是个跳不出来的CMMI评估陷阱吗？我们不这么认为。当年Humphrey规定的，今天我们们还在遵循的一条评估准则是：评估准备阶段评估组必须充分了解评估组织的context（场景），其目的就是要理解组织的特殊性，理解一些特殊做法的合理性，从而完成一场有价值的评估。这就是说，因为场景不同，同样一条实践意图的实现方式是可以多种多样的。
从我们开始做CMM评估师开始，就一直努力摸索破解这个评估陷阱之法。这确实不是一件容易的事，但20年的时间也积累了一些思路。
首先，真正理解模型中实践的意图价值是基础，确定这个意图价值在具体企业中的体现则需要站在他们角度看问题，只有这样才能对无明显价值实践找出替代实践。
比如说，一些CMMI五级的对日外包组织，他们的项目范围仅仅是V模型的下半身，团队只和日方技术团队沟通，工作范围可能仅覆盖详细设计到单体-部件测试，他们没有机会面对真正用户或客户。那么我们们如何实施RDM中操作场景的要求呢（RDM3.2）？如何确认需求在目标环境下实现客户要求呢（RDM3.7）？显然用传统僵化模式的话，我们们只能跳入CMMI评估陷阱了，做一些脱离场景的评估怪事了。但是如果我们们真正理解3.2和3.7的意图，真正理解外包场景，那么找出价值的替代做法也不是一件难事。比如可以通过Q&A票确保团队理解日方提出的输入，同时让日方明确确认我们们的编程、测试思路。成熟的日本客户往往也会要求你这样做，这些替代做法形成的过程既有价值，也实现了RDM相关实践在外包场景的目的。
“以需求为例，它是让众多软件组织头疼的问题，CMMI给出了14条实践帮助大家破解需求难题。但是不同的项目有不同需求问题，随便举几个场景：一些研发项目需求十分模糊，连客户也说不出个道道；有些升级项目需求则包含了客户、开发一致认为应该完善之处，所以十分明确；有些对日外包项目需求就是一些描述清晰的任务包；有些新技术、新领域（如环保）的项目客户根本不熟悉，也不知道如何引入；有些财大气粗、但不了解技术局限的客户对需求会狮子大开口；有些项目跨越多产品，牵扯多接口，多团队；有些项目仅覆盖单系统、单团队。如果做个问题接龙游戏，相信我们们可以玩几个小时。
那么如何用CMMI给出的14条破解之术呢？显然大而空的标准会处处碰壁，最终一定是评估花瓶项目的点缀，不参加评估的项目会各行其是。以之“道”模式打开：先了解14条实践覆盖的点；逐步悟出其中之意，经验决定悟性；根据具体场景，不拘泥固有模式，当繁则繁，当简则简，当无则无，当变则变，无有固有，随机应变，时刻抓住重点，见招拆招，在约束范围内，争取最大价值。
所以学习CMMI也应由繁入简，最终只存其意。当然做到这一点，需要不断的实践，需要谦逊的请教，需要发挥自己的悟性，需要一点创新的精神。每家IT组织都有自己的痛点，每个项目都有不同的场景，每个具体成功的CMMI落地都有其独特之处，CMMI应用之妙，必然是无招胜有招。面对几百条实践，我们们这些CMMI传播者更应该从“器”悟“道”，方得精髓。”
我们观察到不少CMMI评估组没有真正理解一些重要的评估规则，比如，五级评估不是所有项目都要做到五级；不是有一些弱项实践要求就一定没有实现，我们们还要看在评估场景下，弱项带来的危害是否比较大。这里我们也呼吁下，更加明确模型覆盖要求，鼓励CMMI的用户追逐价值，do more with less, 远离CMMI评估陷阱。
分享：
友情链接
