CMMI on line

最近有这样的一个辩论，功能点VS代码行，辩论的焦点就是用哪一种来代表软件规模更好一点。项目规模的度量大有学问，如果您想去听听专业的软件功能点法课程，您可能要付上高昂的学费，并且有可能学了后还不知道如何用上这个办法。这里我不想谈论这两种办法，这些方法可能仅是理论上可行，目前我也没有见到过一个成功实践这类方法的案例。

软件规模就这么难度量吗？以前我的领导曾经问过主任评估师，我们把工作分解得足够细，直到我们可以估计工作量的程度，这不就把工作量估出来了？

没错，我想说的就是这种办法，而我们亲爱的微软，就是采用这样的方法来估算规模的。这样的办法虽然原始，但有效，并且容易掌握。虽然这种办法被扣上主观成分大、项目间难以横向对比的、难以积累历史数据等多种“罪状”，但不好意思，用功能点法或者代码行法就很准吗？我们亲爱的软件工程师们认可功能点法或者代码行法吗？搞功能点法代码行法等这些“虚”办法，还不如老老实实地WBS，直接估算每个工作的工作量。

中国的软件公司所做的大部分项目都会出现不同的新情况，功能点法和代码行法只适用项目类似的情况，或者是做外包时和对方讨价还价用的。下面介绍的软件规模度量办法，是所有公司都能马上采用的办法，而且将会让工程类人员乐于接受，我暂且把这个估算办法叫做“傻瓜估算法”。

第一步：把公司内部最有项目经验最有估算经验的工程们召集在一起，制订组织级别的估算表框架。

软件开发活动，可以分类以下几类：

l        直接生产软件的活动，如：需求开发、设计、编码、测试等工程类活动。

l        项目管理类活动，如：编写项目计划、计划跟踪、发布评审等活动。

l        项目支持类活动，如：配置管理、QA检查等。

l        维护类活动，项目验收后的数据整理、修改缺陷、系统维护等活动。

根据公司的实际情况，列出各类项目活动，可以根据不同的项目类别而列出不同的活动，尽量把这些活动种类细化，如考虑设计时，还需要考虑设计评审的时间，考虑编写计划时，需要考虑主计划、子计划的编写等等。

把这些框架定好，并设计出估算表模板，供项目组使用。

据我的经验，很多估算没有做好的缘故，常常是忘记或者是没有估算好估算管理类、支持类、维护类的活动。当一个公司的估算精英聚集在一起的时候，大家要列出公司估算中常常遇到的问题，全部考虑到估算表模板中，并写上足够清晰的指导。当项目组用这些模板的时候，相当于用了估算精英们的脑袋来思考本项目的估算了。

第二步：项目组选用合适的估算表模板，进行由底而上的估算。

项目组根据自己项目的特点，选用合适的估算表模板，然后项目组成员一起在这个模板的基础上，继续细化，进行详细的WBS，列出要完成这个项目所需要的全部工作，并且把这些工作落实到具体的项目组成员身上，由负责该任务的人来估算自己完成这个任务需要多少时间，而不是由项目经理分配一个完成时间。这就是由底而上的估算办法，这是微软MSF中的估算办法，这个办法有以下好处：

1.  最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。

2.  负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。

3.  做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。

第三步：持续完善模板，持续改进。

每个项目使用模板进行估算后，都可以对模板提出改进建议，把本项目的成功经验融入到模板中，让后面的项目收益。

“傻瓜估算法”非常直接有效，能很准确地估算出项目的工作量。学院派的人士会认为应该先估算出规模，然后再由规模估算出工作量，但我想说的是，估算规模的目的还不是为了估算工作量，如果有办法直接准确地估算工作量，干嘛还要去估算规模，干嘛还要去想功能点法好还是代码行法好？当时我们主任评估师也认可这样的做法，他也认为某些情况下工作量可以直接代表项目规模。CMMI也没有规定非要用什么功能点法代码行法来度量软件规模。

软件的工作量估算是很重要的一项工作，是整个项目成功的基础，用“土方法”也可以把工作量估好估准！

对于软件规模的度量，我们有两层的目的：

1.    能准确地估算出本项目的工作量，为整个项目控制打好基础。

2.    能在不同项目间进行横向比较，为度量组织的生产力打好基础。

