If you are reading this post, you are probably looking for a comprehensive and easy to follow workflow.
So, I decided to share the workflow that I use for my side-projects and for this blog! It helps me stay focused, continue being productive, and track my progress.
It is a variation of the popular Kanban workflow, an Agile and Lean workflow which many teams and individuals use successfully.
If you are so inclined, you can also read more about Open Kanban, an open-source flavor of the Kanban methodology.
If you just want the summary, take a quick peak through the slides.
Tools of the Trade
The tools we’ll be using are:
- Trello to add new stories or bugs and manage our project
- Git to version our code
- Github to save our project
I am intentionally skipping any mention of deployment tools. There are many great options and of course they all depend on your stack. Feel free to check out Codeship’s ebook — It’s a great read.
Here are the lists I like to use for my Trello boards:
In Code Review
Feel free to copy this sample board.
Let’s dive into the details of the workflow and how to use each list.
When you decide to add new features or improved existing ones, you’ll be creating new cards and adding them to the
Backlog is also the right place to add bugs that you discover or your customers report.
It usually helps to generally arrange the
Backlog cards by order of importance. This way you will have at least a rough idea of what you want to start working next.
Once a day, sift through the
Backlog and pick the stories you want to work on next and add them to
2. Next Up
Next Up contains all the stories that you want to implement next. You want to have about 2-3 (but not more than 5) stories per team member in this list.
This is separate from the
Backlog because you want to be able to quickly glance on what should be developed.
It will help you avoid decision paralysis and quickly start working on the next thing that needs to be developed.
You should move stories from the
Next Up once a day or once every few days to keep your queue full and not waste time deciding what to work on next.
3. In Development
So far in the workflow we mostly used Trello. Now it’s time to start working on our codebase:
- Move a card from
- Create a new branch on your repo with the name of the story
git checkout -b <branch-name>
- Work on the story
- If you have a test suite, run your tests
- When you are done with your story move it to
Code Reviewand issue a
pull requeston Github
- Inform your team
- Pick up the next story from
Next Upand repeat
Make sure you merge
master whenever an other branch gets merged into
$ git checkout master $ git pull $ git checkout <your-branch> $ git merge master
If you have merge conflicts:
// Open the files with conflicts // Coordinate with your team members to resolve the conflicts $ git add . $ git commit
4. In Code Review
If you are skeptical about the
Code Reviewprocess, watch this talk from RailsConf. I am a big supporter of code reviewing because: 1) it is a great way to learn from others, 2) it helps your team be more aware of your codebase, and of course 3) it results in an overall healthier codebase.
If you are working with a team have one of your team members review the open pull request on Github.
If you are flying solo, do the CR yourself but be very religious about the process. Try to look at your code as if someone else has written it.
Once that’s done, merge your pull request into
master. If you keep your branch fresh with the latest
master you shouldn’t have any merge conflicts. But even if you do, just go ahead and resolve them.
Finally, delete the branch and move the story’s card to
5. To Release
You made it so far! That’s awesome!
Now, it’s time to start the relase process and get your story out to the world.
Depending on the situation you may want to:
masteron a staging box and give it a spin
- Deploy to production
- Run your build suite and deploy to production
- Run your continuous delivery suite and deploy to production
- Wait for other complementary stories to release them all together
Congratulations! Time your give yourself a quick pat in the back.
But don’t celebrate for too long — another story awaits in
Next Up :-)
Not every story in the
Backlog will get released. Maybe you filed a duplicate story. Or maybe you decided not to implement a feature. The
Abandoned list is to collect all those dormant stories so you can keep them filed instead of just deleting them.
I’ve been using this workflow (or a similar one) in most of the teams I’ve worked on and it seems to be working pretty well for me.
Have you used it yourself? Do you have any feedback? Or maybe you have a better one to recommend?
Feel free to leave a comment.