新人其實很少偷懶，因為一方面正處於入門學習的高峰期，另一方面工作時間不長，需要得到企業和團隊的認可。可為何他們工作總是不得力呢？
新人的真正問題在於無心辦錯事和好心辦錯事。
無心辦錯事包括沒學過某種好的方法、不知道企業已經有某些可用**或庫、不懂業務等種種問題。
好心辦錯事包括想做乙個比領導想想的更好的功能、過度思考了可復用性可維護性等。
這兩個問題筆者都經歷過（作為新人和老人），「避免」是最好的方法，而不是事後改正，這就需要在設計階段和計畫階段從技術、管理兩個方面來提前預防。
技術：輕量級設計
如果要把乙個任務分配給乙個「不放心的人」，有兩種辦法保證成功：師傅把設計做出來交給徒弟做，但是「設計文件」的詳細程度很難把握，寫少了做 不出來，寫多了等做出來了很多內容又多餘了；師傅徒弟結對程式設計，但是很占用師傅的時間，尤其是倘若徒弟「實際上」（可惜只有上帝知道）完全可以勝任這個任 務。
有兩種解決方法。
1. 事前輕量級設計：預想陳述（有點隱喻的意思）
預想陳述是微軟很久以前就使用的一種方法，任何人（不只是徒弟）有什麼設計，不用寫下來因為太費時間了而且還可能被拋棄，而是給大家講一下。大 家會給出評價和意見，以保證其正確性。然後此人就按這種方法去實現了，倘若成功了也被認可了，就簡單寫下來以供日後參考使用。由於系統已經存在，這個簡單 寫下來的設計可以真的很簡單。
在「松結對程式設計」裡邊，有兩種類似的做法。
一種是師傅把自己的想法告訴徒弟（一般用乙個白板，或一張白紙），徒弟提問師傅回答，到差不多為止。
二種相反，徒弟講給師傅聽，師傅師傅質疑和指導，到差不多為止。
兩者都不要事先形成永久文件，但都在被證明可行（就是編碼完成後）寫乙個簡單文件記錄。任何**之外的能幫助理解當時做法的文字/都可以稱為文件，沒有字數限制。如果能和使用者故事放在一起則更好，乙個描述做了什麼，乙個描述怎麼做的。
2. 前檢查點
就是在某事開始的時候進行臨時結對程式設計。一般發生在某個功能剛開始做的時候，詳情會在之後的「日常活動篇」做詳細描述。
管理：共同計畫（共同估算，撲克牌估算）
預想陳述、前檢查點雖然已經很輕量級了，但是如果師傅和徒弟都剛剛對需求（使用者故事）有所了解，還給不出很清晰的思路的時候，比如在scrum 計畫會上，怎樣快速知道徒弟有沒有理解需求，有沒有大致的實現思路呢？那就是共同估算（撲克牌估算是共同估算的一種最好的實現形式）。
1. 共同估算
共同估算的原理和做法還是很複雜的，這裡只簡單說說，以後會有文章詳細講述。
共同估算就是師傅和徒弟基於相同的資訊（一般是在計畫會上聽po講完故事的時候），一起說出自己認為做完這件事情需要多久。基本原理是：若兩個人對某件事情的工期認識是相同的，那麼他們的實現方法不分高下，用哪種方法都差不多。
為了防止人云亦云，一般需要採用匿名方法，而撲克牌估算就實現了高效有效的共同匿名估算（另有文章詳述）。
2. 驗收標準
為了基於相同的目標建立共同估算，也為了防止需求鍍金或最終軟體不能滿足需求，師傅和徒弟要建立對需求的共同理解。
簡單方法就是兩者（其實是師傅和多個徒弟）一起參加估算會，一起聽po講解故事。但最好是在此之後，建立乙個「文件化」的驗收標準。比如在一張 故事卡/excel表裡……上寫上「需整合；無效能要求……」等最簡單的描述（請參考本部落格的敏捷開發分類下一片關於驗收標準的文章）。
共同估算+驗收標準，使得師傅和徒弟（推廣為高手和新手）使用大致相同的方法，做大致相同的東西。共同估算既是乙個工作的過程，也是乙個學習的過程，因為在理解做什麼和怎麼做的同時，徒弟也向師傅學到了東西。
敏捷開發「松結對程式設計」實踐 問題集
剛剛參加完mpd 2011深圳站，在演講中間及後來 採訪，被問到了一些問題，也給出了答案，這裡做一總結。我自問自答到一半，才發現這裡邊的很多問題的答案，都用到了火星人諺語系列之一 有問題的地方無答案 火星人諺語系列之三 正確的答案一定簡單 如果您覺得答案和自己的情況不完全相符，請用火星人諺語系列之二...
敏捷開發松結對程式設計之七問題集錦
size medium b color blue 人員與結構 color b b 在團隊中使用層級結構，是否阻礙了個體與外界的溝通？b 極少有底層程式設計師或新手能和產品經理做深入的溝通的，所以中間放上師傅這一層，讓其代為問問題，徒弟旁聽，不但不會阻礙，反而會促進。這樣徒弟可以更快地學會問答技巧或熟...
敏捷開發「松結對程式設計」系列之七 問題集之一
本文是 松結對程式設計 系列的第七篇。之一，之二，之三，之四，之五，之六，之七，之八 剛剛參加完mpd 2011深圳站，在演講中間及後來 採訪，被問到了一些問題，也給出了答案，這裡做一總結。我自問自答到一半，才發現這裡邊的很多問題的答案，都用到了火星人諺語系列之一 有問題的地方無答案 火星人諺語系列...