讓即戰力加入新的戰場

加入新團隊的老手，其優勢是實務經驗，而且對於軟體開發的觀念或是相關的技術工具，都有一定的熟悉程度。相較於菜鳥程式員初加入團隊之際，必須花費一段時間及教育訓練上的投資，才能協助他建立起基礎的軟體開發觀念，並且熟悉必備的技術工具。

團隊的新成員是有開發經驗的老手
菜鳥程式員和老鳥程式員之間的差異，絕對不僅限於設計程式的技巧。更重要的是，在一個開發團隊中，在角色分工的情況下，依據團隊的開發流程，協同合作的將軟體開發完成。有很多的活動，像是對規格文件、設計文件的審查、程式碼的審查活動，以及像進入測試階段後，程式員如何如何透過瑕疵追蹤系統（Defect Tracking System）和測試人員進行互動，以解決在測試過程中所找到的瑕疵。

剛從學校畢業的菜鳥程式員，有可能完全沒有接觸過任何的版本控制系統，甚至完全沒有使用版本控制系統的概念，對此，可能需要花上一些時間，才能讓他學會使用版本控制系統的軟體，而且花上更多時間，才能建立起版本控制系統的觀念，以及使用時的準則與規範。

老鳥程式員需克服的障礙
當菜鳥程式員加入團隊後，通常你不會需要教他程式語言的語法、以及撰寫的方法，但是，你會需要花上不少時間，協助他習得參與這些活動所需的觀念、融入上述的各種活動之中。相較於對於技術工具的熟悉，這反而是比較耗費力氣的。正如前文中所提到的，經由mentor的帶領，讓菜鳥程式員可以和團隊中其他成員一樣，踩著相同的開發步調、漸漸的融入到團隊中。

老鳥程式員大多都具備足夠的開發觀念，即使他們在過去使用不同的技術工具，例如不同的版本控制系統，但是，版本控制的基本觀念是相通的，並不會因為使用不同的軟體工具而有太多的差別，即使有，也是很容易克服的。所以，無論是技術工具或觀念，都不會對新加入團隊的老鳥程式員構成太大的障礙。那麼，對老鳥程式員來說，比較大的困難在何處呢？

在前文中說過，菜鳥就像一張白紙，要在紙上呈現出美麗的圖畫，需要花費更多的心力去著墨。不過，白紙也不全然是壞處，雖然在技術面和觀念層面上可能需要重新帶領，但是，因為對開發沒有既定的成見，在開發的習慣及文化上，反而容易避免一些可能會有的衝突。

而老鳥程式員在加入另一個不同的團隊之後，最大的障礙就是在習慣及文化面上。不同的團隊會有不同的各種開發習慣，也會有不同的文化。對於已經習慣舊有習慣、既成文化的老鳥程式員來說，倘若新舊兩個團隊之間存在不小的落差，那麼重新適應往往會成為一個問題。

其中可能會有的落差，小到命名慣例的差異、大到開發流程在基礎精神上的不同，都可能會讓已經習慣舊有模式的老鳥程式員，在轉換上花盡心思。

舉例來說，一個習慣傳統瀑布式開發流程的程式員，來到了一個採用像是極限編程這種敏捷開發方法的團隊，肯定會有很大的適應問題。舉凡需求持續變動、用很簡單的方式來描述需求、不做太嚴謹的設計。甚至，還得兩個人一起寫程式。更過份的是，竟然還得先寫測試案例！

對菜鳥程式員來說，反正原來就是一張白紙，要他們接受這樣的觀念，反而簡單。但是，對老鳥程式員來說，當這差異大到連開發流程的基本精神都有很大的不同時，重新適應就要耗費不少心力了。

搭配mentor輔助老鳥程式員適應
即使是老鳥程式員，在加入團隊時，通常還是會採用mentor引導的方式。這裡，我想探討一下mentor的選擇方式。

mentor的選擇方式，通常可以是技術主管，或者是一樣身為程式員的同儕。

選擇程式員同儕做為mentor，或許是比較理想的方式。怎麼說呢？因為，mentor最主要的任務是帶領新成員融入團隊。從同儕的身上，比較容易觀察到自己需要學習的東西，成為模仿的對象。此外，在和同儕相處時，相較於面對技術主管，所需承受的壓力也小了許多。在融入團隊的過程中，新成員會有眾多的疑問，可能會有不少人在面對技術主管的時候，反而因為壓力的關係，不敢提出疑問以尋求解答。面對同儕，這樣的壓力就小得多了。

這個帶領新成員的角色說是mentor，或許太沉重，從另一個面向上來看，其中存在的還有夥伴關係。不僅是在軟體開發本身，提供一些關於新環境的協助，之外，在公司中的其他事務，像是文具的申請、假單的填寫等等，這位mentor兼夥伴，都可以讓新成員沒有壓力、自由自在地尋求協助。這樣，才能更快、更有效率的融入團隊。對老鳥程式員來說，一位好的mentor，有助於協助他克服在習慣上、文化上的落差。

老鳥程式員正式上工
接著，該怎麼讓老鳥程式員開始工作呢？有幾種方式可以考慮。針對菜鳥程式員，前文中提供的建議是選一些獨立性高、涵蓋範圍小、技術難度不高的工作讓菜鳥程式員來習作。這主要原因是菜鳥程式員無論是對於開發觀念、流程、或技術工具都不熟悉，可以透過此類的工作做為習作來逐漸上手。不過，對於老鳥程式員，選擇的方式或許就有所不同了。

對老鳥程式員來說，可以不需要一些小規模的習作來做練習，因此，可以考慮直接參與專案。而想要參與專案，首先必須要建立起對正在開發中系統的認識。因為新加入的成員是在專案開發中途才加入的，對於專案的背景、或者是對於已經開發好的部份都不是那麼熟悉。因此，首要之務便是了解現有的系統。

這要怎麼辦到呢？我們有一種方式，便是請他協助除錯的工作。除錯本身就是一種探索系統的過程。對於一個完全不了解系統的除錯者來說，在找尋錯誤的過程中，會從錯誤發生的表面開始出發，逐漸的往錯誤發生的源頭鑽。為了找到一個錯誤發生的原因，必須在一層又一層的程式碼間鑽進又鑽出。這種在程式碼間走訪瀏覽的方式，對於除錯者了解系統運作會有很大的幫助。為了明白單一個錯誤點之所以發生的原因，能建立起對系統一整個構面的認識。

只要多指派給新加入的成員一些除錯的工作，他了解系統的程度就會愈來愈高。

不過，雖然新成員可以透過除錯了加快認識系統的腳步，但是，發現臭蟲的所在之後，新成員可能就不是好的修正者了。怎麼說呢？因為新成員終究對系統的了解不那麼全面，他所提出的修正方案，或許沒有辦法全盤的考量到系統整體的情況。他所提出的解決方案，或許從局部看似乎解決了問題，但是也有可能引起其他的副作用，而造成了解決一個問題，卻衍生出更多問題的情況。

即使如此，讓新成員來協助除錯還是很有幫助，除了加快認識系統的腳步之外，也會因為新成員對於系統沒有既定的成見，反而身處在局外，格外能跳脫原成員的盲點，因而找到錯誤。