写点什么

关于“敏捷计划与估计的方法”的讨论

  • 2009-10-15
  • 本文字数:1544 字

    阅读完需:约 5 分钟

在做 Scrum 的迭代计划时,不同的团队有很多不同的做法。在敏捷中国讨论组中,对敏捷计划与估计的方法进行了激烈的讨论( Scrum sprint plan 中规模估算的做法调查关于 story point 的单位)。

克强罗列出有四种敏捷计划估计的方法:

  1. 假设 1 个 usre story point 需 1 个理想人天,Velocity 为理想人天 / 实际人天数
  2. 选择最小工作单元为 1 个 User story point,velocity 为 user story point 数量 / 理想人天数
  3. 选择最小的工作单元为 1 个 User story point,velocity 为 user story point 数量 / 实际人天数
  4. 使用 use case point 作为规模,velocity 为 use case point 数量 / 实际天数

首先讨论的焦点集中于对用于“故事点”的理解上。大家对“‘故事点’是没有单位的”形成共识。Xu Yi 首先指出:

user story 用于评估 user story 的相对大小(bigness),它并无一个可用于度量的单位值。一定程度上可以说 story point 最终会达到具有一定的单位效用。当某产品开发大团队(包括若干 scrum 团队)保持团队稳定,以及开发足够长时间后达到 velocity 稳定时,可以­借由建立一定程度上 story point 向“成本”、“时间”等度量的映射,使其成为“虚单位”。

Daniel Teng 也在博客中分析了在敏捷迭代计划中为什么使用“故事点”,以及为什么“故事点”是没有单位的(巧妙使用“故事点”进行敏捷估计)。使用“故事点”的好处包括:

  1. 使用相对估计
  2. 关注规模
  3. 忽略个人能力的不同
  4. 可以相加。

至于“故事点”的原因在于:

  1. “故事点”是一个相对量
  2. 不同团队的单位“故事点”是不同的,也很难统一。

接下来讨论集中于具体使用“理想人天”和“故事点”做迭代计划的具体方法上。姜志辉的团队的做法是:

我们采用的是 bob 的 dx 迭代 +Joel 的任务分配法。 应该说,原则来自于 bob,方法来自于 joel。

Andy 的做法是:

  1. 记录前面几个 sprint 的实际的可以利用的资源(以人天为单位) 和 实现功能的 IMD(Ideal Man Day),计算 资源利用率:实际完成功能的 IMD / 实际可利用的资源。 源利用率可以取多个 sprint 的平均值,也可取上个 sprint 的单点值。
  2. 即将开始的 Sprint 内可以利用的资源是可以首先计算的,乘以资源利用率 ,得到 本 sprint 的 IMD
  3. 按功能的优先级,本次 Sprint 要达到的目标,选择优先级最高的功能,分解为实现任务,并评估如何实现,不断评审优先级最高的一些功能,直至 Team 不能承诺成为止,也即是所选功能的累积 IMD 达到了 本 sprint 的 IMD。

而 Xu Yi 团队的做法是:

sprint planning 第一部分,团队选择有哪些 user story 是可以做掉的,过去的平均 velocity 只是作为参考而已。 sprint planning 第二部分,团队将选取的 user story 详细分割为 task,以小时为单位进行估计,而且和自己的 capacity 不断地进行对比,当 capacity 耗尽时停止。

接下来话题一转,大家集中到怎样计算每个迭代的速率 (Velocity) 上。Xu Yi 团队的做法很简单直接:

根据过去的 sprint 来统计,平均下来每个 sprint 完成的 story point 就是 velocity。比如前 5 个 sprint 分别完成 9、12、5、16、10,那么 team 的 velocity 就是(9+12+5+16+10)­/5=10.4。

很多人有不同的观点,Vincent Lee 认为:

而我说的算法是“用完成的任务点数除以实际投入的人日数”,假设前 5 个 sprint 分别完成 9、12、5、16、10 个 story point,实际投入的人日数分别为 20、20、25、25、20,(9+12+5+16+10)/(20+20+25+25+20)=0.47,利用这个数值­以及下一个 sprint 的可用资源(比如是 25),就可以算出下一个 sprint 可以完成的工作量:0.47*25=11.75 进一步的,由于可以乐观的认为团队熟练程度在提高,可以调高速度为 0.5,于是预计可以完成 0.5*25=12.5 的工作量。

看来不同团队对敏捷计划与估计的理解不尽相同,做法也各异。您的团队在迭代计划使用哪一种方法呢?

2009-10-15 02:022094

评论

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

Spring Security 实战干货:分布式对象SharedObject

Java spring 分布式

CSS(七)——设置背景颜色和背景图像

程序员的时光

程序员 大前端 七日更 28天写作

悟透前端 | javascript中变量声明var、let、const的区别

devpoint

var const let js变量声明

我国首个自主可控区块链软硬件技术体系发布

CECBC

区块链

加油,成功通过阿里P7Java岗面试,分享一些面试心得

Java架构之路

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

数学,离一个程序员有多近?

小傅哥

程序员 面试

阿里直招怒斩“P7“offer,自曝狂啃六遍的面试笔记

Java架构之路

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

2021年了,还听到有些兄弟在问Kafka香不香?

后台技术汇

28天写作

智能电动车的估值模式及电气架构变迁 (28天写作 Day21/28)

mtfelix

汽车电子 28天写作 智能汽车 汽车电气架构

服务网格的最佳实践

阿里巴巴中间件

《携程技术2020年度合辑》,送给爱学习的你

携程技术中心

Elastic开源协议改了,用户怎么办?

星环科技

七面阿里成功offer,入职就是25k*16薪,还原我的大厂面经

Java 程序员 面试

产业区块链蓬勃发展 联盟链成为落地应用最大杀器

CECBC

区块链

阿里云重磅发布云拨测产品:深度挖掘数据,精准定位 IT 问题

阿里巴巴中间件

北京朝阳法院借力区块链化解物业纠纷

CECBC

法院调解

DevOps到底是什么意思?

xcbeyond

DevOps 方法论 软件测试 28天写作

在游戏运营行业,函数计算如何解决数据采集分析痛点?

阿里巴巴中间件

宙斯运维平台简述,看数十万云服务器如何高效运维?

李忠良

28天写作

技术资讯 | 百度智能云拿下MTCS最高安全评级

百度开发者中心

行业资讯

讲真,一位8 年 Java 经验大牛的面试总结,你照猫画虎还怕收不到offer?

Java架构之路

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

微服务“大门”如何选择?

阿里巴巴中间件

当视频恋爱 App 用上了 Serverless

阿里巴巴中间件

LeetCode题解:200. 岛屿数量,DFS,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

IDEA Malformed argument has embedded quote

会飞的猪

IDEA

“删库跑路”,这背后的数据安全你悟到了吗?

BinTools图尔兹

数据库 大数据 数据安全 数据库管理工具 删库

2021直播电商下半场,“网易严选们”为何成主播良港?

脑极体

编程小技巧之 Linux 文本处理命令(二)

程序员历小冰

Linux 编辑器 sed

DjangoRestFramework框架简介及基本使用

行者AI

RESTful

《我们一起学集合》-ArrayList

蚊子

数据结构 面试 ArrayList JAVA集合

“复制”马斯克(二):“一无所有”的世界首富想要什么?

脑极体

关于“敏捷计划与估计的方法”的讨论_研发效能_滕振宇_InfoQ精选文章