Tools for the Development Team - JIRA

  

Crikey, where did the time go?

This has been a very busy time for the team with a large number of projects and small alterations coming through as well as RFIs and RFPs (Request For Information / Proposal) to answer. It is at these times when a good issue management tool proves its worth and certainly ours did.

I've talked a lot about the different tools that we've looked at here, but we did finally make a decision, the winner was JIRA from Atlassian (http://www.atlassian.com/software/jira/).

So what was it about JIRA that made it stand out against the, sometimes free, competition? It does what it does well.

Many of the other programs that I looked at tried to do many things, and in my opinion, sometimes meant that it did none of those very well. JIRA doesn't suffer from that. It knows what its supposed to do and it does it well. That's where the final decision lay as far as the team were concerned.

Getting to know JIRA.

I had used JIRA in the past so it was second nature to me, but not yet to the team. There were a couple of language constraints that we had to get past before some of the team could understand the concept. Everything you place in JIRA is an "Issue". It doesn't matter if its a suggestion, a bug, a task, whatever it is, if its in JIRA, then its an "Issue". This is one of the very few things that I could not change in JIRA.

The other area that new users will enjoy getting used to is that nearly everything in JIRA is configurable. At times it seems that everything that is asked for is there within the configuration available to the JRIA Administrator. You will get to understand how such things as Notification Schemes and Permission Schemes work, and you can assign different schemes to different projects.

Projects

Users or Administrators (depending on what rights the Administrator gives each user or user group) can set up Projects in JIRA and create Issues to the projects. A Project can be either a standard project with a beginning and an end (e.g. a software development project), or an area we can place tasks for normal things needing to be done (e.g. an application or "IT Admin").

I have set up the Notification Scheme so that users will get an email when they area assigned to an issue or when someone has added a comment to an issue that is assigned to them. You can set up notifications as you wish. Users can also "watch" particular issues and be emailed whenever anything changes. You can even email JIRA to open a new issue or add a comment and email attachment to an issue.

Issue numbers are related directly to the project via a 3-4 letter prefix. For example, you might have a project called "IT Administration" and a project called "Worldwide Enterprises Project", which will have a prefix of IT and WWE respectively. Issues in IT will start IT-1, IT-2 etc. and issues in WWE will start WWE-1, WWE-2 etc. so it's easy to know what project an issue relates to. You will find the team with a new vocabulary of words like WWE-193 and IT-22 arising in every sentence.

Users can log work against issues and time tracked.

Workflow

The Enterprise version has a number of tools that allow you to create and change the workflow, however we opted for the standard which uses a good workflow.

With the standard, an issue is Open when it is created. Once a developer starts work on it, they can change it to In Progress, unless its a small issue that is completed in less than 30 minutes - they can then just go straight to Resolve.

I have set it so that only myself and QA can Close an issue, but anyone can Reopen it for any reason.

Issues are never deleted, only closed.

Issues can be Resolved in a number of ways and the user is presented with the following in the Standard JIRA, the other JIRA versions allow you to add to or change these :

• Fixed (default) : A fix for this issue has been completed to the satisfaction of the user
• Won’t Fix : The problem described is an issue which will never be fixed (e.g. the issue relates to a previous version and the workaround its to upgrade)
• Duplicate : The problem is a duplicate of an existing issue (user can link the issue to another)
• Incomplete : The problem is not completely described. Used only if the creator of the issue cannot supply any further information (i.e. the creator is no longer available or all attempts to contacted have failed).
  Normally, if the problem is not described correctly, it is up to the user to reassign the issue back to the creator with more questions as comments
• Cannot Reproduce : All attempts at reproducing this issue failed, or not enough information was available to reproduce the issue. Reading the code produces no clues as to why this behaviour would occur. If more information appears later, the issue may be reopened.

Searching

Users have two ways that they can search for an issue or comment.

"Quick Search" is a seemingly insignificant little search box up the top right of the screen that is extremely powerful. Type anything into there (like "VPN Connection") and JIRA will do a very fast search of all its issues and give you a list of all issues contain that word or phrase. If you know the JIRA number, just type it in and you'll be taken directly to the issue.

"Find Issues" is a menu item that allows you to find issues by creating a Filter. Filters can be created on the fly, saved to a name (e.g. "All Unresolved Development Issues"). JIRA will automatically add a Filter to show you all issues currently assigned to you.

Setting up these Filters is a simple idea of selecting from the list of selections for the fields to search, for example, selecting 1 or more projects to search. Other areas in this search is the Query on the Summary, Description and Comments fields. Query is a reasonably powerful search facility explained Here. Date and time fields have the ability to enter either specific dates, or relative dates (within the last x hours/days, in range from/to). This allows me to, for example, set up a filter to report on all JIRA issues created last month (don't tell my boss that my monthly management reporting is that easy).

When you activate or view a Filter, it shows in a list that you can scroll through and export to Excel or Word, and

Filters can be set up to appear on your JIRA Portal.

The JIRA Portal

The front screen in JIRA can be set up differently by each user. You can add, delete, and move items around the screen to suit yourself. You can add Filters that you created yourself and add pre-set Portlets. These include such things as Project Stats; Admin functions; Filter Stats; My Watched Issues; and Issues in Progress. These can be arranged as you like with the most used Portlets showing at the top of the screen.

My own Portlet shows some details about projects; lists all my save Filters; Overdue Issues; Issues update within the last 8 hours; Resolved issues awaiting me to Close; Issues I'm watching; My assigned issues; and a few of the available graphs that I got from a free JIRA Plugin available from the Atlassian website.

Using JIRA

After using JIRA now for a few months I can honestly say that I have resolved a number of team issues here. I know what is happening; what the team is working on; issues are tracked and comments are added as new information comes in or things are done; the developers and BA can fully understand issues with a place to keep documents, screenshots and comments; work can be prioritised; and everyone can see what work lies ahead of them.

Nothing gets forgotten; work is logged against issues; issues are assigned to others where necessary within the workflow; and management reporting is completed.

The Down Side

Of course there's a downside -  it costs real money. JIRA comes in Standard, Professional and Enterprise editions costing US$1,200, US$2,400 and US$4,800 respectively. While I would have loved the Enterprise edition, we are getting by quite nicely on the Standard edition.

You will have to keep on top of it when you first install it as there is a mind-set that says "I've assigned this issue to someone else, it's no longer my problem". It's also easy to simply ignore issues assigned to you and then get upset when you have hundreds of issues in front of you.

Summary

As I said, "JIRA works". Sometimes it comes down to that. As a Development Manager I can trust it, the developers trust it, and everyone in the company trusts it.

Try it out for free on your server for a month or two. They'll extend the free trial if you ask them nicely, but I don't think you'll need it. It's so nice to find nice people who actually support and use their product themselves.

 

Just a quick note: I have no affiliation with JIRA\Atlassian . I don't know anyone there and I don't get anything free from them .. although a tee-shirt wouldn't go astray (HINT HINT Atlassian - Grin).

Tools for the Development Team - SourceForge

SourceForge

SourceForge (http://sf.net/powerbar/sfee/) was the real contender against Jira and we took a good hard look at it, putting it through its paces. The price (free for less than 15 users) was a compelling argument, as was its document storage and version control of those documents. We installed it on a server here and the team had a play. The following are our findings.

Initially we found SourceForge (SF) very slow. This was perhaps related to the fact it was set up as a virtual machine. This also meant that it was many gigs to download.

There was a small learning curve, same as any new product I suppose. The one thing that threw me immediately was that Tasks is not the area you place issues. Within a project, you can "create" new Trackers, and its in that new tracker area off the Main Menu where you can now track issues, or "Artifacts" as SF calls them. I'm not sure that I like the term 'artifact' as I don't want issues buried for centuries for some scientist to dig up to find out how we performed our work.

You create fields or use the defaults, you can categorise tracker items and the items are also colour coded to show their priority. You can even ask tracker to auto assign different categories to different people. While the auto assignments worked very well, I wanted to auto assign depending on the development process - e.g. auto assign to me all new issues and I can then distribute them to the available team member, then auto assign to QA when the issue is resolved. However, this is another system and what it offers is good.

SourceForge has several areas of concentration:

• Tracker - an issues register
• Documents - a document control system where company and technical documents can be stored, and a sort of version control is applied (more about that shortly)
• Tasks - These are project tasks as opposed to software issues.
• Source Code - links to Subversion or other source/version control systems
• Discussion - a nice discussion forum with threaded messages
• Reports
• Release Packages
• Wiki
• Project Admin

Documents

The document control was a really nice feature that we gave high marks to. I can add folders and sub folders and place documents in them, just like Windows. The main difference here is that when I go back and add updated files into the same folders, instead of overwriting the files as Windows does, SF treats the newer files as new versions of the older files. I can then review previous versions, almost like I was in a Version Control program.

Discussions

The SF discussion forums were a nice touch. You can associate a discussion with a tracker artifact, people can reply to discussions and you

can select to "watch" a particular discussion to get an email when someone adds to the discussion. You can also have it automatically sending out to a mailing list.

There were a couple of downsides to the discussions. When replying to a comment, you can not see the discussion you are replying to. This will surely cause a lot of mis-quoting. Also, it seems that the user is unable to edit their own discussion after posting so even if they find they have misquoted, they can't edit that to change it. While I can understand not being able to change a comment if another has replied, surely you can edit to change that spelling mistake or typo you noticed in that frozen moment after you press save and before it was redisplayed.

File Releases

It is a convenient tool to package files in a patch set. You could upload all the files needed for a patch and when pressing the downloading release button, it saves all files into a zip file. Good for patches but I'm uncertain for major releases.

Reports

Reports can be defined to report on any searchable criteria. A standard report of a graphical summary and the report detail will then be generated. Reports can be on Tasks (project) or Tracker Artifacts.

Wiki

The Wiki was a disappointment. It was a simple and very basic Wiki without even the ability to add graphics other than as a URL. It has a different command set than I was used to but as it was so limiting, it wouldn't take long to learn.

General

It had a nice interface and some nice additions when compared with Jira, however when even after 2 weeks the company still could not reply to even a standard sales enquiry (sent by two of us separately), we were left wondering about the likelihood of any response to a real support query. That was the real clincher as far as we were concerned. Sadly, we dropped SourceForge from our list.

Tools for the Development Team (2)

To continue where I left off, the management team, of which I am a member, looked at Jira in a totally different manner. Each person had their own needs for a tool ever so slightly different to Jira. This caused some problems as I was then asked to evaluate a number of other tools that, perhaps with some compromise, everyone can use. Some suggestions were forthcoming and I dutifully took at look at each one.

The problem with the approach that I made to the management team was that I had obviously failed to impress what the development team needed in the tool. You see, I was out to sell the tool to the rest of the company and in doing so I was focusing on their needs instead of the development team's. This meant that instead of learning how the development team were going to contribute and communicate better, they were thinking "how can I use this new tool", which invariably led to "I need this tool to do X, and I know one that does X much better than this". Of course, that meant that they were thinking of their own needs and Jira just didn't cut it for them. Dang, I missed the plot there.

I got suggestions to consider like Phpaga (http://www.phpaga.net). This is an excellent tool for contacts, invoices, financials, and billing tasks, but it has little to nothing to do with the development process. After discussing this and writing up a small review for the management team I suggested that a CRM package was more in line. They have one so will look again at using it effectively.

Almost all applications I looked at served a single particular purpose, and added some other purposes somewhere along the scale of between "ok" and "that really sucks".

So lesson learned. What I should have done is sold it as a development tool. I could have shown the management team how much better the development team was going to be, how much more accountable, how they will now get both statistics and answers from this bunch of strange speaking weirdos that did things magical and totally unknown things that produced the final products. Now they might understand what's going on there and the tool will be well supported.

As I stated in my last post, I have a number of tools that I will touch on briefly over the next few posts, but as you might have guessed, we have finally decided on Jira. Surprisingly that decision was not made by me. The development team were also asked to review a few of the more successful tools and give their feedback but it was their own decision that we should go with Jira. While Jira did not have the nicest interface or the best reports, and it was only an issues register, it was voted in as the tool to use.

Tools for the Development Team

We placed Jira onto our live server and began using it for real about 2 weeks ago now. So how's it going? Rather well as it turns out.

(Jira is from Atlassian (http://www.atlassian.com/software/jira/) and is an issue tracker tool, see earlier posts for discussions.)

I did a demo for the Development Team and they took to it like a duck to water, now that they understood what it's used for and how. I did the same for the rest of the Management Team and they took to it as well, but in a different way.

Initially it was not used as well as I'd have liked so I put a little pressure on the team by being a bit of a pain in the neck for a couple of days..

Me: "What are you working on?"

Developer: "I'm updating xyz here that needs a new abc because Freda from WxyCorp has found a glitch with it"

Me: "I don't see this in Jira, have you added it?"

Developer: "Um... (ticidatacida) .. I have now (grin)"

Me: "Oh, OK then. You know that if you are working on anything, no matter what it is, it .."

Developer: ".. yea yea, I know, - ..'it needs to be in Jira' (sigh)"

The developers are good guys and they really understood the reasons for putting everything in Jira but being developers, they wanted to just develop. Now I note that no-one is working on anything without a Jira issue and they themselves police that nicely by suggesting that others create a Jira issue before they can start on any work. Nice.

This means of course, that all work is logged and reporting and reviewing can be carried out. Issues are assigned to others with questions when more information is needed, and they get an email to tell them when the issue is reassigned back to them with the answer. Once the have completed the work, they "Resolve" the issue and assign it to the QA Manager. Only the QA Manager and myself as Administrator, can "Close" an issue.

The Management Team has been impressed with Jira but they all have their own ideas of other tools that would work better for what they want to do. Some other tools that I have looked at are...

• SourceForge Enterprise - http://sf.net/powerbar/sfee/
• Trac - http://trac.edgewall.org/
• Mingle - http://studios.thoughtworks.com/mingle-project-intelligence
• Confluence - http://www.atlassian.com/software/confluence/
• FDDTracker - http://www.itps.com.au/dotnetnuke/

Other areas I have also look at with a mind to solving some other issues here, they include...

• TrueCrypt - http://www.truecrypt.org/
• AllSync - http://www.allsync.biz/help/a_produktbeschreibung.htm
• SyncToy - http://www.microsoft.com/windowsxp/using/digitalphotography/prophoto/synctoy.mspx

and I'll hope to have others added to that list soon.

I'll talk on each of those and our eventual decisions as I go along in other posts. In the meantime, I'd like to hear what tools you are using with your team or even on your own to help with development and running a software team.