人世本苦，其苦何鉅-無我詩文舖

引述

[心得]使用 Microsoft Visual Studio 2005 Team System

這本書的內容，是我一直很想了解 VSTS 的新增功能，如果沒錢買書的話，可參考：

http://msdn2.microsoft.com/zh-tw/library/ms304624.aspx

這邊已經有翻譯過的線上手冊，軟體附贈的 MSDN for Visual Studio 只有英文版，我記得前陣子有 MSDN for Visual Studio 2005 的中文更新，我下載並安裝了，居然沒有更新這部份... 好可惜阿。書的內容，已經整合過了，所以看書會比較有結構。

看完這本書後，我想該不會是微軟自己需要，先做給自己用，用的感覺不錯以後，再改成一般化變成套裝軟體吧？台灣很多中小企業不會這麼複雜，能設計到這麼複雜的邏輯，本身也要有相當的經驗，所以滿有這種感覺的，有點像是微軟經驗轉成套裝軟體。

這本書要怎樣說呢，所需要的預先知識並不在這本書內，所以裡面會有很多原則、目的等，會讓剛入門者搞不清楚，我自己是先唸過兩本專案管理、兩本軟體專案管理及經濟部工業局所發布的規範，所以算是知道一點預先知識，但是看起來還是很吃力。

這本書... 這本書... 基本上企業的基層程式設計師應該會很不希望老闆或是主管看到吧？整個專案開發全部納入管理後，有的時候想摸魚可能都不太合適，當然，就企業主、中高階主管、專案經理或是協助專案經理或研發經理管理的人滿適合先看，但不建議立即導入，因為這本寫的還不夠深入。當然，已經導入這類管理模式的單位，所有人員大概都要看。

舉個例子，學校教授做計劃或合作做計劃、或是顧問公司標政府採購案等，都可以適用 VSTS 。

整本書是一整體的，在書的內容是有針對腳色來分，但是不管你是哪一個腳色。都有瞭解的必要，整本沒看完，可能會有霧裡看花的感覺，我自己建議，先看第一章，再翻附錄 B ，再翻第 8 章，知道大概用詞有哪些後，再從頭依照簡介的順序來看。

至於 MSF for Agile Software Development 跟 MSF for CMMI Process Improvement ，我比較建議測試時，直接試用、導入 CMMI ，因為經濟部工業局那邊已經採用 CMMI ，並擬妥國家規格，在國內開發軟體多多少少會跟政府單位有接觸，也許是上游，也許是上上游，所以採用政府要求的格式，將來比較不會有轉換適應的問題。

測試專案部份，我是覺得 Developer 也要用，過去我都是在類別內包含一些測試方法，所以我看完這本後，應該會改用測試專案來玩看看。

我自己今年接個案子，也有這些要求，所以猛畫 UML 圖，如果可以，我也想導入，但是裡面有一些問題，先前我用 VS2005 畫圖，畫完後，不知道該怎樣用向量檔方式轉到 Word 上，畢竟要出報告，最後還是回頭用 Visio 畫，當然先前沒看過這本，所以很多細節不清楚。

整體功能要架個測試站來玩看看，可是流程的導入，對於企業行政是很大的干擾，好像不太能無痛導入，在很趕的專案最好先不要碰。我目前只是看完書，還沒測試過，所以有些疑慮要考慮。

1. 幾乎各企業來說，不管是專案經理 (這本書居然不是用專案經理，而是用專案領導者之類的用詞) 、各各腳色，多半都參與多個專案，所以面臨的是混合專案的問題。有些系統部分，可能是企業核心，有些可能是數個專案共用，有些可能是專案系統內共用，裡面並沒有看到混合的問題。
2. 裡面是以新專案為例，就算企業打算在新專案才開始導入，但是有很多會跟既存專案牽扯在一起，就是前面的問題1 ，混合到其他專案的問題，這邊並沒有明確的介紹與說明。
3. 專案管理的觀念與精神幾乎都整合到 Microsoft Project 內，VSTS 也支援直接使用 Project 當成瀏覽器，軟體專案管理是在專案管理內加上軟體專有的架構、開發、驗證過程，但是很多專案管理的行政部分，在 VSTS 內並不支援，比如說專案人力分配與管理、時薪計算、PERT 圖、甘梯圖等，這部分應該納入整合，甚至包含專案結束後的檢討、歸檔，供新增專案規劃參考時程、成本使用。
4. 專案執行過程中，需要定期備份、出報告，比如說把目前最新版本整個燒成光碟交給業主，作為階段性驗收與撥款，似乎只能備份資料庫。另外針對文書支援似乎完全不考慮，可是專案人員也是要打報告，打各種規劃書，而測試結果雖然會出成 HTML Report ，可是拷貝到 Word 後，又要重調樣式、表格，似乎對於行政支援的部分不太足夠。
5. 在本書裡面，代號要交由系統決定，但是在寫初稿時，通常會一直改，這時自動編號就會重傷，因為無法向業主解釋跳號的問題，而定稿後，比如說測試規劃書送出後，再變更時，則應以新的編號給定，這部份好像不是這樣規劃的。
6. 帳號採用的是 Windows 帳號，有時候很麻煩。有時後專案在投標時，可能提供了人力配置圖跟表給委辦單位，之後企業內部作人力調整時，可能這個人力因為不適任，調去支援其他專案，而為了避免文書行政往來，通常不會爆給委辦單位，這時可能會將該人力分配給多個其他人等，若是有自定帳號系統時，可以由各部份接替人員來登入，或是專案可能有代理人制度，由代理人來處理，所以會覺得一定要對應真實系統時，有時有綁手綁腳的問題。甚至有的時候可能是人頭人力，利用某個高階主管名氣來接案，實際上專案由另外一個主管主持，這個高階主管只是顧問層級。
7. 部分用詞可能有點混淆，比如說簽入，從整本書的說明來說，應該是指包含修改過的程式碼上傳，可是一般來說，簽入通常會以為類似登入的行為。
8. 模組的分類不清。基本上整個管理是以物件類別為基礎，可是我滿偏好模組構成的函式庫，大概學界過去都慣用這類吧，在這本無法窺知模組到底該怎樣配合，都是以物件為單位。
9. 似乎沒有包含原始碼的移交與部署？裡面有二進位檔的佈署考量，不過有些專案契約會要移交原始碼，依照著作權法及專利法來說，非專案內開發的既有功能屬於原公司所有，不需要交接，所以這部份就牽扯到部份二進位碼與部分原始碼的移交，通常契約並不會規範到原始碼要包含使用說明或註解，所以交給委辦單位的原始碼可能想把註解拿掉，來作為下個維護案的技術門檻，這類考量似乎都沒有。
10. 在國內，通常管理階層只出一張嘴，所以專案經理要負責的開新專案、架構可能都是由下面的秘書或助理或菜鳥工程師代為執行，然後在定時會議上拿出來討論、修改，這部份可能要考慮加入簡報的支援能力，最主要的就是圖與報表的展示與彙整，此外，畫上去的元件可能要能轉屬性，比如說原先定義的位階比較高，要降階到某個子系統內，可能從系統元件降為類別等。

我自己很想導入啦。因為今年寫了一堆報告，我也想藉由這個機會學習與導入更制式化的流程，建立維護、開發、設計的基準。

我有空後，應該會去抓些範例來測試與變更，希望能盡快熟悉這套軟體，不過我覺得這套比 Project + Visio 還複雜... 目前只能各部份先行行政作業...