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

Votre architecture est elle SOLID ?

Non il ne s’agit pas d’une publicité pour vous vendre un audit sur l’architecture de vos concurrent ;) mais bien de patterns d’architecture définis par Robert C. Martin.

Comme on peut le lire dans wikipedia, SOLID est un acronyme pour définir les 5 principes :

  • Single Responsability
    • Un objet n’est responsable que d’une chose
  • Open/Close
    • L’objet doit être ouvert au extension de comportement sans modification du code
  • Liscov Substitution
    • On doit pouvoir substituer un objet par un autre de classe dérivée
  • Interface segregation
    • Multiplier les interfaces plutôt que d’avoir une interface à tout faire
  • Dependency inversion.
    • Les objets doivent dépendre d’interfaces pas de classes concrètes

On trouve un document de Robert C. Martin très complet sur le sujet ici.  Sa lecture donne envie de se procurer le livre du même auteur Clean Code.

L’article fournit quelques indicateurs pour mesurer la SOLIDité de l’architecture. Certains sont facile à mettre en œuvre :

  • Sur un objet compter le nombre de responsabilité (facile)
  • L’utilisation de if / switch sur les types d’objets peuvent indiquer une violation du principe Open/Close
  • Compter le nombre d’interfaces d’un objet et visualiser les dépendances vers les classes concrètes

D’autres plus compliqués sans outils adéquat :

  • Rapport des dépendances entrantes vs dépendances sortantes d’un package
  • Détecter les violations du principe de Liscov

En analysant ces critères sur son code, on ne trouve pas son architecture toujours aussi SOLID. Etonnamment on n’aime pas avoir à intervenir sur du code FRAGILE ;)

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

Planning poker : régulateur de discussion

Dernièrement en réunion de planning nous avons eu un bel exemple de l’utilisation du planning poker comme régulateur de discussion. Nous devions estimer une user story qui consistait à réaliser un prototype pour un client. Après avoir négocié le périmètre fonctionnel avec le product owner, le débat s’est vite orienté sur la pertinence de telle architecture par rapport à telle autre. Au bout de quelques minutes de discussion, nous avons arrêté le débat pour estimer une des deux propositions. Comme souvent après deux “plis” de planning poker les estimations ont convergé. Nous avons décidés de ne pas aller plus loin en estimant l’autre architecture car nous avons convenu qu’elle n’allait pas diverger suffisamment. Le débat sur l’architecture a été reporté à plus tard, c’est à dire au moment où la user story sera réalisée.

Souvent nous avons tendance à alimenter le débat avant les premières estimations. On voit ici que cela n’est pas toujours pertinent. Je pense cependant qu’il faut faire attention et vérifier que chaque personne ait pu exprimer son point de vue avant de conclure avec des estimations convergentes. En tous cas c’est une idée pour faire avancer les choses lorsque le débat tourne un peu en rond.

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

Code Retreat à Grenoble : mise en oeuvre de pratiques extrem programming

Vendredi dernier j’ai participé à une session de Code Retreat à Grenoble organisée par le CARA et le JUG. Merci aux organisateurs pour cette belle journée.

Le principe :

La scéance comporte 6 itérations. Le principe du code retreat réside dans le fait d’effacer le code à chaque itération . L’analogie aux arts martiaux tient dans l’idée de travailler plusieurs fois le même geste pour se perfectionner.

Le travaille est réalisé en TDD et en Pair programming. L’objectif est d’investiguer les pistes que l’on ne se permet pas dans un cadre industriel. Une consigne supplémentaire est d’appliquer les règles SIMPLE DESIGN :

1 – Les tests doivent passer
2 – Supprimer les doublons
3 – Nommage pertinent
4 – Faire court

Une itération se compose de :45 min de code, 10 min de rétrospective, 5 minutes de pause.

Ce que m’ont apporté ces itérations :

Pair programming de 10 minutes : l’idée est de changer de rôle toutes les 10 minutes : le pilote devient copilote et vis versa. La sensation est grisante : on a l’impression de courir une course de relais. S’échanger le clavier si souvent oblige à partager le design et la direction où l’on veut aller.

Mesurer le temps de cycle rouge : le TDD définit trois phases : une rouge pendant laquelle le test ne passe pas, une verte lorsque le test passe, et une dernière de refactoring. On s’attache à minimiser le temps de phase rouge en dessous de 5 minutes. L’exercice est intéressant car il oblige à ne pas prendre trop d’avance dans le design et à ne coder que ce qu’il faut pour que le test passe. Cela implique une réflexion sur les contraintes nécessaires pour garantir que le programme fonctionne.

Nouvel indicateur de design : facile à mettre en œuvre, si l’on a un « if » sur un état on peut éventuellement le supprimer en implémentant des classes dérivées.

Refactorisation des tests : attention à ne pas introduire des bugs dans la couverture de test sans s’en rendre compte. C’est pour moi le bémol de cette approche : comment garantie-t-on l’intégrité des tests si on les modifie ?

Le rôle du copilote : en recentrant les questions sur ce que l’on veut faire et les contraintes que l’on s’est donnée, le copilote influe directement sur la productivité. Il limite ainsi une tendance naturelle à s’éparpiller.

Le test comme guide pour le design : stressé par un design complexe, on a souvent tendance à anticiper et à écrire du code en avance alors qu’il n’est pas nécessaire. En essayant de limiter le temps rouge, le design nait de l’analyse de toutes les contraintes plutôt que des aprioris que l’on peut avoir en abordant le problème.

En conclusion :

  • Bilan très positif : 4/5 au ROTI. Il m’a peut-être manqué deux minutes de rétrospective en binôme avant de mettre en commun avec les autres participants.
  • Nouvelle facette du pair programming en changeant toute les 10 minutes : à essayer !
  • TDD : Ne pas trop se poser des problèmes de design en cours de test. Vraiment se concentrer sur l’aspect spécification. Ce sont les tests qui vont nous montrer la voie, il faut leur faire confiance.
  • Cette exercice est très bon pour enrichir ses approches. Promis j’essaierais de venir aux prochains Coding Dojos du CARA.
  • Attention au refactoring des tests.
Posted in Uncategorized, conférences, retours d'expérience | Tagged , , , , , | Leave a comment

Rétrospective 2010

Voici venu le temps de la rétrospective annuelle sur ce blog en particulier et l’agilité en général.

Continue reading

Posted in exemples | Tagged | 6 Comments