傳說中的結對編程，大致結構是兩個人共用一臺電腦，一個開發，一個測試，以隨時評審來抵消返工時間損失。

　　傳說歸傳說，誰也沒有見過。問題出在哪里？有兩種主要原因。

　　一是來自高層的，高層感覺兩個人只有一個人干活，實在是有點浪費。“評審抵消返工時間”虛無縹緲，但每天只有一個人干活卻是現實情況。

　　二是來自基層的，兩人若有高低，高手肯定覺得還不如我一個人干的快；兩人若旗鼓相當，難免產生爭執。

　　其實在我們身邊一直有一種方法很像結對編程：“師徒制度”，就是每個新人來到公司，都指派一個師傅帶著，在技術與業務方面提供指導。他們既不用一臺電腦，也不是老死不相往來，這其實就是一種“松散”的結對編程。只不過多數企業雖然有這種制度或實踐，但卻很少有很清晰的定義，難免限制了這種實踐的效果。本系列的目標，就是從人員結構、計劃實踐、日常工作實踐、績效考核等各個角度，來完整地思考和建立這種制度。

　　挑選小組長（師傅）基本原則

　　樂于助人，有責任心，善于溝通，擅長管理，技術精湛，業務精通……很可惜，好詞匯越多，越難找到符合的人。不過，一些基本原則還是要考慮的：

　　1. 盡量找對業務有興趣的人

　　整體上偏業務的人未來有更好的發展（這是我2001年的上司的原話，事實證明很對），由于有行業壁壘也較少跳槽。由于小組長角色未來將被提拔為更高的項目經理、產品經理，對業務的了解也會為此做好鋪墊。

　　2. 盡量找善于溝通的人

　　善于溝通的程序員成長更快（還是那位上司的原話），也更能幫助別人成長。

　　挑選組員（徒弟）基本原則

　　1. 徒弟能力一定要低于師傅（應該說：師傅一定要高于徒弟）

　　很常見的一種做法是把幾個水平相當的人放在一起工作，認為這樣他們可以互相學習，其實不然。

　　之前我們在的項目組經常發生技術“爭論”，發生的次數多了，我們發現一個規律：每次爭執不下的，都是兩個技術相當的人，而每次爭執的解決，都是一個水平更高的人給出一個截斷眾流的方案，然后大家散去。

　　2. 徒弟年齡不要太大

　　如果有兩個水平相當、月薪要求都是6000的程序員，當然找年輕的了，有發展潛力，后勁足。

　　挑選組長（大項目經理）基本原則

　　1. 項目經理必須喜歡業務勝過技術

　　項目經理是掌舵的而不是干活的，因此必須對業務有深刻理解。

　　2. 項目經理最好精通技術

　　這里不討論是否存在“不懂技術卻精通管理”的項目經理，但是如果目標是項目成功而非證明奇跡的確存在，項目經理應該首選那些從小組長成長起來的既懂業務技術又精湛的人選。

　　這里的“精通技術”不是從技術實現層面考慮的，而是從“技術想象力”層面考慮的，就是說他必須能想象到有某種技術存在。比如以前我們遇到一個程序員寫了一大堆重復代碼，原因就在于他的想象力受到了局限，明明有虛函數、模板等各種方法來簡化代碼，卻沒有想到。“沒有學到”是無法避免的現實情況，但“沒有想到”是可以避免的。

　　團隊結構和運行理念

　　既然待在某個“位置”上，每個人必有不同的職責。這里就不一一列出了，因為猜都猜得出來（比如師傅要帶徒弟之類）。下面只列出松結對編程與一般小組的核心差異。

　　1. 對每個小組（師傅+1～3個徒弟）整體考核

　　也就是師傅要負責到底，不能出現“他剛來所以把事情辦砸了”的情況。這里的負責到底，包括計劃、估算、跟進、進度、質量、徒弟成長……等一干事情，本系列的其他文章中都將展開描述。

　　2. 在工作中學習

　　盡管“松”，但還是“結對編程”，學習和指導過程實在生產過程中集成的，因此師徒關系的成敗不只是人員成長，還包括任務和項目的成敗。這首先是一個生產團隊，其次才是學習團隊。

　　新人其實很少偷懶，因為一方面正處于入門學習的高峰期，另一方面工作時間不長，需要得到企業和團隊的認可。可為何他們工作總是不得力呢？

　　新人的真正問題在于無心辦錯事和好心辦錯事。

　　無心辦錯事包括沒學過某種好的方法、不知道企業已經有某些可用代碼或庫、不懂業務等種種問題。

　　好心辦錯事包括想做一個比領導想想的更好的功能、過度思考了可復用性可維護性等。

　　這兩個問題筆者都經歷過（作為新人和老人），“避免”是最好的方法，而不是事后改正，這就需要在設計階段和計劃階段從技術、管理兩個方面來提前預防。

　　技術：輕量級設計

　　如果要把一個任務分配給一個“不放心的人”，有兩種辦法保證成功：師傅把設計做出來交給徒弟做，但是“設計文檔”的詳細程度很難把握，寫少了做不出來，寫多了等做出來了很多內容又多余了；師傅徒弟結對編程，但是很占用師傅的時間，尤其是倘若徒弟“實際上”（可惜只有上帝知道）完全可以勝任這個任務。

　　有兩種解決方法。

