看過很多團隊,在補進新人時給了魚之後就放生菜鳥。好像拿了些素材給他,他就能上手,但其實這是很不負責任的行為。
如果你在乎的是盡快讓菜鳥成為即戰力,熟悉產品、熟悉系統架構、熟悉開發規範、熟悉產品開發中得接觸到的各個角色、熟悉整個開發流程,你就不該在一開始的三個月把他排除在團隊之外。
而是在一開始就讓他加入團隊,當個觀察者、學徒、活水,甚至讓他貢獻出一些價值,例如發現過去團隊看不見的盲點,針對團隊習以為常卻不合理的部份提出疑問。
而 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》
如果你們有進行 code review,也請你們參考看看這篇文章:Code Review 與 Pair Programming
在〈菜鳥養成策略-Pair Programming〉中有 2 則留言
So how?
認真詢問的口氣 不是踢館的那種
因為文章只看到整體 沒看到說明如何pair programming
我的意思是 是
1.一個人用電腦寫時 另外1位直接在旁邊看
2.IntelliJ系列IDE用Code With Me(但這還在Beta中吧)或其他三方套件或VS Code用live share
這2種 或還有別種?
個人建議是1的那種,兩個人並肩坐在一起討論、輪流寫程式的那種 pair programming。線上遠端的方式當然也可以,只是一般是不得以而為之,例如有地域的限制。我之前跟國外的同事和客戶是用 zoom 一起 pair 的。
其他關於 pair programming 實作上的細節,建議可以參考這一份 結對程設指南 整理地蠻完整的。