实际上不存在基于粗略要求的可靠估计。事实上,根据我的经验,任何估计超过 1 天的单个任务都强烈表明该任务需要进一步分解为子任务。
即使是为期一周的估计通常也很糟糕。以我的经验,大多数在没有进一步细节的情况下估计需要 1 周的任务最终需要 2-3 周,而且随着项目的扩大,问题只会变得更糟。
这主要是心理上的。我们知道,作为程序员/设计师/建筑师,我们是乐观主义者。当我们给自己一个长而模糊的目标来击中时,我们很容易觉得我们领先于比赛,尽管我们实际上并没有。还有4周?我所要做的就是修复上周工作的损坏的搜索功能?这很容易!让我们把它放在一边,研究一些有趣的 Ajax 淡入淡出效果。
话虽如此,我经常在粗略估计中使用一种特殊的启发式方法,让我清楚地表明,这些方法从未真正致力于或用于项目计划——它们只是帮助回答问题的方法客户和经理经常问的问题,“假设我们想做<some_vague_project>
,你认为这需要多长时间?”
首先,我确定了项目的某些方面,即:
- 预期寿命 - 运行一次、临时还是永久?
- 项目的独创性——我们以前做过类似的事情吗?
- 所需的领域知识水平与已知水平 - 规格是否有学习曲线?
- 波动性——范围/所有权有多清晰,改变的可能性有多大?
- 影响——它会支持/替代关键的业务功能吗?
- UI 复杂性 - 少于 5 个屏幕,少于 20 个,还是更多?
- 是面向客户的吗?(如果是这样,它将需要经过无数次的修改)
- 它是否需要与任何其他系统互操作?
然后我通常为这些中的每一个分配“点”(注意这不是一个“系统”,这一切都发生在我的脑海中,通常需要微调)。计算大致项目规模的点数:
- 没有积分:1-2天(一个脚本)
- 1分:1-2周
- 2分:2-4周
- 3分:1-2个月
- 4分:3-6个月
- 5分:6-12个月
- 6分或更多:没有线索。
请注意我在这里所做的 - 具有或多或少的指数增长率和复杂性。当您添加一个新的问题时,例如应用程序是面向客户的,这不仅会为项目增加一点额外的时间,还会使时间增加一倍或三倍,因为现在一切都将花费更长的时间,因为必须经过语言、法律、外观和感觉等方面的审查。如果它正在取代关键的业务功能,则同样的想法;现在,每一个组件都需要防御性地编写,以计划每一个可能的意外情况。
我想重申一下,这在真正的项目计划中没有实际用途,如果不将整个规范分解为最大 1-2 天的任务,我永远不会真正承诺项目时间表。这仅用于在客户/经理有效地要求我在脑海中进行数学运算并且不愿意以“我不知道”作为答案时回答快速、即兴的问题。
再一次,绝对确定每个人都听到了我的声音: 不要使用这种方法来创建实际的项目估算。 它充其量对于提出最小基线项目“规模”很有用,您可以在董事会会议上说这些话来设定一些类似的期望,而无需在虚线上签字。