Mix-IT 2012 – décantation

Jeudi 26 avril dernier se sont déroulées les conférences Mix-IT 2012 organisées par le CARA et le JUG de Lyon. Voici un échantillon de ce que j’ai pu y glaner.

Continue reading

Posted in conférences | Tagged , , , | Leave a comment

Pair programming : le rôle de mentor et la théorie de la passe

Passe VergalloUn des travers dans l’utilisation de la programmation en paire est le syndrome du « clavier englué ». En effet qui n’a pas passé sa journée à jouer uniquement le rôle du pilote ou du co-pilote sans inverser les rôles ? En théorie, les rôles doivent être inversés aussi souvent que possible et au moins toutes les ½ heures (source www.wikihow.com).
Alors pourquoi est-ce si difficile de laisser ou de prendre le clavier ? Continue reading

Posted in retours d'expérience | Tagged , , , | Leave a comment

Limiter son TAF avec les Design Patterns

Au cours d’un dojo improvisé nous nous sommes intéressés à modifier le programme suivant pour limiter le nombre de tâches en cours en utilisant le plus de design patterns possibles.

Le programme d’origine affiche le nombre de travaux en cours dans la sortie console. Basé sur les timers systèmes, toutes les secondes une nouvelle tâche est lancée. Chaque tâche durant 5 secondes, il y a augmentation du nombre de tâches en cours jusqu’à stabilisation du processus.

class Program
{
    static void Main(string[] args)
    {
        int workInProgress = 0;
        var workGenerator = new System.Timers.Timer();

        workGenerator.Interval = 1000;
        workGenerator.Elapsed += (o, s) =>
            {
                Console.WriteLine("begin work {0}", ++workInProgress);
                System.Threading.Thread.Sleep(5000);
                Console.WriteLine("end work {0}", --workInProgress);
            };

        workGenerator.Start();

        Console.WriteLine("Press any key to terminate");
        Console.ReadLine();

        workGenerator.Stop();
    }
}

Continue reading

Posted in architecture, programmation objet | Tagged , , | Leave a comment

Rétrospective 2011

L’année 2012 est déjà bien entamée mais il aurait été dommage de quitter le mois de janvier sans bilan de 2011.

Ce qui s’est bien passé

Ce qui s’est moins bien passé

  • Je n’ai pas écrit d’article sur Agile innovation 2011. C’est dommage, l’expérience était vraiment enrichissante. Si j’ai le temps, je ferais peut être un court billet sur le sujet courant février.
  • Participation aux Coding Dojos du CARA. Je n’y suis allé qu’une fois. Le sujet était le “open/close principle”. Super intéressant, mais pas facile de traverser la ville entre midi et deux pour y aller plus souvent.

Les indicateurs

2010 2011
Nombre de visiteurs / mois 60 100
Nombre d’articles 11 11
Nombre de commentaires 4 6 + 2 pings back

Bilan très positif donc, espérons que 2012 soit aussi riche. Merci à : Yann, Alex, Claude, Carl et Aline pour leurs commentaires.

Posted in Non classé | Tagged | 1 Comment

Agile Grenoble 2011 décantation

Comme prévu cette année Agile Grenoble a été encore une fois très riche. Voici ce que j’en retiens :

Keynote “Starting An Agile Transition with Why”
par Karl Scotland
Introduit comme une personne qui fait du Lean même quand il fait son jardin, la conférence de Karl recentre la réflexion sur le Why. D’après lui c’est en répondant clairement à cette question que l’on est plus efficace car on a plus de motivation donc plus de succès. Ça m’a rappelé une conférence en 2009 de Marie-Pia Ignace sur l’approche A3. Elle nous avait alors posé la question : pourquoi faite vous de l’agilité ? … Et bien les réponses étaient loin d’être claires ;)

Les tests intégrés sont une arnaque!
par J. B. Rainsberger
En allant à cette conférence j’avais un peu peur car je me demandais ce que j’allais y découvrir. J’en ressors rassuré : « les tests unitaires sont bons car ils mettent la pression sur le design ». Et j’utilise les Mock correctement en validant d’un coté les « expectation » et de l’autre le contrat.
Par contre, J. B. nous explique que les tests intégrés (c’est à dire ceux qui testent plusieurs entités logicielles) nous font rentrer dans une boucle infernale.
Je rentre aussi avec une belle astuce : les tests abstraits pour factoriser le code. Merci!

Démonstration / Kata BDD sur un logiciel pilotant un instrument
Par Matthieu Gironnet et Johanny Bergeron
Belle démonstration de Behaviour Driven Developpement pour la validation d’un driver d’un banc de test chimique. Matthieu joue le rôle du PO et Johanny nous montre comment il implémente les tests à l’aide du framework specflow.

Key note “How to Change the World”
Par Jurgen Appelo
Dans sa keynote Jurgen nous explique que les différents facteurs dans une transition vers l’agilité sont : le système, les individus, les connexions et l’environnement. Ça m’a rappelé quelques bons souvenirs et aussi quelques instants de sudation intense. J’en retiens qu’en tant que vecteur du changement, il ne faut pas partir trop tôt sinon les derniers réfractaires reprennent le pouvoir.

