聊一下「版本控管」與 「Issue Tracking 」的專案開發機制

我在輔導各單位不同性質的軟體開發團隊,對於專案開發的工具導入,只要求至少要能提供兩種機制給團隊成員們使用。一為版本控管(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 的工具呢?

文章導覽

   

共有 12 則迴響

  1. 寫得很好,但實在沒有必要過分強調”女”老師,因為即使是老師,也不是全能,我們每個人的能力都是學來的,可以好好教,沒必要把人家提出來的疑問當成是笨蛋提的,台灣的教育真的這點很差勁。

    • Hi Jessie:

      您說得沒錯,個人的確要盡量避免這樣的用字遣詞。

      這也倒非台灣教育的問題,這是個人修養的問題,這不能否認。

  2. Dear Kenming,

    想請教一個問題
    我一直在找有沒有什麼方法能做到CMMI 要求的雙向追溯
    這點一直是我們單位很難落實的地方
    用過EA 但好像只能做到二維的追溯 而無法從 需求到系統分析到系統設計到程式設計到測試案例等
    如果免強用EXCEL 那維護起來簡直是叫苦連人呢

    • PM 管理工具的機制支援,這我肯定是不清楚的 !^^

      不過,上述您所提的狀況,使用 EA Matrix 來追蹤難道不行嗎? 我們在輔導一些單位,針對上述 Artifacts 追蹤關聯等,到還蠻順利的。

      • 您是指 ea 工具能做到在一張報表中看到 需求->功能->程式->測試案例…這樣的雙向追蹤表嗎
        因為我看到的都是 需求追功能 或者 功能追程式 都是二個構面而已

        不知是否我們對ea了解的還不夠多

        • 聽起來應該不是工具使用的問題,而是整個專案開發流程設計產出之間的關聯規範問題。

          在EA中的關係矩陣(Relationship Matrix)主要是呈現二維的分析。

          如果要組成一個完整的追溯表,則可能需要先達成以下幾個重點:

          • 必須要先建立從需求到程式的整體關係:
            就需求與功能點(使用案例)來說,其關係是屬於「實現關係」;測試案例則是屬於使用案例的擴充型的屬性;

            至於程式碼與功能點之間,若按照RUP的觀念來說,並沒有一個直接的關係,反而是透過一個Realization使用案例的Collaboration去建立其間接的關係(透過循序圖中物件合作的關係來達成)。

            測試程式跟測試程式碼間,當然也必須要先行在EA中建立對應的關係。

          • 從上述的說明其實可以得知,需求->功能->程式->測試案例並非一個直線型的關係,本來就只能夠透過兩兩關係來呈現完整的矩陣型。
          • 當然,我們可以透過「需求->功能->使用案例實現->相關類別」的矩陣進行追蹤,而由於這並非EA預設的矩陣關係,使用者可以透過EA的Document Generate的功能來建立自己的文件格式。
  3. ISSUE TRACKING 的確重點在真的有在填
    不過好的工具能加上FLOW的機制以及TODO LIST
    更能讓效果加分
    不過我覺得還有一個重點就是PM有沒有善用

發佈回覆給「Anderson」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *