分类: 敏捷

估算的目的

我第一次与敏捷软件开发的邂逅,是在极限编程刚刚兴起时,跟Kent Beck一起工作的经历。其中让我印象深刻的事情之一,就是我们如何做计划的方式。这里面包括一种估算方式,比起我之前见到过的其他方法,它既轻量,还更有效。这样过了十年,现在一些有经验的敏捷实践者,开始了一场关于估算是否值得甚至是否有害的争论。我想,为了回答这个问题,我们必须审视一下估算的目的。

通常的场景是这样的:

  • 开发者被要求给出对于即将开始工作的估算。人们大多是乐观派,即使没有压力的情况下(一般至少也会有点压力),这些估算通常会比较小。
  • 这些任务和估算会被转化成发布计划,然后用燃尽图跟踪。
  • 接着,人们就会按照这些计划,持续监控着团队为完成任务所投入的时间和资源。结果当实际消耗的时间和资源,超过当初的估算时,每个人都会变得失望。为了迎合当初的估算, 开发者被要求牺牲软件的质量,但这只会让事情变得更糟。

这种情形下,对估算的投入充其量就是一种浪费——因为“估算就是在干净的衬衫上猜测”。只有当估算被当做追逐更多特性的手段时,它才会变成实质上有害的行为。过分追逐特性是一种很糟糕的情形,人们只是始热衷于完成一个又一个特性,而不是追踪项目的真实结果。

估算还会设定期望值,既然估算通常会偏低,所以它们设定的期望值也多是不切实际的。任何时间上的增长,或者软件特性被砍掉,都会被视作是失败。出于对风险的逃避,这些失败的后果往往会被放大。

面对类似这样的情况,我们就很容易看到人们把愤怒对准了估算本身。这样也导致越来越多的人认为,任何沉迷于估算的人并不是真正的敏捷实践者。而批评敏捷的人则说,这意味着敏捷软件开发的本质就是,开发者很快动手开始做,却并不明确要做什么,而且承诺说,该做完的时候肯定会做完它,而且你肯定会喜欢它。

我并不同意估算是天生有害的活动。如果有人问我,估算是不是件糟糕的事情,我的答案会是一名标准咨询师的答案:“不一定”。而接下来的问题就会是“取决于什么”。为了回答这个问题,我们就不得不问,我们为什么要估算——因为我想说:“如果事情值得做好,就值得问清楚,我们到底为什么要做它”。

对于我来说,当你面临重大的决策时,估算就是有价值的。

我的第一个得益于估算决策的例子是:资源的分配。一般来说,组织大多拥有固定数目的钱和人,而且通常有太多值得做的事情。因此人们就面临选择:我们是做A还是B?面对这样的问题,了解A和B分别要涉及多少投入(以及成本)是有必要的。为了做出一个明智的决策,你需要有对成本和收益有个大致的了解。

另外一个例子是估算对协调的帮助。蓝色团队想在他们的网站上发布一个新的特性,但直到绿色团队创建新的服务提供给他们关键数据后才能发布。如果绿色团队估算他们会在两个月后才能完成新的服务,而蓝色团队估算需要一个月去能完成新的特性,那么蓝色团队就知道不值得现在就开始实现这个新特性。他们可以花费至少一个月时间,工作在其他可以早点发布的特性上。

所以任何时候当你想做估算时,你应当非常清楚哪一项决策需要依赖这个估算。如果你找不到这样一项决策,或者那个决策并不是那么重要,这就是一个信号:此时做估算是在浪费时间。当你找到这样一个决策时,那要知道问题的上下文是什么,为什么估算会很重要。同样还要搞清楚期望的精度和准确性。

同时也要明白,有时候为了做决策,可能会是其他替代的方案,而未必需要估算。也许任务A比起B要重要得多,以至于你都不需要一开始把你所有的空闲精力都放在B上。也许有办法让蓝色团队和绿色团队合作,更快地创建出服务来。

类似地,跟踪计划也应该由它如何影响决策来驱动。通常我的意见是,计划扮演的是基线角色,帮助评估变化——如果我们想要添加一个新的特性,我们应该如何把它放进既定的“五磅篮”里呢?估算可以帮我们理解这些取舍,并因此决定如何响应变化。在更大范围下,重新评估整个发布计划,可以帮助我们理解整个项目是否仍然充分有效利用了我们的能力。几年前,我们曾经有一个规模达一年之久的项目,在重估时发现还要多花几个月进去,之后我们取消了这个项目。我们把这视作成功,因为重新估算发现,项目会比我们最初期望的会花费更长时间——早点取消可以让客户把资源转移到更好的目标上。

但跟踪计划的同时,也要记住估算是有适用期限的。我曾经记得有一位经历颇丰的项目经理说过,计划和估算就像是生菜,刚过几天还很新鲜,过了一周有点枯萎了,几个月后就完全看不出来是什么了。

许多团队发现,估算提供了一种有用的机制,可以促使团队成员间彼此交流。估算会议可以帮助大家以不同的方式,对实现即将开始的故事、未来的架构方向和代码库中的设计问题,有更好的理解。在这种情况下,任何输出的估算数字可能都不重要。这样的对话可能以很多方式发生,但如果这些对话没有发生,就可以引入关于估算的讨论。相反地,如果你考虑停止估算,你需要确保估算时会发生的任何有效的对话,在其他地方还能够继续进行。

在任何敏捷相关的会议上,你都会听到很多团队在谈论,没有估算他们也可以工作得很有效。通常这是因为,他们以及他们的客户明白做估算并不会影响重大的决定。举个例子,一支小团队在和业务人员紧密协作。如果广阔的商业前景很乐意分配一些人到那个业务单元,那么就可以按照优先级开展工作;通常这得益于团队把工作拆分成足够小的单元。团队在敏捷流畅度模型中的等级,在这里起到非常重要的作用。在团队前进时,他们首先会纠缠于估算本身,然后开始会做很好的估算,最后达到不再需要估算的境界。

估算本身并无好坏之分。如果你不用估算就可以有效地工作,那就这么干。如果你需要一些估算,那就要确认你很清楚估算在决策时起到的作用。如果估算会影响到重大的决定,那就尽可能做出最好的估算。一定要小心那帮告诉你任何时候都要做估算,或者从来不需要估算的人。任何关于估算用法的争论,都要遵从于敏捷的原则,即针对你特定的上下文,决定你该采用的什么样的方法。

Share

发表评论

评论