AICon 上海站|90%日程已就绪,解锁Al未来! 了解详情
写点什么

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

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

评论

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

红河哈尼族彝族自治州具有资质等保测评机构在哪里?电话多少?

行云管家

等保

Fluss:面向实时分析设计的下一代流存储

Apache Flink

大数据 flink 实时计算 Fluss 新一代存储方案

MES生产管理系统源码,万界星空科技开源MES

万界星空科技

开源 mes #开源 开源mes mes源码

数据飞轮:闭环体系打造企业数字化转型加速器

字节跳动数据平台

数据飞轮

如何进行知识管理

易成研发中心

知识管理 知识管理系统 知识管理软件

从报表到可视化,基于开源Superset实现数据管理升级的实践

华为云开发者联盟

Kubernetes Apache Superset CCE #开源

在SAP Fiori界面上的ME53N事务

SAP虾客

SAP S/4HANA SAP Fiori ME53N

YashanDB演讲实录|王南:YAC集群,核心平替

YashanDB

数据库 yashandb

YashanDB演讲实录|别彬彬:金融科技对智能化创新系统的机遇与路径

YashanDB

数据库 yashandb

筑牢算力底座,九章云极DataCanvas公司赋能大湾区激活新质生产力

九章云极DataCanvas

这个小游戏SDK突破微信可运行在任何的app

Onegun

小游戏 小游戏引擎 小游戏运营 小游戏平台

Go 并发控制:singleflight 详解

江湖十年

淘宝API对接电商平台:解锁无限商机的钥匙

代码忍者

API 接口 pinduoduo API

AI口语陪练APP的主要功能

北京木奇移动技术有限公司

软件外包公司 AI口语陪练 AI口语练习

中层干部如何管理不合作的员工

易成研发中心

企业管理

又有多位自动驾驶技术“大牛”,进入具身智能机器人赛道

机器人头条

自动驾驶 机器人 大模型 具身智能 人形机器他

成都某自研公司一面

王中阳Go

Go 面试题

高成长、高潜力、高社区影响!镜舟科技入选 2024 中国新锐技术先锋企业

镜舟科技

开源 分析型数据库 StarRocks SegmentFault

从6岁女孩跑完马拉松“违规”事件看软件测试的规范与风险管理

测试人

软件测试

微店商品详情数据接口(micro.item_get)丨微店API实时接口指南

tbapi

微店API接口 微店商品数据接口 微店商品详情接口 微店接口

「阿里巴巴」独投的人形机器人公司,再获“产业派”大佬独投!!

机器人头条

阿里巴巴 投资 大模型 人形机器人 具身智能

数字版权NFT系统的主要功能

北京木奇移动技术有限公司

软件外包公司 体育NFT 数字版权NFT

未来已来:人工智能如何重塑我们的生活与工作

天津汇柏科技有限公司

AI 人工智能

数字孪生系统开发的交互工具

北京木奇移动技术有限公司

软件外包公司 数字孪生开发 webgl开发

得物使用AutoMQ构建海量数据处理的新一代可观测性架构

AutoMQ

kafka 得物技术 客户案例 AutoMQ

使用低代码平台,让复杂的应用开发变得更轻松

JeeLowCode低代码平台

低代码 低代码前端 低代码,

媒体集团建设融媒体中心,特色化实践不断

FinFish

小程序容器 小程序技术 智慧传媒 融媒体中心 媒体转型

为什么企业越大,越难实现数字化

积木链小链

企业管理 数字化 制造业 ERP

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