標(biāo)題問(wèn)題的提出是因?yàn)樵诿艚萁叹毿』锇槲⑿湃豪锩娴囊欢螌?duì)話，摘錄如下。
張克強(qiáng) 10:35
Scrum碰到高頻交付，其最小集合要求也得改。
徐毅 10:36
@張克強(qiáng)-獨(dú)立教練-上海?什么是scrum，它不能應(yīng)對(duì)高頻交付嗎
張克強(qiáng) 10:37
到每迭代一次交付的頻度就超越了Scrum創(chuàng)始時(shí)應(yīng)對(duì)的情景。
張克強(qiáng) 10:38
90年代的高頻是相對(duì)當(dāng)時(shí)的瀑布說(shuō)的。
張克強(qiáng) 10:38
現(xiàn)在的高頻是互聯(lián)網(wǎng)的高頻。
張克強(qiáng) 10:38
差2個(gè)數(shù)量級(jí)，以上
徐毅 10:50
你說(shuō)的高頻到底是什么高頻
張克強(qiáng) 11:10
比如每周上線一次，甚至更多
徐毅 11:38
@張克強(qiáng)-獨(dú)立教練-上海?了解。那這種情況下，你說(shuō)的修改最小集合，是要改什么
張克強(qiáng) 11:40
我看到?jīng)_擊最大的是潛在可交付產(chǎn)品和review meeting
徐毅 11:41
@張克強(qiáng)-獨(dú)立教練-上海?怎么個(gè)沖擊
張克強(qiáng) 11:42
上線了，沒(méi)有必要看demo
徐毅 11:43
@張克強(qiáng)-獨(dú)立教練-上海?那么review meeting可以特別高效，是好事啊
張克強(qiáng) 11:46
review meeting本身也許不再需要每個(gè)迭代都需要。
上線后的用戶反饋不會(huì)按照會(huì)議的節(jié)奏來(lái)的。
張克強(qiáng) 11:54
@姜信寶BoB CST@敏捷變革中心? 2迭代一次的review meeting如何？ 在大量線上數(shù)據(jù)和用戶反饋已經(jīng)獲得的情況下？
張克強(qiáng) 11:56
Scrum理論上霸道的宣稱不執(zhí)行其最小集合，就不是Scrum。
姜信寶BoB CST@敏捷變革中心 11:58
你用人家的東西，還去改。改完了還說(shuō)這就是你家的東西
李潔（Jerry Li） 11:58
是不是Scrum，真的很重要嗎？不執(zhí)行最小集合就不符合PDCA的理念嗎
徐毅 11:59
大家只是說(shuō)，你修改之后，就不是Scrum了
張紹鵬 11:59
scrum可以隨便改，只是改完不要叫scrum就行
張克強(qiáng) 12:01
我的point是Scrum不能適應(yīng)現(xiàn)在的高頻交付。
并不是根據(jù)高頻需要修改后的Scrum還叫Scrum。
張克強(qiáng) 12:07
就拿上面例子：一周一迭代，兩周一次開(kāi)review meeting，不能稱為Scrum，
需要為了讓它滿足Scrum，加開(kāi)一次會(huì)議嗎？
李潔（Jerry Li） 12:07
如果在迭代中，故事一完成就進(jìn)行review，還需要在迭代結(jié)束時(shí)召開(kāi)review會(huì)議嗎？

Scrum的Review meeting定義是很容易查到的。參見(jiàn)http://www.scrumguides.org/scrum-guide.html#events-review
其誕生的背景是在上世紀(jì)90年代，當(dāng)時(shí)占主導(dǎo)地位的生命周期模型是瀑布型生命周期模型，配套著相應(yīng)的方法，尤其是里程碑評(píng)審方法。在瀑布型生命周期下，可運(yùn)行軟件在生命周期的最后幾個(gè)階段才能出現(xiàn)。而Scrum就是在上述背景下應(yīng)運(yùn)而生，給出了清晰的沖刺以及沖刺內(nèi)部的各項(xiàng)儀式，其中包括了review meeting。Scrum本身沒(méi)有說(shuō)明發(fā)布與沖刺的關(guān)系，各個(gè)組織根據(jù)自身情況來(lái)安排，常見(jiàn)的一個(gè)安排例子是每三個(gè)迭代進(jìn)行一次發(fā)布。所以早期的Review meeting上是看不到已經(jīng)發(fā)布運(yùn)行的軟件。Scrum對(duì)迭代末產(chǎn)物的說(shuō)法是potentially releasable product Increment，注意是potentially。
到2009年時(shí)，Review meeting上面所演示的對(duì)象往往都是可運(yùn)行的Demo，這已經(jīng)滿足敏捷宣言的要求。甚至于在有些組織內(nèi)部，用Demo會(huì)議或者Demo這個(gè)說(shuō)法來(lái)替代review meeting。
Review meeting與Retrospecitve meeting是有不同側(cè)重點(diǎn)，Review meeting側(cè)重在于所開(kāi)發(fā)的產(chǎn)品或者系統(tǒng)本身，比如新功能，功能改進(jìn)，性能改進(jìn)等等。
而Retrospecitve meeting側(cè)重于如何更好的開(kāi)發(fā)產(chǎn)品或者系統(tǒng)，比如新工具，改進(jìn)DoD，建設(shè)CI等等。

