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

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

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

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

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

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

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

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

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

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

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

一次迭代式开发的研究：软件开发的风险
一次迭代式开发的研究：什么是迭代式开发
一次迭代式开发的研究：怎样进行迭代式开发
一次迭代式开发的研究：迭代开发从这里开始
一次迭代式开发的研究：准确的工作量评估
一次迭代式开发的研究：功能的优先级评估
一次迭代式开发的研究：一个迭代式项目计划
一次迭代式开发的研究：开始真正的工作
一次迭代式开发的研究：从容应对需求变更
一次迭代式开发的研究：需求变更的关键步骤
一次迭代式开发的研究：Where you are
（续）

评论

3 楼 ccxw1983 2011-12-17  

项目管理是个技术+经验的活

2 楼 fangang 2011-11-08  

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

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

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

1 楼 fangang 2011-11-08  

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

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

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

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

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

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