We are rolling out Jira to try out as our centralized ticketing system. I am in charge of the rollout, and it occurs across several, disparate software development projects. Currently, I have 4 different projects, running on 3 different ticketing systems: RT, Trac, Jira.
In order to keep track of the rollout project itself, I was thinking that it would be great to track it in Jira (we have a local installation, as well as an installation of Confluence, and I believe both are running pretty recent versions). How would you all recommend I go about setting this project up? Should I just use plain old Jira to track everything, or is Confluence going to buy me something as well? I should also mention that I would like to investigate any relevant plugins that might be considered essential for project management and project tracking.
Jira. Get the Greenhopper plugin. Make sure you have a setup for you ticket support base projects that is reusible and doesn't change much. Tracking a project roll out and communicating out the status will be easier with Greenhopper and managing it inside there as well.
Thank you for your response...I will take a look at Greenhopper. (Although I thought Greenhopper was only for Agile projects.) Could you elaborate a little bit on "make sure you have a setup for you ticket support base projects that isreusible and doesn't change much"? I'm not sure exactly what you mean by that.
Greenhopper can me blended to work for your needs. Most of the teams that I support that use it, us it as a blended method where workflow plays heavily on the project management side of things.
Support is support. Most of the stuff that will be going into support projects is probably going to be largely the same definition. If you allow every project doing support to heavily customize, you will either have to make a bunch of folks Admins who shouldn't be, or you are going to have a high overhead. Think of defining a common "template" for a project, so each project is 80% the same. 10% of the customization could be done via context of project for Jira. The last 10% is genuine need for difference, but it shouldn't be common.
For example, in a support instance of Jira we spun up it went from 5 projects for 5 different teams up to now 20. If we didn't define a project template and what is "common", we would be repeating the same discovery over and over again.
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot