我不知道的CMMI

可能是因为挂在我头上多年的高级别主任评估师和讲师头衔，让不少朋会认为我对CMMI的了解俨然如宗师。凭心而论，我不反感这样的误解，因为它能给我带来不少好处。

这篇文章，我想诚恳的承认自己的不足和弱项，但愿从某方面给CMMI正面推进。而触发这篇文章的动机是最近看到推特上火热进行的Senior程序员和新手的差异的讨论，看到一些软件大神毫无保留的告诉全世界他们也有许多软件编程的盲点，鼓励软件新人不要迷信所谓人间大神。

首先，CMMI覆盖的领域之全令人生畏，CMMI的功夫在CMMI之外，敢于说“不知道”的同时，努力学习探索。和许多所谓资深软件人员在考虑设计方案一样，在CMMI改进咨询过程中，我非常依赖搜索引擎所指向的相关链接，也会请教一些朋友。

其次，对于几乎所有的CMMI改进者、咨询师来讲，碰到的问题、环境、打交道的人、不同的时间点等因素都可能让他们在膨胀和怯懦之间翻转。有时候资深的CMMI实践者真诚展示自己的不安全感，对于新人也许是种更好的鼓励。

再有，不要对咨询师抱有不切实际的幻想，真正解决问题好要靠自己。

下面列举一些我不知道的CMMI。

从端到端的考虑，如何确定双向需求跟踪的颗粒度；没有工具支持，大颗粒度的需求跟踪还有意义吗？虽然也能给客户一些建议，但总感觉许多时候没有帮助团队找到有效做法，通过需求双向跟踪在产品生命周期中使之在动态变更中保持一致、完整。

缺陷分析在软件过程改进中扮演重要角色，不同技术文档的评审和各类测试能帮助我们发现不同类型的问题，这些质量活动的优化往往依赖于缺陷分析。缺陷分析离不开缺陷分类，因为通过类别分析团队可以对找到共性问题（2-8原则），确定植入阶段，揭示过程环节的欠缺。从30年前IBM发表了其缺陷分类的方法和例子后，实施CAR的组织都会照猫画虎做一些ODC缺陷分类。如何根据团队能力，业务和技术特点，在一套具备较好指导力的方法帮助下，建立、完善易理解、清晰、可操作、满足缺陷分析目的的缺陷分类，我还是经常需要去Google，Google再Google。

虽然能看到6西格玛框框下CMMI高成熟度的问题，一些统计技术应用于软件场景时的游戏世界，但如何跳出这个困境，在统计思维、技术匮乏的环境下，另辟蹊径，找出有效有价值、可持续、常态化的做法，目前没有找到具有普遍性的方法。

CMMI 2.0明确要求计划监控应覆盖运维支持（Operation and Support），众多要做benchmark评估拿成熟度级别，但其场景又和运维支持毫无关系的组织面临需要找到等价替代的挑战。如何找到能实现类似价值、意图的实践，我有时也是一头雾水，给出的建议也是鸡肋，其价值仅限于评估。

在看CMMI 2.0高成熟度实践时，我希望谁能清楚的告诉我，项目中的SPC（统计过程控制）到底应该在哪些PA的高成熟度实践中体现？过程性能模型在项目中的应用又体现在哪里？CMMI 1.3的QPM到底跑到哪里去了？相关的分析方法当然可以在许多仅到三级实践的PA中体现，但2.0高成熟实践的系统性、组织和项目的区分真是模糊啊。

都知道裁剪让过程适用的重要性，但如何解决它对工具导入带来的问题呢？我也百思未到优解。

我常常说“不要做仅仅为了评估而做的事”，但在识别一些具体替代实践，在度的把控方面，真的还有好多事情要学习。

在项目中应用CMMI 2.0的CAR实践时，考虑到项目资源问题、进度压力、其他一些约束条件，如何实现CAR的要求，让其在项目中执行常态化，我往往把握不好恰当的度。在领导5级2.0评估时，如何让随机选中的项目足够体现所有实践，特别是4级和5级的实践，让我有时在矛盾中摇摆。

上面这几条是我可以立刻想到的，并不完全囊括我的盲点，不知和浅知的东西还有很多。

罗列自己的不足，呈现自己的才疏学浅总是有几分抱歉自责。但我还是要负责任的告诉你，所谓专家在一些方面并不如你，你也一样可以做某领域的牛人。

当然，作为资深的CMMI实践者，我的最大价值是经验。我杀过的猪也许不多，但看过的猪绝对是颇为壮观。正视自己的短板，虚心求教，我希望做更好的自己,不断弥补知识的不足。

---