Przejdź do głównej zawartości

Agile in metaphores: cars cleaning

Last Saturday I decided to clean our cars, both mine and my wife's. They really needed cleaning. A few days before I bought a nice, industry-grade vacuum cleaner, better suited for this job than the one we use at home. Basic set of tasks that I have to work through to clean a car is this:

  • vacuum the car
  • take out foot pads and clean them with water and a detergent
  • clean the inner sides of windows
  • clean the cockpit with a special detergent so that it looks glossy
The weather on that day was not bad, though pretty windy and when I was about half way through the job, it looked like it was going to rain.

What is the best way to complete as much cleaning as possible, if there is the risk of rain? Should I vacuum both cars first, because I already have the vacuum cleaner running? But would anybody consider a car that has been vacuumed, but still has lots of dust on the cockpit clean? I wouldn't and, what's more, my wife certainly wouldn't either. What is the best way then, again, to achieve the most value during the job of cleaning the cars when it might start raining any minute? Clean the cars one by one, complete all the tasks for one of them and then start another. Then, even if it starts raining when I work on the second car, I will have at least one car completely clean. Even more value could be achieved, if I chose the right car as first to be cleaned and I think you already know which I would choose to gain the most value...

The same thing is with implementing Agile and working within Scrum framework. This actually also shows that Scrum and Kanban are not that far from each other as we sometimes think. In an iteration, it is always best to keep WIP (Work In Progress) strictly limited. It does not make sense for 6 developers to start working on 6 user stories at the beginning of an iteration and finish their work at the end. Ideally, they would all work on one user story at a time, completing one after another. In practice, there will often be some overlap and the team will work on two, sometimes maybe three user stories concurrently, but they must not work on many at once and those that are in-progress at the same time should not be at the same stage (i.e. second user story will often be started when first is nearing completion).

This is what I often advise the teams I work with. Don't start all your user stories at once. Start one, maybe two or three at most. I prefer going to a sprint review at which I learn that 2 of 6 user stories have not been started, than to one where I learn that 3 of 6 user stories are half-done.


Popularne posty z tego bloga

Unit Testing code with IO file operations (in Python)

We may often come across a piece of code that was written without Unit Tests at all. In addition, the piece of code may be dealing with IO like file writing and reading, which makes it more difficult to Unit Test it when we are trying to refactor and modify. Let's suppose the code in question looks like this:

def writeInitialsToFile(filename, name, surname):
    initials = name[0] + '.' + surname[0] + '.'
    with open(filename, 'w') as file:

def readInitials(filename):
    initials = None
    with open(filename, 'r') as file:
        initials = file.readline()
    return initials

A straightforward and bad idea would be to write a couple of Unit Tests that make use of a real file and simply test the reading and writing. Is therea a better way to test this code?

First of all, we need a way to replace the real file with something else. For both reading and writing we will now have a couple of functions, one that expects a stream fo…

Piotr's Less Obvious Advice on Google Mock: State maintenance

Google Mock provides several ways to maintain state inside mock objects. One way of implementing state maintenance is with SaveArg. Consider the following example.

We have a class Configurator, which allows a caller to set and get values of a parameter:

class Configurator

    virtual ~Configurator() {}

    virtual void setParamX(int n) = 0;
    virtual int getParamX() = 0;

And we have a class Client that calls Configurator's methods and it also has a method incParamXBy, that can be used to increase the current value of paramX by a certain value.

class Client

    Client(Configurator & cfg);
    virtual ~Client() {}

    void setParamX(int n);
    void incParamXBy(int n);
    int getParamX();


    Configurator & _cfg;

incParamXBy internally calls setParamX and getParamX on Configurator:

void Client::incParamXBy(int n)
    _cfg.setParamX(_cfg.getParamX() + n);

Let's assume that the initial value of paramX is A and that we want to increase paramX by…

Piotr's Less Obvious Advice on Google Mock: Returning new objects from a mock

Google Mock provides a way to return newly created objects from a mock method. Suppose we have a  Generator class that is supposed to generate new objects when createNewRecord method is called:

class Generator
    virtual ~Generator() {}
    virtual Record * createNewRecord() = 0;

...and suppose we want to mock this class:

class MockGenerator : public Generator
    MOCK_METHOD0(createNewRecord, Record * ());

Suppose the caller class Client has run method defined as follows:

void Client::run()
    for(int i = 0; i < 3; i++)
        rec_tab[i] = gen.createNewRecord();

We want the mock to return a pointer to a new object each time createNewRecord is called. This is how we can express this in the test code:

TEST(ClientTest, CanRun)
    MockGenerator gen;
    Client c(gen);

    EXPECT_CALL(gen, createNewRecord())
                 //this is equivalent of returning new Record(1,2,3)