Part 2 - First Project using Agile - Using Github Issues with Agile
April 22, 2013
One of those lessons I learned from my teams Agile development process is that I don't think we need Trello. I think we can accomplish everything with Github Issues and labels. SIMPLIFY. EVERYTHING IN ONE PLACE.
In Part 1 of the Agile Development process I referred to using Github Issues to track our web application issues. I also talk about using Trello as the story board, along with learning a few lessons along the way. One of those lessons is that I don’t think we need Trello. I think we can accomplish everything with Github Issues and labels. Github’s great post on issues pushed me in this direction.
Here is what I have proposed to my team:
Change Management (CM) Process
- Create cards for tasks, the backlog, on post-it notes.
- Create issues in Github for the backlog, no labels.
- Decide what is in a sprint.
- Label current issues as “current sprint”.
- When complete the developer closes the issue by using the commit message method and labels it “done”.
- We have to go to Github to add the label.
- The issue would now have 2 labels, “current sprint” and “done”.
- At the end of the sprint we add a tag to the repo updating the last number in of the version. This gets pushed to Dev for testing.
- During testing
- This is all issues labeled as “current sprint” and “done”; they will also be closed.
- If a bug is found the ticket is reopened and labeled as “bug” and the “current sprint” label removed.
- This makes the bug available to be worked on in a later sprint (re-prioritize).
- If a major bug is found the ticket is reopened and labeled as “major bug” leaving the “current sprint” label.
- A major bug would be one that can NOT go to production.
- This automatically applies the bug to the current sprint.
- This could cause an out of cycle push.
- If everything is fine, the issue remains closed and a “ready” label is added (it’s ready for production).
- If an enhancement is being suggested a new issue should be created and added to the backlog, no labels.
- Enhancements should not be a bug fix, they are recommendations to improve the application.
- Not all recommendations will be built. If we decide not build the issue can be closed and labeled as “rejected”.
- Push to production
- Based on the testing, it is possible that we will push known bugs to production but we will not push a major bug.
- The code that will be sent for ops for production will be that latest tag.
The goal is to simplify the process by having everything in one place; all tasks, issues, the code. But again, our process is evolving … hopefully for the better.
Part 1 of the Agile Development process - The Evolving Process
Part 3 of the Agile Development process - Milestones