-
将项目分解为细粒度的任务。对一个大项目进行估算时，先将其分解成若干个小任务，再对每个小任务进行估算。如果一个任务需要两天以上的时间，就进一步分解。冗长的估算过程里总是隐藏着恼人的意外，把它当作一个警告，表明你还没有对这个任务进行充分的思考，没有彻底理解它所涉及的内容。任务拆分得越细，未考虑到的子任务在以后悄然出现的可能性就越小。
-
根据任务需要的时间进行估算，而不是根据自己或别人的希望花多长时间进行估算。管理者会很自然地采用某个版本的帕金森定律，该定律认为“工作会自动地膨胀，占满一个人所有可用的时间。”9管理者会质疑估算结果，目的是推动我们更快地完成任务。但是，如果你已将估算做得很细，就更容易回应质疑。我见过的一个折中方案是用估算值来设定一个公开目标，用主管的要求来设定一个内部的延伸目标（stretch goal）。
-
将估算结果视为概率分布，而不是最佳情况。我们经常将估算结果视为“最乐观的预测，其实现概率大于零”。估算变成了一个“你最快什么时候会无法证明自己不会失败”的游戏。10因为我们是在信息不完全的情况下工作，所以我们应该将估算结果看作是一系列结果的概率分布，包括最好的情况和最坏的情况。
-
让执行实际任务的人来做估算。每个人拥有技能不同，对代码库的熟悉程度也不一样。因此，你花1小时完成的工作，别人可能需要3小时。尽可能让真正负责某项任务的人去做实际的估算工作。将估算的工作分配给更多的团队成员，可以让他们练习估算能力，并且让大家相互能看到不同的人对工作量是如何高估或是低估的（大多数人会低估）。
-
谨防锚定偏差（anchoring bias）。在实际列出所涉及的任务之前，要避免轻易承诺一个初步的数字，因为较低的估算值可能会设定初始锚点，使得以后难以生成更准确的估算结果。
-
使用多种方法估算同一任务。这样做有助于增强对估算方法正确性的信心。例如，假设你正在构建一个新功能，可以这样做：1）将项目分解为细粒度任务，估算每个单独的任务所需的时间，进行自底向上的估算；2）收集历史数据，了解交付类似软件所需的时间；3）计算必须构建的子系统的数量，并估算每个子系统所需的平均时间。新的团队成员需要一段时间来适应项目才能有产出，所以不要认为增加更多的人就可以缩短项目的时间。
-
根据历史数据验证估算结果。如果你知道从历史数据上看自己总是低估20%，那么就很清楚，需要将总体的估算值增加25%；或者，你也可以说，因为你上个季度将用户或收入的增长率提高了25%，本季度预计也能实现类似的增长率。
-
使用时间盒（Time Box）限制任务范围。我们应当为开放性的活动分配一段固定的时间，或者一个时间盒。与其估算完成某项研究大概需要3天时间，不如承诺在3天之后根据现有的数据尽可能做出最好的决定。
-
允许他人质疑估算结果。做估算是很难的，所以我们都会有找捷径或死盯数字的倾向。在团队会议上对估算结果进行审查，虽然会增加一些额外的成本，但是能够提高估算结果的准确性和支持度。其他人可以凭借自己的知识或经验，帮助我们发现估算中的错误或缺失的部分。
网友评论