本文章是由機器翻譯。

VSTS 2010

Visual Studio Team System 2010 中的敏捷規劃工具

Ajoy Krishnamoorthy

本文以 Visual Studio Team System (VSTS) 2010 的預發佈版為基礎。所有資訊均有可能發生變更。

目錄

長期規劃
版本和小版本規劃
VSTS 2010 Excel 工作簿
產品積壓工作簿
容量規劃
小版本積壓工作簿
報表

“敏捷規劃”存在語意矛盾嗎？希望您不會這樣認為，但在最近于洛杉磯召開的一次專項小組會議中，其中一位與會者指出其組織已從敏捷開發轉為採用更為正式的方法。在經過進一步的詢問後，她坦承其團隊無法再根據其經理的口頭要求進行代碼修復並立即將修復結果部署到生產中。現在，她不得不使用正式的程式。對她而言，即意味著放棄了敏捷開發。

實際上她對敏捷開發的理解並不準確，但是我非常高興她的組織能夠制訂正式的更改流程。敏捷並不是指盲目進行加速或出於速度考慮才選擇敏捷的。相反，它是一種符合標準的規劃方法並且其中融入了經驗資料。

Visual Studio Team System (VSTS) 2010 引入了一些新的特性和功能來説明敏捷團隊進行規劃。在本文中，我將向您介紹一些全新的產品積壓工作簿、小版本積壓工作簿以及一組新報表，它們可以説明敏捷團隊規劃和管理版本和小版本。

長期規劃

人們總是擔心沒有精確的長期規劃，這已成為推廣敏捷方法的主要障礙。在 2008 年度敏捷開發狀況調查中，缺乏事先規劃是受訪組織在採用敏捷方法時最關注的問題。我懷疑對許多人來說，缺乏精確的長期規劃就等同于缺乏協同規劃。敏捷團隊選擇多個層級的規劃並在瀑布式規劃過程中進行期間修正，當然本來就該如此。

Steve McConnell 在軟體評估的不確定性圓錐中指出，在專案中過早進行評估可能會得出不准確的結果，偏向高邊的錯誤最高會達到 400%：“在專案早期，待構建軟體本質的具體細節、特定需求的細節、解決方案的細節、專案規劃、人員構成以及其他專案變數均不確定。這些因素的可變性會導致專案評估的可變性。”

當然，這並不意味著主管人員的管理策略是“我們不知道專案何時能完成，也不知道完成時會是什麼樣子”。它實際上是想說明團隊規劃版本的方法以及各版本中所完成工作的範圍均存在變數。

圖 1 產品和小版本積壓

版本和小版本規劃

對於敏捷團隊而言，規劃是在以下兩個截然不同的層級完成的：版本規劃和小版本規劃。版本規劃是一項高級規劃活動，用於説明敏捷團隊查看各種功能或使用者案例。積壓中的專案隨後被依次堆疊、評估並分配給一組小版本。請注意，在此階段使用的是諸如 T 恤尺寸（小、中、大）等單位來執行評估的。其目的是粗略評估積壓中各個專案的成本，而非精確的報價。這也有助於客戶根據心目中的大致尺寸來依次堆疊需求。

在 Scrum 中，這組使用者案例被存放在一個名為“產品積壓”的清單中（請參見圖 1）。每個小版本中需要處理的工作範圍主要取決於團隊進度。版本的定義主要取決於按照客戶要求完成一組可靠需求的時間。例如，如果需要四個小版本才能實現第一組功能，則預計在第四個小版本後能形成第一個版本。

小版本規劃是一項更為詳細的規劃活動，它在每個小版本開始之前執行。來自產品積壓的高級使用者案例將在核查後根據需要拆分成較小的使用者案例。此時，團隊已準備好將使用者案例拆分成較小的案例並定義完成使用者案例所需的任務。然後將會以小時為單位評估這些使用者案例及相關聯的任務。此時，團隊可以瞭解到小版本的範圍。

在敏捷團隊的工具箱中，除索引卡和便箋外，經常還會發現 Microsoft Office Excel 這一工具。VSTS 2010 引入了兩個新的 Excel 工作簿來説明敏捷團隊管理產品積壓和小版本積壓。但在介紹這兩個工作簿之前，讓我們先來快速瞭解一下 VSTS 2010 附帶的新 Agile 過程範本。

VSTS 中的過程範本包括工作項類型、查詢、報表以及文本指南。在這裡工作項是關鍵實體。工作項可以是使用者案例、任務、錯誤等。首先，在 Team Foundation Server (TFS) 中建立一個團隊專案，然後在“New Team Project Wizard”（新建團隊專案嚮導）中選擇 VSTS Process for Agile Software Development v1.0 範本。此範本包括以下工作項類型：

