標題問題的提出是因為在敏捷教練小伙伴微信群里面的一段對話，摘錄如下。
張克強 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結合看板的演進優化

總結

以上是生活随笔為你收集整理的Review meeting还开不开？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。