前面講了一些好的、一些挑戰，但還有一些是『看起來不太適合但實際上正適合』結對去處理的。當然最重要的問題是，透過結對我們可以帶給團隊什麼，這真的值得投資嗎？
我們就先來看一些『看起來不太適合但實際上正適合』的情境：
無聊的任務 Boring Tasks
什麼是無聊的任務？可能改些翻譯字串、幫忙做些資料的撈取、創建帳號、相似功能的建立之類。這些事情通常是一些瑣碎且大家都知道的動作，沒有知識可以分享，因此似乎沒有什麼結對的討論價值？
我們再想一下結對的目標之一：提升團隊產出。而這些無聊的任務都可能影響團隊產出，一個人花費時間在無聊任務上，可能會覺得還好甚至是一個放鬆時間。但當兩人在處理這種任務時可能就會開始思考：我們真的沒更好更有效率的方式可以處理眼前的無聊任務嗎？
通常無聊的任務代表了可能需要改善的空間，資料的撈取為什麼要工程師來撈？資料的需求者有辦法自己取得嗎？為什麼每次新功能同樣的 CRUD 頁面都要重新寫一次？有沒有更好的方式？大家越習以為常但會佔掉許多時間的，往往就是可以優化的地方。有個理論叫做零/一/無限原則提到，合理的事件發生次數為：永遠不會發生 / 發生一次 / 發生無限次。無聊的任務常常就是那個『無限次』，而我們想提升軟體品質，就是要把會發生無限次的事限縮在只需要發生一次。
我真的可以嗎？ Could I Really Do This By Myself?
快速的讓新手進入狀況是結對的優點之一，但若處理得不好可能會造成新手的依賴、無法自主，或是失去一些自己嘗試錯誤、體驗跌倒再爬起來的機會，而這些，都是我們成長所需。試想，靠著自己解決一個難題，以及老司機帶你一起解任務，哪個你會學到比較多，又哪個會比較印象深刻呢？
這當然不是說老司機沒用，而是老司機在『引導』新成員時應該更加注意，可能常常需要退一步讓新成員有空間去嘗試與學習，並指引出合理的學習方向。切忌把鍵盤搶過來就開始自己做，這樣子雙方可能都不太容易成長。引出合理方向其實是老司機必要的修煉，必須要有足夠的基礎才有辦法看到那個正確的方向。
記得，讓子彈飛一會兒。
程式碼審查與結對 Code Review vs. Pairing
The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you.
— Jeff Atwood
如果用提升軟體品質的角度去看，也許會得到『多做程式碼審查』這個結論。
但實際上，在程式碼審查的效率上，結對是好很多的。有什麼會比有個人在你寫程式時直接給你反饋來得即時？而且你還可以即時的跟他討論合適的做法。
除了即時性的差異之外，當程式碼提交之後再做程式碼審查，我們並不知道這個審查何時會完成，時間拖得越久，腦中的思緒就遺忘的越多，要再回來修改就需要耗費更多的精力。相較於結對，這樣的非同步也會使得中間會有一些資訊的落差，提交者覺得有些事情審查者會幫忙看顧，而審查者可能相信提交者會好好的處理。再者，提交之後的心理狀態會改變為：這是一個已經完成的任務，這種狀況下要回去修改也是更為耗力，也就是所謂的『沈沒成本』。
程式碼審查需要審查者 context switch ，轉換到這個任務的狀態下，尤其是越大的功能審查，無法一次審查完的，就需要多次的 context switch。也因此審查常常變成部署前的瓶頸。
2017 edition of the “State of Devops Report” 裡面有提到，持續整合是比較有效率的整合與發佈模式，但這仰賴著高頻率的整合與節制（小於三）的分支數量。高頻率的整合情況下，程式碼審查將大幅影響整合速度，因此相較之下結對可能是更為合適的做法，能保證完成的功能至少有一個人認可。
https://medium.com/哈嘍-世界/團隊的-git-分支管理策略-3-持續整合以及相關比較-59b80a29c997
在這情況下，我們可以考慮以結對當作即時審查的工具，但如果有些特殊或重大情況仍然可以使用 PR / 程式碼審查來處理。
結對不只是結對 But really, why bother?
講了許多好的、挑戰的，當然也有許多做不到的。其實結對需求講起來很簡單，做起來很困難：簡而言之就是精確的溝通與執行能力。說到底，這是一個團隊成員都應該具備的基本能力：專注、任務管理、時間管理、溝通、反饋、同理、信任。這也與結對的本質有關，因為結對只有兩個人的團隊，也因此結對實際上就是兩個人訓練團隊協作能力的好時機。
Pairing unlocks the potential of individuals and teams to learn.
現今社會強調『多元化』『多樣性』，有時卻輕視甚至忽略多元化可能帶來的摩擦，這樣的摩擦也是結對所需要面臨的挑戰。但摩擦也有可能是好事，會讓團隊比較警覺，比如說當團隊內都是前端工程師出身的資工背景台灣人時，自然會有一種很厚的同溫層，工作氣氛也許會很愉快，但卻可能鬆懈，因為一切都太熟悉。如果加入了一個設計師轉職的工程師，可能就會開始有許多討論，也會被迫開始面對一些不是那麼好的積習，這也是 Harvard Business Review 的研究發現。
結對也有類似的效果，當你在自己的同溫層，以及有人來一起討論時，想法的深度與廣度可能會有很大的不同。這意味著結對常常需要燒腦，但這就是我們需要的，合適的摩擦與衝突才有辦法激盪出更多想法，以及激勵我們去實踐他們。這也代表我們應該用正確的心態去面對摩擦，甚至建立一套方法來面對及處理，而結對其實就是其中一種工具。
如果你正在思考如何建構更穩固的團隊，也可以看看我們團隊的開箱心得文
