最佳项目管理工具、源代码控制、构建器和 wiki

Question

你好。我正在组建一个新的软件团队，并且正在寻找不同的工具来克服我之前与其他团队一起经历的噩梦。

在过去的 5-6 年里，我经历了一些转变：

SourceControl：
CVS=> VSS=> SVN

项目管理、错误和问题跟踪：
纸=>便利贴=> OneNote =>错误网 => OnTime

Wiki 和文档：
文字+网络分享=> ScrewTurn Wiki

构建器自动化：
Cruise Control + MSBuild

现在，特别是由于 SVN 和 Wiki 的情况，我正在考虑用一些新鲜的东西来组建这个团队。过去，我们在 SVN 中遇到过分支噩梦，而且我们越是尝试修复它，情况就越糟糕。我面临的另一个挑战是找到稳定且集成的东西。你可以想象BugNet+SVN+ScrewTurn+CruiseControl+MSBuild是完全不同的动物，所以集成和协同非常重要；我不想在 10 个不同的应用程序之间跳转来报告错误或分配任务并检查已完成的工作并查看存储库日志。
因此，我和新团队已经就这个问题讨论了几天，我认为我们已经将其范围缩小到两种可能性：

1. TFS 2010
优点：
- 多合一解决方案。它确实拥有一切，包括新的 SCRUM 流程模板。
- 非常友好的用户界面和 SharePoint 集成。
- WYSIWYG Wiki 和 Office 集成。
缺点：
- 硬件和管理时间的前期成本很高。软件也是如此，但这不会影响我们，因为我们订阅了免费软件的 MSDN。
- 我对 TFS 的源代码控制犹豫不决。 SC 是基于文件的，并且像 SVN 和 VSS 一样具有中央存储库。我真的不想陷入我们过去遇到过的同样问题。

2. FugBUgs + 窑炉 + CC
优点：
- Kiln 使用 Mercurial，具有分布式源代码控制的所有优点。
- 最少的前期成本和规划时间来启动和运行。每个用户每月 30.00 美元。
- 非常友好的网络用户界面。
- 所见即所得维基编辑器。
- 非常简单的问题跟踪器和项目管理工具。集成 SCRUM 流程会很容易。
缺点：
- 缺乏用于更集成流程的构建器自动化工具（如 TFS）。因此，这意味着我们必须继续用命令行功能和社区任务来维护我们的构建器工作人员。

以前，我使用的是 Visual Studio Team System 2005，但并没有给我留下关于该系统的最美好的回忆。但新的 TFS 2010 似乎是一个非常可靠的选择。 FogBugz 和 Mercurial 有点像新来的孩子，它们为新流程带来了新的思维，但一如既往，这是一把双刃剑。
有人对这些有丰富的经验吗？我们是否缺少第三个选项？你有解决我的问题的灵丹妙药吗？

1. 工具集成
   1.1.源代码控制
   1.2.维基
   1.3.构建自动化
   1.4.项目管理
   1.5.问题跟踪器
2. 最大限度地减少源代码控制 分支和合并冲突（是的，我们有必要进行分支和合并）
3. 友好的用户界面（不是每个人都是 CMD 黑客）
4. WYSIWYG Wiki。
5. 开发人员的学习曲线。
6. 是时候让 VS 运行起来了。长期价值。

新团队有4名团队成员+1名项目经理（Scrum Master）和1名产品经理（Product Owner）。所以我们谈论的是一个相对较小且新的团队。我们将从事的范围和项目是大型企业应用程序，具有多个项目和分支变体

Answer 1

您的团队有多大，每个人将使用什么方法/角色？

我想说如果是一个庞大的团队，TFS可能更适合您的需求。
特别是如果您需要发布到共享点，或者在您的团队中有更明确的角色。

但是，如果您想要一个更小规模的解决方案，更适合较小的团队，那么 SVN/Trac/Cruise Control 之类的解决方案可能最适合您的需求。

