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

Question

如果您使用的是TFS 2005或2008，那么如何使用迭代和区域？

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

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

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

但是，我对迭代更加好奇，如果你能向我展示一些具体的例子，我将不胜感激。

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

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

我们正在使用MSF Agile模板。

Answer 1

我们使用区域来表示产品线。

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

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

发布后，在同时处理下一个版本的同时，可以在后台添加错误修复/更新。

Answer 2

迭代和区域路径是您想要的。它如何在空间和时间描述您的项目。一个简单的例子如下：

区域路径（空间） - 可用于描述系统/项目的各个部分。假设您为GUI应用程序创建了一个TeamProject，一些区域将描述其模块（数据输入，报告，GUI，打印等...）

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

Answer 3

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

如何确定迭代的项目通常基于优先级，优先级应基于市场/业务影响（项目的热度）和易于实施。影响分数是较重的，但你应该考虑在你的分数中易于实施，因为你可能有一些“砰的一声”项目。

使用Agile的规则是无法完成的功能被删除。你永远不会延长迭代日期。

这应该回答里程碑与功能性问题。它既不是。您可以按时进行迭代。这是时间盒装了。通过这种方式，您可以确定您的团队对下一次迭代的调整是多么乐观，以便更准确地估算。如果您基于功能进行迭代，那么您将始终错过日期。里程碑也是如此。

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

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