员工工作量评估 _第1页
员工工作量评估 _第2页
员工工作量评估 _第3页
员工工作量评估 _第4页
员工工作量评估 _第5页
已阅读5页,还剩4页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

精品文档2016全新精品资料全新公文范文全程指导写作独家原创1/9员工工作量评估员工工作量评估今天刚刚进行了一个小软件的工作量评估,总是觉得评估的不够准确,而且难以明确,把心中的困扰跟实际所使用的做法简单说说,工作量评估中,困扰我的问题主要有以下几个1、需求不清晰,并且会有变化2、工作量评估在需求规格说明编写的同时就需要进行,一般来说,没有立项,就还不会做详细的需求调研,但这时候就要出工作量评估3、系统架构及设计没有开始,此时工作量评估往往不准确,比如可以采用一个既有的组件,或者重用一些代码,但是没有详细定义设计时,难以确定准确可以节约多少时间,改造成本4、不知道自己将面对什么样的开发团队,有人一天,有人要10天才能做完,但你很难有一支你熟悉了解的团队虽然也了解过各种工作量评估方法,但是实际中总感精品文档2016全新精品资料全新公文范文全程指导写作独家原创2/9觉难以使用自己的做法如下1、确定有多少模块,每个模块下有多少页面,针对每个模块列出需求、设计、开发、测试、部署时间,组成这一模块的时间2、需要多少个公共的类,分别有多复杂3、加上项目管理时间,大概5个人的团队,需要一个不编码的专门管理,做类似于功能检查,代码REVIEW之类的事情4、加上一定比例的变更时间5、最后得出的数字乘以一个153,得出最后时间,这个153是根据评估人历史的情况,比如,我以前一年里评估的工作量大概都需要乘以2才是最后实际的,就会在新项目评估时,这些时间总会被用户有办法用掉,虽然一直按以上这种方式做,但是总觉得不是很好,精品文档2016全新精品资料全新公文范文全程指导写作独家原创3/9主要有以下几个方面1、准确性差,从上可以看到,准确率只有50左右2、难以解释,说这个页面为什么要这么久,这个功能为什么这么久,完全是凭着脑子里过一下,有几个按钮,大概写多少代码的一个感觉,经不起推敲3、评估工作量和实际设计完成后的很难对应上,通过设计后,可能有些部分为了通用超出想象得工作量,有些部分公用了,又减少了。很难理解,到底真正准确率高的工作量评估是怎么做的。在我看来,设计完成后,工作量才能准确评估。但是为什么工作量评估总是要在前期需求刚刚了解一部分就要出。这是为什么呢,怎么做呢特别值得一提的是,根据大概会产生多少代码行进行评估,我特别难以理解,有人能听客户说了一天需求,就大概估算出代码行数,真是神人啊。精品文档2016全新精品资料全新公文范文全程指导写作独家原创4/9欢迎告诉我您的工作量评估方法,让我也学习一下。1根据测试范围和测试方法来估计工作量A)制定测试计划以前,明确测试范围不同的测试范围,对测试量的评估起到至关重要的因素,比如说测试一个模块或测试多个模块或测试整个系统等等,都属于测试范围不一样,明显工作量也不同,差别也挺大的。还有测试范围还包括功能性测试范围或非功能性测试范围等等,在做测试工作量评估的时候,都必须考虑。B)确定合理、有效的测试方法比如说你要考虑测试某个项目,你必须考虑测试方法是否合理。比如说某个模块的功能测试,你可以采用QTP做自动化功能测试,还是手工做功能测试,工作量就不一样,做测试计划以前必须考虑清楚。要不然,估算的工作量肯定不准。精品文档2016全新精品资料全新公文范文全程指导写作独家原创5/92根据测试任务来评估工作量A)质量需求和项目背景决定工作量不同的项目背景,不同的质量要求,决定不同的测试工作量。如果我们测试的是一个银行系统,涉及到每个人的经济利益,我们测试时必然会对性能测试或安全测试放到第一位,设计较多的异常测试用例,这样一做,必然增加我们的工作量。如果是一般的系统,我们可以只执行一般的功能测试通过就可以了,没有必要去做其他的异常、安全测试。如果系统的质量需求要求高,也许就要进行更深层次的测试,回归测试的力度必然要加大,工作量自然就上去了。B)尽可能详细的罗列出项目测试内容一般来说,测试工作量的评估工作都是交给测试经理或项目组成员协助共同来完成的。准确评估项目测试的工作量,必须要求测试LEADER明确详细的测试内容,只有知道测试什么哪些需要测试详细分析需求规格说明书,明确测试任务以后,评估才会有依据,所以精品文档2016全新精品资料全新公文范文全程指导写作独家原创6/9尽可能详细的罗列出项目测试内容非常必要。C)把测试任务细化到每个测试功能点我们在估算测试时间的时候,可以把测试任务细化到每个测试的功能点,比如说“新增“、“修改“、“删除“、“暂停“、“恢复“等等都记成一个功能点,在预算的时候,同时把编写测试用例和执行测试用例的时间都要计算进去。例如编写一个测试用例或执行一个功能测试各需要一个小时,如果我们有100个功能点,我们就知道大约要200个小时。这样估算出来的时间比较精确一点,比较符合实际。D)预估业务测试或模块交叉测试的复杂容易程度很多时候,我们测试初期,对业务了解不是很多,忽视了对业务方面或交叉模块测试的评估,等到了测试后期,大量的业务测试没有测试,测试时间特别紧,所以在测试初期预估测试的复杂容易程度,在评估工作量方面至关重要。3根据开发阶段来评估工作量精品文档2016全新精品资料全新公文范文全程指导写作独家原创7/9不同的开发阶段,测试时间估算也不太相同。比如说,开发的系统是第一个版本,相对以后的测试工作来说,可能安排的时间要多一点。大多数情况下是这样的,也许后面的版本增加很多新功能,测试工作量还大于第一个版本也是常有的事情。作为测试负责人,对于使用测试阶段来评估工作量,必须根据实际情况来定,不能盲目给出数字,应付了事。4根据测试经验的积累来评估工作量我们可以借鉴类似项目的测试经验,比如说被测试的系统,我们做过类似的产品,就可以把相关的测试文档,修改一下,复用以前的测试用例,这时候测试工作量就减少了很多。如果没有,我们只能重来。还有就是借鉴以前项目编写测试用例或执行测试的时间,对测试工作量的准确评估,也具有一定的参考价值。5根据测试风险来评估工作量A)测试人员变动带来的风险精品文档2016全新精品资料全新公文范文全程指导写作独家原创8/9在一般的软件公司,测试人员的流动是常有的事情,所以估计测试工作量的时候,我们一定要把它计算在里面,留有一定的余地,以防不测。比如说以前安排了一个做过类似项目,对类似项目熟悉的测试人员,也许给他安排了一天的工作量。如果他不在了,其它的人去做这个测试也许就2天,甚至3、5天都不一定能够搞定。测试人员带了的风险还是特别高的。B)系统测试环境的风险系统测试环境带来的风险,一般来说比较小,发生的可能性很小,如果一旦发生了,也相当可怕。最可怕的就是硬件故障,在经济实力允许的情况下,我们一般的方法是准备两套测试环境,一套测试环境出现问题,我们立马切换到另外一个测试环境中去继续测试,避免影响正常的测试进度。但是大部分的公司都不愿意花血本,来购买昂贵的硬件,而是以牺牲时间来付出代价。C)、开发人员版本发布延迟风险不做好版本配置管理或没有正规的测试规范的公司,大部分情况下很难估计工作量,他们基本上都是边改边开精品文档2016全新精品资料全新公文范文全程指导写作独家原创9/9发边测试,如果一旦开发出现异常,整个测试就立马终止,这对测试的相互制约作用也会更大,这样对我们估

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论