Teddy 的 Pair Programming 之旅

01:00~02:10

簡單的說，pair programming 就是兩個人共用一部電腦，坐在一起開發軟體，一個動手，另一個閒著 看著，並不時提供意見 (如果沒在啃雞腿、吃泡麵、看連續劇、或睡著的話)。也許叫做 pair developing 會比較貼切一點。問題是 Kent Beck 大哥用了pair programming 這個名稱，晚輩們不敢造次，繼續沿用。

此時 Teddy 又聽到鄉民們的怒吼：「什麼，人都不夠用了還兩個人一起寫，這麼爽。兩個人分開寫不是比較快」

的確，連小學生都會的算數：一個人一小時寫 20 行程式，請問兩個人分開同時寫，一小時可以寫幾行?
答案是：「40 行」

那麼，如果兩個人一起寫，一小時可以寫幾行?
答案是：「20 行」

所以，你的老闆一定反對 pair programming ，因為生產力變成一半。

*************************************************************************

鄉民們有看過「實習醫生」這部影集嗎？片中的實習醫生或是住院醫生，想盡各種辦法，都要陪著「主治醫生」一起進開刀房動手術。手術室中除了若干位醫生，還有護士、麻醉師、操作醫療儀器的技術員等。耶，那開醫院的人一定都是笨蛋，因為這樣生產力變成 1/N。

為什麼動手術需要這麼多人？因為「品質(人命)」比「速度 (生產力)」來的重要。

此外，很多位醫生一起動刀還肩負著 相互監視「經驗傳承 (教學)」的目的。在動手術的過程中，資深醫生會和實習醫生對話，測試他們對病況了解的程度與應對方針是否洽當。時機成熟也會讓實習醫生們動動刀 (可憐的病人...)。

當遇到很棘手的案例時 (例如，切除不良腫瘤)，有時需要動用到多位資深的醫生一起動刀。所以不一定都是資深醫生搭配實習或住院醫生。

*************************************************************************

如果我們看重的是「程式的品質」而不僅是「寫程式的速度」，那麼 pair programming 就很有意義了。因為 pair programming 同時具備 coding、review、testing、 refactoring、learning 等目的，是一種殺傷力很強的武器。但大家也都知道實施 pair programming 不容易。為什麼？扣除大家熟知的環境因素 (沒有開刀房 沒有大桌子、大螢幕)、配對因素 (熟手配熟手、熟手配生手、生手配生手、男生配男生、男生配女生、女生配女生、團團配圓圓、地球人配火星人...)、不信任 (覺得生產力剩下一半、浪費時間、無聊...) 以外，在 Certified Scrum Master 課程講義中有提到一點：

因為 pair programming 打破人的界線 (boundary)

Teddy 很同意，咱們台灣人連「藍綠蜘蛛網」都打不破了，更別說要打破人的界線。

*************************************************************************

Teddy 提一下自己擔任 Scrum Master，在專案中鼓吹 pair programming 的經驗：

• phase 1，政令宣導：鼓勵團隊有機會的話儘量採用 pair programming 。結果是，沒人理Teddy。
• phase 2，自己下海：找一、二個團隊成員來和 Teddy pair。成效還不錯，不過自己累的半死。當 Teddy 停止抓人來配對之後，也沒有人繼續嘗試。
• phase 3，強迫中獎 I：告訴團隊這個sprint所有開發工作都要以pair programming的方式進行。結果，成效很好但只維持兩個sprints。畢竟強制的方式無法持久。
• phase 4，無為而治：。從此不再特別強調，由團隊自己決定。經 Teddy 非正式估算大概只有10~20%左右的開發工作會採用pai programming。
  

說真的，到了這個階段 Teddy 已經沒輒也沒力了。Teddy 自己非常相信 pair programming 的 「藥效」， 但良藥苦口，團隊不肯安心按時服用，Teddy 也不能強迫 (難道真的是叔叔有練過，小朋友不肯學嗎？)。雖然在 retrospective meeting 經常會有人提出需要增加 pair programming 的時間，但神奇的是，等到真正領取工作的時候，又是各做各的比較多 (也許 retrospective meeting 缺少 action plan?)。

• phase 5，強迫中獎 II：以往在估算 tasks 的時候，團隊只估算一個人做這件 task 所需的時間。也許是這個因素，導致於一個 task 通常只由一個人完成。從上週開始，團隊在 sprint planning meeting 時，就大致決定哪些 tasks (約略 80%) 需要採用 pair programming ，將其所需時間乘2，並且在 tasks 上面寫一個 P 字 (不是維大力P)，提醒團隊這是一個經過大家同意，需要 pair programming 的工作 (而且已經分配兩倍的時間)。由於才實施一週，因此長期成效尚難斷定。不過目前感覺起來這是 Teddy 試過的幾種方法中比較好的。當然，決定採用這種方法之前，Teddy 還是循循善誘一番，且經過團隊同意才實施。

友藏內心獨白：什麼是「藍綠蜘蛛網」？