Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Book Review: JIRA 4 Essentials

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Bug 33

frisket writes "The JIRA issue-tracking system has been around for seven years and has proved popular in commercial as well as open-source environments owing to its licensing arrangements (free of charge to certain classes of organizations, and source code available to developers). The release of v.4 in 2009 (now at 4.4) brought some major changes to the UI and searching, a new plugin architecture, and the ability to share project dashboards outside the system. Patrick Li's JIRA 4 Essentials is a comprehensive guide to the interface and facilities that both presents the material straightforwardly and avoids the trap of just being a guide to the menus. Although it is aimed mainly at the administrator, it will also be useful for the desktop user wanting a standalone system." Read on for the rest of Peter's review.JIRA is an tracking system for issues arising in software project management and development (the vendor, Australian software company Atlassian, seems to avoid the use of the phrase "bug-tracker".) It's written in Java and runs on all three main platforms, and can be downloaded for server or desktop, or run hosted, and there is a 30-day trial period.

Pricing is scaled by number of users in bands, and is for a perpetual license with a year's support. Although it is commercial software, Atlassian provides it free of charge to open source projects — one reason for its popularity in the movement — and a limited set of non-profit organization types. Academic and developer licenses are also available at a reduced rate.

JIRA 4 Essentials: Track bugs, issues, and manage your software development projects with JIRA is aimed at the administrator who needs a comprehensive description, explanation, and reference to JIRA that goes beyond the online documentation. Patrick Li has also provided a book that the end user can use and learn from (I administer systems, but not JIRA; but I use it for several applications).

So why this book? JIRA's online documentation is very good, and fine for reference and searching, but the book explains the features in much more detail, with more background on factors like why you might want to use one particular feature rather than another. Patrick Li has done what few authors of the "About..." style of book do: produce a readable yet detailed explanation of how to use an application, without simply reproducing each menu in turn.

The book is divided into ten chapters, approaching the topic from the project management and issue management point of view. This approach means that newcomers learns why they might want to do something rather than just how.

Chapter 1 covers getting started: a description of the JIRA architecture (I did say this was for admins and developers), followed by installation options and the installation process itself (Java, MySQL, and JIRA). The examples and screenshots here are for Microsoft Windows users of the standalone version (which comes bundled with Tomcat): experienced admins on Unix-based systems are assumed to know how to install Tomcat and deploy an application. Very sensibly it includes a section on installing HTTPS, something neglected by many web-based systems.

Chapters 2 and 3 are on project management and issue management as dealt with in JIRA. They take an outward-in approach, describing the overall management facilities (project administration and configuration) before going on to the finer detail of components, issues, priorities, and resolutions. This can be a little frustrating for the admin taking over a running system, and needing to perform individual tasks; or for the user wanting to add an issue rather than configure an entire project, but the four-level table of contents provides enough overview to let you find the right section. The running example used for illustration is a project support desk, and the many screenshots are detailed and accurate. Chapter 3 ("Issue Management") in particular is very detailed: this is one area where most users will spend most of their time, so it merits this approach.

Chapters 4 and 5 deal with field and screen management respectively. The fields available in any interface are always an annoyance to the end user: the one you need is never there, and there are dozens that you can't imaging ever wanting. Getting the fields and their configuration right is critical to the success of any installation, and Li rightly spends a lot of the chapter on customizing the field set. A similar approach pays off in Chapter 5 on screen management, although it would have been useful to cover some of the concepts of usability such as field order logic, data entry types, and flow logic between screens, which tend to be neglected by busy admins, only to raise issues later with the interface to the issue management software itself.

Chapter 6 is on workflows and business processes: how to adapt the concepts of Chapters 4 and 5 to the business logic of your organization. This is possibly one of the most important configurations, as it forms the interface with the rest of the company, but it is the only chapter I would take issue with, as the writing seems to be less coherent and convincing than elsewhere, as if it was done in haste. It's perfectly accurate, so far as I can tell, and the screenshots are carefully detailed; it's just slightly less easy to read, particularly the central part on transitions and conditions. But this is a small defect overall.

Chapter 7 is on setting up email notification and SMTP. As with most collaborative systems, email can be used both as an input and an output, and there is a set of templates that can be edited to reflect the way your company wants users to be notified. (I live in hope that some company will say "Thanks for submitting ticket XYZ. I'm sorry we screwed up on that one: we're fixing it and we'll let you know." which would be much more honest than the usual marketing claptrap.) Mail submission is an often-neglected way of communicating, and it's good to see it get decent attention.

