Przejdź do głównej zawartości

Practical Scrum Training (7) Training Scenario

This is the final post in Practical Scrum Training. I will explain now how I imagine the training should be conducted. I imagine one day, with a lunch break, should be enough to cover what I list here below.

The training group should consist of a few (3-4) groups of individuals and there should be from 2 to maybe 4 people in each group. Each group should be seated in from of one computer.

The training begins with a description of the application and the participants should be able to run the included unit tests as well as the application itself.

Then, the trainer presents the initial product backlog.The trainer acts, to some extent, like a Product Owner. The product backlog refinement that we went through in previous posts is not meant to be performed upfront, but rather in several stages, on as-needed basis.

The goal for the teams is to build product increments in artificially short iterations - each 1 or 1.5 h long. The development team performs all regular Scrum events, like planning, review and retrospective, but because of the artificial shortening of sprints, they are not required to observe any proportion of length of these compared to the sprint itself. For the same reason, the development team does not have daily scrums.

Some of the product backlog items, like checking the validity of entered data, should be hardly possible to increment within an hour and therefore the teams will be forced to divide such product backlog items into a few smaller ones. The teams will be reminded very strongly that they must finish the product backlog items they accepted into a sprint. Leaving an item unfinished at the end of the sprint will be treated as a failure - retrospective should be used to come up with ideas how not to let it happen in next sprint.

Training attendies may choose any approach to work efficiently using one computer per each team of 2 - 4 people. They should, however, be strongly encouraged to use TDD as they code (let's state it directly: they must use TDD). More ambitious teams may try to introduce unit tests into the module that converts internal representation of the tree into pydot objects (something I did not do in the baseline of the application). Apart from wearing the Product Owner's hat the trainer should also do some duties similar to those known from sessions like code retreat: walk from group to group, provide comments and advice regarding code quality. The trainer should be able to do this craftsmanship part of the duties for smaller groups  (less groups, less people in a group).

This outline of the training and the family tree example can be used by anyone who wishes to try it out with a development team. You can use all of this information, if you want to deliver this training yourself. As the author of the training, I am also willing to deliver it in person.


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)