交付产品大概需要多少时间,这是客户常常提出的问题,也是让敏捷团队感到不爽的问题。一方面,在没有开始动手前就估算整个产品功能的工作量,等于无头苍蝇到处乱撞。然而,很多情况下,这是一个很现实的问题,团队不能将其抛在脑后。
Jarrod Roberson 提到:不应该估算一整个项目,因为这与敏捷哲学完全是背道而驰。团队最多能够做到的,是根据成本和其他约束条件设定一个日期,产品负责人应该判断到这个日期截止要完成哪些功能。Pascal Thivent 补充道:任何前期的估算都会导致固定的产品范围,这正是敏捷反对的。更极端的建议是:敏捷团队永远不要介入需要前期估算的项目中。
但是,这么做在现实世界中可行吗?
敏捷团队常常遇到这样的情况,客户需要一个大概的估算,以辅助多方面的决策。 Hugo Palma 认为:
我认为,对于实现给定的功能,所有的客户都想了解大致估算,想知道要花多少钱。有人说:如果用敏捷,就不能这么做;我不同意。现实世界中的客户希望知道在一个项目上大概要花多少钱,至少有个粗略的概念,敏捷是可以调整、适应的。
Mike Cohn 提到:他常常被问及,交付一个产品大概要多少个小时。他推荐的第一种方式,是推迟分析,直到有足够的历史数据,或者在 sprint 规划会议上能够得到一些承诺,再做分析。不过,有时候是需要粗略估算。对于这样的情况,Mike 建议使用 backlog 取样技术,找出不同规模用户故事的平均小时数。
如果我们把 1 个点的故事平均一下,也许可以发现大概每个点数需要 3.2 个小时,2 个点的故事要拆分成任务,每个点数大概 4.3 个小时,3 个点的故事平均每个点 4.1 个小时,如此类推。 然后就可以把平均小时数与产品 backlog 中对应规模的故事数乘起来,再加总。
Mike 提醒大家注意:这种技术会把任务识别和估算步骤中引入的不足全部包括进去。Rob Bowley 的评论是: backlog 取样技术没有效果,因为软件开发无法预测,而且像这样的技术估算出来的工作量会低于实际要完成的工作量。
尝试这么做,是没有道理可言的。它必将大大低估所需的工作量。考虑到软件开发需要投入的资金,结果就是对组织造成财务上的伤害,或是毁掉某些人的事业。
Matteo Vaccari 提到:尽管使用 backlog 采样估算也许有助于得到一些数字,但还是会不断出现新的未知数,比如团队成熟度、一起工作的历史数据、完成的定义,等等;这些都将使得估算失去作用。
这种情形下的另一种选择,是采取Martin Fowler 提议的“柔软范围(Scope Limbering)”方法,其用意是:从固定范围合同开始,然后逐步教育客户敏捷的优点,帮助他们克服“固定范围的海市蜃楼(FixedScopeMirage)”。Rob Thomsett 提议的“翻番再加一点(double and add some)”游戏,也与Martin 的方法类似。
因此,在真正意义上,看起来没有哪个方法是完备的。它们都有某种程度的主观性,因此有自己的问题。不过,如果在需要粗略估算的场景中使用这些技术,也许能帮助利益相关者做出更成熟的决策。
评论