我们是否错误地使用TFS 2010？

Question

我们的团队是TFS2010的新手.从历史上看,我们使用了自己的业务需求矩阵(可追溯性矩阵)Excel电子表格.它有典型的列,如:

要求ID | 项目| 规则组| 业务规则| 键入...等

我们的业务规则列如下所示:

• "该系统应提供一种方法,允许行为者搜索研究."
• "该系统应提供一种方法,允许行为者搜索项目."
• "系统应为入站包生成一个移动活动."
• "要导入条形码清单,系统应在每个样本占位符中包含一个代码,说明样本已由条形码清单创建."

由于我们行业在文档,审计等方面的严谨性,我们选择了MSF for CMMI而不是MSF for Agile作为我们的流程模板选择.

我们已经就如何将"我们的工作方式"实施到TFS 2010世界的最佳方式进行了大量讨论.我们问题的症结似乎归结为以下几点:

• 看起来我们应该遵循Implementation选项卡中Requirement - > Task之间的"父/子"关系.但是,这意味着我们为每个需求都有一个任务(这似乎是多余的,过于细化).
• 我们喜欢将Task视为不太精细的东西(即"开发出站控制台屏幕".)
• 我们希望开发人员能够查看分配给他们的任务,并轻松查看哪些需求(功能和非功能)与这些任务相关联.
• 可追溯性是一个高优先级,但是,我们不一定非常需要它(直到实际的代码行).正如我们所看到的那样,这样做会使发展变得非常乏味和适得其反.我们希望在这方面有一个合理的平衡.

我们的方法是否真的是圆形钉到方孔中？或者,我们只是误解/遗漏了什么？我们觉得我们对各种工作项类型有充分的了解.

为了增加更多的上下文,我们的理解是"功能"类型的需求是更细粒度要求的"父",例如功能,非功能,QoS.我们知道场景的需求类型类似于用例.

因此,我们认为TFS 2010遵循以下层次结构:

• 要求(特征)
• 要求(功能)
• 任务

显然,我们面临的问题是,虽然我们希望在某些方面需要/任务之间的父/子关系......我们几乎同时看到需要一个任务作为需求的父.

我们相信我们可以跳过Implementation选项卡(以及它强制执行的父/子关系)......并且只需使用All Links选项卡.这使我们可以更灵活地通过其他链接类型(例如"相关"或"影响/受影响")来关联需求和任务......但是,最重要的是,它打破了内置的TFS 2010报告(特别是关于跟踪要求进度/小时).

任何见解都表示赞赏.

Answer 1

听起来您需要自定义TFS附带的开箱即用的流程模板.

说实话,我认为每个人都应该定制模板,以确保他们获得适合他们的过程的工具,而不是改变他们的过程以适应工具.

我不确定你是否知道一些可用的自定义选项,所以我只想提一些我为我公司定制TFS时使用过的选项.

您可以编辑流程模板中现成的任何工作项类型.您可以执行许多自定义,例如,在我的公司中,我们只希望测试组中的人员能够关闭错误,因此我们将该约束放在关闭状态的所有转换上.

您可以根据需要添加转场,状态,字段,选项卡等.

如果您想要一个新的工作项,您可以从空白或基础现有工作项类型创建一个新工作项,从现有类型创建一个新工作项,导出工作项类型,编辑xml以将名称更改为您的新类型,然后导入它.

您应该通过创建自定义链接类型然后将它们包含在新模板中来解决您对不同工作项类型之间关系的疑虑.

您似乎对自己想要遵循的流程有一个很好的认识,我认为您需要自定义TFS以匹配该流程.

执行这么多自定义的一个缺点是标准报告不会为您提供有用的信息.这将要求您的团队撰写一些新报告.如果能满足您的需求,您还可以在Excel中做一些不错的报告.

HTH