Q: 結對編程、責任共享，完全是胡說，代碼找不到作者，開發人員哪里會有責任心!
A: 這個疑問基于一個假設: 開發人員的責任心來自于問責制度, 開發人員只有在恐懼的驅使下才會細心去編碼.
我不知道你的職位是什么, 你或許是某個大中型企業的中高層領導, 或許手下有不少的人, 但你不會得到手下的尊敬, 他們只有"畏".
或許在對死亡之類的恐懼面前, 人類會爆發出強大的力量, 對于醫療系統, 軍事系統, 心存敬畏之心是對的. 但日常生活中, 人們在榮譽而不是恐懼的驅使下, 更能發揮自己的潛能
Pair都希望通過展示自己的知識得到彼此的尊敬, 都希望代碼輪轉到其他同行手中時得到對代碼質量的贊賞.
是的, 即使代碼不署名, 團隊依然清楚誰的代碼寫的好, 因為結對和輪換, 因為版本控制系統.
但是, 你, 管理者, 不需要知道哪塊代碼是誰寫的, 不需要知道引起重大損失的Bug是哪個開發者引入的. 所有的事情都是整個團隊一起完成的.
事實上, 你真正想知道的, 是整體上誰優秀, 誰需要提高, 或者誰真的不適合. 有其它比代碼署名更好更有效, 而且不會把整個團隊籠罩在恐懼的陰影下的方法.
Q: 那是什么方法?
A: 這涉及到整個考評體系的轉變. 舉個例子, 團隊應該作為一個整體被考評, 客戶的反饋, 帶來的利潤, 造成的損失, 都應該只到團隊這一級, 榮辱與共.
團隊內部每個成員的考評, 應該由團隊自己完成, 成員之間經歷了輪換結對, 誰優秀, 誰需要提高, 誰不適合, 都會有共識, 偽裝不了.
Q: 你是說同行互評? 別扯了, 我只要弄好人際關系, 隨你怎么評. 況且尤其是中國人, 抹不開面子, 怎么好意思當面說人家壞話.
A: 這是另外一個觀念的轉變, 必須借助于團隊文化達成共識: 同行互評, 是幫助你發現自己的不足, 幫助你提高, 不是指責或貶低你. 如果你真的不合適, 同行互評會更快的讓你認識到這一點, 從而努力提高或盡快選擇其它的道路.
至于面子問題, 依然需要團隊文化, 在秉承"溝通, 反饋, 勇氣", 心態開放的團隊里, 當面反饋反而更易接受.
另一方面, 大家都心智成熟, 如果一個人令周圍的人都不爽, 難道真的因為面子的問題忍受下去?
Q: 怎么結對編程, 責任共享扯出這么大的動靜來? 還要顛覆公司的考核體系?
A: 是的, 結對編程是 XP 實踐中最具爭議的一個. 反對它的開發者不在少數, 但更大的阻力來自老板的本能反對.
我們不幸生活在口號的時代. 或許領導們習慣了喊口號, 而從不考慮讓口號"落地", 從不關注口號的實施. "合作"是不是能把耳朵磨出老繭的口號? 有什么具體行動? 結對編程就是最具體的一種合作啊.
老板們對它的質疑更多的是效率上. 其實就像TDD增加了整體代碼量但不是工作量一樣, 結對編程并非像直覺的那樣降低了效率, 而是失之東隅, 收之桑榆, 甚至魚與熊掌兼得.
幾個俗套但不親身體驗就無法體會的論斷:
-
不是總希望員工像驢一樣干活不要偷懶嗎? 為什么不讓員工互相監督? 有人坐在旁邊盯著你的屏幕, 你能上網,打游戲,和女朋友聊天? 天亮就干活,一直到天黑
-
不是總擔心員工跳槽帶來損失嗎? 為什么不趁他還在的時候就讓團隊把他所有的知識都吸收干凈?
-
不是總擔心有人寫爛代碼嗎? 不是一直覺得code review流于形式效果不理想嗎? 還有比結對/輪換結對更徹底的code review形式嗎?
-
不是總想取長補短, 優勢互補嗎? 不是總想達到"臭皮匠頂諸葛亮"的效果嗎?
-
不是總擔心新員工成長太慢嗎?
-
不是總希望團隊氣氛融洽, 互幫互助, 沒人跳樓嗎?
文章來源于領測軟件測試網 http://www.kjueaiud.com/