• 任務
• 使用者案例
• 錯誤
• 問題
• 測試用例

您可以創建自己的工作項類型或自訂特定的工作項。要瞭解更多有關工作項自訂的資訊，請參閱 Brian Randell 在 2008 年 12 月撰寫的有關使用和自訂 TFS 過程範本的文章：“Team System：使用過程範本簡化團隊專案”。

接下來，我們將深入探討 Excel 工作簿並瞭解這些工作項在開發過程中的流動方式以及它們如何説明使用者規劃和管理價值流。

VSTS 2010 Excel 工作簿

在“敏捷性工具”一文中，Kent Beck 討論了敏捷團隊中存在的大量轉換以及在考慮轉換時對工具的需求。基於 Excel 的規劃工作簿與 TFS 工作項跟蹤的集成有助於最大程度地降低轉換開銷。通過使產品積壓和小版本積壓保持同步，可自動將使用者案例或任務工作項的狀態更新資訊捕獲到小版本積壓中以生成各種報表，許多常見活動要麼被淘汰，要麼被優化。

在使用 VSTS 2010 來管理產品積壓和小版本積壓時，建議敏捷團隊使用以下流程：

• 使用 VSTS 2010 Agile 範本新建一個團隊專案。
• 通過將使用者案例添加到產品積壓工作簿或通過在 Visual Studio 中添加工作項來構建產品積壓。
• 根據各個專案在產品積壓中的堆疊順序，將其分配到某個小版本。預設情況下會創建 Iteration 0、Iteration 1 和 Iteration 2。可使用團隊專案設置來創建更多的小版本。
• 設置查詢以從特定小版本中提取使用者案例、任務及其他工作項，並將其映射到對應的小版本積壓工作簿中。

這些工作簿與 TFS 之間的集成是通過查詢實現的。圖 2 顯示了產品積壓工作簿的配置。在 Excel 功能區中，在“Team”（團隊）選項卡上選擇“Work Items”（工作項）組，然後按一下“Configure List”（配置清單）。這將打開“Configure List Properties”（配置清單屬性）對話方塊。在這個對話方塊中，可選擇一個 TFS 查詢，而此查詢的結果正是試算表中所顯示的內容。

圖 2 Excel 工作簿中的查詢

查詢是在團隊專案中創建的。預設情況下，在建立團隊專案時，會創建一個名為 Work Items\Team Queries\Workbook Queries 的資料夾。在此資料夾下，您會發現有關產品積壓和小版本積壓工作簿的預設查詢。

為了更好地理解工作簿的工作原理，讓我們看一看 2008 年 10 月發佈的 VSTS 2010 和 .NET Framework 4.0 CTP 中包含的 DinnerNow 示例應用程式。（可以在 Team Suite 開發人員中心找到最新的 CTP 下載。）產品積壓和小版本積壓工作簿均可在團隊資源管理器的 \DinnerNow\Documents\Shared Documents 資料夾中找到。

產品積壓工作簿

產品積壓主要用作應用程式中客戶所需的需求清單。我聽說有些團隊在指代一組高級需求時也使用事蹟或主題之類的術語。將這組需求收集到一個清單中、確定其優先順序並在較高級別評估它們，這些操作可説明回答此規劃階段的兩個重要問題：

1. 1.應用程式有哪些需求？
2. 2.它的價格是多少？很顯然，其答案只能通過評估得出。我曾看到過有的團隊在此階段使用案例分數、T 恤尺寸或小時來進行評估。

通過回答這些問題，團隊可以更好地瞭解此版本或接下來的幾個版本的大致情況以及這些版本的預計完成時間。通常會存在預算或計畫限制，如即將進行的廣告活動、法律要求或季節性活動等。這有助於規劃版本的範圍，因為您可以根據此限制來管理版本的範圍。

如果為版本設置了目標日期，則在發佈時間框架內，可通過確定將哪些需求包括在小版本中來管理工作範圍。例如，如果規劃始于 12 月而發佈日期定在 6 月，則實際上需要運行四到五個小版本（假定為一個月的小版本）才能完成此工作。

如果目標日期比較靈活，則發佈計畫將取決於完成最低限度的一組需求所需的時間。例如，如果可以在三個小版本內完成最低限度的一組必需功能，則可以設置在三個小版本後出現版本 1。如果可在五或六個小版本內完成下一組功能，則設置在這五或六個小版本後出現版本 2。

圖 3 顯示了 DinnerNow 專案的產品積壓工作簿。您看到的是使用者案例的積壓。在這些使用者案例中，其中多個已被分配給特定的小版本，並且某些已在 Iteration 0 和 Iteration 1 中完成。很顯然，在開始一個新專案時，首先要從空白工作簿開始構建這些高級使用者案例。

圖 3 產品積壓工作簿

