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