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结合看板的演进优化