博暉科技運用VS 2010將開發流程標準化

博暉科技從十年前就開始運用.NET開發金融產業相關軟體，在臺灣十大投信業者中，有7家使用博暉開發的系統。早期，博暉採用Visual SourceSafe（VSS）進行程式碼的版本控管，再搭配共用資料夾來管理開發文件。但是，這樣的作法缺乏專案歷史軌跡的記錄，專案管理者無法掌握程式碼的異動原因，就算有文件記錄，也很難保證開發者即時更新文件。

為了解決這個需求，博暉在2005年導入了Team Foundation Server（簡稱TFS）來管理開發團隊。博暉科技總經理謝東岳表示：「導入後最大的成效是建立制度，包括安全控管、版本控管和流程控管這三項工作標準化。雖然不一定能節省人工或降低開發成本，但是建立制度就可以避免弊端。」

例如過去由專案經理掌管所有專案文件和資訊，若專案經理有意隱瞞進度，公司不容易取得詳細資料及早發現，往往得等到結案時才會發現。博暉科技研究開發處協理崔啟文表示：「導入TFS之後，大部分的專案資訊都有記錄可查，專案管理就能擁有透明度。」

博暉大約有40多位程式開發人員，其中有30多位使用TFS。另外研發處有8位同仁也使用TFS，他們負責研發產品功能、建立開發專案以及檢查開發團隊的程式碼等工作。崔啟文正是研發處主管，也是導入TFS的關鍵人物

博暉一般會有6～7個專案同時進行，專案規模從數百萬元到上千萬元不等，每個專案小則2～3人，多則有十幾人。從2005年導入VS 2005和TFS 2005後，一直使用至今，崔啟文認為，TFS 2008和2005版的功能相去不大，所以，直到VS 2010時才打算升級。目前在TFS中的專案資料大約有100GB。

崔啟文從去年開始規畫升級TFS，今年2月展開測試，直接在VS 2010測試版中開發兩個研發處的新專案，由研發處6名成員先試用，目前已經陸續升級到VS 2010 Beta 2版本。

如何應用Work Item是關鍵

建立Work Item是連結管理和開發的關鍵，但是，崔啟文認為，這件工作其實不簡單，他說：「Work Item看起來什麼都做得到，反而讓人不知道要怎麼做。建立Work Item其實不難，難的是如何應用。」

例如，開發者何時要發Task，何時要發Bug，反覆項目如何歸類，Team Project如何定義等，崔啟文嘗試了很多種運用模式，最後歸納出一套建立TFS專案的實務作法。首先，崔啟文認為，Team Project必須以團隊的單位來建立，也就是以人的角度建立，才能計算出每一個人的工作量。

但是，在博暉的每一個人還可能參與一個產品下的多個團隊來服務不同的客戶。所以，崔啟文先以產品來建立VS 2010的Team Project，再利用VS 2010提供的區域功能，在Team Project下，對服務不同客戶的團隊所負責的Work Item加以分類，等於是利用區域功能建立子專案，用區域功能將不同團隊的Work Item分群。如此一來，從Team Project下可以看到整體的專案或個人報表，也可以透過區域的條件查詢，看到個別團隊的進度。對專案經理而言，也能夠看到成員參與其他專案時的工作項目來指派適當的工作量。

崔啟文採用VS 2010提供的Agile專案，這種類型的專案提供了6種Work Item，不過崔啟文常用的只有User Story（使用者本文）、Task（任務）、Bug三種，另外有時會用到Issue（問題）。

他將User Story（在VS 2005版時稱為Scenario）視為需求單，而將Task視為工作單。User Story的ID就是需求單的編號。一張需求單會派出多張工作單，例如在一項需求單下最常有用SA、SD、PR和Test等4種Task，可以發給不同角色的專案成員。完成需求單下的所有工作單，才算完成這張User Story。一個User Story通常是3～5天可以完成的工作，最多不超過2周。

Bug的Work Item則分成兩類，一類是在開發過程產生的需求單，通常是由需求單發出工作單後，在工作單中包括了測試工單，測試完成後產生了Bug，這個Bug項目是內部人員產生的Work Item，屬於這個需求單的成本之一，所以連結在這個User Story中。另外一種就是客戶回報的Bug項目，沒有和其他User Story產生關聯。

Issue也有兩種用途，第一是作為里程碑的查核清單，屬於這個階段必須完成的工作，這個開發階段中完成了所有必要的Issue後才能釋出新版本。Issue另一個用途就是做為備忘錄，是讓專案經理人用來提醒自己，還有哪些需要注意的事。這兩種用途類似，都是記錄需要關注的事情，但查核清單必須完成，而備忘錄則不一定要完成。不過，博暉科技比較少用到Issue這項功能。