　　1. 事前輕量級設計：預想陳述（有點隱喻的意思）

　　預想陳述是微軟很久以前就使用的一種方法，任何人（不只是徒弟）有什么設計，不用寫下來因為太費時間了而且還可能被拋棄，而是給大家講一下。大家會給出評價和意見，以保證其正確性。然后此人就按這種方法去實現了，倘若成功了也被認可了，就簡單寫下來以供日后參考使用。由于系統已經存在，這個簡單寫下來的設計可以真的很簡單。

　　在“松結對編程”里邊，有兩種類似的做法。

　　一種是師傅把自己的想法告訴徒弟（一般用一個白板，或一張白紙），徒弟提問師傅回答，到差不多為止。

　　二種相反，徒弟講給師傅聽，師傅師傅質疑和指導，到差不多為止。

　　兩者都不要事先形成永久文檔，但都在被證明可行（就是編碼完成后）寫一個簡單文檔記錄。任何代碼之外的能幫助理解當時做法的文字/圖片都可以稱為文檔，沒有字數限制。如果能和用戶故事放在一起則更好，一個描述做了什么，一個描述怎么做的。

　　2. 前檢查點

　　就是在某事開始的時候進行臨時結對編程。一般發生在某個功能剛開始做的時候，詳情會在之后的“日常活動篇”做詳細描述。

　　管理：共同計劃（共同估算，撲克牌估算）

　　預想陳述、前檢查點雖然已經很輕量級了，但是如果師傅和徒弟都剛剛對需求（用戶故事）有所了解，還給不出很清晰的思路的時候，比如在Scrum計劃會上，怎樣快速知道徒弟有沒有理解需求，有沒有大致的實現思路呢？那就是共同估算（撲克牌估算是共同估算的一種最好的實現形式）。

　　1. 共同估算

　　共同估算的原理和做法還是很復雜的，這里只簡單說說，以后會有文章詳細講述。

　　共同估算就是師傅和徒弟基于相同的信息（一般是在計劃會上聽PO講完故事的時候），一起說出自己認為做完這件事情需要多久。基本原理是：若兩個人對某件事情的工期認識是相同的，那么他們的實現方法不分高下，用哪種方法都差不多。

　　為了防止人云亦云，一般需要采用匿名方法，而撲克牌估算就實現了高效有效的共同匿名估算（另有文章詳述）。

　　2. 驗收標準

　　為了基于相同的目標建立共同估算，也為了防止需求鍍金或最終軟件不能滿足需求，師傅和徒弟要建立對需求的共同理解。

　　簡單方法就是兩者（其實是師傅和多個徒弟）一起參加估算會，一起聽PO講解故事。但最好是在此之后，建立一個“文檔化”的驗收標準。比如在一張故事卡/Excel表里……上寫上“需集成；無性能要求……”等最簡單的描述（請參考本博客的敏捷開發分類下一片關于驗收標準的文章）。

　　共同估算+驗收標準，使得師傅和徒弟（推廣為高手和新手）使用大致相同的方法，做大致相同的東西。共同估算既是一個工作的過程，也是一個學習的過程，因為在理解做什么和怎么做的同時，徒弟也向師傅學到了東西。

　　估算是經久不衰的管理話題，大致分為兩種流派。

　　第一種是領導指派，領導說這是10天的活，就必須當是10天的活來干，如果干不完，可以用加班、損失質量、功能縮水等各種方法曲線救場。另一個變種是大家自己估算，但是交給領導審批；領導審批其實就是砍一半的過程，還好大家之前就已經加了一倍，所以不怕。

　　第二種是自我管理派（偏敏捷），就是由具體開發的人員自己說開發工作量，領導和他人不干預。盡管“自組織”了，但是領導深以為這種方法留下了偷懶的種子，而隊員也覺得某人的估算很不靠譜（太長或太短），到底怎么辦呢？共同估算吧。

　　基本概念

　　假設現在是一個計劃會上，PO（產品經理，策劃組長，項目經理，某銷售……）剛剛講完需求，下一步不是交給某人做估算，而是交給某個潛在的組（師傅+1～3徒弟）。

　　由師傅帶頭打牌，對，在計劃會上玩撲克：

　　1. 大家各自思考可能要花多久時間完成任務，扣一張牌出來；

　　2. 師傅喊開牌，大家亮牌，比較大小；

　　3. 一般最小和最大的兩個人PK，說出自己的觀點，大家一起討論；

　　4. 差異無非來自于兩個方面：做什么，怎么做；PO參與討論回答做什么的問題，師傅和徒弟們討論解決怎么做的問題；

　　5. 討論過后再來幾輪，直到大家覺得結果差不多了。

　　撲克牌估算的匿名性和開放性保證了大家不會人云亦云，也不會因為缺少溝通而難以達成一致。

　　筆者的經驗是一局撲克牌估算大約持續1～5分鐘，還是很快的。偶然有黃莊的，一般都是因為PO那里回答不了做成什么樣子，某某附加功能是否也要做……等等問題時。

　　幾個問題

　　1. 為什么分給組而不是個人？

　　不分個人就打牌使得每個人都不得不思考，因為怕出錯了牌又說不出所以然。這樣即使日后他不做這個功能，也對這個功能很了解。

　　2. 為什么不讓最后領任務的人自己估算？

