Retour sur la conférence Agile France 2012 (part 2/2)

Suite et fin de ma synthèse des deux jours passés à l’Agile France 2012.
Pour lire la première partie, c’est par ici.

Le contrat Agile : retour d’expérience

Gilles Mantel et Hugo Geissmann nous ont présentés lors de cette session les principes de la contractualisation Agile. Les principes d’un tel contrat sont :

• Un périmètre variable
• Partage des risques
• Engagement
• Pénalité
• Réversibilité

Ce type de contrat s’adresse à des typologies de projets critiques pour le business, avec un TTM contraint et innovant aussi bien fonctionnellement que techniquement. On retrouve dans ce type de contrat des métriques qui ne sont pas classiques : productivité , qualité technique et fonctionnelle, satisfaction du client.
Un contrat Open Source existe à cette adresse : http://contrat-agile.org

Atelier : satisfaire complètement ses utilisateurs avec le software kaizen

Alors, venant de Zenika, et avec un titre comportant le mot kaizen, je ne pouvais pas passer outre assister à cette présentation qui traite de l’amélioration continue d’un logiciel ou d’une application. Régis Medina, nous présente dans un premier temps les grands principes du Lean, avec notamment la roue de Deming et le PDCA.
La première des actions consiste à trouver des indicateurs mesurables qui vont nous permettre de constater de façon factuelle les bons résultats ou non des différentes solutions qui vont être tentées suite à un problème identifié.
A partir du constat de ces mesures, il faut ensuite se donner des objectifs. A partir de ces constats et de ces objectifs, on va travailler en utilisant le PDCA dans le but de tenter d’améliorer le produit.

La suite de la séance va consister à nous montrer comment il est possible d’identifier des éventuels axes d’améliorations.
Avant de commencer, il nous explique le principe de Genchi Genbutsu (Go And See), qui consiste à s’installer à coté d’un utilisateur lambda et de simplement regarder ce qu’il fait. D’un coté, on note toutes les actions que l’utilisateur réalise, et de l’autre le temps qu’il met à réaliser ces actions. Le plus dur étant de se taire pour ne pas perturber ou influencer l’utilisateur (visiblement dans la pratique et d’après son expérience personnelle, il y a de quoi s’arracher les cheveux ! 🙂 )
On termine donc cette séance avec un cas concret ou un volontaire prend la place de l’utilisateur, et tout le public celui de l’observateur. Ce fut un atelier riche et intéressant avec un orateur qui captive son auditoire : un agréable moment ou on apprend à améliorer une application.

Des maux, des mots, démo

Un des sujets que l’on retrouve rarement ou même jamais, lors de conférences sur l’agilité, est le Sprint Review et en particulier la démo, c’est ce que soulignent Emilie Franchomme et Caroline Damour-Nobi lors de leur introduction. Pour composer le contenu de cette présentation, les deux oratrices ont réalisé une enquête auprès d’une cinquantaine de personnes dont le but était de connaitre le point de vu de chacun quant au Sprint Review. Ce qui revient beaucoup, c’est qu’il s’agit d’une cérémonie qui nécessite de la préparation :

• inviter les participants
• réserver une salle
• ce qui va être montré
• qui montre quoi
• copies d’écrans à la place d’un process très long comme des batchs SQL par exemple
• anticiper des problèmes de matériel (réseaux, rétro projecteur)

Il ne s’agit pas de faire une simple démo, mais plutôt de raconter une histoire, de montrer ce qui est fini car montrer force à finir. C’est également un moment privilégié pour recevoir du feedback :

• il faut s’attendre a être surpris des feedbacks
• ne pas être sur la défensive
• solliciter tous les participants pour provoquer le feedback
• prendre note de toutes les suggestions : ne jamais écarter une suggestion

Enfin, il s’agit également d’un moment qui permet de célébrer la fin d’un sprint, ce qui favorise la fierté et dynamise l’équipe.
Une présentation certes qui ne ré-invente pas la roue, mais qui donne une bonne piqure de rappel sur les objectifs d’un Sprint Review

Chouette, encoure un bug

MERCI ! C’est le mot que nous apprend a dire Pascal Van Cauwenberghe lors de sa présentation. Il nous fait découvrir l’algorithme idéal lors de la découverte d’un bug avec un objectif majeur : résoudre le bug, capitaliser dessus et faire en sorte de ne plus trouver de bug similaire :

1. Trouver un bug
2. Dire “Merci”
3. Reproduire le problème
4. Ajouter un test qui échoue
5. Corriger le problème
6. Tous les tests passent
7. Executer les actions issues du RCA (foot cause analyze)
8. Améliorer les tests
9. Améliorer la façon d’écrire les tests
10. Des problèmes similaires ? GOTO 2
11. Rendre impossible de refaire la même erreur (refactoring)

