产品经理内容分享(四):需求的工作量估算以及价值如何度量

本文探讨了在敏捷开发中如何进行用户故事的工作量估算,强调了迭代需求拆解的重要性,以及如何通过故事点度量来提高团队效率和价值交付。文章还涉及如何处理紧急需求插入、价值度量的方法和产品经理的角色,以及团队如何通过复盘和价值指标来驱动改进。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

目录

工作量估算

迭代需求拆解

需求交付的度量

需求任务的工作量估算

故事点(或工时)度量的意义

如何应对需求紧急插入

价值如何度量


工作量估算

度量交付需求的数量和时间相对容易,但度量每个需求的大小则比较难落地,我们需要统一的方法来度量各个团队的需求交付规模,它有利于精细化的组织改进,推动团队以比较舒服的节奏完成承诺,还能稳妥处理紧急需求插入,潜在收益远大于成本。

迭代需求拆解

按照敏捷理论,迭代计划会议要对本迭代的需求进行合理拆解,工作量估算,结合PO决策的需求优先级,确认本迭代要完成的用户故事有哪些。表面看起来,这个迭代计划会议不是测试主导,但是计划制定和测试安排的合理性密切相关。

如果需求或用户故事的颗粒度太大,不利于迭代内的高质量交付,这是最常见的项目风险情形。我经常见到测试人员排期的困境,就是由于需求过大,导致测试设计及场景讨论上就花了太多时间,交付速度很慢。如果一个用户故事的开发周期在2~3人天内,它的测试验收效率是非常高的,可以当天完成测试任务并提交反馈,避免开发等待时间过长。

因此,敏捷特性团队应该对偏大的用户故事进行拆解,以便在本迭代内可以排期完成。

作为测试角色一定要关注这个拆解的“可测试性”,拆解后的用户故事应该可以完整验收,否则违背了敏捷迭代的原则。如图所示,我们应该采用下图中第二行的交付方式,每个迭代完成一个让用户可以使用的“增量”产品。

图:每个迭代都交付可用的产品

需求交付的度量

对于软件交付公司,最核心的交付度量指标,也就是北极星指标,应该是需求交付平均吞吐率(或者需求交付平均周期)。它体现了响应用户需求的速度,自然和市场满意度直接相关。

需求复杂度差异极大,而吞吐率也是看上线需求的数量占比,考虑到敏捷团队会经常改变需求计划,这两个指标很难进一步推进团队提效。

如果管理层想了解“我们每个月交付了多大规模的需求”(或者人均每月交付了多大规模的需求),这对团队的度量就提出了更高的要求。

公司使用的研发管理平台,度量交付需求的数量和时间相对容易(虽然有误差),记录每个需求的大小则比较难落地,我们需要一个统一的共识方法来度量各个团队的需求交付大小。

这篇文章聊聊用户故事的估算和拆解有相关介绍,不同需求的大小可能差异巨大:最小规模的需求就是用户故事;中等规模的需求是特性故事;大型规模的需求是史诗故事。中大规模的需求要能准确评估大小,就要拆解到用户故事的粒度再来评估。

通常,用户故事的大小为3个故事点以下时,开发估算准确度、交付信心和测试效率都会达到一个高水平。反之,故事点大于10的用户故事,交付风险和效率都会迅速恶化,建议尽量拆解为多个可测的用户故事。

需求任务的工作量估算

我们可以把一个故事点的规模锚定为1个“理想人天”的研发工作量,这就可以在系统中把“需求规模”和“评估工时”变成同一件事情。一个需求估算为多少个故事点,就意味着需要技术团队多少“人天”来承担。

注意:交付需求的最小价值尺度是“用户故事”,只有完

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

之乎者也·

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值