Rétrospectives’lab: décantation
Par Emilie Franchomme
Très belle présentation disponible ici avec beaucoup d’informations. Ça donne envie de lire le livre Agile Retrospective de E. Derby et D. Larsen. Nous n’avons eu droit qu’à une seule question en fin de séance : « En recherchant ainsi constamment le consensus, comment faites-vous lorsqu’il y a clairement besoin de rupture ? ». Pour moi la solution est dans le rôle du facilitateur, qui doit amener l’équipe à réfléchir sur les vrais problèmes… pas facile !

Comment rendre nos entreprises Agile ?
Par Frédéric Dufau-Joël
Fréderic nous explique comment faire des brainstormings géants avec le café découverte ainsi qu’une définition de HOLACRATIE. Ce qui m’a plut c’est la façon dont on pouvais poser des questions (le fishbowl) : l’orateur avait mit 5 chaises en rond au centre de la salle et pour poser une question il fallait venir s’assoir. Ce qui est intéressant c’est qu’on oublie qu’il y a 40 personnes autour qui écoutent : du coup l’échange est beaucoup plus spontané.
Liens : http://www.integralvision.fr, http://www.inandco.com/, http://www.osphere.fr

Conclusion
Cette année les conférences étaient vraiment de très bonne qualité. Il y a juste l’Atelier Neuro Agile de Laurent Bossavit auquel je n’ai pas pu assister. C’est dommage que les conférences ne soient pas filmées : ca permettrait de profiter un peu des sessions que l’on ne peut pas voir.
Merci encore à toute l’équipe d’organisation et aux sponsors pour ce bel évènement !

Posted in conférences | Tagged , , , , , , , | 2 Comments

Apprentissage collaboratif

Cela fait deux itérations que nous avons pris deux heures dédiées à l’auto-apprentissage de l’équipe.

Le principe est le suivant : sur une matinée, on consacre deux fois une heure aux échanges entre les développeurs. En début de séance l’équipe énumère les sujets qu’elle souhaite aborder. Chaque collaborateur est libre de proposer un échange qui peut être de 3 types :

  • une demande : j’aimerais qu’on m’explique tel sujet
  • une proposition : j’ai compris tel point technique et je suis prêt à le partager avec les autres
  • un approfondissement : j’aimerais qu’on aborde tel sujet à plusieurs

L’équipe constitue ensuite librement des groupes de travail autour des sujets proposés. Le sujet doit être traité en une heure et on organise une rapide rétrospective à la fin. Pendant la séance, une seule règle : dès qu’un collaborateur n’apprend plus rien ou a l’impression de perdre son temps, il le signale. Si le sujet d’à côté l’intéresse, il peut changer de groupe. Si plusieurs personnes sont dans ce cas, c’est peut-être l’occasion de lancer un autre sujet.

La première amélioration a été de mettre en place une To Learn List pour apporter une visibilité sur ce qui a été fait et ce qui reste à faire. Le retour d’expérience est vraiment très positif et le ROTI ne descend pas en dessous de 4/5. C’est fou ce qu’on arrive à faire en moins d’une heure !

Posted in retours d'expérience | Tagged , | Leave a comment

Conférences Agile Grenoble 2011 par le menu

Ca y est, le programme définitif des conférences est enfin disponible ici. Cette année il y a deux jours avec deux thèmes : les conférences traditionnelles le 24 novembre et Agile innovation pour les “agilistes” confirmés le 25.

Comme chaque année le plus dur est de choisir ce à quoi on veut assister. Attention, le jour J ce sont parfois les places disponibles restantes qui choisissent pour nous.

Cette année voici tout ce que j’aimerais aller voir :

Je n’arriverais pas à tout voir, il y a des sessions qui sont aux mêmes horaires. Et vous, qu’est-ce qui vous tente dans ce menu ?

Posted in conférences | Tagged , , | Leave a comment

Exemple de backlog et utilisation de la valeur métier

Pour illustrer la mise en place d’un backlog et de l’ algorithme de valeur métier rien de tel qu’un exemple pratique. A l’instar des « coding dojos », le principe du projet SudokuGame est de mettre  en œuvre certains principes dans un projet sans enjeu industriel. Le backlog complet après 6 itérations est disponible ici.

Définition des utilisateurs

On ne considère qu’un seul utilisateur : le joueur qui fait une partie de sudoku. Il joue pour son loisir mais essaye de s’améliorer. Il peut faire une partie sur plusieurs jours.

Écriture des “epics”

Les “epics” sont définis en terme de lot de fonctionnalités. Pour les définir on se pose les questions suivantes : Quels groupes de fonctionnalités l’utilisateur est il prêt à essayer ? Quels sont les lots qu’il est prêt à payer ? Si on retire une fonctionnalité, l’”epic” intéresse-t-il toujours l’utilisateur ?

Définition de l’algorithme de valeur métier

