交換編程——結對編程的延伸實踐

2019-11-17 04:43:11

字體：大中小

來源：轉載

供稿：網友

　　在傳統的開發過程中，往往是一個人從一個模塊的需求開始，然后作分析、設計、編碼、單元測試，接著才會交給第二個人(專職測試人員)進行其他測試項目。這樣的開發過程會因為開發人員的變動而對項目的進展產生較大的影響，所以就有人提出項目中編碼人員的重要性遠比項目經理大。而同時，極限編程中的結對編程方式，對于開發人員人手嚴重不足的項目中，領導是不認可這種組織方式的，他們認為這會浪費很多的人力，一加一未必大于二?！　　敖Y對編程技術是一個非常簡單和直觀的概念：兩位程序員肩并肩地坐在同一臺電腦前合作完成同一個設計、同一個算法、同一段代碼或者同一組測試。與兩位程序員各自獨立工作相比.結對編程往往只需花費大約一半的時間就能編寫出質量更高的代碼，但是，人與人之間的合作不是一件簡單的事情——尤其當人們都早己習慣了獨自工作的時候。實施結對編程技術將給軟件項目的開發工作帶來好處，只是這些好處必須經過縝密的思考和計劃才能真正體現出來?！?引自《結對編程技術》，原名為《Pair PRogramming Illuminated》，作者為Laurie Williams, Robert Kessler)。下面我們分析一下結對編程的特點：　　·結對編程在很多項目中得到應用，也作為XP(極限編程)一個非常聞名的觀點和做法被很多人大為推崇。　　·結對編程是兩個人同時做同一件事情的一種方法。表現上會給人一種浪費一個開發人員的感覺，實質上這的確是可以提升效率的?！　⊥瑯拥倪@個做法，2002年我在上海進行的一個類ERP項目中用過一次，當時在我做完權限系統的全部功能后，和一個兄弟合作了一個模塊，我們兩個人只用了三四天時間，就完成了這個新的模塊的全部功能。相對于我們此前做的功能模塊來說，時間不到那些模塊開發時間的十分之一。但由于結對編程會讓人感覺到資源被浪費了一半，在2002年的一個項目中，我提出進行結對編程的時候被領導拒絕了。這件事以后，我就開始考慮如何才能降低這種表面的浪費，而又能讓大家交流起來，同時能提高團隊的穩定性?！　?STRONG>產生背景　　2002年我的項目組要做如下這樣的一個項目：　　這是電信MSS系統的核心業務系統部分，包括了規劃、設計、施工、驗收、財務、合同等多個重要環節和多個部門的業務。當時團隊開發人員數量較少，人員技能較為均衡，沒有水平超出其他人過多的技術人員。這個項目在最初評估的開發周期就是第一個版本在五個月內完成，整個項目至少要做上一年以上，而最后的實際情況是，這個項目隨著不斷的升級和調整一直開發了三年多。最初的開發團隊是十一個人，后來擴展到二十三個人，主要開發人員總數為十六個人，其中有四個人技術水平相對較高，另外的七個人技術水平相對較低但是也都有三年多的實際項目開發經驗，其中有三個是我2001年帶的三個應屆畢業生?！　∮捎陂_發團隊中沒有技術水平超出其他人很多的人員存在，因此技術方案的論證過程都是在大家的共同討論中制定下來的，只是在團隊整體控制上，當時我有相對較強的發言權。因此在權衡了整個項目的實際情況后，完成需求工作我就告訴弟兄們——第二階段設計模型的開發大家交換來做?！　傞_始很多弟兄不理解，因為相對而言我的開發經驗比其他人多了幾年，所以當時我說的一些話兄弟們還可以接受，于是我就直接要求大家按照我的計劃執行。在設計模型開發完成后，我再次要求大家進行交換。兩次交換完成后，保證了每一個模塊都有至少兩個人對其十分熟悉，一方面不會因為人員的變動造成團隊的不穩定(這一點考慮相對較少，因為當時的團隊合作時間比較長，大家彼此十分熟悉和了解)，另一方面保證每一個模塊的開發人員都能找到人進行討論，從而增加了團隊內的溝通，方便了協調工作的進行?！　∫虼嗽谀莻€團隊的開發過程中，我們經常是大呼小叫，無論走到哪里，都是十分熱鬧的場景。　　方法定義　　與結對編程類似，交換編程也是一個非常簡單和直觀的概念：兩位或者多位程序員輪流開發同一個軟件系統的同一個模塊的不同階段的任務。交換編程的方式更合適的說法應該是交換開發，這種方式不僅僅可以應用于軟件項目，也適合其他研究開發型項目。相對而言，這更是一種更輕易被人們接受的方法，在前文大家已經看到了它在實際項目中的事實，這里先分析一下它與結對編程的不同之處：　　·它仍然采用傳統的一人一機的開發方式，結對編程是兩人一機。　　·它在每個迭代間進行多人交換或者兩兩交換，結對編程沒有交換的概念?！　∷c傳統的編程方式之間的差別是在每個迭代間進行多人交換或者兩兩交換，而傳統編程沒有交換的概念?！　∵@里說明一下兩個概念：　　輪輪流交換：三個以上的程序員之間相互交換所開發的工件，不僅限于三個。例如：A1的開發內容交給A2，A2的交給A3，……，An的交給A1。這種方式稱為輪流?！　蓛山粨Q：兩個程序員之間相互交換所開發的工件。僅限于兩人之間?！　?STRONG>建議實施方式　　交換編程中的操作與其他過程有較大的差異，根據經驗，建議在軟件工程實施的各個階段按照如下的方式進行：　　·需求工程中，需求調研和需求分析進行輪流交換，輪流交換至少是三個以上的人進行互換，不是兩兩互換;　　·概要設計(分析模型)開發中，需求分析到概要設計也進行輪流交換;　　·具體設計(設計模型)開發中，概要設計到具體設計再進行一次輪流交換;　　·編碼實施啟動后，具體設計到編碼的交換采用兩兩交換，注重這個時候不再采用輪流交換了?！　≡谌探５拈_發方法下的交換編程應用方式如下圖：　　由于目前沒有進行實際數據的度量對比，本文也無法從量化的數據上來說明問題，只能通過一些具體的事實來進行說明和驗證：當時這個項目的模塊從7個擴展到了11個，人員數量從11人擴展到了23人，我們在七個月內滿足了南方11家省級電信公司和集團公司的基本業務需求，從2003年4月到2003年12月期間，基本完成了這些省公司版本的二次定制開發任務?！　≡诰幋a以前全部采用輪流交換的目的就是為了讓更多的人了解項目進展的全部內容，有利于增加團隊內的交流，使更多的人對項目所開發的內容熟悉，并能讓他們提出自己的觀點，也有利于使更多的人從更多的角度來研究某個系統模塊所需要實現的功能和用戶需要解決的實際問題，不會因為某個人的定式思維而出現理解偏差，從而造成對需求的理解不到位。
　　具體設計到編碼的交換采用兩兩交換，這是因為前期需求已經基本上都穩定下來了，這時候不需要對用戶需求進行更多方面的理解，只需要進行實施并進行純粹的編碼工作即可。此時做輪流交換就不存在任何意義了，相反只能影響開發進度?！　?STRONG>優劣勢分析　　這里所提到的優勢都是和具體的開發方法相關聯的，大部分是相對于XP方法中的結對編程，同時也會分析它與傳統開發方式間的優劣?！　￠_發時間“浪費”不明顯　　·表現　　這個開發時間“浪費”不明顯是相對于結對編程與傳統開發模式而言的，至少讓老板沒有感覺到人員分配方式帶來了人員的浪費。大家都知道，結對編程需要兩個人共用一臺計算機、一套鍵盤、做同一個故事，這樣的開發方式往往會給人感覺浪費了一個人，雖然事實上未必如此。但是假如哪個項目經理第一次甚至說前幾次這樣做，估計大多數老板都會表示反對的，因為他會感覺自己的技術人員只有一個人在做事情。同樣，在2006年的靈敏中國開發者大會上，ThoughtWorks的總經理也提到了這個問題，他的解釋是這樣的：當兩個人合作三個月以后，效率會超過兩個人單獨編程的效率!但請注重：這里有一個時間前提——三個月以后。　　三個月這個時間未必是真實確鑿的時間分界線，它只是一個模糊的大概的時間范疇，假如兩個人配合的好，也許只需要兩個多月，假如配合不好，也許需要四五個月的時間，或者更長的時間……。我相信這樣的說法連Martin也不會反對的。從這個時間界限上，大家可以看看國內公司的項目狀況，然后再繼續我們的討論。　　·分析　　項目情況：國內很少有時間限度較長的項目，大多數項目都是在三個月到半年時間內結束，有些甚至只有一個月。這樣的時間特性，將使得這個三個月的期限變成了一句空談，也就是說，當兩個人磨合好的時候，項目已經結束了。這時候，有人會說，下一個項目還可以繼續合作呀，好，那我們來看看國內項目團隊的人員變動情況，然后再繼續。　　人員情況：國內大多數的公司都處于一種為了謀生而存在的狀態下，有很多技術人員都有三五個月就跳槽的經歷。不僅僅是技術人員，往往公司也是這種狀態，很多公司就是為了某一個項目而建立的，老板在招聘技術人員的時候，都是往最低限壓低技術人員的工資，當一個技術人員對項目了解到一定程度的時候，這個時間往往是在三個月到半年時間之間。半年，或者一年，是一個人最輕易發生跳槽行為的時候，因為這個人了解了公司的實質情況，假如老板當時騙了人，那么這個人必然要離開公司;假如老板當時過分地壓低了他的收入，那么這時候這個技術人員就希望能夠獲得加薪等等，除此之外，還有很多很多其他的因素，都會給人帶來未知的行為。也可以說，國內很少有團隊成員能夠合作達到一年以上的時間。這樣的話，第一個項目磨合好了，第二個項目就是在考慮跳槽，第二個項目未結束人就走了，這是我們平時很常見的現象。　　這個時候做結對編程，效果就不會那么明顯，因為在人員相對成熟的時候，人的心理發生了較大的變化，工作的積極性和配合程度也遠遠不及剛剛進入公司的時候。那么結對編程在這樣的環境下還能進行下去嗎?估計不用分析就可以知道了。這時有人會說，假如配合不好，那就換人結對，不一定非要這兩個人結對。那這就要從項目組人數說起了?！　№椖拷M人數：在我所開發過的項目中，大概有不到一半的項目有十個人以上的開發團隊。最大的團隊開發人員是不到三十人，這二十多人還要分成幾個組，每個組也就五六個人而已。在這種情況下，結對的問題就出現了，在組內的你只能和這么三五個人結對，是不是都很輕易配合起來呢?這個事情很難說。配合不好怎么辦?換人?換項目?還是換公司?當然，假如配合了三個月還配合不好，站在公司的立場上，是肯定要考慮開除掉某人了，至少也要將他降薪或者調離這個項目組，因為公司承擔不起這么大的風險。項目經理更是在擔著風險，因為結對編程的事情老板本來就不太樂意看到，本來老板就有意見，而項目組假如發生了這樣配合力度很差的情況，項目經理的處境可能就非常危險了?！　【C合上面這三個方面的情況，我們可以得到如下的結論：　　結對編程在中國這些短小項目過多的情況下是不太適合的!結對編程其實更適合一些相對人員較為穩定的開發環境，否則，三個月的低效率配合時間會讓老板將項目經理的腦袋當球踢的。但是，結對編程還是有其好處的，比如，提高項目組的穩定性，當一個人離開后，另外一個人可以很快地將新人帶到位，項目組不會因為人員變動而發生較大的風險問題。同時，結對編程提高了程序員之間的交流，團結了項目組內成員，同時輕易形成人月神話中提到的膠凍團隊的效果。另外，在三個月后還是有效率提高的情況發生，的確能夠帶來很好的效益的?！　∵@時候，交換編程就帶來了很好的效果，一是沒有老板擔心的兩個人做一件事情的風險，同時增加了項目組內成員的溝通交流，也提高了團隊的穩定性。但如何提高團隊的穩定性?　　項目組穩定性提高　　·表現　　在我前面的例子中可以看到，一個模塊至少有三個人對他它很熟悉，因此在后面的開發過程中，無論哪個人發生變動，都不會影響這個團隊的穩定性，所有的任務都能夠很好的延續下來。每一個系統的模塊都會至少按照階段數量(不同的項目會有不同的開發周期，同時也就有不同數量的人會對這個模塊十分熟悉)分給不同的人來進行開發。假如和結對編程配合起來使用，則將會使得對同一個模塊了解的人數達到一般交換編程的兩倍人數?！　　し治觥　∮辛诉@樣的對每一個模塊都很熟悉的人員數量的存在，團隊的穩定性就會表現出來，任何一個人的變動或者少數人員的變動都不會對團隊和開發進度產生較大的影響。因為隨時都可以有其他人來接替這個發生變動的人的全部工作，也很輕易培養新人進入到團隊內來進行工作?！　「m合沒有絕對高手的團隊　　·表現　　當團隊內沒有絕對高手存在時，也就是說，系統的架構設計將是更多的人一同討論出來的，并在開發過程中不斷的修改和調整?！　　し治觥　]有絕對高手存在，系統架構設計就不能夠在系統進行分析設計前完成，而同時架構的不穩定，就無法更好地安排任務計劃和制定故事，這些都會影響到整個系統的開發進度和過程，同時，靈敏編程所倡導的很多做法就無法在這個大前提下來進行實施。　　國外能夠很好地采用靈敏的做法來實施項目的一個原因是，他們有很多有一二十年工作經驗的開發人員。這些人員的經驗積累是非常重要的，他們可以更好地在項目開始的前期對項目進行整體的控制和把握，同時做好項目計劃和制定好任務故事，而這一點在國內尤其是軟件公司中還不具備這個條件，因此，很多項目我們都處于的狀態類似于我前面所舉的電信項目的團隊情況，甚至情況比那個團隊還要差得多?！　?STRONG>團隊內交流增加　　·表現
　　前面已經提到,“因此在那個團隊的開發過程中，我們經常是大呼小叫，無論走到哪里，都是十分熱鬧的場景?！边@種頻繁的交流，無形中使得團隊的凝聚力提高，相互之間的關系和合作也都更為密切?！　　し治觥　〖偃缡且粋€人從頭到尾開發一個模塊，他就幾乎不需要和團隊內非治理人員進行交流，甚至在某些情況下他只需要和客戶做好溝通就足夠了。而這時候，即使進行了同行評審，這個技術人員也可能會認為兩三天的時間內這些人不可能了解這個系統模塊的內容。這種評審也就輕易流于形式而無法得到真正的重視。其他人也會認為評審是浪費自己的開發時間，于是到了一定程度評審就會成為可有可無的狀態。假如有較多的人參與了這個模塊的前后期分析和開發，每一個階段都可以找到別人來進行討論，在評審時對這些人提出的意見也就更輕易接受——因為他至少會認為這幾個人比他更早介入這個模塊的分析，在某些程度上會比自己了解的更為深入?！　?STRONG>唯一可能的劣勢　　·表現　　由于存在多人之間的交換，在某一個具體工件的開發的時間上會比一個程序員一直做下來略有延長。　　·分析　　由于在任何一次交換之間都需要前一階段開發者隊后一階段開發者進行關于業務和技術方面的溝通和交流，因此會延長項目在初期的開發時間。尤其當團隊成員相互之間的熟悉程度不夠或者配合不協調的時候，這個問題會表現得較為突出，甚至可能影響一些項目的進度以及開發工作的進展?！　〉牵@個影響會在相應的程度上促進團隊內人員之間更快地相互熟悉，這個周期要比結對編程短很多，一般來說，不會超過一個月的時間就可以讓團隊成員之間相互熟悉(由于不是坐在一起開發，這個熟悉的程度比結對編程的要求低很多，因此時間也相應會縮短很多)。　　深入討論　　交換編程的應用方式是有其適用環境的，另外在我的實踐和研究中還建議假如團隊合適，可以考慮與結對編程配合使用?！　∵m用環境：這種開發方法的適應性較強，這里分為團隊狀況和項目情況兩個部分進行一些說明?！　F隊狀況：交換編程適用于人數超過兩個人的開發團隊，因為交換一次至少也需要兩個開發人員。大的團隊也可以應用交換編程的方式，來進行項目開發。要求團隊內的成員有一兩個具有兩三年以上開發經驗的，這是對于一般的項目(哪怕沒有什么技術難度)的最基本要求?！　№椖壳闆r：項目規模不限，開發周期的適應性也較強，對于任何類型的項目都可以適用。　　與結對編程配合使用：假如領導比較認可結對編程的開發方式，這個時候，您引入交換編程也會帶來同樣的好處，比如團隊穩定性，至少從對系統業務模塊熟悉的人數上來看增加了一倍，以及團隊凝聚力，因為頻繁的交流，從而更多地降低因為少數人的思想和考慮偏差造成對用戶需求理解不足等問題?！　∮辛松鲜龅那闆r表現，也使得團隊的規范化操作能力更強，也可以使得很多問題能夠在有效的溝通中的到解決?！　∮纱丝梢?，交換編程的存在是有其道理的，沒有用過的朋友不妨嘗試一下，至少對您的團隊沒有什么傷害和大的變動。

上一篇：軟件與并發巨變不得不面對的革命

下一篇：免費午餐已經結束——軟件向并發靠攏