Customizing JIRA workflow

Like other cool companies we also use JIRA for issue tracking; and we are agile using it. JIRA has posted a very useful article on how  to go agile using JIRA [http://confluence.atlassian.com/display/CONFEVAL/Using+JIRA+for+Agile+Development].

Since JIRA gives you an option to customize the workflow. We've added some more details extending the normal 4 step JIRA workflow to a 6-7 step workflow.

The steps are closely related to what we follow in a normal development cycle, something that is not only natural to a developer, but also helps managers track them. A look at the major steps involved;


  • Open Issue: Issue created by the lead and assigned to a responsible developer.
  • In Progress: Once the developer starts working on it, they mark is as "In Progress", to let others know he's working on it.
  • More Info needed: Along the way is any information is needed from the business analyst or the decision maker, reassign the issue to them and mark it as "More Info Needed" who when provides more info, assigns back to you. Why the run around; well helps you document for future reference. Back "In Progress" the developer continues with the quest to complete it.
  • Development Complete: When finished coding, update the status as "Development Complete". The module is code complete but not unit tested for yet!
  • Unit Tested: Supporting unit test was written and integrated with the Ant/Maven build to run in Hudson/Cruise Control/Bamboo
    • There are also cases, when there are no unit tests needed or possible for the code, the developer can mark  "No Unit Test" in that case.
  • QA Approved: This is where we get a bit waterfally, but only cos we think unit test may not always provide complete testing justice of your application. Here the QA is responsible for ensuring the business requirements are met as specked out.
  • Resolve Issue: Good to go, go to staging, pass some robust abuse, and if all goes well resolve the issue.
  • Close Issue: The build has been released and we are generating release notes of what made it and what was missed. Close the issue and let it rest. If there are any repercussions reopen the ticket. 
*There is some debate about the Unit Test being written first and then the code; so you know what to expect; but in this case, it's a state for the developer and the manager for better understanding.
On how to create a custom workflow, please refer the JIRA documentation

Comments

Post a Comment

Popular posts from this blog

Install motion eye on Raspberry Pi for surveillance.

Image
Decided to go on a month long vacation leaving the home all by itself. This was the perfect opportunity to put a home surveillance system in place. There was nothing I could do remotely if anything happened, but would not want to let go the jackasses who broke in! Hardware in use Raspberry Pi 2 (will work with 3 too!) Logitech 720p old web cam Sony PS3 Eye 480p web cam 64GB SD card for OS and data capture.  I tore the "Easy carry Ziplock" box on the sides for the cables to pass thru. It was placed near the window, and I did not want to leave the pi running naked, since I did not have a proper enclosure, put it in this box. Placed two cameras around the room, one on the lamp, which would monitor 4 entry/exit points in the house, and the other one near the porch to monitor if anyone was approaching the front door.  Steps to install MotionEye 
Read more

2 DTO or not 2 DTO

Since the new project began I've been think about this over and over again reading as many posts and taking ideas from different posts and blogs. The more I read, the less I knew. Below is a collection of few links I've come across which have some conclusive and non-conclusive decisions/arguments, some of these post lean towards POJO's and some towards DTO(Data Transfer Object). Frankly I was not been able to convince myself on what to use. (Leaning more towards POJO's as detached objects).
Read more