看過很多團隊，在補進新人時給了魚之後就放生菜鳥。好像拿了些素材給他，他就能上手，但其實這是很不負責任的行為。
如果你在乎的是盡快讓菜鳥成為即戰力，熟悉產品、熟悉系統架構、熟悉開發規範、熟悉產品開發中得接觸到的各個角色、熟悉整個開發流程，你就不該在一開始的三個月把他排除在團隊之外。
而是在一開始就讓他加入團隊，當個觀察者、學徒、活水，甚至讓他貢獻出一些價值，例如發現過去團隊看不見的盲點，針對團隊習以為常卻不合理的部份提出疑問。
而 Pair Programming 是一種已知很有效果的方式，來讓菜鳥能扎實地融入團隊。
過去常見的作法
- 給菜鳥 wiki、給 power point、給之前 training 的影片、給 spec、給 API document、給 repository source code，然後放生。（不要來煩我）
- 指派簡單的 ticket 給菜鳥，然後壓時間，不期待他能完成或有產出，幾天後在跟他同步。（這段時間不要來煩我）
- 開幾場制式的 training，參加完 training 就期待菜鳥該理解一定的程度，就該自己有能力滿足需求、解決問題。
- 新手村集中營，制式的 training 跟練習，考試測驗程度。
Pair Programming 養成法假設
- 3人以上團隊 + 1位菜鳥
- 養成期 3 個月
- 假設菜鳥 3 個月內無戰力（甚至負戰力，寫了還要其他人花時間看跟改）
- 如果有類似 scrum 的協作模式更好
新手村三個月通用事項
- 菜鳥須全程參與團隊的活動，例如 Daily Scrum, Sprint planning, Refinement meeting, Retrospective, Review meeting
- 盡可能由菜鳥來做各會議的摘要總結
- 針對菜鳥的摘要總結、疑問、答案，隨機往下繼續詢問，讓他發現自己不知道的東西
- mentor 最好已經在公司半年以上
- 團隊共識：養成新人是團隊的共同且重要事項
- 如有整批多人新人加入，有共同的 training，菜鳥還是得先參加 training
- 菜鳥可以有個「疑問與待辦清單」，讓團隊都可以直接看得到，並適時建議項目的順序排列
- pair 過程中，盡可能避免影響到 sprint backlog 中最高優先序 item 的進度
第一個月
- 每一周都有一位 mentor 跟菜鳥 pair，建議每一周換一位 mentor 進行 pair
- pair 過程中，主要由 mentor 撰寫代碼，菜鳥遇到不理解的部份，可即時或記下等會發問。
- mentor 寫一段落後，讓菜鳥發問，回答疑問，反問相關問題。菜鳥沒有疑問，就由 mentor 提問。
第一個月的最後一週
- 菜鳥整理這個月的 4L (Liked – Learned – Lacked – Longed For)
- 由 mentors 給予反饋（好的、待改善）
- 菜鳥擬出待改善的行動計畫
第二個月
- 菜鳥挑一位適合的 mentor 一起 pair 一個月
- mentor 當 navigator, 菜鳥當 driver。由菜鳥來寫代碼，但是是 mentor 說什麼，菜鳥寫什麼。
- mentor 可適時詢問菜鳥，打算怎麼寫。如果菜鳥沒問題，mentor 就問問題。
- 第二個月最後一次 retrospective 由菜鳥對團隊提出一個 CSS (一件 Continue, 一件 Stop, 一件 Start) 的建議
- 由 mentor 給予反饋（好的、待改善）
- 菜鳥擬出待改善的行動計畫
第三個月
- 依據 backlog item 跟團隊其他人進行 pair
- 建議由菜鳥主動說明打算怎麼做，也先由菜鳥來寫，mentor 即時引導、提問、建議、示範
- 最後一週，菜鳥針對產品(or 專案) domain、系統架構/共用元件、開發規範（含團隊公約、DoD等等...）、協作流程，做一個簡報，用以呈現菜鳥對這些的理解程度。簡報只須報告重點，由與會者提問，重點在促進溝通與交流。
- 每個跟菜鳥 pair 過的成員，最後都須給菜鳥評分（試用期團隊接受程度）、反饋、建議
- 整理出菜鳥 top 1~3 的待辦事項（先 grouping post-it, 接著團隊成員投票），當作後續加強或學習方針
以上事項，沒有絕對，我只是先提供個比較具體的描述讓大家有感，重點是達到真實的目的：「讓菜鳥盡快融入團隊、成為戰力、貢獻價值」
補充
- 把菜鳥加入的時間點，當作補全、調整產品與團隊知識庫文件的契機也不錯
- 如果團隊裡面有人想要練習 presentation 或 training，這也是個練習的好時機
- 這樣三個月下來，菜鳥對團隊如何開發產品的流程、方式、規範，對應的角色、產品的功能、系統架構，團隊內部人員的熟悉度，產品的進度，團隊碰到的問題，菜鳥都是其中一份子的參與者，這會讓他更快進入狀況，融入團隊，建立對應的 ownership，也可以針對實務上不足的部份，優先進行強化即可。
友善提醒
有些朋友會提到，我們的專案時程很趕，所有成員趕進度都沒時間了，哪還有空帶新人。
那麼您們該回頭想想，為什麼要補進新人？如果補新人是為了解決眼前這麼吃緊的時程，那建議去翻翻《人月神話》，這是在自取滅亡。
給菜鳥一些素材之後放生，是一件很不道德、沒意義、沒效果的事，這只是在把該花的功夫，拖到試用期三個月結束後來償還原本該做的事。
那一開始最重要的三個月時間就白費了，而且，相信我，三個月之後，你專案的時程還是這麼吃緊的。
時程問題跟補人，可以參考我之前這一篇文章：《Scrum Estimation－Scrum Estimation Model》
blog 與課程更新內容，請前往新站位置：http://tdd.best/
