Get documents about "JIRA Operational Planning Guide
Shared by: wuyunyi
-
Stats
- views:
- 4
- posted:
- 8/4/2012
- language:
- English
- pages:
- 7
Document Sample
JIRA Learning Phase- Approach and Guidelines
Purpose
The purpose of the JIRA Learning Phase is to provide a subset of the CBIIT JIRA user community with a pre-
configured instance of JIRA so that they can use JIRA on a daily basis and provide feedback to the JIRA SWAT
team about standard configuration settings, custom configuration requirements, workflow, security,
reporting, and other standard usage requirements..
Learning Teams
The Learning Teams were selected based on the types of JIRA users who work with CBIIT. A brief synopsis of
our selection rationale is laid out in the table below.
JIRA Users Representative? Example Team
Knowledge Center
CBIIT Development Focused Y CTRP
External Development Focused Y caTissue
Project Development Teams
CBIIT Core Development Teams Y SDK / ISO 21090 Integration
CBIIT Development Teams Y caIntegrator2
Non CBIIT Development Teams Y caTissue
Report Owners
Project Owners Y Ad hoc requirement capture
Enterprise Owners Y Ad hoc requirement capture
Community Members Y Ad hoc requirement capture
The JIRA Learning Team consists of the following teams and representatives
JIRA Learning Team Team Point of Contact
CTRP Steve Lustbader
caTissue Sudha ChudhamaniDave Mulvihill
caIntegrator2 Shine Jacobs
SDK / ISO 21090 Integration Sichen Liu
Learning Phase Timeline and Plan
The Learning Phase timeline will be time-boxed to one month. Each week, the Team Points of Contact will meet
with the JIRA SWAT team to discuss issues, requirements, and lessons learned. Throughout the Learning
Phase, these issues will be documented and aggregated. At the conclusion of the Learning Phase, a JIRA
conclusion document will be presented to the Learning Teams to ensure that the JIRA implementation takes into
account the feedback from the Learning Phase.
Confidential Page 1 of 7 8/4/20124/14/20104/7/2010
JIRA Configuration Approach
JIRA Configurations
For this JIRA Learning Phase, several predefined features are described in the table below.
FIELDS FIELD VALUES
User Types System Administrator – Global Power, including
Add Projects
Approve Add User Requests
Modify environment or network configurations
Configure email notifications and notification events
Project Administrator – Power to modify project parameters once a project
is created, including
Edit project users and project user types
Edit project components (lists of values for project specific fields like
version)
Project Owners – Able to create, modify, and assign issues
Project owners are default assigned all new issues
Project Members – Able to create, modify, and assign issues
Users – Able to create and modify issues
Issue Types Bug – Problem where existing functionality is not working as intended, or
required functionality is not available
Feature Request – Requirement, enhancement, or feature request
Story – Task to be performed for the project. No workflow.
Task – Catch all for any other issue type. No workflow. Formatted: Font: Bold
Priority Severe – User cannot do work
High – Issue has a major impact on functionality
Medium – Issue has a moderate impact on functionality
Minor – Issue has a minor impact on functionality
Trivial – Issue has a cosmetic impact on functionality
Status Open – Default status for any issue
In Progress – Issue is being worked
Resolved – Issues has been resolved, but not tested
Closed – Issue resolution has been tested and confirmed
On Hold – Issue is not being worked at this time
Reopened – Issue has moved from either Resolved or Closed
QA Verified – Issue has been resolved, and the resolution has been
independently verified Formatted: Font: Not Bold, Not Italic
NOTE: State allows users to describe additional information about the issue without describing its
status within the workflow
Resolution Blank – Default value Formatted: Font: Not Bold
Fixed
Duplicate
Cannot Reproduce
Won’t Fix – Wont’ fix implies that this issue will not be fixed at all. If an issue
will be fixed, but not in this release, it should remain Open.
Communications Planning Guide Page 2 of 7 8/4/20124/14/20104/7/2010
Supported Issue Workflow for Bugs, Feature Requests, and Enhancement
Requests
1
Start Open
2
7
In Progress
12
3
10
QA Verified
8
On Hold
11 Resolved 4
13
9
5
Closed
Reopened
6
Step Description
1 User creates Issue within a project context
Depending on Project configuration, Issue is either
o (Default Assigned) - automatically assigned to Project Owner
o (Default Unassigned) - sent to a pool of Open issues that are unassigned
Issue status is automatically moved to “Open”
Depending on Project configuration, email is either sent to
o (Default Assigned) - Project Owner or Project Owner mask
o (Default Unassigned) - Entire team
2 Depending on how the Project is configured
o (Default Assigned) - Project Owner reviews and assigns the issue, validating issue priority
and other fields
o (Default Unassigned) - Assignee takes issue from pool, reviews priority and other fields, and
begins work
Issue status is automatically moved to “Assigned”
Communications Planning Guide Page 3 of 7 8/4/20124/14/20104/7/2010
Step Description
Email notification is sent to the Assignee
3 Assignee resolves the issue, either by setting the resolution to Fixed, Duplicate, Cannot
Reproduce, or Won’t Fix
Assignee moves status to “Resolved” .
Email notification is sent to the Project Owner and the Issue Originator
If there is a testing team, Assignee reassigns issue to a tester Formatted: Bullets and Numbering
If there is not a testing team, move to step 4.
Note: Code changes made as s result of this issue will be traceable in the SVN code repository using Fisheye
4 Assignee validates the resolution and sets the status to “Closed”
Email notification is sent to the Project Owner and the Issue Originator
5 Assignee validates the resolution and determines that the issue is NOT fixed
Assignee sets the status to “Reopened”
Depending on project configuration (Default Assigned)
o Assignee reassigns issue to the person who resolved the issue
o Email notification is sent to the Project Owner, the Assigned party, and the Issue Originator Formatted: Bullets and Numbering
oAssignee unassigns issue, and issue is moved to issue pool
Depending on project configuration (Default Unassigned)
o Assignee unassigns issue, and issue is moved to issue pool Formatted: Bullets and Numbering
oEmail notification is sent to the Project Owner, the Assigned party, and the Issue Originator
o Email notification is sent to the Project Team and the Issue Originator
6 Issue Originator or Team Member determines that the issue is NOT fixed
User sets the status to “Reopened”
Depending on project configuration (Default Assigned) Formatted: Bullets and Numbering
o Assignee reassigns issue to the person who resolved the issue
o Email notification is sent to the Project Owner, the Assigned party, and the Issue Originator
Depending on project configuration (Default Unassigned)
o Assignee unassigns issue, and issue is moved to issue pool
Email notification is sent to the Project Team and the Issue OriginatorIssue is automatically
assigned to Project Owner
Email notification is sent to the Project Owner and the Issue Originator
7 Project Owner reviews and determines the issue should not be worked at this time
Project Owner sets status to “On Hold”
Issue is “unassiged”
Email notification is sent to the Project Owner and the Issue Originator
8 Assignee and Project Owner determine the issue should not be worked at this time
Assignee sets status to “On Hold”
Issue is automatically assigned to Project Owner
Email notification is sent to the Project Owner and the Issue Originator
9 Assignee and Project Owner determine the issue should not be worked at this time
Assignee sets status to “On Hold”
Issue is automatically assigned to Project Owner
Email notification is sent to the Project Owner and the Issue Originator
10 Project Owner or Team Member determine the issue should be worked again
Project Owner reviews and assigns the issue, validating issue priority and other fields
Issue status is automatically moved to “Assigned”
Email notification is sent to the Assignee
11 Depending on how the Project is configured
o (Default Assigned) - Project Owner reviews and assigns the issue, validating issue priority
and other fields
o (Default Unassigned) - Assignee takes issue from pool, reviews priority and other fields, and
begins work
Issue status is automatically moved to “Assigned”
Email notification is sent to the Assignee
Communications Planning Guide Page 4 of 7 8/4/20124/14/20104/7/2010
Step Description
12 QA Team members reviews assignment. Note: QA Team is not a JIRA concept. This is relevant
only within the project itself. and sets status to QA Verified
Email notification is sent to Project Owner and Assignee
13 Project Owner validates the resolution and sets the status to “Closed”
Email notification is sent to the Project Owner and the Issue Originator
Supported Issue Screens
SCREENS DESCRIPTIONS
Create Issue User creates a new bug
Edit Issue User, Project Member, or Project Owner edits a bug
Create Issue Screen
FIELD FIELD CONFIGURATION REQURED?
ID R Y
Issue Type R/W Y
Status R Y
Priority R/W Y
Originator R Y
Title R/W Y
Description R/W Y
Component R/W. Default blank N
Version R/W. Default blank N
Attachment R/W N
Note – If you open an issue on behalf of someone else, there should be an SOP saying that the originator sends
an email with the bug link to the person who first found the issue.
Edit Issue Screen
FIELD FIELD CONFIGURATION REQURED?
ID R Y
Issue Type R/W for Project Members, Y
but not for users
State R/W Y
Priority R/W for Project Members, Y
but not for users
Originator R Y
Title R Y
Description R/W – Can’t delete what Y
has been written
Comment R/W N
Component R/W N
Version R/W N
Attachment R/W N
Resolution R/W Y
Fix Version R/W N
Global Configuration Settings
There are several default JIRA global configuration settings. Only critical settings, or changes to the default
parameters, have been noted here.
Communications Planning Guide Page 5 of 7 8/4/20124/14/20104/7/2010
Parameter Setting Justification
User creation of tickets The default permission scheme will be that users must log in to create a ticket.
However, any user can create tickets for any project. Users will be able to register for
accounts on the JIRA login screen.
Enable File Attachments Enabling file attachments allows users to attach screen prints to Issue logs. However,
attachments are NOT stored in the JIRA database, so enabling attachments requires
a separate backup and restore protocol than the generic DB backup conventions.
Enable Time Tracking Enabling time tracking allows Project Members to track the time they spend
responding to issues, and it allows Program owners to tack response times.
However, we do not currently have a protocol for this, and will need to require Project
Members to record this data accurately.
Enable Sub Tasking Allow sub tasks within issues and tasks
Communications Planning Guide Page 6 of 7 8/4/20124/14/20104/7/2010
Creating a New Project
Project Request Template
When a team wishes to create a new project, they can do so by filling out the following template of information,
in the form of a JIRA Issue Request to the JIRA CCB.
Project Name
Project Short Name – Prepend that will occur before each ticket
Project Icon – Small picture to represent the project
List of Users and User Roles
Configuration Selection – Default Assign or Default Unassign.
o In the “Default Assign” schema, all tickets will be default be assigned to the project lead for
assignment.
o In the “Default Unassigned” schema, all tickets will go into an unassigned pool where they can
be taken on a first come, first serve basis by project team members
For Default Unassigned schemes, a notification scheme will be created to notify the
entire project when a new ticket is created
For Default Unassigned schemes, a rule will be created notifying the project lead if a
ticket remains unassigned and Open for more than three days
Project URL – URL for other project locations, wikis, etc
Project Lead Preferences – One person, or a mask email going to several people
Project Lead Requirements once a Project is Created
Once a project is created, the project lead must do 2 things:
Review the configuration and validate that there are no specific changes required
Create project specific components and versions for the issue list of values
Project Configuration Changes and JIRA Change Control Board
If a project team determines that there are configuration changes they would like to make for their project, they
can log a JIRA ticket under the JIRA CCB project, requesting these changes.
The JIRA CCB is a group of JIRA administrators and the JIRA project lead who are responsible for reviewing
and mediating these requests. Initially, the CCB will meet weekly, and as necessary going forward.
Communications Planning Guide Page 7 of 7 8/4/20124/14/20104/7/2010