這些試算表上的各列是工作項中的欄位，它們依次存儲在 TFS 資料存儲庫中。Excel 和 TFS 之間的集成會使 Excel 中增加一個“Team”（團隊）功能區（請參見圖 4），利用其中的功能表項目可將積壓中的專案發佈到 TFS 中、可利用 TFS 中更新的工作項來刷新積壓，此外還有許多其他功能。

圖 4 Excel 功能區中的 Team 選項卡

積壓中的每一行都被存儲為 TFS 中的一個工作項，如圖 5 所示。經過這種形式的集成後，使用 Visual Studio 的團隊成員現在可從 Visual Studio 自身中更新使用者案例和其他工作項。現在，不必在不同工具之間進行切換即可更新使用者案例、評估結果或剩餘工作的狀態。

圖 5 TFS 中的工作項

容量規劃

作為版本規劃的一部分，敏捷團隊將在試算表中花費大量時間來新增使用者案例、對其進行評估，以及更為重要的，確定它們的優先順序。但是，密切關注版本的狀態也同樣非常重要。產品積壓工作簿包括一個容量規劃工作簿。通過評估使用者案例及其工作所在的小版本，此工作簿可對小版本自身的快速處理提供很大説明。

容量規劃是規劃版本時的一項重要活動。它有助於瞭解可在各個小版本中完成的功能。此計算中的關鍵資料點是進度。進度是在某個小版本中，團隊所完成的工作量。如果恰好有來自先前小版本的資料，則它將是最佳入手點。

圖 6 使用先前的小版本來計算進度

這通常被稱為“根據昨天的天氣進行預報”。實際上，如果 TFS 資料倉庫可用，則容量規劃試算表可從其中提取歷史資料。如圖 6 所示，我可以選擇 Iteration 1 作為從中獲取歷史資料的小版本，並可以鍵入開始日期、結束日期以及團隊成員數。在本例中，進度為 816 小時，這意味著團隊可以在 Iteration 1 中完成 816 個小時的工作。如果對此資料不滿意，團隊可以在開始時使用一個估計值，而在規劃未來的小版本時使用第一個小版本的進度。

在容量規劃試算表中，可指定小版本的日期範圍、團隊成員的數量以及小版本期間的任何中斷情況（如節假日）。通過將此資料與使用者案例評估和進度相結合，可創建一個能夠大體給出小版本工作負荷的圖表。如果發現評估的工作超過了預期的容量限制，則您可能會希望在不同的小版本之間移動使用者案例以得到一個合理的分配。

在我的示例中，我並未在 Iteration 2 中規劃任何工作。我可以將積壓中的一些剩餘使用者案例添加到 Iteration 2 中。現在，容量圖表將如圖 7 所示。這是一種非常不錯的情形——評估工作並沒有超出容量限制。

圖 7 為小版本 Iteration 2 分配了工作的容量圖表

專案啟動後，也可以使用產品積壓工作簿來瞭解各種使用者案例的整體狀態。但是，通過“剩餘工時和進度”、“剩餘工作”和“案例進展”等報表可以瞭解更為詳細的資訊。這些報表均包括在 Agile 範本中，可在團隊專案的 Report 資料夾中找到。我將在本文的稍後部分介紹這些報表。

小版本積壓工作簿

小版本是敏捷團隊的一項關鍵活動。經常使用 Scrum 的敏捷團隊非常熟悉它，將其稱為“衝刺”。小版本的持續時間通常各不相同。對於使用極限程式設計的團隊，小版本的週期為一到兩周；而使用 Scrum 的團隊通常有為期四周的衝刺。

小版本規劃有助於定義特定小版本的範圍。在小版本規劃會議期間，團隊通常會分析針對特定小版本分配的使用者案例、收集詳細的需求資訊、添加相關聯的任務以及評估完成每項任務所需的時間。在此會議中，產品擁有者以及團隊其餘成員將根據以下因素來確定使用者案例的優先順序：依賴關係、成本評估、詳細需求以及特定案例的重要性不如當初預期的可能證據。

首先，我們來看一下 DinnerNow 團隊專案中的小版本積壓。在團隊專案中的 Shared Documents 資料夾下包含名為 Iteration 0、Iteration 1 和 Iteration 2 的資料夾。在其中的每個小版本資料夾中，您都會看到小版本積壓。每個小版本積壓工作簿都會連接到一個特定查詢，它只針對該特定小版本使用者案例和任務。

如果添加了其他工作項類型（如功能、主題或事蹟），則需要將其添加到此查詢中，以便可以在清單中提取出這些額外工作項。DinnerNow 團隊專案中已有多個任務被作為子項添加到 Iteration 2 的使用者案例中。但通常情況下，作為小版本規劃會議的一部分，團隊會添加這些任務並對其進行評估以得到一個滿意的 Iteration 2 小版本規劃。圖 8 顯示了小版本積壓。