如果目标一还没有实现的情况下，就不要直接去追求目标二了，要一步一步来。功能点法、代码行法无疑在理论上是可以同时满足两个目标的，但如果做不到就不要硬来，不要做“拔苗助长”的事情。先把目标一做好了，再考虑目标二。

那“傻瓜估算法”能不能满足目标二呢？

是可以的！做第二步进行WBS进行由底而上的估算时，这些WBS其实是可以分解成功能点或者是代码行的。当公司已经成功用“傻瓜估算法”满足目标一时，可以认真学习以下功能点法、代码行法的精髓，利用这些办法来提高估算的准确率。功能点法、代码行法这里就不详细论述。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

版主您好！

非常精彩的文章。我所在公司目前已经完成了第一步，正在向第二步前进。能否具体讲一下第二步的内容？

 

 

第一步已经为第二步打下良好基础，在第一步的时候，你们有可能根据公司不同业务性质或者不同技术特点的项目，会定下一个到几个估算用的模板。第二步就是直接选用合适的模板，在项目中用起来了。

第二步的关键还是WBS，采用由底而上的估算办法，会遇到很多困难和问题的，如：
1.某些需求不确定，怎样估算？
2.某些技术不确定，如何估算？
3.部分人员喜欢把数字估得很大，为自己预留很多“缓冲”时间，导致项目无法按进度要求完成。
4.部分人员过分乐观，不深入思考，仓促估估一个数字。
.....

具体写下来，内容还是很多的，或者你说说你们具体遇到的问题，看看我能不能针对性地回答？

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

你好： 

     我们公司目前想做软件规模度量。希望能用功能点法对软件规模进行预估。由于之前没有做过，所以不知道怎么开始。对你所说的估算框架和估算模板是什么，没有任何的概念。能否解释清楚一点，并对模板给出相应的例子？

建议先用土办法做好了，再考虑功能点法。

估算框架与估算模板，要和有估算经验的人一起来讨论，这样才能比较好地体会。为公司设计估算过程的人，必须是有实际项目估算经验的，没有实际经验根据一些理论做出来的过程，很难想象是适用的。

之前的帖子中已经大致说明了估算框架和模板的内容了，你再仔细看看？这些内容不是固定的，也不是每个公司适用的，关键是理解道理后应用到自己公司中。

我们online网站一般不会直接给出模板，一是版权问题，另外我们反对"Copy主义"。

参见相关帖子：http://cmmionline.net/forums/thread/830.aspx

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

这个直接估计工作量的方法真的很有意思，以前从来没想过，今天想了一整天，哎，还是没太想通～～

从zhangcb说的那两个目地来看，第一个目地估计规模和工作量真的想不出有什么区别。第二个目地也可以象你说的有了经验在反过来弄。高～～

但是如果直接估计工作量：工作量=资源*进度，可能犯人月神话的错误（一个2KLOC代码的功能不能由50个人1天开发完成）。这里，如果最终要是1个人对多个估计单元应该问题不大，如果是多个人对1个或多个估计单元可能就会有点问题。

但如果用规模：生产率=规模/工作量，你说这个生产率到底起了什么作用呢？

我能想到的一点，生产率提升了，说明效率提升了。

由做这个项目的人来自己来估算自己的任务需要多长时间，“由底而上”的办法，做过软件的人，特别是项目经理都会理解的。

估算的第一目的是保证做好项目计划及项目跟踪，先保证这个，再考虑生产率等高级话题。
第一目标是首要目标，这个实现好了，才考虑第二目标：
1.能准确地估算出本项目的工作量，为整个项目控制打好基础。
2.能在不同项目间进行横向比较，为度量组织的生产力打好基础。

第一目标没做好，就追求第二目标，项目组是不会“理”你的。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

zhangcb您好，我们正在做项目计划，对于项目估算和项目工作量这两个概念，到底有什么区别呢？您帮我解释一下这个区别好吗？谢谢！

项目估算包括的内容有：采购成本、差旅成本、人工成本等，一般来说人工成本是占最主要的，而人工成本是由项目工作量得出的。

没有必要一开始就去深究这些概念，不知道你是不是项目经理？如果你是项目经理，你想想准备做个怎样的计划才能将项目做好？将这些东西写下来就可以了。

项目计划包含的内容很多，很多刚开始做计划的PM，通常想到的只是进度计划，没有关系，由简到繁，慢慢就会掌握了。（PP中其实列出了很多项目计划需要考虑的内容，可以通过工作来慢慢体会）

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

