25 October 2006

Pair programming 是兩個人一起寫程式的意思,是 XP 實做中的一環。我們 team 實施已經一年多了,能 pair 的,需要 pair 的專案,都盡量以 pair 的方式進行。需要 pair 的專案是指:

  • 重大的專案,開發時間長
  • 難度高
  • 需要長期維護

呃... 其實有點廢話,Rule 看似簡單,但是我們 team 也沒辦法完全的實行,往往遇到了重要的模組卻騰不出人來。我們 team 的 pair 方式是最簡單的規則:不相衝 -- 當 A, B 兩人 pair 在一起,就讓 AB 一起處理某一正開發中的模組。A,B 除了維護自己過去的專案之外,不會再接其他重大的模組,讓 AB 兩人可以專心衝刺。也就是說我們盡量避免同一時間一模組為 A,B pair,另一模組為 B,C pair 這種 B 無法分身的情形。

理想狀態下當然是盡量做到,不過就是會有 B 相衝的情形。這時可能 C 的模組就被犧牲掉了,變成自己一個人寫。pair 輪替也許是一種解法,但我們認為輪替太沒人性,而且寫程式貴在專心不是嗎?早上寫一半,下午寫另一模組的一半。這 0.5 + 0.5 可不會等於 1 啊,腦袋只會更加勞累混亂而已。當然 pair 途中會有一人忽然被叫去處理舊的模組的問題,另一人就忽然被迫停下來了。不過這算是小 break,並不會有太大的問題。個人稱這段時間為調劑時間。pair 過程是非常緊湊,十分耗費體力與精力 (沒試過的人可以試試,保證累死你),而且一整天下來可能完全沒有個人的時間。老實說這一點還蠻殘忍的,所以一有調劑時間,大家都會盡量把握。

不相衝但有所犧牲是我們現在的策略,不能說是最好的做法,但 run 起來還算滿順的

Pair 現象

Pair 有什麼現象?嗯... 從某個角度來看就兩種:

  • 會起衝突
  • 不會起衝突

我自己覺得這樣歸納還蠻白吃的啦,也或許是看輕了某些事實。就個人的觀察,真的有 pair 個半年而完全不會起衝突的,而且還佔多數。(這裡的衝突是指對某一個做法持不同看法,然後一段時間僵持不下之類的事。) 這真是個好消息啊,最少大多數的 pair 可以順利進行,而不用傷太多腦筋。究其原因,難道是人性本善嗎?呵,我寧可相信是如此。不過管理階層先不要高興的太早。不會起衝突不代表沒有問題,也許是:

  • 彼此間不斷容忍、容忍、容忍、容忍.... 但忍耐有時會有限度的
  • 有一方完全在狀況外,完全由另一方主導,有 pair 和沒 pair 一樣

除了主管要細心觀察 pair 間的互動,及早處理之外。pair 本身也該有所自覺,畢竟自己就是當事人 -- 有時你必須停下來,看一看你的伙伴,或是自己是不是無意中掉入了上面的狀況?

那麼會起衝突的 pair 是不是很差,失敗的組合?個人的看法是,意見不同算是正常的 (意見都相同那還 pair 什麼呢?),鬧衝突其實是把問題給找出來了。完全沒起衝突反到比較危險,因為這種 pair 間的問題是隱性的,不易察覺。當然這種看法好像是希望 pair 都該起個衝突似的... 有點危恐天下不亂。純粹只是提供另一個角度來思考:能夠及早發現、及早治療,也是不錯啊?至於衝突該怎麼解決?Well, 個人不是人際關係的專家,我自個兒的人際關係也是不及格地 (geek 一隻...),不過有一句話到是不錯用:退一步海闊天空 -- 與全台灣 pair 人共勉之。

ps. 全台灣到底有多少 developer 在 pair 啊?


回響

可以用 Tag <I>、<B>,程式碼請用 <PRE>