你的位置:软件知识原创基地 >> 知识海洋 >> 项目管理 >> 详细内容 在线投稿

软件度量都该度个啥?

排行榜 收藏 打印 发给朋友 举报 来源: 原创   发布者:张传波
热度4086票  浏览1890次 时间:2009年9月15日 16:27

摘要

这年头IT界流行“用数据管理过程”、“用数字说话”,软件度量成为热点话题!一方面一堆专家在“哗众取宠”,而另外一方面企业在推行软件度量的实践中遇到了各式各样的问题,软件度量在软件企业中的实施效果不甚理想。一个软件企业应该从何做起度量工作呢?希望本文能给大家带来有益的启发!


特别声明:
如需转载此文,请给出指向本网站的连接,如下:
作者:张传波
摘自:http://www.umlonline.cn
如不能按此要求,请不要转载此文。


形形式式的度量陷阱

N年前,老板对我们过程改进工作曾指示:能量化的工作尽量量化,不能量化的就不要勉强。当时觉得这个指示非常好,我也相信这个观点很多人都会认同。实际上应该是这样吗?软件度量就必须用数字来说明问题吗?量化的结果一定比非量化的结果更准确客观吗?

没有一套好的度量工具,很难做好度量工作!这是很多人的认识。而一些度量工具的生产厂商,更加是大力渲染,目的还不是为了更容易从软件企业的口袋里面掏钱呗!要做好度量工作,真的需要一套强大的度量工具吗?

处于手工作坊的软件公司,难以进行软件度量,软件度量只能在有一定过程基础的公司进行。另外,对于小公司、小项目没有度量的必要,度量更适用于大公司、大项目。是这样吗?难道小公司、不规范的公司、小项目就不能利用软件度量来改善生产力吗?

软件生产活动是智力活动,要客观度量是很难的,要做好将会是很花成本的事情,而且开始阶段要忍受比较高的成本,软件度量所带来的效果,需要长时间才能体现。软件度量难道就没有立竿见影的效果吗?难道软件度量是大公司、有钱公司才能玩得起吗?

形形式式的度量陷阱,还远不止以上这些呢!

 

什么是度量?

我一直想搞清楚度量的定义,在网上查了一大轮,只能找到一些让人看了还不如不看的“学院派”的定义。搞清楚什么是软件度量,非常重要,将会让我们少走弯路,直接发挥度量的价值。看看下面我对度量的定义:

度量是这样的一种活动:基于一定的目的,采用一定的办法或者标准,对目标事物进行观察,得到客观的评价结果,根据评价结果,采取适当的行动。

这个定义,反应了度量活动的四个要素:

1.    基于一定的目的。

2.    采用一定的办法或者标准。

3.    得到客观的评价结果。

4.    采取适当的行动。

下面我们以度量水的温度为例来体会一下度量的定义。

如果有人给你一个度量任务,要求你度量水的温度,你会怎样做?

你会不会马上想到用温度计?

不好意思,如果是这样,你就落入了度量的其中一个陷阱了。你应该先问,为什么要度量水的温度?不同的目的,做法是不一样的。

如果度量的目的是为了判断煲水的时候水是不是开了。你还会用温度计吗?当然你可以用能测量一百摄氏度的温度计来度量水的温度,但我们更多的会用肉眼观察水的形态,来判断是否水开了,如果想更简单一点的,买一个水开的时候会响的水壶或者是搞个饮水机就可以搞定了。

如果度量水的温度,目的是希望水温合适,好帮BB洗澡呢?有些妈妈会用温度计,有些妈妈会用自己的手直接去感觉水温,两种办法都可以。

一个小小的度量水温的问题,都很有学问,大家发现,不同的目的下,做法是不一样的。有些做法很简单实用,不需要什么专门的工具,直接用手感觉温度,或者肉眼观察就可以了。相反,如果我们搞不清目的,就很可能杀鸡用牛刀,甚至是受到伤害,一个不小心,你就可能直接用手去感觉开水的温度了。

另外我们也发现,度量的结果不一定都是数字来的,只要满足目的,越简单越好。水是否开的问题,我们只需要知道水是否开了就可以了,度量结果只有两个:是或者否,我们不需要知道这水是摄氏多少度。度量并不需要很精确,满足目的就好!

度量的目的不是光为了得到一个结果,而是要根据度量的结果采取行动。如果妈妈发现水温不够,她会加入一些热水,如果觉得太热,就会加入冷水。这些行动的目的就是为了让BB有适合的水温洗澡。

 

首先应该度量的指标——公司的效益指标

如果要做度量工作,最开始应该度量什么呢?我建议应该首先度量公司的效益,度量效益的目的是对公司生产力状况有一个准确的认识,更准确地分析出问题所在,为决策提供更准确的依据。

那么公司的效益该如何度量呢?

公司有两大生产力指标,成本与收入。公司近一年的总体成本,包括人工、采购、水电费、房租费等全部费用加起来,财务肯定会有这样的一个数字。公司近一年所有人员的工作时间,所有人员包括开发、测试、行政、财务等,凡在公司的工作的所有人,这些人上了多少天的班,一定也会知道,每个公司都有考勤请假的记录吗,就算没有也可以大概估算。这样我们可以得到公司全部人员一年的总体工作时间,单位是小时。这样我们有这样的一个指标:

成本指数 公司总费用/总工作时间,单位:元/小时

