Thursday, January 16, 2014

Pivotal Tracker and Parallel Releases

I've used a fair number of issue trackers, but lately I've been leaving most heavily on Pivotal Tracker. It sits in the sweet spot between simplicity and complexity for me, does the key elements well and emphasizes some things that I mostly don't need.

In particular, I feel like Pivotal does a really good job of allowing you to keep a prioritized list of features / stories, work on the most important one, know what people are working on and how it's going, manage them with iterations and velocity. It's ability to predict release schedules is also reasonably solid, as is its implementation of subtasks.

Pivotal is very definitely opinionated software. It works well if you approach software from a particular perspective, but there are lots of situations in which Pivotal's approach might either not help or actively interfere with how you might want to run your own project. That's fine, that just means that Pivotal isn't the right tell to help you in that situation.

Its emphasis on user stories means that you can only put so much detail into a story before it starts to feel unwieldy. Some trackers are a more rich environment for describing requirements in detail, but Pivotal's agile mindset doesn't encourage that, and that works fine for me.

You can't really customize the workflow or the issue fields, but the standard workflow and issue fields that Pivotal supports are roughly the ones I would want anyway.

However, a few times I've noticed an area where Pivotal's approach isn't to my liking, around managing parallel releases.

Parallel Releases
It's not uncommon when working on software to have a couple of releases running in parallel. Unless you're doing something like continuous delivery, it's likely that after a significant release, you will sometimes want to deliver bug fixes for the recent release while at the same time working on features for the next release. This is easy to do in most source control systems, and not that hard to do in most issue trackers, but in this case, Pivotal's opinionated simplicity tends to get in the way.

Some examples:

  • If the patch release boundary is already in the 'current' section of pivotal, you can't move tasks above that marker without starting them. This can make it confusing to manage tasks that you want to include in a patch release that will be done during the current iteration. You either have to mark them as started when you may not be ready to do so, or to remember that when you do start them, they need to be moved into the patch release.
  • If you accept a feature for the next significant release while the patch release is still unfinished, the accepted story moves up above all incomplete stories, making it look like it's part of the patch release, when it might not be.
There are workarounds. You might:
  • Not accept features for the next release until the patch release is finished.
  • Always mark patch release stories as started as soon as they're created if you need them to move into the 'current' section.
  • Use labels or epics judiciously to help out.

These do work, and ultimately, it's nothing I'm going to quit pivotal over, but it is an annoyance.

Other Issue Trackers
What other issue trackers might you consider?

GitHub Issues
GitHub is great, and having issues built in works reasonably well for fairly small projects. I use it happily for some open-source projects, but I'm not at all certain that I'd like it for even a relatively small team. I haven't used it much in a team setting, but I suspect I wouldn't be that pleased with its ability to keep me informed about the progress of a team and a project if I were managing scope, timelines, deadlines and priorities for a team.

Basically, what's there works fine, but it's pretty limited and in particular I think it's limitations would be strongest on the planning and prediction side which tends to be pretty important in a corporate setting.

JIRA
Jira has a ton of features, and it's very customizable. If you need a lot of features and you want to customize heavily, Jira might be the tracker for you. That said, in my experience, Jira was always a little clumsy in places, and it seems to have gotten worse in that respect rather than better. It's very easy to end up feeling like you have a lot of good information in Jira but that you can't find all of it when you want to. It's not very good at giving you an idea of how a project is going, it's easy to misconfigure Jira in a way that will end up biting you in the butt. I've seen more than a few Jira configurations that I thought were absolutely terrible.

Still, if you really feel like you need these features and these customization capabilities, I don't know what else to recommend, so it still fills a niche.

Trello
While not strictly an issue tracker, I definitely know people who've used and enjoyed Trello as an issue tracker. It's closest to a kanban setup, so if you're choosing an approach closer to lean software development or kanban, this might be more your style.

I've played with it enough to know that I'd be willing to give it a try on a project, but I'm not certain yet how I'd feel about it.

Sprintly
Sprintly looks like it's a close competitor to Pivotal, but I don't know anyone who uses it and I haven't used it myself. Looks good from the outside.

Bugzilla
Bugzilla makes even JIRA look good. I don't understand why people use it.

Trac
Redmine
Neither of these are terrible choices but neither would be in strong consideration for me.

Lots and Lots More
There are lots of others. Some of them might even be good.

No comments:

Post a Comment