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

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

因为我们使用Scrum,所以TFS中的迭代用于定义我们的发布周期,以及这些发布周期中的冲刺。

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

发布之后,在同时运行下一个版本的同时,向积压工作中添加bug修复/更新是非常好的。

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

区域路径(空间)-可用于描述系统/项目的各个部分。假设您为一个GUI应用程序创建一个团队项目,一些区域将描述它的模块(数据输入、报告、GUI、打印等)。

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

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

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

使用敏捷的规则是,不能完成的特性会被删除。您从不延长迭代日期。

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

注意:如果你说的是瀑布式的,那么规则可以基于里程碑和功能,但是有了敏捷,时间就是王道。

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