1、那可不可以说“估算人工成本”就是估算工作量？

2、人工成本以什么为单位呢？就是说是以“人月”为单位吗，还是公司自己来定？

问题1：
可以这样认为，工作量乘以一个人工单价，就是人工成本了。
很多公司都会用统一的一个平均值来代表人工单价，我们公司就是这样。但如果想做得更精确，可以根据不同职位或者不同人的水平，来定不同等级的人工单价。

问题2：
以什么单位都可以，人月、人周、人日、甚至人时都是可以的，看看用那个单位更符合贵公司的精度需要。我们公司做估算的时候，要精确到人日，而我们安排进度计划的时候，每个任务的时间要精确到人时。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我们也做过估算,我认为做好估算主要有2个方面的要素:

1.在自己公司内积累历史数据,这些数据在采集时要注意数据的真实性(如工作日志),同时对这些数据的产生背景做详细纪录.这些数据对以后的估算将起到参考指导作用.

2.在估算时参照的基准数据要适合自己公司的能力,如生产率80行/人天等,可以借鉴标杆数据,但一定要适合或贴近自己公司,否则将严重导致估算结果的偏差,也可以在估算结果的基础上做适当的调整

另外,就是要识别由于估算不准确所带来的风险,可制定相应的缓解及应急措施等,这样随着估算次数增加,经验增长,就可以做好估算了.

关于项目估算，想请教楼主，

EPG 根据历史数据做了一个PPB基线，其中有生产率，

目前我们也是采用WBS分解的方法进行估算，

我疑惑的是，用当前的这种方法进行估算，

那统计出来的生产率岂不是没用了？

 

项目估算可以分为两种应用场景：
1.用来招投标的时候用的。
2.用来指导具体项目工作用的。

对于第一种情况，项目通常需求不是很确定的，并且也不知道谁将会是项目组成员，这时有必要利用生产率数据进行估算，这个时候的估算一般只能算是概算。

对于第二种情况，需求应该比较明确，项目组成员也确定。这样，如果还是死抱着生产率来估算，是不太合适的。应该还是根据具体情况来估算，而生产率可以用来参考，而不是决定因素。
生产率实际上是一个统计值，并且只能反应历史情况的。用生产率来估算当前项目，只能大致反应项目的情况，实际上是不够精确的，但可以利用这个数字来校验你们的估算，重新思考你们的估算，但最终还是应该相信你们WBS的分解估算。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

你好，zhangcb，我们公司是外包公司，一般在接项目的时候会用代码行数或功能点数去考虑和客户讨价还价以及能否在预算内接纳项目，但是在实际进入项目的时候进行WBS分解的时候，任务分配一般是项目经理或项目组长去进行分解，但是和你说的由开发者去进行估算还是有较大的差距，因为首先开发者对担当的需求还没有整体的认识，以及他们的估算有一定的保留水分在里面，我感觉由底层开发人员进行WBS分解感觉比较难做。

底层人员去估算并不是让他们瞎估或者大概估算，你提到的问题其实很普遍存在的：
1.底层人员对需求了解不清楚。
2.底层人员可能会给自己预留很多缓冲时间，如5天可以做完的事情，要10天。

对于问题1，其实是项目的风险来的，做这个任务的人不清楚任务的具体内容，是很大的风险。我们通过底层估算就是用来规避这样的风险，要求每个项目成员，在审核计划的时候，就要思考情况要完成这个任务所要面对的困难，让他们尽早知道自己要做什么，而不是在做这个任务的时候，才说这样不行那样不行。

对于问题2，这种情况也很常见，原因除了项目组成员信心不足外，更主要的原因是他们没有能直接感受项目的压力，进度的压力全压在项目经理身上，他们只想自己“舒舒服服”地完成自己的任务。要克服这个问题，就是要培养项目组成员的承担意识，共同对项目负责，分散项目经理的压力，让大家参与到项目管理中来。

一般来说WBS还是有项目经理或者资深项目人士来做的，分解后每条任务的工作量估计，就由承担这个任务的人，还有项目经理共同商量。任务承担者要主动了解清楚任务的性质，做出切实的客观估计，而项目经理要保证任务承担者清楚知道这个任务的具体要求的，给出适当的辅导。通过这样的做法，可以培养项目组成员的管理意识、承担意识，让每个人“提早”了解清楚任务性质，规避风险。