L’algorithme qui a été mis en place est le suivant :

Valeur epic = Nécessité + Satisfaction utilisateur

Les deux grandeurs sont estimées par deux entiers.

Répartition de la valeur métier sur les user-sory

  • La valeur de chaque epic est répartie équitablement sur chaque user story qui le compose
  • Ensuite la valeur de chaque US est pondérée par l’estimation de l’effort (colonne valeur / cout).
  • On essaye de fixer les priorités en fonction de cette valeur.

Petite rétrospective

  • La valeur métier comme indicateur : lorsque l’on ne veut pas suivre l’algorithme c’est peut être qu’il y a un problème de découpage. Par exemple en début de projet il n’y avait qu’un seul epic “confort de jeu”, dès la deuxième itération on se rend compte qu’il y a des fonctions de confort qui son indispensable pour l’utilisateur. L’épique est alors divisé en deux avec une nouvelle répartition de la valeur.
  • Pas facile d’être PO. Sur un projet simple, même lorsque le PO est lui même l’utilisateur final, on arrive pas forcément à fixer les priorités au début du projet. (La sauvegarde de la partie en cours était tout en bas dans les priorités mais est très vite devenue indispensable après quelques démos). Vive l’itératif !
  • Le problème de cet algorithme est qu’il repose uniquement sur des grandeurs arbitraires difficiles à pondérer.
Références:
- User stories applied – Mike Cohn
- http://www.xp.be/businessvaluegame/
Posted in exemples | Tagged , , , , | Leave a comment

100 % tested – comment jardiner les tests automatiques

Dernièrement je suis intervenu dans une équipe qui débutait dans la pratique de Scrum et n’avait pas la culture “tests automatiques”. La pratique de Scrum et notamment la perte de propriété du code est périlleuse sans une forte utilisation de tests automatiques. En effet quand on est tout seul responsable de son code, on se passe généralement de tests auto vu qu’on se porte garant à la fois des non régressions et de la cohérence du code. Dans une équipe conséquente, où plusieurs personnes peuvent intervenir sur les mêmes parties du code on perd cette centralisation.

Voici la petite recette que j’ai utilisée pour jardiner la culture test :

  • Commencer par tester tout le code qu’on produit soi-même (balayer devant sa porte… :) )
  • A chaque fois qu’un développeur fait passer au rouge, ne pas le laisser tout seul, l’aider à tout remettre au vert, et identifier le comportement mis en défaut.
  • Pair programmer pour montrer comment on peut faire des tests petits et simples
  • Pair programmer pour montrer comment on peut appréhender le TDD
  • Être un peu “intégriste” : un bug trouvé est une fonctionnalité non testée
  • Utiliser des outils pour afficher la couverture de code (voir des zones à 100% est  très motivant)

Par l’exemple, en refusant de fournir du code non testé, l’équipe s’est peu à peu rendue compte des avantages des tests automatiques. Au bout de 4 mois  de projet j’ai commencé à entendre des phrases du type : “Si les tests ne passent pas c’est que j’ai changé du comportement…”, “J’ai encore du mal avec le test before, mais je comprend l’utilité du test auto”, “J’ai été convaincu de l’utilité du test unitaire, c’est indispensable pour pouvoir faire des évolutions sereinement”, “Quand je code un comportement, je suis serein lorsque d’autres personnes développent sur le même code car tout changement est signalé”.

Les tests auto sont une ceinture de sécurité et quand on n’en a plus on se sent un peu nu :)

Posted in retours d'expérience | Tagged , , , | Leave a comment

Profils agiles et profils d’équipe

Hier j’ai assisté pour la première fois à une “rencontre autour de l’agilité” organisée par le CARA. Jérôme Barrand  nous a présenté “l’Agile profile” qu’il utilise dans ses échanges avec les équipes de management. L’approche de Jérôme est intéressante dans le sens où il ne vient  pas du monde informatique. Il est l’auteur  du livre “Le manager agile” qu’il avait présenté en ouverture de l’Agile Tour 2008.
Le profil est une projection de l’individu sur 6 comportements répartis sur 3 principes :
ANTICIPACTION
(Agir et anticiper la conséquence)
PROOPERATION
(Coopération réciproque / échange de satisfaction)
JUSTINOVATION
(Juste ce qu’il faut au bon moment)
Intuition
pro-action
Empathie systémique
Synchronisation
Rébellion constructive
Pédagogie managériale

Jérôme nous a ensuite montré comment les méthodes agiles de nos systèmes d’informatiques encourageait ces comportements :

  • Daily meeting pour la synchronisation
  • Rétrospectives pour la rébellion constructive
  • Dashboard visuel : pour la vision systémique

D’après lui l’agilité d’une équipe est renforcée lorsqu’il ne manque pas d’individus moteurs dans chaque comportement.

Merci à Jérôme Barand et au CARA pour cette conférence.
Je lui mets 4/5 au ROTI.
J’aurais mis 5 si on avait pu plus échanger sur les parallèles avec le développement informatique.

Posted in conférences | Tagged , | 1 Comment