A Glass case of Thoughts

Purpose:

1. Utility to report issues/ tasks
2. Convey status of each task on list unambiguously

Contribution to planning:

1. Plan releases
2. Manage product versions

Configuration:

1. Projects: Projects should be clearly defined in the system to avoid any confusions regarding the context of the reported issue/ given task
2. Versions: At least three versions should always be considered in roadmap
3. Status: Enough status codes should be defined to convey the actions being taken without having to spend time on co-ordination for this task.

Status transition process:
A process that has always worked for me in all the projects till date

Reported

Issue has been reported, waiting to be assigned

Assigned

Issue has been assigned to a team member

Accepted

Issue has been reproduced by the assignee and has accepted to resolve it. At this point of time, the developer should specify the due date for delivery of fix.

NotAccepted

Issue could not be reproduced by the assignee and requires more information. Issue notes should specify the data required

Testing

Issue has been fixed and is being unit tested by developer

Requires Testing

Developer has completely tested the issue and requires a tester to test it

Resolved

Tester has tested the issue successfully. If tester does not approve it to be tested, the status should be changed back to assigned with details in issue notes.

Closed

The issue has been successfully tested in both test as well as deployed version. The issue is determined to be eliminated. There should be only one person who should be responsible for closing issues – preferrable a tester appointed by client.

Re-opened

An old closed issue has been detected in later version and has been reopened waiting to be assigned.

Tools used:
JIRA
FLYSPRAY

JIRA Analogy
Help: Ernie’s inputs

JIRA gives us capability to create multiple projects hence helping us to draw boundaries for tasks. Apart from that it also allows us to create Components for a project – another level of abstraction – could be towards modules in a project.

By default JIRA provides following status codes

• Open
• In progress
• Cannot reproduce
• Won’t fix
• Resolved
• Closed
• Re-opened

Process mapping:
We have two options to map our process to JIRA

1. Create a completely customized list of status codes for our process – simple and best
2. Map the default status codes of JIRA to process status codes

Reported		JIRA allows to create a task and not assign it to anyone. That option was turned off, but it is now enabled. So, a task which has been created and not assigned would fit this
Assigned		In JIRA, this is a task which is “open” and assigned to someone
Accepted		In JIRA, this would be a task that is “in progress” (click “start progress” under “available workflow actions”).
Not Accepted		When an issue is marked as “resolved” in JIRA, the person who is resolving it has to specify what the resolution is. Some of the choices here include “Won’t fix” and “Cannot reproduce”. That seems to cover “not accepted” pretty well.
Testing, Requires testing, Resolved		In JIRA terminology, marking an issue “Resolved” generally means that the coding is done and the developer is satisfied with it – at which point it would move on for testing. We could also add a status “testing” to the default statuses to accomplish the requirement.
Closed		As is in JIRA
Re-opened		As is in JIRA