Pour ce qui est du refactoring important nécessitant un temps de réalisation conséquent, il nous propose un rapport A3 qui va être affiché sur un mur visible de tous. Ce rapport est découpé en 4 :

• Un schéma de l’architecture actuelle (avant le refactoring)
• Un schéma de l’architecture cible
• Une liste d’actions
• Un indicateur d’avancement de ce refactoring (burndown chart)

Au final, nous avons ici une présentation d’une méthode pragmatique d’amélioration d’une application basée sur la découverte d’un bug. Et pour le clin d’oeil à l’auteur : MERCI ! 🙂

L’île mystérieuse : Behaviour Driven Development et les tests d’acceptances

Ayant beaucoup entendu parlé du BDD dans sa théorie, mais n’ayant jamais eu l’occasion d’avoir un retour concret de son application, j’étais très intéressé d’assister à cette présentation animé par Gabriel Le Van. L’animateur nous fait dans un premier temps un bref rappel des différents niveaux de tests :

• Les tests unitaires dont le but est de valider que le code fonctionne
• Test Driven Development qui permet d’améliorer la conception en faisant du “Design par contrat”
• Les tests d’acceptance qui permettent de valider que le code porte de la valeur fonctionnelle
• Behaviour Driven Development dont le but est d’optimiser la valeur apporté par du “Design par valeur”

Le BDD a été poussé par Dan North en 2003 avec l’idée d’avoir un langage simple et compréhensible par tous : l’Ubiquitous Language. Ces tests d’acceptante devraient être écrits par les fonctionnels en suivant le schéma : Given -> When -> Then. La constitution d’un corpus de tests d’acceptances automatisés permet en outre de disposer d’une documentation executable : a living documentation.

Son retour d’expériences personnelles, l’amène aux conclusions suivantes :

• L’implication des fonctionnels est difficile car elle nécessite l’implication d’un Product Owner volontaire.
• Les gains sont moins immédiats qu’avec le TDD
• Sécurisation des MEP
• Une documentation maintenue à jour
• Ouvre la porte au déploiement continu

Pour terminer sa conférence, Gabriel Le Van nous propose des exemples de l’utilisation de 3 outils majeurs :

• Concordion
• JBehave
• Fitness

Un retour d’expérience très intéressant qui confirme mes appréhensions à la mise en place du BDD due principalement à l’impli
cation des fonctionnels.

Kapla World Tour : revisited Scrum

Le dernier atelier de ces deux jours denses se veut ludique avec la (re)découverte de Scrum animé par Antoine Berthelin et son équipe Agile So@t. Le principe est simple : construire des monuments du monde avec des Kaplas :

• 4 équipes de 5 personnes sont en concurrence
• un Scrum Master par équipe assuré par un des animateurs
• un PO commun
• un maitre du temps
• un Product Backlog contenant les monuments à construire, un nombre de points de satisfaction du PO par monument et une liste (non exhaustive) de critères d’acceptante.

Le jeu se déroule en 3 itérations, chacune décomposée de la façon suivante :

• Une cérémonie de début de Sprint dans laquelle l’équipe doit s’engager sur un certain nombre de monuments à réaliser pendant le Sprint
• La réalisation, pendant laquelle il faut bien sur construire les monuments mais aussi aller à la pêche aux critères d’acceptante manquants auprès du PO
• Un Sprint Review pendant lequel on fait une démonstration de la réalisation. C’est aussi l’occasion pour le PO de valider ou non les réalisations en fonction de tous les critères d’acceptante.
• Une restrospective pendant laquelle l’équipe doit dégager une action pour s’améliorer.

Des points de satisfaction sont également donnés durant chaque sprint en fonction de la visibilité de l’avancement (BurnUp chart, post-it des monuments, etc…) que donne l’équipe au PO.

Une activité ludique qui permet, pour tous les participants déjà très à l’aise avec Scrum, d’appliquer les principes généraux. On y trouve surtout un jeu simple et pédagogique pour faire découvrir à des néophytes la méthode Scrum. Petit bémol néanmoins, il serait intéressant de construire un et un seul monument de manière itérative pour se rapprocher au plus près de Scrum.

Conclusion

Comme je le dis tout au long de ces deux articles, ces deux jours ont été riches en retours d’expériences. Le nombre de conférences étant très important (6 en même temps à tout moment de la journée), il a été nécessaire de faire des choix parfois douloureux, et c’est le seul regret que je pourrais avoir. Un grand merci à l’Agile France d’avoir organisé cette 7ème édition, et c’est avec une grande hâte que j’attends la prochaine en 2013 ! 🙂