Pair Programming

去年以來個人一直在 team 裡疾呼 unit-test 的重要。現在整個 team 裡除了幾個不曾跟 heavy-tester 一起合作的人之外，幾乎都了解 test 的好處和重要 (有些人是沒寫test 吃了大虧，有些人先是被逼著寫，後來嘗到了甜頭 )。去年的開發幾乎完全都是個人單打獨鬥，然後單純互相討論，今年這個新專案由六個人組成，好玩的是分工完之後就自動兩兩成對 pair 了。記得去年前 pair 時大家都哇哇叫，今年好像因為個別的不同理由不得不 pair 啊，目前 pair 的分配是：

• pair A -- 資深(主導性強) + test 新手
• pair B -- 資深(主導性強) + 中等
• pair C -- java 新手 + test 新手 (兩人主導性差不多)

上面的資深資淺以 test 的資歷來計，我個人認為 unit-test 的 quality 很適合用來判斷一個 developer 的生產力。

A組沒有 pair 跟本做不下去，完全由資深帶領資淺，以免出差錯，不過資深的步調極快，資淺的步調極慢.........

C組的只能 pair 了，因為其中一人剛學 java.... 另一人功力夠，不過還沒實際作過專案，也沒有 test 的經驗

B組的都有 test 經驗，而且都能夠獨力作業，其實不 pair 好像也沒差，不過看起來 pair 的理由是有人可以互相討論，減輕壓力。

這是現在看到的現象，不知再過三個月會變成如何呢？呵呵，接下來討論一下經驗和構想吧：

• Personality

我發現讓兩個主導性強的或是兩個主導性弱的 pair 在一起問題會很多。兩個主導性強的會堅持己見，很容易吵在一起，不僅氣氛差，進度也會變慢。兩個弱的則是遇到問題會卡很久，然後慢吞吞的，不曉得東西什麼時候會出來，很危險。

• Relax Time Control

這個..... 我們目前完全沒有控制作息的時間，目前我的構想是 break 個兩次。讓兩人休息休息，下個禮拜建議大家實施看看好了。

• Standup Meeting

XP 的早上一開始都會開個幾分鐘的小會議，目前我們也還沒有試過，不過這個大概很難吧... 台灣人好像很不喜歡在制式的會議上發言.... 大家覺得能躲就躲.... 如果這個要推行的話，得將會議弄的輕鬆一點。

• Pair Rotating

目前我們 team 已經自動 pair 起來了，下一個目標自然是 pair rotating。這個遠大的目標不知何時可以採用？還是先玩個 pair 兩三個月好了，等大家非得 pair 時，再來試試看。