CMMI2.0之我见-估算EST&监督与控制MC

编者按：

CMMI2.0之我见系列将通过系列文章形式介绍CMMI2.0所涉及到的其中20个实践域，笔者将通过系统性的梳理、浅显易懂的文字描述，同时结合笔者的思考和观点，对每个实践域的目标以及所基本涵盖的内容进行描述，希望能抛砖引玉、相互碰撞，燎原出契合读者各自心中的答案。

目录/CONTENT

01 策划PLAN

02 风险与机会管理RSK

03 估算EST&监视与控制MC

04 组织级培训OT&供应商协议管理SAM

05 需求开发和管理RDM

06 验证和确认VV&同行评审PR

07 技术解决方案TS&产品集成PI

08 原因分析和解决CAR&决策分析和解决DAR

09 配置管理CM

10 过程管理PCM&过程资产开发PAD

11 管理性能和度量MPM

12 治理GOV&实施基础条件II

13过程质量保证PQA

---

估算（EST）

EST是CMMI2.0中新增的一个实践域，是从CMMI1.3版本中的PP与IPM 过程中剥离了一些实践出来。从这一点看，2.0版本对估算工作很重视，估算是项目实施的基础，也是对内和对外承诺的基础，估算是项目计划的基础。

没有一个好的估算，项目计划就像无源之水。实践证明，拍脑袋给出的计划可执行性是很差的，发布版本总是延迟，所以我们需要做好估算，例如：功能点，代码量，工作量等。项目经理根据估算结果结合市场及客户需要进行进度的调整，同时“工欲善其事，必先利其器”，大多数公司在估算中也离不开对组织度量库和资产库的使用，我们早期单独写过一篇关于组建和使用知识库的文章，有兴趣的可以自行在赛希咨询微信公众号查阅一下。

估算要有方法论，要根据估算的结果与实际的偏差率不断调整，优化估算方法。下面介绍一下，在项目初期，项目到底需要估算哪些方面，如何进行估算。

规模估算：根据软件的需求等估算软件的规模，通常以功能点或代码行的形式。功能点估算是最常见的规模估算方式之一，功能点方法由5个仅取决于需求规格说明的要素组成，包括内部逻辑文件（ILF）和外部接口文件（EIF）；外部输入（EI）、外部输出（EO）、外部查询（EQ）。通过功能点方法做规模估算就是要根据软件需求识别这五类计数项，并根据每类计数项的权重计算功能点数，计算的结果就是我们要估算的软件规模。

项目的规模估算对于项目其它方面的管理或多或少也起着客观性的作用，例如：在项目范围提出变更的时候，通过规模估算推导出项目的计划是否变化、项目成本的变化程度等等，从而为项目管理者判定是否应该接受此次范围变更提供强有力的说服理由。

对于项目的质量管理、项目的沟通管理、项目的采购管理以及项目的集成管理也是同理，因为规模估算提供的是一个依据，一个建立在项目成员经验上、建立在项目管理理论基础上的一套科学的推算方法。

无论是Dephi(专家法)，还是功能点法，还是三点技术法，都可以得到项目管理所需要的人力、物力、时间等这些项目管理基本要素，从而达到指导项目管理实际工作的目的。

工作量估算：根据项目的规模等估算完成工作所需要的工作量，通常以人/月，或者人/天的形式。

进度估算：根据软件的规模、软件的工作量等估算项目的进度，通常以自然月，日历月的形式。进度估算可以先从任务规模估算入手。可以把项目计划中的任务罗列出来，根据估算并固定工期调整项目计划。另一方面，项目经理利用项目成员的周工作计划，其中会呈现成员一周相关任务工作量的估算，这样当期与实际工作量就有一个对照，便于项目经理调整整个项目的项目计划。

资源估算：软件开发类的项目最关键的资源就是人力资源。项目经理有了项目计划书，根据项目估算的规模，进度表，就能够在项目的开始阶段统计项目的人力投入情况。何时需要何种人员?人员的能力水平如何?人员工作的强度如何?何时人员可以进入或退出项目组?有了这些信息，项目经理就可以进行下一步安排。但重要的是事前沟通，提前从公司领导处得到资源满足的承诺，而不是等项目使用的时候干瞪眼。

成本估算：根据项目的工作量、进度等估算项目的成本，通常包括功能性成本，非功能性成本等。软件开发项目的主要成本就是人力，同项目资源管理一样，有了估算的项目规模可以推导出人力投入情况表，项目经理可以很容易地算出项目的整体成本，也可以通过及时地释放人员来降低成本。在项目发生变更时，也能够快速得到项目成本变化的趋势，找到项目成本控制的办法，从而达到成本管理的目的。

