6

我的团队正在寻求将我们的许多工具（SCM、错误跟踪、构建、测试）迁移到 TFS。我们正在考虑分阶段移动每个系统。例如，首先移动源代码控制，然后是错误/功能跟踪等……

由于我们必须选择一个流程模板来使用源代码控制（或 TFS 中的任何东西），我们对决策的锁定程度如何？我希望避免以后必须创建另一个项目（或者这不像我想象的那么糟糕？）。

我知道我理论上可以在事后自定义流程模板配置的所有内容（对吗？），但这在实践中有多可行？

以下是我对事情发生的看法：

  1. 我们迁移我们的源代码。我们选择微软的 CMMI 模板。
  2. 我们创建了一个新的工作项（或签到说明），它是我们遗留错误跟踪系统的简单链接。
  3. 我们工作一段时间。
  4. 我们等到有权力（我们是一家规模相当大的软件公司）制定新的 TFS 开发工作流程。这可能是新工作项的简单集合或配置各种东西的全新模板。
  5. 我们尝试在不丢失历史记录的情况下将我们的 TFS 项目迁移到这个新系统。

我们是否会后悔我们没有等到所有这些决定都完成后才使用 TFS？

4

1 回答 1

9

因此，考虑您的流程模板是正确的，因为存在一定数量的“锁定”，但它并不太严重。就像你被蜂蜜而不是超级胶水粘在你的工艺模板上一样。

就个人而言，我将从 MSF Agile 模板开始。它的重量更轻，包含的工作项目更少——所以你更倾向于向它添加东西（在 TFS 中很容易，得到很好的支持）而不是把它们拿走（更复杂且不完全令人满意）。

但是，如果权力决定采用超级流程定义流程并在 12 个月内神奇地提出一个他们希望您使用的新流程模板，那么它并没有完全丢失。如果您发现要创建一个全新的团队项目，只要它在该服务器上（或 TFS 2010 中的项目集合），那么您可以将您的代码分支到新的团队项目（这意味着历史有点在当前版本的 TFS 客户端中隐藏）或者您可以创建一个新的团队项目，其中包含一个用于源代码控制的空文件夹，然后将子文件夹从旧团队项目移动到新项目。这将完美地保留历史，因为 TFS 会为同一 TFS 实例上的移动保留历史。

显然，通过在实际项目中实际使用 TFS 12 个月，当你受到打击时，你也将处于一个更好的位置，知道你希望你的闪亮的新流程模板看起来像什么 - 我经常发现这是一个从未发生过的练习，大多数人都乐于在 MSF 敏捷的边缘修修补补，或者选择更具规范性的东西，比如Scrum For Team System。

希望有帮助，

马丁。

于 2009-05-05T19:38:04.427 回答