　　因為他很可能因為不知道某代碼可用、不知道某軟件不行、不懂template（我們因此扔過1個人月代碼）……而選擇了錯誤的實現方法。

　　3. 為什么不讓師傅估算大家采納，他不是最厲害嗎？

　　師傅的想法常常是徒弟們理解不了的——比如為什么不留在女兒國而偏偏去西天取經之類的，呵呵——共同估算就是讓大家在思考中對照自己的實現方法和師傅差異的過程。

　　4. PO怎么還參加？不是不讓別人干預嗎？

　　很多問題比如在游戲中“顯示武林排行榜”，具體工作量可能不在于怎么做而在于做什么：憑什么排名？排多少名？實時排名還是每周排名？怎么顯示排名？……因此PO不能寫出一堆文檔，然后以不便干預估算為名不參加敏捷計劃會議。

　　PO可以挑戰估算，比如：“這真的要這么久嗎？我記得上次……”但要有理有據。其實實踐中更容易看到的是，團隊往往過于激進樂觀，PO反而要讓他們意識到完整的需求和要求，做出更現實的估算。估算不準確，PO也有責。

　　5. 一直無法達成一致怎么辦？

　　其實估算不是為了最后那個數字，而是弄清楚做什么和怎么做的問題，如果這兩件事情清楚了，但結果卻是偏偏有人說4天有人說6天，隨便取個數就可以了（事實是應該按墨菲定理取6天）。有師傅在，一般很少會就實現方法爭執不下；有PO在，一般很少會就要實現什么爭執不下。

　　不排除有特殊情況比如PO發現自己也沒想過排行榜憑什么排行，那么就應該擱置此用戶故事；又比如大家覺得如果數據庫給力可能實時排名也行但又拿不準，可以暫時擱置到開發的時候再說，但把故事上標注一下“若需要每周自動排名+1天”。如果經常黃莊，Scrum Master要分析總結避免。

　　6. 四個人出牌不同，師傅先說還是徒弟先說？

　　想起個腦筋急轉彎：科學家 醫生 士兵 護士 ……等等一群人在飛機上，飛機結冰快墜落了需要有人（可能不止一個）跳下去，問誰跳？答案是從體重最重的人開始跳，因為可以少跳幾個。

　　因此我們是出牌數字最小的先說，和師徒無關。因為他極有可能掌握最佳實現方法。如果后來發現不是如此，請參考下一條。

　　7. 都有什么理由可陳述？

　　按下面的順序，越靠前的越接近真理，感覺自己接近真理的就一定要舉手先說，馬后炮招人嫌：

　　經驗事實：我以前做過……咱們有個類庫……那個方法我試過不可行……

　　蛛絲馬跡：誰還記得上次……聽說隔壁……與上回相比……你以前不是……

　　邏輯推理：理論上說……我覺得……

　　幾個注意事項

　　1. 小組內不要有強分工，否則大家會缺省認為肯定是某人的工作。

　　2. 師傅不要太搶眼，要通過估算鼓勵徒弟思考，同時也掌握徒弟的真實水平。

　　3. 師傅不要太較真，編程規范、易用性、易維護性這些紀律不能放松，但如果徒弟想嘗試一種不同但工作量也差不多的方法，可以適當鼓勵。

　　4. Scrum Master監控整個過程，防止太細/爭執……等問題。

　　5. PO必須參加。

　　團隊中常見的一種情況計劃、估算、設計的時候大家還在一起，但編程的時候就會分開。分開看似是安全的，但是卻充滿隱患。

　　2001年，一位招聘考試前三名（一共120員工）的程序員的兩個月的成果被徹底放棄重寫，原因是里邊包含3000多個常數，而且很難修改（碼流參數），重寫的人座位距離他只有4米，重寫也只花費了2周；2002年，一位月薪7000（那時候北京房價才3000多）的程序員編寫了一個月的4000多行代碼，在一個下午被重寫為50多行，座位距離他只有5米的項目經理疑惑加驚訝地問：“你真的沒學過c++ template？”。

　　這就是團隊的距離，即使是高薪聘請來的程序員也難免犯錯。難道我們只能避免下一次問題發生，而不能避免這次問題發生？

　　前檢查點

　　前檢查點就是在做某功能的最初一段時間，師傅與徒弟結對編程，完成最初最重要的設計。

　　“開始做X功能的時候叫我一聲，咱們敲定一下具體怎么做。”這個是師傅的前檢查點標準語法。盡管在共同估算的時候大家還是略有共識，但是限于計劃會的有限時間，徒弟未必真的知道怎么做。在剛開始的一兩個小時里邊，師傅帶領徒弟一起把基本的結構理清楚，最好寫上一些基本代碼，讓徒弟有一個直觀的概念。

　　在上面提到的2周的重寫工作中，重寫者和被重寫者一起工作了1.5天，重新設計了打包類、遞歸函數等最難纏的部分；被重寫者在剩下的兩周里邊完成了工作，而且很出色。倘若這一切發生在兩個月前該多好。那次事故之后，我們訂立了更嚴格的代碼審查制度，所有代碼均由部門技術最好的人審查后才進代碼庫；之后再來的新人，均指派師傅，并由師傅保證其代碼質量；將人員劃分為需指導的/免于指導的/可指導的/可培訓的四級（10年后我在NEC參觀交流時發現了幾乎完全相同的分級制度）。

