本文將會為您講述如何使用TFS 2010 MSF Agile 5.0流程模板為迭代項目而提供的工作簿。首先，讓我們看一看Visual Studio 2010 IDE中的Team Explorer插件：

　　接下來，我們將會進入到SharePoint project portal中，為大家展示Team Explorer是如何模擬它的結構的。我們首先右擊名字是Team Project的標題的那個節點，如下圖所示：

　　這會讓我們進入到SharePoint project portal中，如下圖所示。注意Team Explorer是如何模擬這個結構的，你可以創建新文件夾，上傳文檔，或復制/粘貼現有的文檔或文件夾。

　　現在，讓我們回到Team Explorer，在Team Explorer中，我們將會選擇“Product Planning”工作簿（對于這個Team Project來說，它是“Product Backlog”）：

　　在雙擊這個“Product Planning”工作簿以后，我們現在可以看到下面這張“Product Backlog”工作表。在這里，你可以為整個項目批量錄入工作項。Stack Rank作業，設置Area Paths，和在項目等級上錄入Story Points來平衡workload等工作都可以在這個工作簿中完成。

　　如果你想修改查詢，你可以選擇“Configure”下拉列表框，然后選擇“List”項，如下圖所示：

　　選擇List以后，你將會看到一個對話框，這個對話框可以讓你選擇你喜歡的查詢。默認的Product Backlog是一個flat query，所以，我建議你改成hierarchical query。

　　現在，我們將會選擇“Iterations”工作表，如下圖所示，在“Iterations”工作表中，我們可以為定義的每個迭代輸入開始和結束的 日期。基于在“Product Backlog”工作表中錄入的Story Points，你將會在“Velocity”圖表中看到這個workload。在你項目開始的時候，你將會看到有什么事情被計劃了，在某個迭代中，對于那 些已經完成的用戶故事，你可以看到交付這個用戶故事所花費的小時數的增加，以及在這個圖表中的顏色編碼。還有一點需要注意一下，Team Size字段可以粗略地表示在某個迭代中交付的工作量。

　　接下來，我們一起來看一下“Interruptions”工作表，它可以有效地屏蔽掉那些在項目進行期間無法工作的那些日期。

　　現在，讓我們回到Team Explorer中，在Team Explorer中，我們將會選擇第一個迭代的Iteration Backlog。對于每個迭代來說，我們都會得到一個iteration backlog。TFS（Team Foundation Server）給每個Team Project預置了3個迭代，但是你可以復制和粘貼迭代文件夾，讓它指向Team Queries中的合適的查詢。你必須要在Team Queries中執行復制/粘貼操作，為每個迭代修改查詢。一般來說，在理想情況下，如果在Team Queries中對一個迭代執行了執行拷貝/粘貼/修改操作，然后緊接著就應該在Shared Documents文件夾下對一個迭代執行復制/粘貼/修改操作。

　　雙擊以后，我們將會看到“Iteration Backlog”工作簿，如下圖所示。在這個工作簿中，你可以管理來自于那些工作表的所有迭代——把任務安排到特定的迭代中，在“燃燒工作表”中，針對燃 燒圖設置各個迭代的日期，為團隊成員（私人事件或假期）設置中斷，為團隊成員做Capacity計劃。（和2008版本相比，這是一個巨大的改進，僅次于 按等級劃分的工作項）

　　通過Product Backlog，你可以通過選擇“Configure”下拉列表修改underlying query。如下圖所示：

　　當你從那個下拉列表中選擇“List”的時候，你將會看到一個對話框，這個對話框可以讓你選擇不同的underlying query，如下圖所示：

　　當我們選擇Settings工作表的時候，我們可以為這個迭代輸入一些日期，而且，這個工作表還可以計算天數，如下圖所示：

　　接下來，我們可以選擇“Interruptions”工作表，在這個工作表中，我們可以為計劃的中斷輸入一些日期，以及這個特定的迭代中的一些假期。在“Capacity”工作表中，可以從各個capacity中減去這些日期。

　　接下來。我們看一看比較重要的“Capacity”工作表。僅次于“Burndown”工作表，在任何一個迭代中，這個工作表都是第二有用的工作 表。請注意，我已經安排到“Iteration Backlog”中的任務都反映在這里了，你也可以看到在“Interruptions”工作表中指定的假期也被考慮進來了（也就是說，對于這個迭代來 說，有效的工作時間是15天，而不是19天）。還有，Hours/Day字段被用來表示某個團隊成員的“理想”工作時間（根據我的經驗，一般是6個小時， 所以，開發者們進行估算的時候一定要注意，真正的估算值是不包括飲水機旁的閑聊時間，上洗手間的時間，或與其他重要的人進行溝通的時間的。）

　　在“Individual Capacity”圖表中，綠色的區域是團隊成員可以工作的時間的總數。在這個迭代中，藍色的部分是實際被分配的工作量。在理想情況下，分配給一個團隊成 員的工作應該和他可以完成的工作量相當。如果一個團隊成員落后了，會通過Over字段（這個字段是基于每天錄入的時間的，我稍后將會討論這方面的內容）反 映在這個圖表中，然后，這個工作表中的工作可以被重新調整。另外，任何時間你都可以回到“Interruptions”工作表，為某個團隊成員增加更多的 時間，然后再回到”Capacity“工作表重新進行調整。

　　至于團隊成員任務的時間錄入，在客戶的重壓之下，這是我的主要工作。十分簡單，不用每天都錄入時間，燃燒圖和報告都是沒有意義的。在Task工作項中，你將會看到所有重要的字段，如下圖所示：

　　一般來說，當團隊成員們坐下來，把整個團隊當成一個整體來進行估算的時候（我推薦這樣做），每個團隊成員都會做一個初步的估算。當團隊成員開始完成 某個特定的任務的時候，每天，他們都在推進這個任務，他們將會輸入要完成這個任務，還需要多少個小時，以及在那天完成的小時數。原始的估算值不應該被改 變，因為TFS（Team Foundation Server）會使用它來計算還沒有列入計劃的工作。如果在某一天“Remaining”字段的值增加了，而不是減少了，那么就像我上面討論的那樣，這會 被反映到“Iteration Backlog”的“Individual Capacity”工作表中。

　　我們最后要介紹的工作表是“Burndown”，在項目進度方面，它是一個起決定性作用的視圖。團隊的主管每天都會使用這個視圖來追蹤某個迭代的項目進度。這里我就不詳細討論了，因為有很多地方可以學到如何更好地理解一個燃燒圖。但是，以后我可能會添加一些新想法的。

NET技術：Visual Studio 2010中敏捷開發流程模板的應用，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。