在 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 以确保完成这些积压项目。

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

Answer 2

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

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

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

Answer 3

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

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

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

这应该回答里程碑与功能的问题。 两者都不是。 您按时间进行迭代。 现在是盒装时间。 通过这种方式，您可以计算出您的团队对下一次迭代调整的乐观程度，以获得更准确的估计。 如果您基于功能进行迭代，您将始终错过日期。 里程碑也是如此。

注意：如果你说的是瀑布，规则可以基于里程碑和功能，但对于敏捷，时间为王。

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