产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

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

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

评论

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

ChatGPT加持,需求分析再无难题

测试人

人工智能 软件测试 ChatGPT

阿里云首个 AI 员工入职,围观开发工程师使用反馈

阿里云云效

阿里云 Serverless 云原生 通义灵码

有手就会?记一次绕过防重放的漏洞挖掘

权说安全

漏洞挖掘

Bookends for Mac(文献书籍管理工具)v15.0.1注册激活版

iMac小白

2024 年 3 月 Web3 游戏报告:市场趋势与投资动态

Footprint Analytics

gamefi\

开源语言大模型

百度开发者中心

人工智能 机器学习 大模型

阿里云ACK One GitOps:轻松实现多团队多集群应用交付

阿里巴巴云原生

阿里云 云原生 容器服务

2024 AutoMQ 布道师计划启动!

AutoMQ

大数据 云原生 布道师 AutoMQ

避雷指南:11个常见 Kubernetes 误区详解

SEAL安全

Kubernetes 容器 云原生

SQLPro Studio for Mac(可视化数据库管理工具)v2024.21激活版

iMac小白

Premiere Pro 2024 for Mac(PR 2024视频编辑软件)v24.3.0中文激活版

iMac小白

Rectangle Pro for Mac(光标快速移动和管理窗口的工具)v3.0.22激活版

iMac小白

详解从ERP传到MES系统的数据

万界星空科技

系统集成 ERP 生产管理系统 mes

硬件标准化之道:Linux社区与硬件厂商的协同创新

GousterCloud

硬件 Linux Kenel 设备

《射雕》热度不减!英特尔锐炫A750亮眼帧率展现高性价比优势!

E科讯

Acrobat Pro DC 2024 for mac (领先的PDF编辑转换器)中文激活版

iMac小白

LLama2大模型指令微调实操:解锁AI生成文本的新境界

百度开发者中心

人工智能 机器学习 大模型 llama2

ChatGPT加持,需求分析再无难题

测吧(北京)科技有限公司

测试

你的代码是干的还是湿的?

敏捷开发

项目管理 敏捷开发 代码 代码人生 bug管理

Magic Disk Cleaner for Mac(磁盘垃圾清理工具)v2.7.3激活版

iMac小白

Yoink for mac(临时文件拖放暂存工具)v3.6.90激活版

iMac小白

Media Encoder 2024 for Mac(ME2024)v24.3激活版

iMac小白

Ghost Buster Pro for mac(苹果电脑内存清理专家)v3.2.1激活版

iMac小白

Kafka痛点专题:AutoMQ 如何实现分区持续重平衡?

AutoMQ

云计算 大数据 kafka AutoMQ

不惜血本、重金打造的数据平台为何效果平平?

feng

数据平台 企业数据化运营

AI智能尺码引导未来决策 推动品牌业绩飙升

第七在线

阿里云首个 AI 员工入职,围观开发工程师使用反馈

阿里巴巴云原生

阿里云 AI 云原生 通义灵码

怎么用OpenAI Sora?最全分析-新手小白必看

蓉蓉

openai ChatGPT sora

Live Wallpaper & Themes 4K Pro for Mac(超高清4K动态壁纸)v19.9中文激活版

iMac小白

捷途山海T2预售开启,安全动力更卓越,仅需18.49万元起

Geek_2d6073

2024的财富契机,Meta Earth或在模块化赛道一展宏图

威廉META

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