如果您使用的是 TFS 2005 或 2008，您如何使用迭代和区域？
您是否为正在构建的应用程序的特定部分创建区域？
这是一篇关于区域以及 TeamSystem 团队如何使用它们的有趣文章：
http://blogs.msdn.com/ericlee/archive/2006/08/09/when-to-use-team-projects.aspx
但是，我对迭代更加好奇，如果你能给我一些具体的例子，我将不胜感激。
您是基于里程碑还是基于某些功能创建迭代？
完成 v1 后会发生什么，如何管理 v2 或对 v1 的更新？
我们正在使用 MSF Agile 模板。
我们使用区域来表示产品线。
由于我们使用 SCRUM，因此 TFS 中的迭代用于定义我们的发布周期，以及这些发布周期中的 sprint。
积压项目分配给发布周期，工作项目分配给 eash sprint 以确保完成这些积压项目。
发布后，在处理下一个版本的同时将 bug 修复/更新添加到 backlog 是非常好的。
迭代和区域路径是您想要的。它是您如何在空间和时间上描述您的项目的方式。一个简单的例子如下：
区域路径（空间） - 可用于描述系统/项目的各个部分。假设您为 GUI 应用程序创建了一个 TeamProject，某些区域将描述其模块（数据输入、报告、GUI、打印等......）
迭代路径（时间） - 描述项目的版本控制或发布周期。在我工作的公司使用发布版本作为他们的迭代（主要、次要、构建、修订）。它有助于跟踪工作项以标记预期完成的迭代。我们有一个静态的 TBD 迭代，它是所有创建的工作项的默认值。管理层稍后将决定将这些工作项定位到何处并分配或关闭它们。
我假设您正在使用迭代作为 MSF 敏捷或其他类型的敏捷方法的一部分。如果是这样，一般来说，您会计算出您的团队在接下来的 n 周内可以完成多少工作。一般来说，我们使用了 3 周，但您的迭代长度可能会有所不同。
您如何确定迭代的项目通常基于优先级，这应该基于市场/业务影响（项目的热度）和实施的难易程度。影响分数是较重的权重，但您应该在分数中考虑易于实施，因为您可能有一些“物有所值”的项目。
敏捷的规则是放弃无法完成的功能。您永远不要延长迭代日期。
这应该回答里程碑与功能的问题。两者都不是。您按时间进行迭代。现在是盒装时间。通过这种方式，您可以计算出您的团队对下一次迭代调整的乐观程度，以获得更准确的估计。如果您基于功能进行迭代，您将始终错过日期。里程碑也是如此。
注意：如果你说的是瀑布，规则可以基于里程碑和功能，但对于敏捷，时间为王。
现在到领域：这个更主观。划分区域的一种方法是将用例分组。我喜欢这种方法。但是，当涉及到用户界面时，您还可以为特定表单创建区域等。