军衔: 二等兵
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 52篇
注册: 2002-1-15

--------------------------------------------------------------------------------


怎么没人讨论项目估算的话题？刚翻译了老美的一篇，请大家指正！

http://www.sdmagazine.com/documents/s=747/sdm0002e/0002e.htm?temp=ult6iB8ydx

不要再预想出现奇迹
“我一开始怎么没想到？”作为一个不准确的项目估算带来的后果，这好象是经常听到的一句话。下面的DELPHI团队估算法可能会有些帮助
Karl Wiegers
作为软件开发者，经常会遇到工作量估算的问题，但是很少有人擅长于此。我们经常是太乐观，或者很快忘掉上一个项目延期的痛苦。将项目中的不确定性或风险用浮动时间来代替似乎不是一件简单的事情。并且在开始估算一个项目的时候，我们经常忽视某些活动的某些方面。这样当我们在实际过程中，或者会去执行这些不在计划列表中的任务，那样会超出我们的预期；或者会忽略这些任务，那样则会伤及项目的质量。
要成为一个好的项目估算者，有多种方式。最基本的方法是记录每一次估算的过程和假设，以及执行过程中的用时和工作量。实际结果与预算的比较能为今后的精确估算提供帮助。对于可能出现的遗漏重要工作的问题，这种将任务条目化的过程能够很好的避免。
另外一种方法是源于“三个臭皮匠能抵一个诸葛亮”的原则。DELPHI估算法是开始于1948年南德公司，这种方法首先让一小组相关专家无记名地给出自己对问题的估算，然后经过多次反复讨论以达成一致的估算结果。在七十年代早期，巴里褒曼和他的南德公司同事改进了这种方法，增加了更多团队间交互式的估算过程（见褒曼的《软件工程经济学》），从而创造了一种团队的DELPHI法。在这以后，Mary Sakry和 Neil Potter将其发展成为一种可重用的适用于软件项目的估算方法。
这种团队DELPHI法几乎可以用来估算项目中的任何事情，一个特定子系统开发所需要的人月数，一个完整产品的代码行数或者Class的个数，甚至要重新粉刷Bill Gates的别墅需要多少加仑的油漆也可以用这种方法估算出来。我曾经用该方法与一个过程改进小组一起估算过某特定的组织达到CMM2标准所需要的努力程度。
DELPHI法帮助你构造出一个详细的工作分解结构，这样一个工作分解结构是自底向上安排工作量或估算项目规模的基础。DELPHI过程的起点可以是待估算项目的一份规格说明书，也可以是初始的任务列表或项目计划。而该方法的结果应该包括详细的项目任务列表，与质量、过程相联系的具体事务列表，假设条件，以及项目的全局估算，最好是每块具体由单独一个成员负责给出。
图一给出了团队DELPHI过程的流程图。在计划阶段给出待估算问题的定义并选择参加人员。答疑会的目的是使所有的估算人员的思想集中到问题本身上来，排除一些不必要的细枝末节。然后每个参与者独立准备他们的初始任务列表和估算。在估算会上他们拿出这些条目，经过几轮筛选和讨论，最后会得到一个更加综合性的结果，这时主持人或项目经理暂时休会将达成的估算信息做个总结，如果已经达到预先定义的效果则估算会可以宣告结束。经过这个过程的估算结果将比任何人的估算都更加接近现实。下面我们具体看看团队DELPHI法的各个阶段。

图一
计划阶段
团队DELPHI过程以问题及其范围的定义开始，将大型问题分解成几个可管理的部分，每个部分可以交给不同的小组，这样估算就可以更加精确些。估算活动的组织者在过程的初期给出问题的详细定义，这样能使参与者得到充足的信息以做出可信的估算。
估算的参与者包括一个主持人、一个项目经理和两到四个其他的估算人员，主持人的任务是计划并协调整个过程，他应该是个中立者，不能把自己的偏见或主张带到会议中来。但对其他的估算者，主持人的地位不应有任何特殊性。参与者的选择基于他们对具体问题和估算内容的熟悉程度。

答疑会
在主要过程开始之前，需要花大约一个小时时间将所有参与者集中在一起以加速整个估算过程。主持人可以向那些还太熟悉DELPHI方法的小组成员解释该方法，并且明确问题的定义、假设和约束条件。这样做的目的是让估算人员知道必要的足够信息，但也不至于信息过量以影响他们独立作出估算。
小组需要重新审视估算对象并讨论每个估算项的问题。参与者需就计量单位达成一致，例如周、劳动力小时数、美元或代码行。如果主持人认为所有的与会者都掌握了这些共同知识，就可以进入下面的过程。否则，还应该对相关问题进行更详细的介绍，或者有可能替换小组成员，吸收那些能够做出更加精确估算的成员入组。
是否能够进入下一步的团队DELPHI过程，取决于一些预设的条件是否达到。这些条件包括：
挑选适当的小组成员
举行答疑会
与会者就估算目标和计量单位达成一致
项目经理能够到会
主持人掌握足够信息以实现高效参与

