敏捷開發“松結對編程”實踐

　　[1] 人員結構篇

　　[2] 計劃與設計篇

　　[3] 共同估算篇

　　[4] 日常工作篇

　　[5] 代碼檢查篇

　　[6] 大型團隊篇

　　[7] 問題集

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

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

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

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

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

　　挑選小組長(師傅)基本原則

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

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

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

　　2. 盡量找善于溝通的人

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

　　挑選組員(徒弟)基本原則

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

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

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

　　2. 徒弟年齡不要太大

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

　　挑選組長(大項目經理)基本原則

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

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

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

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

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

　　團隊結構和運行理念

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

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

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

　　2. 在工作中學習

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

原文轉自：http://kb.cnblogs.com/page/107713/2/