收到一位网友的E-mail,询问如下的问题:
”不少资料里面都提到"开发的度量结果不应成为奖惩的根本依据". 但我们实际的项目组在操作时,免不了会根据度量结果来评价一个开发人员的绩效,例如SRS文档的缺陷率有无达到质量目标?等等. 也有的人支持根据有效的度量数据来考核开发人员的工作绩效. 不知道你是怎么看这个问题的?“
遂总结了一下自己的理解:
"开发的度量结果不应作为奖惩的根本依据"的根本原因在于
"质量天生具有的不确定性"。因此,没有人可以肯定开发过程中达到了质量目标(如SRS缺陷发现缺陷率)软件的质量就会好。
如果仅以过程中的质量目标达成情况来衡量开发人员的绩效是片面的<wbr></wbr>,会抹杀一部分责任心很强员工的积极性,比如一位员工<wbr></wbr>,不管是SRS、HLD、CODE、UT等等在检视或测试的过程中<wbr></wbr>发现的缺陷都是最少的,谁能说他的质量不好或者绩效不好<wbr></wbr>,很有可能他是团队中质量最好的一位。
过程中的度量,如SRS缺陷发现率的作用主要是用来牵引项目组在进<wbr></wbr>度和质量保证活动投入工作量(如检视/单元测试等)中进行均衡<wbr></wbr>,防止项目组盲目的追逐进度。如果某个模块的质量目标没有达标,需要分析相应的检视或测试活动的<wbr></wbr>工作量投入情况,看看是否由于工作量投入不足引起的<wbr></wbr>,对于工作量投入不足造成的情况,必须打回。
衡量项目成员绩效还有很多其他的方法,其基本的原则应该是鼓励员工<wbr></wbr>对于质量的责任心,如:
1、收集每位成员参与检视活动发现的缺陷情况,进行相应的排名<wbr></wbr>,鼓励积极参与检视活动
2、评比文档或代码检视缺陷发现率最少的模块或个人(质量最好的那个)<wbr></wbr>,评比不建议直接看数据,因为对于一个尚未成熟的团队大家在反馈检<wbr></wbr>视意见时有时存在比较随意的情况,可以采用直接让大家评比的方式<wbr></wbr>。这样做可以鼓励大家在提交检视时进行充分的自检<wbr></wbr>,而不是完成一个半成品就甩给别人去帮忙查找错误。
3、或者更为简洁或更有效的做法(我自己的做法)是要求项目经理亲<wbr style="color: rgb(0, 0, 255);"></wbr>
自查看每篇文档,自己评判,如果一个项目经理没有看过大家的文档仅<wbr style="color: rgb(0, 0, 255);"></wbr>
仅依靠质量目标的达成情况来衡量大家的成绩,是一种对团队对质量极<wbr style="color: rgb(0, 0, 255);"></wbr>
不负责任的做法。不过要说服这样的项目经理刚开始有些困难<wbr style="color: rgb(0, 0, 255);"></wbr>
,不妨一边不停的在他耳边说(最好是有其他的优秀的项目经理作例子<wbr style="color: rgb(0, 0, 255);"></wbr>
),一边自己看项目组的文档,拿出实际情况给他看<wbr style="color: rgb(0, 0, 255);"></wbr>
,这样做还有一个好处,就是QA比PM更清楚项目组文档或代码的质<wbr style="color: rgb(0, 0, 255);"></wbr>
量状况,在和更高级的领导一起交流时QA会比PM更显得有理有据<wbr style="color: rgb(0, 0, 255);"></wbr>
,久而久之这位对团队质量状况以及成员都不了解的项目经理自己都会<wbr style="color: rgb(0, 0, 255);"></wbr>
惭愧的。 QA以旁观者的身份和项目经理一样,有挖掘优秀项目成员的义务。4、将最终结果(遗留缺陷密度)也纳入进来,以结果为导向<wbr></wbr>,任何人都没有什么好说的。即使短期内过程质量目标没达标的项目成员会受些委屈<wbr></wbr>,但最终他会得到肯定。
以上的几点最好一起用。
质量好坏的最终责任在于项目组本身,不是QA。QA的目标始终有些悲哀,我理解的终极目标是:让QA从项目组消亡<wbr></wbr>。消亡不是被项目组赶走,而是树立项目组自己的质量意识以及相应的<wbr></wbr>方法,在项目组达到不需要QA也可以自行良好的运作的时候<wbr></wbr>,QA就可以撤退了。所以,在一个好的项目组中作QA<wbr></wbr>,远不如在一个较差的项目组作QA,所学到的东西多<wbr></wbr>。当整个开发组织的所有项目都不需要QA也可以良好运作的时候<wbr></wbr>,我们QA就可以考虑转行了,呵呵,不过好像还比较遥远!
作者:fasiondog
来源:
http://blog.csdn.net/kongdong/
分享到:
相关推荐
项目组织度量绩效指标库.xls
基于java的开发源码-软件度量源码.zip 基于java的开发源码-软件度量源码.zip 基于java的开发源码-软件度量源码.zip 基于java的开发源码-软件度量源码.zip 基于java的开发源码-软件度量源码.zip 基于java的开发源码-...
该文档对软件项目开发管理过程中的度量指标进行了详细介绍
软件工程 软件开发成本度量规范 架构师 开发工程师 造价工程师
软件工作量估算是软件项目管理的重要组成部分之一,功能点度量方法逐渐成为该领域的主要方法....量度量结果,便于项目管理人员控制软件项目活动,合理安排人员等资源,可以在一定程度上解决软件项目频繁超支和超时的问题
软件度量是指计算机软件中范围广泛的测度。测度可以应用于软件过程中,目的是在一个连续的基础上改进它。测度也可以用于整个软件项目中,辅助估算、质量控制、生产率评估、及项目控制。最后,软件工程师使用测度能够...
与此同时,软件项目规模的不断壮大、功能的增强和复杂度的增加,软件的成本、进度、质量也变得更加难以控制,这使得软件差错的经济代价和社会代价不断上升。因此,如何生产出高质量的软件产品成为软件产业生死牧关的...
软件度量的目的是为项目管理提供项目的执行情况的充分可见性,并使项目管理者了解项目实际进展与项目计划之间的偏差,以便采取纠正行动,保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。此...
并取得良好效果,尤其是在电子政务、军队、金融、通讯、能源、交通、制造等领域,基于历史数据及估算模型的量化软件成本评估方法大量应用,越来越多的用户单位开始依据行业标准和基准数据对软件开发项目进行成本评估...
本资源包含两个文档,一般产品的开发过程,华为的IPD流程
1 项目管理 3 11 项目立项过程 3 12 项目策划过程 3 13 项目监控过程 4 14 风险管理过程 5 15 需求管理过程 6 16 项目结项过程 6 17 量化项目管理过程 7 ...34 度量分析过程 17 35 原因分析与解决过程 18
软件度量是对软件开发项目、过程及其产品进行数据定义、收集以及分析的持续性定量化过程,目的在于对此加以理解、预测、评估、控制和改善。没有软件度量,就不能从软件开发的暗箱中跳将出来。通过软件度量可以改进...
CMMI3级项目 度量与分析(MA)过程域培训 .ppt文件
常见软件项目度量指标
传统金融与互联网金融风险度量和绩效评价的对比研究——基于EGARCH-GED模型的VaR方法.pdf
项目度量 项目度量是针对软件开发项目的特定度量,目的在于度量项目规模、项目成本、项目进度、顾客满意度等,辅助项目管理进行项目控制。 规模度量 软件开发项目规模度量(size ...
软件过程和项目度量2022优秀文档.ppt
本文描述在需求管理过程中如何有效设计度量体系和指标
利用沪深300指数实证发现, 投资组合的夏普比率与时间标度存在关联, 基于基准标度推导获得的多标度夏普比率存在非系统性误差, 导致资产组合绩效度量产生偏差. 在此基础上, 研究探讨了引致夏普比率非系统误差的原因, ...
基于深度度量学习的行人重识别方法.pdf