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

　　什么是結(jié)對輔導(dǎo)

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

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

　　結(jié)對輔導(dǎo)來源于極限編程的一個開發(fā)實踐──結(jié)對編程：

“結(jié)對編程，就是兩個開發(fā)人員用一臺電腦一起編程。一個人操作鍵盤和鼠標(biāo)，充當(dāng)駕駛員的角色。另一個人在旁邊觀察和思考，提出建設(shè)性的意見，充當(dāng)著領(lǐng)航員的角色。同時，兩個人會頻繁的進(jìn)行角色互換。”

　　我們把這項實踐運用到咨詢中，我會去一個項目團隊，和大家一起工作，用結(jié)對的方式對團隊中不同角色的人進(jìn)行輔導(dǎo)。我會和開發(fā)人員一起結(jié)對，指導(dǎo)他們?nèi)绾巫鲩_發(fā)和設(shè)計;我會和業(yè)務(wù)分析師一起結(jié)對，指導(dǎo)他們?nèi)绾巫鰧懹脩艄适拢绾巫鲂枨蠓治?我會和項目的經(jīng)理一起結(jié)對，指導(dǎo)他們?nèi)绾喂芾眄椖亢蛨F隊，如何系統(tǒng)思考，如何主持各種會議等等。下面分享我是如何對開發(fā)人員進(jìn)行結(jié)對輔導(dǎo)，指導(dǎo)他們在真實項目中進(jìn)行TDD開發(fā)和設(shè)計。

　　如何輔導(dǎo)一名主開發(fā)人員做TDD開發(fā)和設(shè)計

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

　　梳理需求

　　在結(jié)對開發(fā)開始之前，我和她花了一天的時間，從下面幾個方面對需求進(jìn)行了梳理：

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

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

　　糾正錯誤的編程習(xí)慣

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

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

　　真正的TDD開發(fā)

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

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

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

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

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

　　心得體會

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

　　關(guān)于作者

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

it知識庫：敏捷咨詢工具箱（三）──結(jié)對輔導(dǎo)，轉(zhuǎn)載需保留來源！

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