Best Project Management tools, source control, builder and wiki [closed]

Question

Howdy there. I'm putting together a new software team and I'm looking at different tools that overcome previous nightmares I've had with other teams.

Over the last 5-6 years these are some transitions I've gone thru:

SourceControl:
CVS => VSS => SVN

Project Management, Bug and Issue Tracking:
Paper => PostIt Notes => OneNote => BugNet => OnTime

Wiki and Documentation:
Word + Network Share => ScrewTurn Wiki

Builder Automation:
Cruise Control + MSBuild

Now, specially because of SVN and the Wiki situation, I'm looking into starting this team with something fresh. In the past we've had branching nightmares with SVN, and the more we try to fix it, the worst it becomes. The other challenge I have is to find something that is stable and integrated. You can imagine that BugNet+SVN+ScrewTurn+CruiseControl+MSBuild are quite different animals, so integration and synergy is very important; I don't want to be jumpint between 10 different applications to report a bug or assign tasks and review the work completed and look at the repo log.
So, the new team and I have been talking this out for a couple of days now, and I think we've narrowed it down to 2 posibilities:

1. TFS 2010
Pros:
- All-in-One solution. It truly has it all, including a new SCRUM process template.
- Very friendly user interface and SharePoint integration.
- WYSIWYG Wiki and Office Integration.
Cons:
- High upfront costs in hardware and admin time. Software too, but it doesn't affect us because we have an MSDN subscription with free software.
- I'm hesitant about the source control of TFS. SC is file-based and with central repository just like SVN and VSS. I really don't want to fall for the same issues we've had in the past.

2. FugBUgs + Kiln + CC
Pros:
- Kiln uses Mercurial, with all the benefits of distributed source control.
- Minimal upfront costs and planning time to get it up and running. $30.00 per user per month.
- Very friendly web user interface.
- WYSIWYG Wiki editor.
- Very simple issue tracker and project management tools. It would be easy to integrate SCRUM processes.
Cons:
- Lacks builder automation tools for more integrated processes (like TFS). So this will mean we'll have to keep on banging our heads with command line functions and community tasks to maintain our builder workers.

Back in the day, I used Visual Studio Team System 2005 and I didn't take the best memories with me about the system; but the new TFS 2010 seems a very solid bet. FogBugz and Mercurial are kinda like the new kids in the block and they bring fresh thinking to the new processes, but as always this is a double edge sword.
Anybody with solid experience with any of these? Are we missing that 3rd option? Do you have that silver bullet for my problems?

1. Tools Integration
   1.1. Source Control
   1.2. Wiki
   1.3. Build Automation
   1.4. Project management
   1.5. Issue Tracker
2. Minimize Source Control Branching and Merging conflicts (yes, it is necessary for us to branch out and merge)
3. Friendly User Interface (not everybody is CMD hacker)
4. WYSIWYG Wiki.
5. Learning Curve for developers.
6. Time to get it all running VS. Long Term Value.

The new team has 4 team members + 1 Project Manager (Scrum Master) and 1 Product Manager (Product Owner). So we are talking about a relatively small and new team. the scope and projects we'll be working on is large, enterprise applications with multiple projects and branching variations

Dispirited

For source control: git is the master of branches! :) – Bowie

"SC is file-based and with central repository just like SVN and VSS. I really don't want to fall for the same issues we've had in the past." This is not the case with TFS. TFS source control is all in the relational db. – Attenuation

Do not agree with the assumption that there is a high amount of hardware cost or admin time required for TFS. With a small dev team, like you have, you can easily host the application and data tiers on desktop machines running a flavor of Server, or could do a single machine setup on one more powerful box. Admin time is not that extensive either. Following the directions from MS, TFS can be setup in a couple of hours (mostly waiting for the installations). We created SGs in AD and mapped those to our projects, so we don't even need to touch TFS for staffing changes. "It just works." ;-) – Domoniquedomph

Ran out of room in my previous comment. Should clarify, TFS 2010 makes things a lot easier than TFS 2008. Microsoft made a solid effort to streamline the experience, and if you already have MSDN, you really should be looking for a compelling reason not to use TFS, since your licensing costs are already covered for your devs. You may need CALs for your product owner / project manager if he/she do not have licensed copies of Visual Studio. Personally, I like keeping with one product for as much as possible. – Domoniquedomph

These are all great comments. It is interesting though that nobody has even mentioned or bring up FogBugz as an alternative to TFS as a product to solve these problems. It seems to be quite a bit of support for TFS and other independent tools but not for FogBugz or Kiln(ultimately using Mercurial). Some of the team members are doing some homework and hopefully we'll come up with the best decision by next week. Thank you all for the support! – Dispirited

We finally decided for TFS 2010. Thanks everyone for the great feedback! – Dispirited

Answer 1

I suggest you to use TFS 2010 and Visual Studio 2010 (if you are developing .Net Applications)

You don't need to worry about SC at TFS. TFS stores everything in SQL Server DB. TFS works on a web server, so you can connect your source control where you want.

WI tracking is a plus. TFS has an amazing WI tracking mechanism. You can customize your WIs if you want. TFS supports additional software process such as MSF, CMMI or Agile.

Test capabilities of TFS 2010 is perfect. If you use with Visual Studio 2010 you can maximize your efectiveness with TFS 2010.

Branching is allways annoying when the time comes to merge; but TFS 2010 allways helps you. You can track changes at your sources before branches and merges.

TFS 2010 Build mechanism supports WorkFlow. So you can highly customize your build process easily; if this is not okey for you, you can use additional batch files (MsBuild).

TFS 2010 has an easier administration operation then TFS 2008 and 2005. You can easily create build agents, machines, project collections, etc...

TFS 2010 supports almost all MS products; such as MS Office. Excel has a great integration with TFS Or MS Project. Don't forget Sharepoint.

TFS is not only a source code management system, TFS is a project management system, application lifecycle management system, workitem tracking system, and so on..

But i know you can not use TFS from MSDN Subs for commercial purposes. Because this is only for test and only 5 user can connect (i am not exactly sure)

At least, you don't had to set up TFS on a dedicated server if you want (this is not recommended). You can set up on Win7 if you want and TFS can work on SQL Server Express

So i suggest you TFS 2010. If you are developing .Net Apps nothing can be better then TFS.

Bondage

We finally decided for TFS 2010. Thanks everyone for the great feedback! – Dispirited

Answer 2

How big will your team be, and what methodology / roles will everyone use?

I would say if it's a huge team, TFS might more suit your needs.
Especially if you need to publish to sharepoint, or have more defined roles in your team.

However if you want a smaller scale solution, which will fit a smaller team better, something like SVN/Trac/Cruise Control might best fit your needs.

Ickes

The new team has 4 team members + 1 Project Manager (Scrum Master) and 1 Product Manager (Product Owner). So we are talking about a relatively small and new team. – Dispirited

I have to add that the scope and projects we'll be working on is large, enterprise applications with multiple projects and branching variations. – Dispirited

Your TFS Server can host just about everything and doesn't need to be incredibly powerfully. The biggest thing to look for is fast disk. TFS will be a DVCS in the near future... Branching and Merging complaints from 2005 and 2008 (well founded) are a thing of the past. I use Git often and the b/m in TFS 2010 is just as good. SVN just won't cut the needs of a team any longer. Git/Hg or TFS allows you to implement good practices of development isolation. If you are ever going to work disconnected from the TFS network, go DVCS. If you plan to have connectivity all of the time. Go TFS. – Biped

Answer 3

You sound like you're looking for something like Trac.

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. Our mission is to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.

It provides an interface to Subversion (or other version control systems), an integrated Wiki and convenient reporting facilities.

Trac can be extended with plugins. The Trac-Hack wiki is the place to go for plugins.

Here's another stackoverflow question asking for recommended Trac plugins.

Pimp

Answer 4

Redmine to the rescue.

Detwiler

Answer 5

So far I have been very pleased with atlassian product(s). JIRA integrates very well with subversion. If you provide a textual tag in your commit message, JIRA will display issue related code changes as well. Instead of using FishEye, websvn was the tool of choice as svn web front end. If your just looking for a 'wiki', foswiki does a good job. But I'm looking more from a linux angle at the tool chain.

Heurlin

Answer 6

Absolutely no offence intended, but … you keep changing - have you considered why? And how confident can you be that you won't find yourself changing again. Invest extra time and effort on getting it tight this time.

Without advising on specific tools, I will advise you to to do two things.

1) look for a tool chain - not just a collection of tools. See for instance Seeking a true "tool-chain" which discusses tools which play well together. A smoother work flow should save time and might increase the project's chances of success.

I note that you say “You can imagine that BugNet+SVN+ScrewTurn+CruiseControl+MSBuild are quite different animals, so integration and synergy is very important “, so I think that we are in agreement on that one

2) you need acceptance from the people who will use these tools. Don't present them with a fait accompli, ask what they think – in advance. In fact, canvas them for suggestions. This point might be tricky in light of the previous point.

Cabal