　　前檢查點的工作作用是打下設計的基礎，保證工作順利進行。如果一切按照前檢查點的設計進行，徒弟可以繼續獨立工作，如果有偏離，要詢問師傅。

　　前檢查點的學習作用是顯而易見的，師傅平時工作的精華都展示在徒弟面前。而且這種展示是動態的，在結對編程的狀態下，徒弟可以完整地看到師傅是怎樣入手工作，怎樣

　　后檢查點

　　后檢查點就是某事做完后，師傅檢查一下徒弟的結果，保證達到驗收標準。

　　曾經分配給我一個剛畢業半年的組員，剛來沒多久就經常看到他上網玩，過去一問，原來工作做完了（真的非常快），驚奇之余趕緊看看結果：功能是有了而且實現得也很好，就是總有點瑕疵：要么按鈕不正，要么界面上有錯字。后來就改成每次任務完成都趕緊喊我去看看，修正后繼續下一個。他后來能力超群，在此公司作為“臺柱子”10年，現在還在。

　　其實多數新人在大學中都形成了“能運行就行”的概念，并不懂商業軟件開發的標準。本人也一樣，畢業5年還不知道delete內存（C++），每次都是多預留點C盤空間，這樣程序就能多運行一段時間，下班之后關機重啟就可以了……這樣的軟件肯定無法在服務器上長期運行的。

　　后檢查點的工作作用是可用來進行代碼審查，以確保軟件產品的質量，之后會提到。

　　后檢查點的學習作用是幫助新人學習商業軟件的開發標準，逐步養成好的習慣。

　　日常工作

　　除了在任務前后的時間點外，日常8小時也應該保持良好的溝通。在一次極端的環境中，我們曾經將其發揮到極致。

　　當時我們以很高的日薪臨時聘用了兩個不錯的程序員。他們技術雖然很好，但是卻對業務一無所知，也沒有提前看過文檔。因為總共也沒有多少天，當然不能把任何一分鐘花費在熟悉業務上，所以……

　　1. 每天早上（包括第一天）

　　整個軟件被大致分為三類功能區，互相關聯。組長（我）也自己編程，負責其中一類功能。

　　有20分鐘的晨會，組長會把一個簡單的設計文檔的一部分拿出來講解給兩個人，同時指出今天要做的工作要給予其中的哪些內容，他們提問我回答。散會前我們會就沒人的工作做一個簡單的估算（當年還不會撲克牌估算，太可惜了），確保當日是可以完成的。

　　晨會會提到技術問題，而不是每日立會中說的只說進度。但技術問題一般只涉及到要求，比如“做分段計價模型的時候，不要在C++里邊做For循環，看能不能在SQL里邊解決，如果解決不了來找我”“好，我試試。（或）這可能嗎？”凡是有問題的就會稍微深入一點；凡是“我試試”的，都放過，但如果試驗的結果不通就必須找組長討論而不能自行解決。

　　小組加組長只有3個人，所以所有人都參加這個20分鐘會，包括肯定不做某任務的人，也聽組長和別人的討論。

　　2. 每天下午1：30點左右

　　就是吃飽飯犯困的時候，組長會分別和大家在計算機前碰頭一下，主要是看當日的工作是否可能在下班前完成（堅持不加班）；另外就是看是否和晨會上預想的一樣。

　　其實就算是短短的半天時間，事情就可能有變。有一次其中一個程序員在一上午寫了大約4屏幕的代碼（一般每天才寫這么多），而功能卻遙遙無期。原來他不知道有個函數可以快速實現這些功能，正在自己造輪子，他本應該告訴組長所遇到的困難。

　　程序員很少在這個時候求助，他們總是相信自己能最終解決問題……因此在轉型為自組織團隊的時候，擔心程序員會偷懶的想法整體上是多余的，更需要預防的是蠻干/過于樂觀/激進/需求鍍金/消息閉塞/無法互相學習等問題。

　　3. 每天下午下班前

　　當時6點鐘有《七龍珠》（工作場所有臺電視），兩位對此都很著迷，所以我們基本到點就看片，看完后散伙回家。

　　因為也不能讓電視臺調整播出時間，基本上下午5點就要開始打掃戰場：組長分別找兩位，看最終結果是否完成，并做一下修改。同時還要做代碼審查（請看下一篇詳述）。

　　由于估算不會太準確，我們專門把所有三不管的小功能梳理出來，誰提前做完了，誰就找其中一個把剩下的閑工夫占上，結果其中一位幾乎包攬了全部。

　　4. 晚上

　　對，組長晚上還要工作。在他們走后組長會在晚上做個集成，把幾個人做的功能合成在一起運行。當時也沒有持續集成工具，所以只能手工。

　　在正常項目的正常團隊中，這個工作應該在第二天的工作時間完成，也就是說或者找專人（或輪流），或者讓組長做，或者讓自動工具做最好。推薦小組內輪流負責此事，因此可以讓大家理解別人的工作、整體的工作，乃至與組外人員的集成工作等內容，為組員成長為組長打下基礎。

　　5. 隨時

　　可以已經注意到我們沒有“每日立會”，一則當年還不知道Scrum，二則感覺一個3～5人的團隊還要靠開會交流實在迂腐。比如在篇首提到的兩次事故中，團隊都沒有少開會，但都因為缺少隨時的溝通而導致大錯。

