扫码阅读
手机扫码阅读

聊聊需求的工作量估算

82 2024-01-12

这是鼎叔的第八十七篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。


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


迭代需求拆解

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

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

因此,敏捷特性团队应该对偏大的用户故事进行拆解,以便在本迭代内可以排期完成。相关方法可以参考聊聊用户故事的估算和拆解

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

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

需求交付的度量

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

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

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

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

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

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

需求任务的工作量估算

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

注意:交付需求的最小价值尺度是“用户故事”,只有完整实现了用户故事才算交付了完整的价值。但一个用户故事的具体研发工作可以拆分为多个“任务”,其中包括测试任务,完成任务并不代表价值被交付了。因此,有些团队把拆解后的任务定义为“子需求”,这是错误的。

在测试工作量的预估上,我们认为“任务”是最小的工作量估算层次。建议测试任务的划分也不要太粗,单个任务的完成时间不超过一人天,这样有利于团队找到测试效率可以提升的地方,同理,不同测试人员的任务也建议分开估算。

测试任务的独占周期太长,也会影响迭代需求的完成目标,我们有必要具体看看测试范围和优先级,找到合理覆盖策略,保障核心功能用例的验收。

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

针对一个组织的每个交付需求,都在系统上填写故事点或工时,有利于精细化的组织改进。它可以大幅提升度量团队交付效能的准确度,有利于管理层全盘视角,潜在长期收益远大于成本。 比如:

一,迭代计划的需求总规模(点数),是否大于技术总理想人天(工程师人数*迭代工作日)?

比如一个有十个技术人员的Scrum团队,在一个双周迭代能交付的需求规模应该只有100故事点(人天)。

如果排期的需求规模偏大,很可能导致交付目标难以达成,或者交付质量低于预期。因此需要对计划完成的需求进行缩减。

二,度量“计划故事点(工时)”和“实际完成故事点(工时)”的偏差。可以用于迭代复盘,Scrum团队总结如何提高估算技巧,或找到拖慢研发速度的罪魁祸首。

三,如果产品/需求本身有优先级的标签,整个组织就可以度量多少人力投放到了公司战略项目,多少人力投放到了非核心项目上。

有些同学提出几个疑问,我们来回答下。

一,每个Scrum团队的故事大小/工作量预估方法都不同,是否要拉通对齐么?

答案是:不需要!故事点/工时是用来校准Scrum团队的计划执行准确率的,每个团队的成员级别、技能和经验不同,天然会有不同的效率(研发速率)。对于敏捷研发组织来说,重要的是交付可预测,节奏稳定。强行要求不同团队有一样的产出,容易产生灾难性的后果。

因此,我们需要花费几个迭代的时间,让每个Scrum团队内部进行集体估算和集体讨论的实验。初期不太准是正常的,后面的团队估算实践会越来越准确和快速,以比较舒服的节奏完成承诺。

二,既然故事点评估尺度不需要跨团队拉通,那研发团队怎么互相学习呢?

答案也简单,派代表围观其他团队如何集体进行需求大小评估的,识别各种风险对于工作进度的影响。

当开发估算有分歧时,会分享各自的原因,暴露自己不知道的风险,让团队能互相学习。测试等角色也从中受益。为工时估算付出一点成本,会带来极大收益,同时让后期工作计划更靠谱,团队也能更自信。

通过跨团队的故事点实践对比,故事点交付代码规模小、质量相对低的团队,可以像指标高的团队学习,但还是要保持自身的稳定节奏和交付满意度。

估算开发工作人日,可以用一个理想人日完成的工作打一个折扣,比如20%,用于应对迭代工作以外的干扰、学习、会议、交流放松等。如果实践下来发现这个折扣偏高,说明团队应该进行治理,降低非迭代的干扰。

三,有同学会提出自己的担心,故事点度量会用于工程师的考核么?

