团队今天的迭代评审会，有一个小话题是关于“代码走查记录没有及时关闭的问题”。之所以会这样，是因为我们的团队已经实践了一年多的日常代码审查（dailycodereview）。质量跟踪器将在wiki页面的表格中记录这些问题和负责修改的人员。如果修改负责人下来关闭代码问题处理，登录wiki，在相关问题项的复选框打勾，说明问题已经修复。似乎规则和人员都清楚。但根据近几个月的观察，演练中发现的问题的修复和关闭并不理想。通常有很多问题已经存在很久了，到月底还没有检查解决。我一般都是扮演“看门人”的角色，月底去打卡，但坦白说效果不佳，事倍功半。由于项目和部门的质量部会关注每个团队代码走查的落实情况，虽然每天都在代码走查上花费精力，但是从外部感知和结果统计来看，一堆问题并没有被解决及时关闭。没有闭环。这里有什么问题？如何解决这个难题？看似一个小问题，大家议论纷纷，一场民主大讨论开始了。第一点：质量监督员的问题。质量主管不仅要记录，还要督促相关开发主管及时修改，这样才不会把这么多问题留到月底。同意的小伙伴A：质量跟踪员没有尽职尽责——对了，你知道本次迭代的质量跟踪员是谁吗？对人民。同意的伙伴B：我们看看迭代的花名册吧。从下一次迭代开始，让跟踪器履行他的责任——也许把质量跟踪器的名字写在便利贴上，贴在大屏幕旁边。反对伙伴C：这不是质量追踪器的问题，而是个人主动性和意识的问题。假设按照这个方案，质检员不仅要记录，还要督促别人修改。如果一次提醒失败，质量跟踪器需要提醒两次。质量跟踪器很累。让我们看看，哪些是每次都没有改变的？中立合伙人丁：每个人都很聪明，都有自己的处事方式，所以要相信他们的专业性。不要让大家面对面，压力太大。第2点：不是质量跟踪器的问题，而是写代码的人的问题。伙伴A同意：谁制造问题，谁负责清理问题，就应该主动。这显然是你的问题，为什么质量跟踪器要买单？同意的小伙伴B：刚走完就直接修改了问题。今天的事件，今天的结束，既然演练的记录被认可了，写代码的同学就该解决问题了。不同意的伙伴C：首先，我不同意记录的所有问题，例如：变量命名，类名单词拼写错误，从继承关系到组合关系。这些必须改吗？不改会有什么问题吗？wiki中记录的问题是否得到了有关方面的认可，或者大多数人当场同意。其次，有一类题，是researchquestion，不是修改代码，现在也记录下来。是否适合记录在代码演练的wiki中？这些问题很费时，一时半会儿解决不了。通常重要不紧急。回答伙伴C的丁：这两个建议都很好。笔录的内容应该是大家公认的，如果有疑问，民警会在现场走查确认后再录音。对于非代码问题，衍生业务澄清或业务讨论，最好用单独的笔记本记录，以免与代码修改问题混淆。观点三：不对，是因为现在的做法是有问题的。小伙伴A：最好不要让qualitytracker录，让写代码的同学在walkthrough的时候自己说录。自己记录的问题肯定是自己认可的，一定会修改的。伙伴B：频繁轮换不好，讲解的人要有重点。不建议边讲解边录音。质量跟踪器最好不要轮换，我一起记录一下，保证月底前打勾。C小友：阿弥陀佛，我真的受不了了……这么点小事，怎么会越来越复杂呢？小伙伴D：只要涉及到人，就没有小事。因为人们的认知、行为和习惯是不同的。除了每个人心智模式的差异，还有人与群体关系的复杂性。如果只站在“我”的角度看问题，是很难理解背后的复杂性的。当你遇到问题的时候，你需要用更多的角度去看待和分析问题。不要急于下结论。C小朋友：对，就事论事吧。经过热烈的讨论，我们还是好朋友。定论不休尽管在求同存异之后，这个问题还没有得到普遍接受的定论。但我觉得能开诚布公地讨论还是不错的，以免陷入个人思维的局限。正如乔所说，保持饥饿，保持愚蠢。观点没有对错之分，只看是否适合、贴近球队实际情况。秉承敏捷精神，我们可以拥抱变化，尝试几个头脑风暴后提到的小改进，然后看效果，好的就保留，不好的就微调。