最后再着重说一下规模估算，它是项目起步的源头，规模估算确实是一项比较重要且复杂的事情。我们把工作分解得足够细，直到我们可以估算工作量的程度，这样的办法虽然原始，但是简单有效并且容易掌握。老老实实地做WBS，直接估算每个工作的工作量，充分发挥好专家的专长和力量。

Delphi专家法是估算软件规模最简单的办法，下面以工作量估算为例介绍一下：

首要，把公司内部最有项目经验、最有估算经验的工程师专家召集在一起，制定组织级的估算表模板，根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别列出不同的活动，尽量把这些活动种类细化。如考虑设计时，还需要考虑设计评审的时间；考虑编写计划时，需要考虑主计划、子计划的编写等等。例如：软件开发活动，可以分类为直接生产软件生命周期的活动，项目管理类的活动，项目支持类活动，维护类活动。

其次，项目组选用合适的估算表模板，进行由底而上的估算。项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。

所有的估算都离不开财富库，离不开度量库，这些大量的数据积累和历史财富在估算过程中发挥着重要作用。每个项目使用模板进行估算后，都可以对模板提出改进建议，完善模板，持续改进，把本项目的成功经验融入到模板中，纳入财富库，让后面的项目受益，这是一个不断迭代的良性生态。

监督与控制（MC）

监督与控制这个实践域的目的是提供对项目的全面了解，参照计划对项目进行监督和管理，同时在项目计划发生明显偏移时采取适当的纠正措施。

项目计划是监督活动、沟通状态以及采取纠正措施的基础。通过项目进度表、周例会、里程碑等环节，将实际的工作产品与规模、工作量、成本、进度、干系人介入、资源投入等与计划进行对比，通过分析结果来确定进展情况，在明显发生与目标偏差时采取合适的纠正措施。

这些措施可能包括：修订原来的计划，建立新的目标，签订补充协议或者在当前计划中增加额外的预算等。例如：对干系人的监控，我们需要关注在不同的结点，干系人是否按照计划参与项目的相关活动并达成一致，如果在监控中未识别或未按要求执行，就需要重新建立干系人计划，并且确保干系人在新计划中的介入信息。

CMMI2.0中监督与控制这个实践域对比之前的1.3版本有了一些调整和优化，例如2.0中首先强调的是问题的识别和解决，问题能否被有效识别和解决是监督与控制实践域的重要指标。

项目的生命周期中，几乎总是会出现意想不到的问题，当这些问题出现时，我们必须准备好处理它们，否则它们可能会潜在地影响项目的结果。

大多数问题发生都是意料之外的，如何确保能够快速有效地处理它们呢？CMMI实施中，在开始项目之前，组织就需要一个适当的问题解决过程，以确保按进度进行，并满足项目的目标。问题管理是识别和解决问题的过程。例如：资源问题、技术故障、进度问题等，这些都可能对项目产生负面影响，如果问题得不到解决，就有可能产生不必要的冲突、延迟，甚至无法生产出你的可交付成果。

很多人对问题和风险概念经常混淆，它们并不是一回事。对于风险，通常预先会有一个大概的预判和风险的应对措施，而问题往往是难以预测的，它可能毫无预兆地发生。例如，无法找到满足技能要求的人员是一种可识别的风险，但是如果一位重要的成员突然就离职了，那就是问题。

在项目开始之前识别风险是很重要的，需要对风险进行优先排序并制定计划，一旦风险发生就执行预先安排好的解决方案，对风险进行有效管理。在遇到问题时必须及时处理，问题管理就是减少返工，对已发生的目标偏差尽可能挽回的过程。

风险在项目开始时没有被识别时，极有可能以后会成为问题，所以在项目管理中只有不断的学习，不断的复盘，从中取长补短，才会减少未来项目同类型问题的产生。

CMMI2.0中监督与控制（MC）实践域新增的还有监督向运维和支持的移交。对于运维阶段的工作CMMI2.0在很多地方进行了加以说明，例如，在策划（PLAN）这个实践域SP2.5强调了有计划地对运维和支持的工作进行移交；在监督与控制（MC）实践域中SP2.3强调了完成的解决方案要移交给运维或售后服务人员，进入生命周期的维护阶段，移交给运维的活动需要做计划，需要监督执行情况。

由此可见，售后运维的重要性。在软件技术服务中，人们通常认为决定企业竞争力的是“综合技术力”，即包括传统意义上技术研发能力，也包含针对客户的售后、运维等在内的“软实力”。两者结合并且没有短板才是一家企业在竞争中占据优势的关键。“软实力”的组成中，售后运维服务是十分重要的一环，也成为了行业竞争的重要组成部分！

关注微信公众号【赛希咨询】，了解更多精彩内容。