写点什么

估算实践是浪费吗?

2008 年 8 月 15 日

软件的“估算”,这个有年头的老大难问题,最近在敏捷社区内引起了有趣的讨论。J.B. Rainsberger 、Arlo Belshee、Josh Kerievsky、David Anderson 和其他人提出这样一个问题:“估算真的有必要吗?”

著名的敏捷专家 J.B. Rainsberger 在 Yahoo 的 XP 讨论组中发起了一个有趣的讨论,质疑在敏捷软件项目中做估算的必要性。J.B. Rainsberger 与 2008 Gordon Pask 两位中奖者之一 Arlo Belshee 对这个话题有过谈话,他是这样详细讲述的:

[Arlo]对我讲了一些他完成的研究和实践,主要是关于成本估算的,关键在于他的研究和实践中不做这些估算。他的观点是,或者是我领悟到的是,在做出和管理成本估算上付出的精力要超出拥有这些估算带来的好处。

Mike Hill 加入了讨论并指出,Industrial Logic 公司的家伙们在开发自己的敏捷 eLearning 产品时,已经开始朝不做估算的方向转变了:

对我们自己的工作来说,纯粹的“拉”模式就已经很好用了。客户会将需求按优先级排序,并放到“需求栈”中。我们从栈中“拉”出位于顶端的故事并进行实现。规划会议的规模越来越小,大家都把精力放在最重要的任务之上。

Industrial Logic 的创始人 Josh Kerievsky 在 Agile 2008 大会中作了题为“被认为是浪费的估算”的演讲,并涉及很多细节。他解释了大家是如何通过交付更小、更频繁的“微发布版本”来取得成功的,这样大家可使用“点数和速度”方式时积累下来的“直觉”来更高效地开发,而且不必再花时间去在卡片上写数字,做算术题。

不久前,Amit Rathore 接触了类似的想法。 Rathore 描述了这样一个流程,接下来要开发的最重要的需求,将被打散成同样大小的故事(大概耗时几天),并会在下个迭代中按照优先级顺序展开开发:

诀窍在于:每个故事的工作量不应该超过 1-3 天。对下一个需求也做同样的事情,一直这样做,直到这些故事把两周内的时间都安排满。

Rathore 解释了为什么这样做不只减少了“浪费”,而且在很多方面都增加了价值:

这种做法带来了节省时间和精力的有益副作用。能够真正掌控开发流程,是真正的价值所在。小故事允许在必要时做出改变,在需要时可以从待办事项列表(backlog)中拉出来,任何时候有业务需求都可添加新的小故事。它也可以让团队以更快的速度前进,因为开发小块增量代码很容易,测试也方便,将小的版本发布给用户也变得轻松。 最后,强制要求每个故事必须保持小规模,大家就会在开始编程之前深入思考需求。这也可以强制团队将需求拆分成一个个可以进行增量开发的小片段,并且完全可以避免出现总是剩个小尾巴开发不完的故事。

David Anderson 在很长时间之前就做出了类似的评论,并且从那时起就非常积极地参与了“软件的看板”运动。这项运动与Belshee、Kerievsky 和Rathore 讨论的想法有非常密切的联系。

从多个角度观察,也许有人会问:“_ 真的_ 没有进行估算吗?”这也是J.B. 曾经思考过的问题。Kerievsky 和Anderson 认为这种过程其实近乎于“直觉”,Rathore 认为故事的“大小相当”。也许不是,但是这样做是好是坏?问题真的应该是“没有估算?”,还是“没有数字?”还是别的什么?

哪位读者有不进行估算做敏捷项目的经验?不管你估算与否,可以在这里或是 Yahoo 的 XP 讨论组上加入讨论。

查看英文原文: Is Estimating A Wasteful Practice?


InfoQ 英文站的读者和编辑在文后进行了热烈的讨论。Agile 社区首席编辑 Deborah Hartmann 介绍说最近开始使用 T 恤的大小来估算产品待办事项列表。她说道:

……这样做的结果是:当不再需要用数字时,人们会觉得估算起来更加自如。我们都知道,这种级别上的估算讲“准确性”只能是幻觉,可使用数字估算也难逃此劫吧。

她还建议开发工具的人提供将 T 恤估算转换成数字的功能,供版本发布预测使用。

Christian Gruber 更喜欢 Amit 规范故事大小的方式,认为这样可以让预测更容易,并进一步说到:

