我还注意到,事情总是似乎比原计划需要更长的时间,有时甚至要长得多。我不知道为什么我们不开始计划它,但我认为这可能是出于激励目的。
Ryan
我完全同意之前的帖子...不要忘记你团队的工作量。仅仅因为你估计一个项目需要3个月完成,并不意味着它会在那个时间之内完成。
我在一个较小的团队中工作(5名开发人员,1名领导),我们中的许多人同时参与几个项目 - 有些大,有些小。根据项目的优先级、管理层的心血来潮以及其他团队的可用性(如果需要),对项目的工作会穿插在其他项目中间。
因此,是的,价值3个月的工作可能是准确无误的,但可能是在6个月的时间段内完成的价值3个月的工作。
我曾经独立完成了1-6个月的项目,而且我总是倾向于将我的原始估计翻倍或者四倍。
比较两个编程项目实际上是不可能的,因为有太多的因素意味着仅从一个项目中得出的指标并不适用于另一个项目(例如使用的特定技术、开发人员的先前经验、需求的变化)。除非您正在复制几乎与之前构建的系统完全相同的另一个系统,否则您的估计将具有低准确性的概率。
当您与同一团队构建现有系统的下一个版本时,一个警告是:具体的经验可以提高估计下一批工作的能力。
我见过太多的估算方法尝试,但没有一种方法奏效。它们可能具有伪科学的吸引力,但在实践中却行不通。
唯一有意义的答案是敏捷倡导者所提倡的相对短的迭代:选择可以在短时间内执行的工作范围,交付它,然后进行下一轮。预算是根据短期基础分配的,利益相关者能够评估他们的资金是否被有效地使用。如果进展缓慢,他们可以放弃该项目。
我从2周到1年的时间内完成项目。通常情况下,我的估计是相当准确的,事后来看。然而,在项目开始时,我通常会受到抨击,因为我的估计被认为太大了。
这是因为我考虑了很多人们忘记的事情:
诀窍在于使用基于证据的调度(请参见Joel on Software)。
问题是,如果你计划多留一点时间,如果没有问题出现,你将用它来改进代码库。如果出现问题,你仍然在估计范围内。
我相信Joel已经写过一篇关于这个的文章:你可以要求团队中的每个开发人员详细列出他的任务(需要完成哪些步骤),并要求他们估计每个步骤所需的时间。稍后,当项目完成时,将实际时间与估计时间进行比较,就可以得到每个开发人员的偏差。在开始新项目时,再次要求他们评估时间,并将每个开发人员的偏差乘以估计时间,以获得接近实际预期的值。
几个项目后,你应该有非常好的估计结果。