Review meeting还开不开?

标题问题的提出是因为在敏捷教练小伙伴微信群里面的一段对话,摘录如下。
张克强 10:35
Scrum碰到高频交付,其最小集合要求也得改。
徐毅 10:36
@张克强-独立教练-上海 什么是scrum,它不能应对高频交付吗
张克强 10:37
到每迭代一次交付的频度就超越了Scrum创始时应对的情景。
张克强 10:38
90年代的高频是相对当时的瀑布说的。
张克强 10:38
现在的高频是互联网的高频。
张克强 10:38
差2个数量级,以上
徐毅 10:50
你说的高频到底是什么高频
张克强 11:10
比如每周上线一次,甚至更多
徐毅 11:38
@张克强-独立教练-上海 了解。那这种情况下,你说的修改最小集合,是要改什么
张克强 11:40
我看到冲击最大的是潜在可交付产品和review meeting
徐毅 11:41
@张克强-独立教练-上海 怎么个冲击
张克强 11:42
上线了,没有必要看demo
徐毅 11:43
@张克强-独立教练-上海 那么review meeting可以特别高效,是好事啊
张克强 11:46
review meeting本身也许不再需要每个迭代都需要。
上线后的用户反馈不会按照会议的节奏来的。
张克强 11:54
@姜信宝BoB CST@敏捷变革中心  2迭代一次的review meeting如何? 在大量线上数据和用户反馈已经获得的情况下?
张克强 11:56
Scrum理论上霸道的宣称不执行其最小集合,就不是Scrum。
姜信宝BoB CST@敏捷变革中心 11:58
你用人家的东西,还去改。改完了还说这就是你家的东西
李洁(Jerry Li) 11:58
是不是Scrum,真的很重要吗?不执行最小集合就不符合PDCA的理念吗
徐毅 11:59
大家只是说,你修改之后,就不是Scrum了
张绍鹏 11:59
scrum可以随便改,只是改完不要叫scrum就行
张克强 12:01
我的point是Scrum不能适应现在的高频交付。
并不是根据高频需要修改后的Scrum还叫Scrum。
张克强 12:07
就拿上面例子:一周一迭代,两周一次开review meeting,不能称为Scrum,
需要为了让它满足Scrum,加开一次会议吗?
李洁(Jerry Li) 12:07
如果在迭代中,故事一完成就进行review,还需要在迭代结束时召开review会议吗?

Scrum的Review meeting定义是很容易查到的。参见http://www.scrumguides.org/scrum-guide.html#events-review
其诞生的背景是在上世纪90年代,当时占主导地位的生命周期模型是瀑布型生命周期模型,配套着相应的方法,尤其是里程碑评审方法。在瀑布型生命周期下,可运行软件在生命周期的最后几个阶段才能出现。而Scrum就是在上述背景下应运而生,给出了清晰的冲刺以及冲刺内部的各项仪式,其中包括了review meeting。Scrum本身没有说明发布与冲刺的关系,各个组织根据自身情况来安排,常见的一个安排例子是每三个迭代进行一次发布。所以早期的Review meeting上是看不到已经发布运行的软件。Scrum对迭代末产物的说法是potentially releasable product Increment,注意是potentially。
到2009年时,Review meeting上面所演示的对象往往都是可运行的Demo,这已经满足敏捷宣言的要求。甚至于在有些组织内部,用Demo会议或者Demo这个说法来替代review meeting。
Review meeting与Retrospecitve meeting是有不同侧重点,Review meeting侧重在于所开发的产品或者系统本身,比如新功能,功能改进,性能改进等等。
而Retrospecitve meeting侧重于如何更好的开发产品或者系统,比如新工具,改进DoD,建设CI等等。

那么这个世界变化越来越快,软件更新因为业务需求越来越频繁,比如每周一个冲刺并且发布的情况,
这里的背景与以前90年代的背景发生了巨大的改变,软件一直在运行,发布之后马上就有实际最终用户在使用,可运行软件这个要求被天然的满足。
那么Scrum的执行如何应对?
是因为Scrum定义了其最小集合,就仍然要严格按照Scrum要求执行Review meeting吗?
还是说Review meeting在一周一发布的情况下仍然是很有帮助的会议,值得坚持?
抑或是根据实际需要,不追求一定符合Scrum,取消Review meeting,或者合并到Retrospective meeting里面,二合一的会议改名为冲刺结束会议
抑或是把下个迭代的计划会议也合并进来,出现一个三合一的会议,这会议也许改名为迭代会议。 从时间顺序而言,这三个会议本来就紧挨着。当迭代周期缩短时,一般会议时间也缩短,这样情况下,三个会议是完全有可能在安排在一个半天里面的。
当然讨论的焦点其实是在第二个问题:Review meeting在一周一发布的情况下仍然是很有帮助的会议,值得坚持?
Review meeting最关键的目标是 elicit feedback and foster collaboration。在发布的情况下,不再只是potentially releasable product Increment,而是上线运行的产品整体(还可能是更加复杂的灰度发布,或者金丝雀发布等等)。通过实际运行不仅仅是已经做了收集反馈,而且是必须做收集反馈并处理。其反馈的极端形式是线上故障,必须紧急修改。另外的例子有用户抱怨、意见和建议,有些高优先级抱怨转换来的需求可能需要马上处理,或者直接放入下个迭代处理。
现在多数高频发布的产品一般都有用户使用数据自动采集机制,不需要用户主动提出反馈,产品本身直接收集大量用户使用数据,来判断产品运行情况。不少组织甚至做到了实时用户数据分析。
在这样的背景下,review meeting如果非要坚持每周开一次,也许只需花10分钟很高效的过一下,因为需要处理的已经处理,那这样的review meeting就不再是必须要开的会议了。

当然,“Scrum碰到高频交付,其最小集合要求也得改。” 这句话也许表达是有误的。因为Scrum的最小集合不接受再减少,因此当Review meeting不开的情况下,就不能称之为Scrum。
目前只有Scrum的两位作者有权可以修改其最小集合要求。
因此,那句话也许应当修改为“当Scrum碰到高频时,就没有必要坚持Scrum所要求的最小集合要求,结合实际情况来判断是否每个迭代召开Review meeting,或者考虑合并到回顾会,甚至大合并计划会议。
一旦突破Scrum的最小集合要求,那么不能宣称是在实践Scrum”。
不执行Scrum所要求的最小机会的Scrum实施,在业界有个Scrumbut的说法,也许在结合看板使用的情况下,有另外一个更加合适的说法,就是Scrumban。

下图是Scrumban微信群的邀请,欢迎来探讨Scrum结合看板的演进优化
这里写图片描述

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页