I mentioned earlier that it was good to see HTTPS being covered: the same is true of Chapter 8 ("Securing your JIRA") which covers the benefits and shortfalls of signup, captchas, the permission hierarchy, and the roles of JIRA sysadmin and JIRA admin.

The final two chapters cover searching and general administration. Searching is one of the biggest bugbears in bug^H^H^Hissue submission: people have so many different ways of expressing what they feel to be the matter that no amount of urging will make them write the same topic when they submit the same bug. Dev teams have to deal with repeated duplicate submissions which would be avoided if search engines would only let people find earlier reports of the same thing, but this magic continues to elude us. JIRA introduced JQL in an attempt to help: this is based on a field=value query syntax which is fine for token list fields, but not much use for freetext searches, where a thesaurus would be more useful. However, Li explains the problem and the solutions available, and also covers setting up stored filters, and creating dashboards and reports. The last chapter (10) deals with customizing the general look and feel, colors, logos, date and time configs, and the use of plugins (the Google Docs Connector is illustrated).

Each chapter has a summary, but they are rather short. It would be more useful to see a whole page summarizing the material covered, rather than just a few lines: this would then provide a valuable resource when using the book for training. Perhaps a re-issue of the book for v.5 could address this.

There are some minor cultural/linguistic problems with the use of "a software" and "softwares" as nouns, and the occasional appearance of "manual" for "manually", which indicates that some tighter copy-editing might be appropriate for a future edition. There is a good two-level index, but it is unclear from simple capitalization what the semantics of entries are (a reserved word or phrase? a key value? a prompt or GUI widget?). A minor annoyance is the otherwise very good Table of Contents, which appears to have been done by a PowerPoint user, with the font-size continually shrinking and the margin indenting as the depth increases (for the page numbers as well as the entries!): better control of the design is needed.

Overall, I found the book both readable and useful. It is well illustrated with very clear screenshots, using tooltip-yellow callouts to explain fields and prompts. The writing style is light and illustrative, explaining why an action is needed before how to do it.

On the subject of training, the book would probably be useful to trainers for the same of its detailed procedures (go here, click this, type that, click there). Li does state that JIRA can be used for managing issues outside the software issue-tracking field, which implies that it could be used by non-IT people at some stage, and training would certainly be needed. The HelpDesk application example, which recurs throughout, will probably be a useful point of reference for the majority of readers. If the future plans for JIRA are to extend its reach outside the IT issue-tracking field, it might be useful to develop a non-IT application example for another edition.

You can purchase JIRA 4 Essentials from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

ahhh java (1)

