靈活開發“松結對程式設計”實踐之六：大型團隊篇|後記（大型研發團隊，學習型團隊，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，找教育訓練課程，看部落格——包括這裡，隻要還找不到的，也不再嘗試不再創新，這就背離了創始人的初衷。

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