Some stuff about Web and .NET development
RSS icon Email icon Home icon
  • Fibonacci numbers for agile estimates

    Posted on February 18th, 2011 Thibaut 142 comments
    Sprint Planning

    During the sprint planning, team members give estimates about the tasks they’re going work on in the coming sprint. Maybe some of you have already experienced that endless discussion about “is this a 10h or a 11h task ?”. This is where the planning poker, based on the Fibonacci numbers comes to the rescue.

    Fibonacci numbers are an integer sequence defined by the following recurrence relation :

    Fn = Fn-1 + Fn-2

    Which produces the following sequence :

    0, 1, 1, 2, 3, 5, 8, 13, …

    See the point ? Fibonacci numbers are particularly relevant for giving estimates. While one can easily estimate a 1h or 2h task, I don’t think a lot of people (if any) can tell for sure that a task will take 11h and not 12h. But with this technique, deciding between 8 and 13 is much easier. Some pokers also contain the 1/2 value, but the most useful addition is surely the “?” card, meaning that an accurate estimate isn’t possible because of the lack of visibility and more information should be given by the product owner.

    Planning poker

    When hesitating too much about two consecutive values, consider the time dedicated to testing (manual testing, unit tests, …) and don’t forget that velocity isn’t really compatible with quality ;)

    Share/Save/Bookmark

  • [FR] DotNetHub, le UserGroup .NET/Agile francophone

    Posted on January 17th, 2010 Thibaut No comments

    DotNetHub

    DotNetHub, le tout nouveau UserGroup francophone en Belgique, est le résultat du projet initié par 3 de mes collègues (Pierre-Emmanuel Dautreppe, Norman Deschauwer et Thierry Thoua) en association avec d’autres professionnels de l’informatique. Le but de ce dernier est double :

    • Pallier l’absence de UserGroups francophones en Belgique. Le premier UserGroup belge, VISUG, se rapprochant toujours plus de la partie nord du pays, l’initiative est plus que la bienvenue
    • Proposer en plus d’un pôle technologique (.NET) un pôle méthodologique consacré à l’agilité (Scrum, XP, …) par l’organisation de dojos, entre autres

    Pour la première session, DotNetHub aura le plaisir d’accueillir Peli De Halleux, un petit belge travaillant désormais pour Microsoft à Redmond. Il vous présentera Pex, Moles & Stubs, des outils de tests unitaires pour .NET.

    Pour plus d’infos sur la session, c’est par ici. Pour s’inscrire, cela se passe par là.

    Bonne session ;)

    Share/Save/Bookmark

  • CITCON 09 @ Paris : summary

    Posted on September 27th, 2009 Thibaut 1 comment
    CITCON Some days ago was held the 2009 edition of the CITCON (Continuous Integration & Testing Conference) at Paris. As my colleages and I are working on a project using the eXtreme Programming methodology, we are always eager to share our experience and learn from others. Below is given a summary of this edition.

     

    The principle of organization

    For those who never went there, here’s an introduction about the principle : the first day, from 6pm to 9pm, everybody introduces himself and then everyone who wants to be speaker has to “sell” his topic to the public. A post-it is for each topic put on a shedule board and people vote for the ones they like. The day after, only the topics with most votes remain (similar subjects are often merged) and then people can choose which session that want to attend. A session is about 1 hour long and is very interactive : everybody can talk and share his experience. In total, 5 sessions are organized : 2 in the morning and 3 in the afternoon.

    Introduction

    Session #1 : Testing & “done”

    The purpose of this session, animated by our architect Pierre-Emmanuel Dautreppe, is to discuss about what to test and how (database, UI, everything) and when you consider your testing done. Here are some key elements of the discussion :

    • Cannot test everything
    • Test to limit the risks of the application
    • Ask the customer how he expects his application to behave. Then, write user stories accordingly (test cases)

    Done ?

    • Tested every user story in the app (at least the main ones)
    • For some people, it’s only about code coverage (ex : 80%)
    • Having generated enough information reflecting the quality of the product (test results as a control panel)
    • Tested every part of the API
    • When confident on the product quality (= ready to be shipped)

    Session #2 : Mock objects

    When to mock ? (cf VISUG session about Mocking)

    • External object (web service, DB)
    • Non deterministic objects (temperature, …)
    • Hard to reproduce situations (network error, HDD out of space, …)
    • Slow down execution (simulate long calculations)
    • When some objects are not implemented

    Other advices :

    • Try to mock the minimum possible
    • Some mocking frameworks allow to mock without coding interfaces (less need to code the application following the testing framework behind it)

    Session #3

    Developers & business people collaboration

    • Too often, business people are too far away from the implementation
    • A close contact should be kept with the customer. In the context of acceptance testing, it’s useful to define user stories
    • Important to make the project beneficiate from the knowledge of business people

    Top 5 reasons why teams fail with acceptance testing

    • No collaboration
    • Focusing on how and not on what
    • Tests unusable as live documentation
    • Expecting tests to be a full regression suite
    • Focusing on tools

    Session #4 : putting Selenium in its place

    Selenium is a web application testing system that enables you to record operations (while you manipulate the browser) and generate code in multiple languages (C#, Java, Ruby, …). You can watch a quick demonstration on the official website.

    After this introduction, one of the big cons of this approach (and also code-based approaches) was underlined : when the front-end changes, a lot of acceptance tests fail. Indeed, suppose that you have many tests for a single page (to cover different scenarios for example), if you change one thing, everything might fail. The point here was to propose a solution to this problem, abstracting common operations into activities.

    Activities are blocks of code, enabling top abstractions of recurrent actions on a web page. Thus, if something changes on your front-end, you modify one activity and not a whole bunch of tests. Unfortunately, no examples were given but you should get the idea anyway.

    Session #5 : 100 agile learning ideas

    This fifth and last session was more than a discussion, it was actually a little workshop where everyone had to imagine new learning ideas about the agile methodology. The approach was the following : we have products :

    • Coding dojo
    • Meetings
    • Pair programming

    And dimensions (characteristics of the products) :

    • Audience
    • Format
    • Involvment
    • Required material
    • Inspired on

    In fact, the audience was split in 2 teams. The first one had to find products and the second one dimensions. A matrix such as this one was then built :

    Audience Format Involvment Required material Inspired on
    Coding dojo Developers Numeric ++ Computers Martial arts  
    Meetings Developers and business people Open discussion + None None  
               

    After that, everybody was assigned a random value in each column and had to imagine what product could be created from that. For example, I got :

    • Audience : developers
    • Format : team
    • Inspired on : martial arts
    • Involvment : +++
    • Support : computers

    And created Best Pair, a situation where 2 developers are given conflicting instructions (such as opposing implementation alternatives) and must develop accordingly. The informations given are related to the same goal, but developers are not informed about that. They must communicate, keep their self-control (martial-arts inspired) to face the conflict and reach an agreement. The point here is to learn to work towards the same goal without staying blocked too long on concerns such implementation details. If the developers success in developing the application and resolve the conflict in a limited, pre-defined amount of time (ex : 1 hour), the exercise will be a success.

    Conclusion

    This was my first CITCON and found it interesting and original at the same time. The fact that participants are speakers at the same time enable rich discussions and return of experiences. Definitely not an event to miss if you’re working with (or interested in) agile methodologies !

    Share/Save/Bookmark