JIRA, Pivotal Tracker, and Playnice.ly for issue tracking

-

I've used each of these tools on at least one project now (JIRA for quite a few) and thought I would share my observations about when each one would be most appropriate.

Pivotal Tracker

Pivotal Tracker is only offered as a cloud based or hosted solution, but has a pretty impressive list of customers. On the upside, they've fully embraced the cloud concept and offer a well documented set of RESTful APIs to integrate with third party systems. You can connect issues to SCM commits using post commit hooks from svn or git (or anything with a little effort)

I find the pivotal tracker User Interface be a bit confusing, but pretty useable out of the box and geared toward agile methods. Another big plus is that they can auto-estimate your actual velocity and burndown which helps you get your arms around your real velocity. In addition, they have some out of the box reporting.

playnice.ly

playnice.ly is also a hosted solution, but of the three has taken an more interesting approach to bug tracking. They've jumped on the gamification bandwagon and have tried to craft an experience that is actually enjoyable instead your typical cold-war soviet style user interaction that most bug/issue tracking systems seem to espouse. While innovative, they are missing some features and are decidedly still in the Minimun Viable Product stage.

You can integrate with git via post-commit hooks, but third party integration doesn't exist is still in beta and frankly the documentation was somewhat difficult to find (hint -- the link is in the footer). I can appreciate the idea of keeping things simple and this product will certainly work well for a small agile team or an independent who's just keeping track of things for himself. It's hard to say how this would scale to a larger team or very complex project as it is deliberately bare bones and I suspect this could work against you on a largish project or team.

JIRA

Last, but certainly not least, is Jira from Atlassian. I'd consider this the 800lb gorilla of bug/issue tracking and I've used it for years on multiple projects in a variety of teams and workflows. Frankly, you can do anything you want with this product... They can host it, or you can run it internally with a slew of different databases. It integrates with just about everything, and it has a plugin system that folks have used to build a vast array of plugins to help do just about anything you want.

The default user experience seems is horrendous and to match the impedence between what an agile/small team might need and the default JIRA config you're going to waste a lot of time either fetching plugins or configuring things to work how you want. JIRA's biggest strength is also it's biggest weakness and it would be difficult for me to recommend JIRA for smaller teams or startups as it's enormity imposes to some serious overhead --- either you eat the time trying to figure out the default UI or you eat the overhead of configuring it to be less complicated...

Here are the users I think would be a good fit for the tools:

  • A small team who just doesn't want to lose track of bugs or tasks, and has an interest in keeping an informal and deliberately fun culture - playnice.ly
  • A similarly small team, but one that finds a need for stronger organization and reporting options and/or if you think the idea of bug tracking being fun is somehow off putting - pivotal tracker
  • A large team or large organization who has thousands or hundreds of thousands of issues to track and will end up with a full time person or more to help manage track them. Additionally, if you need to host in-house, JIRA is the way to go

Comments

Post a Comment

Popular posts from this blog

Push versus pull deployment models

-
There are two deployment models: push and pull. In a "Pull" deployment model, the individual servers contact a master server, download their configuration and software, and configure themselves. In a "Push" model, a master server pushes the configuration and software to the individual servers and runs commands remotely. While neither technique is right or wrong, they both have some specific advantages and disadvantages that you should understand when making a decision. In the ruby hosting world, an example of a "push" deployment is heroku , while Engine Yard is an example of a "pull" type deployment. In the Pull model, each server has information about how to obtain it's configuration, when it boots (or whatever the configuration triggering event happens to be) it can continue to proceed without intervention from the master server. In the Push model, because the master server is orchestrating things, it will typically need to have a c
Read more

the myth of asynchronous JDBC

-
Image
I keep seeing people (especially in the scala/typesafe world) posting about async jdbc libraries. STOP IT! Under the current APIs, async JDBC belongs in a realm with Unicorns, Tiger Squirrels, and 8' spiders. While you might be able to move the blocking operations and queue requests and keep your "main" worker threads from blocking, jdbc is synchronous. At some point, somewhere, there's going to be a thread blocking waiting for a response. It's frustrating to see so many folks hyping this and muddying the waters. Unless you write your own client for a dbms and have a dbms that can multiplex calls over a single connection (or using some other strategy to enable this capability) db access is going to block. It's not impossible to make the calls completely async, but nobody's built it yet. Yes, I know ajdbc is taking a stab at this capability, but even IT uses a thread pool for the blocking calls (be default). Someday we'll have async databa
Read more

Installing virtualbox guest additions on Centos 7 minimal image

-
I've just spent some time setting up a bare Centos 7 image to support development stripping out as much as possible. While CoreOS is probably a better choice, we run redhat in production at this point and centos is a better fit for the time being. The problem I've found is that many of the instructions available via google were written against prerelease versions or espouse manually installing random rpms instead of just using yum. While I get this "works", I'm not a huge fan of this approach and would rather do everything with the package manager. After a LOT of scouring and trial and error, I finally found the "magic" combination. The winner is courtesy of http://www.pc-freak.net/ . I've taken these instructions and tweaked them slightly for my purposes. The original poster did this on a more "full fledged" version of centos with a windows host and my instructions are for a minimal install using and OSX host (though I'm certa
Read more