简单看软件开发度量

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/u011250455/article/details/78144179



大部份管理者都说关心项目的延误(或项目总工作量),也说很关注产品的质量(例如:金融/银行 /保险等)。
但是当问到过去一年项目的实际延误情况如何?产品质量如何?
很多管理者没有头绪。
怎样做才能解决上述问题呢?


做好项目估算(estimation)

管理者说:项目经理都有做预估——按每个项目功能数量,识别其中的复杂度,再乘以相关的生产率便得出项目的总工作量(人天),难道这样不是做好了项目估算吗?

解答:
复杂度怎样制定/定义?
生产率用多少?依据是什么?
过程有没有记录?

(聪明的您应可猜后面的对话,. . . .注意:我接触过的,用公式来估算的公司已是很少,更大部分是直接“估算”项目工作量和工期)


软件开发估算为什么不简单?

一个好的估算应该是不同的人做出来的差不多。但现实是,有很多因素会影响,例如:

项目规模的大小,会因为理解不同,估算结果也不同。

此外,人手与生产率的关系是否成正比?增加一倍人手,生产率就提高一倍吗?

其实软件开发中有不同的阶段,生产率在编码时候达到高峰,但到了系统测试阶段,因没有新增代码,生产率反而变下降,所以在软件开发中,用以下的基本方程没有想象那么简单:
 工作量= 规模 /  生产率
 成本(人力) = 工作量 * 人工率


日常我们进食时会考虑食物的卡路里;
使用汽油时会考虑汽油每公升可跑多少公里;
使用电脑时,会考虑它的CPU速度
以上的度量有三个共同点:
     - 都是直接可看见或可数得出的
     - 95%以上的人都会觉得重要
     - 低于1%的人会了解背后的真正计算方程式


既然关心进度、生产率、质量等,让我们看看软件开发可以如何做好度量与估算:

从管理角度,软件开发主要关心下面几个指标:

-    Schedule 时间 / 进度
-   Effort 工作量 / 成本
-    Size 规模大小
-   Quality 质量
-    Process Productivity 生产率
它们之间的关系在30年前已经有人研究过了:关系是一定有的,但并非简单的线性关系,还会因项目性质不同、行业不同等,有很大差异。



所以没有一套全球通用的计算法则,但公司可以依据下图:


先估算项目的总规模 (图左上角),依据以往历史项目数据,调整预测模型 (calibrate),便可以估算出项目的时间、工作量和缺陷率等 (图右面的估计)。


备注一:团队人数——如果是几个人的小团队时候,通常是所有人从头到尾参与项目,这些人的个人生产率高低会影响项目进度、工作量等,即影响图的右面,所以个人生产率也是其中一个输入。如果是大型项目人数会从少到多,达到一个峰值,再减少;项目高峰时的人数会影响右面的估算。

备注二: 软件规模——估算应该在每个主要阶段都要做,例如:开始时要进行初步估计;需求确定后,可依据功能点进行具体估算;开发完成后,可以从实际代码算出规模。不要把规模和项目总人天混淆,因前者和人员的能力无关。


问题:这种度量方法是否只适用于传统的大型开发项目,但我们现在很多项目都走迭代和敏捷,是否还适用?

回答:

虽然这些是依据传统的中大型项目得出,但道理是一样,但需要变通。因在敏捷中,一般团队人数少而且较固定,所以是估计整个项目的所需时间(多少次迭代)。

以前分阶段的工作(需求、设计、编码、测试等)都合在一个迭代中,简单来看可以看成把N个瀑布叠在一起,每次包含了瀑布的所有阶段,例如以前缺陷是分到不同阶段中(单元测试、集成测试、系统测试),现在每次冲刺可能只记录了最终的缺陷数。

每次迭代测试找出来的缺陷数,下一次同类的迭代,预计缺陷数也类似。


大家可以利用以上的框架不断收集公司的历史数据优化。便可以有系统地改善项目的估算模型。


问题:如何度量软件开发的规模大小?
回答:

最早是用代码行,但有不少缺点。

从70年代开始出现了功能点数,它解决了:可否重复 (repeat)、可否全项目周期前后都适用等不足。
但有些人觉得比较复杂,要花时间学习。
可能正是这原因,在敏捷中出了很多规模/总工作量估算的简化版:故事点、 T恤码、扑克牌. . . 但主要依靠团队一起判断,缺乏公司级历史数据,与公司生产率标杆的概念。


问题:为什么我们建议使用功能点来估算规模?

回答:

无论做任何事,都是一个从0到1的过程。首先建立0,再向1前进。
用功能点来代替故事点或者代码行,只是一个零的概念,就他们两个是对等的,因此实现了之后并没有增值。
但如果指出做了功能点之后,到底又会发生什么事情?而这些事情是原来完全做不到的,那么这时候就出现了1。

从实际应用层面来看,使用了功能点以后:
我们就可以横向比较公司和团队的生产率,从而进行绩效管理;
从质量的角度,规模可作为质量的分母,可以算出每功能存在多少缺陷数;
也可以让客户更理解项目的大小,用来合理地报价。



一位老师很开心地说:“本来以为功能点要教个两三天,但昨天在一堂课中只花了两个半小时便简单地教懂了。开发主管很感兴趣,希望再安排现场辅导。”


总结


度量与估算可能一直都是困扰软件开发管理者的一个重要课题,但总觉得太复杂,以上我们分享的只是冰山一角。
Weinberg先生在《咨询的秘密》中说得好,如果过程中所需的数学是高数程度或以上,你应该问问自己是否需要?
度量在软件开发中一直未被重视其中主因是太复杂了,人们搞不懂所以就不用。

这方面,我们急需的不是如何利用大数据分析、神经网路、machine learning  等把估算的准确度降低10-20% ,而是如何简单地让大家做项目管理的快速用上。


如果您正好有这方面的需求,我们会有一系列关于度量与分析、估算的FAQ/模板等, 让大家可以快速简单地用于项目中。
有兴趣,可到我们网站:http://www.processis.org/Home/Index/coursesflist看相关的培训信息,也可以以下列方式联系我们,获得资料。


联系我们

电话: 18921395967 QQ: 1228021190 微信: processis2009 地址: 香港/北京/江苏 官网: www.processis.org 邮箱: [email protected]


本文感谢陈勇老师拨冗斧正。


猜你喜欢

转载自blog.csdn.net/u011250455/article/details/78144179