Grooming Meeting及测试人员所扮演的角色

Grooming Meeting的中文翻译是“梳理会议”,它并不是Scrum框架中标准的会议(标准会议为Planning Meeting, Daily Scrum Meeting, Review Meeting和Retrospective Meeting),而是为了澄清需求从而提高planning meeting的效率而添加的,可以称之为Pre-planning meeting。

目的

  • 添加新的用户故事(也可以来自团队内部)
  • 澄清需求,让团队对用户故事的理解在同一层面上
  • 分解用户故事,并重排相应的优先级
  • 评估用户故事的难易程度(planning poker)
  • 添加Acceptance Criteria
  • 找出用户故事模糊不清的方面,及时澄清确认

时间

  Grooming Meeting举行的时间点一般为当前Sprint结束之前的2~3天,这样可以为会议中遇到的一些不太明朗的需求预留澄清时间。Grooming Meeting的时长一般是2小时(针对两周的Sprint)

参会人员

  Grooming Meeting鼓励所有敏捷团队成员参加,当然如果有客户参加会更好,这样不同角色的人员可以从不同的角度来看待待梳理的用户故事

流程  

  梳理会议是由scrum master主持,PO作为主讲人按照用户故事的优先级进行梳理,梳理的用户故事只要够满足或者稍微超过下个Sprint所能commit的数目就行。

  针对一个story的梳理步骤一般为:

  • 会前

    • 团队成员查看(review)待梳理的用户故事,有一个初步了解
  • 会中  
    • 从用户故事列表中选择最高优先级的待做用户故事
    • PO对用户故事进行讲解
    • 团队成员针对用户故事从不同角度进行提问
    • PO解释,并最终对用户故事的内容达成一致,对于尚不清楚的需求,记录、添加action item并制定相应的所有人,会后进行确认
    • 团队定义acceptance criteria
    • 团队用Planning Poker对用户故事的难易程度进行评估
  • 会后
    • PO和团队成员对会议中尚不清楚的需求进行信息收集和确认  

测试人员

  对于测试人员,需要从以下几个视角来看待待梳理的用户故事:

  • 产品经理视角:用户故事是否合理?是否对客户有价值?是否为核心功能?优先级是否合理?是否可拆分?
  • 用户视角:是否易用?
  • 测试视角:acceptance criteria是否全面、合理?是否有blocking(环境、外部依赖等等)?

总结

通过梳理会议,团队成员对下个Sprint所要做的用户故事都已经有了一个清晰的理解,对计划会议相应的任务创建、评估会有一个很好的把握。

时间: 2024-11-06 06:10:36

Grooming Meeting及测试人员所扮演的角色的相关文章

测试人员在团队中的定位

前言 接触了许多非测试和新入行的测试从业者,听到最多的问题就是:“测试是否被需要?“ 团队职能介绍 <暗黑者1>中有句台词,“专案组有五个职能角色构成,侦探.网警.痕迹侦查专家.法医还有心理学专家”. 软件项目开发也是个分工明确的系统工程,不同的人员扮演了不同的角色,可以分为:项目.产品.开发.测试.美工等等. 项目经理负责分配资源,确定优先级,协调与客户和用户之间的交往. 产品经理负责市场调查并根据产品.市场及用户等的需求,确定产品功能的定义.规划和设计. 开发包括开发经理.前端开发.后端开

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

扎心了!让测试人员心酸的五大谣传

