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 啊？