　　其實任何伸伸懶腰的時間都可以進行溝通。不過一般不要“太隨時”，應該以師傅的時間為主，也就是如果徒弟遇到了問題，但可以繞過去先走著，就先來一句“我這有問題，有空幫忙看看”+“好，再過15分鐘”。這樣既不會讓徒弟被卡住，也不會讓師傅因為經常被打斷而導致無法工作。但師傅可以隨時發起交流，因為他們是去幫助徒弟的，聊的也是徒弟的事情，不存在打擾的說法。

　　注：上述部分內容僅限于特定環境中，但思路很多時候都是可取的。

　　松結對和緊結對不一樣，兩個人不是總坐在一起隨時發現問題解決問題，而是很短時間地坐在一起。其中在后檢查點發生的主要事情有兩個：一是看結果是否符合需求（做什么），而是看代碼是否存在問題（怎么做），后者就是代碼檢查。

　　代碼檢查（也稱代碼審查Code Inspection）是一種由來已久但是很神秘的東西，最初引入是在一些生命攸關、重大財產相關的軟件開發中，典型的就是SSOS（美國航天飛機的軟件），其每段代碼都交由6個人審閱，方可入庫。成果就是在1989年之前（之后筆者沒有數據），SSOS在太空中失效次數只有一次。筆者親身參與的代碼審查活動包括某數字電視CA系統的代碼審查（25個程序員只有1個測試，已用于CCTV）、某電信計費系統的代碼審查（一周發現2400個缺陷）、某電信運維系統的審查（2天發現200個重要缺陷，其中1個已困擾團隊5年）、某航空無損檢測系統的代碼審查（交付后一年內客戶只發生一次失效）。

　　代碼檢查的基本原理就是相信人腦（而非人眼）是判斷代碼好壞的最好工具，比如如果代碼中有一行：if (i == 1001) return die()的錯誤或非法代碼，幾乎無法經由測試包括自動測試發現，但肉眼卻一目了然。

　　筆者曾編寫過一個“復雜而徹底”的代碼檢查培訓教材，但后來發現過于復雜而且還不徹底，所以作罷。下面將要介紹的是一種業余但卻有效的代碼審查方法。

　　-----------------------------------------------------------------------

　　程序員的質量觀

　　有人曾把程序員分為四級：編寫可用軟件（大致是大學在校生的狀態），編寫可靠軟件（大致是好一些的職業程序員的狀態），編寫精美軟件（在簡單性/可維護性/可復用性上有所突破），編寫思想深邃軟件（設計模式、MVC、JQuery及早期OLE、RPC等創始者所做的事情）。

　　但在現實中，卻往往發現很多程序員停留在第一層次：“你測吧，測出缺陷來我改”“這個不用改也能運行”“這么編就是難讀點而已”，師徒間的代碼檢查，就是把程序員從第一級別向上提高的過程。

　　第一段提到的25個程序員+1個測試人員的團隊是01年我們所在的團隊，當時保持了良好的質量風氣。尤其由于大家知道沒有測試人員擦屁股，留下缺陷相當于給自己找麻煩，所以大家不得不習慣自己動手防患于未然。這個產品后來發展勢頭很好，07年曾占據市場60%（之后不詳）。

　　怎樣檢查

　　“高手本來自己就要開發很多代碼，還要替新手檢查代碼，多花費時間啊……”這是一個常見問題，答案是：“每天，在后檢查點，花費不超過15分鐘時間，能看出什么來就說什么，時間到了就停。”

　　一般而言，大致每天高手能編寫100多行有效代碼（按分號計數），新手會多一些但也不超過200（他們編寫代碼比較費時），也就是10個屏幕以內。有經驗的人一定知道：高手看新手的軟件，5秒鐘就能發現問題。

　　常存在的一種情況是高手“看不懂”新手的代碼，當然不是因為技術太精妙了，而是寫得太亂了。但在松結對編程里邊不存在，由于師傅徒弟天天在一起，這200行代碼可謂一目十行，如果以往一直每天檢查代碼，那么里邊存在的問題應該不會很多。

　　檢查什么

　　這個是重點，整體包括：

　　1. 結構問題

　　代碼最大的問題，不是一兩個地方有技術缺陷，也不是業務邏輯錯誤，而是整個軟件編寫的不好。前兩者都可以通過測試或使用來發現和更正，但后者就不同了。如果回想一下自己見過的各種爛攤子，是不是有同感？具體哪里有問題怎么改說不上來，就是整個軟件看上去混亂無章，無從下手。

　　具體結構問題包括：重復拷貝代碼（不封裝函數，不用Template/泛型……），函數過長（超過一屏幕就叫過長），錯誤封裝（不恰當的public/不用Interface/不內聚/強耦合/在類中封裝了無關方法……），內容錯誤（多個無關類置于一個文件/不恰當的命名……）等等。

　　改正結構問題，是從編寫可靠軟件向編寫精美軟件邁進的重要方法。

　　2. 業務邏輯問題

　　就是軟件是否與需求的要求符合的問題。師傅和徒弟經常對業務需求的理解有差異，借此機會同步一下，必要時引入PO（產品經理/策劃人員……）。

