本文将会为您讲述如何使用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”，在项目进度方面，它是一个起决定性作用的视图。团队的主管每天都会使用这个视图来追踪某个迭代的项目进度。这里我就不详细讨论了，因为有很多地方可以学到如何更好地理解一个燃烧图。但是，以后我可能会添加一些新想法的。