这样的做法实际上与排队理论是一致的。队列中的单位越规整,如果相对于队列的宽度来说单位的尺寸越小,为了得到最优的有效产出而需要留出的闲置资源就越少,也就是说队列越有效率。经验告诉我,这样做在管道系统、高速公路等方面都是可以的,而且在软件团队中同样可以发挥作用。

文中提到的 Amit Rathore 这样回复:

当然不是不做任何估算了。这与结对编程的精神是一样的,有了结对编程就不必做代码复查了。这更像是“禅”的方式,是通过做得更多来达成目的的——一对开发人员总是在做代码复查,时时刻刻。 将故事们打散成小块是好事情(排队理论)。如果几乎所有的故事都可以拆分到这种程度,就会带来很多好处(正如上面多个博客中提到的)。还有一个好处:要得到这种同质性,相关人员必须要经常估算。

只不过是关注点上的差异。提升有效产出,而不是做无意义的预测,这才是到达目标的简单方式。

其他更多相关讨论,请查看英文原文

2008 年 8 月 15 日 22:46305
用户头像

发布了 479 篇内容, 共 126.4 次阅读, 收获喜欢 29 次。

关注

评论

发布
暂无评论
发现更多内容

Mac 安装Homebrew慢的问题解决

秦怀杂货店

Mac homebrew

架构师训练营第八周作业

四夕晖

四周 习题与总结

水浴清风

甲方日常 51

句子

工作 随笔杂谈 日常

线程池运用不当的一次线上事故

AI乔治

Java 架构 高并发 线程池

权威报告发布:京东智联云首次参评即跻身机器学习卓越表现者阵营

京东科技开发者

人工智能 云计算 供应链

Java 集合(9)-- Vector超级详细源码解析

秦怀杂货店

Java 源码 集合 ArrayList vector

JDBC【1】-- 初级入门之增删改查

秦怀杂货店

数据库 jbdc crud

JDBC【2】-- 工作原理以及简单封装

秦怀杂货店

Java JDBC 工作原理

Mybatis【2】-- 多个mapper文件以及namespace作用

秦怀杂货店

mybatis Mapper namespace

Mybatis【2.1】-- 从读取流到创建SqlSession发生了什么?

秦怀杂货店

数据库 mybatis SQLSession

你以为只是简单的排序?(二)

书旅

go 数据结构与算法

Java 集合(8)-- ArrayList 源码解析

秦怀杂货店

Java 源码 集合 ArrayList

Java 集合(6.1)-- Collection 和Collections什么关系?

秦怀杂货店

Java collection 集合 Collections

踩了一个java命令行参数顺序的坑

AI乔治

Java 架构 stream

记一次 Java 服务性能优化

AI乔治

Java 架构 性能优化 高性能

transient关键字的作用以及几个疑问的解决

秦怀杂货店

序列化 反序列化 transient

ARTS打卡 第24周

引花眠

微服务 ARTS 打卡计划 springboot

JVM系列-java内存模型(JMM)

诸葛小猿

JMM Java内存模型 共享变量读写

HTTP2服务器推送的第一次尝试

Gopher指北

golang HTTP2.0

大量类加载器创建导致诡异FullGC

AI乔治

Java 架构 JVM GC

常用Git命令速查手册

jiangling500

git

Mybatis【1】-- 第一个Mybatis程序

秦怀杂货店

mybatis 入门 教程

Java反射说得透彻一些

秦怀杂货店

Java 反射 java反射

免费图床+CDN:GitHub+jsDeliver

jiangling500

GitHub CDN 免费图床 jsDeliver

JDBC【3】-- SPI技术以及在数据库连接中的使用

秦怀杂货店

数据库 spi

Scala语法特性(二):控制语句及函数方法

正向成长

Scala函数 Scala控制语句

一次“诡异”的JVM缓存加载问题排查

AI乔治

Java 缓存 架构 JVM

serialVersionUID作用是什么以及如何生成的?

秦怀杂货店

Java 序列化 serialVersionUID 反序列化

你还在使用迭代器删除集合数据,out了,Java 中函数removeIf 不香么

Geek_6f0746

Java JAVA集合 Java迭代器

Java 集合(7)-- List 接口源码解析

秦怀杂货店

Java List 源码 集合 java集合使用

演讲经验交流会|ArchSummit 上海站

演讲经验交流会|ArchSummit 上海站

估算实践是浪费吗?-InfoQ