软件度量都该度个啥?(3)——软件规模的度量

zz/2024/6/13 21:24:23

摘要

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


大纲:

1.形形式式的度量陷阱(1)
2.什么是度量?(1)
3.首先应该度量的指标——公司的效益指标(2)
4.每个软件公司都可以并且应该做好的度量——缺陷度量(2)
5.成功的基础——软件规模度量(3)
6.项目跟踪的利器——进度度量、成本度量(4)
7.被吹得最多的六西格玛管理(5)
8.量体裁衣、身体力行(5)

我将分5篇为你分享,大纲后面的数字表示将在第几篇分享该部分内容。

 

 

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

 

曾经有这样的一个辩论,功能点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得到两个输出,一个是工作量,一个是功能点或者是代码行数。如果积累了一定的数据,就可以建立功能点或者代码行数与工作量的对应关系,这样不仅可以用来衡量公司的生产力,也可以利用这些经验数据来估算以后的项目。

 


请看下一文……



作者:张传波

创新工场创业课堂讲师

软件研发管理资深顾问

《火球——UML大战需求分析》作者

www.umlonline.org 创始人

 


http://www.ngui.cc/zz/2748872.html

相关文章

IT行业常见职位职业路线图

我曾经面试过一些计算机相关毕业的应届生,问他希望做什么工作时,他回答只要是软件开发就好了,再细问一下你了解到的软件开发是怎样的?除了软件开发,还有其它什么工作?就答不出来了。 这里我先给出一张IT知识…

3.6 CMMI3级——确认(Validation)

验证强调的是在开发过程中对工作产品进行检查,尽早发现问题。而确认强调的是,在真实的使用环境中,确保软件能达到预期的效果。开发环境与真实环境是不可避免存在差异的,为了有效地避免在开发环境中没有问题,但一到真实…

1.2 《硬啃设计模式》 第2章 学习设计模式需掌握的UML知识

要看懂 设计模式,你需要懂 类图(Class Diagram),也需要懂一点对象图(Object Diagram),下面介绍一些 UML的必要知识,以便你学习设计模式。 属性、操作 下图简单介绍类的属性和操作…

3.8 《硬啃设计模式》 第17章 结构型设计模式小结

序号模式一句话说明1桥(Bridge)将“抽象”和“实现”自由搭配。2轻量(Flyweight)轻松地处理“大量”对象。3外观(Faade)同时提供简单接口和复杂接口。4装饰者(Decorator)不改变接口但…

5.3 CMMI5级——原因分析及解决方案(Causal Analysis and Resolution)

聪明的人在出现问题的时候,除了解决问题外,都会想到如何避免问题以后再次发生,避免的办法可能是从过程或者技术两个方面入手,从根本杜绝问题的发生。 问题分析是很常见的,为什么在5级的时候才有这样的要求呢&#xff1…

敏捷需求分析及深度提升(广州 2014.1.11)- 活动报道

这次活动已经顺利开办啦,谢谢大家的支持! 以下是图片花絮: 此活动的原始报道链接: http://www.umlonline.org/school/viewthread.php?tid2700

全能项目经理训练营-张传波-专题视频课程

立即学习:https://edu.csdn.net/course/play/24657/276936?utm_sourceblogtoedu

为什么企业宁愿开高工资给新员工,都不愿意给老员工加工资?

有朋友问到: 为什么企业宁愿开高工资给新员工,都不愿意给老员工加工资? 俺的建议: 先从这位被低薪压制的老员工角度说说: 决定你的薪资水平的根本原因是你的实力,而影响因素是你的性格。为什么说是你的性…

2016峰会:项目管理与高级项目管理 - 图片花絮

现场相片大汇杂: 签到、学员入座、暖场: 老师激情分享中: 给力的参会朋友: 精彩瞬间: 大会现场视频已经发布啦: 猛点图片进入课程学习啦! 高级信息项目经理实战班 (广州站&#xff…

部门赶工,团队成员都积累了上百个小时以上的调休时间,如何调休?

有朋友问: 部门赶工,团队成员都积累了上百个小时以上的调休时间然后闲下来了,调休潮来了批准太多,怕影响不好不批准嘛,这些时间难消采用每月每人只准调一次,每次同时调休人员不得超过20%的人数这样处理&am…