用順位屬性安排工作優先順序

另外，在User Story和Task都有一個「順位」的屬性，可以用來設定優先順序，因為不同區域的Work Item都屬於同一個Team Project，所以就能共同排序。對專案成員而言，遇到不同專案中的任務相衝突時，就可以透過順位屬性來決定優先順序。

崔啟文以4位數編碼來排順位，並以10為間隔，例如0010、0020、0030等，預留以後有臨時插單的情況，例如可以插入一張0011的單子，代表在0010之後，但是在0020之前。在VS 2005中，順位數字越小代表優先順序越高，但是到了VS 2010時，由於採用了Scrum的開發方法論，數字越大反而代表優先順序越高。

用本文點估算專案成本

另外，VS 2010導入Scrum方法論後，增加了一個新概念叫做本文點（Story Point），崔啟文則用本文點來估算專案開發的時間成本。例如有兩個User Story，A和B，A的難度是B的兩倍，崔啟文就定義A有兩點本文點，而B只有1點。依照同樣的作法，他透過困難度比較的方法，定義出每一項Work Item的本文點數，最後可以加總出一個專案的本文點總數，待這個專案完成後，就用這個專案所花費的時間成本來估算一個本文點所對應的時間成本。經過幾次專案的調整，最後就能得到一個有效的本文點估算方式。

或是將本文點視為人時的單位，例如崔啟文先用1個本文點等於1個人時，或2個人時的方式來估算Work Item的工作量，同樣經過幾個專案的實測後，可以得到更精確的本文點與人時的換算方式，「未來只要知道新專案的總本文點數，就能先估算出可能的開發成本。」崔啟文說。

上述這些Work Item使用規則，就是博暉科技開發團隊要遵守的開發規範，每次崔啟文建立開發專案前，都會先培訓開發人員，依據這些規範建立共同的開發習慣。

建立新專案的4大步驟

崔啟文表示，建立一個新的開發專案，可以分成幾個步驟，第一先建立Team Project，利用VS 2010新增加的專案集合（Collection）功能，為不同部門建立各自的專案集合中，每個集合能設定各自的權限，避免專案被其他部門的人存取，還能將同一集合下的專案放到不同的資料庫中來分攤負載。

第二步驟則是建立版本控制的目錄，崔啟文通常會建立三個目錄，包括Main、Maintenance和Development。在開發初期，主要版本的Baseline放在Main目錄中，等到發布第一個版本後，將後續的改版分支到Development目錄中，待新功能開發完成後，才把程式碼併回Main目錄。若遇到Bug，則在Maintenance目錄以Bug名稱建立分支，待問題解決後才合併回Main目錄。Main目錄的程式碼通常也是和客戶同步的版本。

第三步則是在SharePoint Server上建立開發團隊的入口網站，VS 2010會自動建立基本網站，崔啟文則是進一步設定需要的文件庫，建立文件管理規則，如文件格式樣板，每階段應產出的文件等，另外還會建立討論區讓開發者回饋意見。此外，還會建立一個外部客戶可以瀏覽的文件庫。

專案建立最後一步則是依照需求單建立User Story和Task，若一開始專案還沒有需求單，崔啟文會先建立一個「其他User Story」來歸類需要的Task。博暉的研發部門完成這些專案建置工作後，就交給開發團隊，依照這些工作流程來開發。

不過，對於剛開始導入TFS Work Item的企業，崔啟文則建議：「先導入Bug和Task兩項Work Item，先用TFS作為Bug進度管理工具，從淺顯易懂的項目著手，讓使用者習慣操作介面和工作方式，再逐步擴大施行範圍。」

目前，博暉也還未全面導入VS 2010，只有研發處正在使用VS 2010的Beta 2版本，崔啟文解釋，因為VS 2010需要安裝在Windows Server 2008 R2上，但這會和博暉現有的Windows 2000網域AD衝突，導致在帳號名稱變成亂碼。所以，崔啟文先建立一個獨立的測試網域供研發處使用。他打算今年將網域升級到2008版本後，才將VS 2010的專案開發模式擴大到全公司的開發團隊，同時導入Team Lab功能、憑證認證機制，並且和Project Server整合。

博暉科技總經理謝東岳表示：「導入Visual Studio和TFS可以建立一套標準的開發制度，將安全控管、版本控管和流程控管三大流程標準化。」

博暉科技研究開發處協理崔啟文建議：「先用TFS作為Bug進度管理工具，從淺顯易懂的項目著手，讓使用者習慣操作介面和工作方式，再逐步擴大施行範圍。」

