簡睿隨筆 《科技篇》

對於每一個開發團隊而言，正確且順暢的溝通協調運作機制是不可或缺的，少了這些協同機制，就像在交響樂團裡的走調雜音，或像團體裡我行我素的獨行俠，都會 使團隊戰力大打折扣，畢竟現今的軟體開發已經複雜到無法依賴單打獨鬥的曠世天才而能完成的。只要體認到開發不能只依靠少數人、必須群策群力、互相配合、遵 循共同的流程規定，那麼像Tracking system、Version control system等就必然變成開發人員的好朋友，無法離開它們而能順利運作的了。

然而現實的狀況是：功能強大且完整的協同軟體不是每天在生存線上掙扎的台灣小軟體公司能用得起的，導入與使用費用之高都令人咋舌，因而導入Open source的工具再搭配部份自訂流程就變成不得不的選擇。我們最早的版本控制工具是微軟的Visual SourceSafe，但當開發團隊分散兩地時，Visual SourceSafe就陣亡了，雖然有第三方廠商的Source OffSite讓Visual SourceSafe能在Internet上使用，但所費不貲，最終才使用了CVS+WinCVS的組合，在CVS上我們開發了重要的產品和許多個大小專案，期間也是跌跌撞撞，歷經許多錯誤嘗試。

接著是Bug/Issue tracking system的導入，用以補足問題的自動追蹤功能與任務的線上分派。最早使用的是Track+，選用它的原因是它是以Java撰寫的，而Java正是我們的主力開發語言且2.X版時能下載程式碼，因而給了我們自行修改的機會（現在3.x版已經沒辦法修改原始碼了），再者Track+具備國際化(I18N)的能力，約在2003年我在珠海趁晚上和假日完成了繁體中文語言包，再經幾個小專案的測試後推動到所有專案。

CVS用了幾年後，因為Subversion提供更快速的存取與相容CVS的操作方式，在這兩三年裡就逐步由CVS+WinCVS轉移到Subversion+TortoiseSVN，轉移的策略是舊的專案或較少變動的專案就保留在CVS上，新的專案與更新頻繁的專案就移到Subversion上。而2007年又開始試用Trac，嘗試把Wiki、Tracking、Subversion整合在一起，以下是我們使用Trac的幾個試驗：

• 在Wiki首頁放置一個公佈欄：PM、SA要公佈的開發事項以日期排序，以通知專案成員。以前大多是用E-Mail聯絡通知，但新成員是沒辦法看到的，全部放在Wiki上就不怕有疏漏的狀況。
• 任務分派用Ticket發送：SA透過Trac分派給PG(Programmer)要撰寫的作業，開始日期與期望完成日期皆有紀錄，PG的作業狀況與績效都能追蹤考核。
• 透過異動歷程了解開發活動：每天PM透過異動歷程能大致了解PG的進度與程式撰寫狀況。
• 我們把Trac的Component存模組代碼，再增加模組報表，如此便能輕易地知道各個模組作業的完成進度。

Subversion 則是所有文件與程式碼的統一窗口，所有專案成員皆以Subversion上的檔案為準，這樣以前用Mail寄來寄去，或透過File Server取檔導致版本不一致的問題就消弭於無形了。一般專案開發組織裡，我們尚有測試組的配置，當PG經由Trac通知測試人員開始測試時，測試人員 由Subversion取出程式，在他的本地端編譯、測試，以確保測試的版本是正確、一致的，若有差錯也能立即被發現。

這裡再分享幾個推動上的小經驗。

• 中文化是必須的：要能順利推動某個工具，一定要有中文介面，缺少中文介面一定都會大打折扣，且會給成員推拖的藉口。尤其是大陸同事，看到英文心就亂一半，要他們用非中文工具，簡直是比登天還難。
• 要循序漸進、不可躁進：推行此類會影響作業流程的工具時，切忌一開始就全面推動，若不先經小範圍測試再逐步修改調整，可能對團隊帶來翻天覆地的混亂感受，從而增加推行失敗的機率。
• 主管要堅持，成員要配合：導入初期的不適應，勢必引起反彈，但只要是對的政策就應該堅持，主管、成員都要敞開心胸，針對扞格不合之處做調整與修正，最終才能磨合成適合環境的較理想運作模式。

事 實上，Tracking system與Version control system僅是專案運作的基本功而已，但這些基礎都無法運作順利，遑論其他更因人而異的管理機制了。從以上的推動描述可以看出我們對於推動新的流程與控 管機制是抱持慎重其事的心態，因為一個機制的變更影響到的是許多聰明、又有想法的開發人員，最終還是要讓這些機制內化成每天的標準動作，而這樣的流程也才 有執行的必要。

以上小小經驗與大家分享。

##