mewsenews (251487) | more than 3 years ago | (#37333916)

It's written in Java and runs on all three main platforms

write once.. run on three platforms

Issue Track... (-1)

Anonymous Coward | more than 3 years ago | (#37333944)

...my penis.

Slow news day? (0)

nurb432 (527695) | more than 3 years ago | (#37333998)

A review of a non-free book about a non-free application. *yawn*

Re:Slow news day? (0)

thePowerOfGrayskull (905905) | more than 3 years ago | (#37334188)

It's just the weekly Packt Press feature.

Depending on which definition of free you mean: free jira licensesare given to OSS projects.

Re:Slow news day? (0)

southpolesammy (150094) | more than 3 years ago | (#37334234)


Re:Slow news day? (1)

shawn(at)fsu (447153) | more than 3 years ago | (#37334468)

This just in, I'm being told that many things in life aren't free.

http://www.mychatta.net (0)

Anonymous Coward | more than 3 years ago | (#37334038)


Maybe it's just me... (2)

lattyware (934246) | more than 3 years ago | (#37334076)

Maybe it's just me, but does it seem like a bug tracker shouldn't require a book to use?

I've used JIRA, and I can't imagine this being anything other than stating the obvious.

Re:Maybe it's just me... (1)

Snotman (767894) | more than 3 years ago | (#37334202)

I guess it depends on your SDLC so I would think it is somewhat relevant when it comes to customizing it for how you do your work.

Re:Maybe it's just me... (2)

Eponymous Coward (6097) | more than 3 years ago | (#37334204)

If you think JIRA is just a bug tracker, then you should probably pick up a copy of this book.

I'm looking for a bug tracker and JIRA seemed way too complicated. After reviewing lots of different systems, my coworkers and I agreed on RedMine. The most interesting thing is that cost had nothing to do with the decision (RedMine is free). My second favorite was YouTrack, but it was just a bit too basic (it really is just a bug tracker).

Re:Maybe it's just me... (1)

Espectr0 (577637) | more than 3 years ago | (#37334998)

RT is way much better than anything else unless you want an integrated forum with your tracker, in that case i guess redmine would be fine.

Re:Maybe it's just me... (1)

Tim C (15259) | more than 3 years ago | (#37337588)

It really depends on how you use your bug tracking system. My company used to use RT for tracking customer support tickets and frankly it wasn't up to the job of tracking defects, at least for us; once it was confirmed that a ticket really did represent a defect that needed to be fixed we (in development) copied the report into our bug tracking software and used that instead.

Re:Maybe it's just me... (1)

Eponymous Coward (6097) | more than 3 years ago | (#37339160)

I had never looked at RT. We aren't planning on using the forum part of Redmine, we just liked the simple UI and the fact that you could do things without having to click a never ending stream of submit buttons (I'm looking at you, JIRA). I think I should install RT and take it for a spin. I especially like the fact that you can buy support which is the one big problem with Redmine (IMO).

Re:Maybe it's just me... (1)

k8to (9046) | more than 3 years ago | (#37337104)

at its heart, jira is a bug tracker. That's what the design was more or less built around.

However, it's true that it can do a lot of other things reasonably well.

Unfortunately, it's also true that they keep making the UI slicker, but worse to actually use.

Re:Maybe it's just me... (1)

PmanAce (1679902) | more than 3 years ago | (#37335424)

Greenhopper, custom reports, etc. Not all is straighforward.

Re:Maybe it's just me... (1)

Techman83 (949264) | more than 3 years ago | (#37336324)

It doesn't require a book to use, but rather to configure. Well if you want to get fancy with your configuration anyway. The Out of Box experience is well suited to managing software development (It's not just a bug tracker, it's a full software development management suite), however if your using it for something unrelated to software, it takes some tweaking.

We are using it to replace a completely custom developed .NET piece of garbage and there hasn't been a road block that isn't crossable or at least worked around. It's extremely powerful, which means things can get a little complicated. The documentation is pretty good and I haven't struggled much in getting my head around the concepts.

Re:Maybe it's just me... (1)

Pascal Sartoretti (454385) | more than 3 years ago | (#37350358)

Maybe it's just me, but does it seem like a bug tracker shouldn't require a book to use?

To use it not, but to configure it certainly.

Who needs a book for Jira? (1)

Anonymous Coward | more than 3 years ago | (#37334090)

Surely all the required information is in the manual?

It's hardly the most complex piece of software out there, pretty self-explanatory from what I have seen of it.
...............now Bugzilla on the other hand... -_-

Maybe you need a book (1)

OrangeTide (124937) | more than 3 years ago | (#37340216)

It's probably the most flexible issue tracker out there, and there are a lot of ways to set it up and hook it into other systems. If you didn't realize that, then maybe you need a book?

goodie, this week's packt noise (1)

thePowerOfGrayskull (905905) | more than 3 years ago | (#37334164)

If you buy a book on how to use JIRA, you deserve to be parted with your money.

On the other hand it's nice to see packt reviewers are listeningto the complaints and including the bad as well as the good, while giving it a score that accurately reflects both.

Oh wait. That must have been in the *other* reality.

ahhh Packt (2)

turkeyfeathers (843622) | more than 3 years ago | (#37334302)

It's been a while since we've seen a good Packt book review here... I was beginning to wonder if they'd missed making their regular payments to Slashdot.

Re:ahhh Packt (0)

Anonymous Coward | more than 3 years ago | (#37334734)

Track your issues with Drupal.

Re:ahhh Packt (1)

Fnord666 (889225) | more than 3 years ago | (#37335682)

It's been a while since we've seen a good Packt book review here...

The duration "eternity" springs to mind...

fuck3r (-1)

Anonymous Coward | more than 3 years ago | (#37334548)

the longejst or

Slashvertisement (1)

nitehawk214 (222219) | more than 3 years ago | (#37334788)

So did Jira somehow magically get super complicated last week that it needs a book? No. Is there something brand new that makes it Slashdot newsworthy? (a laughable concept that it is) No, Jira 4 was released over a a year ago.

Fuck Packt, This bullshit has convinced me to never consider their books. If Slashdot and Packt would own up to the fact that their "reviews" are paid for, I wouldn't hate them, I simply would ignore the paid reviews.

Wow good rating (2)

Desler (1608317) | more than 3 years ago | (#37334864)

rating 7

How very helpful. This is a 7 out of what? 7 out of 7? 7 out of 10? 7 out of 50?

Re:Wow good rating (1)

geminidomino (614729) | more than 3 years ago | (#37335728)

7 easy payments of $19.99 to pay for the slashvertisement.

Re:Wow good rating (0)

Anonymous Coward | more than 3 years ago | (#37338716)

or couple of hours of manually labor.

Not Just a Bugtracker (1)

WhoBeDaPlaya (984958) | more than 3 years ago | (#37336222)

JIRA is far beyond being just a bugtracker. I implemented a complete EDA service request submission and progress tracking system in it. Quite a fair bit of subtleties involved.

Jira is not a bug tracker (1)

angel'o'sphere (80593) | more than 3 years ago | (#37338582)

Jira is an issue tracker. If you don't know the difference you should probably not be in software industry.
Yes, you of course can track bugs. But you can also track user stories, test scenarious plan a roadmap for development, do your Scrum or XP planning with it, book working hours on issues (or the subtasks of the issues) generate your time sheet, track your project costs, your projects progress and much much more.
Every issue has a type and based on that a typical set of fields and its own defined workflow. Every workflow has roles attached to the actions so that only certain roles can close an issue or move it from "implemented" to "tested" to "verified" to "done".
Of course everything can be freely configured. The ticket tracker can as well be connected to your version controll system.
I would claim that 99% of the tickets I saw so far in Jira instances where development and planning related and max 1% where defects / bugs. But well I once worked for a small company that originally used Jira only for bug tracking and milestone planning (one single ticket per milestone) where developers only booked working hours on that issue (to send the monthly bill to the customer).
I transformed them to really utilize Jira but as they where not really good analysts/developers/testers they had about 10% to 15% bug rate in their Jira. But now they had the defects related to CVS commits, responsible developers, and cross linked with the requirements and the stories and the sprint they where planned for.

It's Java, so I'll skip it. (0)

Anonymous Coward | more than 3 years ago | (#37339158)

One thing you quickly discover when you have to support hundreds of applications running on thousands of desktops is that Java applications are a system administrator's nightmare.

This is less true when dealing with server-side Java - if it's running on a server, and it behaves like a typical Java program, you can just give it ten or a hundred times the hardware resources you'd use for a compiled C program doing the same job. Hardware's cheap, so this strategy can be supportable.

On the desktop, however, it's nearly impossible to find six real-world Java applications (real-world means not academic software, but actual applications that perform functions having commercial value) that can run simultaneously with anything approaching acceptable performance. Usually such apps will require different, mutually incompatible versions of Java at any given time, which doesn't help this situation.

I don't think this necessarily means Java is a bad language (although it seems that most implementations of Java are bad enough that they need to be patched constantly). It may be that it's just Java programmers that suck - certainly the majority of Java programmers are incapable of accepting any criticism of their chosen faith, and will froth at the mouth when they read this post. Intransigent refusal to accept reality does not a good programmer make; you can't improve something until you recognize that it is imperfect, and Java programmers generally talk about their programming language as if it were divinely inspired and ordained.

âoeA simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work next. If you find something that is complex replace it with something simple. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it.â â" from http://www.extremeprogramming.org/rules/simple.html [extremeprogramming.org]

Compare any Java-based solution with another piece of software, written in C at roughly the same time, that solves the same problems. The Java solution is invariably slower, requires more resources, and has more extremely odd and difficult-to-isolate bugs. Anything written in Java can be rewritten in C to create a faster, more robust, more sustainable piece of software. Of course, this can also be said of C++, and as previously noted, this may simply be because C programmers are better coders than Java programmers. I dunno. Perl and Python do not have this problem, or at least not to the degree that Java does.

Re:It's Java, so I'll skip it. (0)

Anonymous Coward | more than 3 years ago | (#37340802)

Jira IS a server application...

Perhaps this book is for you...

why not Practical JIRA Administration? (1)

OrangeTide (124937) | more than 3 years ago | (#37340234)

I like the book Practical JIRA Administration by Matt Doar

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?