最佳项目管理工具,源代码管理,构建器和维基

时间:2010-09-12 17:41:43

标签: svn tfs project-management wiki fogbugz

你好吗?我正在组建一个新的软件团队,我正在寻找不同的工具来克服我之前与其他团队一起做过的噩梦。

在过去的5 - 6年里,这些是我过去的一些转变:

SourceControl:
CVS => VSS => SVN

项目管理,错误和问题跟踪:
纸=> PostIt Notes => OneNote => BugNet => OnTime

Wiki和文档:
Word +网络共享=> ScrewTurn Wiki

Builder Automation:
巡航控制+ MSBuild

现在,特别是因为SVN和Wiki的情况,我正在考虑以新鲜的方式开始这个团队。在过去,我们有SVN的分支噩梦,我们越努力修复它,它就变得越糟糕。我面临的另一个挑战是寻找稳定和整合的东西。你可以想象BugNet + SVN + ScrewTurn + CruiseControl + MSBuild是完全不同的动物,所以整合和协同作用非常重要;我不想在10个不同的应用程序之间跳转来报告错误或分配任务并审查已完成的工作并查看仓库日志。
所以,新团队和我现在已经谈了几天了,我想我们已经把它缩小到2个可能性了:

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

2。 FugBUgs + Kiln + CC
优点:
- Kiln使用Mercurial,具有分布式源代码控制的所有优点 - 最低的前期成本和计划时间来启动和运行。每位用户每月$ 30.00 - 非常友好的网络用户界面 - WYSIWYG维基编辑。
- 非常简单的问题跟踪器和项目管理工具。整合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.长期价值。
  7. 新团队有4名团队成员+ 1名项目经理(Scrum Master)和1名产品经理(产品负责人)。所以我们谈论的是一个相对较小的新团队。我们将要开发的范围和项目是具有多个项目和分支变体的大型企业应用程序

6 个答案:

答案 0 :(得分:3)

您的团队有多大,每个人都会使用哪种方法/角色?

我想说如果它是一个庞大的团队,TFS可能更适合您的需求 特别是如果您需要发布到sharepoint,或者在您的团队中有更多已定义的角色。

但是,如果您想要更小规模的解决方案,这样可以更好地适应更小的团队,那么SVN / Trac / Cruise Control等最适合您的需求。

答案 1 :(得分:2)

你听起来像是在找Trac之类的东西。

  

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

     

它提供了Subversion(或其他版本控制系统)的接口,一个集成的Wiki和便捷的报告工具。

可以使用插件扩展Trac。 Trac-Hack wiki是插件的地方。

这是另一个要求recommended Trac plugins的stackoverflow问题。

答案 2 :(得分:2)

Redmine救援。

答案 3 :(得分:1)

我建议您使用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构建机制支持WorkFlow。因此,您可以轻松高度自定义构建过程;如果这不适合您,您可以使用其他批处理文件(MsBuild)。

TFS 2010比TFS 2008和2005更容易管理操作。您可以轻松创建构建代理,机器,项目集合等......

TFS 2010支持几乎所有MS产品;比如MS Office。 Excel与TFS或MS Project有很好的集成。不要忘记Sharepoint。

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

但我知道你不能将MSDN Subs的TFS用于商业用途。因为这仅用于测试,只有5个用户可以连接(我不完全确定)

至少,如果需要,您不必在专用服务器上设置TFS(不建议这样做)。如果需要,可以在Win7上进行设置,TFS可以在SQL Server Express上运行

所以我建议您使用TFS 2010.如果您正在开发.Net应用程序,那么TFS就没有比这更好的了。

答案 4 :(得分:0)

到目前为止,我对atlassian产品非常满意。 JIRA与颠覆相结合。如果在提交消息中提供文本标记,JIRA也将显示与问题相关的代码更改。而不是使用FishEye,websvn是svn web前端的首选工具。如果你只是在寻找'wiki',foswiki做得很好。但我从工具链的linux角度看更多。

答案 5 :(得分:0)

绝对没有违法行为,但是......你不断改变 - 你考虑过为什么?你有多自信,你不会发现自己再次改变。这次投入额外的时间和精力来加强它。

如果没有就具体工具提出建议,我会建议你做两件事。

1)寻找工具 chain - 而不仅仅是工具集合。例如,请参阅Seeking a true "tool-chain",其中讨论了可以很好地协同工作的工具。更顺畅的工作流程可以节省时间,并可能增加项目成功的机会。

我注意到你说“你可以想象BugNet + SVN + ScrewTurn + CruiseControl + MSBuild是完全不同的动物,所以整合和协同作用非常重要 “所以我认为我们就那个问题达成了一致意见

2)您需要使用这些工具的人员的接受。不要提出他们的既成事实,提前询问他们的想法。事实上,请他们提出建议。鉴于前一点,这一点可能很棘手。