回到问题上来
如果沟通金字塔的理论说的通，那代码评审就不再是一个：“必须要做的敏捷实践”，而只是沟通金字塔上的一层而已。那它的存在必然是为了弥补上下层沟通之间的空隙，那这个空隙到底是什么呢？是什么样的沟通是结对编程所不能覆盖，而用类似于迭代计划会这种更高层的沟通机制覆盖又不太经济的呢？为了让团队重新找回这个答案，我们最终决定试一试：
停止代码审查一个月，在这一个月的时间我们去体会没有代码审查的得与失，在一个月之后重新举行回顾会议再来讨论是否要继续做代码审查。
在一个月后如期进行的回顾会议上，团队又重新讨论了这个议题，最终觉得通过这一个月的尝试，在还无法做到更频繁地 Switch Pair 的情况下，代码审查还是很有必要的。例如在这个月中，大家对于其他人在做的工作了解变少，集成出现了很多冲突；缺陷的数量也有所增加，其中有些是很明显的错误，很容易通过代码审查的方式发现并在前期消除；代码质量也有明显下降，出现了测试的缺失和很多代码坏味道。
而另一方面为了让代码审查能够真正的发挥其作用和价值，经过讨论我们也优化了代码审查的方式，让大家更有参与感，更有效率，也更有乐趣（见下图抓拍）。
图 5. 改进后的 Code Review
交付价值 Over 遵循实践
日本剑道有个心诀，叫守 破 离:
1.“守”：最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界。
2.“破”：基础熟练后，试着突破原有规范让自己得到更高层次的进化。
3.“离”：在更高层次得到新的认识并总结，自创新招数另辟出新境界。
守固然重要，但如果不能在守得基础上寻求突破，领会其中的奥秘和背后的道理，则始终无法达到离的新境界。在中国的武术中也有“无招胜有招”的说法，这里的无招就是指在将招数融会贯通之后，能够运用招式背后的原理，打破招数的限制，随机应变，自由应对。
而反观我们自己，是不是已经慢慢的不知不觉的被困在“守”的围城之内，变成了猴子定律中最后的那群猴子，只知道去拿香蕉会被打，也会跟着其他猴子去打那些试图拿香蕉的新猴子，但是为什么要这么做？我们已经忘了，或从来都没有知道过。
所以，不要以为遵循了敏捷提倡的一些实践我们就是敏捷的，不要以为遵循了精益的实践我们就是精益的。在我们没有理解并追求其背后真正价值的时候，只不过是平添了另外一份成本而已，不如不做。
本文转载自健荐公众号。
评论