今天文中不想去探讨SCRUM的流程，而是讲一个故事吧。
事情要从去年十月份左右的悬崖计划开始，当时对质量抓得很紧，从我们做过的需求，改过的故障中还不断引入新的问题。于是领域给我们定了很严格的两地研讨评审流程。所有的合入版本的需求、故障必须要经过两地研讨，评审通过后，方可合入。
这个流程刚引入的时候。团队的故障迅速积压起来，三十个、四十个、七十个、九十个……故障在源源不断的进来，明显消费速度远远跟不上解决的速度。
所以，在团队里，大家一度的反馈说，故障请审核流程太重了，很多故障都分析了，但是领域没评审或没要求合入，所以一直挂在那里。各种评判的声音不绝于耳。
到了今年年初，对去年一年的质量改进做复盘的时候。却出现了让我很意外的结果。不管是开发还是QA，不少同学都反馈两地研讨对我们的质量提升有很好的作用，因为每次评审的时候，经常会识别出不少风险，而经过评审的故障或需求，大家会觉得放心很多。
再到今年Q1加固迭代的时候，大家识别出目前要外发的版本，合入的不少故障未经两地研讨。最后十天左右的时间，大家把这个事情优先级放得很高。
波总和老刘也不止一次的表扬团队小伙伴的交付材料写得很齐备，故障波及影响分析很清楚。又从另外一方面去反馈了这样一个重型的流程给团队带来的收益。因为，目前质量是团队最最重要的事情。所以这个流程即使增加不少额外工作量，它依然是有意义的。相比较，出了外场故障，各种鸡飞狗跳，写回溯报告，这点投入也是划算的。
感悟:当我们在考虑，是否需要引入一个新流程时，一定想要清楚，我们想要达到的目的是什么。除此以外，还有别的选择吗？大家都是很聪明的小伙伴，做一段时间后，自然会清楚收益是什么样的。另外，SM在这个过程中，不断去找反馈点也很重要。比如，在复盘过程中，大家都提到，两地研讨很有意义，但比较花时间。花的时间，一方面是画流程图，另外一方面其实是在研讨前，要么交付材料写的不够清晰，要么故障没有把疑点都分析清楚。一来二去，做几次下来，大家自然知道如何更高效的去做这件事情。
提问:到底是SCRUM给我们带来的会议太多，流程太多？还是你的会议不够高效？一个流程是否有意义，在于它是否能真正有效的解决你的问题？
