[译] 敏捷软件开发 - 项目估计的意义
原作者：Martin Fowler
原文链接：PurposeOfEstimation
翻译：北十九
image.png
我第一次接触敏捷软件开发，是在极限编程开始的时候与 Kent Beck 一起。那个项目，他们做计划的方式给我留下了深刻的印象。跟我之前的经历相比，他们采用了更轻量但有效的估计方法。从那时起到现在，已经过了不止十年。在资深的敏捷践行者中间，一直存在一个争论：估计是不是值得做，或者这是不是一个有害的事情。要想回答这个问题，我们一定要先看下估计的意义到底是什么。
经常会有下面这些场景发生：
- 开发被要求对即将到来的活动进行估计。人们总是乐观的，所以估计值往往偏低，即使是在没有施加压力的情况下（岁经常会有一些隐性的压力）
- 这些任务和估计会转变为发布计划，并使用燃尽图进行追踪
- 在计划里会用时间追踪工作量进度。当工作在预定时间没完成的时候，谁都会感觉不舒服。为了加快节奏来赶上估计，开发会被告知通过牺牲质量来完成预定工作，不过这只会让事情变得更糟。
狭义上讲，把工作量转换成估计，在最好的情况下，也是一种浪费。因为“估计是干净衬衣上的猜测”（PS：没看懂老马在说什么。。）。大部分情况下，估计会以严重的副作用告终，因为他们会鼓励 FeatureDevotion 这么一种令人难受的状况 ---- 人们开始关注于勾掉那些完成的功能，而不是追踪项目真正的价值产出。
估计还会设置一种期望。因为估计值往往偏低，所以这事实上设置了一种不切实际的期望。对某个功能来说，花更多的时间来做，或者在预定的时间交付了少的功能，都被视为一种损失。因为对损失的恐惧，这些损失会有一个放大效应。
面对类似这样的情况，很容易看到人们会把他们的怒气撒到估计身上。这会导致一种观念的增强：任何沉溺于估计的人都不是一个真正的敏捷践行者。敏捷的批评者会说：敏捷开发就是开发人员在做一些模棱两可的东西，并承诺能完成，并且当完成的时候，保证你一定会喜欢。
我不会说估计是一个生而邪恶的实践。如果有人问我估计是不是一件坏东西，我的回答是标准的咨询师套路 -- it depends。任何时候，当有人回答“it depends”的时候，接下来的问题就是“取决于什么(upon what)”。想要回答这个，我们必须要问，为什么我们要做估计 -- 就像我常说的“如果这值得做好，那么在地球上你为什么要做它，就值得问一下”。
对我来说，当估计可以帮你做一个重要决定的时候，它是有价值的。
关于估计影响决策的第一个例子，是关于资源的分配。组织拥有基本固定数量的钱和人，经常有太多值得做的事情。因此人们面临着这样的抉择：我要做A还是B？面对这样的决定时，经常需要知道每件事情都涉及多少工作量（成本）。关于要做什么，如果想要做一个合理的决策，那么你需要对这两件事情的成本和收益都有些感觉。
另一个例子是协同互助。蓝队想要在他们的网站上发布一些新特性，但是直到绿队构建一个新的服务提供了关键数据之后才能做。如果绿队估计他们会在2个月内做完，蓝队估计会花一个月来构建新特性，那么蓝队就知道没必要今天就开始。他们可以花至少一个月的时间工作在其它特性上，以尽早发布。
因此，当你考虑是不是需要一个估计的时候，你应该搞清楚这个估计会影响什么决策。如果你发现没有，或者这个决定并不重要，那么这是个信号 --- 估计是浪费的。当你确实有个决策与估计相关，那么估计可以给这个决定提供一些上下文，不过还是需要说明估计所需要的精确程度，以避免不必要的浪费。
还要明白的一点是，这个决策可能可以用估计之外的行动来决定。可能任务A并不比B重要，你不需要把你全部的能量放到估计上，来率先把这件事完成。可能对蓝队成员来说，还可以跟绿队一块工作，来让服务构建的更快一些。
同样，对计划的追踪也应该由它如何影响决策来驱动。在这里我经常会说，计划要作为估计改变的基线而存在。如果我们想要增加一个新特性，我们如何把它合适地放到五磅的袋子里？估计可以帮助我们理解这些权衡，以此决定对变化如何反应。在更大的尺度上，重估一整个发布可以帮我们理解，项目作为一个整体，我们的工作是否还是最优地分配在项目上。一些年前，我们有一个长达一年的项目，在做了两个月后进行了一次重估，项目被取消了。我们将此视之为成功，因为重估表明这个项目将会花费比我们初期预计的长得多的时间。更早的结束，可以让客户把资源移到更佳的目标上。
但是记住，在追踪项目计划中，估计的保质期有限。我还记得有一个粗放的项目经理说过，计划和估计就像生菜叶子一样，一两天还挺新鲜，一个星期后就皱巴巴了，如果过了一两个月，就完全认不出来了。
很多团队发现估计可以提供一个有效的推动力，让团队成员彼此沟通。估计会议可以让大家对即将要做的故事卡有更好的理解，包括未来的架构方向，以及代码库的设计问题。在这种前提下，任何输出的估计值变得不那么重要。这样的交流有很多种方式发生，但是如果这种讨论没有发生的话，估计的研讨可以被引入。相反，如果你在考虑停止估计的实践，你需要确保在估计中的有效沟通，可以在其它地方继续发生。
去参加任何敏捷相关的会议，你都会听到在没有估计的情况下团队有效工作的事情。很多情况下这都行得通，是因为他们，以及他们的客户，理解进行估计并不会影响重要的决定。其中有一个例子，是一个小团队与业务紧密工作在一起，如果更大范围上，业务乐于安排一些人到业务单元上，那么工作可以贯彻业务的优先级；这会帮助团队把工作分解到更小的单元。团队级别的敏捷流畅度模型，在这里就扮演者重要的角色。当团队进度与估计发生冲突的时候，他们可以有效的调整，然后达到目标。
估计既不好，也不坏。如果你可以在没有估计的情况下有效工作，那么继续下去。如果你认为你需要一些估计，那么确保你理解它们在决策制定时扮演的角色。如果它们会有重大影响，那么就尽量把估计做到最好。在此之外，要谨防那些总是告诉你他们需要估计或者完全不需要估计的人。任何关于是否进行估计的争辩，总应该指向这样的敏捷原则 -- 在特定的情景下，要采用哪些正确的技术，应该由你来决定。
