是否有充分的理由对几个月后的特性进行时间估计?

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

如果使用这些估计值向管理层报告而不需要警告,那么这可能是一种危险的做法。另一方面,如果他们被用来做一些高层次的计划或起草一个项目计划供讨论,那么这些估计可能非常有用。

我们经常用wag(狂野的屁股猜测)这个词来做这些估计。它们可能有+100%/-50%的差异。随着需求的充实,这个估计被转移到一个球场估计,可能有+50%/-50%的差异。

是的,我想说你错过了要点。

也许类比是正确的…你在做一些家庭更新,你来找我估计一下我的工作。我问你想做什么,你告诉我。然后我带着一个引言回来。我告诉你,“好吧,我知道下个星期我会做什么,但从那一点上,它会变得有点模糊……我真的不认为我有什么特别的价值,但我确信在几个月/几年后/无论它会做什么,但只要你继续付钱给我,我肯定我能想出怎么做。”

我能得到这份工作吗?

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

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

然而,重要的是不要掉进这里的陷阱-你可以说“好吧,可能要花N天”,然后三个月后,在功能被极大地膨胀之后,管理层会告诉你“你承诺要花N天,你怎么敢现在增加估计和需求4N天?”您需要证明这是一个非常扭曲的估计,因为您还不完全知道特性的大小。

我读过的关于管理软件开发过程的最好的书是 Rapid Development 史蒂夫·麦康奈尔。这涵盖了估算的问题,非常详细——如果你参与了项目规划,而你没有读过这本书,我怀疑你真的知道你在做什么(我没有读过)。

这就像在六个月后的某一天预测天气一样:你不知道天气会怎样,但你可以说出天气会怎样。基于这些假设,我们可以展望未来,粗略估计暖气或空调的费用,规划衣柜,预定假期,邀请朋友过来。

现在,预测软件开发在某种意义上不同于预测天气,作为程序员,我们对构建软件的影响比天气更大,更直接:我们可以添加和削减特性,优先考虑,有时甚至灵活使用资源。

通过有一个比较现实的目标,团队的目标是在三个月或六个月内实现,这就有可能倒退工作,并找出所有必须做的事情才能达到目标。然后评估任务并沉溺于削减特性、设置优先级和移动资源。有时,在三个月内有一个明确的目标会对明天或马上要做的事情的任务和优先顺序产生怎样的影响,这可能是非常有启发性和令人惊讶的。

我们需要找到更多的客户吗?或者现在开始找更多的人?我们是应该削减特色,还是应该在我们的计划中变得更雄心勃勃?约翰能在两个月内休两周年假吗?我们现在应该考虑介绍一个额外的开发人员,作为约翰休假时的掩护吗?

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

我想你误解了为什么要你做这些估计。

假设您有特性A、B、C、D和E,您希望按这个顺序实现这些特性。你估计他们每个人大约要花一周的时间。 您的管理层不想知道从现在起一个月后是否需要一周时间来实现特性E。 他们想知道你的项目是否能按时完成。如果有延误,他们希望尽早知道,以便采取行动使项目回到正轨。所以他们要求你的评估,这不仅给他们一个结束日期(不管它可能是多么不确定),而且也给他们一个功能A,B,C和D的里程碑。现在他们可以通过检查你是否达到了里程碑,很容易地看到项目是否延迟。

这就是他们想要的原因。

乔尔说 in one of his articles 一个详细的时间表使您提前考虑模块的设计,从而通过软件的体系结构得到更好的思考。

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

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

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