扫码阅读
手机扫码阅读
聊聊需求的工作量估算
939 2024-01-12
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
查看原文:聊聊需求的工作量估算
文章来源:
敏捷测试转型
扫码关注公众号
敏捷测试转型及需求交付度量摘要
本文主要探讨了如何在敏捷转型中度量需求的交付规模,并强调了用户故事拆解的重要性,以及故事点(或工时)度量的意义和实施策略。
迭代需求拆解
敏捷团队应在迭代计划会议中合理拆解需求,以确保可测试性和高质量的迭代内交付。小颗粒度的用户故事有利于提高测试验收效率。需求过大时,应拆解为可在本迭代内完成的多个用户故事。
需求交付的度量
需求交付平均吞吐率是核心的交付度量指标,与市场满意度直接相关。需要一个统一的方法来度量团队的需求交付大小,这有助于组织改进和管理决策。
需求任务的工作量估算
工作量估算可将一个故事点定义为1个理想人天的研发工作量。故事点的大小与开发估算准确度和交付信心相关,过大的用户故事应拆解为多个可测故事以降低风险。
故事点(或工时)度量的意义
系统化故事点或工时的填写可以提升交付效能的度量准确度,并帮助管理层进行全盘考量。通过对故事点的度量,团队可以改进迭代计划、提高估算技巧,并合理分配资源。
故事点度量实践中的疑问解答
故事点评估尺度不需要跨团队统一;团队可以通过互相观察和学习来提升估算技能。故事点度量不应用于工程师考核,而是用于优化团队的开发节奏和协作。
应对需求紧急插入
团队应拥抱变化但同时有必要进行权衡,根据优先级和团队速率作出决策。产品backlog中的需求优先级排序对于应对紧急插入需求至关重要。
想要了解更多内容?
查看原文:聊聊需求的工作量估算
文章来源:
敏捷测试转型
扫码关注公众号
《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。
81 篇文章
浏览 49.5K
敏捷测试转型的其他文章
聊聊需求评审与验收测试
验收测试是质量左移的利器,也是团队各角色对需求形成共识的“语言”。遗憾的是大多数团队没有好好利用这个武器,仅仅把验收测试当成P0用例,在流程最后才使用
聊聊测试团队在NPS变革中可以做什么
NPS变革对公司转型如此重要,作为用户品质的捍卫者,测试团队也应该义不容辞参与其中,而不是做沉默的被动执行者。本文分享测试团队如何拥抱NPS变革的六大落地措施,提升面向体验交付的测试能力。
聊聊每日站会
每日站会是一线敏捷团队自己的会议,快速同步成员为达成迭代目标所做出的贡献,并对有风险的阻碍采取行动。如果测试人员所在的项目团队没有组织每日站会,一线测试团队也可以自行组织站会,用很少的时间高效沟通,受益良多
聊聊角色扮演探索式测试与肥皂剧模型
本篇介绍以人为本,生动有趣的角色扮演探索式测试和肥皂剧模型。随着对于用户体验问题的挖掘经验越来越丰富,我们就可以沉淀原创的探索式测试方法,并把最容易产生效果的场景,关注点,窍门,固化用例等记录在知识库里共享。
聊聊刻意练习-构建心理表征
社会上经常出现的两类观念,一个是天才和大师有着常人没有的巨大天赋,一个是只要“刻意练习”一万个小时以上就能成为大师,这两种说法都容易误导人。天才并不存在,盲目训练也可能适得其反,但高效且正确的长期训练可以让普通人在任何方面成为大师
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设
白皮书上线