Retour sur les conférences XP Day 2009

Ce billet est un petit résumé des conférences XP Day 2009 auxquelles j'ai assisté. De façon générale, les deux jours étaient super bien organisés et très enrichissants. Le plus enrichissant étant bien evidemment les échanges avec les différents intervenants ou participants hors conférences...

Soigner sa schizophrénie projet MOA / MOE : voyage autour des exigences fonctionnelles exécutables

L'auteur part de deux constats : un projet regroupe deux personnalités différentes : MOA (équipe projet qui indique ce qu'il faut faire) et MOE (équipe technique qui indique comment le faire), et 20% des fonctionnalités d'un logiciel sont réelement exploitées. Ceci nous montre un problème de communication flagrant entre MOE et MOA.

De plus, nous pouvons toujours nous questionner sur la définition du mot "terminé". Pour la MOA, terminé indique la fin des spécifications, pour la MOE, terminé indique la fin des développements. Ceci nous amène à nous poser cette question : en recette, aurons-nous les mêmes attentes ?

La solution à ce problème est les spécifications exécutables. Nous appelons cela ATDD (Acceptance Test Driven Development). Nous travaillons suivant 4 étapes, qui se répète en boucle : Discuss => Distill => Develop => Demo.

Pour ce faire, il est nécessaire d'utiliser un langage commum basé sur GIVEN - WHEN - THEN, avec des spécifications basées sur l'exemple, qui permettent ainsi d'éviter les ambiguités.

Plusieurs outils existent pour réaliser des spécifications exécutables. Les outils proches du code (difficile à utiliser par le client) : JBehave, Aspec, EasyB. Les outils moins techniques, plus utilisables par le client : Fitnesse, GreenPaper, Concordion, RobotFramework. Un nouvel outil apparait sur le secteur : Twist, qui possède sa propre interface pour créér les pages du tests, et permettant le refactoring automatique.

Agile = Absence de spécifications ?

Dans le même ordre que la précédente présentation, l'auteur part du constat que l'écriture de spécifications détaillées avant le démarrage du projet est inutile et qu'elles sont trop ambigues. L'idée est de suivre la théorie des contraintes en réalisant les spécifications "juste à temps" et en laissant l'équipe auto-organiser son planing.

L'idée est de rechercher la définition du mot "terminé" à partir de scénarii, par l'exemple.

Le planning Game

L'auteur part du principe que durant une itération :

• la valeur ajoutée est maximale
• l'équipe s'engage en confiance
• il n'y a pas de modification de priorité
• les stories sont suffisaments détaillées
• l'équipe sait ce qu'elle doit faire

Ainsi pour qu'un planning game soit réalisable et efficace il faut :

• découper/regrouper/créer de nouvelles stories
• faire des spikes
• estimer par comparaison avec les stories précedentes (pour cela, il faut désigner et chiffrer une story moyenne)
• ne pas chiffrer les tâches
• être strict sur la validation des stories

La Théorie des centres, une nouvelle façon de voir la conception incrémentale des logiciels

Plusieurs termes sont à définir :

• Flow => Etat émotionnel ou la personne est productive. Mais tout au long de la journée, nous passons du temps à essayer de comprendre des choses complexes sans raison (y = b(g(x), z, p, t) ???). En résumé, dans une journée il y a beaucoup trop de gaspillage qui empêche le développeur à être dans l'état Flow.

• Théorie des centres de Christophe Alexander (architecte des batiments) : son objectif est de fabriquer des endroits où les personnes se sentent bien. On peut apercevoir dans ses travaux des similitudes avec les méthodes agiles : Design (activité d'élimination d'erreur), Pattern (pour ce type de problème, voila une solution récurente et élégante de le résoudre), idée d'itération en faisant participer les futurs habitants afin d'avoir une construction répondant aux besoins.

• Centre : un centre est quelque chose d'intérêt, qu'on remarque, qui attire l'attention. L'important c'est les relations / les propriétés entre les centres, leur cohérence.

• Process : l'important c'est la conception incrémentale. L'idée est qu'il est impossible de faire quelque chose de bien, répondant aux besoins "from scratch". D'ou l'idée d'amélioration continue, de nettoyage continu.

• La théorie des centres appliquées au développement logiciel : l'idée est de faire ressortir les centres forts d'une application (main, run.sh, mainWindows.html) et de supprimer ce qui ne sert à rien pour renforcer l'important (les centres) => REFACTORING. Par exemple, un morceau de code dupliqué est un centre fort potentiel qui nécessite d'être mis en evidence.

L'idée est donc de faire ressortir les parties importantes d'un logiciel afin d'éviter les gaspillages, les pertes de temps avec des choses sans importance. Le refactoring est l'outil principal pour mettre en place cette idée.

Ce fut LA présentation de ces XP Day à mon avis, super bien présentée, dynamique, bien amenée. Un réél plaisir.

Pour une ergonomie et une Expérience Utilisateur Agile

Ergonomie = Utile (répond aux besoins rééls) & Utilisable (assure réussite, efficacité, efficience et satisfaction). L'idée est d'améliorer l'expérience utilisateur et le dialogue homme-machine en privilegiant les individus et leurs intéractions (plutôt que des process et des outils) en ayant à l'idée les valeurs de simplicité, de changement, de feedback, de collaboration, de valeur ajoutée.

Nous pouvons voir que pour développer une interface érgonomique (répondant aux besoins et efficace) rien de tel que d'utiliser les méthodes de développement Agile en faisant participer l'utilisateur final tout au long du développement.

6 idées pour développer à bien une interface utilisateur :