那么這個(gè)世界變化越來(lái)越快，軟件更新因?yàn)闃I(yè)務(wù)需求越來(lái)越頻繁，比如每周一個(gè)沖刺并且發(fā)布的情況，
這里的背景與以前90年代的背景發(fā)生了巨大的改變，軟件一直在運(yùn)行，發(fā)布之后馬上就有實(shí)際最終用戶在使用，可運(yùn)行軟件這個(gè)要求被天然的滿足。
那么Scrum的執(zhí)行如何應(yīng)對(duì)？
是因?yàn)镾crum定義了其最小集合，就仍然要嚴(yán)格按照Scrum要求執(zhí)行Review meeting嗎？
還是說(shuō)Review meeting在一周一發(fā)布的情況下仍然是很有幫助的會(huì)議，值得堅(jiān)持？
抑或是根據(jù)實(shí)際需要，不追求一定符合Scrum，取消Review meeting，或者合并到Retrospective meeting里面，二合一的會(huì)議改名為沖刺結(jié)束會(huì)議
抑或是把下個(gè)迭代的計(jì)劃會(huì)議也合并進(jìn)來(lái)，出現(xiàn)一個(gè)三合一的會(huì)議，這會(huì)議也許改名為迭代會(huì)議。 從時(shí)間順序而言，這三個(gè)會(huì)議本來(lái)就緊挨著。當(dāng)?shù)芷诳s短時(shí)，一般會(huì)議時(shí)間也縮短，這樣情況下，三個(gè)會(huì)議是完全有可能在安排在一個(gè)半天里面的。
當(dāng)然討論的焦點(diǎn)其實(shí)是在第二個(gè)問(wèn)題：Review meeting在一周一發(fā)布的情況下仍然是很有幫助的會(huì)議，值得堅(jiān)持？
Review meeting最關(guān)鍵的目標(biāo)是 elicit feedback and foster collaboration。在發(fā)布的情況下，不再只是potentially releasable product Increment，而是上線運(yùn)行的產(chǎn)品整體（還可能是更加復(fù)雜的灰度發(fā)布，或者金絲雀發(fā)布等等）。通過(guò)實(shí)際運(yùn)行不僅僅是已經(jīng)做了收集反饋，而且是必須做收集反饋并處理。其反饋的極端形式是線上故障，必須緊急修改。另外的例子有用戶抱怨、意見(jiàn)和建議，有些高優(yōu)先級(jí)抱怨轉(zhuǎn)換來(lái)的需求可能需要馬上處理，或者直接放入下個(gè)迭代處理。
現(xiàn)在多數(shù)高頻發(fā)布的產(chǎn)品一般都有用戶使用數(shù)據(jù)自動(dòng)采集機(jī)制，不需要用戶主動(dòng)提出反饋，產(chǎn)品本身直接收集大量用戶使用數(shù)據(jù)，來(lái)判斷產(chǎn)品運(yùn)行情況。不少組織甚至做到了實(shí)時(shí)用戶數(shù)據(jù)分析。
在這樣的背景下，review meeting如果非要堅(jiān)持每周開(kāi)一次，也許只需花10分鐘很高效的過(guò)一下，因?yàn)樾枰幚淼囊呀?jīng)處理，那這樣的review meeting就不再是必須要開(kāi)的會(huì)議了。

當(dāng)然，“Scrum碰到高頻交付，其最小集合要求也得改。” 這句話也許表達(dá)是有誤的。因?yàn)镾crum的最小集合不接受再減少，因此當(dāng)Review meeting不開(kāi)的情況下，就不能稱之為Scrum。
目前只有Scrum的兩位作者有權(quán)可以修改其最小集合要求。
因此，那句話也許應(yīng)當(dāng)修改為“當(dāng)Scrum碰到高頻時(shí)，就沒(méi)有必要堅(jiān)持Scrum所要求的最小集合要求，結(jié)合實(shí)際情況來(lái)判斷是否每個(gè)迭代召開(kāi)Review meeting，或者考慮合并到回顧會(huì)，甚至大合并計(jì)劃會(huì)議。
一旦突破Scrum的最小集合要求，那么不能宣稱是在實(shí)踐Scrum”。
不執(zhí)行Scrum所要求的最小機(jī)會(huì)的Scrum實(shí)施，在業(yè)界有個(gè)Scrumbut的說(shuō)法，也許在結(jié)合看板使用的情況下，有另外一個(gè)更加合適的說(shuō)法，就是Scrumban。

下圖是Scrumban微信群的邀請(qǐng)，歡迎來(lái)探討Scrum結(jié)合看板的演進(jìn)優(yōu)化

總結(jié)

以上是生活随笔為你收集整理的Review meeting还开不开？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。