Q: 結對編程、責任共享，完全是胡說，代碼找不到作者，開發人員哪里會有責任心!
A: 這個疑問基于一個假設: 開發人員的責任心來自于問責制度, 開發人員只有在恐懼的驅使下才會細心去編碼.
我不知道你的職位是什么, 你或許是某個大中型企業的中高層領導, 或許手下有不少的人, 但你不會得到手下的尊敬, 他們只有"畏".
或許在對死亡之類的恐懼面前, 人類會爆發出強大的力量, 對于醫療系統, 軍事系統,
心存敬畏之心是對的. 但日常生活中, 人們在榮譽而不是恐懼的驅使下, 更能發揮自己的潛能
Pair都希望通過展示自己的知識得到彼此的尊敬, 都希望代碼輪轉到其他同行手中時得到對代碼質量的贊賞.
是的, 即使代碼不署名, 團隊依然清楚誰的代碼寫的好, 因為結對和輪換, 因為版本控制系統.
但是, 你, 管理者, 不需要知道哪塊代碼是誰寫的, 不需要知道引起重大損失的Bug是哪個開發者引入的. 所有的事情都是整個團隊一起完成的.
事實上, 你真正想知道的, 是整體上誰優秀, 誰需要提高, 或者誰真的不適合. 有其它比代碼署名更好更有效, 而且不會把整個團隊籠罩在恐懼的陰影下的方法.
Q: 那是什么方法?
A: 這涉及到整個考評體系的轉變. 舉個例子, 團隊應該作為一個整體被考評, 客戶的反饋, 帶來的利潤, 造成的損失, 都應該只到團隊這一級, 榮辱與共.
團隊內部每個成員的考評, 應該由團隊自己完成, 成員之間經歷了輪換結對, 誰優秀, 誰需要提高, 誰不適合, 都會有共識, 偽裝不了.
Q: 你是說同行互評? 別扯了, 我只要弄好人際關系, 隨你怎么評. 況且尤其是中國人, 抹不開面子, 怎么好意思當面說人家壞話.
A: 這是另外一個觀念的轉變, 必須借助于團隊文化達成共識: 同行互評, 是幫助你發現自己的不足, 幫助你提高, 不是指責或貶低你. 如果你真的不合適,
同行互評會更快的讓你認識到這一點, 從而努力提高或盡快選擇其它的道路.
至于面子問題, 依然需要團隊文化, 在秉承"溝通, 反饋, 勇氣", 心態開放的團隊里, 當面反饋反而更易接受.
另一方面, 大家都心智成熟,
如果一個人令周圍的人都不爽, 難道真的因為面子的問題忍受下去?
Q: 怎么結對編程, 責任共享扯出這么大的動靜來? 還要顛覆公司的考核體系?
A: 是的, 結對編程是 XP 實踐中最具爭議的一個. 反對它的開發者不在少數, 但更大的阻力來自老板的本能反對.
我們不幸生活在口號的時代. 或許領導們習慣了喊口號, 而從不考慮讓口號"落地", 從不關注口號的實施. "合作"是不是能把耳朵磨出老繭的口號?
有什么具體行動? 結對編程就是最具體的一種合作啊.
老板們對它的質疑更多的是效率上. 其實就像TDD增加了整體代碼量但不是工作量一樣, 結對編程并非像直覺的那樣降低了效率, 而是失之東隅, 收之桑榆,
甚至魚與熊掌兼得.
幾個俗套但不親身體驗就無法體會的論斷:
-
不是總希望員工像驢一樣干活不要偷懶嗎? 為什么不讓員工互相監督? 有人坐在旁邊盯著你的屏幕, 你能上網,打游戲,和女朋友聊天? 天亮就干活,一直到天黑
-
不是總擔心員工跳槽帶來損失嗎? 為什么不趁他還在的時候就讓團隊把他所有的知識都吸收干凈?
-
不是總擔心有人寫爛代碼嗎? 不是一直覺得code review流于形式效果不理想嗎? 還有比結對/輪換結對更徹底的code review形式嗎?
-
不是總想取長補短, 優勢互補嗎? 不是總想達到"臭皮匠頂諸葛亮"的效果嗎?
-
不是總擔心新員工成長太慢嗎?
-
不是總希望團隊氣氛融洽, 互幫互助, 沒人跳樓嗎?
Q: 我干嘛要把辛辛苦苦很多年積累的經驗白白告訴別人? 我喜歡不可替代的感覺.
A: 是的, 本質上這是一個心理學和政治學的問題, 我也無法說服你. 但有幾點, 還是要說一下.
-
獨自解決一個別人無法解決的難題, 可以得到公司的承認; 把知識傳授給團隊, 至少也會得到團隊的認可
-
解決已知問題的經驗, 可以傳授. 但當未知問題出現時, 多年的沉淀依然不可代替. 即使新手知道解決問題的一般原則, 真正熟練運用也需要歲月的歷練.
-
如果你真的擁有智慧, 不必擔心別人剽竊你的只言片語, 它們剽竊不了你的思想
如果你只是擔心功勞會被別人搶走, 好吧, 我心理學和搞政治兩方面都很差, 也沒什么辦法. 或許你可以堅持你不喜歡結對, 團隊也不應該強求你結對.
Q: 有些老手不喜歡結對, 覺得新人不勞而獲對他們不利, 不情愿, 怎么辦?
A: 人們總是在心甘情愿的去做一件事的時候效率最高, 結對編程也應該遵循這個原則. 但并不意味著不做任何努力就放棄結對的紀律.
有些人可能憑直覺不喜歡結對, 但不曾真的嘗試過. 你要想辦法讓團隊的人真正花點時間試過, 再來下結論, 或許想法就會有所改變.
但實踐初期, 有一個敏捷教練是有必要的. 結對涉及到人與人之間的合作, 性格的碰撞. 人的問題是最難纏的問題, 稍有不順心, 就會夸大結對的負面效果,
比如彼此之間的爭執, 互不相讓等, 又或者總是由強勢的人來主導, 平和的人總是被迫承擔不喜歡的決定, 及它帶來的后果.
敏捷教練可以發現這些問題的苗頭, 并協助團隊建立良好的紀律和習慣.
Q: 你剛才提到結對就是持續 Code Review, 可如果是兩個新手結對, 代碼質量還是得不到保證. 聽說不鼓勵新手結對, 是否真的?
A: 沒什么真不真, 取決于你的資源情況. 兩個經驗豐富而又各有所長的人合作解決問題自然是最高效的. 現實生活中的最佳拍檔不勝枚舉,
甚至小說中人們也表達了對這種合作形式的強烈向往: 陸小鳳與花滿樓司空摘星, 楚留香與胡鐵花姬冰雁, 四大名捕等.
然而確實團隊中不是每個人都是楚留香. 事實上, 有經驗的人能占到一半, 從而保證每對開發者都有一位經驗豐富的人, 已經很不錯了.
新人結對, 卻也有另外一種效果, 以探索的方式成長, 雖然對團隊短期的整體效率可能是個短板, 但對個人的成長, 會留下一些印象深刻的教訓,
在未來的職業生涯中發揮作用.
有一些互相支撐的實踐來提高新人結對的效率, 比如團隊專用的開發空間, 實際上大家都坐在一間屋子里,
經驗豐富的人聽到新人Pair之間的討論明顯偏離正確的解決方案的時候, 隨時可以加入討論.
Q: 那互不相讓怎么辦?
A: 幾種實踐:
-
卷入更多的人討論, 時間窗;
-
先選擇其中一個人的意見做做看看;
-
不要選擇夾生飯, 即妥協出來的方案通常集中了兩種方案的缺點.
其實結對編程對開發者的沖擊最大. 把你的工作重點從與機器打交道變成了與人打交道. 把你從虛擬的機器世界拉回到現實世界. 把程序員重新變回成"人",
練習人與人之間的交流.
工作上的爭論, 對事不要對人.
Q: 強勢的人主導怎么辦?
A: 這個問題很快能夠被整個團隊發現. 團隊需要和強勢的人溝通, 提醒, 碰到問題不應該一味維護自己的方案. 但通常本性難改,
這時其他成員在發生此類問題的時候如果堅信自己的方案有可取之處, 要堅持不要放棄, 可以擴大討論范圍, 卷入更多的人討論.
項目經理和初期的敏捷教練需要特別關注此類問題, 因為它有可能把結對變成假結對, 只是表面看是兩個人.
Q: 難道一定要結對? 個人編碼時代一樣產生了無數優秀的軟件, 而且更能體現作者的思想和個性.
A: "一定"這類詞只應出現在幾個基本定理中, 其它場合通常是錯的, 而且總會給措辭追咬者提供把柄, 有時甚至你只是說某個東西好推薦使用,
他也能理解成你說的是"一定"要用某個東西
至少兩個極端情形下, 結對并不強制:
-
復雜, 初期需要靜心思考的問題, 可以分頭行動, 各自有了理解或解決方案或時間窗到了再來討論. 言語在思考的過程中也會幫忙, 但我們都知道對有些問題,
言語只會打擾思路.
-
一堆瑣碎毫無技術含量的工作, 不得不手工完成, 只是考驗耐心, 自然不妨分頭行動, 效率肯定比結對要高
Q: 幾對開發者同時討論各自的問題, 太吵了!
A: 小點聲.
Q: 又說Pair之間要交流, 要討論以便周圍的人聽到后可以及時發現偏差以節省時間. 到底要小聲還是要大聲?
A: 安靜的討論
Q: 如果代碼集體所有, 那某個模塊出錯，此時已經有超過5對開發者編輯過此模塊代碼，那么誰來改?
A: 團隊來改. 如果要在某個模塊上增加新功能, 此時已經有超過5對開發者編輯過此模塊代碼,
那么誰來添加?
Q: 我想修改某段代碼, 想找原作者了解一下思路, 可根本不知道是誰.
A: svn praise/blame. 然而更應該發生的是:
-
TDD, 一旦改錯單元測試用例會給你反饋.
-
輪換結對編程, 可能很多人都清楚那段代碼.
-
簡單設計, 代碼不應該太復雜