How We Use JIRA to Manage Our Mobile App Development Projects

By Bobby Gill on February 5, 2020

Despite its many warts, JIRA is a more than capable issue management tool ideal for managing software projects of various types and team sizes, including mobile app development. Part of JIRA’s power, and I would imagine the reason behind its insanely complex configuration UX, is that it is flexible enough to adapt to the nuances of each team which uses it and the project it is being used for. At Blue Label, our team has developed over 200 mobile apps and through all that I’m proud to say we do not subscribe to any particular development dogma or methodology. Instead, we’ve developed over the years a mobile app development process that is the son of a 1000 Agile fathers, one that borrows heavily from different frameworks and which we adapt based on the client and project we are working on. However, one thing that remains constant is how we use JIRA as the central point of management of our mobile app development process, from specification to sprint planning, from bug tracker to release management, JIRA is our main tool to coordinate our engineering efforts.

One of the first things any organization needs to choose when setting up JIRA for the first time is the “workflow” they would like to use for issues in JIRA. The “workflow” is essentially the set of statuses and transitions between those statuses that any issue in JIRA might travel from birth to completion. Issues can be anything from user stories such as “A logged in user should be able to reset their password using only their email address” to very specific bugs like “App crashes when user attempts to login with hyphenated email address”.

At Blue Label, our JIRA workflow is very complicated and has many different transitions which aren’t always used on each project. As we are software development agency, we have to adapt our use of JIRA to fit the client we are working with and something that is critically important for a Fortune 500 client might add little value to a small startup looking to get their MVP out the door. So much like a brown bear caught on a glacier, we adapt.

In the spirit of detente, here is a very brief look at our JIRA workflow and the relevant statuses and transitions that are common to all mobile app development projects we run:

A visual look at our complete JIRA workflow that we use.

 

  • Open
    • All issues are by default opened in this state and remain so until triaged by a PM.
  • Selected for Development
    • Issues are moved here when, as the name would imply, the Issue has been triaged and approved by the PM to go to development.
  • In Active Development
    • Need I say more?
  • Dev Smoke Testing
    • Issues are moved here by engineering only when the work itself is complete and unit and smoke tests run by the dev team pass.
  • Ready for Testing (QA Team)
    • Issues in this state are ready for formal verification by the QA team and for final resolution. Issues in the “Ready for QA” pile are deployed in the testing environment where QA is able to properly verify them and perform regression testing.
  • Verified (by Internal QA)
    • Issues move here after the QA signs off on them. However, they don’t immediately move to a Done state, instead they stay here until the PM verifies User Acceptance Testing (UAT) has passed and that the Issue is truly and completely resolved.
  • QA Fail
    • There are few things more frustrating to a PM then a developer saying they fixed a bug when they really didn’t. This status indicates that a Issue needs to return to engineering and also serves as a cathartic outlet for the frustrated sighs of many a PM.
  • Blocked
    • Issues land here when they cannot be worked on due to an external dependency.
  • Done
    • Finally, after an often long and tortuous journey, Issues arrive here to live in eternal rest once they have been fixed, tested and deployed.

While the above might sound a little complex and ambiguous, it reflects a process which has emerged in our organization over the more than 200 projects we’ve completed in the past decade. The important thing to take away is that no two mobile app development projects are the same, and as such, our JIRA workflow has to adapt to the particular nuances of a project and client while at the same time retaining a core set of central principles which can allow any member of our team to jump in and work on a project.

 

caopo超碰最新地址发布