综观现今软件测试的一些轶事,我对某些错误想法的频繁出现感到吃惊.尽管有很多可以罗列,但是我还是想分享测试的五个最常见的谣传(基于我短暂的经验).我发现前三个盛行于一些主流的新闻文章,而后两个则在科技领域的各个方面普遍存在. 谣传1:测试无聊 曾有人说:"测试就像性.如果它不好玩,那就是你做的不对".一件单调且无聊的事,作为测试的一个传闻,频繁见诸于主流媒体文章中,这些文章把测试者比作软件产业的装配线工人.而事实上,测试工作每天都呈现给我们新的令人兴奋的挑战.MichaelBolton(

“测试人员”与“开发人员”的视角差异

测试人员和开发人员的目标是相同的,即向利益相关者提供高质量的产品.但他们的思维方式不同. 正确的说法是,"测试人员和开发人员没有什么不同,但他们遵循不同的途径来实现相同的目标". 开发人员认为:"我怎样才能提出申请呢?" 测试人员认为:"我怎样才能破解这个申请呢?" 测试人员和开发人员的行为就像猫和和老鼠.但最终的结果只有当他们一起工作时才是积极的. 说"如何破坏应用程序"并不意味着测试人员的座右铭是破坏开发人员所做的工作.这

作为一个测试人员,在你提出问题之前请先想想如下问题

之前架构师米洛阐述了测试员报BUG的礼仪,并且引申出一个问题,该如何和程序员交往.其实,程序员群体,甚至推而广之的工程师群体,并没有那么的脾气大,对待测试人员还是挺客气的. 根据架构师米洛多年的开发经验,工程师还是希望通过解决一个接着一个的问题,来提现自己的价值.就像LOL中的推塔一样. 其实很多测试人员并不知道,出现问题之后,找程序员之前,该确定那些个问题,更能让自己的问题得到快速解决. 这里告诉测试员尤其是MM,你提供的信息越是多,越是全,程序员GG越是会觉得问题很容易重现,就会先去解决.当

对于软件开发中开发人员与测试人员关系的理解

在软件开发中都会有开发人员(以下简称开发)和测试人员(以下简称测试),在一些小型公司可能并没有测试,仅仅是开发兼任测试.在这里我仅针对于有专业的测试和专业的开发的项目. 每个公司应该都有考核机制,对于开发和测试的考核实际上很难量化,通常来讲大的方向就是开发所负责模块的bug数,对于测试来讲就是测出来的bug数,但这真的有效吗?这也许对开发有约束力,理论上开发是能够自己控制bug数的,如果从产生的bug数来评判开发的绩效还算有效,这样开发自然就会把代码写得更加认真.但如果根据测试测出来的bug数来

测试人员遇到不断变化的项目需求该如何应对?

需求频繁变更这个产生的主要原因是: 1.前期需求调研工作没有做到位,在需求调研时没有真正深入了解用户需要什么东西?用户做这个东西的目的是什么?为什么要这么做? 2.项目经理对项目掌控力度够,在项目的需求一定情况下,没有采用集中变更或者分阶段变更: 3.客户在最开始时自己也没搞清楚要做出什么样子?随着系统的成型上线,提出一些新想法等导致需求变更. 4.客户就是上帝,所以有些变更是必须的. 测试人员如何面对变更? 1. 协调制定变更规范,比如说每次需求人员都会发出变更邮件,这样可以作为开发人员和测试

接口测试-测试人员必备技能

接口测试,其实并没有那么可怕,但是作为测试人员也是必不可少的技能. 接口分为:内部接口和外部接口. 内部接口:是浏览器与服务器的接口.这个很容易理解,web开发一般分前端和后端,前端开发人员用html/css/javascript等技术.后端开发人员用php/java/python等各种语言.用户输入的数据是输入到前端页面上.怎样把这些数据传递到后台呢?通过http协议的get.post请求来实现前后端的数据传递.这也可以认为是接口测试,这通常称之为内部接口. 外部接口:大部分都是服务端与服务端

转:什么样的测试人员是好的测试人员

1 工作积极主动 工作态度如何,是评价一个测试人员最主要的方面,一个高水平的测试人员(指纯技术能力)如果没有一个好的工作态度,在测试团队中有时候不但不能对测试工作起到推动作用,有时候还起到阻碍作用,而一个愿意工作的测试人员,哪怕他的技术水平不高,人也不聪明,但对自己的工作认真负责,你告诉他的事情,他都可以认真去做,这个测试人员也会对测试工作起到很大的促进作用.这也是为什么很多企业愿意让刚参加工作的人员做测试工作的一个主要原因.另外,测试人员对工作是否主动也会很影响一个测试人员的发展,举一个例子,