文档章节

敏捷开发中故事点和估算的秘密

Worktile
 Worktile
发布于 08/22 17:15
字数 1986
阅读 2258
收藏 29
高质量的估算能够帮产品负责人优化效率和冲突。因此,精准估算的重要性毋庸置疑。

估算并非易事。对软件开发人员来说,估算堪称是最难的工作之一。估算必须考虑所有能帮助产品负责人做出影响整个团队和业务决策的因素。因此,从开发到高管都为它焦头烂额也不足为奇,但这种做法是错误的。敏捷估算并不是什么性命攸关的大事,就只是估算而已,事实就这么简单。

我们不用要求团队周末加班加点来弥补一项被低估的工作。换句话说,与其事后补救,不如事前看一看有什么方法可以让敏捷估算尽可能变得更精准。

与产品负责人(PO)合作

敏捷开发中,产品负责人 要负责确定backlog的优先级次序——即一个按优先级排好序的工作列表,其中包含关于产品所有所需完成的功能和修复的缺陷的简短描述。产品负责人能够从业务中提取需求,但他们不一定了解具体如何实现。因此,精准的估算能让产品负责人对每个工作项目的工作量有新的了解,这对他们评估每个项目的相对优先级能起到一定作用。

开发团队开始估算后,关于需求和用户故事的问题会经常出现。这是一件好事:这些问题可以帮整个团队更加充分的理解工作。对产品负责人来说尤为特别,将工作项拆解为粒度较小的任务,然后通过估算故事点帮助他们确定所有(和可能隐藏的)工作的优先级。而一旦他们得到开发团队的估算后,可能会再重新排列backlog中的工作项。

敏捷估算是一项团队工作

敏捷估算的关键在于全员(包括开发人员、设计人员、测试人员、部署人员……等等)参与。团队每个成员都能就产品和需要交付的工作贡献一个用户故事。例如,如果产品管理者想要实现支持新浏览器这一看似简单的功能,开发和QA就需要谨慎权衡,因为他们的经验告诉他们这个看似简单的需求背后可能隐藏巨大的困难。

同样的,设计的变更不仅要设计团队的投入,还需要开发和QA人员的参与。缺乏全员参与的估算会降低估算质量,也会导致团队士气低迷,因为关键的贡献者会认为自己被排除在外。所有这些因素都会影响最终交付的软件质量。

因此,不要让你的团队成为封闭估算的受害者。封闭状态下的估算只会加速失败。

故事点和小时数

传统的软件开发团队以时间为单位来估算工作量,例如:天、周、月等等。而敏捷团队大多采用故事点为计量单位。故事点的相对规模(工作量)用斐波那契数列如0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100表示。这听起来似乎有点有违常理,但这种抽象的表述实际上能够促使团队针对工作的难点做出更果断的决策。下面是使用故事点的几点原因:

  • 以日期为单位,无法计量那些无法避免的非项目相关的工作,如需要团队成员参与的电子邮件、会议和访谈等。
  • 日期可会存在一定的感情因素,而相对估算则可以剔除感情因素。
  • 每个团队估算工作的范围略有不同,这意味着团队的速度(以故事点为计量单位)自然也会有所不同。反过来,这样就可以避免出现以速度为争端的团队间的勾心斗角。
  • 一旦团队就每个故事点价值的相对工作量达成一致,团队就可以在无争议的情况下实现点数的快速分配。
  • 故事点能够激励团队成员以工作难度而非耗费的时间为基础来解决问题。这确保团队成员能专注于价值交付,而不是强调花费了多少时间。

故事点和计划扑克

使用故事点进行估算的团队会用计划扑克的形式来统一团队的估算值。团队从backlog中抽取一个工作项,简单地讨论之后,请每个成员在脑海里构思一个估算。然后每个人拿一张卡片,写下自己的估算值,由scrum master收齐卡片后展示每位的估算值。如果估算一致,那么讨论结束,如果存在不同的估算值,就花点时间(无需太久——几分钟即可)了解为什么成员给出了不同的估算。记住,估算讨论应该抓大放小、提纲挈领,如果团队过于纠缠细节,则暂停讨论,提升讨论的水平和高度之后再继续。

精准估算讲究效率,无需浪费时间

任何单个任务都不应花费超过16小时。(如使用故事点,则可以设置20个故事点为上限)。如果单个工作项超过这一工作量,对其进行精准估算会更难。而精准估算对于位于backlog顶部的工作项来说尤为重要。如果单个工作项的估算超过了16小时(或20个故事点)的上限,意味着我们需要将其拆分为更小的工作项并重新进行估算。

