我在輔導各單位不同性質的軟體開發團隊，對於專案開發的工具導入，只要求至少要能提供兩種機制給團隊成員們使用。一為版本控管(Version Control)；另一為 Issue Tracking。

各個單位可以自行選擇，無論是選擇 VSS(Visual Source Safe)/VSTS(Visual Studio Team System), CVS, Subversion, ClearCase 等版本控管工具，以及使用 TFS(Team Foundation Server), ClearQuest, 甚至是只用 Excel 當作 Issue Tracking 工具，這些我都沒有意見，團隊成員們覺得好用、還有，真的有實際在用即可。

不過，我是蠻堅持要至少導入這兩種機制，理由為何？ 我覺得道理就是很簡單、很自然。 版本控管機制如同 10 餘年前 Novell FileServer 一樣，所有的文件、設計產出(artifacts)、程式碼都是集中放在一個儲存區 (repository)內，團隊成員就是去同一個地方把開發的文件取出來(check-out)，改完後再放回去(check-in)，而不同於 FileServer，版本控管就是多了因為共用的議題而衍生出衝突的情形發生時，所提供的解決方式與功能。所以，三年多前，我到某大學教授資訊系的講師與教授等，其中一位帶學生作專案開發的女老師就問道了，每個參與開發的同學都負責某一部份的文件與程式碼，並放置在他們各自的硬碟中，但是要整合時卻是問題多多，該如何解決這問題？ 這個就是，不是問題的問題。很自然地，放起一起就對了，交給版本控管工具來協助管理即可，但是，另外一個問題是，女老師認為安裝與設計這些工具是難事，呵，這好像不是理由，往對的方向走後，再來思考 How-to 的解決議題就是了。 Issue Tracking 為何也要導入？ 只要是超過兩人以上的開發，必然會有溝通(其實，一個人也會有溝通的問題，與內心自己的溝通)，也必然會有問題的紀錄與回應。我最是鼓勵團隊成員第一是勇於問問題，是的，要能勇敢的問問題，這本身就不是一件容易的事。其次就是不要只把問題放在心中，要能 Write Down 下來！ 對於某些問題的本身，就是一個可以讓成員之間討論溝通的主題，然後就是把這些溝通的經過給紀錄保存起來，這才是真正有效的知識分享(knowledge sharing)。

簡單的說，版本控管是設計產中的一種共享；Issue Tracking 則是大量溝通的機制。

哪個時候導入？ 我是不會專案一開始就馬上導入的，當然，專案經理可以先準備好，我也沒意見。理論上，應該是專案啟動時就要馬上導入的，但是，團隊成員，在那個時間點其實要謀和太多的議題了，包括技能、技術、產出之間的橋接、默契 … 等太多的事情了。我是不主張一開始就是花時間在工具的學習使用，反而是，慢慢地，等到團隊成員們越來越有默契、越來越覺得好像少了什麼東西似的，那個時候，就是可以找工具來導入的好時機了，而且往往是水到渠成，使用這些工具，不會變成壓力，而真正是一種助力了。

用哪些工具，有沒有差別，是否最好是能有一套統籌的 “ALM, Application life-cycle management” 專案管理機制比較好？ 我是不會想那麼多、那麼嚴肅的。工具好用順暢即可，還有，更更重要的是，真的有在用才行！ 嘿，是真的有在用，而不是變為一種形式上的紀錄而已喔，實在是好多單位，還真的是淪落為形式而已，哪可不是更形增加軟體開發人員的負擔與反感嗎？ 我可不知道這些專案管理層級的主管們是在想什麼。

我輔導過的單位，有使用過 Microsoft TFS, Rational ClearQuest 等比較重量型的 Issue Tracking 工具，當然也有是採用 OpenSource 的工具。有些公司的專案經理，就會請我協助選擇個比較不錯，便宜(最好是免費)的工具，這些我當然欣然接受，沒有問題的。

哪一個 Issue Tracking 的工具功能最佳呢？ 就我輔導過許多單位的經驗來看，嗯， 就某大型零售業資訊單位所使用的 Excel 最棒！ 因為，他們是我所看過最勇於發問問題，也勤加記錄問題的解決步驟與方案。我們在每一次的輔導，一開始一定是針對 Issue 來討論的，而且，他們也會對 Issue 作分類，還標上顏色識別種類與重要程度。

真的有寫上 Issue，真的有對 Issue 來討論，這才是根本。所以，何嘗 Notepad 不也是一種 Issue Tracking 的工具呢？