How to process a ticket
Grab the ticket
In the ticketing system, add your name on the ticket if it was not assigned to you. Move the ticket to the Doing collection.
Read the ticket
Read the ticket and get a general understanding of what it is about.
After this initial reading, you should be able to answer these basic questions:
- Is the ticket for a feature, a bug fix or a refactoring?
- What are you supposed to do?
- Which app or apps in the project are impacted?
- What rough user workflow, if any, would reflect the successful implementation of this ticket?
- What are the standard cases in your testing plan?
Read the ticket (again)
Read the ticket a second time ot get a clear understanding of which aspects of the project are impacted: which apps, which components or modules?
By now you should have identified some edge cases for your testing plan.
Read the ticket again
In this 3rd reading, pay attention to the details of the requirements in the ticket.
Look for critical words that specify a key aspect of the ticket.
You don't want to find out after several weeks of work that you missed an important aspect, because of one word that you skipped.
Reformulate the ticket
At this point, you should be able to explain what the ticket expects you to do. What problem are you supposed to fix?
Reformulate the ticket in your own words. You should be able to explain this to your supervisor.
Create a feature branch
Find the appropriate name for the branch. If the project's practice is to name the branch after the ticket number, the do so. Otherwise, find a suitable short and appropriate name that reflects the purpose of the ticket.
Write your testing plan
Identify the standard cases — this is where everything works perfectly.
Also identify the edge cases — this is when things do not go according to plan, eg the user does not do what he is supposed to do; networks connection are down; servers are unavailable. In other words, ask yourself: What could go wrong?
Tip
Your testing plan is only as good as the edge cases you have identified.
Identify at least 2 implementation solutions
You should come up with a minimum of 2 implementation solutions. Your first solution could very well not be the best one, and it is worth spending some extra time looking for an alternative to challenge your own initial idea.
Write your implementation plan
At the very least, write a series of bullet points in the ticket.
If the ticket is complex and will require more than 1 day to complete, break it up into multiple child tickets. Each of these sub-tickets should include 1 daily deliverable.
Doing this will help you challenge your own thoughts. It will also provide useful documentation for others to either review your implementation solution, or execute it.
Implement your solution
Test locally
Read the ticket
Read the ticket again to verify that you haven't missed, or forgotten, any requirement (or added requirements that were not present).
Definition of Done
Check the project's Definition of Done. Do you meet all the criteria?
Create an MR
Tip
Check the coding standards. Lint your code.
Move the ticket to the MR collection.
Test on develop server
If your MR is accepted, after it is merged, test the ticket on the develop server.
Test on staging server
Once the code is deployed to the staging server, test again.
Mark the ticket as done
Move the ticket to the Done collection.
Clean up your code
Remove your feature branch (unless you want to keep working on it for the next ticket).