写点什么

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

  • 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:022458

评论

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

我是一名数学专业的应届博士,我该如何选择offer?

IC男奋斗史

职业规划

iOS防截屏|担心App内容被截屏泄露吗?这个开源库就是你要的

LabLawliet

ios

Hoo虎符研究院|2022年三月值得关注的赛道

区块链前沿News

Web NFT 元宇宙 虎符交易所

这是我们的黄金时代

IC男奋斗史

职业规划 芯片行业思考 芯片技术

裸奔?哒咩!

IC男奋斗史

芯片技术

为什么需要线程池?什么是池化技术?

CRMEB

Kafka中指定副本为Leader的三种实现方式

石臻臻的杂货铺

kafka 运维

看到字节跳动28岁员工猝死,我都想润了......

IC男奋斗史

职业规划 芯片行业思考

凤姐如何变冰冰?

IC男奋斗史

芯片技术

检测图片中是否有二维码

逆锋起笔

android 二维码 Android端 3月月更

数仓中长跳转问题复现及解决方案

华为云开发者联盟

寄存器 GaussDB(DWS) 长跳转 编译器O2

我的奋斗:我在外企那些年(一)

IC男奋斗史

职业规划 芯片行业思考

芯片工程师太贵?贵你妹啊

IC男奋斗史

芯片行业思考

我的奋斗:我在外企那些年(二)

IC男奋斗史

职业规划 芯片行业思考

第三次“世界大战”——芯片保卫战,无烟的战场

IC男奋斗史

芯片行业思考

微博评论架构设计

刘洋

#架构实战营 「架构实战营」

芯荒荒,汽车芯片路在何方

IC男奋斗史

芯片行业思考 芯片技术

PostmangRPC功能使用介绍

蜜糖的代码注释

gRPC 调试 Postman 3月月更

Redis现网那些坑:用个缓存,还要为磁盘故障买单?

华为云开发者联盟

redis 缓存 SSD 磁盘故障 缓存Redis

IOS技术分享| anyLive 开源项目

anyRTC开发者

ios 音视频 移动开发 视频直播 开源demo

VuePress 博客优化之中文锚点跳转问题

冴羽

typescript Vue 博客 vuepress 博客搭建

博文推荐|使用 Apache Pulsar 构建边缘应用程序

Apache Pulsar

开源 架构 分布式 云原生 Apache Pulsar

Ember 速度最快、性能最高的渲染技术框架之一

devpoint

前端框架 ember.js

聊聊redo log是什么

程序猿阿星

Redo Log MySQL InnoDB

为什么需要线程池?什么是池化技术?

王磊

面试

通过简书网学习 ActionChains,selenium webdriver 学习第3篇

梦想橡皮擦

Python 3月月更

李凌:6 年,我如何从开源小白成为 Apache 顶级项目 PMC

腾源会

开源 腾源会

润还是不润?这是个问题

IC男奋斗史

职业规划 芯片行业思考

云原生多云应用利器 -- Karmada 调度器

Daocloud 道客

Kubernetes 云原生 开源软件 Karmada

云原生网络利器--Cilium 总览

Daocloud 道客

ebpf cilium 云原生网络 容器网络方案

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