当然不会,每个团队的人员成熟度和经验不同,业务难度不同,都会形成一个适合自己的开发吞吐节奏,有利于产能最大化和自主改进。

之所以要团队集体估算,也是要减少对个人故事的追踪。

如果把故事点和个人绩效挂钩,会导致个人在评估时降低要求(提高估计值),同时阻碍团队内的互助合作。

四,很多开发工作和需求故事不是强相关,但是scrum团队还是必须完成,比如线上故障,大促,技术债等。怎么办?

把技术故事明确拆解出来,并估算故事点。和产品一起确认哪些技术故事能排入高优先级,能在当前迭代内完成。或者分配指定比例的工作量预留给日常开发运营工作。

五,有些团队没有用户故事拆解的实践,会阻碍故事点的度量实践么?

不会,没有进行用户故事拆解,开发也可以凭团队经验估算工作量大小。

但是用户故事估算实践是行业推荐的主流敏捷方法,有利于团队成员互相学习和提升,估算效果也更稳定。

六,技术团队目前都很支持产品经理的各种需求,如果按照故事点度量,会不会导致支持力度下降,协作意愿下降?

敏捷和精益理论都鼓励跨岗位合作,one team-群策群力。但是这些一定要建立在健康节奏之上才能持续高效,即:团队迭代速率(完成故事点)是一定的,WTP(在制品)最大数量是一定的。

限制故事总大小才能让团队聚焦交付价值的最大化,养成复盘需求的习惯。

当团队为尽可能多的需求实现而精疲力尽时,我们需要扪心自问,真的在交付高价值产品么?

七,业务方要求发布日期不能变,需求工作倒排怎么办?产品经理对接的业务方不止一个,业务方要求都要上线怎么办?

发布日倒排不是问题,从倒排日计算多少个迭代,根据团队速率计算总故事点,看看哪些需求能排入发布计划即可。

产品经理是需求优先级的第一责任人。业务方如果在产研团队外,需求不一定都能满足,这可能导致很多冗余需求。关键是产品经理和业务方能否深入沟通最本质最紧急的需求是什么,能否拉近业务方和研发的距离。比如把业务方卷入研发迭代规划会议,确认需求优先级,甚至参与需求验收。

产品的用户群体到底是谁,业务方是排序第几的用户群体?

产品经理有两种需求排期方式:一,先满足最重要用户群体的重要紧急需求,还有故事点空间再满足次重要群体的。二,给每个用户群体分配固定比例的故事点(即分配泳道大小)。

如何应对需求紧急插入

实际迭代排期中,经常出现产品负责人把新的需求紧急插入本迭代的场景,这会让开发和测试人员很不满。针对紧急插入需求,我们应该如何正确看待?

从敏捷价值观而言,我们拥抱变化。没有必要强制需求排期计划不能变更,哪怕是在本迭代这么短的时间内。但是我们有必要集体确认:新排入的需求优先级如何?它和本迭代中计划完成的其他需求对比起来,优先级是高还是低?如果它优先级比本迭代某个需求高,在迭代剩余工作量能完成的情况下,可以替换这个目前在做的需求。

简而言之,针对紧急需求插入,不能只做加法,而是有加有减。根据优先级拥抱变化,根据团队速率大小替换一定大小的排期需求。因此,我们也要检查产品backlog中的需求优先级,是不是有严格的唯一排序?这个很重要,有进就会有出。

存在一种可能性,有的产品需求,永远都无法排期开发上线,因为它的优先级PK永远不过后面的新需求。这也符合敏捷设计的原则,即适时设计。当前重要的产品想法,可能到了后期便不再重要了。

原文链接: http://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247484471&idx=1&sn=63e8e6053ccbbdf11880c27d4ab3f7d4&chksm=c24fb155f5383843f22fa5dcee48daae0782b94a030919996a8d5e9aa2a45fef288f41b761b5#rd

《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。

81 篇文章
浏览 4634
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线