近日,Michael Sync 提出这样一个问题:如何对大项目或是大特性进行估算:
我知道我们不应该对一个以上的 sprint 进行估算,因为后面可能会对其进行修改。但真实情况往往并非如此。我们需要提前对整个项目或是一些特性进行估算,这样才能确定目标日期并对特性进行调整或是改变其优先级。 为了能更加精确地进行估算,我们需要在创建 sprint 之前将用户故事分解为任务。 那该如何处理或是估算呢?
Peter Bell对估算与承诺进行了严格的区分:
是否有人问过你关于估算或是承诺的问题呢?所谓估算,就是根据目前可用的信息做出的合理猜测。估算不是偏高就是偏低,通常在构建复杂软件时估算会偏低。他们不是承诺,也不能当作承诺。
Scrum Development 邮件列表上的成员所达成的共识是项目估算并非特别有用,也不值得你花很多时间在这上面。“woynam”写到:
进行估算的组织请不要再忧虑某些东西要花费多少代价了,请转到变化上来吧。如果你知道要花费多少代价、要花费多少时间,那么唯一变化的就是你的这些钱会实现多少个高优先级的特性了。关键在于如果你不再进行估算, 那么你仍旧可以确保首先实现最有价值的那些特性。
George Dinwiddie写到:
如果利润或是损失取决于对花费的精准预测,那么你可能选错产品了。这种产品的升值潜力太低了。 我经常发现组织中的高层很清楚这一点,但中层经理往往不太理解:
对于大多数组织来说,估算都不是什么好事:他们被当作承诺和威胁,还会导致人们机械化地决定工作量、增加故事点或是小时数,而非仔细洞察团队到底能完成什么,如何完成。 我完全不赞成对故事进行估算,除了这样的描述:“几个人干几天”。当然了,这仍然是估算,但却不易被误用。
我喜欢让团队在几周内对大的故事进行估算,然后不断累加。这么做的结果会让人们对项目大小形成一种共识。不能将这当作承诺,但可以作为一个点,你可以提出重要的问题,比如说:在 N 美元和 M 月的前提下, 我们能否交付呢?
评论