个人准备
假设你希望估算完成某个项目所需总的工作量（一般用劳动力小时数表示）。作为估算过程的开始，每位参与人员独立给出一个完成预定任务目标所必需的初始任务列表，这样的列表格式如图2。然后，每人又估算其中每项任务需要花费的工作量。将活动分解成足够细小的能够精确估算的任务项，当存在单个超过20劳动力小时数的任务时，就有理由怀疑其精确性。任务必须明确定义，因为每个人的任务列表会被合并成为一个复合列表。在这样一个列表中，将每项任务的估算合并起来，就得到最初的项目总估算。

图2
估算过程决不应该与迎合项目经理或股东的意愿关联起来。很有可能估算结果超出了可以接受的项目资源、人手或成本，这样就需要协商，也许要缩小范围，扩展日程或者调整资源，但决不要让外部压力影响你对项目执行过程的最佳且最现实的设想。
在明确项目任务之余，还需要单独记录与任务相关的或起支持作用的活动。在我的第一个团队DELPHI过程中，所有参与人员在第一轮都忘记了将质量保证、配置管理和与过程相关的活动列出。很快我们发现了这个问题并在下一轮估算中把它们加上。确保任务列表中在测试或审查活动之后存在“返工”的任务项。现实就是这样，为改正错误而做的“返工”的确存在，因此你不可避免，需要在计划中将它们考虑进去。如果你在做一个日程的规划，你还需要想到一些与项目没有特定关系的一般性活动，包括一些会议、假期、培训和其它项目的任务以及无数别的会夺去你时间的事情。
不同的假设会导致很大的估算差别，明确这一点，并在准备做估算时记录下这些假设。例如，如果你假设购买某个特定的组件库或者复用以前某个项目中的组件，把它们写下来。另外一个估算人员也许假设自己开发那样一个组件库，这就会导致总估算的差异。
记住以下估算原则：
假定你一个人执行全部任务。
假定所有任务按顺序执行，在这时不要担心顺序和前置任务。
假定你不间断地执行每项任务（这也许太乐观了一点，但简化了估算的过程）
在日历部分，列出所有可能发生在任务间的等待时间，这可以帮助你在以后将工作量估算转化成日程估算。

估算会
主持人将所有参与者的独立估算收集起来并制作一个如图3所示的表格。每个参与者的总估算被标在X轴的“Round 1”线上。每个估算者可以看到自己的初始估算在图表上所处的位置。这样一个初始估算也许会横跨很大一个范围，想象一下当每个估算者被问及他们的结果时所得到的答复，再想一下用其中一个结果做估算的风险。

图3
主持人并不指明图中的每个估算点出自谁之手，这种无记名性是DELPHI方法的一个重要的方面。无记名性防止了某些爱显山露水的同事胁迫其他一些参与者按照他的角度去看待问题，同时也意味着当个人分析导致不同结果时，团队成员不太可能屈从于某位最受尊敬的参与者的判断。
每个估算人员重新阅读他最初给出的任务列表，同时识别其中隐含的假设并且提出一些问题。在这个过程中，并没有公开每个估算结果的作者。将各自的这些任务列表合并就得到了一个比任何一个人的单独估算更为完全的列表。这个列表也许包含数十条任务，再多就太细了，那就需要将整个问题分解成若干子问题并分别作出估算。
在这次初次讨论中，小组成员也谈及到他们的一些假定和对项目尚存疑虑的地方。小组得到的结果将包含一个共享的假定集和一个通用的任务列表。这样当下一次碰到类似的项目，就可以用到这些任务列表作为起点。
在初次讨论之后，有了讨论中共享的一些信息和对任务范围和项目假定的新的理解，所有参与者在会议室里开始对他们自己第一次做的估算进行修改，注意这时要保持安静。估算者们会在他们的表格中加入一些新的任务，并注明一些与上次估算不同的变化。所有任务项变化的累加就等于该参与者总估算的变化。

图4
主持人将修改过的总估算收集起来，并在同一张图的“ROUND 2”线条上标出这些值。如图4所示，这第二轮结果的方差也许比前一轮小，而均值也许比前一轮高。如此方法还可以继续下去，修改结果、讨论假定、准备新的估算，直到出现以下情况：
完成四轮以上
估算结果差异缩小到可以接受的程度（接下来会有定义）
预定估算会时间已到（一般是两个小时）
所有的参与者都不愿意再改变自己最后的估算结果。

