L’Agile Tour a fait une étape à Nantes le mercredi 14 octobre 2009.

L'Agile Tour (http://agiletour.com) a fait une étape à Nantes le mercredi 14 octobre 2009.

Le lycée Nicolas Appert a accueilli dans ses locaux environ 80 personnes (des développeurs, chefs de projet, DSI, MOA ...)

L'après midi s'est déroulée en plusieurs étapes.
Une première conférence était organisée pour présenter les divers acteurs de l'Agile Tour et les fondamentaux de l'agilité (méthode de génie logiciel itérative et collaborative).
Ensuite il a fallu faire des choix entre les conférences et les ateliers proposés car je ne possède malheureusement pas le don d'ubiquité et c'est bien dommage car le programme était plutôt alléchant :
3 conférences et 4 ateliers (entrecoupés de pauses pour profiter du buffet et échanger avec les participants).

Le programme était bien ficelé :

  • de 14h à 14h15 : Une introduction à l'agile tour et à l'agilité avec Laurent Morisseau (consultant) et Olivier Tabone (Directeur technique de chez Ripple Motion).
  • de 14H15 à 15h : Un retour d'expérience de Scrum chez Ripple Motion.
  • de 15h30 à 16h15 : Retour d'expérience Scrum/XP dans un contexte d'évaluation CMMI niveau 2 par Olivier Chotin, consultant CMMI chez Alcyonix et Yann Coste de chez Eurogiciel.
  • De 16h45 à 18h : Le développement hédoniste par Dominic Williams, directeur technique.
  • En paralléle un XP GAME de 14h15 à 16h15 par Laurent Morisseau formateur agile indépendant et Sébastien Fauvel consultant Pacte Novation.
  • Puis de 16h45 à 18h15 : un Test Driven Development par Eric Mignot, évangéliste des méthodes agiles.
  • D'un autre côté Arnaud Bailly, consultant OQube, présentait Java script et développement agile de 14h15 à 16h15.
  • Et pour finir Anne Dubedout, directeur de projets, Mc3si nous a présenté un atelier sur la Maitrise des coûts d'un projet agile.

Alors L'agilité ?

Nous connaissons tous assez bien les méthodes en cascade avec le cycle en V ou le cycle en W.
Ce sont des méthodes dites prédictives:

  • Nous avons une hypothèse de base,
  • Nous maitrisons ce que nous voulons et nous nous engageons à le réaliser.

Cycle en V

Mais il existe une autre méthode dite empirique:
Nous faisons l'hypothèse de base que ne nous ne maîtrisons pas ce que nous allons faire
et nous allons essayer d'avancer avec l'incertitude.
Pour réaliser cela, il y a 3 piliers fondamentaux :

  1. la transparence (avoir les informations).
  2. inspection (inspecter les indicateurs).
  3. Adaptation (améliorer, réorienter).

