当我问起无数人，什么是迭代式开发时，人们总是抛来一副不屑的神情：“迭代开发！这还不清楚？就是按迭代的方式进行开发嘛，开发过程采用持续集成的方式。”但我再详细询问怎么进行开发，甚至谈到如何制订计划，以及计划前的分析整理时，人们却投来诧异与迷茫的神情：“啊！迭代开发这么复杂呢？”
所有对迭代式开发的实践与研究中，工作量评估往往是最令人头痛、最大的难题。当人们信心满满地决定尝试迭代开发时，工作量评估就让不少人望而却步了。工作量评估真的有这么难吗？我们应当怎样进行评估呢？
毫无疑问，工作量评估的第一步应该是工作分解。将整个系统划分为数个模块，每个模块划分为数个功能，每个功能划分为多项工作。再逐项分解工作，直到确保每项工作能够正确评估为止。一项为其10天以上的工作是不能够准确评估的，所以应当分解，直到分解为2~3天以内的小块工作。完成工作分解以后，最终合并每项工作的工作量，就是一个功能的工作量；合并每个功能的工作量，就是一个模块的工作量；合并每个模块的工作量，就是整个系统的工作量。
但是，即使将工作量适当地进行了分解，由于每个人对需求理解的不同，对设计方式的不同，技术熟练程度的不同，对同一项工作的工作量评估也是不同的。因此，要客观地评估工作量，应当采用多人共同完成的方式，而不是一个人全搞定。
首先，将分解好的各项工作，按模块按功能罗列在一个表格中，依次描述每项工作的业务需求和工作任务，使每一个参与评估的人都清楚每项工作。然后将工作量评估分配给多个人，保证每项工作都有2~3个人同时给予评估。
该阶段的评估应当是独立的，即每个人的评估结果都不会影响另一个人。当每个人完成了自己的评估以后，项目经理收集每个人的评估结果，组织会议进行讨论。
在工作量评估讨论会上，会议组织者将一项一项地讨论每项工作。对某项工作，如果参与评估的每个人评估的工作量差异都不大，说明大家对该项工作的分歧不大，选取最合适的一个工作量评估；如果某个人的评估与其他人差距较大，认真听取他的意见。也许他对该项工作的某个细节存在误解，但也可能该细节正是需求不明确的地方。停下对该项工作的评估，联系客户明确需求，之后才可以继续该项评估。
实际上，工作量评估也是一个迭代的过程：客户提出需求、评估工作量、发现需求不明确的地方、与客户确认、再评估……如此往复数轮，不仅工作量评估出来，业务需求也能逐渐明确下来。
另外，迭代开发的每个迭代期应当包括需求分析、设计、开发、测试。因此在工作量评估时应当全面地考虑进去，而不仅仅只是开发。
最后，当所有工作量被评估出来以后，是否就可以提交客户了呢？一个成熟的项目经理应当考虑更多。并非所有人在所有时间都能满负荷工作，生病、接收突发任务、人事变动，都可能影响项目进度。因此，适当地为每项工作增加一个备用时间的系数，提供一些富余的时间，可以确保项目过程更加稳健。
转自:http://fangang.iteye.com/blog/1185132