|
|
傳說中的結(jié)對(duì)編程，大致結(jié)構(gòu)是兩個(gè)人共用一臺(tái)電腦，一個(gè)開發(fā)，一個(gè)測(cè)試，以隨時(shí)評(píng)審來抵消返工時(shí)間損失。
傳說歸傳說，誰也沒有見過。問題出在哪里？有兩種主要原因。
一是來自高層的，高層感覺兩個(gè)人只有一個(gè)人干活，實(shí)在是有點(diǎn)浪費(fèi)。“評(píng)審抵消返工時(shí)間”虛無縹緲，但每天只有一個(gè)人干活卻是現(xiàn)實(shí)情況。
二是來自基層的，兩人若有高低，高手肯定覺得還不如我一個(gè)人干的快；兩人若旗鼓相當(dāng)，難免產(chǎn)生爭執(zhí)。
其實(shí)在我們身邊一直有一種方法很像結(jié)對(duì)編程：“師徒制度”，就是每個(gè)新人來到公司，都指派一個(gè)師傅帶著，在技術(shù)與業(yè)務(wù)方面提供指導(dǎo)。他們既不用一臺(tái)電腦，也不是老死不相往來，這其實(shí)就是一種“松散”的結(jié)對(duì)編程。只不過多數(shù)企業(yè)雖然有這種制度或?qū)嵺`，但卻很少有很清晰的定義，難免限制了這種實(shí)踐的效果。本系列的目標(biāo)，就是從人員結(jié)構(gòu)、計(jì)劃實(shí)踐、日常工作實(shí)踐、績效考核等各個(gè)角度，來完整地思考和建立這種制度。
挑選小組長（師傅）基本原則
樂于助人，有責(zé)任心，善于溝通，擅長管理，技術(shù)精湛，業(yè)務(wù)精通……很可惜，好詞匯越多，越難找到符合的人。不過，一些基本原則還是要考慮的：
1. 盡量找對(duì)業(yè)務(wù)有興趣的人
整體上偏業(yè)務(wù)的人未來有更好的發(fā)展（這是我2001年的上司的原話，事實(shí)證明很對(duì)），由于有行業(yè)壁壘也較少跳槽。由于小組長角色未來將被提拔為更高的項(xiàng)目經(jīng)理、產(chǎn)品經(jīng)理，對(duì)業(yè)務(wù)的了解也會(huì)為此做好鋪墊。
2. 盡量找善于溝通的人
善于溝通的程序員成長更快（還是那位上司的原話），也更能幫助別人成長。
挑選組員（徒弟）基本原則
1. 徒弟能力一定要低于師傅（應(yīng)該說：師傅一定要高于徒弟）
很常見的一種做法是把幾個(gè)水平相當(dāng)?shù)娜朔旁谝黄鸸ぷ鳎J(rèn)為這樣他們可以互相學(xué)習(xí)，其實(shí)不然。
之前我們?cè)诘捻?xiàng)目組經(jīng)常發(fā)生技術(shù)“爭論”，發(fā)生的次數(shù)多了，我們發(fā)現(xiàn)一個(gè)規(guī)律：每次爭執(zhí)不下的，都是兩個(gè)技術(shù)相當(dāng)?shù)娜耍看螤巿?zhí)的解決，都是一個(gè)水平更高的人給出一個(gè)截?cái)啾娏鞯姆桨福缓蟠蠹疑⑷ァ?/p>
2. 徒弟年齡不要太大
如果有兩個(gè)水平相當(dāng)、月薪要求都是6000的程序員，當(dāng)然找年輕的了，有發(fā)展?jié)摿Γ髣抛恪?/p>
挑選組長（大項(xiàng)目經(jīng)理）基本原則
1. 項(xiàng)目經(jīng)理必須喜歡業(yè)務(wù)勝過技術(shù)
項(xiàng)目經(jīng)理是掌舵的而不是干活的，因此必須對(duì)業(yè)務(wù)有深刻理解。
2. 項(xiàng)目經(jīng)理最好精通技術(shù)
這里不討論是否存在“不懂技術(shù)卻精通管理”的項(xiàng)目經(jīng)理，但是如果目標(biāo)是項(xiàng)目成功而非證明奇跡的確存在，項(xiàng)目經(jīng)理應(yīng)該首選那些從小組長成長起來的既懂業(yè)務(wù)技術(shù)又精湛的人選。
這里的“精通技術(shù)”不是從技術(shù)實(shí)現(xiàn)層面考慮的，而是從“技術(shù)想象力”層面考慮的，就是說他必須能想象到有某種技術(shù)存在。比如以前我們遇到一個(gè)程序員寫了一大堆重復(fù)代碼，原因就在于他的想象力受到了局限，明明有虛函數(shù)、模板等各種方法來簡化代碼，卻沒有想到。“沒有學(xué)到”是無法避免的現(xiàn)實(shí)情況，但“沒有想到”是可以避免的。
團(tuán)隊(duì)結(jié)構(gòu)和運(yùn)行理念
既然待在某個(gè)“位置”上，每個(gè)人必有不同的職責(zé)。這里就不一一列出了，因?yàn)椴露疾碌贸鰜恚ū热鐜煾狄獛降苤悾Ｏ旅嬷涣谐鏊山Y(jié)對(duì)編程與一般小組的核心差異。
1. 對(duì)每個(gè)小組（師傅+1～3個(gè)徒弟）整體考核
也就是師傅要負(fù)責(zé)到底，不能出現(xiàn)“他剛來所以把事情辦砸了”的情況。這里的負(fù)責(zé)到底，包括計(jì)劃、估算、跟進(jìn)、進(jìn)度、質(zhì)量、徒弟成長……等一干事情，本系列的其他文章中都將展開描述。
2. 在工作中學(xué)習(xí)
盡管“松”，但還是“結(jié)對(duì)編程”，學(xué)習(xí)和指導(dǎo)過程實(shí)在生產(chǎn)過程中集成的，因此師徒關(guān)系的成敗不只是人員成長，還包括任務(wù)和項(xiàng)目的成敗。這首先是一個(gè)生產(chǎn)團(tuán)隊(duì)，其次才是學(xué)習(xí)團(tuán)隊(duì)。
新人其實(shí)很少偷懶，因?yàn)橐环矫嬲幱谌腴T學(xué)習(xí)的高峰期，另一方面工作時(shí)間不長，需要得到企業(yè)和團(tuán)隊(duì)的認(rèn)可。可為何他們工作總是不得力呢？
新人的真正問題在于無心辦錯(cuò)事和好心辦錯(cuò)事。
無心辦錯(cuò)事包括沒學(xué)過某種好的方法、不知道企業(yè)已經(jīng)有某些可用代碼或庫、不懂業(yè)務(wù)等種種問題。
好心辦錯(cuò)事包括想做一個(gè)比領(lǐng)導(dǎo)想想的更好的功能、過度思考了可復(fù)用性可維護(hù)性等。
這兩個(gè)問題筆者都經(jīng)歷過（作為新人和老人），“避免”是最好的方法，而不是事后改正，這就需要在設(shè)計(jì)階段和計(jì)劃階段從技術(shù)、管理兩個(gè)方面來提前預(yù)防。
技術(shù)：輕量級(jí)設(shè)計(jì)
如果要把一個(gè)任務(wù)分配給一個(gè)“不放心的人”，有兩種辦法保證成功：師傅把設(shè)計(jì)做出來交給徒弟做，但是“設(shè)計(jì)文檔”的詳細(xì)程度很難把握，寫少了做不出來，寫多了等做出來了很多內(nèi)容又多余了；師傅徒弟結(jié)對(duì)編程，但是很占用師傅的時(shí)間，尤其是倘若徒弟“實(shí)際上”（可惜只有上帝知道）完全可以勝任這個(gè)任務(wù)。
有兩種解決方法。
1. 事前輕量級(jí)設(shè)計(jì)：預(yù)想陳述（有點(diǎn)隱喻的意思）
預(yù)想陳述是微軟很久以前就使用的一種方法，任何人（不只是徒弟）有什么設(shè)計(jì)，不用寫下來因?yàn)樘M(fèi)時(shí)間了而且還可能被拋棄，而是給大家講一下。大家會(huì)給出評(píng)價(jià)和意見，以保證其正確性。然后此人就按這種方法去實(shí)現(xiàn)了，倘若成功了也被認(rèn)可了，就簡單寫下來以供日后參考使用。由于系統(tǒng)已經(jīng)存在，這個(gè)簡單寫下來的設(shè)計(jì)可以真的很簡單。
在“松結(jié)對(duì)編程”里邊，有兩種類似的做法。
一種是師傅把自己的想法告訴徒弟（一般用一個(gè)白板，或一張白紙），徒弟提問師傅回答，到差不多為止。
二種相反，徒弟講給師傅聽，師傅師傅質(zhì)疑和指導(dǎo)，到差不多為止。
兩者都不要事先形成永久文檔，但都在被證明可行（就是編碼完成后）寫一個(gè)簡單文檔記錄。任何代碼之外的能幫助理解當(dāng)時(shí)做法的文字/圖片都可以稱為文檔，沒有字?jǐn)?shù)限制。如果能和用戶故事放在一起則更好，一個(gè)描述做了什么，一個(gè)描述怎么做的。
2. 前檢查點(diǎn)
就是在某事開始的時(shí)候進(jìn)行臨時(shí)結(jié)對(duì)編程。一般發(fā)生在某個(gè)功能剛開始做的時(shí)候，詳情會(huì)在之后的“日常活動(dòng)篇”做詳細(xì)描述。
管理：共同計(jì)劃（共同估算，撲克牌估算）
預(yù)想陳述、前檢查點(diǎn)雖然已經(jīng)很輕量級(jí)了，但是如果師傅和徒弟都剛剛對(duì)需求（用戶故事）有所了解，還給不出很清晰的思路的時(shí)候，比如在Scrum計(jì)劃會(huì)上，怎樣快速知道徒弟有沒有理解需求，有沒有大致的實(shí)現(xiàn)思路呢？那就是共同估算（撲克牌估算是共同估算的一種最好的實(shí)現(xiàn)形式）。
1. 共同估算
共同估算的原理和做法還是很復(fù)雜的，這里只簡單說說，以后會(huì)有文章詳細(xì)講述。
共同估算就是師傅和徒弟基于相同的信息（一般是在計(jì)劃會(huì)上聽PO講完故事的時(shí)候），一起說出自己認(rèn)為做完這件事情需要多久。基本原理是：若兩個(gè)人對(duì)某件事情的工期認(rèn)識(shí)是相同的，那么他們的實(shí)現(xiàn)方法不分高下，用哪種方法都差不多。
為了防止人云亦云，一般需要采用匿名方法，而撲克牌估算就實(shí)現(xiàn)了高效有效的共同匿名估算（另有文章詳述）。
2. 驗(yàn)收標(biāo)準(zhǔn)
為了基于相同的目標(biāo)建立共同估算，也為了防止需求鍍金或最終軟件不能滿足需求，師傅和徒弟要建立對(duì)需求的共同理解。
簡單方法就是兩者（其實(shí)是師傅和多個(gè)徒弟）一起參加估算會(huì)，一起聽PO講解故事。但最好是在此之后，建立一個(gè)“文檔化”的驗(yàn)收標(biāo)準(zhǔn)。比如在一張故事卡/Excel表里……上寫上“需集成；無性能要求……”等最簡單的描述（請(qǐng)參考本博客的敏捷開發(fā)分類下一片關(guān)于驗(yàn)收標(biāo)準(zhǔn)的文章）。
共同估算+驗(yàn)收標(biāo)準(zhǔn)，使得師傅和徒弟（推廣為高手和新手）使用大致相同的方法，做大致相同的東西。共同估算既是一個(gè)工作的過程，也是一個(gè)學(xué)習(xí)的過程，因?yàn)樵诶斫庾鍪裁春驮趺醋龅耐瑫r(shí)，徒弟也向師傅學(xué)到了東西。
估算是經(jīng)久不衰的管理話題，大致分為兩種流派。
第一種是領(lǐng)導(dǎo)指派，領(lǐng)導(dǎo)說這是10天的活，就必須當(dāng)是10天的活來干，如果干不完，可以用加班、損失質(zhì)量、功能縮水等各種方法曲線救場(chǎng)。另一個(gè)變種是大家自己估算，但是交給領(lǐng)導(dǎo)審批；領(lǐng)導(dǎo)審批其實(shí)就是砍一半的過程，還好大家之前就已經(jīng)加了一倍，所以不怕。
第二種是自我管理派（偏敏捷），就是由具體開發(fā)的人員自己說開發(fā)工作量，領(lǐng)導(dǎo)和他人不干預(yù)。盡管“自組織”了，但是領(lǐng)導(dǎo)深以為這種方法留下了偷懶的種子，而隊(duì)員也覺得某人的估算很不靠譜（太長或太短），到底怎么辦呢？共同估算吧。
基本概念
假設(shè)現(xiàn)在是一個(gè)計(jì)劃會(huì)上，PO（產(chǎn)品經(jīng)理，策劃組長，項(xiàng)目經(jīng)理，某銷售……）剛剛講完需求，下一步不是交給某人做估算，而是交給某個(gè)潛在的組（師傅+1～3徒弟）。
由師傅帶頭打牌，對(duì)，在計(jì)劃會(huì)上玩撲克：
1. 大家各自思考可能要花多久時(shí)間完成任務(wù)，扣一張牌出來；
2. 師傅喊開牌，大家亮牌，比較大小；
3. 一般最小和最大的兩個(gè)人PK，說出自己的觀點(diǎn)，大家一起討論；
4. 差異無非來自于兩個(gè)方面：做什么，怎么做；PO參與討論回答做什么的問題，師傅和徒弟們討論解決怎么做的問題；
5. 討論過后再來幾輪，直到大家覺得結(jié)果差不多了。
撲克牌估算的匿名性和開放性保證了大家不會(huì)人云亦云，也不會(huì)因?yàn)槿鄙贉贤ǘy以達(dá)成一致。
筆者的經(jīng)驗(yàn)是一局撲克牌估算大約持續(xù)1～5分鐘，還是很快的。偶然有黃莊的，一般都是因?yàn)镻O那里回答不了做成什么樣子，某某附加功能是否也要做……等等問題時(shí)。
幾個(gè)問題
1. 為什么分給組而不是個(gè)人？
不分個(gè)人就打牌使得每個(gè)人都不得不思考，因?yàn)榕鲁鲥e(cuò)了牌又說不出所以然。這樣即使日后他不做這個(gè)功能，也對(duì)這個(gè)功能很了解。
2. 為什么不讓最后領(lǐng)任務(wù)的人自己估算？
因?yàn)樗芸赡芤驗(yàn)椴恢滥炒a可用、不知道某軟件不行、不懂template（我們因此扔過1個(gè)人月代碼）……而選擇了錯(cuò)誤的實(shí)現(xiàn)方法。
3. 為什么不讓師傅估算大家采納，他不是最厲害嗎？
師傅的想法常常是徒弟們理解不了的——比如為什么不留在女兒國而偏偏去西天取經(jīng)之類的，呵呵——共同估算就是讓大家在思考中對(duì)照自己的實(shí)現(xiàn)方法和師傅差異的過程。
4. PO怎么還參加？不是不讓別人干預(yù)嗎？
很多問題比如在游戲中“顯示武林排行榜”，具體工作量可能不在于怎么做而在于做什么：憑什么排名？排多少名？實(shí)時(shí)排名還是每周排名？怎么顯示排名？……因此PO不能寫出一堆文檔，然后以不便干預(yù)估算為名不參加敏捷計(jì)劃會(huì)議。
PO可以挑戰(zhàn)估算，比如：“這真的要這么久嗎？我記得上次……”但要有理有據(jù)。其實(shí)實(shí)踐中更容易看到的是，團(tuán)隊(duì)往往過于激進(jìn)樂觀，PO反而要讓他們意識(shí)到完整的需求和要求，做出更現(xiàn)實(shí)的估算。估算不準(zhǔn)確，PO也有責(zé)。
5. 一直無法達(dá)成一致怎么辦？
其實(shí)估算不是為了最后那個(gè)數(shù)字，而是弄清楚做什么和怎么做的問題，如果這兩件事情清楚了，但結(jié)果卻是偏偏有人說4天有人說6天，隨便取個(gè)數(shù)就可以了（事實(shí)是應(yīng)該按墨菲定理取6天）。有師傅在，一般很少會(huì)就實(shí)現(xiàn)方法爭執(zhí)不下；有PO在，一般很少會(huì)就要實(shí)現(xiàn)什么爭執(zhí)不下。
不排除有特殊情況比如PO發(fā)現(xiàn)自己也沒想過排行榜憑什么排行，那么就應(yīng)該擱置此用戶故事；又比如大家覺得如果數(shù)據(jù)庫給力可能實(shí)時(shí)排名也行但又拿不準(zhǔn)，可以暫時(shí)擱置到開發(fā)的時(shí)候再說，但把故事上標(biāo)注一下“若需要每周自動(dòng)排名+1天”。如果經(jīng)常黃莊，Scrum Master要分析總結(jié)避免。
6. 四個(gè)人出牌不同，師傅先說還是徒弟先說？
想起個(gè)腦筋急轉(zhuǎn)彎：科學(xué)家 醫(yī)生 士兵 護(hù)士 ……等等一群人在飛機(jī)上，飛機(jī)結(jié)冰快墜落了需要有人（可能不止一個(gè)）跳下去，問誰跳？答案是從體重最重的人開始跳，因?yàn)榭梢陨偬鴰讉€(gè)。
因此我們是出牌數(shù)字最小的先說，和師徒無關(guān)。因?yàn)樗麡O有可能掌握最佳實(shí)現(xiàn)方法。如果后來發(fā)現(xiàn)不是如此，請(qǐng)參考下一條。
7. 都有什么理由可陳述？
按下面的順序，越靠前的越接近真理，感覺自己接近真理的就一定要舉手先說，馬后炮招人嫌：
經(jīng)驗(yàn)事實(shí)：我以前做過……咱們有個(gè)類庫……那個(gè)方法我試過不可行……
蛛絲馬跡：誰還記得上次……聽說隔壁……與上回相比……你以前不是……
邏輯推理：理論上說……我覺得……
幾個(gè)注意事項(xiàng)
1. 小組內(nèi)不要有強(qiáng)分工，否則大家會(huì)缺省認(rèn)為肯定是某人的工作。
2. 師傅不要太搶眼，要通過估算鼓勵(lì)徒弟思考，同時(shí)也掌握徒弟的真實(shí)水平。
3. 師傅不要太較真，編程規(guī)范、易用性、易維護(hù)性這些紀(jì)律不能放松，但如果徒弟想嘗試一種不同但工作量也差不多的方法，可以適當(dāng)鼓勵(lì)。
4. Scrum Master監(jiān)控整個(gè)過程，防止太細(xì)/爭執(zhí)……等問題。
5. PO必須參加。
團(tuán)隊(duì)中常見的一種情況計(jì)劃、估算、設(shè)計(jì)的時(shí)候大家還在一起，但編程的時(shí)候就會(huì)分開。分開看似是安全的，但是卻充滿隱患。
2001年，一位招聘考試前三名（一共120員工）的程序員的兩個(gè)月的成果被徹底放棄重寫，原因是里邊包含3000多個(gè)常數(shù)，而且很難修改（碼流參數(shù)），重寫的人座位距離他只有4米，重寫也只花費(fèi)了2周；2002年，一位月薪7000（那時(shí)候北京房價(jià)才3000多）的程序員編寫了一個(gè)月的4000多行代碼，在一個(gè)下午被重寫為50多行，座位距離他只有5米的項(xiàng)目經(jīng)理疑惑加驚訝地問：“你真的沒學(xué)過c++ template？”。
這就是團(tuán)隊(duì)的距離，即使是高薪聘請(qǐng)來的程序員也難免犯錯(cuò)。難道我們只能避免下一次問題發(fā)生，而不能避免這次問題發(fā)生？
前檢查點(diǎn)
前檢查點(diǎn)就是在做某功能的最初一段時(shí)間，師傅與徒弟結(jié)對(duì)編程，完成最初最重要的設(shè)計(jì)。
“開始做X功能的時(shí)候叫我一聲，咱們敲定一下具體怎么做。”這個(gè)是師傅的前檢查點(diǎn)標(biāo)準(zhǔn)語法。盡管在共同估算的時(shí)候大家還是略有共識(shí)，但是限于計(jì)劃會(huì)的有限時(shí)間，徒弟未必真的知道怎么做。在剛開始的一兩個(gè)小時(shí)里邊，師傅帶領(lǐng)徒弟一起把基本的結(jié)構(gòu)理清楚，最好寫上一些基本代碼，讓徒弟有一個(gè)直觀的概念。
在上面提到的2周的重寫工作中，重寫者和被重寫者一起工作了1.5天，重新設(shè)計(jì)了打包類、遞歸函數(shù)等最難纏的部分；被重寫者在剩下的兩周里邊完成了工作，而且很出色。倘若這一切發(fā)生在兩個(gè)月前該多好。那次事故之后，我們訂立了更嚴(yán)格的代碼審查制度，所有代碼均由部門技術(shù)最好的人審查后才進(jìn)代碼庫；之后再來的新人，均指派師傅，并由師傅保證其代碼質(zhì)量；將人員劃分為需指導(dǎo)的/免于指導(dǎo)的/可指導(dǎo)的/可培訓(xùn)的四級(jí)（10年后我在NEC參觀交流時(shí)發(fā)現(xiàn)了幾乎完全相同的分級(jí)制度）。
前檢查點(diǎn)的工作作用是打下設(shè)計(jì)的基礎(chǔ)，保證工作順利進(jìn)行。如果一切按照前檢查點(diǎn)的設(shè)計(jì)進(jìn)行，徒弟可以繼續(xù)獨(dú)立工作，如果有偏離，要詢問師傅。
前檢查點(diǎn)的學(xué)習(xí)作用是顯而易見的，師傅平時(shí)工作的精華都展示在徒弟面前。而且這種展示是動(dòng)態(tài)的，在結(jié)對(duì)編程的狀態(tài)下，徒弟可以完整地看到師傅是怎樣入手工作，怎樣
后檢查點(diǎn)
后檢查點(diǎn)就是某事做完后，師傅檢查一下徒弟的結(jié)果，保證達(dá)到驗(yàn)收標(biāo)準(zhǔn)。
曾經(jīng)分配給我一個(gè)剛畢業(yè)半年的組員，剛來沒多久就經(jīng)常看到他上網(wǎng)玩，過去一問，原來工作做完了（真的非常快），驚奇之余趕緊看看結(jié)果：功能是有了而且實(shí)現(xiàn)得也很好，就是總有點(diǎn)瑕疵：要么按鈕不正，要么界面上有錯(cuò)字。后來就改成每次任務(wù)完成都趕緊喊我去看看，修正后繼續(xù)下一個(gè)。他后來能力超群，在此公司作為“臺(tái)柱子”10年，現(xiàn)在還在。
其實(shí)多數(shù)新人在大學(xué)中都形成了“能運(yùn)行就行”的概念，并不懂商業(yè)軟件開發(fā)的標(biāo)準(zhǔn)。本人也一樣，畢業(yè)5年還不知道delete內(nèi)存（C++），每次都是多預(yù)留點(diǎn)C盤空間，這樣程序就能多運(yùn)行一段時(shí)間，下班之后關(guān)機(jī)重啟就可以了……這樣的軟件肯定無法在服務(wù)器上長期運(yùn)行的。
后檢查點(diǎn)的工作作用是可用來進(jìn)行代碼審查，以確保軟件產(chǎn)品的質(zhì)量，之后會(huì)提到。
后檢查點(diǎn)的學(xué)習(xí)作用是幫助新人學(xué)習(xí)商業(yè)軟件的開發(fā)標(biāo)準(zhǔn)，逐步養(yǎng)成好的習(xí)慣。
日常工作
除了在任務(wù)前后的時(shí)間點(diǎn)外，日常8小時(shí)也應(yīng)該保持良好的溝通。在一次極端的環(huán)境中，我們?cè)?jīng)將其發(fā)揮到極致。
當(dāng)時(shí)我們以很高的日薪臨時(shí)聘用了兩個(gè)不錯(cuò)的程序員。他們技術(shù)雖然很好，但是卻對(duì)業(yè)務(wù)一無所知，也沒有提前看過文檔。因?yàn)榭偣惨矝]有多少天，當(dāng)然不能把任何一分鐘花費(fèi)在熟悉業(yè)務(wù)上，所以……
1. 每天早上（包括第一天）
整個(gè)軟件被大致分為三類功能區(qū)，互相關(guān)聯(lián)。組長（我）也自己編程，負(fù)責(zé)其中一類功能。
有20分鐘的晨會(huì)，組長會(huì)把一個(gè)簡單的設(shè)計(jì)文檔的一部分拿出來講解給兩個(gè)人，同時(shí)指出今天要做的工作要給予其中的哪些內(nèi)容，他們提問我回答。散會(huì)前我們會(huì)就沒人的工作做一個(gè)簡單的估算（當(dāng)年還不會(huì)撲克牌估算，太可惜了），確保當(dāng)日是可以完成的。
晨會(huì)會(huì)提到技術(shù)問題，而不是每日立會(huì)中說的只說進(jìn)度。但技術(shù)問題一般只涉及到要求，比如“做分段計(jì)價(jià)模型的時(shí)候，不要在C++里邊做For循環(huán)，看能不能在SQL里邊解決，如果解決不了來找我”“好，我試試。（或）這可能嗎？”凡是有問題的就會(huì)稍微深入一點(diǎn)；凡是“我試試”的，都放過，但如果試驗(yàn)的結(jié)果不通就必須找組長討論而不能自行解決。
小組加組長只有3個(gè)人，所以所有人都參加這個(gè)20分鐘會(huì)，包括肯定不做某任務(wù)的人，也聽組長和別人的討論。
2. 每天下午1：30點(diǎn)左右
就是吃飽飯犯困的時(shí)候，組長會(huì)分別和大家在計(jì)算機(jī)前碰頭一下，主要是看當(dāng)日的工作是否可能在下班前完成（堅(jiān)持不加班）；另外就是看是否和晨會(huì)上預(yù)想的一樣。
其實(shí)就算是短短的半天時(shí)間，事情就可能有變。有一次其中一個(gè)程序員在一上午寫了大約4屏幕的代碼（一般每天才寫這么多），而功能卻遙遙無期。原來他不知道有個(gè)函數(shù)可以快速實(shí)現(xiàn)這些功能，正在自己造輪子，他本應(yīng)該告訴組長所遇到的困難。
程序員很少在這個(gè)時(shí)候求助，他們總是相信自己能最終解決問題……因此在轉(zhuǎn)型為自組織團(tuán)隊(duì)的時(shí)候，擔(dān)心程序員會(huì)偷懶的想法整體上是多余的，更需要預(yù)防的是蠻干/過于樂觀/激進(jìn)/需求鍍金/消息閉塞/無法互相學(xué)習(xí)等問題。
3. 每天下午下班前
當(dāng)時(shí)6點(diǎn)鐘有《七龍珠》（工作場(chǎng)所有臺(tái)電視），兩位對(duì)此都很著迷，所以我們基本到點(diǎn)就看片，看完后散伙回家。
因?yàn)橐膊荒茏岆娨暸_(tái)調(diào)整播出時(shí)間，基本上下午5點(diǎn)就要開始打掃戰(zhàn)場(chǎng)：組長分別找兩位，看最終結(jié)果是否完成，并做一下修改。同時(shí)還要做代碼審查（請(qǐng)看下一篇詳述）。
由于估算不會(huì)太準(zhǔn)確，我們專門把所有三不管的小功能梳理出來，誰提前做完了，誰就找其中一個(gè)把剩下的閑工夫占上，結(jié)果其中一位幾乎包攬了全部。
4. 晚上
對(duì)，組長晚上還要工作。在他們走后組長會(huì)在晚上做個(gè)集成，把幾個(gè)人做的功能合成在一起運(yùn)行。當(dāng)時(shí)也沒有持續(xù)集成工具，所以只能手工。
在正常項(xiàng)目的正常團(tuán)隊(duì)中，這個(gè)工作應(yīng)該在第二天的工作時(shí)間完成，也就是說或者找專人（或輪流），或者讓組長做，或者讓自動(dòng)工具做最好。推薦小組內(nèi)輪流負(fù)責(zé)此事，因此可以讓大家理解別人的工作、整體的工作，乃至與組外人員的集成工作等內(nèi)容，為組員成長為組長打下基礎(chǔ)。
5. 隨時(shí)
可以已經(jīng)注意到我們沒有“每日立會(huì)”，一則當(dāng)年還不知道Scrum，二則感覺一個(gè)3～5人的團(tuán)隊(duì)還要靠開會(huì)交流實(shí)在迂腐。比如在篇首提到的兩次事故中，團(tuán)隊(duì)都沒有少開會(huì)，但都因?yàn)槿鄙匐S時(shí)的溝通而導(dǎo)致大錯(cuò)。
其實(shí)任何伸伸懶腰的時(shí)間都可以進(jìn)行溝通。不過一般不要“太隨時(shí)”，應(yīng)該以師傅的時(shí)間為主，也就是如果徒弟遇到了問題，但可以繞過去先走著，就先來一句“我這有問題，有空幫忙看看”+“好，再過15分鐘”。這樣既不會(huì)讓徒弟被卡住，也不會(huì)讓師傅因?yàn)榻?jīng)常被打斷而導(dǎo)致無法工作。但師傅可以隨時(shí)發(fā)起交流，因?yàn)樗麄兪侨椭降艿模牡囊彩峭降艿氖虑椋淮嬖诖驍_的說法。
注：上述部分內(nèi)容僅限于特定環(huán)境中，但思路很多時(shí)候都是可取的。
松結(jié)對(duì)和緊結(jié)對(duì)不一樣，兩個(gè)人不是總坐在一起隨時(shí)發(fā)現(xiàn)問題解決問題，而是很短時(shí)間地坐在一起。其中在后檢查點(diǎn)發(fā)生的主要事情有兩個(gè)：一是看結(jié)果是否符合需求（做什么），而是看代碼是否存在問題（怎么做），后者就是代碼檢查。
代碼檢查（也稱代碼審查Code Inspection）是一種由來已久但是很神秘的東西，最初引入是在一些生命攸關(guān)、重大財(cái)產(chǎn)相關(guān)的軟件開發(fā)中，典型的就是SSOS（美國航天飛機(jī)的軟件），其每段代碼都交由6個(gè)人審閱，方可入庫。成果就是在1989年之前（之后筆者沒有數(shù)據(jù)），SSOS在太空中失效次數(shù)只有一次。筆者親身參與的代碼審查活動(dòng)包括某數(shù)字電視CA系統(tǒng)的代碼審查（25個(gè)程序員只有1個(gè)測(cè)試，已用于CCTV）、某電信計(jì)費(fèi)系統(tǒng)的代碼審查（一周發(fā)現(xiàn)2400個(gè)缺陷）、某電信運(yùn)維系統(tǒng)的審查（2天發(fā)現(xiàn)200個(gè)重要缺陷，其中1個(gè)已困擾團(tuán)隊(duì)5年）、某航空無損檢測(cè)系統(tǒng)的代碼審查（交付后一年內(nèi)客戶只發(fā)生一次失效）。
代碼檢查的基本原理就是相信人腦（而非人眼）是判斷代碼好壞的最好工具，比如如果代碼中有一行：if (i == 1001) return die()的錯(cuò)誤或非法代碼，幾乎無法經(jīng)由測(cè)試包括自動(dòng)測(cè)試發(fā)現(xiàn)，但肉眼卻一目了然。
筆者曾編寫過一個(gè)“復(fù)雜而徹底”的代碼檢查培訓(xùn)教材，但后來發(fā)現(xiàn)過于復(fù)雜而且還不徹底，所以作罷。下面將要介紹的是一種業(yè)余但卻有效的代碼審查方法。
-----------------------------------------------------------------------
程序員的質(zhì)量觀
有人曾把程序員分為四級(jí)：編寫可用軟件（大致是大學(xué)在校生的狀態(tài)），編寫可靠軟件（大致是好一些的職業(yè)程序員的狀態(tài)），編寫精美軟件（在簡單性/可維護(hù)性/可復(fù)用性上有所突破），編寫思想深邃軟件（設(shè)計(jì)模式、MVC、JQuery及早期OLE、RPC等創(chuàng)始者所做的事情）。
但在現(xiàn)實(shí)中，卻往往發(fā)現(xiàn)很多程序員停留在第一層次：“你測(cè)吧，測(cè)出缺陷來我改”“這個(gè)不用改也能運(yùn)行”“這么編就是難讀點(diǎn)而已”，師徒間的代碼檢查，就是把程序員從第一級(jí)別向上提高的過程。
第一段提到的25個(gè)程序員+1個(gè)測(cè)試人員的團(tuán)隊(duì)是01年我們所在的團(tuán)隊(duì)，當(dāng)時(shí)保持了良好的質(zhì)量風(fēng)氣。尤其由于大家知道沒有測(cè)試人員擦屁股，留下缺陷相當(dāng)于給自己找麻煩，所以大家不得不習(xí)慣自己動(dòng)手防患于未然。這個(gè)產(chǎn)品后來發(fā)展勢(shì)頭很好，07年曾占據(jù)市場(chǎng)60%（之后不詳）。
怎樣檢查
“高手本來自己就要開發(fā)很多代碼，還要替新手檢查代碼，多花費(fèi)時(shí)間啊……”這是一個(gè)常見問題，答案是：“每天，在后檢查點(diǎn)，花費(fèi)不超過15分鐘時(shí)間，能看出什么來就說什么，時(shí)間到了就停。”
一般而言，大致每天高手能編寫100多行有效代碼（按分號(hào)計(jì)數(shù)），新手會(huì)多一些但也不超過200（他們編寫代碼比較費(fèi)時(shí)），也就是10個(gè)屏幕以內(nèi)。有經(jīng)驗(yàn)的人一定知道：高手看新手的軟件，5秒鐘就能發(fā)現(xiàn)問題。
常存在的一種情況是高手“看不懂”新手的代碼，當(dāng)然不是因?yàn)榧夹g(shù)太精妙了，而是寫得太亂了。但在松結(jié)對(duì)編程里邊不存在，由于師傅徒弟天天在一起，這200行代碼可謂一目十行，如果以往一直每天檢查代碼，那么里邊存在的問題應(yīng)該不會(huì)很多。
檢查什么
這個(gè)是重點(diǎn)，整體包括：
1. 結(jié)構(gòu)問題
代碼最大的問題，不是一兩個(gè)地方有技術(shù)缺陷，也不是業(yè)務(wù)邏輯錯(cuò)誤，而是整個(gè)軟件編寫的不好。前兩者都可以通過測(cè)試或使用來發(fā)現(xiàn)和更正，但后者就不同了。如果回想一下自己見過的各種爛攤子，是不是有同感？具體哪里有問題怎么改說不上來，就是整個(gè)軟件看上去混亂無章，無從下手。
具體結(jié)構(gòu)問題包括：重復(fù)拷貝代碼（不封裝函數(shù)，不用Template/泛型……），函數(shù)過長（超過一屏幕就叫過長），錯(cuò)誤封裝（不恰當(dāng)?shù)膒ublic/不用Interface/不內(nèi)聚/強(qiáng)耦合/在類中封裝了無關(guān)方法……），內(nèi)容錯(cuò)誤（多個(gè)無關(guān)類置于一個(gè)文件/不恰當(dāng)?shù)拿?hellip;…）等等。
改正結(jié)構(gòu)問題，是從編寫可靠軟件向編寫精美軟件邁進(jìn)的重要方法。
2. 業(yè)務(wù)邏輯問題
就是軟件是否與需求的要求符合的問題。師傅和徒弟經(jīng)常對(duì)業(yè)務(wù)需求的理解有差異，借此機(jī)會(huì)同步一下，必要時(shí)引入PO（產(chǎn)品經(jīng)理/策劃人員……）。
有人會(huì)說業(yè)務(wù)邏輯問題不是一測(cè)試就知道了嗎？可是測(cè)試一般發(fā)生在很久以后，有些邏輯測(cè)試還需要一定的觸發(fā)條件，而且測(cè)試只會(huì)發(fā)現(xiàn)失效（failure, 與預(yù)期不符）而不能發(fā)現(xiàn)缺陷（defect, 具體哪里出了錯(cuò)），等積累長了，誰也找不到原因了。
3. 編程素養(yǎng)問題
很多問題屬于那種“這樣也行那樣也行”的狀態(tài)，比如命名/初始值/縮進(jìn)/斷行……但是高手的做法總是比新手好一些。
比如bool result = true; 這句話就有問題，剛初始化就先宣布成功，必有隱患。這是一個(gè)真實(shí)案例，而下面也的確有一個(gè)分支錯(cuò)誤地返回了這個(gè)true（實(shí)際案例是個(gè)HRESULT）。而發(fā)現(xiàn)這個(gè)問題，不是測(cè)試而是代碼檢查。實(shí)際上測(cè)試幾乎發(fā)現(xiàn)不了這些問題，比如上面那段代碼會(huì)在某文件打不開的時(shí)候錯(cuò)誤地返回這個(gè)true，而在測(cè)試中幾乎不會(huì)故事破壞那個(gè)文件來測(cè)試其結(jié)果。
實(shí)際使用時(shí)，不用拉太長的清單，師傅能想到的看到的告訴徒弟就行。
徒弟不需要學(xué)到天上去，只要能學(xué)到師傅那么好就可以了。之前在做CMMI咨詢的時(shí)候我弄過一些檢查表，推廣均以失敗而告終。那些表都是為了頂級(jí)安全性的軟件考慮的，在普通項(xiàng)目里邊使用是個(gè)災(zāi)難。
幾個(gè)問題
1. 師傅天天檢查，會(huì)不會(huì)很累？
檢查不全是為了發(fā)現(xiàn)缺陷，而是為了提高成長。如果總是發(fā)現(xiàn)重復(fù)問題，此徒不可教。好學(xué)的徒弟有半年時(shí)間就能接近師傅了，考慮到師傅一般比徒弟多工作2年，我們因此讓一個(gè)人加速1.5年。
2. 不會(huì)餓死師傅嗎？
會(huì)，也不會(huì)。如果師傅止步不前，即使他不教別人，也遲早被人超越；師傅也是需要學(xué)習(xí)的。事實(shí)是會(huì)教徒弟的師傅才會(huì)學(xué)習(xí)，而會(huì)學(xué)習(xí)的師傅才會(huì)教徒弟。
3. 師傅跟誰學(xué)？
師徒制度是最底層團(tuán)隊(duì)制度（1個(gè)師傅+1～3個(gè)徒弟左右），其上還有更大的結(jié)構(gòu)和更高的高手。我們之前曾把人員層次設(shè)為需指導(dǎo)的（徒弟）/可免于指導(dǎo)的（也是徒弟）/可提供指導(dǎo)的（師傅）/可培訓(xùn)的（團(tuán)隊(duì)最高級(jí)別的高手），最后一級(jí)需要定期與大家分享內(nèi)容。
師傅作為高級(jí)技術(shù)人員，還享有機(jī)會(huì)外出培訓(xùn)/采購圖書等待遇。
師傅自學(xué)也很重要，經(jīng)驗(yàn)更是不可取代的。前事不忘后事之師，要把自己的經(jīng)歷和別人的經(jīng)歷都當(dāng)作經(jīng)驗(yàn)來看待。
4. 師傅努力編好自己的軟件不久已經(jīng)有很大貢獻(xiàn)了，為何要幫助徒弟？
軟件整體是一個(gè)串聯(lián)系統(tǒng)，一個(gè)環(huán)節(jié)出了問題整個(gè)軟件崩潰（Web軟件好一些）。因此軟件質(zhì)量取決于最差的部分，而不是最好的部分。
代碼審查的確會(huì)占用時(shí)間導(dǎo)致最好的部分變差，但卻使最差的地方變得好得多，整體質(zhì)量因此而得以提高。
------------------------------------------------------------
從工作層面講，代碼檢查使得代碼的質(zhì)量尤其是結(jié)構(gòu)質(zhì)量，整體上保持在師傅可能達(dá)到的水平，從而保證了項(xiàng)目的成功。
從學(xué)習(xí)層面講，代碼檢查使得徒弟可以不斷/漸進(jìn)地學(xué)習(xí)，從而花費(fèi)遠(yuǎn)遠(yuǎn)低于師傅的時(shí)間成本達(dá)到更高層次。
心態(tài)是其中的關(guān)鍵。徒弟不能因此而覺得有一個(gè)后盾了可以放任存在問題等師傅發(fā)現(xiàn)，要珍惜師傅的時(shí)間，也要利用師傅的時(shí)間每次都學(xué)不同的內(nèi)容；師傅也不能覺得徒弟學(xué)會(huì)了對(duì)自己是個(gè)威脅，威脅時(shí)刻都在，不來自于自己的徒弟，也會(huì)來自于別人的徒弟，唯有自我提高。
至此所有實(shí)踐層面的內(nèi)容基本上都寫完了，下一篇將提到一些“139團(tuán)隊(duì)”的問題，所謂“139團(tuán)隊(duì)”就是一個(gè)使用松結(jié)對(duì)編程工作方式的大型團(tuán)隊(duì)。
松結(jié)對(duì)編程是小型團(tuán)隊(duì)的實(shí)踐，大約運(yùn)行在1個(gè)師傅+1～3個(gè)徒弟的尺度上，當(dāng)面臨更大尺度的時(shí)候，就需要大型團(tuán)隊(duì)模型。這里推薦139團(tuán)隊(duì)模型，因?yàn)樗坏梢宰屗山Y(jié)對(duì)編程運(yùn)轉(zhuǎn)順利，還解決了大團(tuán)隊(duì)溝通、績效考核、師傅的出路等問題。
139團(tuán)隊(duì)的整體情況相當(dāng)復(fù)雜，將另有系列博文描述，這里只描述與“松結(jié)對(duì)編程”相關(guān)的內(nèi)容，以保證本系列博文的完整性。
基本概念
139團(tuán)隊(duì)就是1個(gè)項(xiàng)目經(jīng)理，3個(gè)師傅，9個(gè)徒弟的簡稱，當(dāng)然實(shí)際上未必正好湊夠13個(gè)人，也未必正好每個(gè)師傅都有3個(gè)徒弟。
在第一篇里邊已經(jīng)提到過三個(gè)層級(jí)的工作關(guān)系，下面是一些深入的剖析。
績效考核
績效考核歷來是軟件業(yè)最頭痛的問題，按代碼行考核吧新程序員寫的垃圾代碼比高手多，按任務(wù)數(shù)考核吧任務(wù)大小不一，按功能點(diǎn)考核吧多數(shù)人不會(huì)數(shù)，按工作按時(shí)完成率考核吧師傅還幫不幫徒弟了？……139團(tuán)隊(duì)大致有個(gè)答案：按1-3-9的層次安排大致薪金和獎(jiǎng)金比例（在139團(tuán)隊(duì)系列中有詳細(xì)分析）。
139團(tuán)隊(duì)認(rèn)為績效考核首先是團(tuán)隊(duì)的整體績效；在分解到個(gè)體時(shí)，不是看具體每個(gè)人干活多少，而是看在團(tuán)隊(duì)中所起的作用。
所以，想加薪？帶徒弟吧。不過有一點(diǎn)，帶一隊(duì)沒用的徒弟是沒用的，首先要有團(tuán)隊(duì)績效，才會(huì)有個(gè)人績效。
人員招聘
人員招聘一般在較高層進(jìn)行，最低也是項(xiàng)目經(jīng)理，但是最終帶新人的卻是師傅。所以招聘的時(shí)候應(yīng)該請(qǐng)未來的師傅也在場(chǎng)，部門經(jīng)理/項(xiàng)目經(jīng)理可以問師傅“這個(gè)人給你當(dāng)助手，你覺得夠嗎？”這個(gè)問題我最近正好問過，師傅的話語權(quán)很重，因?yàn)槿绻幌矚g，下面的配合會(huì)很難。如果是招聘師傅，項(xiàng)目經(jīng)理心里要對(duì)此人和現(xiàn)有師傅水平的高下比較有個(gè)概念，尤其是溝通和教學(xué)能力。
師徒的差異既不能太大，也不能太小。太大學(xué)不明白，白耽誤師傅的功夫；太小沒什么可學(xué)，還可能引發(fā)沖突（經(jīng)常半斤大戰(zhàn)八兩，如果其中一個(gè)是二兩就打不起來了）。如果理解了松結(jié)對(duì)編程的上述實(shí)踐，在遇到實(shí)際人員的時(shí)候?qū)嶋H情況實(shí)際分析一下就可以了。
職業(yè)生涯規(guī)劃
徒弟學(xué)好了可以做什么？可以獨(dú)立工作，比如新出現(xiàn)一個(gè)模塊或業(yè)務(wù)，可以單獨(dú)交給此人開發(fā)（要配代碼審查人）；做得更好了可以做師傅，帶徒弟。
師傅學(xué)好了可以做什么？可以做項(xiàng)目經(jīng)理。比如如果有個(gè)師傅帶了多達(dá)3～5個(gè)徒弟，而且還想增加人，那么他的那個(gè)模塊多半要分拆為一個(gè)子項(xiàng)目了，而分拆后，師傅是新項(xiàng)目經(jīng)理的最佳人員。
之前呆過的一家高成長性公司，去的時(shí)候只有18人，一年半以后就達(dá)到120人了，而業(yè)務(wù)骨干多半都是當(dāng)年的徒弟，而不是新招來的高手。究其原因，一則業(yè)務(wù)壁壘不是剛招來的高手能突破的，二則師徒制度使人成長很快。最初大家并沒有正式的師徒制度，但是項(xiàng)目經(jīng)理無私地指導(dǎo)大家，為團(tuán)隊(duì)成長和后來建立師徒制度建立了條件。本人剛?cè)サ臅r(shí)候工作五年了，還不知道申請(qǐng)的內(nèi)存要?jiǎng)h除（C++），現(xiàn)在的編程功底基本上都是在這家公司學(xué)成的。
主程序員團(tuán)隊(duì)
如果遇上一個(gè)頂十個(gè)的師傅，也有團(tuán)隊(duì)模型就是主程序員團(tuán)隊(duì)。師傅干活，徒弟打雜+學(xué)習(xí)。本人用過兩次半，都很成功。主程序員團(tuán)隊(duì)的工作方式更“松”，但也有其工作模式和師徒制度。
主程序員團(tuán)隊(duì)不如松結(jié)對(duì)編程團(tuán)隊(duì)健康和有潛力，個(gè)人感覺只適合某些情況。
本文未涉及的139團(tuán)隊(duì)內(nèi)容
自組織團(tuán)隊(duì)的激勵(lì)機(jī)制，大型團(tuán)隊(duì)的計(jì)劃會(huì)，大型團(tuán)隊(duì)的每日立會(huì)，大型需求團(tuán)隊(duì)與開發(fā)團(tuán)隊(duì)的配合，強(qiáng)分工團(tuán)隊(duì)的工作方式，139團(tuán)隊(duì)詳細(xì)的績效考核/非物質(zhì)激勵(lì)等內(nèi)容，將在139團(tuán)隊(duì)系列中展開討論。
-----------------------------------------------
139團(tuán)隊(duì)是應(yīng)用松結(jié)對(duì)編程的大型敏捷團(tuán)隊(duì)，在其3-9級(jí)別上適合松結(jié)對(duì)編程過程，而在整個(gè)層面上適合Scrum過程。
139團(tuán)隊(duì)解決了績效考核、人員招聘、職業(yè)生涯規(guī)劃等一些大團(tuán)隊(duì)問題，從而為小團(tuán)隊(duì)（師徒團(tuán)隊(duì)）應(yīng)用松結(jié)對(duì)編程和日后健康成長鋪平道路。
本文是“敏捷開發(fā)松結(jié)對(duì)編程實(shí)踐”的最后一篇，本系列所屬實(shí)踐僅適用于幾個(gè)開發(fā)人員的微觀環(huán)境，其外圍大型團(tuán)隊(duì)的實(shí)踐請(qǐng)參考“大型敏捷開發(fā)團(tuán)隊(duì)：139團(tuán)隊(duì)模型”系列。
------------------------------------------------
后記
任何開發(fā)方法都有局限性，也都有可取之處，松結(jié)對(duì)編程也不例外。
筆者在多年開發(fā)及咨詢過程中，逐漸發(fā)現(xiàn)所有研發(fā)方法都會(huì)遇到困難，而所有研發(fā)方法經(jīng)過變形都可以某種方式應(yīng)用下來。關(guān)鍵問題在于，在遇到困難的時(shí)候不要因?yàn)槔щy而否定方法，而要積極為解決困難尋找答案。格言說得好：不是缺少發(fā)現(xiàn)問題的眼睛，而是缺少解決問題的手。
松結(jié)對(duì)編程本身就是在實(shí)際環(huán)境中應(yīng)用敏捷開發(fā)和結(jié)對(duì)編程的時(shí)候遇到困難后的變形，所以在應(yīng)用松結(jié)對(duì)編程的時(shí)候如果遇到困難時(shí)，辦法只有一個(gè)：繼續(xù)變形。
敏捷開發(fā)傳入中國已經(jīng)10年了，但是如果問哪家企業(yè)非常成功地應(yīng)用敏捷開發(fā)，誰能出來好好地講講案例，幾乎無一能者。究其原因無外乎兩個(gè)：
1. 過于迷信方法，因此嘗試原封不動(dòng)地使用方法，結(jié)果水土不服遭到失敗。
2. 過于不迷信方法，嘗試失敗后就輕易放棄。
整個(gè)過程中最容易被忽略的，是實(shí)踐者自身的創(chuàng)造力。其實(shí)早在創(chuàng)建Scrum的時(shí)候，Ken就指出Scrum只是一個(gè)起點(diǎn)，他建議人們從原裝的Scrum入手以保持穩(wěn)定的過程框架，并進(jìn)而自行發(fā)揮。但多數(shù)人在應(yīng)用時(shí)，都過于喜歡查書，百度，google，找培訓(xùn)課程，看博客——包括這里，只要還找不到的，也不再嘗試不再創(chuàng)新，這就背離了創(chuàng)始人的初衷。
剛剛參加完MPD 2011深圳站，在演講中間及后來媒體采訪，被問到了一些問題，也給出了答案，這里做一總結(jié)。
我自問自答到一半，才發(fā)現(xiàn)這里邊的很多問題的答案，都用到了火星人諺語系列之一：有問題的地方無答案、火星人諺語系列之三：正確的答案一定簡單。如果您覺得答案和自己的情況不完全相符，請(qǐng)用火星人諺語系列之二：問問題的人負(fù)責(zé)找答案。
另外多數(shù)答案在本系列1～6中有，只是比較分散，不太容易意識(shí)到是答案。
人員與結(jié)構(gòu)
在團(tuán)隊(duì)中使用層級(jí)結(jié)構(gòu)，是否阻礙了個(gè)體與外界的溝通？
極少有底層程序員或新手能和產(chǎn)品經(jīng)理做深入的溝通的，所以中間放上師傅這一層，讓其代為問問題，徒弟旁聽，不但不會(huì)阻礙，反而會(huì)促進(jìn)。
這樣徒弟可以更快地學(xué)會(huì)問答技巧或熟悉業(yè)務(wù)，真正學(xué)成了，師傅才懶得在中間“阻礙”呢，呵呵。
師傅又要懂業(yè)務(wù)，又要懂技術(shù)，又要帶徒弟，是否要求太高了？
的確不低，但是如果不要求這三個(gè)師傅如此，就要要求全組如此，更難；當(dāng)然可以要求讓程序員們可以不懂業(yè)務(wù)，但這樣的程序員怎么放心讓他干活呢。
但實(shí)際上，這點(diǎn)要求算不上什么，和“多才多藝”二字沾不上邊。所以這種人其實(shí)很多，只是他們沒被賦予這種職能而已。
師與徒
高手不愿意帶徒弟怎么辦？
所謂求什么得什么，如果企業(yè)給個(gè)人能力高的人發(fā)高薪，而不給能帶團(tuán)隊(duì)的人發(fā)高薪，屋子里邊坐著的一定是一堆不愿意帶徒弟的高手；反之則反。
另外一個(gè)角度，139團(tuán)隊(duì)不只是一個(gè)學(xué)習(xí)團(tuán)隊(duì)，而首先是一個(gè)生產(chǎn)團(tuán)隊(duì)。師傅帶徒弟，一定程度上有上級(jí)帶下級(jí)的感覺。還沒有一個(gè)上級(jí)不希望自己有更多手下的，也沒有上級(jí)希望自己手下都是飯桶的。
所以制度合適，人自然改變。
招聘了徒弟，沒有師傅愿意帶怎么辦？
以往人是招聘來塞給某人“你負(fù)責(zé)他的成長的”，現(xiàn)在應(yīng)該是有師傅說“忙不過來了，給我招聘個(gè)徒弟吧”。師傅要參與徒弟的招聘和試用。
徒弟不聽師傅的怎么辦？
試用期就走人。
時(shí)間與效率
師傅一個(gè)頂仨，照顧別人是否降低效率？
要做好時(shí)間管理，就是師傅找徒弟隨時(shí)，徒弟找?guī)煾殿A(yù)約（“我有問題……”“好，等15分鐘……（繼續(xù)干活至一段落為止）”）。
一個(gè)人看那么多人的代碼，會(huì)不會(huì)很花時(shí)間？
高手看新手的代碼，10分鐘就能看到一大堆錯(cuò)誤。
師傅看徒弟的代碼，5分鐘就行；每天早上做了設(shè)計(jì)，中間還有前后關(guān)鍵點(diǎn)，沒什么可看的。
今天看到的問題，明天不可再見，早晚一天無問題可見。師傅是培養(yǎng)徒弟干活的，不是給徒弟擦屁股的（在試用期就要考核這個(gè)，不怕起點(diǎn)低，但一個(gè)人連培養(yǎng)價(jià)值都沒有，還能干啥）。
專家與雜家
大家需要了解的東西太多，生產(chǎn)率是否降低？
我見過的最高的幾個(gè)高手，都是以更廣泛地了解業(yè)務(wù)和技術(shù)為特點(diǎn)的。
我見過一個(gè)13個(gè)人的團(tuán)隊(duì)，9年來人換了好幾批了，從來都是每人只負(fù)責(zé)的功能，都是“專家”。產(chǎn)品最后有25萬行，被一個(gè)高手花一年半改為1.3萬行。問為什么原來的代碼那么多，答：“原來的專家走了，沒人能看懂其代碼，所以只能大面積拷貝粘貼。”這樣的專家，要他何用。
有些人希望只專注于自己的工作，怎么辦？
目光這么窄的人，能做好自己的工作才怪；所知這么窄的人，能委之重任才怪；一直自己干活的人，能管理部門才怪。很多人苦苦鉆研技術(shù)，希望能力提高然后被提拔，實(shí)在是緣木求魚。道理一講就通。
如果還講不通，遲早會(huì)發(fā)現(xiàn)不想當(dāng)將軍的士兵，連廚子都做不好的，呵呵。
績效與成長
師傅學(xué)不到東西怎么辦？
師傅之上還有師傅；師傅人數(shù)少，可以送去培訓(xùn)……師徒制度里邊沒有關(guān)于師傅怎么學(xué)習(xí)的內(nèi)容，但如果理解“有問題處無答案”，這類問題很好解決。
教會(huì)徒弟，會(huì)不會(huì)餓死師傅？
如果我是老板，我會(huì)喜歡下金蛋的鵝，勝過金蛋，因此給鵝更多錢。
如果我是師傅，我會(huì)喜歡賣金鵝蛋，勝過賣烤鵝腿，因此能值更多錢。
如果我是徒弟，我會(huì)羨慕下金蛋，勝過我就是個(gè)蛋（好慘啊）。
徒弟的能力超過師傅怎么辦？
我的編程能力超過我?guī)煾档臅r(shí)候，他做部門經(jīng)理去了，因?yàn)槲覀儾块T的所有師傅，都是他的徒弟，不選他選誰。
能力的不總是等于編程能力，而是一種在不同年齡不同層次有不同定義的東西，只有這種東西才能叫做能力。
上面這句話套用金剛經(jīng)語法，就是“如來所說能力，則非能力，是名能力”，剛開始很難理解，但理解了就發(fā)現(xiàn)是一種很通用很有效的思維方式。
比如把“創(chuàng)新”帶進(jìn)去，就會(huì)得到喬布斯的創(chuàng)新觀：我們蘋果所說的創(chuàng)新（價(jià)值觀創(chuàng)新），是不能被模仿的創(chuàng)新，所以才叫做創(chuàng)新（換言之能被那么容易模仿的，還談不上什么創(chuàng)新）；你們模仿iPod，我就做iPhone，你們模仿iPhone，我就做iPad；你們模仿iPad，我就得胰腺癌……
因?yàn)?strong>何為“能力”，怎樣根據(jù)“能力”確定師傅和徒弟，根據(jù)什么“能力”來考核師徒，是139團(tuán)隊(duì)和松結(jié)對(duì)編程的核心，所以多說兩句。
個(gè)人感覺凡是不違背敏捷之神的研發(fā)管理方法，均為敏捷。所有敏捷的實(shí)踐者，都應(yīng)該在敏捷的大框架下，跟著自己直覺和本能的引導(dǎo)，去創(chuàng)造適合自己的敏捷實(shí)踐方法。
it知識(shí)庫：敏捷開發(fā)“松結(jié)對(duì)編程”實(shí)踐，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
