[yanglinux]的博客:
http://DickYoung.mypm.net
估算随感-想说爱你并不容易.doc

实事求是地讲,我们的估算一点也不准确。在软件项目中,最难的也就是估算工作。并且,我做了这些年,发现这种情况也没有得到什么大的改变(至少在我的身上)。核心是,记录估算数据以及如何使用它们——估算的数据、数据、数据,这是核心问题。

 

       记录实际值和估算值。在哪里可以得到历史数据来提高估算未来工作的能力?如果把今天发生的事情写下来,明天它们就会成为历史数据。除非把每个任务所实际花的工作量和时间记录下来,并与之前的估算进行比较,否则估算永远还是猜测。每个人都可以开始记录估算值和实际值,项目经理应以项目任务或里程碑为基础跟踪这些度量数据。除了工作量和进度,还可以估算和跟踪产品的大小、需求数量、代码行数、功能点、类和调用的方法、界面或其他合适的项目单位。

 

有很多方式可以让估算和报告估算变得更容易。

    估算只是一个大概值——一个猜测。猜测的范围越多,可能产生的错误也就越多。在对项目完成日期进行估算时,要提供一个日期范围,让人知道你的估算只是一个猜测。

    很多软件开发人员都很乐观的。在学校接受的训练就是要让他们变得乐观,这些训练会一直停留在他们脑海中,直到学会估算小的功能,并接收对于估算的反馈。

    完成一项任务总是要花费比预计更长的时间

    估算小块的工作更容易

    估算采取“人时”的时间单位,而不要用“人日”

    项目经理和团队需要练习估算并收集反馈。没有反馈的估算只是“写下来的猜测”——它让你感觉良好,但是不能产生长期的结果,最终只能被证明毫无价值。

    做好反复估算的的准备。在项目进行到一半的时候意识到估算过于乐观并不晚,花点时间重新估算,重新安排剩下的工作。已经延迟的项目是无法再赶上进度的,它们一定会延迟交付。即使项目看起来不会晚,也应该花时间重新做估算。

    如果项目经理必须遵循某个截止日期,那就干脆什么都别估算了。把所有的功能进行排序,并按优先级进行开发。

    如果项目被限制得很死,就要用时间盒把各个阶段和任务包围起来

    如果任务过大或者包含很多技术风险,不容易估算好,可以先用试探性开发。

 

       估算对于我们而言完全不陌生,只是由于各种原因,我们总是通过印象或者残留在脑海中的经验来进行估算,其结果当然可想而知了——一塌糊涂。其实估算是有一套完整的方法组合的,我使用过的有:比对历史数据、使用日期范围进行估算、使用三个日期估算等,其它的都是我从书上学习并加以总结而来的。在整个项目管理的各个子知识领域中,估算是我最薄弱的一块。

 

实用的估算方法

1、通过对比历史数据进行估算

如果所管理的项目的产出是某一个产品的后续发布版本或者只是一个实施项目,这种估算是好做的。如果表面看起来只有20%的区别,那么肯定是不能简单的加上20%的工作量,很有可能要比这个20%的时间多得多,因为项目是非线性的。这个时候需要将历史数据与“专家背靠背方式”结合起来,效果会更好。

2、通过Delphi方式和宽带Delphi方式进行估算

通过Delphi方式进行估算,项目经理会把团队召集在一起,并就项目的有关事宜向他们阐述。大家提出各种问题,每个人都写下来自己的任务列表和时间估算,同时注明自己对项目的预设条件。接下来,团队收集任务列表并进行复查,看看哪些任务可以同时进行。项目经理再把估算时间加在一起,得到项目的整体估算。

如果项目经理不能接触到从事实际工作的人——真正的项目团队,此时不妨使用宽带Delphi方式。一小组专家会暂时替代项目团队,产生任务列表和估算。在完成估算后,他们会提交任务列表、预设条件和风险。

使用这两种Delphi预测方式,其效果都要好于项目经理自己进行估算。但是,它们都有同样的问题——每个人负责估算的一小部分,而且通常是按架构进行切分的,这样会导致估算过低

3、小心顺序式生命周期的估算陷阱

对于使用顺序式生命周期的项目经理来说,我们总要在一开始负责估算安排整个项目的时间表。这会花去至少两周的时间,因为我们需要对需求和系统架构有足够的理解,才能产生合理的估算。基于组织对该项目的陌生程度,我们的估算会发生偏差,从100%400%不等的偏差幅度。

从一开始就估算整个项目,这是个陷阱。如果必须使用顺序式生命周期,是很难对项目做出准确估算的。要想做好,可以让团队先动手做一点开发工作,测量出完成这些工作需要多长时间,再看看项目中包括多少类似工作量的工作,并通过迭代方式得到估算。

4、使用自信心范围进行估算

你对自己的估算有多大把握?项目刚开始,我一点儿把我都没有。我只知道项目不会完全按照我们制定的日程推进。有些东西会变的,它们会改变估算。不要使用对结束日期的单点估算,我们可以尝试使用自信心范围,即可能性的范围就是自信心的水平。

5、使用日期范围进行估算

6、使用三个日期:最佳状况、最有可能、“墨菲”日期

以上三条(4,5,6),个人认为是非常有必要的,既然装修房子的预算都可以有一个范围,为什么比它更不可知、可视性更差的软件就更有必要了。

7、在估算时分别考虑任务的大小与持续时间

8、规划扑克  (按牌点的大小决定其优先级)   估算时应该用“人时”还是“人日”

9、在估算前用试探性开发收集数据

 

以上方法只有落到实处才能有效,要落实之前是有很多工作要做。

 

 

 

yanglinux 发表于 2010/11/11 9:35:00 阅读全文 | 回复(0) | 引用通告 | 编辑 | 收藏该日志

发表评论:

    昵称:
    密码:
    主页:
    标题:
公 告
登 陆
日志日历
搜 索
日 志
评 论
链 接
统 计