My mind to your mind. My thoughts to your thoughts...        -- Mr. Spock

　　什么是結對輔導

　　在前面的兩篇敏捷咨詢工具箱中，我分享了如何做讀書寫代碼活動和OO訓練營。認真的做好這兩項活動之后，團隊的開發設計能力會提升一個臺階。對于有經驗和有能力的團隊，他們可以直接把這些技術和思想直接應用到項目中。但有一些團隊還需要進一步的跟進。那我們如何進一步的跟進，保證大家能把這些技術應用到項目中呢？

　　這對一個敏捷咨詢顧問是一個很大的挑戰。在很多人眼里，顧問就是那些能說會道，把事情說得天花亂墜，但都是只會紙上談兵，站著說話不腰疼，為團隊帶來麻煩，卻不解決實際問題的人。我承認，顧問的好名聲就是曾經被這樣的人給敗壞了。那顧問如何才能深入團隊，解決他們的真正問題呢？答案是把顧問放到一個具體的項目團隊里面，為團隊成員提供結對輔導。那什么是結對輔導呢？

　　結對輔導來源于極限編程的一個開發實踐──結對編程：

“結對編程，就是兩個開發人員用一臺電腦一起編程。一個人操作鍵盤和鼠標，充當駕駛員的角色。另一個人在旁邊觀察和思考，提出建設性的意見，充當著領航員的角色。同時，兩個人會頻繁的進行角色互換。”

　　我們把這項實踐運用到咨詢中，我會去一個項目團隊，和大家一起工作，用結對的方式對團隊中不同角色的人進行輔導。我會和開發人員一起結對，指導他們如何做開發和設計;我會和業務分析師一起結對，指導他們如何做寫用戶故事，如何做需求分析;我會和項目的經理一起結對，指導他們如何管理項目和團隊，如何系統思考，如何主持各種會議等等。下面分享我是如何對開發人員進行結對輔導，指導他們在真實項目中進行TDD開發和設計。

　　如何輔導一名主開發人員做TDD開發和設計

　　我在一個客戶那里，結對輔導了一個主開發人員。我們一起用了三周時間，完成了一個完整的用管理功能模塊，這個功能大致分為6個左右的用戶故事。我們是在C語言的開發環境下，使用TDD的編程方式。下面將分享我是如何做的結對輔導。

　　梳理需求

　　在結對開發開始之前，我和她花了一天的時間，從下面幾個方面對需求進行了梳理：

• 以前是否有用戶管理功能，它的業務流程是什么樣的？
• 為什么要做一個新的用戶管理功能？
• 新的用戶管理流程會是什么樣的？
• 每個需求的內容是什么？它的功能范圍是什么？背后的價值是什么？
• 有哪些驗收用例，這些用例是否全面和具體？
• 測試人員如何驗收？這些需求是否可以端到端的進行完整測試？

　　通過這樣的提問和交流，我們完整的把這些需求梳理了一遍。同時也把遇到的一些不合理用戶故事做了重新劃分。

　　糾正錯誤的編程習慣

　　第二天，我們開始結對編程。剛開始結對的時候，發現她已經從別的地方拷貝了一堆代碼，修改了一些，可以編譯通過。她想在這碓代碼的基礎上開發，這也是典型的復制&粘貼式的開發方法。我們花了很長時間討論了這個問題。復制和粘貼是邪惡重復代碼產生的根源之一，這顯然是錯誤的編程方法和習慣。可是她卻習以為常，并不覺得有什么錯，按照她的話說：有現成的代碼，拷貝過來修改一下有什么錯。激烈的討論之后，最終以雙方的妥協和各自讓步達成了一致：

• 這些代碼是有價值的，它只是用來做Spike，驗證一些功能是否可以實現
• 但是Spike之后這些代碼需要扔掉的，作為妥協，她愿意把這些代碼全部注釋起來（舍不得這些破爛）
• 用TDD的方式寫代碼，先寫測試后寫代碼，沒有測試失敗就不要寫代碼，重構代碼除外

　　真正的TDD開發

　　我要求她使用TDD開發即測試驅動開發。先寫一個測試，運行測試失敗，然后再寫業務代碼。可是，她上來就反對：“費那事干嗎，一次把所有的測試都寫完了再寫實現代碼，這樣豈不是更快？”。我先是無語，然后便開始說服她，告訴她這叫小步前進，就是把復雜問題分解開，從最簡單問題的開始，一步一步的前進，這樣開發才有節奏，每一小步都會有反饋（測試失敗，實現業務代碼，測試通過），整個開發過程可控可駕馭。我苦口婆心說了半天，她還是堅持自己的意見。于是我問她：“你為什么要一次寫完所有的測試？”。她的回答讓我恍然過來：“因為我想到了很多測試場景，如果沒有寫下來，我擔心自己后面會忘掉”

　　啊哈！我終于搞明白了她的顧慮。這個好辦，我們拿了一張卡片，然后把想到的測試場景全部寫到卡片上。實現完一個小功能，就在上面做個標記。這樣在做TDD開發的時候，就可以專注寫一個測試，有了一個失敗測試之后，讓測試通過是壓倒一切的任務。這樣的開發過程很專注，思維不容易發散，任何時候想到了其它相關的問題，就及時的紀錄在卡片上，等后面再實現。

　　在我的嚴格要求之下，她開始了TDD方法，先寫一個測試再寫業務代碼。我的目標是把她培養出來，所以我們采取了是教練式的結對方法：我提出想法，她操作鍵盤和鼠標寫代碼（有時候我會為她寫一些測試代碼）。結對也是一個引導的過程，有了一個新的測試之后，第一步是要讓測試通過，這時不用去追求代碼的優雅，只要測試通過就可以了，然后我會提出代碼中的壞味道，和她一起討論，問是否有更好的方法？如何讓代碼更能表達業務意圖？如何在同一個層次上編程等等？引導她一步一步的進行重構。

　　下面這張圖是一步步用TDD方式產生的用戶登錄功能的測試用例：

　　就這樣，用了三周左右的時間，我們一起完成了這個功能模塊的開發。三個星期的結對下來，我也有了一些心得體會。

　　心得體會

• 在同一個經驗豐富的開發人員進行結對輔導的時候，前面會有一個挑戰的磨合期。因為他們一般都積累了自己的一套成功的編程方式和習慣，這樣導致他們對新的TDD開發和簡單設計有抵觸的情緒。這樣就需要顧問一步一步的引導說教，讓他們切實體會到新開發方法的好處。
• 結對輔導需要兩個人緊密的協作，剛開始肯定會有一些工作方法和習慣上的沖突。如果對方不認可敏捷的開發方法時，不要一味的說教，一定要先溝通和交流，詢問為什么不愿意這樣做，了解清楚對方的顧慮和擔憂之后，對癥下藥，提供一些實踐解決對方的顧慮。
• 有時候我們的建議遭到拒絕，往往并不因為是建議本身的問題，而是因為我們還沒有建立好信任和領導力。

　　關于作者

　　錢安川，ThoughtWorks公司高級軟件咨詢師、敏捷過程教練、資深講師、Team Leader、開發者、 BeiJing Open Party組織者和主持人。個人博客：敏捷開發訓練。

it知識庫：敏捷咨詢工具箱（三）──結對輔導，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。