软件工程估算的技巧 - shubhro


Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章,介绍了如何更好地估计一个项目需要多长时间才能完成。
一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐观的,而计划是最悲观的(它解释了可能遇到的任何问题)。

工程师们经常要互相询问 "估算"--对项目所需时间的粗略预测。虽然有些团队做了严格的估算仪式,取得了不同程度的成功,但许多情况下只需要根据直觉来回答。

尽管答案往往是基于直觉,但你如何要求和解释估计仍然很重要。以下是我观察到的一些行为上的小技巧,它们往往能使一次糟糕的估算谈话和一次伟大的估算谈话之间产生区别。

将估计与目标、承诺与计划分开
考虑一个估计是否真的是你所寻找的东西。估算与目标、承诺或计划是不同的。

在《软件估算。解密黑科技》中,Steve McConnell对它们进行了相应的区分。

  • 估算:预测:"预测一个项目将需要多长时间或花费多少钱"
  • 目标:"一个理想的商业目标的声明"
  • 承诺:承诺:"承诺在某一日期前以特定的质量水平交付规定的功能"
  • 计划:如何 "寻求一个特定的结果 "的步骤

利益相关者之间的对话常常因为混淆了这四个术语而踏上了错误的道路。值得注意的是,麦康奈尔警告说 "你可以就承诺进行谈判,但不要就估算进行谈判"。

下面的一些小技巧可以同时适用于估算和承诺。

识别极端情况
识别一个项目可能完成的最晚/最早时间是很重要的,但团队经常发现很难推理出这个问题--特别是当被要求当场给出答案时。

在《MFM Mini--提出更好的问题指南》中,Shaan Puri分享了Twitch CPO Dan Clancy的一句精彩提问。

(对于最坏的情况)"我知道我们不知道确切的时间表[......]你什么时候会对我们没有完成这个任务感到惊讶?"

(对于最好的情况)"最好的情况,你在想什么?"

这些问题很有用,因为它们的非正式性鼓励人们分享他们坦率的感受。

注意精确度
当听完一个估计/承诺时,注意答案所表达的 "精确性"--无论是以天、周、月、季度还是年为单位。

然后,为了给自己设定期望值,在所提供的估计值上增加一个单位的表达精度。一个估计在 "第二季度的某个时候 "完成的项目,同样可能在第三季度完成。

当然,项目的真正延迟最终可能是无限长的,但答案的精度至少可以让你从概率上看到延迟可能有多长。

询问一段时间内的信心水平
人们在分享他们的工程估计/承诺时,通常会分享信心水平(高、中、低)。但随着项目的进展,持续更新这些信心水平的情况并不常见。

随着时间的推移,更新信心水平是很有价值的,可以在发现风险的时候促进对话。

这对跨团队的对话特别有用,因为在这种情况下,合作伙伴可能会犹豫不决,直到接近预期完成日期时才会沟通潜在的延误。想象一下,听到以下的每周更新。

(第六周)"还需要四个星期,我们有很高的信心"

(第七周)"仍然需要三周,但我们现在是中等信心"

了解是什么将信心从高位变为中位,将告诉你更多关于潜在的结果,而不是估计本身。

结论
工程估算很少能100%准确地预测现实世界的结果;现实是大多数项目都会出现延误。不过,注意我们如何要求和解释估算,可以帮助适当地设定期望。