写点什么

是时候停止用户故事估算了吗?

2011 年 10 月 12 日

大多数新的敏捷团队在从基于小时数估算过渡到基于故事点的相对估算,但我们真的需要估算吗?

Michael Dubakov 提示以下你需要停止使用用户故事估算的原因:

  1. 你不要在估算上浪费时间
  2. 你不需要对更高的管理者解释为什么需要这么久
  3. 你不用给出难以达到的承诺
  4. 你不用给开发团队额外的压力
  5. 你可以专注于真正重要的事情

Stephan Schwab, 担心时间估算可能会导致团队分裂并且会成为团队解决问题的障碍:

想象一下一个组织期望通过团队给出 backlog 的完全估算来决定项目成本的情形,乍一看,这种做法似乎是一个好主意,将要做该工作的人会提供估算,而且由此基于他们所说的可以了解真正的工作成本。

但项目的真正成本就真的就这样可以了解吗?当一组聪明人开始解决问题的时候会有什么发现呢?对于一个 6 个月的项目,针对一些小的故事卡片,在几周内数位分析师能够分析问题并给出好的解决方案似乎不大可能,他们或许在几周内能够创造超过 500 个故事卡片,但我认为这都是基于最初的假设,如果问题能够在几个星期内被解决,那就不需要整个团队付出超过 6 个月的工作了。

所以对我来说,这似乎更像是预测未来,创建一个计划并按计划来管理。

一个团队被要求提供充分估算并且足够详细的 backlog 会导致拘泥于规定的行为,并阻碍技术团队成员从分析师、用户体验师和 Product Owner 得到信息做出解决方案,最后,如果由此产生的“解决方案”的质量低于预期应该是毫无疑问的,因为团队被阻碍做出优秀的工作。

质量也会成为这所谓虚假的可预见性的代价,尽管一些利益相关者期望高质量产品,但同样来自于他们的要求很可能会导致这种情况发生。

比“计算”的成本更重要的是构建有价值的东西。那些可以使用并且最终使利益相关者想扩展或有新的想法的时候还想要找同样的人来完成的东西。

Mike Cottmeyer 则坚持估算也有好处:

因为我们不喜欢经理和我们不喜欢死亡行军 ,我们就断定创造软件是一个不可预知的过程中,估算是不好的,所以我们绝不能进行估算。有没有可能我们并不是真地遇到估算的问题呢?是否有可能,这是一个管理不善的问题呢?

我看不出有任何理由停止估算。事实上,除非你的商业模式支持完全的自然成果,否则你的某些目标和商业成果的机会是和一些事先定义好的交付物捆绑在一起的,这些机会意味着你已经向客户卖出了东西现在你必须实现这一承诺。

我们可以整天辩论这种商业模式,但如果这是现实,你是需要估算的。

估算得有范围和可能性。你需要管理好假设条件并降低风险。我们必须能够衡量我们的估算有多大的误差,这样我们就可以开始提前预测误差。

我们忽视了数据告诉我们的信息,我们忽略了团队相对于估算的实际绩效。我们有很大的交付竞争压力;有要在下月末之前增加额外的功能,这样我们就可以提高销售的巨大压力;有交付那些我们销售团队为赢得大生意而承诺的功能的巨大压力。在如此大的压力之下,使得我们都脱离了现实。

真正的问题是,我们过于频繁地吹嘘组织的交付能力。真正的问题在于“你必须不惜一切代价,提供”的文化不尊重团队做出经过测试可工作软件的实际能力。

面对不合理的期望、死板的项目进度和承诺时,在不愿意向交付低头的压力下,错误的估算会成为问题,管理不善也成为一个问题。

Bob Marshall: 对同一篇文档做如下评论

此外,我经常不得不问:“为什么要做估算?”。除非到了人们对需求的估算彻底心领神会,否则谁又能有任何把握说估算是有价值的呢?

许多人认为看板已经废弃了估算, Karl Scotland 澄清了这种情况 :

看板团队不只是因为做起来很难才避开估算。有些团队选择不做估算,因为他们可以得到同样的效果而付出低于估算所需的成本。老笑话对此仍然适用(“医生,我这样做会很痛”,“那就不要做了”)。如果估算有害那就找到其他方法鼓励整个团队的互动和合作,了解过去的能力和预测未来的能力。另一方面,如果估算无害,或成本不太高的话,那么它可能在你所处环境中是应该做的正确的事情。

