在Team Foundation Server 2008中使用区域和迭代

Question

如果您使用的是TFS2005或2008，您如何使用迭代和区域？

您是否为正在构建的应用程序的特定部分创建区域？

这里有一篇关于区域以及TeamSystem团队如何使用它们的有趣文章：

http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx

但是，我对迭代更感兴趣，如果您能向我展示一些具体的示例，我将不胜感激。

您是基于里程碑还是基于某些功能来创建迭代？

完成v1后会发生什么，您如何管理v2或v1的更新？

我们使用的是MSF敏捷模板。

Answer 1

我们使用面积来表示产品线。

由于我们使用了SCRUM，TFS中的迭代被用来定义我们的发布周期，以及这些发布周期中的sprint。

积压项被分配给发布周期，工作项被分配给eash sprint，以确保这些积压项被完成。

在发布之后，将bug修复/更新添加到backlog中，同时处理下一个版本，这是非常好的。

​

​

Answer 2

迭代和区域路径就是您想要的。它是你在空间和时间上描述你的项目的方式。下面是一个简单的例子：

Area Path (Space) -可用于描述系统/项目的各个部分。假设您为图形用户界面应用程序创建了一个TeamProject，某些区域将描述其模块(数据输入、报告、图形用户界面、打印等)。

迭代路径(时间)-描述项目的版本控制或发布周期。在我工作的公司，使用发布版本作为他们的迭代(主要的，次要的，构建的，修订的)。它有助于跟踪工作项，以标记期望它完成的迭代。我们有一个静态的待定迭代，这是创建的所有工作项的默认迭代。管理层将在以后决定将工作项定位于何处，并分配或关闭它们。

Answer 3

我假设您正在使用迭代作为MSF敏捷的一部分，或者一些其他类型的敏捷方法。如果是这样的话，一般来说，你可以计算出你的团队在接下来的n周内可以完成多少工作。一般来说，我们使用了3周，但您的迭代长度可能不同。

如何确定迭代的项目通常基于优先级，这应该基于市场/业务影响(项目的热度)和实现的简易性。影响分数是较重的权重，但您应该在您的分数中考虑易于实现，因为您可能有一些"bang for The buck“项目。

敏捷的规则是，无法完成的功能会被丢弃。您永远不会延长迭代日期。

这应该回答了里程碑与功能的问题。两者都不是。您可以基于时间进行迭代。时间到了。这样，您就可以计算出您的团队对调整下一次迭代的乐观程度，以获得更准确的估计。如果您将迭代建立在功能上，那么您将总是错过日期。里程碑也是如此。

注意:如果你在谈论瀑布，规则可以基于里程碑和功能，但对于敏捷，时间是王道。

现在转到领域:这一点更主观。划分区域的一种方法是对用例进行分组。我喜欢这种方法。但是，当涉及到用户界面时，您也可以为特定的表单等创建区域。