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