敏捷方法心得分享 - 塗智宇

[Gaitz Cheng]

陳教授您好，與您分享從學校畢業後到現在的工作經驗與一些心得。

畢業後到了一間做網通產品的系統廠服三年的研發替代役，軟體部門約三十多人，做事情的方法還蠻傳統的，連版本控管都沒有做得確實。基本上一個產品就是一個人負責，除非該產品有包含韌體(Firmware)與應用程式(Desktop Application)才會由兩位RD來負責開發，雖然開發同類產品的RD會互相交流，但嚴格說起來還是各忙各的，一直到產品開發完才會送QA測試。

從上間公司畢業後到了國內製作影音播放器/編輯器的廠商，是一間純軟公司。公司的產品很多元，一個產品通常由兩個團隊負責，一個負責上層UI，一個負責底層的核心，每個團隊另外還會負責一些各產品通用的元件，像是錯誤回報或是跟各個社群網站連線的元件。我待的團隊負責的產品每年都會發行新版，開發週期大約是一年，一開始會有一個多月的”充電”時間，充電時間就是用來review一下source code，看看有沒有什麼地方可以重構，讓後續開發可以更方便，或是study下一版的重點功能該如何實作，有哪些技術上的困難需要克服，順便也為新版開發做一些基礎建設。

接下來真正的開發過程會分成四個sprint，每個sprint都有很確定的目標，花費五至六週，每個sprint結束之後QA會做一次“Bug attack”。當然，每週都會release一版給QA，確保不會到最後關頭才發現問題。

每個sprint都結束之後，QA就會對整個產品做完整的測試，而我們就一邊開始為新產品更換外觀，最後大概會留將近三個月的時間來解bug，一直到產品穩定然後發行。雖然每週都會讓QA來測試，不過我們還是有做daily build跟daily auto test來確保平常沒有把code改壞，做一些基本的把關動作。

開發過程的溝通方面，雖然沒有到”綿密”，不過我覺得已經算是沒有障礙了，PM就像是我們的客戶，常常會來串門子看一下開發狀況，我們對spec不了解或是覺得有問題的地方，也會直接跟PM討論，通常很快就會有結論。

目前在一間GPS產品製造商，主要負責產測程式以及QA需要的自動化測試程式的開發。團隊有十四個人，一年總共大約會有五六十個產品，雖然每個產品的複雜度跟穩定性差異很大，但可想而知，節奏是很緊湊的，跟其他部門的溝通非常頻繁，每個人常常會遇到一些新需求要加到測試程式裡，雖然不複雜，但是必須快速的完成，如果稍有怠慢，產線可是會追著我們跑的！

通常改好程式會直接release beta版然後進行測試，確認沒問題後再merge進正式版裡面，正式版則是每週release一次，同樣有daily build與daily auto test來把關我們程式的品質，團隊也常常開會分享最近改動的功能與程式，有時也大家也會想想要怎麼重構，讓code的品質更好。雖然我們並沒有特別強調使用某種開發流程，但是這樣的工作節奏卻跟Agile method很多部分不謀而合，強調溝通以及頻繁的release...等等。

待在這邊印象最深刻的事就是前主管非常重視軟體工程，也很樂於嘗試各種方法，在他提出有沒有人想要pair programming的時候，我當然是非常的興奮，自告奮勇的想要參與！Pair programming的過程是非常開心的，幾乎感覺不到壓力，開發的過程很像邊討論(聊天?)邊做事，另一個人很容易就可以發現你的一些小錯誤，因為每個人的思考方式非常不同，寫程式一定都會有自己的習慣跟邏輯，pair programming就是一個很好的交流，互相學習的機會。雖然乍看之下好像花了兩個人力來做同一件事，但是品質是非常好的，而且比較不用擔心有人請假了或是離職了，還需要另外安排人力來從頭看code瞭解流程。”前”主管現在已經不在這個團隊了，後來這個程式還有新的需求，我當然可以很快進行修改並且交付，pair programming也有類似”買保險”的功能呢！

從學校畢業到現在經歷過一些工作，發現各個公司都會有既定的風氣跟歷史包袱，一個基層RD其實是很難去改變的，不過我們還是可以養成個人的習慣，慢慢去影響周遭的人，就能慢慢改變這個環境。我覺得，軟體工程是一個態度也是一門藝術，在未來的工作生涯，還是要努力繼續修行！