I’ve been off the wire for quite some time.
A demanding year at work, a new life enriching our family and a busy life in general all meant that I arrived at home just with enough strength to help my daughter with her homework, eat and go to bed.
If you’re thinking that since you’re reading this article the situation is different now, I’ll have to disappoint you. However, I chose to make an extra effort, to keep learning as that’s the only way to move forward.
To help myself in this journey I decided to implement a new product. Its concept is very simple but I wanted it to touch most of the technology aspects that I want to stay current with. My goal is to learn new technologies and techniques, re-learn and validate rusty ones and prepare material for a new development training course. Additionally I’d like to offer this product to the public as a SaaS (Software As A Service).
The product will have the following characteristics:
- Use an API-led and Microservices based architecture
- Use Docker and Kubernetes as container technology
- Be Cloud native, deployed as a SaaS
- Use Bootstrap 4 for the front-end
- Use some database in the cloud (I haven’t decided yet if NoSQL or relational)
When thinking which activity to tackle first, I found myself going backwards and forwards between API, front-end, Cloud setup, requirements, Continuous Delivery and so on.
I started tackling the API but after upgrading all my API tech stack to the latest versions, I thought of it again and decided that maybe I should have wire-framed the solution to help with the journeys.
Ultimately though I decided that my first activity would be to define the user journeys that this product will address. As for the technique, I decided to use the User Story Mapping technique introduced by Jeff Patton is his book:
In one of my Twitter conversations with Jeff I asked if he could recommend any tools to work with User Story Mapping and his reply was:
The full Tweet can be found here: Tweet with Jeff Patton
So I decided to try Cardboardit. One of the primary reasons was that it was free for public boards and there’s nothing better than free when you’re learning.
So I created an account and created a board for my product, which I’ll call Pulse. Here’s a screenshot:
You can view the board online here.
So, why requirements first? I think they have several advantages:
- They provide the foundations to build a shared understanding between all stakeholders involved in Product delivery
- If written properly, they are independent from the technology solution. They should survive evolving technologies
- They can be understood easily by people new to the team, thus making new members on boarding easier
- They are the foundations onto which build Behaviour Driven Development (BDD) automated acceptance criteria. We indeed should write journeys like the ones above as the result of conversations we have with interested stakeholders. They should emerge by asking the right questions, typically “What if…”.
- They are long term. With this I don’t want to say requirements don’t change, as they inevitably do. What I mean is that I might go back to them some time later and remember with ease what I wanted to build.
I’ll stop here for now. The next step for me will be to implement the simplest end-to-end journey, so I can prove the infrastructure and technology to lay the foundations for my Continuous Delivery Pipeline.