建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块

Tony老师不...

发帖: 4粉丝: 1

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2020-2-27 10:34:19 345 5
直达本楼层的链接
楼主
显示全部楼层
【讨论帖】用户故事的澄清难道不应该在计划会议上做吗?

讨论主题

有些团队在采用Scrum实践敏捷开发的时候,会选择在计划会议上做即将开始的Sprint的用户故事澄清。也有些人提出了反对的声音,故事的澄清应该在在“梳理会”上,可是Scrum指南中却并没有指出有“梳理会”。


说出你的想法

针对用户故事的澄清大家认为应该什么时候进行呢?请谈谈你的想法。

比如,如果是在梳理会上进行澄清的好处是什么,都需要谁来参加?何时进行?时间盒又是多少等。

格式不限,参考如下:


好处

在估算和开始工作之前,让人们有更多时间消化新的用户故事。

有更多时间优化设计。

...


参与人:

PO、 SM,再顺带几个核心人员就够了吧。


什么时间开、开多久:

下个Sprint开始前的2、3、4、5……天都行吧,反正 别一开始本迭代就讨论下个迭代的事就行。至于多长时间,我觉怎么也得1个小时吧。


其他

...


欢迎大家积极讨论



Scrum

举报
分享

分享文章到朋友圈

分享文章到微博

kaverjody

发帖: 10粉丝: 4

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2020-2-27 11:05:30
直达本楼层的链接
沙发
显示全部楼层

用户故事其实是个持续的过程,并不限定于梳理会或计划会,而是应该持续地进行的。


从计划会的定义上来讲,名字就可以看出来,计划会当然主要是为了计划啊,用八二原则来说,80%的情况下应该需求都是确定的、咱们只需要做个计划出来就好了呀,或者说应该80%的需求都是明确的、只有20%左右的需求需要在会上再探讨确认一下。简单地去说计划会上应不应该澄清需求,是有些偏激了,好像只有应该、不应该两种选择,这是落入了二元思考的陷阱里面去了。计划会上当然可以澄清需求,但是不应该是计划会的主要内容,也不应该有很多需求都拖到计划会议上才来澄清。


也即是说,澄清需求这件事,在计划会议上去做是可以的,但不能是常态,只能是例外。澄清需求这件事,应该在日常做,持续地做,到了计划的时候,应该大多数情况下、大多数需求都是已经澄清的,不需要再反复澄清。你说,马上要搭房子了,还没想清楚建几层、建几个房间,没法估算工作量更没法干活吧?软件开发,不也是一个道理么。

点赞 评论 引用 举报

敏捷江湖桃...

发帖: 2粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2020-2-27 16:36:42
直达本楼层的链接
板凳
显示全部楼层

不建议放到计划会议上,原因如下

  • 梳理会议上讨论出的需求设计,在碰撞出新思想之后,产品负责人可以重新好好设计下。

  • 梳理会议上会发现一些需求的依赖,需要在迭代之前解决,可以在梳理会议后去解决,然后再召开新的梳理会议去继续讨论。如果在计划会议上发现这种拦路虎的话,那么计划会议无法进行下去了。

  • 需求梳理之前,只能预估需要的时间,所以花费的时间不确定,有可能比较长。放在上一个迭代中开的话,一次讨论不完,可以再召开一次。如果放在计划会议上开的话,会导致计划会议时间太长,后面还要做任务认领,团队会很疲惫。

  • 梳理会议上澄清完需求的话,在上一个迭代的末期及下一个迭代计划会议之前,团队也都大概知道接下来会有什么需求,会有时间去思考一下。如果只在计划会议上澄清的话,在下一个迭代的计划会议之前,团队会迷茫。

最后,梳理会议的时间点,可以设置在上一个迭代的中后期,比如两周的迭代的话,可以放在第二周周三左右,其他的迭代周期可以参考。虽然Scrum Guide上没有说明梳理会议,但是LeSS框架下有明确的梳理会议及大致的时间点,我觉得比较合理。




点赞1 评论 引用 举报

黄药师(黄...

发帖: 33粉丝: 3

级别 : 注册会员

Rank: 2

发消息 + 关注

发表于2020-2-27 16:58:31
直达本楼层的链接
地板
显示全部楼层

从标题来看,不能简单回答是和否。还是要看情景,以下两点可以借鉴:

1,计划会议最重要的目标不是澄清需求,或者说澄清需求可以在会上做,但不是最重要的。计划应该是最重要的。如果有人对需求不理解,当然可以提出。

2,需求是渐进明细的,需求澄清贯穿整个构建过程。从PO那里拿到需求,计划做这个需求,拆解这个需求,直到开发这个需求,相信越往后的环节你应该是对需求细节越理解的,所以过程中不断思考、提问和理解,需求澄清时刻存在。


有点偏激的讲,如果需求非常少,就要在计划会议上做澄清,难道不行吗?我想可以。

另个面偏激点讲,需求量非常大,难道需求的理解都要在计划会议上吗,那什么时候做计划呢?

点赞 评论 引用 举报

自由的风

发帖: 0粉丝: 1

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2020-2-27 18:11:21
直达本楼层的链接
5#
显示全部楼层

参与过一些项目,都是在梳理会进行的,会梳理出2个迭代左右的任务,如果合并到计划会议时间太长了,计划会上会查缺补漏。

点赞 评论 引用 举报

小小读书虫

发帖: 0粉丝: 0

级别 : 新手上路

Rank: 1

发消息 + 关注

发表于2020-3-2 11:31:19
直达本楼层的链接
6#
显示全部楼层

目前我们团队是在计划会议中做澄清的,这个澄清包括需求的讲解和答疑。我们的计划会议一般1个小时到1个半小时,从时间上来说是可以接受的,暂时也没有出现过什么问题,目前来说还是比较合适于团队的。

梳理会没有实践过,说说我的看法吧:

参加的人员,我觉得应该全员参加,不能仅限于几个核心成员,这样会造成再信息再传递的浪费或丢失。

时间上,可能要具体看下跌打周期的长短,不能一概而论。具体时间我觉得还是在距离结束三分之一左右吧。

点赞 评论 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册