对于那些位于backlog下方的工作项,可以只进行粗略估算。因为等到团队真正开始要做该工作项时,需求可能已经发生了变化,相应的应用程序肯定会有所变化。因此,先前的估算可能就会不那么准确。所以不要浪费太多时间去估算那些可能会发生变更的工作项。只需要提供粗略的估算,为产品负责人提供一个可以用来确定产品路线图优先级次序的大概数据即可。

借鉴以往估算的经验

回顾会议是团队从已完成的迭代中总结经验教训的机会,当然也包括估算准确性总结。很多敏捷工具可以跟踪故事点,这让团队可以更轻松地反思和调整估算。例如,我们可以尝试提取过去故事点估算值为8 的5个用户故事,讨论每个工作项的工作量是否大致相同。如果存在差异,讨论其背后的原因。然后将讨论得到的经验用于未来的估算。像敏捷的其他实践那样,估算也是一项熟能生巧的实践。因此团队肯定会越做越好。

翻译/校对:Worktile

文章来源:Worktile敏捷博客

欢迎访问交流更多关于技术及协作的问题。

文章转载请注明出处。

© 著作权归作者所有

Worktile
粉丝 31
博文 55
码字总数 136153
作品 1
朝阳
私信 提问
我们应该停止使用故事点和速率吗?

敏捷社区的专家正在热议如何使用故事点和速率(Velocity),不少人对使用它们估算和度量总体进度产生了怀疑,打上了问号。大家普遍认为,产生问题的根本原因就是这些度量项往往不是挂羊头卖狗...

oschina
2012/12/20
3K
12
PMI-ACP 敏捷项目管理9——识别干系人

一、识别干系人 识别干系人并分析和记录他们的相关信息,可以帮助敏捷项目经理建立对各个干系人或者干系人群体的适度关注。在项目或者阶段的早期,识别干系人,并分析他们的利益层次、个人期...

隔壁老李头
2017/11/26
0
0
敏捷团队的度量-承诺达成率与迭代速度

敏捷团队运行很长的时间了,也积累了很多数据,如何从敏捷数据里面得出一些指标来指导我们团队的改进,是敏捷团队面临的重要话题。 理论基础 度量是理念、设计、应用三位一体的过程。 度量是...

通爸
2018/01/19
0
0
PMI-ACP 敏捷项目管理——模拟试题1

1、团队重视培训新人的个人技能,以扩展其跨职能的能力。这样做的主要目的是什么? A 它能减少瓶颈风险 B 它能增加跨职能团队的沟通频率 C 它能促使干系人接受风险 D 它能利用新的工具来跟踪...

隔壁老李头
2017/12/03
0
0
PMI-ACP 敏捷项目管理——模拟试题2

1、在项目的Sprint回顾会后,团队成员指出那是抱怨会,不是非常有效。Scrum主管应该怎么做? A 建议团队尊重敏捷宣言原则,解释其属于回顾会的组成部分 B 建议团队成员将他们的观察列入产品待...

隔壁老李头
2017/12/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

小知识:讲述Linux命令别名与资源文件的区别

别名 别名是命令的快捷方式。为那些需要经常执行,但需要很长时间输入的长命令创建快捷方式很有用。语法是: alias ppp='ping www.baidu.com' 它们并不总是用来缩短长命令。重要的是,你将它...

老孟的Linux私房菜
36分钟前
2
0
《JAVA核心知识》学习笔记(6. Spring 原理)-5

它是一个全面的、企业应用开发一站式的解决方案,贯穿表现层、业务层、持久层。但是 Spring 仍然可以和其他的框架无缝整合。 6.1.1. Spring 特点 6.1.1.1. 轻量级 6.1.1.2. 控制反转 6.1.1....

Shingfi
37分钟前
4
0
Excel导入数据库数据+Excel导入网页数据【实时追踪】

1.Excel导入数据库数据:数据选项卡------>导入数据 2.Excel导入网页数据【实时追踪】:

东方墨天
46分钟前
4
1
正则表达式如何匹配一个单词存在一次或零次并且不占捕获组位置

正则表达式如何匹配一个单词存在一次或零次并且不占捕获组位置 今天要用正则表达式实现匹配一个词出现一次或者不出现的情况,但是又不仅仅是这么简单的需求。先详细说下我这种情况吧,也许有...

Airship
52分钟前
6
0
第八讲:asp.net C# web 读取文件

本讲主要讲解如何在asp.net页面上传文件。 首先,前台页面: 其次,后台页面: 结果: 1、前台效果: 2、后台结果:

刘日辉
今天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部