扫码阅读
手机扫码阅读
聊聊需求的工作量估算
![](/theme/default/default/images/main/eye-open.png)
敏捷测试转型及需求交付度量摘要
本文主要探讨了如何在敏捷转型中度量需求的交付规模,并强调了用户故事拆解的重要性,以及故事点(或工时)度量的意义和实施策略。
迭代需求拆解
敏捷团队应在迭代计划会议中合理拆解需求,以确保可测试性和高质量的迭代内交付。小颗粒度的用户故事有利于提高测试验收效率。需求过大时,应拆解为可在本迭代内完成的多个用户故事。
需求交付的度量
需求交付平均吞吐率是核心的交付度量指标,与市场满意度直接相关。需要一个统一的方法来度量团队的需求交付大小,这有助于组织改进和管理决策。
需求任务的工作量估算
工作量估算可将一个故事点定义为1个理想人天的研发工作量。故事点的大小与开发估算准确度和交付信心相关,过大的用户故事应拆解为多个可测故事以降低风险。
故事点(或工时)度量的意义
系统化故事点或工时的填写可以提升交付效能的度量准确度,并帮助管理层进行全盘考量。通过对故事点的度量,团队可以改进迭代计划、提高估算技巧,并合理分配资源。
故事点度量实践中的疑问解答
故事点评估尺度不需要跨团队统一;团队可以通过互相观察和学习来提升估算技能。故事点度量不应用于工程师考核,而是用于优化团队的开发节奏和协作。
应对需求紧急插入
团队应拥抱变化但同时有必要进行权衡,根据优先级和团队速率作出决策。产品backlog中的需求优先级排序对于应对紧急插入需求至关重要。
想要了解更多,点击
查看原文
《无测试组织-测试团队的敏捷转型》主题探讨。从打造测试的组织敏捷,到敏捷测试技术的丰富实践,从一线团队的视角来聊聊我们是怎么做的。面向未来,拥抱敏捷原则,走向高效能组织。
81 篇文章
浏览 26.6K
敏捷测试转型的其他文章
聊聊刻意练习-构建心理表征
社会上经常出现的两类观念,一个是天才和大师有着常人没有的巨大天赋,一个是只要“刻意练习”一万个小时以上就能成为大师,这两种说法都容易误导人。天才并不存在,盲目训练也可能适得其反,但高效且正确的长期训练可以让普通人在任何方面成为大师
聊聊竞品体验对比评测(下)
下篇聊聊竞品体验对比测试实战的三个真实案例
聊聊Scrum价值观与测试启发
针对对主流的敏捷实践框架做简单的核心知识回顾,然后展开阐述测试人员应该如何支持敏捷落地,并汲取补齐自己短板的理论,拉通非测试专业人员完成有价值的测试活动。我们先从普及程度最高的敏捷框架- Scrum开始聊起
聊聊CMM/CMMI认证的反敏捷
对于传统软件行业的QA(过程改进)人员,CMM/CMMI知识是基本要求,但是在推行敏捷的组织中,CMM/CMMI并不被接受,甚至和敏捷转型理念背道而驰。这篇短文就聊CMM/CMMI认证的反敏捷之处,QA人员可以对比思考
聊聊定位-如何占领用户心智
业务和产品频繁提及的“占领用户心智”,如何做,令人困惑。我们从营销领域著名的变革作品-《定位》,来理解一下为什么要占领用户心智,以及如何占领。软件产品的定位也是同样道理。
加入社区微信群
与行业大咖零距离交流学习
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
![](https://cdn.easycorp.cn/rongpm/upload/202312/f_39217d624bb2b42ce8f6322ebd7e573a.png)
软件研发质量管理体系建设
白皮书上线