项目估算不是项目经理一个人事情，要让大家都参与进来，每个人都对项目的成败负责。要培养大家参与的意识，发挥各位成员的“主人翁”精神。项目团队建设和公司文化是很重要的，没有好的文化，不管用什么估算方法，都不太可能取得成功。

话说回来，要培养团结的团队文化，是长期的过程，国内的项目组情况普遍就是PM一个人拼死拼活，项目组成员得过且过。稍微好一点的情况可能是：项目组成员会看在项目经理的面子上稍微努力一下。由底而上的估算方法，其实对每个项目组成员的要求都比较高，项目组成员不具备这样的条件前，就不能照搬硬推。
就算在我们公司，每次我们分解任务到具体的项目组成员时，很多项目组成员还是不会去认真深入思考这个任务的，特别是新员工，都是需要我们持续教育和培养的。但一旦让大家都形成这样的工作气氛和工作习惯，这就是一个超强的团队了。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

zhangcb你好，如果度量软件规模的目的是为了计算缺陷密度，你的建议是什么？代码行？工作量？

“度量软件规模的目的是为了计算缺陷密度”，这样说似乎不太对，“计算缺陷密度”是为了什么呢？

至于缺陷密度选择什么做分母，这点你们自己决定吧，我们公司没有度量缺陷密度。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我们公司计算缺陷密度的目的是：

根据缺陷密度的历史数据预估正在开发的软件中可能存在的缺陷数量，进而制定各个测试阶段发现的缺陷数量的目标；

项目结束后，实际的缺陷密度数据也可以作为评判开发质量的一个依据；

目前我们用的缺陷密度的分母是代码行。

为了达到这两个目的，是否有更好的方法？

我们公司有一个缺陷预测模型，可根据标准用例数，输入测试时间，来了估计能发现的缺陷数量，或者是设定一个缺陷发现率，然后估计出需要的测试时间。
我们用这个模型已有3年的时间，但我们从来不是用这个模型的数字来作为质量的唯一标准，或者说这个模型所得到的数字，最多只占我们判断的30%比重。

如果从测试的角度来判断开发质量，应该从以下几个方面去判断：
1.测试是否全面？
一个系统要测的内容很多，但实际上不是全部内容都可以面面俱到的。如果本身测试不全面，用什么缺陷模型、缺陷密度等指标，意义是不大的。
我们公司每个项目都会有详细的需求，并会编写详细的测试方案，哪些部分需要测试，哪些部分不需要测试，都会写得很清楚。这些需求、测试方案等需要开发和测试一起来评审。如果要保证测试质量，则应首先保证需求质量，然后是测试方案的质量，而需求质量、测试方案质量不是什么指标能说明问题的。
2.测试是否深入？
测试可以只走冒烟测试，也可以只走正常用例，也可以连异常用例、边界用例全部执行，不同的测试深入程度，对测试质量来说是不同的。但我们测试，往往是不能所有地方都执行最高强度的测试的，肯定会有取舍，测试方案里面要考虑测试强度问题，重点的核心的地方要执行高强度的测试，而其它地方可以简单测试甚至不测试。同理，测试深入程度也不是靠一些指标可以搞定的。
3.回归测试的广度和强度如何？
很多公司并不会执行100%的回归测试，一般我们只会测试可能受影响的部分，并且测试的强度也不会很大。回归测试的广度和强度，其实也是靠我们项目组自己判断的，往往也是开发告诉测试，什么地方可能受影响，我们测试就去测一下。自动化测试能帮助我们做不少回归的工作，但自动化程度一般都不高。回归测试的广度和强度，也同样不是某某指标能搞定的。
3.缺陷情况。
有些缺陷很严重，有些缺陷很低级，有些缺陷重复出现，有些缺陷消灭后引发其它缺陷，这些情况都可以反映出开发的质量。在我们公司，低级缺陷（如按按钮就出错）、重复缺陷、修改缺陷后又引发新缺陷，这些都是被严格控制的，凡出现这样的情况，均认为质量有严重问题。

我们都尝试用一些量化的方法，对项目的质量情况有比较好的把握，但从我们的实际工作经验看来，不能光靠量化方法。以上提到的1、2、3点，都需要定性去判断，量化的方法只是辅佐的方式。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx