JIRA vs TFS 2012 as full ALM system [closed]

Question

we are on the research level of choosing a full ALM system for our company. we consider both TFS 2012 and JIRA for use in product, project managment, QA, support and developemnt teams departments. the things to support are bug tracking, workflows, project graphs (such as bugs count, burn down and so on). any recommendations? pricing? as far as i can see TFS is better for R&D teams using visual studio and less for eclipse.

Answer 1

Here are TFS advantages:

1. TFS is an application life-cycle management (ALM) solution, but Jira is simply an issue tracker. Many features of TFS, e.g. source control and automatic builds are not supported in jira and you should use other solutions, e.g. Subversion or Bamboo to this aim.
2. All TFS components, i.e. source control, issue tracker, build automation are fully integrated. Such level of integration cannot be attained on other solutions.
3. It is fully integrated with Visual Studio.

Here are Jira (and other Atlasian Solutions) advantages:

1. It has been used in MANY open source projects, e.g. JBoss, Spring, etc.
2. For launching TFS, you need a high end server, MS SQL, etc. But Jira could be installed on an ordinary PC on open DBMSes, e.g. my SQL.
3. If you are using Java technologies, many Java IDEs, e.g. IntelliJ, Eclipse and Netbeans fully support Jira. I have not seen such a nice support for TFS.
4. There are lots of plug-ins available for Jira. You can take a look at them here.
5. If your team is small, Jira costs only $10. It is really cheap.
6. Atlasian solutions have better support for java technologies (Ant, Maven, junit, etc.)

Answer 2

I have worked with JIRA / Subversion and now with TFS 2010, and I think JIRA / Subversion are much better tools.

I like the idea of having source control, workitem control, build control, test control in one integrated package, but somehow TFS is just a below average implementation of everything (Except Gated Checkin because that is cool).

TFS version control uses binding just like VSS, so doing multiple checkouts of the same requires extra effort. The ability to Suspend/Resume work using TFS shelveset, is the official workaround for being able to do concurrent work.

TFS sometimes goes haywire with its SQL table locks, so it has be restarted. Also the SQL indexes randomly gets broken, so suddenly showing folder history takes minutes. TFS in VS2010 needs to be online all the time to do any source editing, though this has been fixed in VS2012. But the VS2012/VS2013 GUI is so tightly integrated with TFS, so if the TFS-server has issues, then everything becomes sluggish in VS. This is really visible with the new VS2015 CodeLens, where all TFS WorkItem Lookup should be disabled, or else VS2015 will get stuck more often than usual.

Visual Studio will one or two times during a work week fail to get latest source (sometimes silently). If you attempt to get latest again, then it will say you already have latest. When you perform a build, then it will ofcourse fail. The workaround is to perform a get specific version with forced overwrite.

To create a wiki for documentation, then one have SharePoint, and version 2010 is a really crappy wiki tool.

For some really strange reason Microsoft System Center (really expensive) is completely detached from the TFS solution, and lingers around like an old lady. Making it super difficult to synchronize incidents with TFS-workitems, and get TFS-builds deployed using System Center. VS2013 Update 4 now includes the almost free InCycles Release Management, that should make the continuous integration work better (IIS applications can use Web Deploy).

If you work with advanced stuff like release-branching, then you will be surprised how difficult it is to generate a release notes document (read requires unsupported 3rd party tools). There is no automatic association of Work Items when merging to release-branch. And if you suddenly want to release a new build, then no help around for creating a release-report that lists the changes/workitems that has been included since last released build.

The integration of JIRA/Subversion in Visual Studio (VisualSVN) is so much better (ankhsvn is an alternative opensource version of VisualSVN). Still don't understand why Tfs-annotate cannot jump to next previous version like Svn-blame can.

I have no idea about the difficulty of setting up TFS 2010/2012, but JIRA / Subversion / CruiseControl.NET was very easy and cheap (Guess one would now use Git and Jenkins that also supports Gated Checkin).

VS2012 also includes a redesign of the entire user interface, which includes a new "improved" TFS Team Explorer that is really a pain to work with as a developer (Compared to VS2010). Microsoft has declared that Team Explorer has been fixed in VS2013, but it is not true. It is mouse-click hell to perform checkin and associate tfs-workitems.

Visual Studio 2012 now includes a virtual kanban board, but I would be surprised that this feature is not added to JIRA.

Became very suprised when the Visual Studio Team announced that they will implement GIT support in Visual Studio 2012. Guess it is easier than trying to rewrite TFS into a distributed version control system. Hope the new GIT integration will come up to the standards of VisaulSVN.