一次迭代式开发的研究5:准确的工作量评估

当我问起无数人,什么是迭代式开发时,人们总是抛来一副不屑的神情:“迭代开发!这还不清楚?就是按迭代的方式进行开发嘛,开发过程采用持续集成的方式。”但我再详细询问怎么进行开发,甚至谈到如何制订计划,以及计划前的分析整理时,人们却投来诧异与迷茫的神情:“啊!迭代开发这么复杂呢?”

所有对迭代式开发的实践与研究中,工作量评估往往是最令人头痛、最大的难题。当人们信心满满地决定尝试迭代开发时,工作量评估就让不少人望而却步了。工作量评估真的有这么难吗?我们应当怎样进行评估呢?

毫无疑问,工作量评估的第一步应该是工作分解。将整个系统划分为数个模块,每个模块划分为数个功能,每个功能划分为多项工作。再逐项分解工作,直到确保每项工作能够正确评估为止。一项为其10天以上的工作是不能够准确评估的,所以应当分解,直到分解为2~3天以内的小块工作。完成工作分解以后,最终合并每项工作的工作量,就是一个功能的工作量;合并每个功能的工作量,就是一个模块的工作量;合并每个模块的工作量,就是整个系统的工作量。

但是,即使将工作量适当地进行了分解,由于每个人对需求理解的不同,对设计方式的不同,技术熟练程度的不同,对同一项工作的工作量评估也是不同的。因此,要客观地评估工作量,应当采用多人共同完成的方式,而不是一个人全搞定。

首先,将分解好的各项工作,按模块按功能罗列在一个表格中,依次描述每项工作的业务需求和工作任务,使每一个参与评估的人都清楚每项工作。然后将工作量评估分配给多个人,保证每项工作都有2~3个人同时给予评估。

该阶段的评估应当是独立的,即每个人的评估结果都不会影响另一个人。当每个人完成了自己的评估以后,项目经理收集每个人的评估结果,组织会议进行讨论。

在工作量评估讨论会上,会议组织者将一项一项地讨论每项工作。对某项工作,如果参与评估的每个人评估的工作量差异都不大,说明大家对该项工作的分歧不大,选取最合适的一个工作量评估;如果某个人的评估与其他人差距较大,认真听取他的意见。也许他对该项工作的某个细节存在误解,但也可能该细节正是需求不明确的地方。停下对该项工作的评估,联系客户明确需求,之后才可以继续该项评估。

实际上,工作量评估也是一个迭代的过程:客户提出需求、评估工作量、发现需求不明确的地方、与客户确认、再评估……如此往复数轮,不仅工作量评估出来,业务需求也能逐渐明确下来。

另外,迭代开发的每个迭代期应当包括需求分析、设计、开发、测试。因此在工作量评估时应当全面地考虑进去,而不仅仅只是开发。

最后,当所有工作量被评估出来以后,是否就可以提交客户了呢?一个成熟的项目经理应当考虑更多。并非所有人在所有时间都能满负荷工作,生病、接收突发任务、人事变动,都可能影响项目进度。因此,适当地为每项工作增加一个备用时间的系数,提供一些富余的时间,可以确保项目过程更加稳健。

 

如何杜绝评估人整体推高时间估计?如何准确评估工作量?

谈谈我在工作量评估中的一些感受吧。工作量评估不论你怎样做肯定是有误差的,这毫无疑问,关键是误差有多大。比如我最近刚刚完成的一次封闭开发,实际参与的开发人员是5人、测试人员3人,10天完成。比对事先评估的工作量情况,发现开发工作量评估是47.75人天,与实际的50人天差距较小,但测试工作量评估是57.75人天,与实际的30人天差距较大。经过对测试中各个项目计划与实际情况的比对发现,评估的误差在,有19.75人天的测试工作因各方面原因被取消,实际只完成了38人天的,基本在可以接收的误差范围内。

在多次对评估结果与实际情况的比对和总结分析的过程中我发现,一个工作如果分解得比较细则比较容易准确评估,如果分解得粗则误差较大。如有一次需求分析与设计的讨论会中我要求大家进行工作量评估。起初,所有人都按照各个功能模块进行评估,告诉我的结果都是1周、2周这样的粗略数字。当我问他们为什么时,得到的回答是拍脑袋瞎估的。随后,我要求大家将每个功能模块进行任务分解,也就是要完成这个功能,先做什么,再做什么,最后做什么。。。然后依次去评估每个任务的工作量。(注意,并不是每个人分解各自的功能模块,而是所有人分解所有的功能模块)。随后的讨论就变成了对模块设计的讨论:每个人对同一功能设计的不同,任务划分也是不同的。经过一番争论、妥协、再争论,最后交给我的是一份所有人都认可的工作任务分解,以及它们的工作量评估。当你拿到这样一份工作量评估,首先的感受是它是可信的。随后的结果也证明了这样一份工作量评估的可信度,与之前未分解的工作量评估是一个质的变化。


 

问:文中提到的工作量评估的协商制,这种协商制在实际应用中是否真的可行?
一般情况下,整体工期是既定的,各个阶段的时间也是确定的,每个模块的规模是确定的,所以每个模块的工作时间一般是倒推计算得到的,这个时间是计划时间的底线,如果评估人给出的时间大于这个时间,如何处理?

的确,你遇到的问题也是我遇到的问题,相信也是大多数项目经理遇到的问题。关键是我们如何去应对。

很多情况,客户早早地就确定了工期,即交付时间;公司呢,也早早地确定了人员,即多少个开发人员,多少个测试人员。工期、人员和工作范围,还有质量,往往是项目中的一组矛盾体。在规定的工期、规定的人员、规定的工作范围能否完成软件项目,并且达到规定的质量,这是项目经理在项目计划之初必须考虑的问题。但非常遗憾的是,许多项目经理都没有认真去计算,认真去评估,就草草进入项目执行阶段了。这无疑将是一个巨大的风险。它造成的结果就是无休止地加班、赶工,降低测试时间和质量,甚至不得不延期,等等。。。

进行工作量评估,首先使项目经理有一个谱,在规定的工期、规定的人员、规定的工作范围能否完成软件项目,进行一个项目预演。如果推算的结果是不能,怎么能够调整?这个调整可能是跟客户重新讨论工期,重新划分工作范围,使项目经过评估是可以完成的。然后,我们才可以按照这样的估算制订项目计划,执行项目。

如果客户那里既不能调整工期,又不能调整工作范围,毫无疑问,项目经理必须提早告知公司领导。向公司领导汇报情况时,无疑必须拿出有效的依据。工作量评估就是这份依据。这时,公司领导会根据情况考虑增加资源。

工作量评估如此的重要,但在实际操作过程中,准确地工作量评估可谓是难上加难。以上所说的一切前提都是,你做的工作量评估要足以服众。关于这方面,我只能说是一步步摸索,每完成一次项目,就对之前的评估进行仔细核对,总结经验。。。

 

你可能感兴趣的:(项目管理,敏捷开发)