JIRA Operational Planning Guide by wuyunyi

VIEWS: 4 PAGES: 7

									                          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

								
To top