• l'ergonome doit aider le product owner : fournir et alimenter le backlog, fixer les priorités, décrire les fonctionnalités, ajuster et prioriser les fonctionnalités à chaque itération...
• faire juste ce qu'il faut de recherche et de modélisation en début de projet : simplicité, concision : le but est d'aller à l'essentiel et ainsi d'éviter les gaspillages.
• travailler sur plusieurs modes à la fois : conception (pour les IT futures), accompgnement (IT en cours) et évaluation (tests utilisateur IT+1)
• être réactif aux feedback utilisateurs
• faire du prototypage rapide et adapté
• un groupe (équipe) doit être créé, doit être source de proposition, doit apprendre et explorer toutes les pistes menant à bien le projet.

Coatching

Cette présentation n'était pas une présentation sur le coaching XP comme nous le connaissons, mais le coaching afin d'accompagner un client vers un objectif dans le but de mettre en autonomie le client. En effet, le coaching doit se faire durant quelques mois afin de permettre à l'équipe d'être autonome dans son fonctionnement en mode projet.

Qualité du code source et intégration continue

Il est nécessaire de savoir qu'un code de mauvaise qualité est une réelle dette technique, qui peut amener à la réecriture complète d'une application. De plus, le code de bonne qualité doit être l'affaire de toute l'équipe, et cela ne veut pas dire prendre plus de temps, ce n'est pas une tâche spécifique.

Comme l'indique si bien Kent Beck : "le code doit révéler les intentions d'un développeur", c'est à dire qu'il doit être explicite, maintenable (éviter la duplication de code, enlever le code mort, longueur des classes et méthodes, dépendances), performant (utilisation d'API, de framework) et lisible (Keept It Stupid Simple) : l'objectif est de faire simple, de ne pas apporter de la complexité là ou il n'y a pas a en avoir.

Mais attention à la surqualité qui ne doit pas être un frein à la productivité. pour ce faire, l'équipe logiciel doit mettre en place quelques règles simples : règles de codage, mise en place d'un environnement de développement efficace, revue de code, réalisation de post mortem suite à une mise en production.

Des outils existent afin d'analyser la qualité du code source (disponible souvent pour le langage JAVA) : PMD, CheckStyle, FindBugs, sonar).

Lean Software Development et pratiques Agiles

Lean est la culture du changement dans le but d'accroitre l'efficience des processus client (elimination des gaspillages). Les principes sont les suivants :

• Valeur : se concentrer sur ce qui est important pour le client
• Chaîne de valeur : s'assurer que toutes les activités sont nécessaires et ont de la valeur ajoutée
• Flux : La sortie d'une activité est prise en compte par l'activité suivante du processus sans attente
• Flux tiré : rien n'est fourni par l'amont tant que l'aval n'en exprime pas le besoin
• Perfection : prévenir les défaut et le rework, entretenir une amélioration continue

Les 7 principes fondateurs de LEAN sont :

• Éliminer les sources de gaspillage : trop de fonctionnalité, travail partiellement fait, transmission d'information, retards, défauts
• Favoriser l’apprentissage : on apprend par la pratique et on apprend de ses erreurs
• Reporter la décision : décider au dernier moment, pour ne pas se fermer des portes inutilement
• Livrer vite : on livre vite, ainsi on a le feedback rapidement, on livre vite, ainsi le client est satisfait de "voir" quelque chose, même perfectible
• Responsabiliser l’équipe : pour un meilleur investissement
• Construire la qualité intrinsèque : la qualté comme fil rouge
• Optimiser le système dans son ensemble : vision produit et non projet

En quoi LEAN est une pratique Agile :

• Développement Itératif (revue de code, itération rétrospective) dans le but d'éliminer les gaspillage, de livrer rapidement, de construire la qualité intrinsèque, d'optimiser le système dans son ensemble
• TDD, Refactoring, Tests de recette, Intégration continue dans le but de construire la qualité intrinsèque, de favoriser la connaissance, de retarder la décision, d'éviter les gaspillages
• Pair programming, design simple dans le but d'éviter les gaspillages et de favoriser les connaissances

Ce fut vraiment un très bonne présentation avec une super comparaison entre méthodes Agiles que nous connaissons (XP, Scrum) et LEAN software Development.

Pratiques d'Ingénierie Incrémentale

Cette présentation ne m'a rien appris de nouveau mais ce fut un réel plaisir d'y participer car les présentateurs étaient de qualité. L'objectif était de présenter les avantages d'un développement itératif en présentant des pratiques incrémentales que de nouvelles équipes pouvaient mettre en place petit à petit comme :

• livraison incrémentale
• retrospective
• tests automatisés
• backlog priorisé
• TDD
• equipe auto-organisée
• stand-up meeting

"Business Value Game" : trois itérations dans la peau du Product Owner

Jeu annimé par Pascal van Cauwenberghe. Nous étions organisés en équipe avec un client, une équipe de développement, un comptable et l'objectif était de gagner le maximum d'argent en mettant en production les demandes clients et en rendant les clients satisfaits par les mises en production.

Le but recherché par ce jeu était de montrer l'importance de la Valeur Metier, c'est à dire ce que ça apporte au client. L'important est de créer de la Valeur Metier en mettant les demandes clients en production et non en développant des histoires d'utilisateurs, en limitant le nombre de demandes et de stories en cours en fonction de la capacité des développeurs. Enfin il vaut mieux parfaois satisfaire un client et en perdre un autre que de garder deux clients mécontents...

Ce jeu état vraiment très bien organisé et animé et montrait une des valeur clé de tout projet de façon ludique.