GOJIRA

Paul René Jørgensen / Adresseavisen AS

[paul.rene.jorgensen@adresseavisen.no]

Version: 20100211
Agenda
Introduction
What is JIRA?
JIRA Concepts
What's an issue?
Features
Issue Creation
Versions
Components
Reporting
Roadmaps
Notifications
Search
Schemes
Best Practices
Generic
Administration
Project Setup
Users, Groups & Roles
What is JIRA?

JIRA is a web tool

Use it to prioritize, assign, track, discuss, report and
watch issues / tasks
Very configurable and extendable
You can adapt it to your business processes
It maintains your historic data
Many uses..

Bugs / Change request tracking

Help-desk / Support / Customer Service
Project Management
Task Tracking
Requirements Management
Workflow / Process Managment
Jira Concepts - projects, issues and sub-tasks
What's an issue?
Everything is customizable, but make it an exception
rather than the rule to make changes from the default
Built in issue types bring you a long way
Bug
New Feature
Improvement
Task
Summary - An informative title will make your life
easier
Don't prioritize everything as a blocker
Blocker, Critical, Major, Minor, Trivial
Assignee
The person responsible for progress
Reporter
The person responsible for follow up
Status

Resolution
Fixed, Won't fix, Duplicate, Incomplete, Cannot reproduce
Description
Put all the meat here
Comments
Crucible for communication and documentation
Workflow

You may customize the workflow to meet the business needs

Example: Software development project
Example: Help Desk
Issue Creation

Creating a task, support ticket, bug report, feature requst is

very straight forward
You may customize all the fields and types in an issue
Issues may be created in two different ways
Web: Using a form on the web
Email: Sending an email to a POP-enabled email
account
Versions and Releases

Affects Version
This is the version that this issue is prevalent
Fix Version
This is the version where the issue is resolved
Versions may be software releases, but can also be thought
of as deadlines, sprints or ie. meetings
A version should be released when a deadline occurs.
Issues without resolution could either be put back in the
long tail or be moved into a future version
Components

Use components to group issues together

A component may have a user that is auto assigned issues
when they are created
Greatly improve the usefulness of reports
Reporting
Roadmaps
Easy view of the progress of a version / milestone
Notifications

Email notification when an email make a transition from one

status to the next
Eg. Open -> In Progress
Notifications are fulle configurable
Subscribe to periodical reports on issue status
Search
Search in all fields, even in custom defined ones
Searches can be saved, shared and used as filters
Schemes

By using user roles schemes can easily be shared between

projects
Schemes
Notification Scheme
Controls who is notified when
Permission Scheme
Controls who is allowed to do what
Other noteworthy features

Fine grained security system, even on the issue level

Supports work and time tracking
Highly extensible with open API's and a ton of third party
plugins
Source Code is available to commercial customers
BEST
PRACTICES
Best Practices

Avoid complex configurations

Use naming conventions
Don't make everyone administrators!
Use roles to delegate administration
Use Roles
Minimizes the number of schemes necessary
Use the default workflow if possible
Use a staging server to test new configurations
Document everything (Use Confluence)
If you use custom fields
Limit the context and reuse
Who is responsible for what
Who Sys Admins JIRA Admins
Why Knows the system better Knows the business better
What Manage system fields Manage workflows
(priorites, issue types, Manage components /
resolutions, status) versions
Create projects Manage custom field values
Manage users/groups Bulk operations
Define standards Create shared filters,
Approve plugins dashboards, group filter
Manage security subscriptions
Maintain permissions
Maintain notifications

How Communicate well Train them well

Project Setup Best Practices (1)

Custom Fields
Limit Context by Project / Issue Type
Reuse fields (use project contexts)
Don't put every custom field in a global context
It clutters the issue navigator
Understand the resolutions field
When an issue has a resolution field set, JIRA considers
it closed. Affects filters and reports.
Set resolution field ONLY when issue is considered
closed
Project Setup Best Practices (2)

Determine Project Structure

Many small projects (ie. one per product)
You can denote the product information on an issue in these
various ways
Project name itself (J)
Components field (J)
Version field (J)
Custom fields (S)
Cascading select field (S)

Handled by: (J) - JIRA Admins, (S) - SysAdmin

Users, Groups & Roles Best Practices

Users sign up be themselvs

Joins the jira-users group
Use groups to mimic the organization
Use roles to give individual users and/or groups permissions
using permission schemes
Never give a whole group permissions in a scheme, use
roles instead. Only exception: jira-users group
Q&A - don't let anything stop you

http://www.atlassian.com/software/jira/docs