我的小组即将迁移到 Team Foundation Server。事实上，我正在努力。
您要决定的一件事是您使用哪种方法 - 敏捷、CMMI 等。
问题是 - 我不知道我们使用什么方法。我的意思是，我们没有积极使用一个。而且我对敏捷或其他方法还不够熟悉，不知道哪种方法（如果有的话）恰好适用于我们的工作方式。
有一些默认的方法吗？例如，如果我们经历一些非常生硬的过程（获取需求、代码、测试、推送到 QA、进行 QA 测试、推送到生产），它还有名字吗？
作为奖励，对于 TFS，一开始就选错了会受到什么惩罚？如果我们决定采用敏捷或其他方式，以后换档有多难？
切换方法没有重大损失——您只需在安装时选择一个默认方法，您可以选择用于任何给定项目的方法。事实上，它只与 TFS 最初如何配置 Sharepoint 项目页面有关 - 您可以在页面创建后添加任何您想要的内容，因此如果您决定更改项目的方法，这并不难。
对于 TFS 开箱即用的两个（Agile 和 SCCM/Waterfall），这确实是您的流程问题 - 您是“尽早且经常”发布，随着错误的出现而发布较小的包，还是运行您的项目在大型迭代中，发布的频率要低得多，但具有明显的里程碑发布？
一个要问的问题（虽然不完全准确，但总是对我有帮助）：产品是否有对最终用户有意义的版本号？例如，许多网站都是敏捷的，因为它们不断发布改进和补丁，并且通常不会有巨大的改进/大修，而像 MS Office 这样的产品有一个有意义的版本号（2003、2007 等），即更可能是 SCCM。
如果您没有明确的方法，那么现在是开发方法的好时机 - 确定哪个发布周期对您有意义，在每个发布周期中创建一个项目并查看 TFS 自动为您设置的内容 - 执行进度指示器和 Sharepoint 页面感觉？有什么明显的缺失吗？
如果您无法辨别方法，那么您正在使用临时方法。它可能类似于现有的方法（偶然）。但是请注意，遵循一种方法并不等于成功。我已经看到很多方法论繁重的项目都失败了，并且很多“裤子座位”项目取得了巨大的成功（如果尘埃落定后可能需要进行一些重构）。
改变方法最取决于你的文化。机构往往抵制变革，而做一些个人。然而，这又取决于情况：如果现有情况明显被打破，一个机构有时可以做出让所有人都感到惊讶的快速改变。
有些方法比其他方法“更重”：那些更难改变或改变。即使是测试驱动开发也很“繁重”，因为事后采用它意味着向旧代码添加大量测试。大多数现实世界的过渡只是添加测试，因为文件是出于其他原因编辑的。同样，从 TDD 迁移到某种瀑布式风格将需要在大型废弃活页夹中记录大量代码。
最基本的方法往往是您的迭代或“瀑布方法”，因为您只是一步一步地进行。不过，它似乎不再那么受欢迎了。