当我们在计划的时候,我们应该把工作分解为可理解的部分,而不是调整工作本身。

Jeff Anderson 给出了另一种在看板中使用估算的情况:

随着团队的发展,接受的工作通常会归类到更好理解的工作类型,这些类型很少变化。比如 A 团队的工作可能通常基于 Java 的增强功能、紧急的缺陷和固定格式的报告。

估算最重要的部分是把工作分解成小块的。一旦你做到了这点,唯一关注小范围差异的理由就是想要引起讨论。

虽然看起来估算成果的价值可能会有疑问,似乎估算的真正好处是整个团队一直对于这一点产生各种交流。您对于此有哪些经验呢?

查看英文原文: Is it Time to Stop Estimating User Stories?

2011 年 10 月 12 日 07:012175
用户头像

发布了 42 篇内容, 共 14.0 次阅读, 收获喜欢 0 次。

关注

评论

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

必须收藏:20个开发技巧教你开发高性能计算代码

华为云开发者社区

性能 并发

数字货币永续合约平台搭建方案,一键跟单系统开发

WX13823153201

MySQL-技术专题-联合索引最左前缀匹配原则

李浩宇/Alex

架构师训练营第五周学习总结

邓昀垚

极客大学架构师训练营

发挥区块链技术优势 确保食品安全

CECBC区块链专委会

区块链技术 信任机制

PLSQL 过程语言-结构化查询语言

Flychen

APP 莫名崩溃,开始以为是 Header 中 name 大小写的锅,最后发现原来是容器的错!

程序员小航

Java bug Header携带签名 工作笔记 问题排查

架构师第一期作业(第5周)

Cheer

作业

MySQL-技术专题-聚集索引和慢查询

李浩宇/Alex

在算力“沃土”上,种植互联网下一个奇迹十年

脑极体

10个自动化测试框架,测试工程师用起来

华为云开发者社区

软件 测试 质量

目标2025:通信产业在能源变局中拥抱智能未来

脑极体

sync-player:使用websocket实现异地同步播放视频

GoEasy消息推送

websocket 数据同步 实时通信

蘑菇街大牛熬夜整理的Spring MVC知识点总结(思维导图+源码笔记),免费分享文档资料

Java架构之路

Java 程序员 架构 面试 编程语言

最新版MySQL在MacOS上的安装与使用

王磊

MySQL

java安全编码指南之:ThreadPool的使用

程序那些事

java安全编码 java编码指南 java安全编码指南 java代码规范

速度(Velocity)不背这个锅

BY林子

敏捷开发 估算与计划

(转)程序员的写作课

Leo

学习 前端进阶训练营 技术博客

法定数字货币对银行存在潜在冲击,可能是第六版的人民币

CECBC区块链专委会

数字货币 金融

云原生在京东丨基于 Tekton 打造下一代云原生 CI 平台

京东智联云开发者

ci 云原生 Tekton

深度详解企业CRM系统,体验软件快速开发平台

Marilyn

敏捷开发 快速开发 CRM

忘记MySQL密码怎么办?一招教你搞定!

王磊

MySQL

老公熬夜都要看的:从基础到进阶的Java面试题,助你2021年金三银四拿下大厂offer。

996小迁

Java 编程 架构 面试 计算机

详解GaussDB(DWS) explain分布式执行计划

华为云开发者社区

数据库 计划 数据

用Python加载数据的5种不同方式

计算机与AI

Python 数据处理

从资金荒、恒大事件看区块链技术在供应链金融上的应用价值

CECBC区块链专委会

区块链 供应链物流

spring-boot-route(二十)Spring Task实现简单定时任务

Java旅途

Java Spring Boot Spring Task

iOS底层原理之—dyld与objc的关联

iOSer

ios开发 iOS Developer dyld objc

十八、深入Python函数

刘润森

Python

go-zero 如何应对海量定时/延迟任务?

Kevin Wan

golang 定时任务 时间轮 microservice 延迟任务

金九银十期间成功斩获58万架构师Offer!六面字节跳动面经和面试题分享

Java架构追梦

Java 学习 架构 面试 JVM

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

是时候停止用户故事估算了吗?-InfoQ