51Testing软件测试论坛

标题: 关于工作量度量的调查总结，也请大家指点 [打印本页]

作者: sunlight0124 时间: 2009-9-28 15:11
标题: 关于工作量度量的调查总结，也请大家指点
领导让我找一个能度量开发人员工作量的方法，我查找了很多资料，实例，感觉都不适用，最终总结，觉的工作量的度量，要把“感性分析”和“量化分析”混合起来使用，只要企业内的大部分人觉得合理即可。
我顾虑，领导会说“你小子，找了半天都没有找到，还找借口没有准确度量的方法！”
请大家，指点一下，有没有准确度量的方法呢？？？

工作量度量，有关软件度量的方法有很多，但是我看了好久，感觉都不可靠。也许是我的经验不行吧，呵呵。
总结：
对于工作量度量业界很多是用数学公式来计算，可能数学公式更加的客观和科学。
但是看看市面流行的计算方法吧：
最常见的是基于代码行的数学模型，那么这里存在不少问题，工作量估算主要是为了在项目进行中进行有效的项目监控，那么软件开发尚未结束，谁知道最后的代码行有多大？代码经常会被修改，那么修改的代码算不算？如果算，那么代码修改越多难道能说明工作量越大？代码效率的区别也是很大的，假如一个10行代码可以实现的东西被写成50行，难道能客观的反映工作量？
还有疑问就是，代码行分析方法就是就是对软件产品的源代码的行数进行测量，但是是计算物理行数,还是程序的命令数量?
　　空行是否计算? 注释是否计算? 预定义文件是否计算? 不同版本如何计算?
　　这里面是否设计到一系列的规则定义问题?
　　开发过程种的配置脚本,编译脚本是否计算?
　　共享文件(例如共享的开发库文件种的头部文件)如何计算?
对于这方面我也查了很多资料，但是都没有很好的办法。
还有2种比较高级点的方法是基于功能点和COCOMO的方法，那么它们的公式中的系数该怎么定？不少人都说，根据自己的实际情况来定呗，但是觉得这些都需要相应的成本和工作投入，而且可靠性并不一定能得到保证。也许得靠经验的积累吧。
所以感觉工作量的度量还是要靠人的经验来估算，大家可以在项目周会上对工作量进行充分的估算，在估算时要同时考虑到项目执行的难度，根据经验给出合理的评估。

研发人员从事智力创作，不像民工那样可以采用简单的“计时、记件”方式来衡量业绩，也无法像销售人员那样可以用“明确的数字”如“销售额或销售毛利”来衡量业绩。
研发人员的“工作量、工作难度、进度延迟率、工作成果质量、工作态度”都会影响业绩，如果要用一系列指标来衡量研发绩效，每个指标的权重可能是不同的。
目前业界不存在最优的或者是标准的研发绩效评估方法，无法用数学公式（即完全量化方式）来评价智力创作过程。我们不必追求精确的评估方法，只要企业内的大部分人觉得合理即可，通常要把“感性分析”和“量化分析”混合起来使用。
感觉这些度量方法，都是理论的，要实施是很麻烦的，需要大量的记录文档，会占用时间和人力。

附录：
简介代码行分析方法：
代码行(line of code)指所有的可执行的源代码行数，包括可交付的工作控制语言(JCL：job control language)语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。
一代码行(1LOC)的价值和人月均代码行数可以体现一个软件组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。
代码行LOC（源代码行数）常用于源代码的规模估算。
简介功能点分析法：
功能点分析法(FPA：function point analysis)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。
从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：“在外部式样确定的情况下可以度量系统的规模”，“可以对从用户角度把握的系统规模进行度量”。功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。
简介COCOMO模型：
COCOMO,英文全称为constructive cost model,中文为构造性成本模型.它是一种精确、易于使用的,基于模型的成本估算方法。
从本质上说是一种参数化的项目估算方法,参数建模是把项目的某些特征作为参数,通过建立一个数字模型预测项目成本(类似于居住面积作为参数计算的整体的住房成本).

[ 本帖最后由 sunlight0124 于 2009-9-28 15:51 编辑 ]

作者: sunlight0124 时间: 2009-9-28 16:45
标题: 回复 2# 的帖子
恩，最终是要给领导看的，我也会再整理的。
你说的这些，是不是需要大量的文档记录呀，这样会占用开发人员的时间，我觉得不该让组员为了与产品无关的事情疲于奔命，被外界的杂事干扰正常的进度，以致项目进度不断延误，甚至停滞不前了。
应该让开发人员永远记得自己真正的目标，然后让团队用最有效又最愉快的方法把它完成.
所以感觉工作量的度量还是要靠人的经验来估算，大家可以在项目周会上对工作量进行充分的估算，在估算时要同时考虑到项目执行的难度，根据经验给出合理的评估。
把“感性分析”和“量化分析”混合起来使用，只要企业内的大部分人觉得合理即可
不对吗？？？

作者: sunlight0124 时间: 2009-9-30 12:25
标题: 回复 4# 的帖子
计划游戏我看了，其本质是划分客户和开发人员之间的职责，客户决定特性的重要性，开发人员决定实现一个特性所花费的代价。
感觉和工作量的度量联系不大呀！

作者: sunlight0124 时间: 2009-10-13 10:46
标题: 回复 6# 的帖子
计划游戏我看了，看的是《敏捷软件开发：原则、模式、实践》上面的。至于你说的story point我没有找到具体是什么，是和功能点有关的吗？
计划游戏的本质是划分客户和开发人员之间的职责。客户决定特性的重要性，开发人员决定实现一个特性所花费的代价。客户会了解开发人员的开发速度，能够确定项目会持续多长时间，以及会花费多少成本。
感觉计划游戏跟度量的关系不大呀。
我现在的感觉是软件生产活动是智力活动，要客观度量是很难的。
当然要做好将会是很花成本的事情，而且开始阶段要忍受比较高的成本。
软件度量所带来的效果，需要长时间才能体现。
软件度量难道就没有立竿见影的效果吗？
难道软件度量是大公司、有钱公司才能玩得起吗？

作者: sunlight0124 时间: 2009-10-13 14:04
标题: 回复 8# 的帖子
说是这样说，但是客户的需求要求开发一个星期完成任务，这时还是靠开发人员赶进度了呀。
还有就是需求难度的问题了呀，需求难度大了，这个迭代周期时间肯定需要延长了。
再说这些story的point主要是靠人来估算吧，一些估算还需要有经验数据能帮助才能做好估算，但核心问题还是做估算的人的知识、经验和能力。
其中还有考虑各个开发人员的能力，任务情况。
还有我觉得即使这个story point 可以，但最多只能用来参考。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)