那些在需求评审和迭代计划会议中容易忽视的质量问题Thoughtworks洞见

那些在需求评审和迭代计划会议中容易忽视的质量问题

45分钟 ·
播放数254
·
评论数6

欢迎收听质量三人行第五季。如果你是经常收听质量三人行的朋友,可能会了解我们之前聊过的几乎每一期,都是问题驱动的,我们基于某个软件质量方面的问题,或者测试人员的遭遇,来展开讨论。

第五季,会有一些不同。这一季我们尝试以大规模的虚拟项目作为背景,来探讨在大规模项目中,按照软件的生命周期的顺序,我们QA或者说质量人员,可能会遭遇到的、与软件质量相关的、方方面面的问题。

在本期节目中,我们探讨了那些需求梳理阶段和迭代/冲刺启动会议上有可能被忽视的质量相关问题,以及QA或者质量人员如何更好的介入研发之前的阶段。

本期主播

  • 主持人:刘冉
  • 嘉宾:张凯峰,林冰玉,于晓南

时间轴

  • 02:25 需求梳理过程中遇到的质量相关问题
  • 17:00 需求梳理会开得很重(1-2天),这正常吗?
  • 26:25 迭代计划会议中容易忽视测试任务和软件的可测性等问题

关于质量三人行

质量三人行是一款来自Thoughtworks(思特沃克)的播客节目,我们关注软件行业测试领域的现状和未来,质量和测试人员的职业发展。

你可以在小宇宙喜马拉雅,以及Pocket CastsGoogle PodcastsApple Podcast等泛用型播客客户端,搜索质量三人行,订阅收听到我们的节目。

展开Show Notes
roxiiii
roxiiii
2023.4.18
需求梳理会开得很重(1-2天),这正常吗? 需求梳理会应该是在迭代前的Inception阶段吧?时间长短不应该和迭代的周期去比较吧?2周一个迭代不能说2天的grooming就很长。个人认为不长🤣 请指教🤣
BY林子
:
通常来说,在敏捷团队2周一个迭代的情况下,Backlog Grooming控制在2个小时内算比较健康的,撑死了半天哈,因为,整个团队坐在一起花很长时间讨论需求是件非常可怕、非常低效的事情。 当然,具体情况具体分析,你觉得花两天时间不长,团队都觉得可以,那可能是目前符合你们团队现状的最优方式,这也是可以的。不过,还是要尽量减少团队聚在一起讨论需求的时长,根据团队现状分析可以优化的方式。比如先跟关键角色的代表进行初步讨论,到讨论比较清晰的时候再整个团队参与;或者需求过于复杂,考虑能否拆分更小一些,每块需求不会需要太长时间,一个迭代的grooming也可以不是一次性的活动,持续进行未尝不可;也可能还有架构等因素引起需求讨论时间过长,那就跟技术专家提前讨论清楚,跟第一种方式类似... 任何实践都不能生搬硬套,适合自己的才更有价值,如何保持一直适合自己,那就需要回顾总结,做到持续改进。
张凯峰
:
https://mp.weixin.qq.com/s/cAjJxOltwor8mtCfG3K-4A
5条回复