Answer 2

您听起来像是在寻找类似 Trac 的东西。

Trac 是一个用于软件开发项目的增强型 wiki 和问题跟踪系统。 Trac 使用简约的方法进行基于 Web 的软件项目管理。我们的使命是帮助开发人员编写出色的软件，同时不妨碍他们。 Trac 应该尽可能少地对团队既定的开发流程和政策施加影响。

它提供了 Subversion（或其他版本控制系统）的接口、集成的 Wiki 和方便的报告工具。

Trac 可以通过插件进行扩展。 Trac-Hack wiki 是寻找插件的地方。

这是另一个 stackoverflow 问题，询问推荐的 Trac 插件。

Answer 3

Redmine 来救援。

Answer 4

我建议您使用TFS 2010和Visual Studio 2010（如果您正在开发.Net应用程序）

您不需要担心TFS的SC。 TFS 将所有内容存储在 SQL Server DB 中。 TFS 在 Web 服务器上运行，因此您可以将源代码管理连接到您想要的位置。

WI 跟踪是一个优点。 TFS 拥有令人惊叹的 WI 跟踪机制。如果需要，您可以自定义 WI。 TFS 支持其他软件流程，例如 MSF、CMMI 或 Agile。

TFS 2010的测试能力非常完善。如果您与 Visual Studio 2010 一起使用，则可以最大限度地提高 TFS 2010 的效率。

当需要合并时，分支总是很烦人。但 TFS 2010 总能帮助您。您可以在分支和合并之前跟踪源的更改。

TFS 2010 Build机制支持WorkFlow。因此您可以轻松地高度定制您的构建过程；如果这对您来说不合适，您可以使用其他批处理文件（MsBuild）。

TFS 2010 比 TFS 2008 和 2005 具有更简单的管理操作。您可以轻松创建构建代理、机器、项目集合等。TFS

2010 支持几乎所有 MS 产品；例如微软Office。 Excel 与 TFS 或 MS Project 具有良好的集成。不要忘记共享点。

TFS不仅仅是一个源代码管理系统，TFS还是一个项目管理系统、应用程序生命周期管理系统、工作项跟踪系统等等。

但我知道你不能将MSDN Subs中的TFS用于商业目的。因为这仅用于测试，并且只有 5 个用户可以连接（我不太确定），

至少，如果您愿意，您不必在专用服务器上设置 TFS（不建议这样做）。如果需要，您可以在 Win7 上进行设置，并且 TFS 可以在 SQL Server Express 上运行，

因此我建议您使用 TFS 2010。如果您正在开发 .Net 应用程序，那么没有什么比 TFS 更好的了。

Answer 5

到目前为止，我对 atlassian 产品非常满意。 JIRA 与 subversion 集成得很好。如果您在提交消息中提供文本标记，JIRA 也会显示与问题相关的代码更改。 websvn 没有使用 FishEye，而是选择作为 svn Web 前端的工具。如果您只是寻找“wiki”，foswiki 会做得很好。但我更多的是从 Linux 的角度来看待工具链。

Answer 6

绝对没有冒犯的意思，但是……你一直在改变——你有没有想过为什么？你有多自信你不会发现自己再次改变。这次要投入额外的时间和精力来把它拉紧。

在不建议具体工具的情况下，我会建议您做两件事。

1）寻找一个工具链 - 而不仅仅是工具的集合。例如，请参阅寻求真正的“工具链”，其中讨论了可以很好地协同工作的工具。更顺畅的工作流程应该可以节省时间，并可能增加项目成功的机会。

我注意到你说“你可以想象BugNet+SVN+ScrewTurn+CruiseControl+MSBuild是完全不同的动物，所以集成和协同非常重要
“，所以我认为我们在这一点上达成了一致：

2）你需要得到使用这些工具的人的认可。不要向他们呈现既成事实，提前询问他们的想法。事实上，向他们征求建议。鉴于前一点，这一点可能很棘手。