分類
blog

菜鳥養成策略-Pair Programming

公司對新人到職三個月是怎麼安排的呢?給一堆投影片叫他自己看,然後報告?給他知識管理系統連結,要他自己去看?還是上幾次課,然後考試呢?給他無關緊要的ticket讓他修嗎?如果你希望新人用最短時間融入團隊真實工作,請試試看透過 pair programming,效果顯著。

看過很多團隊,在補進新人時給了魚之後就放生菜鳥。好像拿了些素材給他,他就能上手,但其實這是很不負責任的行為。

如果你在乎的是盡快讓菜鳥成為即戰力,熟悉產品、熟悉系統架構、熟悉開發規範、熟悉產品開發中得接觸到的各個角色、熟悉整個開發流程,你就不該在一開始的三個月把他排除在團隊之外。

而是在一開始就讓他加入團隊,當個觀察者、學徒、活水,甚至讓他貢獻出一些價值,例如發現過去團隊看不見的盲點,針對團隊習以為常卻不合理的部份提出疑問。

而 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 實作上的細節,建議可以參考這一份 結對程設指南 整理地蠻完整的。

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *