本文使用以下技術：
Visual Studio Team Foundation Server 2008
現在，您可以在 Team Foundation Server (TFS) 中收集和跟蹤團隊項目內部的所有工作和項目。團隊項目僅僅是一個存儲容器，用來存儲和劃分開 發項目期間所跟蹤和使用的所有項目。使用 Team Foundation Client (TFC) 中的“新建團隊項目 ”向導可幫助您進行收集和跟蹤。
此向導非常簡單。單擊“文件”|“新建 團隊項目”啟動該向導。打開之後，必須提供團隊項目的名稱。單擊“下一步”使用組 合框選取過程方法模板。再次單擊“下一步”並添加說明，該說明將由 SharePoint 顯示在門 戶的主頁上。再一次單擊“下一步”，您可以選擇確定定義版本控制的方式。您可以選擇創建 新樹干，通過從現有樹干中分支來創建新樹干，也可以選擇不創建新樹干。做出決定之後單擊“完 成”，幾分鐘後，您即可獲得一個可以隨時使用的新團隊項目。
如果僅僅是這麼簡單，那麼 本文應該是一篇非常短小的文章。我的編輯極有可能會拒絕支付報酬，甚至會重新考慮我在專欄的地位。 但是，並不像所說的這麼簡單。實際上，使用 Visual Studio Team System (VSTS) 時，開發項目是否具 有良好的開端，選擇過程模板的向導頁面起關鍵作用。這是因為過程模板定義團隊項目的初始結構和內容 。
過程模板
如前所述，通過團隊項目可以集中管理您所在團隊的所有項目。當然，您在團 隊項目中存儲版本控制的項目（如源文件）。您還管理和存儲所有工作項和工作項查詢。您將文檔存儲在 SharePoint 文檔庫中，它們是團隊項目門戶的一部分。最後，針對數據倉庫運行報告以跟蹤團隊的工作 情況。
過程模板定義包含在團隊項目中的默認項目模板。具體來說，它定義您可以使用的工作項 類型，還定義 SharePoint 站點的用戶界面和結構，以及加載到文檔庫中的默認文檔 — 文件和模 板。它還為報告服務站點提供默認報告，並定義默認的安全組、區域、迭代和版本控制設置。最後，過程 模板將說明性指南作為 SharePoint 站點的一部分來提供。
首次安裝 TFS 時，您會發現它提供了 兩個過程模板。在 TFS 的 2008 版本中，它們的正式名稱分別是 Microsoft Solutions Framework (MSF) for Agile Software Development (MSF Agile) 和 MSF for CMMI Process Improvement (MSF CMMI)。
MSF 使用很強的客戶交互促進迭代開發過程。MSF 的當前版本是版本 4.0，並且影響 TFS 過程指南，盡管它具有自己豐富的一組 MSF 指導資源。您可以在 Michael Turner 編寫的《Microsoft Solutions Framework Essentials》（Microsoft Press，2006）一書中進一步查找有用的信息。
Microsoft 過程模板中包括的說明性指南深入探討了運行開發項目和構建工作流的方法。本指南 著重介紹了開發過程，而不是 Visual Studio 或 TFS 的機制。您可以通過團隊項目的 SharePoint 門戶 主頁上的“過程指南”鏈接訪問該指南。對於 MSF Agile 和 MSF CMMI 來說，本指南還可以 從 Microsoft 上單獨下載。
深入了解 MSF 模板
一種簡單的區分 MSF Agile 與 MSF CMMI 過程模板的方法是一個靈活，一個正規。這兩種模板都基於屬於七個邏輯區域的團隊成員定義不同的角色 。MSF Agile 模板定義了八個角色作為其團隊模型的一部分。相比之下，MSF CMMI 定義了的角色數量相 當多，為 20 個。如圖 1 所示，CMMI 模板通過更多特定角色擴展了各個邏輯區域。這些角色包括經理和 其他不屬於核心開發團隊的相關人員。
圖 1 MSF Agile 和 MSF CMMI 團隊成員角色
區域 角色 CMMI Agile 體系結構 基礎結構架構師 Y N 體系結構 解決方案架構師 Y N 開發 構建工程師 Y N 開發 開發經理 Y N 開發 開發主管 Y N 產品管理 審核員 Y N 產品管理 產品經理 Y N 產品管理 發起人 Y N 產品管理 行業專家 Y N 項目管理 集成項目管理 (IPM) 總監 Y N 測試 測試經理 Y N 用戶體驗 用戶培訓專家 Y N 用戶體驗 用戶體驗架構師 Y N 開發 數據庫開發人員 Y Y 開發 開發人員 Y Y 產品管理 業務分析師 Y Y 項目管理 項目經理 Y Y 發行工作 數據庫管理員 Y Y 發行工作 發行經理 Y Y 測試 測試人員 Y Y 體系結構 架構師 N Y 用戶體驗 業務分析師 N Y
除了角色之外，您還會發現工作項有許多差別（請參見圖 2），其中包括為每個模板提供的實際工作 項類型的差別。Microsoft 從以下四個方面描述每個工作項類型：用途、字段、工作流和布局。因此，即 使兩個模板都包含一個錯誤工作項時，從根本上說它們的類型也不同。實際上，MSF Agile 與 MSF CMMI 工作項的主要區別在於表示為狀態和轉換的工作流。如果深入了解 MSF Agile 錯誤的過程指南並檢查 “狀態和轉換”部分，您會注意到 MSF Agile 錯誤有三種狀態和 23 種轉換（請參見圖 3） 。而 MSF CMMI 錯誤有四種狀態和 17 種轉換（請參見圖 4）。
圖 2 MSF Agile 和 MSF CMMI 工 作項類型
工作項類型 說明 CMMI Agile 更改請求 更改請求標識對產品或基准的某部 分所做的提議更改。 Y N 問題 問題工作項記錄可能會妨 礙工作或當前正妨礙產品工作的事件或情形。 Y N 要求 要求捕獲並跟蹤解決客戶問題產品所需執行的操作。 Y N 審核 審核工作項記錄設計或代碼審查的結果。 Y N 錯誤 錯誤是通知系統中可能存在或已存在問題的工作項。 Y Y 風險 風險是將來可能會對項目產生負面後果的任何 可能事件或情況。 Y Y 任務 任務工作項通知需要執行某 項工作。 Y Y 服務質量要求 服務質量要求說明系統的特 征，如性能、負載、可用性、壓力、可訪問性、可服務性和可維護性。 N Y 方案 方案是記錄整個系統中用戶交互的單個途徑的 一種工作項。 N Y
圖 3 MSF Agile 錯誤狀態和轉換
圖 4 MSF CMMI 錯誤狀態和轉換
例如，您會注意到 CMMI 錯誤開始時處於已提議狀態， 而 MSF Agile 錯誤一旦創建就處於活動狀態。這兩種類型的錯誤的另一個差別就是用途。Microsoft 使 用 MSF Agile 錯誤捕獲所有錯誤的各方面信息。如果仔細查看非自定義的 MSF Agile 錯誤，您會發現它 包含名為 Issue 的布爾字段。對於 CMMI 過程模板，Microsoft 創建單獨的 Issue 工作項類型。這僅僅 是一個差別示例。但是，使用團隊項目時，上述這些差別將影響您所在團隊的工作流。
每個 MSF 工作項類型在名為“過程指南”的文檔中都有專門的部分進行介紹。過程指南分為兩節：工作 流和活動工作流通常是與給定角色相關的活動的邏輯流。活動是重點解決特殊任務的一組步驟。
每個活動都包含進入和退出條件，並且與一個或多個角色以及一個工作流相關聯。例如，如果查看 MSF Agile 中的“重現錯誤”活動，您會發現它是“修復錯誤”工作流的一部分並且開 發人員是唯一的參與角色。其他活動（如“確定迭代長度”，該活動還是 MSF Agile 模板的 “計劃迭代”工作流的一部分）都包含負責角色（項目經理）和參與角色（開發人員和數據庫 開發人員）。
根據您的團隊和過程的成熟程度，您可以采用指南中提供的所有建議或一部分建議 ，也可以不采用建議。但是，重要的是要意識到 Microsoft 已經設計了每個模板附帶的工作項、報告和 文檔，以便用於各個模板指南的設計。因此，您應該查看文檔，並判斷出哪些適合您的團隊，哪些不適合 您的團隊。然後，您可以決定希望使用所提供的框架，還是根據團隊需要對其進行調整。
自定義 過程模板
盡管您的團隊可以使用現成的一個 Microsoft 模板，但很可能要改進一些內容。大多數 團隊首先要做的工作是自定義工作項。除此之外，還要創建和自定義簽入策略、SharePoint 門戶站點和 報告。
在我最開始所撰寫的《MSDN 雜志》專欄文章中，我高度贊揚了 Team System 豐富的自定 義功能集的優點，過程模板也不例外。幾乎每個過程模板都可以更改和自定義。實際上，有一種好方法可 以讓您了解可以執行哪些自定義操作：花點時間探索兩個更熱門的第三方模板，它們高度體現了 Scrum 開發方式的優點。
Conchango 發布了第一個 Scrum 公共模板（我對此有一定的了解），並提供了適用於 TFS 2005 和 TFS 2008 的模板版本。截止到發稿時，Conchango 向社區免費提供了這兩個版本的模板，但是要求注冊 才能獲得下載鏈接。
下載模板之後，您需要提取內容並運行安裝程序包。配置後，您會發現模板 在“新建團隊項目”向導中顯示為一個選項。如果創建團隊項目，您會注意到該模板的 TFS 2008 版本定義了六種自定義工作項類型、16 項團隊工作項查詢、15 個報告、一個 SharePoint 模板和 自己的過程指南。
第二個熱門模板是 VSTS Scrum 過程模板（輕型 Scrum）。VSTS MVP Mike Azocar、Steven Borg 和 Willy-Peter Schaub 將此模板作為社區驅動的項目。與 Conchango 模板類似 ，項目所有者已使此模板可用於 TFS 2005 和 TFS 2008。此外，他們還提供了支持與 Microsoft Project Server 2007 VSTS Connector 協同使用的版本。
輕型 Scrum 模板的 TFS 2008 版本附 帶了六種自定義工作項類型、18 項團隊工作項查詢、5 個報告、一個 SharePoint 模板和自己的過程指 南。要安裝此模板，必須先安裝 SharePoint 模板。安裝完畢後，使用“過程模板管理器”安 裝其余的輕型 Scrum 模板，過程模板管理器可通過 Visual Studio 內部的“團隊 ”|“Team Foundation Server 設置”訪問。將輕型 Scrum 模板解壓縮到某個文件夾， 然後打開“過程模板管理器”，單擊“上載”按鈕。導航到包含 ProcessTemplate.xml 文件的文件夾後，單擊“上載”按鈕（請參見圖 5）。
圖 5 導入輕型 Scrum 模板
通過這兩種 Scrum 模板，您都可以很好地了解可能的自定義級別。如果搜索 Internet，您還會發現其他模板。一些 VSTS MVP 已經建立了名為“Templex”的 CodePlex 項目來創建社區驅動的過程模板庫。
創建自己的模板
盡管您可以獲取文檔並手動建立自己 的過程模板，但與我合作的大部分客戶都發現從現有的 Microsoft 模板開始更簡單。我將介紹此方法幫 助您入門。
首先，創建一個目錄以下載一個 Microsoft 過程模板。如果認真對待，則應該在下載之後在版本控制 中配置一個位置以簽入模板。借助“團隊”菜單中的“TFS 設置”菜單項，使用 “過程模板管理器”將 MSF Agile 模板下載到 C:\PMT。“過程模板管理器”創建 一個名為“MSF for Agile Software Development–v4.2”的文件夾。在此文件夾中， 您會看到六個文件夾和一個 XML 文件 — ProcessTemplate.xml（請參見圖 6）。
圖 6 下 載 MSF Agile 過程模板的結果
大多數文件夾及其內容都很容易理解。您使用一些 XML 文件描述 過程模板及其內容。這些 XML 文件與實際項目（如報告定義文件、HTML 文檔等）一起定義過程模板。圖 7 列出了配置文件及其所在位置和用途。
圖 7 過程模板配置文件
您可以通過多種方式修改 XML 文件。當然，可以使用任何文本編輯器（如 Notepad）。如果您習慣手 動編輯 XML，而且喜歡使用 Visual Studio XML 編輯器，則可以通過下載 Visual Studio 2008 SDK 與 XSD 文件聯系起來。您會在 %SDK Install Folder%\VisualStudioTeamSystemIntegration\Process Templates\ProcessTemplateSchemas 找到 XSD 文件。此外，還可以在 %SDK Install Folder% \VisualStudioTeamSystemIntegration\Work Item Tracking\WorkItemTrackingSchemas 找到包含工作項 定義和全局列表的 XSD 文件。您可以在 MSDN 上找到過程模板架構文檔。
您可能會發現，隨 VSTS 2008 TFS Power Tools（“基本 Power Tool 工具”中有詳細說明）提供的 可視“過程模板編輯器”更為方便（尤其是在您剛剛接觸整個過程時）。您可以從 Visual Studio 內部 的“工具”菜單中訪問“過程模板編輯器”。
在打開下載模板中的任何文件之前，您應該將文件夾重命名為希望用於模板的名稱 — 例如“MSDN Magazine Agile 1.0”。完成重命名並安裝最新版本的 Power Tools 後，單擊 Visual Studio 中的“工 具”|“過程模板”|“打開過程模板”打開 ProcessTemplate.xml 文件。此時會打開模板設計器。將名 稱和說明更改為合理內容（請參見圖 8），然後保存更改。如果關閉設計器並重新打開該文件，則編輯器 將顯示新名稱。編輯器左側的樹視圖提供了對圖 7 中描述的核心文件以及所有工作項類型定義和工作項 查詢的訪問。
圖 8 編輯新模板的名稱和說明
開始編輯時，主要“過程模板編輯器”提供的大部分項目都很容易理解。如前所述，工作項通常是更 改的第一個大項目。在樹視圖中，選擇“工作項類型定義”節點下方的“錯誤”工作項。Visual Studio 會在“工作項類型”定義編輯器中打開該工作項類型。編輯器允許您使用普通文本框控件更改名稱和說明 。
工作項編輯器包含三個選項卡（請參見圖 9），可提供對工作項類型定義的訪問：字段、布局和工 作流。此外，單擊“查看 XML”按鈕可輕松查看類型的 XML 表示形式。您會在整個編輯器中看到此按鈕 ，對於您來說，這是了解更改原始 XML 文件所產生的效果的好方法。隨著您的不斷熟悉，您可能會發現 編輯 XML 文件比使用“過程模板編輯器”更加快捷方便。
圖 9 編輯“錯誤”工作項類型
“字段”選項卡列出了工作項類型使用的所有字段。Microsoft 將字段定義為包含名稱、類型和引用 名稱。您可以將引用名稱視為字段的完全限定名稱。該名稱必須至少包含兩部分，由句點隔開。引用名稱 在工作項查詢中充當列顯示名稱。
單擊“新建”按鈕可以添加新字段。在“字段定義”對話框中，填寫字段（請參見圖 10），然後單擊 “確定”。“名稱”和“類型”字段很容易理解。您可以選擇的其他有效數據類型包括 DateTime、 Double、History、HTML、Integer、PlainText、String 和 TreePath。History 和 TreePath 是分別專 用於歷史字段和區域與迭代字段的控件。使用工作項實例時，將鼠標指針懸停在字段上時會出現“幫助文 本”。
圖 10 新字段定 義的值“可報告”字段控制 TFS 是否將字段導出到 TFS 數據倉庫，以便您能夠將其包含在報告中。如果 您決定使其成為“可報告”字段，則選擇“Dimension”、“Detail”還是“Measure”非常重要。您可以 對 DateTime、Double、Integer 和 String 字段使用“Dimension”。如果您希望使用字段進行篩選，請 選擇一個“Dimension”字段。當字段使用一組標准值時，此選項最合適。
如果您希望報告的字段包含 大量文本，請使用“Detail”選項。TFS 不會將“Detail”字段放在數據倉庫多維數據集中，而是只放在 關系倉庫數據庫中。您可以對 DateTime、Double、Integer 和 String 字段使用“Detail”字段。
最 後，如果您希望使用公式（例如求和或計數）或對字段執行類似的操作，請使用“Measure”字段（僅支 持 Double 和 Integer 數據）。如果選擇“Measure”，您要從公式字段中選擇一個選項。值得注意的是 ，當前文檔指出只有求和公式有效，這是不正確的。
請切記，將“可報告”屬性應用到字段後，無法 對其進行更改。但是，可以在使用字段後對其應用“可報告”屬性。使工作項的字段成為“可報告”後， 對該工作項所做的任何修訂都將保存在倉庫中（如果存在）。但是，TFS 不會將字段設置為“可報告”之 前所做的更改回填到倉庫中。
創建字段後，您要指定它應該出現在表單的什麼位置。單擊“工作項類 型”編輯器中的“布局”選項卡。您可以單擊“預覽表單”按鈕以查看當前工作項。在樹視圖中，向下移 動直到看到“TabPage - 詳細信息”節點。您會在該節點下看到“組”節點，再下面是兩個“列”節點。
在第一個列節點下的“組 - 常規”節點中，您會看到一個“列”節點。右鍵單擊該節點，然後選擇“ 新建控件”。選擇新添加的控件節點，並使用右側的“屬性網格”將 FieldName 更改為 MSDN.Mag.Beverage。將標簽更改為 Beverage，然後預覽結果。如果您對結果滿意，請保存所做更改，然 後關閉所有打開的編輯器。
使用“過程模板編輯器”，單擊“上載”按鈕，並導航到包含已修改的 ProcessTemplate.xml 文件的文件夾。上載模板後，運行“新建團隊項目”向導，並創建名為 MSDNMagDemo 的團隊項目。（我建議您使用 Virtual PC 映像進行測試，在上文中提到的 Team System 的“基本 Power Tool 工具”文章中有相關介紹。）創建團隊項目後，添加新的“錯誤”工作項並切換到 “詳細信息”選項卡。您會看到新字段。請關閉新的“錯誤”工作項，但不保存。
編輯自定義的模板
假設您希望將該新建字段更改為包含允許飲料的特定列表。此外，您希望能夠對該字段運行報告。由 於您希望此更改對剛剛創建的團隊項目和任何新團隊項目生效，因此您需要多做一些額外的工作。
首 先，單擊“過程編輯器”|“工作項類型”|“從文件打開 WIT”重新打開“錯誤”工作項模板。導航到 C:\PMT\MSDN Magazine Agile 1.0\WorkItem Tracking\TypeDefinitions 並選擇 Bug.xml 文件。查找並 選擇“Beverage”字段，然後選擇字段列表頂部的工具欄中的“打開”命令。將“可報告”字段值更改為 “Dimension”。
接下來，單擊“規則”選項卡，然後單擊工具欄上的“新建”。從“選擇規則類型” 對話框中可以看到，每個字段都可以應用許多規則。選擇“ALLOWEDVALUES”，並單擊“確定”。在 “ALLOWEDVALUES”對話框中，單擊“新建”。在“列表項編輯”中，輸入“Coffee”，然後單擊“確定 ”。再重復兩次該操作，將“Soda”和“Juice”添加到列表中（隨意創建或根據項目的許可情況）。完 成該列表後，單擊“確定”關閉“ALLOWEDVALUES”對話框。單擊“確定”關閉“字段定義”對話框，並 使用 Visual Studio“文件”菜單上的“保存”命令保存更改。
此時，您已更改磁盤上的文件。您需 要按照先前的步驟重新上載模板。在未對 ProcessTemplate.xml 文件進行任何其他更改的情況下嘗試重 新上載時，您會收到此模板已存在的警告。單擊“是”覆蓋該模板的先前副本。
這解決了新團隊項目 的問題。但是，您需要修復 MSDNMagDemo 團隊項目中的現有“錯誤”工作項模板。單擊“過程編輯器”| “工作項類型”|“從文件服務器導入 WIT”。在“導入工作項類型定義”對話框中，單擊“浏覽”按鈕 ，並選擇位於 C:\PMT\MSDN Magazine Agile 1.0\WorkItem Tracking\TypeDefinitions 處的 Bug.xml 文件。然後，在要導入到樹的“項目”的團隊項目列表中，選擇 MSDNMagDemo 團隊項目，並單擊“確定 ”。如果不顯示 MSDNMagDemo 團隊項目，您需要關閉並重新啟動 Visual Studio。
在嘗試添加新的“ 錯誤”之前，必須右鍵單擊“團隊資源管理器”窗口中 MSDNMagDemo 團隊項目節點下的“工作項”文件 夾並選擇“刷新”，以刷新“工作項”定義緩存。圖 11 顯示了您應該看到的界面。
圖 11 已完成的包含新 Beverage 字段的“錯誤”工作項
我希望您已經了解到，Microsoft 為提供工具及其說明性指南付出了多麼大的努力。我建議您花點時 間了解一下這兩個內置模板（或由社區提供的模板）。給自己一點時間，了解一下選擇模板對您的團隊和 整個開發過程的意義。
Brian A. Randell 是 MCW Technologies LLC 的一名高級顧問。他主要從事 Microsoft 技術方面的 講解、培訓和撰寫工作。Brian 是 Pluralsight 的 Applied Team System 課程的作者，同時也是 Microsoft MVP。您可以通過 Brian 的博客 mcwtech.com/cs/blogs/brianr 與他聯系。
