Microsoft Team System 似乎是面向流程的系统实施的绝佳平台，但是如果您剥离 BA、PM 和业务用户的访问权限，而只是在开发团队中纯粹使用它，它是否比仅仅具有更多价值？使用 Visual Studio Professional、SourceSafe、缺陷跟踪工具和 CruiseControl 或 TeamCity 等持续集成服务器？
【问题讨论】：
标签： visual-studio tfs continuous-integration teamcity
是的。您提到的每一项替代技术都是 Team System 软件包支持的（在此版本或下一个版本中）。所有这些组件都旨在在 TFS 中相互集成和协同工作。这是 TFS 团队对所有组件的高优先级。结果是一组在大多数情况下无缝集成的功能。
我不熟悉您提到的其他几个项目，但它们不太可能像相应的 TFS 组件那样相互集成。这并不是说它们没有集成或作为产品表现不佳。只是它们的设计不是为了相互合作。因此，交互不会像 TFS 组件那样清晰。
这是否足够有价值以继续使用 TFS？不知道，因为这在很大程度上取决于您对这种集成的重视程度。
【讨论】：
对我的团队而言，TFS 的一大卖点是它为我们的整个产品生命周期提供了一致性。我们确实允许 BA、PM 和业务用户对 TFS 具有一定级别的访问权限，但即使我们不这样做，该产品仍然具有很大的使用价值。在 TFS 中管理我们的工作流并在整个开发团队中强制执行一致性的能力非常棒。
我们使用 TFS 提供的一些功能：安全性、报告、工作流管理、集成构建、电子邮件警报、分支/合并。
你能用一大堆其他工具来完成它吗？可能，但它不会那么容易管理和维护，而且您可能无法像使用 TFS 那样提取报告和跟踪所需的数据。
在旁注中，如果您指望 Visual SourceSafe 作为您的存储库，我强烈建议您寻找其他地方。从个人和业务经验来看，我可以证明它不能算作一个稳定/强大的存储库。
我的想法。
【讨论】：
当然有价值。仅在 Team SKU 中有大量客户端功能（不要让名字欺骗了你——它们主要只是新的“超级高级”厨房水槽版本，还有一个不错的好处是包括一个服务器 CAL 用于TFS。）此处提供的确切规格：http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx
特别看一下协作功能，系统的价值也很明显，其组件被设计为可以相互“正常工作”。设置是精简的（尽管它还有很长的路要走）； UI 是一致的并且可以相互访问；后端提供统一的报告/分析服务。如果您有一个大型团队，那么整体性能/可扩展性也远远超过目前典型 OSS 套件的能力。
问题是这对你来说是否值得。为什么使用 Visual Studio Professional 而不是 SharpDevelop？为什么选择 SourceSafe 而不是 Git？为什么不用记事本和特别标记的文件夹？
所有商业产品都是有商业目的的（好吧，也许不是 SourceSafe！）。如果您想要具有广泛的功能集、紧密集成、定义明确的支持和测试生命周期、良好的配合和完成等的东西，那么通常值得花费 $$ 并让您的开发人员继续他们的工作。如果您不介意自己进行设置和故障排除，作为开发工作流程的一部分在多个应用程序之间切换，失去查询和报告整个团队统计数据的能力等等，那么一定要开源——许多 OSS 开发人员如今的工具非常可靠。
【讨论】：