这个数字表明,在这个公司工作的每一位员工,每工作一个小时,其实是需要这样的一个成本的。没有算的公司尽快算算,你可能会发现,原来这个数字还相当大呢,远远超过这个人的时薪。

关于收入,我们有这样的一个指标:

收入指数 = 公司总收入/总工作时间,单位/小时

这个数字表明,在这个公司工作的每一位员工,每工作一个小时,为公司带来多少的价值。

如果收入指数大于成本指数,说明公司是在赚钱的。公司的生产力就可以看这两个数字了,我们希望尽量降低成本指数,尽量提高收入指数,于是我们会得到下面这个指标:

效益指数收入指数:成本指数

企业最终追求的是提高效益指数,成本大没关系,效益指数高就没问题了。这些指标都可以继续细化,如:可把成本分类,成本会分成人工成本、非人工成本,人工成本有可以分为工程类人员人工成本、支持类人员人工成本等,经过细分,可以发现自己的成本构成不合理的地方,进行相应的改善。如:把收入细分,看看收入的组成,收入都是由哪些部门哪些人产生的,这些都能帮助企业提高收入。

公司的效益指标的度量是任何公司都可以做的,而且应该是第一时间就要做的度量,并且要持续地做的。公司所做的任何工作,市场活动、过程改进工作、度量工作等等,最终目的还是为了提高效益指数!

 

每个软件公司都可以并且应该做好的度量——缺陷度量

就算一个开发极不规范公司,我想总会对缺陷有一定的管理办法吧?至少缺陷会被记录下来(哪怕是各种方式),而不会只是口头说而毫无记录吧?

大多数软件公司都会有一套管理缺陷的系统,我们应该如何把缺陷度量做得更好呢?

我们需要目标驱动地把度量工作做好,首先有两个最基本的要求:

1.    缺陷被准确的记录和跟踪。

2.    客观地依据缺陷状况对软件发布进行决策。

根据这两个要求,我们需要详细定义缺陷的属性,这些缺陷的属性就是我们要度量的内容。很多公司都会定义缺陷的描述、严重程度等属性,另外也会规定发布的时候,什么严重级别的缺陷不能超过多少个等要求。

以上两个目标只是缺陷度量的两个基本目标,如果更深入一点,我们希望能预防缺陷的再次发生,最简单有效的办法就是:直接让项目组成员一起来分析缺陷的原因,让大家避免重犯。

如果想做更系统更深入的分析,就需要考虑在组织层面来做这个分析工作。这时有必要增加缺陷一个属性,叫做“缺陷来源”,就是说产生这个缺陷的源头是在哪里,是需求没有分析到位,还是设计没有做好,还是编码出问题?按“缺陷来源”来分析公司不同类型的项目的缺陷情况,您就会发现公司的软件开发过程最有问题的是哪个过程?哪些过程做得比较好?这些分析结果会很好的指引过程改进的方向。

缺陷度量有很多可以发掘的地方,这是每一个公司都应该做好也是最有条件做好的一种度量。

 

成功的基础——软件规模度量

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

我们为什么要进行软件规模度量呢?目的无非是:

1.      作为报价或者决策的依据。

2.      安排具体的项目进度。

3.      可以作为组织的生产力数据,可以有很多用途,如:各项目间横向比较,供以后项目参考等。

如果是为了投标报价,建议用Delphi法,功能点法、代码行法太慢了,不能适应商战社会,投标经常是没有这么多时间让你去折腾的。Delphi法的大致方法如下:

1.      找几名资深专家,一起对项目进行WBS,把项目的工作分解为十几条最多二三十条的工作项。

2.      全部专家各自估计每条工作项的工作量,并向其他专家阐述自己的理由。

3.      第一次各专家估出来的结果可能差异比较大,每位专家听取别人的意见后,重新估算。

4.      按照上述办法,各专家反复估算几次,一般次数就是2-4次,各专家估计的工作量会越来越趋近,这个时候取全部专家的平均值。

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

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

软件开发活动,可以分类以下几类:

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

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

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

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

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

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

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

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

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

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

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

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

第三步:持续完善模板,持续改进。

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

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

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

如果要满足目标3,即作为组织的生产力数据,应该如何度量呢?

满足目标3之前,我们应该保证我们能满足目标1和目标2,如果目标1和目标2都没满足的情况下,我们就去追求目标3,是有点“超前”,这种“超前”对公司来说可能是“拔苗助长”。当然我们希望有一种方法能同时满足这三个目标的,但到目前为止,我还没有见到过这样的成功案例。软件规模度量还是要一步一步来,不要一开始就期望吃成个“胖子”了。

如果在“傻瓜估算法”的基础上多做一步,我们是可以满足目标三的。在第二步进行WBS进行由底而上的估算时,这些WBS其实是可以分解成功能点或者是代码行数。我们可以利用这些WBS得到两个输出,一个是工作量,一个是功能点或者是代码行数。如果积累了一定的数据,就可以建立功能点或者代码行数与工作量的对应关系,这样不仅可以用来衡量公司的生产力,也可以利用这些经验数据来估算以后的项目。


TAG: 软件度量
顶:245 踩:323
对本文中的事件或人物打分:
当前平均分:-0.49 (1203次打分)
对本篇资讯内容的质量打分:
当前平均分:-0.54 (1140次打分)
【已经有1175人表态】
222票
感动
131票
路过
121票
高兴
118票
难过
137票
搞笑
134票
愤怒
160票
无聊
152票
同情
上一篇 下一篇
软件知识大学