　　有人會說業務邏輯問題不是一測試就知道了嗎？可是測試一般發生在很久以后，有些邏輯測試還需要一定的觸發條件，而且測試只會發現失效（failure, 與預期不符）而不能發現缺陷（defect, 具體哪里出了錯），等積累長了，誰也找不到原因了。

　　3. 編程素養問題

　　很多問題屬于那種“這樣也行那樣也行”的狀態，比如命名/初始值/縮進/斷行……但是高手的做法總是比新手好一些。

　　比如bool result = true; 這句話就有問題，剛初始化就先宣布成功，必有隱患。這是一個真實案例，而下面也的確有一個分支錯誤地返回了這個true（實際案例是個HRESULT）。而發現這個問題，不是測試而是代碼檢查。實際上測試幾乎發現不了這些問題，比如上面那段代碼會在某文件打不開的時候錯誤地返回這個true，而在測試中幾乎不會故事破壞那個文件來測試其結果。

　　實際使用時，不用拉太長的清單，師傅能想到的看到的告訴徒弟就行。

　　徒弟不需要學到天上去，只要能學到師傅那么好就可以了。之前在做CMMI咨詢的時候我弄過一些檢查表，推廣均以失敗而告終。那些表都是為了頂級安全性的軟件考慮的，在普通項目里邊使用是個災難。

　　幾個問題

　　1. 師傅天天檢查，會不會很累？

　　檢查不全是為了發現缺陷，而是為了提高成長。如果總是發現重復問題，此徒不可教。好學的徒弟有半年時間就能接近師傅了，考慮到師傅一般比徒弟多工作2年，我們因此讓一個人加速1.5年。

　　2. 不會餓死師傅嗎？

　　會，也不會。如果師傅止步不前，即使他不教別人，也遲早被人超越；師傅也是需要學習的。事實是會教徒弟的師傅才會學習，而會學習的師傅才會教徒弟。

　　3. 師傅跟誰學？

　　師徒制度是最底層團隊制度（1個師傅+1～3個徒弟左右），其上還有更大的結構和更高的高手。我們之前曾把人員層次設為需指導的（徒弟）/可免于指導的（也是徒弟）/可提供指導的（師傅）/可培訓的（團隊最高級別的高手），最后一級需要定期與大家分享內容。

　　師傅作為高級技術人員，還享有機會外出培訓/采購圖書等待遇。

　　師傅自學也很重要，經驗更是不可取代的。前事不忘后事之師，要把自己的經歷和別人的經歷都當作經驗來看待。

　　4. 師傅努力編好自己的軟件不久已經有很大貢獻了，為何要幫助徒弟？

　　軟件整體是一個串聯系統，一個環節出了問題整個軟件崩潰（Web軟件好一些）。因此軟件質量取決于最差的部分，而不是最好的部分。

　　代碼審查的確會占用時間導致最好的部分變差，但卻使最差的地方變得好得多，整體質量因此而得以提高。

　　------------------------------------------------------------

　　從工作層面講，代碼檢查使得代碼的質量尤其是結構質量，整體上保持在師傅可能達到的水平，從而保證了項目的成功。

　　從學習層面講，代碼檢查使得徒弟可以不斷/漸進地學習，從而花費遠遠低于師傅的時間成本達到更高層次。

　　心態是其中的關鍵。徒弟不能因此而覺得有一個后盾了可以放任存在問題等師傅發現，要珍惜師傅的時間，也要利用師傅的時間每次都學不同的內容；師傅也不能覺得徒弟學會了對自己是個威脅，威脅時刻都在，不來自于自己的徒弟，也會來自于別人的徒弟，唯有自我提高。

　　至此所有實踐層面的內容基本上都寫完了，下一篇將提到一些“139團隊”的問題，所謂“139團隊”就是一個使用松結對編程工作方式的大型團隊。

　　松結對編程是小型團隊的實踐，大約運行在1個師傅+1～3個徒弟的尺度上，當面臨更大尺度的時候，就需要大型團隊模型。這里推薦139團隊模型，因為它不但可以讓松結對編程運轉順利，還解決了大團隊溝通、績效考核、師傅的出路等問題。

　　139團隊的整體情況相當復雜，將另有系列博文描述，這里只描述與“松結對編程”相關的內容，以保證本系列博文的完整性。

　　基本概念

　　139團隊就是1個項目經理，3個師傅，9個徒弟的簡稱，當然實際上未必正好湊夠13個人，也未必正好每個師傅都有3個徒弟。

　　在第一篇里邊已經提到過三個層級的工作關系，下面是一些深入的剖析。

　　績效考核

　　績效考核歷來是軟件業最頭痛的問題，按代碼行考核吧新程序員寫的垃圾代碼比高手多，按任務數考核吧任務大小不一，按功能點考核吧多數人不會數，按工作按時完成率考核吧師傅還幫不幫徒弟了？……139團隊大致有個答案：按1-3-9的層次安排大致薪金和獎金比例（在139團隊系列中有詳細分析）。

　　139團隊認為績效考核首先是團隊的整體績效；在分解到個體時，不是看具體每個人干活多少，而是看在團隊中所起的作用。

　　所以，想加薪？帶徒弟吧。不過有一點，帶一隊沒用的徒弟是沒用的，首先要有團隊績效，才會有個人績效。

　　人員招聘