Pour appliquer ces principes plusieurs méthodes sont possibles : source (http://www.agileproductdesign.com/blog/dont_know_what_i_want.html)

  • itérative

méthode iterative ou incrémentale

  • incrémentale

méthode iterative ou incrémentale

  • approche mixte

Les Valeurs de l'agilité : source Wikipedia( http://fr.wikipedia.org/wiki/Méthode_agile )

4 valeurs fondamentales (les citations du manifeste sont indiquées entre parenthèses) :

  • L'équipe (« Personnes et interaction plutôt que processus et outils ») : Dans l'optique agile, l'équipe est bien plus importante que les outils (structurants ou de contrôle) ou les procédures de fonctionnement. Il est préférable d'avoir une équipe soudée et qui communique, composée de développeurs (éventuellement à niveaux variables) plutôt qu'une équipe composée d'experts fonctionnant chacun de manière isolée. La communication est une notion fondamentale.
  • L'application (« Logiciel fonctionnel plutôt que documentation complète ») : Il est vital que l'application fonctionne. Le reste, et notamment la documentation technique, est une aide précieuse mais non un but en soi. Une documentation précise est utile comme moyen de communication. La documentation représente une charge de travail importante, mais peut pourtant être néfaste si elle n'est pas à jour. Il est préférable de commenter abondamment le code lui-même, et surtout de transférer les compétences au sein de l'équipe (on en revient à l'importance de la communication).
  • La collaboration (« Collaboration avec le client plutôt que négociation de contrat ») : Le client doit être impliqué dans le développement. On ne peut se contenter de négocier un contrat au début du projet, puis de négliger les demandes du client. Le client doit collaborer avec l'équipe et fournir un feed-back continu sur l'adaptation du logiciel à ses attentes.
  • L'acceptation du changement (« Réagir au changement plutôt que suivre un plan ») : La planification initiale et la structure du logiciel doivent être flexibles afin de permettre l'évolution de la demande du client tout au long du projet. Les premières releases du logiciel vont souvent provoquer des demandes d'évolution.

Principes

Ces 4 valeurs se déclinent en 12 principes généraux communs à toutes les méthodes agiles :

  • « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles ».
  • « Le changement est bienvenu, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client ».
  • « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte ».
  • « Les gens de l'art et les développeurs doivent collaborer quotidiennement au projet ».
  • « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail ».
  • « La méthode la plus efficace pour transmettre l'information est une conversation en face à face ».
  • « Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet ».
  • « Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».
  • « Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité ».
  • « La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle ».
  • « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent ».
  • « À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens ».

Une méthode qui réunit ces différents concepts : SCRUM http://fr.wikipedia.org/wiki/Scrum

Schéma source :

Scrum

Les différents a priori sur l'agilité :

  • L'agilité est simple
    • peu de pratiques
    • pratiques faciles
    • peu de risque à essayer.
  • L'agilité est difficile
    • implication et bon sens.
    • constante inspection et adaptation à la réalité
    • culture et contextualité
  • L'agilité est subtile
    • pratiques interdépendantes

Finalement on peut dire que l'agilité :

C'est transformer quelque chose de technique en quelque chose de plus beau, une belle œuvre comme une partition de musique.

J'ai choisi ensuite de participer à l'atelier XP Game :

Voici une description rapide de ce jeu source: (http://agiletour.com)

Résumé
Expérimentez trois itérations au sein d'une équipe agile qui "implémente" des histoires d'utilisateurs.
La meilleure équipe sera celle ayant créé le maximum de valeur.
Alors quelle sera la meilleure stratégie d'estimation? de priorisation?
Audience
Cette session est destinée à tous les acteurs du développement logiciel souhaitant s'initier au développement Agile.
Bénéfices
Apprenez les pratiques d'une équipe agile et comment les différents rôles dans l'équipe collaborent pour ajouter de la valeur.
Clarifier l'estimation et la planification agile.
Format
Atelier d’1h30, véritable classique des ateliers XP.
Programme

  • Explication des concepts et du jeu – 10’
  • Organiser les équipes – 5’
  • Itération 1 – 20’
  • Rétrospective itération 1 et introduction de la vélocité 8’
  • Itération 2 – 13’
  • Rétrospective itération 2 8’
  • Itération 3 - 11’
  • Débriefing final – 15’

25 participants se retrouvent autour de plusieurs tables.
Laurent nous explique le concept du jeu. Le but de celui ci est de voir des notions de xstreme programming,

  • de donner une priorité aux tâches,
  • de gérer la vélocité,
  • et la productivité de l'équipe.

Nous somme une équipe de 5 personnes et nous allons avoir plusieurs tickets à gérer.
Ces tickets ont une vélocité et une valeur métier.
Chaque itération dure 3 minutes (c'est très court !!!! 😉 ).
Le but est que l'équipe réalise un maximum de valeur métier.

Le premier défi est de lire chaque ticket et d'estimer en combien de temps on peut le réaliser de 10 secondes à 60 secondes ou si cela est impossible dans le temps imparti.
Il faut alors discuter avec mes nouveaux collègues et se mettre d'accord sur le temps pour chaque ticket.
Dans un second temps nous donnons une priorité aux tâches et nous nous engageons sur notre réalisation.

Les tickets sont variés voici quelques exemples :

  • Gonfler 5 ballons de 40 cm de diamètre.
  • Trier un jeu de 54 cartes.
  • Faire un château de carte à 4 étages.
  • Lancer 2 dés et faire au moins cinq 6.
  • Faire un bateau avec une feuille de papier.

Nous décidons alors de nous engager sur un gonflage de ballon pour 300 Valeurs puis de trier des cartes pour 300 Valeurs.
Les dés valent 500 valeurs mais comportent un risque alors nous préférons les mettre de côté.

Le sprint démarre et chacun prend son ballon. Nous avions prévu 30 secondes pour cette tâche.
Il faut ensuite faire valider par le client nos 5 ballons. Celui-ci nous dit : " Vous avez gonflé des ballons de différentes couleurs or je les voulais tous de la même couleur".
L'équipe discute avec lui mais il ne veut rien savoir, le temps passe et nous courrons chercher d'autres ballons, finalement nous aurons le temps de faire que ce ticket.

Toutes les autres tâches n'ont pas pu être réalisées.
Nous n'avons pas tenu nos engagements et finalement nous ne réalisons que 30 secondes et une valeur de 300 alors que l'équipe s'était engagé à 150 secondes et plus de 800 en valeur.
Le premier sprint démarre mal.

L'équipe reçoit à nouveau des tickets pour le second sprint.
Cette fois ci nous apprenons de nos erreurs et nous décidons de faire des tickets plus sûrs comme trier les cartes.
Nous revoyons aussi nos temps à la hausse.
Finalement l'équipe s'engage sur un peu moins de valeur.
Le sprint redémarre et c'est mieux nous réalisons 3 tâches et presque 4 avec une valeur de 700. en 120 secondes

Nous avons appris de nos erreurs nous avons changé nos pratique et finalement tout le monde est gagnant.

3ème sprint : de nouveaux tickets entrent en jeu.
On s'organise encore mieux lors de la transition entre les tickets pour gagner du temps afin de les faire valider par le client.
Finalement en 120 secondes comme le sprint précédent on réalise 1100 en valeur.

Bilan : de la dernière place lors du premier sprint on prend la tête du jeu.

Ensuite on entame une discussion sur les différentes pratiques de l'XP Programming et des méthodes SCRUMS.

Ce jeu nous a permis de voir les différentes techniques de l'agilité ainsi que la remise en question de nos pratiques pour pouvoir améliorer notre productivité
et apprendre de nos sprints précédents.
Ce fut vraiment un XP Game très intéressant.

J'ai ensuite participer à l'atelier sur la maîtrise des coûts d'un projet agile.
L'assemblée de cet atelier était très différente. Il y avait moins de développeur et plus de MOA ou de décideurs.
Les questions sur les méthodes agiles étaient nombreuses et on notait vraiment leur attachement au cycle en V.
Anne Dubedout, directeur de projets chez Mc3si nous a présenté les avantages et les inconvénients d'un cycle en V.

Les principaux avantages sont :

Les principaux inconvénients :

  • spécifications obsolètes
  • ne prends pas bien en compte le changement.
  • pics de charge à absorber -> surcoût
  • effet tunnel.

Puis ceux de la méthode SCRUM :

  • Produire la plus grande valeur métier dans un minimum de temps.
  • Un produit qui fonctionne est livré toutes les 2 à 4 semaines.
  • Les besoins métiers sont définis progressivement -> réactivité au changement.
  • Réhabiliter l'oral par rapport à l'écrit.
  • Une collaboration directe plutôt qu'un échange de livrables.

Ensuite tous les participants ont listés les risques:

  • architecture cible instable
  • refactoring = surcoût
  • Pas de trace des besoins
  • instabilité de l'équipe
  • engagement

Personnellement je ne suis pas forcément d'accord avec les différents points notamment au niveau de l'engagement qui pour moi est un des piliers des méthodes agiles.
Je pense que la plupart des participants a mis l'engagement dans les risques car ils imaginent que nous travaillons dans le flou sans avoir toutes les spécifications écrites à l'avance.
Idem pour le refactoring. Pour ma part, je pense que faire du refactor au fur et à mesure diminue les coûts, surtout au niveau de la maintenance de l'application et de la gestion des bugs.
Pour eux, s'il y a un échange verbale il n'y a pas de trace du besoin. Je pense, au contraire, qu'on gagne du temps en discutant ensemble du besoin. Et, lorsque tout le monde est d'accord on peut alors donner son engagement.

Au sujet de l'instabilité de l'équipe, ils pensent qu'il faut avoir la même équipe sur le projet. Or, une équipe agile a justement l'habitude de s'adapter plus rapidement. Sur un plateau technique, si on travaille quotidiennement sur des projets différents ou sur des modules différents dans un même projet nous aurons plus facilement l'habitude de basculer d'un projet à l'autre ou d'une technologie à l'autre. Ainsi, le fait que l'équipe tourne posera peu de problèmes.

Nous avons ensuite participer au jeu du bistrot.

Par binôme : une personne joue le rôle du client et l'autre celui du restaurateur. Nous devions établir un menu ensemble.
Sachant que le client pouvait avoir un budget limité ou illimité et avait des recommandations de son médecin pour éviter de manger certains aliments.

A la fin de cet exercice il fallait noter sur un post-it le menu proposé et son prix.
Nous nous rendons alors compte qu'avec un budget illimité et sans recommandation nous pouvons vraiment faire n'importe quoi.
Avec un budget et des recommandations on sait déjà plus ou l'on va. On doit faire certains choix.

Ce jeu permet de mettre en parallèle les différentes approches du cycle en V et de SCRUM.
Avec la méthode SCRUM tout se négocie, c'est la négociation qui donne son engagement.
Le budget est contraint pour maitriser les coûts.
La négociation se réalise lors du sprint planning.
Le product owner (en général la MOA) présente ses besoins.
Une négociation à l'oral a lieu.
Ensuite un accord et un engagement sont pris pour la prochaine itération.
On maximise le R.O.I. (Return On Investment),
La M.O.A. maitrise et pilote le budget.
Plusieurs outils sont mis à disposition pour nous aider à construire notre projet.

  • Négociation
  • Budget
  • scrum meeting: réunion quotidienne avec le product owner c'est mieux.
  • burn up (avancement du projet en valeur métier)
  • burn down de l'itération ou Reste à faire fait par la MOE.
  • backlog maj par le product owner.
  • démonstration du produit à la fin des itérations.
  • restrospections Amelioration continue.

Pour finir la journée, nous sommes invités à un pot ou l'échange est fort agréable.

Je remercie l'équipe de l'Agile Tour pour cet événement qui fut, je pense, un succès.

J'aurai aimé participé à plus d'ateliers.
J'ai appris aussi qu'il y avait comme le JUG de Nantes(java user Group de nantes)
une association qui se réunissait tous les mois pour parler de l'agilité http://groups.google.com/group/agilenantes.

Pour conclure je pense que nous pouvons améliorer nos pratiques agiles. Il y a de bonnes idées à reprendre pour les utiliser au quotidien.
Les MOA sont encore assez réticentes à passer au méthodes agiles. La culture du cycle en V est encore bien ancrée, pourtant les personnes semblent intéressées par
ces nouvelles techniques.
Il faut les rassurer et leur expliquer ce que l'agilité apportera à leur projet.
Personnellement je trouve qu'une fois qu'on a gouté à l'agilité c'est très dur de revenir en arrière 😉

L'agilité est aussi à la mode au JUG de Nantes puisque c'est le sujet de la prochaine réunion. Alors venez nombreux. http://www.nantesjug.org/

2 commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.