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

【问题标题】：Using Areas and Iterations in Team Foundation Server 2008在 Team Foundation Server 2008 中使用区域和迭代
【发布时间】：2010-10-09 20:25:35
【问题描述】：

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

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

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

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

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

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

我们正在使用 MSF Agile 模板。

【问题讨论】：

【解决方案1】：

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

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

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

发布后，可以在处理下一个版本的同时将错误修复/更新添加到积压工作。

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

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

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

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

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

【讨论】：

您是否也像 Kevin 一样使用由特定日期周期定义的迭代？
是的，我愿意。但这对于敏捷来说很常见。如果您不对迭代进行时间限制，那么您最终会同时限制时间（因为管理层一直提供日期）和功能限制。您通常也是资源盒装的，这意味着您必须通过 Z 开发人员交付 X by Y。死亡行军！ ;-)