圖 8 包含子任務的小版本積壓

TFS 現在支援分層工作項，這將允許您創建父/子樹。在本例中，以下新任務被作為子任務添加到使用者案例“使用者應該能夠通過手機使用 DinnerNow”中：

• 確定 UI 的哪些部分用於手機
• 針對 UI 使用卡堆疊體系結構
• 識別大多數大眾化手機
• 減少下訂單時所需的按鍵次數

此時，團隊已做好了進行任務分配的準備。每個團隊成員在選擇工作量時需要考慮的因素包括該小版本的團隊成員容量、領域專門技術以及團隊成員加入團隊的時間長短。

小版本積壓工作簿還包含一些附加表單，可説明在規劃和執行時處理其他方面的問題。容量規劃工作簿類似于產品積壓工作簿中的工作簿。可使用此工作簿來瞭解團隊的容量。

在規劃期間以及小版本自身執行期間，負載平衡工作簿將派上用場。當出現有關某個特定使用者案例的最新資訊時、當發現針對某個任務的技術依賴關係時或者當某個團隊成員變為不可用時，敏捷團隊將在整個小版本過程中持續進行規劃以執行期間修正。這些具體情況要求更新任務分配，而這正是負載平衡工作簿發揮作用的地方。

另一有趣的工作簿是用於進度跟蹤的工作簿。熟悉板球運動的人們都知道術語“當前得分率”和“所需得分率”。這兩個統計資料可以準確給出某個團隊在比賽中的表現。通常情況下，如果所需得分率高於當前得分率，則擊球團隊必須加快速度才能避免失敗。另一方面，如果當前得分率高於所需得分率，則表明擊球團隊形勢不錯。

在熟悉板球的讀者邀請我打球之前，我想說的是其他統計資料（如出局人數和剩餘輪數）對於全面瞭解比賽情況而言也都非常重要。在敏捷專案中也同樣如此。進度跟蹤表可讓您快速瞭解在某個小版本中完成使用者案例的當前團隊進度和所需進度。就像板球一樣，其他統計資料（如剩餘天數）對於全面瞭解您在小版本中的進展情況也十分重要。例如，如果當前進度趕不上所需進度，則團隊可能不得不縮小範圍。再次重申，關鍵在於要讓客戶瞭解這種狀況並對團隊進行必要的調整。

報表

當然，您不必成為一位狂熱的板球迷也可以開始利用 VSTS 2010 來管理專案。您可以借助各種報表來監視專案的進展情況（如剩餘工時和剩餘工作）。

圖 9 顯示了 Iteration 1 的剩餘工時報表。剩餘工時報表顯示出已完成工作的小時數、剩餘工作的小時數以及進度。從圖表中的剩餘小時數可以看出，團隊並未完成分配給此小版本的所有任務。

圖 9 剩餘工時圖表

趨勢線也顯示了這一狀態。正如圖表所顯示的，實際趨勢線表明在 Iteration 1 中，按照此團隊的速度將無法準時完成工作。在此小版本過程中，團隊可監視剩餘工時並進行必要的期間修正，也可以讓客戶瞭解到發佈計畫可能會受到影響。

剩餘工作報表也非常有用。如圖 10 所示，團隊在完成工作的過程中始終保持穩定的進度。在此小版本過程中，未向積壓添加任何額外工作，這是一個好跡象。在接近小版本終點的時候，團隊的進度也逐漸放緩，並導致未能完成任務。

圖 10 剩餘工作

正如您看到的，VSTS 2010 的敏捷規劃工具和工作簿為團隊提供了一個 Excel 前端，此外還提供了從版本規劃到小版本規劃以及從測試執行到編譯品質等過程中捕獲和挖掘資料的集成資料存儲庫。這為規劃和管理敏捷專案的經理和團隊中的開發和測試人員提供了一個極好的工具——使得他們可以協同工作、評估進度、必要時進行更改以及管理整個專案。此集成消除了敏捷團隊在收集資料和生成報表時需要執行的許多手動和單調的活動。

如需更加倚重數學原理的不同方法來實現高級規劃，請參考 James McCaffrey 博士撰寫的有關此問題的測試運行專欄。

Ajoy Krishnamoorthy 是 Microsoft 模式和實施方案小組的產品規劃主管。在此之前，Ajoy 是 Microsoft Visual Studio Team System 的高級產品經理。其間 Ajoy 負責產品管理、戰略和市場行銷。他在曾擔任過的多個職務（包括開發人員、架構師和技術專案經理）方面擁有超過 10 年的諮詢經驗。您可以流覽其博客，網址為：blogs.msdn.com/ajoyk。