Pair Programming 成本太高，嗎？

December 26 09:05~10:57


兩個禮拜前有人對 Teddy 說他們公司有採用 Scrum 但是他們不用 pair programming，因為 pair programming 『成本太高』。何謂成本太高？因為 pair programming 顧名思義就是『兩個人黏在一起開發軟體』，大部分的人直覺的想法便是：


原本一個人可以做的事情，用 pair programming 人力成本變成兩倍，所以『成本太高』，不划算


很久以前其實 Teddy 也有這樣的困擾，一直到三年半前採用 Scrum 並且實施 pair programming 的初期，在 Sprint Planning Meeting 估算做完一個 task 所需時間的時候，Teddy 都有類似的疑惑，例如：


一個 task 假設預估需要 5 小時做完，那麼這個 task 如果採用 pair programming，需要幾小時？


有三個可能的選項：

• 5 小時：不管多少人一起完成一個 task，反正原本估算多少小時可以完成就用原本估算的值。這個選項是否合理呢？假設團隊有 6 個全職投入的開發人員，一個 sprint 兩週，那麼這個團隊可以用來『燃燒的時間（可以投入的工時）』為：6 （人）* 10 （兩週 10 個工作天）* 5 （一天五個小時）= 300 小時。如果不管多少人一起完成該 task 都以花費 5 小時計算，那麼最後團隊可以投入的時間其實是『被高估了』，所以這個選項感覺不太合理（所有 task 的預估時間加總起來應該要接近團隊成員所可以貢獻到該 sprint 的時間，以這個例子而言總時間為 300 小時）。
• 2.5 小時：原本需要 5 小時，兩個人一起做所以只要 2.5 小時。聽起來好像很有道理，但是現在預估的工作是『程式設計』，不是『掃地』或是『刷油漆』。Teddy 的經驗上很少有工作因為 pair programming 的關係而比原先預估的時間還要提早 50% 以上可以完成的。所以，把原本預估時間除以二這個選項也排除了。
• 10 小時：一件『程式設計』的工作一個人做 5 個小時，兩個人需要 10 個小時（直接把時間乘以二），這是 Teddy 最後採用的方案。耶，這樣看起來不正是證實了『pair programming 成本太高』的批評嗎？請接著看下去。

先講結論，Teddy 的經驗是，只要有 task 是採用 pair programming 方式施工的，Teddy 都比較放心該 task 的施工品質。所以說，如果某個 sprint 絕大部分的 tasks 都是採用 pair programming，那麼依據 Teddy 的經驗 sprint 結束後的產出物品質都會比較好。所以只要看到團隊成員都在『配對做事』，Teddy 就會很放心。反倒是如果某個 sprint 團隊成員都在『各作各的』，這樣好像看起來每個人都很忙，但是經驗告訴 Teddy 最後的產出物相對來講品質會比較差。

看到這邊鄉民們可以能會說，Teddy 你用『兩倍的成本（pair programming）』來做『一半的事情』所以產出物的品質當然會比較好啊。

上面這個問題很好，但是反過來思考，假設我們對於品質的要求是固定的（我們要求好的品質），再假設 pair programming 可以達到我們對於品質的要求，那麼這樣是不是意味著『原本的施工方式（不採用 pair programming）』有一些該做的 tasks 被隱藏起來了？

***

那麼那些該做的 tasks 被隱藏起來了？

• 設計：當一人獨自設計程式的時候（包含 coding），經常會出現一些『自己看不到的盲點』，這些盲點小至可能耽誤你幾分鐘的時間去發現，大到可以埋入一個不容易被發現的 bug。另外，有時候一個人設計程式做的很累的時候，可能會取巧只要讓『程式可以動』就好，所以所寫出來的程式其實是不容易閱讀與維護。有時候因為自己能力不足的關係也可能做出不易閱讀與維護的程式。這些都是增加日後開發的成本，但是這些成本卻都被隱藏在『程式可以動啊』的大帽子下面（請記住 all programming is maintenance programming 這個道理）。
• 測試：和設計問題很像，一個人寫程式（此人也被要求要寫單元測試）假設程式已經可以動了，此時腦袋可能已經有點累了，所以會有一種想要休息的欲望，導致有時候無法把單元測試寫得很完整。也有可能是自己的盲點導致漏寫了某些單元測試。同樣的，不足夠的單元測試除了可能少抓到一些 bugs 以外，還會增加做 refactoring 的困難度與風險。這些被隱藏的工作也都會增加日後開發的成本。
• Review：不管是 design review 或是 code review 都是找出設計或是程式問題的有效方法。Pair programming 有一個很重要的精神就是『隨時隨地都在 review』。這些 review 的工作在很多團隊中其實是被忽略了。
• 除錯：很多時候寫程式可能只花了 1 小時『就寫好了』，但是除錯（debug）可能花了一整天（8 小時）甚至更久。在 pair programming 的模式之下通常發生這種狀況的機率會比較低一點。
• 派工（分工並合作）：採用 Scrum 或是任何軟體開發方法，當需求被細分為 tasks（施工項目）的時候，接下來就要思考工作分派的問題。傳統單人施工模式，很容易造成每個人對自己所做的工作（或是分配到的程式模組）很熟，但是對於其他人在做什麼卻完全不知。這個現象其實是一個很嚴重的問題，但是大部份的時候都被隱藏起來了，直到有人請假，或是更慘的，有人離職，問題才凸顯出來。Pair programming 可以讓開發經驗在團隊成員彼此分享，尤其是如果配對開發的對象經常性的輪替交換，那麼久而久之團隊成員就比較有能力可以修改『其他人所寫得程式』。更好的狀況是，最後團隊達到 shared code 的境界。

***

扯了這麼多，Teddy 要再強調一次，以上說明都基於某個假設，這個假設要成立 pair programming 才有意義，什麼假設，就是：

軟體的品質是重要的

如果鄉民們的公司或是專案強調的是寫出看起來可以動的程式就好，先把客戶的錢 騙 收進來其他事情以後再說。亦或是公司文化要求比賽誰留在公司的時間比較長，誰比較晚下班而不是誰工作效率與績效比較好，那麼請忘記 Teddy 剛剛所說得一切，並且立即將腦袋運作模式切換為『派大星』模式，謝謝。

***

Pair programming『看起來』花費兩倍的時間，但實際上節省去了後續很多開發與維護的成本，從專案的『總成本』這個角度來看，還是非常非常值得一試的方法。

***

友藏內心獨白：今天的功課提早做完了。