「結對編程」令專案走慢了？ 其實跑得更快！
前言
關於「結對編程」，我相信不少人對這個名稱不會陌生。一些人對它欣賞有加，一些人對它充滿懷疑，也有一些人對它敬而遠之。從不同方法得知，不少人都有對它以下的解讀：
結對編程要安排兩位人員做同一件事，令資源有所增加。
結對編程只適合新人使用。
結對編程會減慢進度。
結對編程只適合除錯，不適合其他用途。
有不同的理解，是因為「它」是從實踐中啓發出來，不是從理論中發掘出來的。
或者，你有其他原因使用或不使用結對編程。就讓我用某次的經歷，讓大家了解它是怎麼幫我推進專案和使開發人員怎麼在短時間內得到高度的協調性。
基礎了解
一說到結對編程，大家立刻便會想到「兩個人一起編寫程式」。對！就是兩個人「一起」做！聽起來很奇怪。但是，這卻是結對編程成功的最重要因素！一個人本來也做得到，為什麼要「兩個人」呢？在回答此問題之前，大家有否想過有什麼事情是必須兩個人做的？
沒錯，雖然在疫情下我們少了使用商用民航機，但是此交通工具，都必需由二位機師負責駕駛。如果更大一些，甚至要三位機師同時在場才可以起飛。在快速又複雜（Complex）的環境中，這不單是安全考量，還有更多的好處：
分擔工作：一位專心駕駛，一位專心儀表板和聯絡。
避免漏掉重要資訊：兩對眼總比一對眼更容易發現異常。
更少的準備時間。
同樣，如果我們使用結對編程，我們也可以得到同樣的好處：
分擔工作：一位專心把需求變成程式碼，一位專心留意需求理解的一致性和完成度。
避免漏掉重要資訊：兩對眼一起望著需求資訊和程式碼，避免無謂錯誤，導致要重新檢視。
更少的準備時間：不需要先完全理解需求，一邊閱讀和理解，一邊編寫和測試。有問題，立刻提出。如果兩人都解答不了，可以立刻找相關人仕詢問。
同時，我們一般都低估了編寫程式的難度。我們在估算的時候，我們往往只用需求所寫的去做估算。但事實上，程式編寫員需要運用其自身的經驗去評估哪一個做法更適合，把程式架構起來。還有，當做了專案一段時間後，程式已夾雜了不同人的代碼。在上千個變數中，怎麼知道用哪一個更適合呢？對其他部份的了解便變得異常重要。然而，經驗和知識的交流，不是隻言片語便可以完全處理，還需要實戰操作。「結對編程」便是在快速開發下，一個非常實用的方法。
以下，便是本人在以前專案中曾使用的方法。此方法是在就讀碩士時學到的，十分實用。
【專案背景】
當時，剛剛開始一個保險行業的專案。雖然客戶很簡單地道出要把原有的網站重新設計，但就像一般專案一樣，剛開始的需求都是非常不清晰。客戶只能道出大概的範圍，不能說出更仔細的內容。因為對他們來說，他們也不知道甚麼東西有助開發。
所以，專案經理和開發團隊同時做兩件事。專案經理和UX設計師先設計最重要的流程，和客戶取得外觀和基本流程的一致理解。同時，我和開發團隊（3人）先決定開發工具和建立開發平台的基礎。一段時間後，和客戶（包括業務和IT）取得基本共識後，便開始進行開發。此時，開發團隊人數卻瞬間增至10人。新的開發人員很多都時剛剛從別的公司請回來，他們的經驗和對開發工具的熟悉程度完全不一致。而且，他們對專案的行業更是陌生。
經過2次Scrum Sprint（2週），我們發現在開發工具、商業知識和測試上，都有不同的問題。但有趣的是，他們每個人的難處都不太相同。所以，我決定以「結對編程」去幫助他們。
【實驗過程】
這是此次實驗的配置：
人員：所有開發團隊成員，包括前端、後端、QA和BA。
時長：1個Sprint（1週）
角色：
1 位駕駛者(Driver)：不停告訴觀察者你在做什麼。
1 位觀察者(Observer)：每當對駕駛者所作的任何事有疑問或其他意見，便要立刻提出。
流程：
在 Sprint Planning 之後，大家都已經拿到自己要做的工作(Task)。
開發團隊成員自由組合，兩人一組，一起完成兩人手上的工作。
每天可以選擇和不同人組合，但一天的組合，在決定後便不能更改。
第一節，先選擇誰做駕駛者，另一位做觀察者。
每節時間不超過 30 分鐘，然後交換角色。
每節完結前，先完成簡單記錄。
每節完結之後，可以隨意小休。
準時午飯、準時放工。
記錄表樣板：
節數 | 駕駛者 | 開始時間 | 完結時間 | 處理檔案 | 意見 |
|---|---|---|---|---|---|
1 | A | 2021-10-15 10:00 | 2021-10-15 10:30 | A.docx B.class |
（回答以上3條問題） |
2 | B | 2021-10-15 10:35 | 2021-10-15 11:00 | A.docx C.class | |
每天結束前，回顧一下當天的經歷：
如果今天只有你一個人做這些事，你會認為你可以： 1. 更早完成； 2. 同樣時間完成； 3. 需要更多時間完成。
你今天學到什麼？
【實驗結果】
完成了一個Sprint之後，總匯了一下所有人的意見如下：
90%以上的小節，駕駛者都是滿意的。剩下的原因，主要是因為想完成更多導致超時和很多共識還沒有建立。
70%以上的小節，駕駛者認為夥伴有給與有用的意見，幫助工作完成得更好。
95%以上的小節，駕駛者認為兩個人做更容易。主要原因是觀察者幫助他們討論和了解更多，讓他做的事更有效率。
所有人都認為，如果一個人做這些事，是不會更早完成。
另外，他們也有記錄了一些有趣的想法：
雖然他和夥伴不是在做同一種類的事情（前端、後端、QA和BA），但是藉著此活動，他們更加深入了解其他角色是怎樣幫助自己的工作做得更好。
如果是前、後端的開發人員，他們會嘗試一同開發前端或後端的工作，不分自己原有崗位。同樣情況出現在QA和BA的組合。
完成了一個Sprint之後，他們可以隨意決定是否繼續此活動。再過多一個Sprint之後，我發現以下事情：
他們有時會自己結對起來。
他們對自己更有自信，每當其他人想了解他們的做法時，他們會給出很好的理由。
沒有人再說自己對開發工具不熟悉。他們有能力自己處理更多在開發上的疑難。
品質明顯改善不少，而且全部人的品質穩定。
後記
雖然此實驗中任何一組的兩位同事，不一定長時間做同一件事，但也發現了「結對編程」變奏版的可能性。同時，也顯示出「結對」工作的重要性。「單打獨鬥」當然易於管理和方便能力評估。但是，「人」的複雜特質，卻不是算術中的1＋1＝2。
另外，敏捷界經常說要「T」型人才，但我經常聽說這是「不可能」。其實，問題是企業是否願意創造空間給員工變成「可能」。因為執行專案不是單純的繁複（Complicated）公式，是專案團隊的創意傑作。
無論如何，「結對編程」不單是一個品質提昇的方法，它更是創造交流環境和讓員工全面進步的一個實踐。
文章同步刊登於：專案經理雜誌60期