聊聊用户故事的估算和拆解
这是鼎叔的第六十七篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。
对于Scrum和用户故事实践的最大难点,我相信是如何估算用户故事的大小,如何拆解它?过大的用户故事会带来一系列的沟通复杂度和潜在质量风险,最好的用户故事是不超过2-3开发人日就能够完成的。本文重温行业经典的估算和拆解方法,并从测试人员的角度思考它。
相关文章请看:聊聊用户故事和测试启发。
故事的大小
用户故事从大到小,可以分类为Epic(史诗故事,需求梳理阶段时的宏大目标),Feature(特性故事,迭代规划的重点目标),User Story(用户故事,迭代中要完成的具体价值点)。注意,也有些敏捷书籍把Epic的规模放在Feature之下,鼎叔采用的是大规模敏捷框架的定义,认为Epic规模更大。
常见的拆分模式
当用户故事太大,无法放入一个迭代中,我们可以用各种手段进行拆分,确保拆分的每个用户故事都有其价值,并可以独立地端到端验收。
以渐进的方式逐步拆分故事,更小粒度的故事有利于团队更准确地对工作量进行估算,更早交付解决方案中价值最高的那部分。
常见的9种用户故事拆分方法,如下。
-
按工作流步骤拆分。哪怕只是一部分工作流,对用户也是有体验感知的,可以及时提供反馈。如网上预定机票这个故事,可以拆分为:查找预定航班,生成订单,获取出票结果信息,系统发送订票成功短信等。
-
按业务规则变化拆分。如积分兑换这个故事,可以1 按积分兑换,2 按部分积分+现金兑换。
-
按主要/次要工作拆分。比如支持信用卡支付机票费用这个故事,可以先支持微信支付,再支持其他主要支付方式。
-
按业务简单和复杂划分。比如商品搜索功能,可以1 按商品名称搜索,2 按其他商品属性的高级搜索。
-
按照处理数据变化来划分。比如网站的内容管理功能,可以 1 支持中文,2支持英文,3 支持其他语言。
-
按照界面变化来划分。比如先输出最简单的UI界面,再输出精美配色的UI界面。
-
按照性能规格来划分。先从慢速中把用户价值做出来,再进行性能优化改进。如1 完成XX功能显示, 2 在10秒内完成XX功能显示。
-
按照操作边界来划分。例如数据的增删改查,1 完成数据的查询,2 完成数据的增加和删除,3 完成数据的修改。
-
拆出一个探针故事。对于我们知之甚少的比较大的故事,我们先在一段时间内做一个探针实验,得到初步的调查结论。
估算用户故事的方法
估算用户故事的大小是团队协作的难点,基本的出发点是越小的故事,估算误差越小,越大的故事,估算精度越低。就好像评估星球的体积大小。这就是我们经常利用斐波拉契数列来收敛估算结果的原因,如下图,以最小星球体积为1,其他星球的大小只能在这个序列中挑选估值:1,2,3,5,8,13,21,34... ...
用户故事的大小估算方法,通常是集体评估的方式,只做相对大小的评估,可利用斐波拉契扑克牌和T恤尺寸等方法进行估算。
开始估算故事之前,需要PO给大家阅读或讲解这个故事的目的,验收标准,如果有交互原型等信息更佳。成员可以针对这个故事进行提问,PO和技术leader可以解答。
成员集体估算是背靠背的,即同时摊开手中的牌,看大小是否一致。先找一个最简单的开发需求来做估算,看看能否对齐成员间的基准,对齐后再估算更大的故事。
发生估算分歧时,会让双方解释原因,重新估算或投票,最多只能估算三轮。
集体估算不是集体承诺,估算无需精确度量,目标是求稳,长期估算结果趋同即可,眼前有一些分歧很正常。整个过程,便于大家对于需求背后的价值和复杂度形成共识,互相学习。
我们可以默认一个故事点就是一个工程师人天可以完成的研发工作(包括设计,编码,测试修复,研讨等),它并不是按沉浸式满负荷工作时长(理想人日)来估计的,有一定的buffer(折扣,通常是10%或20%),考虑到人员有临时请假,团队外会议和杂事打扰的事项。但是这个折扣如果过高就需要集体改进了。
其他团队的做法是,故事点数考虑所有测试工作,人数也包含了专职测试人员。
这两类做法我认为都是正确的。
项目经理需要关注迭代中的工作燃尽图表,分析是什么原因导致计划中的测试任务完成过程不太符合预期,比如,测试任务为什么迟迟没有开始,前期测试进程为什么被阻塞,测试工作量估算明显和实际不符合,等等,这个分析过程对于未来的测试速率估算准确性,对于提高人员效率,将大有裨益。迭代燃尽图如下所示,理想情况下,它是一个下降的曲线,随着剩余工作的完成,烧尽至零。
迭代中想变更交付需求怎么办?
敏捷研发欢迎变化,当一个更紧急的需求插入本迭代时,先估算插入需求的故事点,再从迭代相对低优先级故事中,拿出同样大小的故事集合即可。这种应对方式比传统研发管控方法更灵活,更简单,更准确。
业务方代表担心功能遗漏带来的风险,要求把各种功能都加上。 客户缺乏安全感,通过加需求作为谈判技巧。 业务方/客户图省事,或者公司由麻烦的预算制度,所以一次性尽可能把需求都提上。
《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。