Minesweeper: Initial sparring

Before starting this project i had a quick sparring session with one of my best friends. He’s an incredible smart guy and i love just talking about random technical problems with him because he always has some insights for me that i hadn’t considered yet.
Continue reading

Minesweeper: Motivation

My main goal for this project is not getting a finished product running on a server somewhere. The project will functional as a playground for me to experiment, in a safe environment, with new (to me) technologies, methodologies and ways of working.

Continue reading

Minesweeper: Initial attempt

Previously I was taking a very OO approach to the idea. Making each cell an object with its x and y position, the number in the cell, wether it was a bomb or not and if there was a flag on the cell. Note that at the time it was designed as a single player version so just a boolean value for the flag state was sufficient.
Continue reading

Minesweeper: Origins

A couple of years ago some person made an online minesweeper game where you could compete against random people from the internet. You could score points by correctly putting a flag on a bomb or opening non-bomb squares. Clicking on a bomb or misplacing a flag wouldn’t kill you. Instead you would lose some of your points. There was no win or loss condition. Just the infinite span of the field and a visible high score table to give a sense of competition.
Continue reading

My ideal way of working

Analysis Planning

Product owner/manager talk to the customer to understand the scope of the feature request
Define userstories and verify scope of each story with the customer
Plan analysis tickets on the development board of the next sprint for each of the stories
The description of the ticket should describe the entire scope of the story. Give as much info here as possible to reduce confusion later on
Order of the tickets on the board define priority. Higher on the todo-queue means higher prio.
Continue reading

Limit your WIP

We want to deliver value to the customer as fast as possible.
We can increase the delivery speed by focusing the team’s effort on getting single tasks from To Do to Done as fast as possible. In general we prefer finishing an already started task before picking up a new one. A ticket that is 80% finished has 0% value for the customer but costed 80% of the time. Having many of these half finished tickets on the board can quickly add up in cost.
Enter WIP limits.
Continue reading

Pull, don't push

Currently

This is the current life cycle of a ticket on the Jira board.

In Progress

When the developer is looking for something to do they open the Jira board and look at the To Do column. Because the sprint planners did their job properly they can simply take the ticket at the top of the column and know that the priorities are right.
So they pull the ticket from To Do into In Progress.
Continue reading