Few months ago in the office we started a discussion about testing.
The original topic was “how to implement a continuous integration/continuous delivery workflow”, so “how to test” became immediately a requirement and a parallel important topic.
My suggestion was to start coding in TDD of course, but like every office we had a lot of legacy code to deal with.
In order not to be stuck by that, we decided temporarily to focus on new (or almost new) projects and apply it to them.
So the point became to find a way to have all the developers, regardless on the seniority and the project, on the same page about the topic.
After the first implementation of the game, my friend and I compared our versions.
He focused on the deck model instead of the dealer like I did.
This simple choice drove his design to a complete different path.
He put a lot of effort trying to replicate a realistic deck, implementing the shuffle logic and making impossible to draw the same card twice.
This hypotheses never came up to my mind because I knew that in the real game there are multiple decks in order to make almost impossible for the players the calculation of the drawn cards.
Speaking to a friend a couple of weeks ago, he told me about an interview he did where one of the challenges was to create the blackjack game.
The algorithm itself is not too complicated, but it’s a good test to practice TDD and having never tried it in AngularJs I decided to give it a shot.
When I developed the pivotaltracker plugin to extract our backlogs (here the post), instead of create a mock application to use it, I gave the library to my colleague so he could integrate it in the real application that my frontend application would have used to retrieve all the backlogs.
Everything went well until the application tried to parse the stories in the final contract, then the application crashed miserably.
I and my colleague worked side by side:
The first thing I did was to run my test: all passed.
So I checked the response of the pivotaltracker API, maybe they had changed something: nope, the response of the API was exactly what I expected to receive.
So what happened?
Why my test didn’t represent correctly the real situation?
In our weekly meeting with the boss, I showed my roadmap-preview to have feedback and improve it (here the first part and here the second part of the creation of the roadmap-preview).
The roadmap-preview had to be used in two different places: in a dashboard as part of a summary of a project and in a Roadmap page where was needed to show more detailes.
My roadmap-preview had been considered good-looking, but lacking of information.
It wasn’t clear the content and the month of a release: in the dashboard had to be possible to read the key features of a release clicking on the flag, but in the Roadmap page was considered more useful to view them immediatly.
I decided not to create two different roadmap-preview directives; I prefered to have something like:
There we are.
The goal with this plugin was to give an easy way to get from a project the stories of the current iteration.
I usually prefer to work time boxed when I play on an exploration task, so I decided to give five hours to this task and then evaluate the results and possible efforts/costs to obtain an usable version of the plugin.
My team uses Pivotatracker so I already had the credentials to use the API, but before to write any code, I started reading a few of documentation and making some test using my REST Client.
After one hour I was sure to have enough information to start.
Well, the idea was to have a website where to show, for every project, backlog and other informations more related at the Company and its workflow.
We decided to split the work, so I was in charge to develop the website and to give a help to develop the plugins able to get stories from pivotaltracker and easybacklog and able to map them in a common DTO.
The others two team members started to analize a repository and a backoffice to put other relevant information apart the backlogs.
Long story short : it is three years I am working in an agile team (two years as Scrum Master) . Initially, the team was supposed to be a pilot for the company and because of some results we brought, it was decided to migrate other teams in an agile approach .
In the spirit of the methodology, each team have had the possibility to self-organizing; after that, they chose which tools ( electronic or not) they could use to optimize their work.