　　人員招聘一般在較高層進行，最低也是項目經理，但是最終帶新人的卻是師傅。所以招聘的時候應該請未來的師傅也在場，部門經理/項目經理可以問師傅“這個人給你當助手，你覺得夠嗎？”這個問題我最近正好問過，師傅的話語權很重，因為如果他不喜歡，下面的配合會很難。如果是招聘師傅，項目經理心里要對此人和現有師傅水平的高下比較有個概念，尤其是溝通和教學能力。

　　師徒的差異既不能太大，也不能太小。太大學不明白，白耽誤師傅的功夫；太小沒什么可學，還可能引發沖突（經常半斤大戰八兩，如果其中一個是二兩就打不起來了）。如果理解了松結對編程的上述實踐，在遇到實際人員的時候實際情況實際分析一下就可以了。

　　職業生涯規劃

　　徒弟學好了可以做什么？可以獨立工作，比如新出現一個模塊或業務，可以單獨交給此人開發（要配代碼審查人）；做得更好了可以做師傅，帶徒弟。

　　師傅學好了可以做什么？可以做項目經理。比如如果有個師傅帶了多達3～5個徒弟，而且還想增加人，那么他的那個模塊多半要分拆為一個子項目了，而分拆后，師傅是新項目經理的最佳人員。

　　之前呆過的一家高成長性公司，去的時候只有18人，一年半以后就達到120人了，而業務骨干多半都是當年的徒弟，而不是新招來的高手。究其原因，一則業務壁壘不是剛招來的高手能突破的，二則師徒制度使人成長很快。最初大家并沒有正式的師徒制度，但是項目經理無私地指導大家，為團隊成長和后來建立師徒制度建立了條件。本人剛去的時候工作五年了，還不知道申請的內存要刪除（C++），現在的編程功底基本上都是在這家公司學成的。

　　主程序員團隊

　　如果遇上一個頂十個的師傅，也有團隊模型就是主程序員團隊。師傅干活，徒弟打雜+學習。本人用過兩次半，都很成功。主程序員團隊的工作方式更“松”，但也有其工作模式和師徒制度。

　　主程序員團隊不如松結對編程團隊健康和有潛力，個人感覺只適合某些情況。

　　本文未涉及的139團隊內容

　　自組織團隊的激勵機制，大型團隊的計劃會，大型團隊的每日立會，大型需求團隊與開發團隊的配合，強分工團隊的工作方式，139團隊詳細的績效考核/非物質激勵等內容，將在139團隊系列中展開討論。

　　-----------------------------------------------

　　139團隊是應用松結對編程的大型敏捷團隊，在其3-9級別上適合松結對編程過程，而在整個層面上適合Scrum過程。

　　139團隊解決了績效考核、人員招聘、職業生涯規劃等一些大團隊問題，從而為小團隊（師徒團隊）應用松結對編程和日后健康成長鋪平道路。

　　本文是“敏捷開發松結對編程實踐”的最后一篇，本系列所屬實踐僅適用于幾個開發人員的微觀環境，其外圍大型團隊的實踐請參考“大型敏捷開發團隊：139團隊模型”系列。

　　------------------------------------------------

　　后記

　　任何開發方法都有局限性，也都有可取之處，松結對編程也不例外。

　　筆者在多年開發及咨詢過程中，逐漸發現所有研發方法都會遇到困難，而所有研發方法經過變形都可以某種方式應用下來。關鍵問題在于，在遇到困難的時候不要因為困難而否定方法，而要積極為解決困難尋找答案。格言說得好：不是缺少發現問題的眼睛，而是缺少解決問題的手。

　　松結對編程本身就是在實際環境中應用敏捷開發和結對編程的時候遇到困難后的變形，所以在應用松結對編程的時候如果遇到困難時，辦法只有一個：繼續變形。

　　敏捷開發傳入中國已經10年了，但是如果問哪家企業非常成功地應用敏捷開發，誰能出來好好地講講案例，幾乎無一能者。究其原因無外乎兩個：

　　1. 過于迷信方法，因此嘗試原封不動地使用方法，結果水土不服遭到失敗。

　　2. 過于不迷信方法，嘗試失敗后就輕易放棄。

　　整個過程中最容易被忽略的，是實踐者自身的創造力。其實早在創建Scrum的時候，Ken就指出Scrum只是一個起點，他建議人們從原裝的Scrum入手以保持穩定的過程框架，并進而自行發揮。但多數人在應用時，都過于喜歡查書，百度，google，找培訓課程，看博客——包括這里，只要還找不到的，也不再嘗試不再創新，這就背離了創始人的初衷。

　　剛剛參加完MPD 2011深圳站，在演講中間及后來媒體采訪，被問到了一些問題，也給出了答案，這里做一總結。

　　我自問自答到一半，才發現這里邊的很多問題的答案，都用到了火星人諺語系列之一：有問題的地方無答案、火星人諺語系列之三：正確的答案一定簡單。如果您覺得答案和自己的情況不完全相符，請用火星人諺語系列之二：問問題的人負責找答案。

　　另外多數答案在本系列1～6中有，只是比較分散，不太容易意識到是答案。

　　人員與結構

　　在團隊中使用層級結構，是否阻礙了個體與外界的溝通？

　　極少有底層程序員或新手能和產品經理做深入的溝通的，所以中間放上師傅這一層，讓其代為問問題，徒弟旁聽，不但不會阻礙，反而會促進。