主持人要保证每轮讨论在预定的轨道中进行，以15或20分钟为限，避免没完没了的争论。主持人应该遵循高效会议的实施原则，例如准时开始和结束，鼓励所有参与者提出自己的看法，保持一个公正、没有任何偏见的环境。在讨论的前几轮中采用无记名的方式，小组成员就可以无所顾忌的拿出他们的真实想法，通过公开讨论而非别的方式达到最终结果。即使各人的看法差异非常大，这种方法也给他们一个机会去讨论那些任务项。不到会议结束，主持人都不应该公开每个估算结果的作者。

合并任务
估算会结束后，工作还没有完。这时主持人或者项目经理要将项目任务和各人的估算组合起来，形成一个完善的任务列表。这个人还要将各人估算的假定条件也组合起来，另外还包括与质量和过程相关的活动，日常性任务和等待时间等等。
合并的过程还包括去掉一些重复性的任务，综合对单个任务的不同估算得到某种合情理的方案。这里“合情理”不是指以项目经理的喜好去代替小组的估算结果。对明显类似任务的估算结果所产生的巨大的差异也许表明估算人员看待任务的不同角度。例如，两个人也许都有一个任务“完成一个Class”，但是其中一个人可能在该任务中包括单元测试和代码审查，而另一个人只是给出了编码的工作量。所有的估算人员应该将他们写出的任务明确定义以减少合并过程中可能出现的混淆。合并过程应该给每个任务的估算值保留一个估算区间，但如果某个估算人员对其中一个任务的估算与其他人大相径庭，则可以考虑修改或删去该值。

审查结果
最后一步，估算小组审查最终的结果，并达成一致意见。项目经理拿出总的任务列表，各自的估算，累加的估算，假设条件的列表和其它一些信息。整个小组花30到60分钟回顾估算过程并为估算活动画个句号。这次会议也为项目小组审视团队DELPHI过程在该项目执行的效果提供了机会，并为将来项目中应用该方法找到一些改进的方法。
参与者应该尽可能使最终的结果列表完整。在估算会过程中他们也许会想到一些附加的任务，现在都应该加到任务列表中来了。检查一下当初出现巨大差异的地方现在是否用一种合情理的方式合并起来了。整个过程最大的客观性就是产生一个估算区间使得项目经理和其他一些主要的股东能够在一种可接受的置信度上继续进行项目计划。

完成估算
当达到预定的退出标准以后，估算过程可以宣告结束，这时你就可以全身而退。以下是团队DELPHI过程的退出标准：
总的任务列表组合完毕
估算假设条件综合在一起
估算人员就他们各自的估算在一个可以接受的程度内达成一致。

现在你需要决定的是如何使用已经得到的数据。你可以简单地拿出一个最后的平均结果，把它告诉想知道的人。然而一个平均值可能太少了点，保留估算的差异区间还是有益处的。估算是对将来的预测，区间的大小很好地反映了这种不确定性。你可以拿出三个数字：被估对象可能的平均结果、当出现最好情况下的结果和最差情况下的结果。或者你也可以对预期的结果给出一个名义上的平均值，再附加上一个三个值之间间隔的波动区间。
每个估算结果都有一定的可能性成为现实，因此这一组估算结果形成了一个概率分布。在《软件工程的原则》（Addison-Wesley,1995）一书中，Watts Humphrey描述了一种精确的数学方法用来从多个估算结果和不确定性中得到一个含有预计区间的总的估算。另一个复杂的方法是采用蒙特卡罗仿真方法得到一个基于最终估算结果的概率分布。
也许以上介绍的DELPHI过程不是那些急功近利的人愿意听到的方法，他们可以用百分之十的置信程度来计划他们的项目，或者是百分之九十，或者中间的任何一个数字。为了使你们的今后的估算结果更为精确，一定要在实际项目完成的时候比较一下和估算时候的差异。

团队DELPHI方法的评价
没有任何一种估算方法是十全十美的；如果有的话，那是预测而非估算。然而团队DELPHI技术融入了一些管用的估算原则。团队方法认同了多位专家意见综合的价值。从中产生的估算结果的差异区间反映了估算过程中人的直觉的差异性。
虽然整个过程要花费一定的时间并且需要一组有经验的估算人员，团队DELPHI方法防止了估算过程中的一些武断性，并如沙里淘金般将将最初的估算值精确化。这种方法反映了我的哲学，当有人就估算方面的问题请教我的时候，我会说“我也要回问你同样的问题。”

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 该贴在 2003年2月9日 18:00:07 被 macrolife 修改过 ]


wyzhoub

军衔: 无军衔
财产:
经验:
魅力:
来自: 不告诉你 :)
鉴定: 本功能已经被关闭
发帖: 3篇
注册: 2003-2-10

--------------------------------------------------------------------------------


好

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2003年2月10日 21:26:01 ]