|
引言pmp.mypm.net
当你要雇一位漆工来装饰你的房子，或者一位修理工来修你的车时，你会要他们先给个估算，对吗?你需要知道大概会花多少钱，需要多长时间。这是常识。training.mypm.net
然而经验告诉我们什么?初始的估算和最终的账单有多大差距?很有可能漆工会发现有松动的石膏需要铲除，墙面需要修补和重新粉刷;修理工一定会发现要让你车子重新上路还有些其它的问题要解决。在1951年的《纽约客》杂志中有这样一幅漫画，Syd Hoff画了一个修理工对他的客户说：项目管理者联盟
“当然，那不过只是个估算，实际的花费一定会更多”service.mypm.net
如果漆工或修理工告诉我们的这些问题还不是非常紧迫，我们可以选择暂时不处理…… 然而，通常的情况是，我们会觉得不得不修复那些额外的问题。谁会想住在一个可能墙面受潮的房子里，或者开着一辆有可能方向盘失灵的车呢?项目管理培训
那我们怎么解决这样的问题呢?常见的做法就是我们坚持要工人给一个全面的、确定最终价格的估算，也就是通常我们叫的“报价单”，这样工人就会花更多心思用更长的时间来进行更准确的估算。然而现实中，无论他们如何用心努力，终究还是无法预知到那些意想不到的问题。www.mypm.net
在项目中，我们面临同样的问题pmp.mypm.net
传统上，项目经理往往会致力于创建很详细的估算，这个估算从财务的角度要经得起推敲。当然这样的估算是基于能够预见的情况再加上针对“已知的未知因素”所设的应急预算…… 然而就像Donald Rumsfeld的名言所说“有一些我们未知的未知因素——有些事情我们根本不知道我们不知道”。就像上面那些商人，我们永远无法预知那些意想不到的情况。项目管理者联盟
我们花越长的时间来创建详细的估算，麻烦却越多。我们可以把详细的估算看作是一个绑定报价，一个不同于真正交付价值的目标，它使得我们的注意力都放到能在协议的日期和成本内交付一些东西——任何东西，无论它的价值高低。项目经理圈子
在每次实施后的回顾评审中，初始估算和实际之间的差距总是让我们备受打击，然后告诉我们自己下次再努力些。爱因斯坦曾经说过，所谓神经错乱就是“一遍又一遍地做同样的事情，却期望得到不同的结果”。因此事情不应该这样，一定有其它更好的方法。项目经理圈子
敏捷项目显然就不是这样?我们何不就从一个大概的需求范围开始，然后在做的过程中逐渐理清细节?嗯，对，但也不全对。在敏捷项目中我们不会去创建详细的估算来束缚自己，但是对将要进行的工作量的大小有一个认识还是很重要的，这就是为什么……项目管理者联盟
为什么我们需要估算项目管理者联盟
忘掉那些传统的估算，那些漂亮的精心制作的甘特图，那些图表迫使我们的注意力都放在要进行的任务上，而不是要交付的成果。在项目中有三种活动需要我们进行一些粗略的估算。项目经理圈子
当我们在考虑一个新提议项目的合理性时，我们需要提前知道大概的成本，这样才能决定是否值得投入。项目管理者联盟
当我们正在将新的或改进的产品推向市场时，我们需要知道那些重要的特性大概什么时候可以发布，这样我们才能安排相关的活动。项目管理者联盟
当我们在为工作排优先级时，产品负责人需要知道每个故事(或待办清单项)的成本，而团队需要知道每个故事的价值。bbs.mypm.net
有件事很有意思，只要整个团队都一起参与进来共同协作，估算本身也可以变成一种很有意义的活动。它有助于团队增进理解，并保证团队每个人都对要交付的需求范围和价值达成共识。项目管理者联盟
然而对“估算”这个词的传统理解可能会让我们偏离这个方向。blog.mypm.net
使用“大小”而不是“估算”项目管理者联盟
为了避免让人误会我们讨论的是对成本和时间的估算，当我们评估一个故事的复杂程度时，有些人喜欢用“大小”而不是“估算”来描述。在90年代当我第一次使用Scrum和XP时——那时它们都还没有被称为敏捷实践——我们是使用T-shirt尺寸来评估故事的大小(S，M，L，和XL)。项目管理者联盟
现在我们使用故事点数——一种评估故事之间相对大小的方法——因此我们先找到可能最简单的故事，将它的点数设为1点，接下来用其他的故事与它进行比较，如果另一个故事比这个更复杂，那个故事可能就是3点。service.mypm.net
让评估变得更有趣的是，我们不采用简单连续的数列，比如1，2，3，4，5等——而是采用一种近似菲波拉契数列的形式，像1，2，3，5，8，13等(就如《达芬奇密码》里面看到的)。这样当数字越大相邻数之间的间隔也越大，使得我们更容易区分哪个故事更小哪个更大。项目经理圈子
尽管这不是一种精确的科学，但对上面提到的三种需要估算的情况这种方法已经足够好了。像John Maynard Keynes所说，“粗略的正确好过精确的错误”。这也意味着，我们仍然需要将故事点数转换成粗略的时间和成本估算。bbs.mypm.net
另一个主要用于敏捷项目的实践是建立“完成标准”，就是对一个故事要能够标注为完成并可发布所需要满足的所有条件进行全面的理解，包括各种项目，比如用户文档、翻译、广告等等。项目管理者联盟
假如我们有清晰的完成标准，就可以拿几个样例故事来计算所需要的工作量。基于这种计算我们就能为投资决策进行粗略的成本估算，为版本计划进行粗略的时间估算，让我们对故事有更充分的认识以便能协助产品负责人进行故事优先级的设置。项目管理者联盟
|
