Accueil > Méthodes Agiles > Méthodes agiles – XP days 2009

Méthodes agiles – XP days 2009

J’ai eu la chance de participer cette année pour la première fois aux XP days les 25 et 26 mai.

Cet événement a été un beau succès : environ 250 participants et plus de 50 sessions sur 2 jours. Avec 6 sessions en parallèle, il n’était donc pas toujours facile de choisir!

Les sujets abordés ne concernaient pas seulement XP mais également l’agilité au sens large, Scrum, Lean, … d’ailleurs l’édition 2010 s’appellera « Agile Paris 2010 ».

Pratiquant Scrum en tant que Scrum master, je me suis orienté principalement vers les sessions concernant les sujets suivants:

  • Les aspects tests / critères d’acceptance : il est essentiel de pouvoir définir un besoin et de s’accorder sur la notion de terminé sans la moindre ambiguïté. J’étais particulièrement intéressé par l’ATDD (Acceptance Test Driven Development) et par le retour d’expérience sur l’utilisation d’outils à ce sujet.
  • Le Product owner : son rôle est important puisque c’est à partir de sa vision, son découpage et sa gestion des priorités que l’équipe Scrum travaille. Je souhaitais échanger sur la façon de découper les besoins et les prioritiser pour maximiser la valeur business.
  • Agilité au sens large / retour d’expérience : La résistance au changement est, de mon point de vue, une des principales difficultés pour le passage à l’agilité à tous les niveaux (et pas seulement pour l’équipe de développement). Avoir des métaphores ou encore assister à des présentations qui présentent des retours d’expérience, permet d’enrichir nos arguments, trouver les mots et exemples pour convaincre ceux qui ne le sont pas encore 😉 ou pour introduire certains concepts en douceur.

Je vous livre ci après un résumé et un avis sur les sessions que j’ai le plus appréciées.

Test / Critères d’acceptances

J’ai beaucoup apprécié la présentation Soigner sa schizophrénie projet MOA / MOE : voyage autour des exigences fonctionnelles exécutables.

Elle explique la nécessité pour des équipes MOA (maitrise d’ouvrage qui définit ce qu’il faut faire) et MOE (maitrise d’œuvre qui fait) de communiquer pour définir le besoin et s’accorder sur la notion de TERMINE. Spécifier par l’exemple c’est à dire décrire les user stories à travers des exemples permet de lever toute ambiguïté. Des outils existent pour formaliser ces tests et rendre les spécifications exécutables. Les slides de la présentation sont disponibles http://www.slideshare.net/ehsavoie/soigner-sa-schizophrnie. Je vous invite grandement à les parcourir.

Personnellement, cette présentation m’a donné envie d’évaluer et utiliser ce genre d’outils.

J’ai également participé à l’atelier Dojo TDR (Test Driven Requirement). L’objectif de cet atelier était d’utiliser les tests pour décrire des exigences et règles de gestion. Une personne à tour de rôle prenait les commandes du PC, pour une durée time boxée de 5 mn, pour décrire un test sous FitNesse.

Le formalisme utilisé était:

  • Given : Etant donné (précondition)
  • When : déclenchant.
  • Then : ce qui doit se produire.

Ou encore un tableau de décision : chaque ligne correspond à un test et les colonnes sont les données d’entrée ou de sortie associées à ce test.

Nous avons vu qu’il est nécessaire de partager une vision globale et qu’il ne faut pas hésiter à changer la règle du jeu pour utiliser, par exemple un paper board.

J’ai bien apprécié cet atelier et envisage de mettre en pratique cette approche rapidement.

Product owner

J’ai choisi de participer au retour d’expérience Rôle du Product Owner et conception produit et non pas à l’atelier en parallèle Product Owner, qui es-tu, que fais-tu ? (comme je l’ai indiqué les choix n’étaient pas toujours faciles!).

J’ai trouvé le retour d’expérience intéressant : Le rôle du product owner doit avoir à la fois un profil marketing, mais également comprendre et anticiper les contraintes de l’équipe de développement (nécessite un background technique) tout en connaissant bien les règles de Scrum. Avec un Scrum master très expérimenté, le rôle du Product owner peut se limiter à donner des directives produits. Le Product owner doit s’impliquer dans le projet pour partager les succès et échecs. Il n’est pas forcément le client de son produit : il doit donc rencontrer et impliquer les utilisateurs du produit.

Dommage que cette session ait été écourtée (en raison d’un petit problème technique au début). J’aurais souhaité échanger par la suite sur ce sujet mais je n’en ai malheureusement pas eu l’occasion. Peut être lors d’une prochaine manifestation mais c’est un sujet qui me tient particulièrement à cœur. De mon point de vue, il est important que le couple « product owner / scrum master » fonctionne correctement. La frontière précise entre les 2 (notamment sur les aspects qui ne sont pas purement fonctionnels métier) dépend des compétences et expériences de chacun.

Le “Business Value Game”, trois itérations dans la peau du Product Owner

Il y avait beaucoup de monde pour cette session et j’ai seulement pu y participer en tant qu’observateur. Cet atelier était basé sur le jeu http://www.xp.be/businessvaluegame.html qui permet de se mettre dans le peau du Product owner pour essayer de maximiser la business value en prenant en compte différents facteurs (coût, vélocité de l’équipe, satisfaction client,…).

Cet atelier a été très bien animé et était intéressant. De ce fait, j’espère trouver l’occasion de le pratiquer lors d’une prochaine manifestation.

Présentation Agilité / retour d’expérience

La parabole du trafic urbain – l’Agilité expliquée autrement

Une présentation de très bonne qualité pour nous expliquer l’agilité en utilisant la métaphore du trafic urbain : les blocages locaux, saturations, diversité de véhicules, flux changeant, … Le feu rouge est un système commande & contrôle (approche classique) alors que le rond point est plus agile puisqu’il privilégie la communication (observe les autres), la simplicité (trafic d’un seul coté), ne privilégie aucun flux, met en avant le respect du conducteur et maximise le flux.

J’ai bien aimé le résumé qui en est fait sur le blog : http://www.touilleur-express.fr/2009/05/27/xp-day-france-2009-journee-1/

J’ai trouvé cette comparaison très intéressante à la fois pour présenter l’agilité de façon simple mais également pour voir les choses d’un autre œil. Lorsque j’observerai des points de blocage, j’essayerai de faire le parallèle et trouverai peut être la solution, en rentrant en voiture, bloqué dans les bouchons 😉

J’ai également participé à plusieurs présentations et retours d’expérience entre autre Chef, la recette et Legacy people : motivons les troupes !

L’agilité ne concerne pas que les aspects techniques. Elle concerne également la gestion de projet. Elle nécessite de procéder par étapes et de se donner des objectifs atteignables. Il est nécessaire de s’adapter aux personnes et faire les choses lorsque c’est pertinent. Il est important de mettre en avant les aspects humain, travailler sur la communication et valoriser les personnes.

J’apprécie les retours d’expériences. Il est toujours intéressant d’avoir d’autres points de vue et d’autres façons d’aborder les mêmes problématiques en fonction du contexte du projet.

Je partage avec vous quelques slides des XP days qui sont disponibles en ligne :

Conclusion :

J’ai bien apprécié de participer à ces XP days. J’espère avoir l’occasion d’y participer à nouveau l’année prochaine.

Ces manifestations sont l’occasion de suivre des présentations, de pratiquer et d’échanger avec d’autres personnes.

Je profite de ce post pour indiquer qu’il est également possible d’échanger régulièrement au sujet de l’agilité sur la région Rhône Alpes via le CARA. Vous trouverez toutes les informations sur http://www.clubagile.org