8項VS 2010專案建置原則

原則1：以產品類別來建立Team Project，用區域功能將不同團隊的Work Item分群，等於是利用區域功能建立子專案。

原則2：依部門區分專案集合（Collection）與存取權限，將不同集合中的專案安裝到不同的資料庫來分散負載。

原則3：User Story：將Work Item的User Story（在VS 2005版時稱為Scenario）視為需求單，User Story的ID就是需求單的編號。一張需求單會包括多張工作單。完成需求單下的所有工作單，才算完成這張User Story。一個User Story通常是3～5天可以完成的工作，最多不超過2周。

原則4：Task：將Work Item的Task視為工作單。例如在一項需求單下最常有用SA、SD、PR和Test等4種Task，可以發給不同角色的專案成員。

原則5：Bug：Bug Work Item分成兩類，一類是由內部人員執行User Stroy的測試工作所發現的Bug，屬於這個User Stroy的成本之一，所以歸屬於旗下。另一種則是客戶回報的Bug項目，沒有和其他User Story產生關聯。

原則6：Issue：有兩種用途，第一是作為里程碑的查核清單，屬於這個階段必須完成的工作，完成了所有必要的Issue後才能釋出這階段的新版本。另一個用途則是備忘錄，用來提醒但不一定要完成。

原則7：「順位」屬性：每個Work Item都可以用順位來設定優先順序，採4位數編碼，以10作為間隔，預留未來插單之用，在VS 2010新版中，數字越大，優先順序越高。

原則8：本文點（Story Point）：可用來估算專案開發的時間成本。透過比較方式，依照困難度或開發時間，定義出專案中每一個Work Item的本文點數，待專案完成後，就可用實際花費的時間成本來估算一個本文點所對應的人時，經過幾次專案調整後，能用本文點預估新專案時間成本。

資料來源：崔啟文，iThome整理，2010年7月

善用本文點有效估算開發專案的時間成本

在VS 2010中，增加對Scrum方法論的支援，在User Story和Task這兩種Work Item的屬性上多了一項本文點（Story Point）的設計。博暉科技研究開發處協理崔啟文指出，本文點讓VS 2010專案多了時間概念的成本控管方式。今年2月，博暉開始導入VS 2010來開發兩個新專案，就運用了本文點來估算專案的時間成本。

崔啟文表示，本文點其實是一個抽象概念，可以用來代表任何單位，主要用來計算，完成一個User Story所需要的時間。一個本文點可以代表1人時、2人時或者是1人天等，可依實際開發情況自行定義。

常見一種定義本文點的作法是將1點定義成1人天（8小時），不過，崔啟文認為：「用1天的單位所估算的時間太粗略，我剛開始先用1點等於1人時或2人時，再隨著專案開發過程慢慢修正找出合適的對應方式。」

為每一個 Work Item估算本文點時，崔啟文有兩種作法，第一種是依據工作難易度來決定。例如有兩件Task（工作），工作A和工作B，A的難度是B的兩倍，崔啟文就定義A是兩個本文點，而B只有1點。依照這樣的邏輯，相互比較出專案中每項開發工作的本文點，最後可以加總出這個專案所需要的總點數，這就是專案所需要的開發時間或者是開發成本。

崔啟文也提醒，用工作難度的方式來比較本文點，是從研發產品要完成軟體功能的角度來看，比較沒有考慮專案時程的壓力。他建議，若要考慮專案時程，也可直接比較不同Work Item的工作量來估算本文點。

等到專案完成，崔啟文再來比對本文點與實際開發時間的關係，例如一個專案實際上用了5個人和100個工作天，也就是5人乘以100天乘以每天8小時，總共花了4,000 人時。若這個專案的本文點總數是2,000，就可以得出每1個本文點等於2個人時。

經過幾次專案以後，這個用本文點對應人時的對應規則，會越來越接近實際值，就可以用來估算還未進行的開發專案。專案經理只要完成開發專案所需要執行的Work Item，並且估算出每一個Work Item所需本文點數，彙總出新專案的總本文點數，就能運用對應規則估算出這個新專案所需要的時間成本。在VS 2010中也提供了一些進度報表，利用本文點計算出專案的理想進度，崔啟文表示：「當本文點越接近實際情況，這些報表的參考性越高，專案經理更能夠掌控管理專案的實際進度與成本。」他也建議企業，專案經理必須了解Scrum方法論和本文點，才能發揮VS 2010各項報表的效用。

VS 2010新增本文點的概念，可以用來估算每一個Work Item的工作量，相關報表也會以此數值作為控管進度的參考。

相關報導請參考「用VS 2010實踐團隊開發」