[[236712]]

團隊今天的迭代回顧會，有一個小議題是關于“代碼走查記錄的問題關閉不及時”的問題。

事情起因是這樣的，我們團隊踐行每日代碼走查(daily code review)已有超過一年了，走查過程中大家會針對前一天提交的代碼提出不少問題和修改意見，然后由一位質量跟蹤員將這些問題及問題的修改責任人，記錄在wiki頁面的表格里。如果修改責任人下來將代碼問題處理關閉了，就登陸wiki，對相關問題項的復選框打勾，表示問題已經被修復。

看起來，規則和人員都是明確的。但從近幾個月觀察來看，走查發現問題的修復和關閉情況卻不甚理想，通常都有不少問題一直擺在那里，到了月底還沒有打勾解決。我通常會扮演“看門人”的角色，在月底去跟催打勾，但坦率地講效果不佳，而且事倍功半。

由于項目和部門質量部都會關注每個團隊的代碼走查執行落地情況，因此，雖然每天都花費了精力投入代碼走查，但是外部觀感和結果統計來看卻是一堆問題沒有及時關閉，問題沒有閉環。

這到底是哪個環節出了問題?謎題該怎么破?

看似小問題，大家你一言我一語，展開了一場別開生面的民主大討論。

觀點1：質量監督員的問題。

質量監督員不僅要記錄，還要跟催相關的開發負責人及時修改，這樣就不會遺留那么多問題到月底了。

贊同的小伙伴甲：質量跟蹤員，沒有很好地履行自己的職責——對了，大家知道本迭代的質量跟蹤員是誰嗎?算了，恐怕質量監督員自己都不知道，責任沒有落實到人。

贊同的小伙伴乙：那我們就來看看迭代輪值表，下個迭代起，讓跟蹤員盡到責任——不妨把質量跟蹤員的名字寫個便簽紙，貼在大屏幕旁邊。

反對的小伙伴丙：這不是質量跟蹤員的問題，而是個人的主動性和意識問題。假設按這種方案，質量跟蹤員既要記錄，又要去跟催別人修改，一次催了不行，還要催二次，質量跟蹤員好心累。不妨看看，每次都是哪幾個人沒有改?

持中立態度的小伙伴丁：每個人都是聰明的，有自己的做事方式，要信任其專業性。不要把大家弄得針尖對麥芒，太有壓力。

觀點2：不是質量跟蹤員的問題，而是寫代碼的人的問題。

贊同的小伙伴甲：誰制造的問題，誰負責清理，應該有主動性。明明是你的問題，為什么要質量跟蹤員來買單?

贊同的小伙伴乙：我自己就是走查的問題下來立即就修改了。今日事，今日畢，既然認可走查的記錄，寫代碼的同學就應該解決掉問題。

反對的小伙伴丙：首先，我不認可記錄的所有問題，比如：變量命名，類名單詞拼寫錯誤，從繼承關系改為組合關系，這些是不是一定要改，不改會不會有問題?記錄到wiki的問題，是否經過了當事人認可，或者說多數人當場同意。

其次，有一類問題，屬于研討類問題，并不是要修改代碼，現在也記錄了。適不適合記錄在代碼走查的wiki里?這些問題，比較耗時，一時半會也關閉不了。通常是重要不緊急。

回答小伙伴丙的丁同學：兩點建議非常好。記錄的內容，應該是大家認可的，有疑問的***走查當場確認后再記錄。非代碼類問題，衍生出來的業務澄清或者業務研討，***另外用本子記錄，這樣就不會和代碼修改的問題混為一談了。

觀點3：都不對，是當前的做法有問題

小伙伴甲：不如就不要質量跟蹤員記錄了，走查時讓寫代碼的同學自己講，自己記錄。自己記錄的問題自己肯定是已認可的，肯定會去修改。

小伙伴乙：頻繁輪換不太好吧，而且講解的人需要專注，不建議一邊講解一邊記錄。不如不要輪換質量跟蹤員，統一我來記錄吧，保證月底前都會打勾。

小伙伴丙：阿彌陀佛，老衲實在看不下去了……那么小的事情，怎么就越搞越復雜呢?

小伙伴丁：只要涉及到人的事，就沒有小事。因為人與人的認知，行為，習慣都不同。除了每個人的心智模式的差異，還有人與人之間的關系，群體的復雜性。如果只用“我”的視角來看問題，難免難以理解這背后的復雜性。遇到問題，要用更多的視角去看待問題，分析問題。不用著急得出結論。

小伙伴丙：是滴，就事論事，大家激烈討論完，依然還是好伙伴。

未劃休止符的結論

雖然，這個問題在求同存異后，還沒有得到普遍認可的結論。但我覺得，能開放式地探討挺好的，不至于陷入個體思維局限。正如喬幫主說的，keep hungry, stay foolish。觀點沒有對錯，而是說是否適合和貼近團隊的實際情況。

秉持敏捷精神，我們可以擁抱變化，嘗試一下大家頭腦風暴后提到的幾種小改進，然后看看效果，好的就保留，不好則再微調。