今天文中不想去探討SCRUM的流程，而是講一個故事吧筑悴。
事情要從去年十月份左右的懸崖計劃開始，當(dāng)時對質(zhì)量抓得很緊睛竣，從我們做過的需求求摇，改過的故障中還不斷引入新的問題。于是領(lǐng)域給我們定了很嚴(yán)格的兩地研討評審流程与境。所有的合入版本的需求、故障必須要經(jīng)過兩地研討挥转，評審?fù)ㄟ^后，方可合入绑谣。
這個流程剛引入的時候。團(tuán)隊的故障迅速積壓起來借宵，三十個、四十個豁护、七十個欲间、九十個……故障在源源不斷的進(jìn)來，明顯消費速度遠(yuǎn)遠(yuǎn)跟不上解決的速度猎贴。
所以，在團(tuán)隊里吝梅，大家一度的反饋說惹骂，故障請審核流程太重了做瞪，很多故障都分析了，但是領(lǐng)域沒評審或沒要求合入装蓬，所以一直掛在那里。各種評判的聲音不絕于耳牍帚。
到了今年年初，對去年一年的質(zhì)量改進(jìn)做復(fù)盤的時候鄙币。卻出現(xiàn)了讓我很意外的結(jié)果蹂随。不管是開發(fā)還是QA，不少同學(xué)都反饋兩地研討對我們的質(zhì)量提升有很好的作用岳锁，因為每次評審的時候，經(jīng)常會識別出不少風(fēng)險咳燕，而經(jīng)過評審的故障或需求，大家會覺得放心很多招盲。
再到今年Q1加固迭代的時候，大家識別出目前要外發(fā)的版本表制，合入的不少故障未經(jīng)兩地研討控乾。最后十天左右的時間，大家把這個事情優(yōu)先級放得很高蜕衡。
波總和老劉也不止一次的表揚團(tuán)隊小伙伴的交付材料寫得很齊備，故障波及影響分析很清楚久脯。又從另外一方面去反饋了這樣一個重型的流程給團(tuán)隊帶來的收益镰吆。因為帘撰，目前質(zhì)量是團(tuán)隊最最重要的事情万皿。所以這個流程即使增加不少額外工作量，它依然是有意義的蹬耘。相比較减余，出了外場故障，各種雞飛狗跳位岔，寫回溯報告，這點投入也是劃算的妙黍。
感悟:當(dāng)我們在考慮瞧剖，是否需要引入一個新流程時可免，一定想要清楚做粤，我們想要達(dá)到的目的是什么。除此以外怕品，還有別的選擇嗎？大家都是很聰明的小伙伴闯估，做一段時間后吼和，自然會清楚收益是什么樣的。另外炫乓，SM在這個過程中，不斷去找反饋點也很重要侠姑。比如，在復(fù)盤過程中莽红，大家都提到邦邦，兩地研討很有意義，但比較花時間圃酵♀晒埽花的時間，一方面是畫流程圖捌锭，另外一方面其實是在研討前罗捎，要么交付材料寫的不夠清晰，要么故障沒有把疑點都分析清楚桨菜。一來二去捉偏，做幾次下來泻红，大家自然知道如何更高效的去做這件事情。
提問:到底是SCRUM給我們帶來的會議太多讹躯，流程太多缠劝？還是你的會議不夠高效？一個流程是否有意義惨恭，在于它是否能真正有效的解決你的問題？
