3

我今天与一位顾问开会(就内部程序向我们咨询),我们进行了一项计划未来三个月发展的练习。我完全不反对这样做,我认为必须了解接下来会发生什么,以什么顺序以及它们的相对大小。我也认为为你想在特定日期完成的事情设定目标是很棒的。但我一直认为,与这位顾问和我的一些团队成员的不同意见,试图将时间估计(甚至在几天和几周内松散地)用于实现功能(尚未指定,甚至没有讨论)最后)是一项完全没有意义和徒劳的任务。根据我的经验,当我开始工作时,

我是否偏离了基础并且错过了花费时间和精力来猜测在 2 个月内实现 FeatureX需要 8 天(考虑到HL )的价值?

4

7 回答 7

4

这实际上取决于估计将用于什么以及附加什么期望。

如果将估计值用于向管理层报告而没有任何警告,那么这可能是一种危险的做法。另一方面,如果他们被用来做一些高层规划或起草项目计划以供讨论,那么这些估计可能非常有用。

对于这些类型的估计,我们经常使用术语 WAG(野驴猜测)。它们带有可能的 +100%/-50% 差异。随着要求的充实,这个估计被转移到一个可能有 +50%/-50% 差异的棒球场估计。

于 2009-07-27T06:20:49.933 回答
3

是的,我会说你没有抓住重点。

也许和类比是为了......你正在做一些家庭装修,你来找我评估我的工作。我问你想做什么,你告诉我。然后我回来引用一个报价。我告诉你“好吧,我知道我下周要完成什么,但从那时起它会变得有点模糊......我真的认为我没有任何价值,但我确信几个月/几年/不管它会完成什么,但只要你继续付钱给我,我相信我能弄清楚该怎么做。”

我会得到这份工作吗?

于 2009-07-27T06:16:16.043 回答
2

在处理松散规范的需求时,以及在处理几个月后的项目时,给出高级估计通常很有用。高水平估计可以表示为一个广泛的范围(即 4 到 8 周)。它们有助于为估计的接收者提供对大小的粗略了解,使他们能够执行一些计划。围绕高层的合同是,当您需要提供更准确的估计时,它会发生变化。较低级别的估计通常会变得更窄,并且在您最初提供的范围内。此时您需要适当的规范,并更好地了解您的可用资源,这很可能在实施前几个月不可用。

于 2009-07-27T06:17:35.477 回答
1

讨论该功能可能需要多少是完全合理的。这提高了对应该更仔细考虑什么以及应该立即丢弃什么的理解。管理层需要这个来更好地计划并减少产品延迟或不完整的机会。

然而,重要的是不要落入这里的陷阱——你可以说“嗯,可能需要 N 天”,然后三个月后,该功能被大大夸大后,管理层会告诉你“你承诺需要 N 天,你现在怎么敢增加估价和要求4N天?” 您需要证明这是一个非常扭曲的估计,因为您还不完全了解特征大小。

于 2009-07-27T06:14:38.650 回答
1

我读过的关于管理软件开发过程的最好的书是Steve McConnell的《快速开发》。这非常详细地涵盖了估算问题——如果你参与了项目规划并且你没有读过这本书,我怀疑你真的知道你在做什么(我不知道)。

于 2009-07-27T12:38:00.340 回答
0

这就像在六个月后的某一天预测天气:你不知道会发生什么,但你可以说会发生什么。并且基于这些假设,可以展望未来并粗略估计取暖或空调费用,计划衣橱,预订假期并邀请朋友过来。

现在预测软件开发在某种意义上与预测天气有些不同,作为程序员,我们对构建软件的影响比天气更多和直接:我们可以添加和削减功能、优先级,有时甚至可以灵活利用资源。

通过有一个有点现实的目标,团队的目标是在三到六个月的时间内实现,它可以向后工作并找出实现目标必须做的所有事情。然后估计任务并沉迷于削减功能、设置优先级和移动资源。有时,在三个月内制定明确的目标如何影响明天或立即需要完成的任务和优先级,这可能会非常具有启发性和令人惊讶。

我们需要找到更多的客户吗?或者现在就开始寻找更多的人?我们应该削减功能还是应该在我们的计划中变得更加雄心勃勃?如果我们现在考虑引入一个额外的开发人员,作为约翰休假后的掩护,约翰能否在两个月内休两个星期的年假?

开发人员讨厌频繁的任务切换和最后一分钟的项目,通过分配一些资源的清晰路线图,您将帮助开发人员感到更安全并为未来的项目做好准备。

于 2009-07-27T12:30:53.240 回答
-1

我认为您误解了为什么要求您进行这些估算。

假设您有要按该顺序实现的功能 A、B、C、D 和 E。你估计他们每个人都需要大约一周的时间。您的管理层不想知道从现在起一个月后您是否需要一周时间来实施功能 E。他们想知道您的项目是否会按时完成。如果有延误,他们希望尽早知道,以便采取行动使项目重回正轨。因此,他们要求您提供估算,这不仅为他们提供了结束日期(尽管可能不确定),而且还提供了功能 A、B、C 和 D 的里程碑。现在他们可以轻松查看项目是否延迟检查您是否达到了里程碑

这就是他们想要它的原因。

话虽如此,Joel在他的一篇文章中说,详细的时间表可以让您提前考虑模块的设计,从而更好地思考软件架构。

这就是为什么你也应该想要它。


编辑:好吧,也许我误解了你的问题 ;-) 如果你没有明确的功能规范,你不能估计,你只能猜测。其价值相当低。我的建议是引导下一次会议从这些猜测转向更清晰的功能规范。尝试让他们参与有关功能更具体细节的对话。

不要指望他们会提出详细的功能规范。如果他们没有这些,提供它们是你的工作(并在此基础上,给出一些时间估计)。

于 2009-07-27T07:15:15.113 回答