写点什么

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

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

评论

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

架构训练营 -- 模块三

LJK

架构训练营

【云堡垒机】市面上部分云堡垒机厂商大汇总

行云管家

云计算 网络安全 堡垒机 IT运维 IT资产

手把手教你使用 Timestream 实现物联网时序数据存储和分析!

亚马逊云科技 (Amazon Web Services)

Data

TDinsight——基于Grafana的TDengine零依赖监控解决方案

TDengine

数据库 tdengine 时序数据库 后端技术

Java中List排序的3种方法!

王磊

Java

南瓜电影CTO早晨6点接到紧急电话,被告知“系统压力大”,看其如何化解危机

大咖说

Serverless 技术 数智化

公安合成作战指挥系统开发,情指勤舆一体化平台建设

电微13828808271

Atlassian 被 Forrester Wave 评选为企业服务管理的领导者!

Atlassian

Atlassian Jira 协作 ITSM Confluence

中科柏诚布局信创产业,护航信创产品安全

联营汇聚

Java 基础之详解 Java IO

编程江湖

JAVA开发

实现更高性能,一起探索Amazon Redshift高级查询加速器

亚马逊云科技 (Amazon Web Services)

Data

盘点 2021 征文大赛|记录你的年度闪光时刻!

InfoQ写作社区官方

盘点2021 热门活动

linux学习全套资料:结构化命令case-for-while

侠盗安全

Linux 运维 运维工程师 云计算架构师

问诊把脉“实景三维业务发展瓶颈在哪里”和“御医良方”

焱融科技

云计算 云原生 GIS 高性能 文件存储

恒源云(GPUSHARE)_云GPU服务器如何使用Spyder?

恒源云

人工智能 #python 算力加速

Linux之nl命令

入门小站

Linux

在线JSON转ClickHouse数据表工具

入门小站

工具

企业如何正确使用CRM系统?

低代码小观

低代码 企业管理 CRM CRM系统 企业管理软件

Linux之nl命令

入门小站

Linux

IP创作

张老蔫

28天写作

给弟弟的信第18封|除了自己,你谁也改变不了

大菠萝

28天写作

CameraX入门笔记

Changing Lin

12月日更

2022年一站式服务器管理软件就用行云管家!

行云管家

云计算 服务器 IT运维 服务器管理

Amazon Aurora 并行查询——加速分析处理的利器

亚马逊云科技 (Amazon Web Services)

Data

Linux一学就会--Shell教程 || Shell的基础用法(详细)

学神来啦

Linux centos 运维 Shell linux云计算

智慧公安重点人员管控系统开发建设方案

a13823115807

智慧公安

微前端技术在游戏平台后台系统的实践

bilibili游戏技术

游戏

质量基础设施一站式服务线上平台助力高质量发展

电微13828808271

智慧警务系统建设方案,公安重点人员动态管控系统开发

电微13828808271

阿联酋区块链大会“DCS 2021 ” 闭幕 Hoo虎符成会展焦点

区块链前沿News

DCS 虎符 Hoo 虎符交易所 DCS 2021

打气球

Tiger

28天写作

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