　　這樣徒弟可以更快地學會問答技巧或熟悉業務，真正學成了，師傅才懶得在中間“阻礙”呢，呵呵。

　　師傅又要懂業務，又要懂技術，又要帶徒弟，是否要求太高了？

　　的確不低，但是如果不要求這三個師傅如此，就要要求全組如此，更難；當然可以要求讓程序員們可以不懂業務，但這樣的程序員怎么放心讓他干活呢。

　　但實際上，這點要求算不上什么，和“多才多藝”二字沾不上邊。所以這種人其實很多，只是他們沒被賦予這種職能而已。

　　師與徒

　　高手不愿意帶徒弟怎么辦？

　　所謂求什么得什么，如果企業給個人能力高的人發高薪，而不給能帶團隊的人發高薪，屋子里邊坐著的一定是一堆不愿意帶徒弟的高手；反之則反。

　　另外一個角度，139團隊不只是一個學習團隊，而首先是一個生產團隊。師傅帶徒弟，一定程度上有上級帶下級的感覺。還沒有一個上級不希望自己有更多手下的，也沒有上級希望自己手下都是飯桶的。

　　所以制度合適，人自然改變。

　　招聘了徒弟，沒有師傅愿意帶怎么辦？

　　以往人是招聘來塞給某人“你負責他的成長的”，現在應該是有師傅說“忙不過來了，給我招聘個徒弟吧”。師傅要參與徒弟的招聘和試用。

　　徒弟不聽師傅的怎么辦？

　　試用期就走人。

　　時間與效率

　　師傅一個頂仨，照顧別人是否降低效率？

　　要做好時間管理，就是師傅找徒弟隨時，徒弟找師傅預約（“我有問題……”“好，等15分鐘……（繼續干活至一段落為止）”）。

　　一個人看那么多人的代碼，會不會很花時間？

　　高手看新手的代碼，10分鐘就能看到一大堆錯誤。

　　師傅看徒弟的代碼，5分鐘就行；每天早上做了設計，中間還有前后關鍵點，沒什么可看的。

　　今天看到的問題，明天不可再見，早晚一天無問題可見。師傅是培養徒弟干活的，不是給徒弟擦屁股的（在試用期就要考核這個，不怕起點低，但一個人連培養價值都沒有，還能干啥）。

　　專家與雜家

　　大家需要了解的東西太多，生產率是否降低？

　　我見過的最高的幾個高手，都是以更廣泛地了解業務和技術為特點的。

　　我見過一個13個人的團隊，9年來人換了好幾批了，從來都是每人只負責的功能，都是“專家”。產品最后有25萬行，被一個高手花一年半改為1.3萬行。問為什么原來的代碼那么多，答：“原來的專家走了，沒人能看懂其代碼，所以只能大面積拷貝粘貼。”這樣的專家，要他何用。

　　有些人希望只專注于自己的工作，怎么辦？

　　目光這么窄的人，能做好自己的工作才怪；所知這么窄的人，能委之重任才怪；一直自己干活的人，能管理部門才怪。很多人苦苦鉆研技術，希望能力提高然后被提拔，實在是緣木求魚。道理一講就通。

　　如果還講不通，遲早會發現不想當將軍的士兵，連廚子都做不好的，呵呵。

　　績效與成長

　　師傅學不到東西怎么辦？

　　師傅之上還有師傅；師傅人數少，可以送去培訓……師徒制度里邊沒有關于師傅怎么學習的內容，但如果理解“有問題處無答案”，這類問題很好解決。

　　教會徒弟，會不會餓死師傅？

　　如果我是老板，我會喜歡下金蛋的鵝，勝過金蛋，因此給鵝更多錢。

　　如果我是師傅，我會喜歡賣金鵝蛋，勝過賣烤鵝腿，因此能值更多錢。

　　如果我是徒弟，我會羨慕下金蛋，勝過我就是個蛋（好慘啊）。

　　徒弟的能力超過師傅怎么辦？

　　我的編程能力超過我師傅的時候，他做部門經理去了，因為我們部門的所有師傅，都是他的徒弟，不選他選誰。

　　能力的不總是等于編程能力，而是一種在不同年齡不同層次有不同定義的東西，只有這種東西才能叫做能力。

　　上面這句話套用金剛經語法，就是“如來所說能力，則非能力，是名能力”，剛開始很難理解，但理解了就發現是一種很通用很有效的思維方式。

　　比如把“創新”帶進去，就會得到喬布斯的創新觀：我們蘋果所說的創新（價值觀創新），是不能被模仿的創新，所以才叫做創新（換言之能被那么容易模仿的，還談不上什么創新）；你們模仿iPod，我就做iPhone，你們模仿iPhone，我就做iPad；你們模仿iPad，我就得胰腺癌……

　　因為何為“能力”，怎樣根據“能力”確定師傅和徒弟，根據什么“能力”來考核師徒，是139團隊和松結對編程的核心，所以多說兩句。

　　個人感覺凡是不違背敏捷之神的研發管理方法，均為敏捷。所有敏捷的實踐者，都應該在敏捷的大框架下，跟著自己直覺和本能的引導，去創造適合自己的敏捷實踐方法。

it知識庫：敏捷開發“松結對編程”實踐，轉載需保留來源！

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