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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

作者簡介


Advertisement

更多 iThome相關內容