Magazine Internet

Retour sur les conférences XP Day 2009

Publié le 28 juin 2009 par François Mottet

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.


Vous pourriez être intéressé par :

Retour à La Une de Logo Paperblog

Ces articles peuvent vous intéresser :

  • Another Day

    rien de bien neuf à dire juste qu'on a toujours des soucis de net donc c'est pas topsinon dans d'autres infos plus gaies j'ai enfin pu prendre ma place de balle... Lire la suite

    Par  Mabo
    JOURNAL INTIME, TALENTS
  • Fisherman’s day

    est une démo, un petit prototype de jeu où l’on déplace un personnage grâce à la souris dans un univers 3D. Cette application a été créée par Sylvain Brian... Lire la suite

    Par  Goanna
    BEAUX ARTS, CULTURE
  • Day off

    Dimanche, cela fait 15 jours que je suis là. Le rythme de boulot est assez intensif, c'est mon premier jour off. Jusqu'à présent je n'ai pas eu beaucoup... Lire la suite

    Par  Martin
    BD & DESSINS, TALENTS
  • Day dream

    L’âne et l’éléphant par French Fry C’est un jour historique : Inauguration Day, c’est-à-dire prise de fonction du nouveau président des États-Unis, en... Lire la suite

    Par  Jlhuss
    HUMEUR, SOCIÉTÉ
  • Obama Day

    En hommage aux 170 millions de dollars dépensés pour l'investiture, sans compter les millions de dollars claqués par toutes les télés, radios et journaux du... Lire la suite

    Par  Allo C'Est Fini
    A CLASSER
  • Navy Day !

    Une tenue des plus simples pour aujourd'hui... Il y a des jours ou on n'a pas trop envie de chercher à faire compliquer... c'est le cas pour moi aujourd'hui...... Lire la suite

    Par  Twiggy
    CÔTÉ FEMMES, CULTURE, MODE FEMME
  • Obama day

    "Jurez-vous, Barack Hussein Obama, d'éradiquer la pauvreté et la faim, de vaincre la dépression économique, de donner du travail à tous, de mettre en place un... Lire la suite

    Par  Adadala
    POLITIQUE, SOCIÉTÉ

A propos de l’auteur


François Mottet 8 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte

Dossiers Paperblog