[译] 敏捷软件开发 - 项目估计的意义

作者: 北十九 | 来源:发表于2017-07-03 17:10 被阅读88次

    原作者:Martin Fowler
    原文链接:PurposeOfEstimation
    翻译:北十九


    image.png

    我第一次接触敏捷软件开发,是在极限编程开始的时候与 Kent Beck 一起。那个项目,他们做计划的方式给我留下了深刻的印象。跟我之前的经历相比,他们采用了更轻量但有效的估计方法。从那时起到现在,已经过了不止十年。在资深的敏捷践行者中间,一直存在一个争论:估计是不是值得做,或者这是不是一个有害的事情。要想回答这个问题,我们一定要先看下估计的意义到底是什么。

    经常会有下面这些场景发生:

    • 开发被要求对即将到来的活动进行估计。人们总是乐观的,所以估计值往往偏低,即使是在没有施加压力的情况下(岁经常会有一些隐性的压力)
    • 这些任务和估计会转变为发布计划,并使用燃尽图进行追踪
    • 在计划里会用时间追踪工作量进度。当工作在预定时间没完成的时候,谁都会感觉不舒服。为了加快节奏来赶上估计,开发会被告知通过牺牲质量来完成预定工作,不过这只会让事情变得更糟。

    狭义上讲,把工作量转换成估计,在最好的情况下,也是一种浪费。因为“估计是干净衬衣上的猜测”(PS:没看懂老马在说什么。。)。大部分情况下,估计会以严重的副作用告终,因为他们会鼓励 FeatureDevotion 这么一种令人难受的状况 ---- 人们开始关注于勾掉那些完成的功能,而不是追踪项目真正的价值产出。

    估计还会设置一种期望。因为估计值往往偏低,所以这事实上设置了一种不切实际的期望。对某个功能来说,花更多的时间来做,或者在预定的时间交付了少的功能,都被视为一种损失。因为对损失的恐惧,这些损失会有一个放大效应。

    面对类似这样的情况,很容易看到人们会把他们的怒气撒到估计身上。这会导致一种观念的增强:任何沉溺于估计的人都不是一个真正的敏捷践行者。敏捷的批评者会说:敏捷开发就是开发人员在做一些模棱两可的东西,并承诺能完成,并且当完成的时候,保证你一定会喜欢。

    我不会说估计是一个生而邪恶的实践。如果有人问我估计是不是一件坏东西,我的回答是标准的咨询师套路 -- it depends。任何时候,当有人回答“it depends”的时候,接下来的问题就是“取决于什么(upon what)”。想要回答这个,我们必须要问,为什么我们要做估计 -- 就像我常说的“如果这值得做好,那么在地球上你为什么要做它,就值得问一下”。

    对我来说,当估计可以帮你做一个重要决定的时候,它是有价值的。

    关于估计影响决策的第一个例子,是关于资源的分配。组织拥有基本固定数量的钱和人,经常有太多值得做的事情。因此人们面临着这样的抉择:我要做A还是B?面对这样的决定时,经常需要知道每件事情都涉及多少工作量(成本)。关于要做什么,如果想要做一个合理的决策,那么你需要对这两件事情的成本和收益都有些感觉。

    另一个例子是协同互助。蓝队想要在他们的网站上发布一些新特性,但是直到绿队构建一个新的服务提供了关键数据之后才能做。如果绿队估计他们会在2个月内做完,蓝队估计会花一个月来构建新特性,那么蓝队就知道没必要今天就开始。他们可以花至少一个月的时间工作在其它特性上,以尽早发布。

    因此,当你考虑是不是需要一个估计的时候,你应该搞清楚这个估计会影响什么决策。如果你发现没有,或者这个决定并不重要,那么这是个信号 --- 估计是浪费的。当你确实有个决策与估计相关,那么估计可以给这个决定提供一些上下文,不过还是需要说明估计所需要的精确程度,以避免不必要的浪费。

    还要明白的一点是,这个决策可能可以用估计之外的行动来决定。可能任务A并不比B重要,你不需要把你全部的能量放到估计上,来率先把这件事完成。可能对蓝队成员来说,还可以跟绿队一块工作,来让服务构建的更快一些。

    同样,对计划的追踪也应该由它如何影响决策来驱动。在这里我经常会说,计划要作为估计改变的基线而存在。如果我们想要增加一个新特性,我们如何把它合适地放到五磅的袋子里?估计可以帮助我们理解这些权衡,以此决定对变化如何反应。在更大的尺度上,重估一整个发布可以帮我们理解,项目作为一个整体,我们的工作是否还是最优地分配在项目上。一些年前,我们有一个长达一年的项目,在做了两个月后进行了一次重估,项目被取消了。我们将此视之为成功,因为重估表明这个项目将会花费比我们初期预计的长得多的时间。更早的结束,可以让客户把资源移到更佳的目标上。

    但是记住,在追踪项目计划中,估计的保质期有限。我还记得有一个粗放的项目经理说过,计划和估计就像生菜叶子一样,一两天还挺新鲜,一个星期后就皱巴巴了,如果过了一两个月,就完全认不出来了。

    很多团队发现估计可以提供一个有效的推动力,让团队成员彼此沟通。估计会议可以让大家对即将要做的故事卡有更好的理解,包括未来的架构方向,以及代码库的设计问题。在这种前提下,任何输出的估计值变得不那么重要。这样的交流有很多种方式发生,但是如果这种讨论没有发生的话,估计的研讨可以被引入。相反,如果你在考虑停止估计的实践,你需要确保在估计中的有效沟通,可以在其它地方继续发生。

    去参加任何敏捷相关的会议,你都会听到在没有估计的情况下团队有效工作的事情。很多情况下这都行得通,是因为他们,以及他们的客户,理解进行估计并不会影响重要的决定。其中有一个例子,是一个小团队与业务紧密工作在一起,如果更大范围上,业务乐于安排一些人到业务单元上,那么工作可以贯彻业务的优先级;这会帮助团队把工作分解到更小的单元。团队级别的敏捷流畅度模型,在这里就扮演者重要的角色。当团队进度与估计发生冲突的时候,他们可以有效的调整,然后达到目标。

    估计既不好,也不坏。如果你可以在没有估计的情况下有效工作,那么继续下去。如果你认为你需要一些估计,那么确保你理解它们在决策制定时扮演的角色。如果它们会有重大影响,那么就尽量把估计做到最好。在此之外,要谨防那些总是告诉你他们需要估计或者完全不需要估计的人。任何关于是否进行估计的争辩,总应该指向这样的敏捷原则 -- 在特定的情景下,要采用哪些正确的技术,应该由你来决定。

    相关文章

      网友评论

        本文标题:[译] 敏捷软件开发 - 项目估计的意义

        本文链接:https://www.haomeiwen.com/subject/dhkzcxtx.html