l

2009年11月17日 星期二

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 還是循循善誘一番,且經過團隊同意才實施。

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

7 則留言:

  1. 熟手配生手不會有反效果嗎?
    我覺得竹門對竹門木門對木門,兩個實力相當的才能發揮pair programming 的功效,否則就是雞同鴨講。
    但是我同意生手以旁觀者的身份觀察熟手coding會學到很多(前提是不要打斷別人coding)。

    回覆刪除
    回覆
    1. 熟手配生手的主要目的在於知識傳承與分享,不見得是追求立即的生產速度。雙方還是應該要互動,如果生手光是看,不能說話(你所說的「打斷別人coding」),效果會打折。

      刪除
  2. 有些工程師就是偏愛獨立作業, 不喜歡(或是不習慣)成雙配對, 怎辦? 不將這類人編入pair programming嗎?

    回覆刪除
  3. 個人對 pair programming 的成效感到非常良好, 幾點看法:

    1. 未必需要所有的時間都這麼做, 可與自獨立作業方式兼容並進. 更多的時候它可以隨機發生. 只要兩人比鄰而坐, 平時亦可分別作業, 但無論其中之一是完成了獨自的工作或是卡住了, 這時候若另一方正在作業, 只要雙方覺得妥當, 亦不妨即興進行.

    2. 未必需要強迫使用同一台機器, 而是強調同心協力; navigator 若手邊有電腦亦可經由網路即時收集知識提供給 driver, 但不宜因此分心或中斷. 重點在於共同達成目標的熱情, 而不是袖手旁觀的心理.

    3. 不刻意強調進行時間的長度, 但不建議將時間拉的過長. 每次 10 分鐘不嫌短, 一小時之中也雙方可交互進行幾次, 並做角色的對換.

    4. 老手生手搭配也不要緊, 重點在於敞開心胸與屏除成見. 生手往往有些天真的想法, 可以激發老手的靈感; 老手所具備的經驗若能重點式的讓新手快速複製, 相得益彰. 人總有盲點, 很多知識你有, 但有時候某接癥結上你可能沒發現或者剛好沒想到, 先前別人從你身上學到的, 回過頭來也許也幫到了自己.

    5. 程式碼行數多寡的衡量從來不是一概而論的事情. 無論是大量的程式碼只做了少少的事情, 或者超複雜的事情寫成過度精簡的程式碼, 兩者都未必是好現象. 兩個人共同完成的程式碼, 至少兩個人同時思考過, 也同時了解了這段程式在做什麼, 為什麼這麼寫; 等於在撰寫期間已經進行了一次 peer review, 對於程式碼組成的 "平衡感" 應該多少有幫助.

    6. 總歸 pair programming 最重要的莫過於積極良好與平等的溝通, 應放下個人主義, 拿出熱情, 共創 "雙腦合一" 的境界, 將會收到非常好的效果.

    以上根據個人經驗之拙見 ..

    回覆刪除
  4. 藍綠蜘蛛網 不就 Ingress ..

    回覆刪除
  5. 個人對 pair programming 的成效感到非常良好, 幾點看法:

    1. 未必需要所有的時間都這麼做, 可與獨立作業方式兼容並進. 更多的時候它可以隨機發生. 只要兩人比鄰而坐, 平時亦可分別作業, 但無論其中之一是完成了獨自的工作或是卡住了, 這時候若另一方正在作業, 只要雙方覺得妥當, 亦不妨即興進行.

    2. 未必需要強迫使用同一台機器, 而是強調同心協力; navigator 若手邊有電腦亦可經由網路即時收集知識提供給 driver, 但不宜因此分心或中斷. 重點在於共同達成目標的熱情, 而不是袖手旁觀的心理.

    3. 不刻意強調進行時間的長度, 但不建議將時間拉的過長. 每次 10 分鐘不嫌短, 一小時之中也雙方可交互進行幾次, 並做角色的對換.

    4. 老手生手搭配也不要緊, 重點在於敞開心胸與屏除成見. 生手往往有些天真的想法, 可以激發老手的靈感; 老手所具備的經驗若能重點式的讓新手快速複製, 相得益彰. 人總有盲點, 很多知識你有, 但有時候某接癥結上你可能沒發現或者剛好沒想到, 先前別人從你身上學到的, 回過頭來也許也幫到了自己.

    5. 程式碼行數多寡的衡量從來不是一概而論的事情. 無論是大量的程式碼只做了少少的事情, 或者超複雜的事情寫成過度精簡的程式碼, 兩者都未必是好現象. 兩個人共同完成的程式碼, 至少兩個人同時思考過, 也同時了解了這段程式在做什麼, 為什麼這麼寫; 等於在撰寫期間已經進行了一次 peer review, 對於程式碼組成的 "平衡感" 應該多少有幫助.

    6. 總歸 pair programming 最重要的莫過於積極良好與平等的溝通, 應放下個人主義, 拿出熱情, 共創 "雙腦合一" 的境界, 將會收到非常好的效果.

    以上根據個人經驗之拙見 ..

    回覆刪除