IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Compte rendu de l'Agile Tour 2008

Date de publication : 12/11/2008 , Date de mise à jour : 18/11/2008

Par Hervé Delannoy
 Rémy Sanlaville
 Bruno Orsier (autres articles) (Blog)
 Philippe Leménager
 TheLeadingEdge
 Ashgenesis (autres articles)
 Emmanuel Hugonnet (Blog)
 Aline Paponaud (Blog)
 Alexandre Boutin (Blog)
 Eric Lefèvre (Blog)
 Emmanuel Etasse (Blog)
 Emmanuel Chenu (Blog)
 Laurent Farcy (Blog)
 

Avec 7 étapes à travers la France et la Suisse, l'Agile Tour 2008 a parcouru le territoire pour parler Agilité avec les acteurs locaux pendant tout le mois d'octobre. Les organisateurs (Patrice Petit, Eric Lefevre, et Ramiro Sarmiento) ont fait preuve d'agilité en concrétisant leur volonté d'aller à la rencontre des régions plutôt que d'organiser un évènement central dans la capitale.

            

1. Introduction
1.1. Qu'est-ce que l'Agile Tour
1.2. Le public
2. Etape Lilloise du 14 octobre
2.1. Intégration continue & offshore (Thomas Recloux), commenté par Hervé Delannoy
2.1.1. Une pratique courante : la division
2.1.2. Des contacts et du partage pour améliorer la qualité
2.1.3. Trois conseils et exemples pratiques
2.1.4. Quatre étapes pour mettre en place l'intégration continue
2.2. Spécifications exécutables avec GreenPepper (Eric Mignot & Laurent Cobos), commenté par Hervé Delannoy
2.3. Les pratiques d'ingéniérie incrémentale (Eric Mignot & Laurent Cobos), commenté par Ashgenesis
2.4. Le Dojo Randori, commenté par Ashgenesis
2.5. Les projets Agile - de la réponse aux appels d'offres à la maintenance - retour d'expérience (Oana Juncu), commenté par Ashgenesis
4. Etape Toulousaine du 16 octobre
4.1. Impressions de Philippe Leménager
4.2. Les présentations (en format PDF)
5. Etape Grenobloise du 9 octobre
5.1. Introduction et Keynote
5.1.1. Commenté par Eric Lefevre
5.1.2. Commenté par Aline Paponaud
5.1.3. Commenté par Laurent Farcy
5.2. Introduction à Scrum (Eric Lefevre)
5.2.1. La session, par son auteur
5.2.2. La session, commentée par Aline Paponaud
5.3. Retour d'expérience - implémentation Scrum / XP (Bruno Orsier)
5.3.1. La session, par son auteur
5.3.1.1. Introduction
5.3.1.2. Sondage
5.3.1.3. Question 1 (bénéfices des méthodes agiles)
5.3.1.4. Question 2 (intérêt des diverses pratiques)
5.3.1.5. Conclusion
5.3.2. La session commentée par Eric Lefevre
5.4. Aspects Psychologiques des méthodes Agiles (Ramiro Sarmiento), commenté par Aline Paponaud
5.5. Mise en place d'outils pour industrialiser le développement (Emmanuel Hugonnet, Rémy Sanlaville)
5.5.1. La session, par ses auteurs
5.5.1.1. Introduction
5.5.1.2. Le Build
5.5.1.3. L'Intégration Continue
5.5.1.4. Retour Projets
5.5.1.5. Bilan et Perspectives
5.5.2. Commenté par Aline Paponaud
5.6. Agilité et avionique (Emmanuel Chenu)
5.7. Senteurs Agiles (T. Lissajoux), commenté par Emmanuel Hugonnet
5.8. Architecture Agile chez Yahoo!/Kelkoo (Arnaud Delafosse), commenté par Eric Lefevre
5.9. eXtreme Programming - Retour d'expérience après 6 années de pratiques (J-M. Voisin), commentée par Emmanuel Hugonnet
5.10. Développement Web Agile avec Ruby on Rails (G. Karékinian), commentée par Laurent Farcy
6. Etape Valentinoise du 23 octobre
6.1. Atelier « Artistes et Specifieurs » (Gery Derbier)
6.2. Agile Dojo : L'art de grandir en équipe (Ramiro Sarmiento), commenté par Bruno Orsier
6.3. Retour d'expérience YAHOO International (Alexandre Boutin)
6.3.1. La session, par son auteur
6.3.2. Commenté par Emmanuel Etasse
6.3.3. Commenté par Emmanuel Chenu
6.4. Le refactoring (Régis Medina)
6.5. La méthode Crystal (Gery Derbier)
6.5.1. Commenté par Alexandre Boutin
6.5.2. Commenté par Emmanuel Etasse
6.5.3. Commenté par Bruno Orsier
6.6. Forums ouverts
7. Conclusion et remerciements
8. Liens


1. Introduction


1.1. Qu'est-ce que l'Agile Tour

L'Agile Tour est une suite d'événements Gratuits répartis sur plusieurs villes européennes pendant tout le mois d'octobre 2008. L'édition 2008 est organisée sur 7 conférences réparties en France et en Suisse. Ces 7 conférences se sont déroulées en plusieurs temps :

  • 01 octobre : Besançon
  • 03 octobre : Mulhouse
  • 06 octobre : Genève
  • 09 octobre : Grenoble
  • 14 octobre : Lille
  • 16 octobre : Toulouse
  • 23 octobre : Valence
Son objectif étant de décentraliser les séminaires agiles de Paris vers les autres régions industrielles afin de promouvoir l'agilité, de la populariser, de la soutenir et d'inciter le développement de la culture de l'Agilité.


1.2. Le public

Le sondage mis en place par les organisateurs a eu un succès relatif avec (à l'heure de la publication) 167 votes (il est encore temps de participer).
Voici un résumé des résultats :

A quel stade en êtes vous dans l'adoption de l'approche agile dans votre entreprise ?
  • Pas connue : 20%
  • Pas d'utilisation : 12%
  • En cours d'analyse : 15%
  • Analysée et Rejetée : 1%
  • Projets Pilotes : 5%
  • Mise en Oeuvre Partielle (Utilisation de certaines techniques agiles) : 25%
  • Adoption Partielle (Certains projets utilisent ces méthodes) : 11%
  • Adoption Totale (Tous les nouveaux projets utilisent ces méthodes) : 11%
Un public relativement hétérogène donc.


2. Etape Lilloise du 14 octobre

L'Agile Tour fait étape à Lille le 14 octobre, dans les locaux de Telecom Lille1, sur le campus de l'USTL de Villeneuve d'ascq.
Les 11 conférences & ateliers ont été répartis parmi les trois salles selon un vote préliminaire des participants : sur un grand tableau blanc, chaque participant a collé une gommette en face du nom des conférence qu'il souhaitait voir.

L'organisation n'était donc pas fixée à l'avance, et le planning s'est construit pour maximiser la satisfaction du public, pendant que nous assistions à la présentation de l'Agile Tour dans sa globalité. De cette présentation est ressortie la volonté de décentralisation (l'Agile Tour ne fait pas étape à Paris volontairement), l'envie de dynamiser les initiatives locales, et celle de proposer une organisation suivants les préceptes agiles.
Les conférences se sont ensuite enchaînées avec une ponctualité à toute épreuve.

Néanmoins, des désistements parmi les orateurs ont causé de nombreux remaniements dans liste des sessions proposées.


2.1. Intégration continue & offshore (Thomas Recloux), commenté par Hervé Delannoy

L'objectif : améliorer les projets utilisant l'offshore


2.1.1. Une pratique courante : la division

Une des organisations traditionnelles pour un projet en offshore est une équipe Analyse/Conception en local, et le développement est délocalisé. Cette organisation s'oppose au principe agile de favoriser les contacts humains. Une fracture se produit ainsi entre le client et les développeurs, et une seconde fracture s'installe entre le tandem Analyse/Conception et les développeurs. Elle n'est pas adaptée à des cycles incrémentaux et itératifs : la réalisation se déroule en cascade, avec en premier l'analyse, puis la conception et enfin le développement. D'autre part, cela entraîne généralement des débats longs et coûteux autour des dossiers.

Une autre organisation parfois rencontrée est une équipe complète en local, et une équipe de développeurs distants, en support. Cette manière de faire pose de gros problèmes à l'équipe distante : elle ne voit (presque) jamais le client, il est nécessaire de réexpliquer les dossiers, les contacts sont généralement limités. Cela génère au final des livrables de moins bonne qualité, parfois inadaptés au besoin, induit des délais plus longs, et peut donner un sentiment d'isolement et donc de désimplication à l'équipe distante.


2.1.2. Des contacts et du partage pour améliorer la qualité

Une des solutions possible serait, non pas de faire deux équipes (une locale et une distante), mais une unique dont certains membres sont éloignés.
Cela ressemble à un mauvais jeu sur les mots, mais les différences sont précises : les engagements de travail, de délais sont identiques pour tous les membres, les membres éloignés ne sont pas toujours les mêmes, les livrables et livraisons sont partagés.


2.1.3. Trois conseils et exemples pratiques

Tout d'abord, favoriser les rencontres physiques, dans les deux sens. Faire venir les membres distants durant la première itération permet d'établir un contact et améliorer les communications suivantes. Durant les itérations suivantes, instaurer un roulement afin que les membres éloignés ne soient pas toujours les mêmes (autant parmi les développeurs, que parmi les analystes, concepteurs, chefs, testeurs....) casse le sentiment d'isolement, permet de faciliter les compréhensions fonctionnelles et améliore les retours.

Investir dans la communication est essentiel pour garantir un bon feedback et une bonne transmission des informations. Rien n'est de trop : téléphone, visioconférence, messagerie instantanée, tableau blanc virtuel (pendant électronique du grand tableau couvert de notes, indispensable dans un projet agile). Des réunions en équipe complète sont elles aussi très importantes. Une par itération semble une bonne fréquence, lors des réunions charnières inter-itérations.

Instaurer l'intégration continue assure la propriété collective du code, et permet de toujours proposer une application testable en permanence. A terme, les coûts et les délais s'en trouvent réduits.


2.1.4. Quatre étapes pour mettre en place l'intégration continue

La mise en place d'un contrôle de code source unique pour tous les membres de l'équipe est la toute première chose à faire. Il ne faut pas le considérer comme un outil de sauvegarde, mais bien un outil de publication de son travail. Idéalement fonctionnant en mode déconnecté, il permet à tous de travailler en tout temps sur chaque fichier. On peut notamment citer SVN et TeamFoundationServer en mode connecté, et Mercurial en mode déconnecté.

Vient ensuite l'ajout d'un référentiel des demandes client. Pour garantir un suivi parfait, ce référentiel de demandes doit se lier au contrôle de code source afin de repérer quelle demande a occasionné quelle modification du code, et inversement. Trac est un trés bon exemple d'outil permettant de définir des jalons, de poser des demandes, et de relier des taches au code y répondant. Il s'intègre à SVN notamment.

Afin d'améliorer la productivité et de se focaliser sur la valeur ajoutée (au sens agile du terme, soit les fonctionnalités livrées et utiles), il est conseillé d'automatiser le plus possible tout ce qui a une faible valeur ajoutée. Par exemple, l'automatisation de la compilation et du déploiement n'est pas évidente dans tous les projets. Peut venir ensuite la génération du code technique et le lancement automatisé de batteries de tests. Maven est l'un des outils qui permet de faire tout cela en une opération.

Un automate d'intégration continue comme Continuum vient parfaire cette panoplie d'outils. Proche de Maven, il surveille le contrôleur de code source, lance des compilations / tests / déploiements chez le client de manière automatique et publie les résultats. Avec l'intégration continue s'installe une dynamique dans l'équipe, sous forme de jeu (un gage au premier qui empêchera la publication automatique, durer le plus de temps avant qu'elle n'échoue...)


2.2. Spécifications exécutables avec GreenPepper (Eric Mignot & Laurent Cobos), commenté par Hervé Delannoy

On parle souvent de tests unitaires, parfois automatisés. Mais quid des tests fonctionnels ? Généralement, ces spécifications sont répertoriées dans un CDCF, une expression des besoins, un document pas toujours électronique et en langage naturel.

A l'autre bout de la chaîne, les testeurs établissent des scénarri de test, pas forcément en adéquation pour diverses raisons (erreurs, incompréhensions...).

Au milieu, les développeurs, qui doivent jongler entre les deux en comblant les lacunes potentielles dues au langage naturel.
L'objectif des spécifications fonctionnelles exécutables est triple : être non ambigües, parfaitement lisibles par un analyste et se vérifier très rapidement.

Ces spécifications s'intègrent parfaitement dans une optique TDD, en plus des tests unitaires. Elles s'écrivent en binôme voire trinôme (testeur/analyste/développeur). L'analyste exprime le besoin, les seuils ; le testeur construit le scénario ; et le développeur les traduit dans l'outil, de manière très visuelle et lisible (présentation sous forme de tableau ou de wiki dans GreenPepper).

Dans la foulée, le développeur code ce que l'on peut appeler Fixture. Cette fixture est un pont entre GreenPepper et le code de production. Ce sont les fonctions de la fixture qui seront appelées par GreenPepper, elles encapsulent les appels au modèle objet mis en production, et indiquent si tout c'est bien déroulé. Ainsi, l'outil est en mesure de lancer toute une batterie de tests afin de valider les diverses règles et scénarii spécifiés.

Une fois que tous les tests sont validés, on peut considérer que le coeur de l'application est terminé (il reste les tests ergonomiques à valider).
Tout cela peut intervenir dans une optique d'intégration continue et favorise les contacts analyste/développeur et analyste/testeur.


2.3. Les pratiques d'ingéniérie incrémentale (Eric Mignot & Laurent Cobos), commenté par Ashgenesis

Les approches agiles nous proposent d'adopter une approche incrémentale dans la construction de nos logiciels ; de réfléchir à notre définition de "terminé" et d'étendre progressivement cette définition. Le besoin d'évolution de nos pratiques se fait alors vite sentir : que deviennent les longues phases de modélisation ? De recette ? Les livres nous demandent d'atteindre la qualité production dans chaque itération. Cela demande parfois beaucoup de changement. Quelles sont les pratiques rapidement adoptables ? Comment intégrer cette amélioration continue en cours de projet ?

Cette session s'est déroulée aussi de manière participative où tout le monde avait son mot à dire. Un partage d'expérience très fructueux sur les différents points de vues du Pair-Programming (Programmation à 2, ou appelé aussi binôme). Cette pratique a été débattue pendant toute la séance. Sur les avantages et inconvénients de la pratique comme la question de rentabilité, le fait de "bloquer" deux développeurs sur la même machine divise-t-on alors le rendement de production par deux. La qualité du code et la facilité de compréhension par le binôme qui finalement ne fait plus qu'une seule et même entité. La compatibilité entre les 2 développeurs composant ce binôme est-elle importante.

La question principale qui est revenue assez souvent était le fait que de bloquer deux développeurs sur une seule machine ne favorisait pas le rendement de l'entreprise pratiquant cette méthode. En fait la vision est toute autre le pair programming permet de développer plus rapidement car les bugs sont assez souvent et rapidement corrigés avant mêmes qu'ils ne se produisent du à la complicité des développeurs. Ainsi la qualité du code étant améliorée, il y a moins de "pertes de temps" à corriger les bugs du programme. La facilité de compréhension d'un code nouveau est aussi évidente deux cerveaux en concert laissent moins facilement la place à des oublis et ainsi il y a vraiment une amélioration de compréhension à ce niveau là. Le code ainsi produit est un code de qualité car doublement réfléchis.


2.4. Le Dojo Randori, commenté par Ashgenesis

Je n'ai malheureusement pas pu participer à cet atelier mais je vais faire une brève introduction sur le dojo de programmation Un dojo de programmation est identique à un dojo d'arts martiaux à la différence près qu'on pratique l'art de la programmation. Ce concept a été initié en France par, entre autres, Laurent Bossavit et Patrice Petit. Son but étant de progresser, d'apprendre, et de partager ses connaissances avec les différents participants, qui peuvent être de tous niveaux, à l'aide des principes et des méthodes de l'eXtreme Programming.

Le dojo se pratique de deux façons différentes en Randori ou en Kata. Le randori permet à tous les membres de pratiquer alors que le kata ressemble plus à un cours magistral. Le dojo commence par un tour de table où chacun propose un sujet en expliquant un peu le contenu du problème et la manière dont il souhaiterais le réaliser (en mode Kata ou Randori). Une fois les sujets évoqué un vote est fait et le problème intéressant la majorité est retenu.

  • Le mode kata est assez simple une personne ou un binôme conçoive le programme sous le regard averti des autres participants qui peuvent interagir avec la personne effectuant le kata.
  • Le mode randori oblige tous les intervenants à participer à la création du programme chacun prend à tour de rôle le clavier et la souris et endosse le rôle de développeur les autres continuant leurs réflexions et commentaires sur le code si nécessaire.
Le développement est piloté par Test Unitaire. C'est à dire, pour un randori, qu'au tour de chacun, le participant doit écrire la partie de code qui fait passer le Test Unitaire et écrire un test afin de passer le clavier à son voisin dans les mêmes conditions qu'il l'a reçu. Après 1h45 de développement, on passe à la phase de débriefing où l'on discute des difficultés rencontrées, de l'intérêt du sujet et des conclusions à en tirer. Je tiens à remercier Perrick Penet pour m'avoir fait découvrir cette pratique.


2.5. Les projets Agile - de la réponse aux appels d'offres à la maintenance - retour d'expérience (Oana Juncu), commenté par Ashgenesis

Les sujets liés à cette problématique sont :

  • Réponse aux appels d'offre : Comment qualifier l'opportunité de réponse en Agile? Définir l'argumentaire
  • Contractualisation : Mais quels sont les engagements à prendre ?
  • L'initialisation du projet : le piège à éviter: Ca y est, on se lance dans le développement !
  • Les jalons du sprint : (bilan, planning game, rétrospectives) toutes les raisons de les éluder sont mauvaises.
  • L'amélioration continue : La régulation de la vélocité, le contrôle de la qualité du code, la dynamique de l'équipe, la rétrospective.
  • La mise en production : des tâches incontournables à exécuter.
  • La maintenance : quel sens dans un projet AGILE? Comment gérer les priorités de la productions sans contourner l'esprit de l'Agilité ?
Cette session était plutôt sur le type conférence qu'atelier participatif. L'oratrice présentant un retour d'expérience sur les différentes étapes d'un projet du début à la fin de façon Agile. Pour tous projets les contraintes sont assez similaires :

  • Respecter le budget
  • Définir l'ensemble d'un périmètre
  • Positionnement inattendu
  • La pression d'un résultat dans un environnement externe
  • Réputé complexe et mouvant
  • Quelles garanties
Afin de respecter toutes ces contraintes, il faut éviter les pièges :

  • Concevoir tout en même temps, car on s'adaptera en cours de route
  • Ne pas mettre en place de modélisation/conception car c'est "development driver"
  • On démarre avec ce que l'on a aujourd'hui, on est pressé, car c'est pour ça que l'on a choisi le développement agile
  • Le niveau technique de l'équipe est bon, c'est le principal
Comment peut-on faire?
Bien définir ces objectifs, fiabiliser le backlog, constituer l'équipe en rapport avec le projet et la compatibilité des développeurs entre eux. La première itération (ou sprint suivant si on utilise l'eXtreme Programming ou Scrum), le sprint 0 donc, est incontournable et cela permet à l'équipe de se familiariser avec le projet et ainsi de réguler la vélocité (fr La vélocité n'est pas une mesure de productivité) de l'équipe.

Le sprint 1 devient fiable suivant les résultat du premier sprint. Ce qu'il faut garder en tête c'est la constance des paramètres d'un sprint, sa durée (une durée assez courant est entre 1 et 2 semaines), pas d'échange standard de stories d'un sprint, l'abandon d'une storie dans un sprint est toléré mais il ne doit pas y avoir de remplacement : l'équipe ayant effectué le planning game porte le sprint.
La souplesse de la maille via des maillons forts, la fin d'un sprint doit avoir ses stories finies, la vélocité se régule naturellement, on aperçoit aussi une amélioration continue au fur et à mesure des sprints, l'utilisation du Pair Programming aide aussi au développement du projet.
La mise en prod se fait après minimum 3 sprints, elle aura été définie dans le backlog.
Il faut adapter le rythme itératif avec la méthode de planification.
Lors d'un sprint, il est important de penser à la gestion du support de prod.
La maintenance est le moyen de stabiliser un outil.


4. Etape Toulousaine du 16 octobre


4.1. Impressions de Philippe Leménager

J'ai assisté à l'étape toulousaine en tant que novice complet : je ne connaissais pas du tout les méthodes agiles et j'y allais 'pour voir'.
J'ai été intéressé par la présentation de Scrum et du logiciel open source développé à l'université de Toulouse : iceScrum.

En tant qu'ancien responsable qualité (pas dans l'informatique) j'ai retrouvé dans cette conférence des méthodes de management de la qualité :

  • La roue de Deming de la qualité (Plan, Do, Check, Act) se déploie ici dans les sprints à coups de Develop, Wrap, Review, Adjust mais le principe est le même : l'amélioration continue
  • Un intervenant a dit qu'il fallait prendre les modifications comme une chance. La maîtrise des modifications est un élément important des démarches qualité et de la norme ISO 9001
  • Un intervenant venu du Canada (Philippe Kruchten, très applaudi) a également parlé des difficultés à la mise en place des méthodes agiles, et notamment des 'excuses piscine' qui empêchent le lancement de la démarche : "Oui mais chez nous ce n'est pas possible parce que...". Le qualiticien se bat au quotidien contre ce genre de comportement
Au cours de cette conférence, l'accent a été porté également sur l'importance de tenir compte du contexte pour mettre en œuvre les méthodes Agile. Les pratiques seront différentes selon le nombre de personnes impliquées, les relations avec le client, le regroupement de l'équipe au sein d'un même lieu ou non...

Ainsi, le coeur de cible des méthodes Agiles est :
  • Une équipe de 5 à 12 personnes ;
  • Regroupée sur un seul site ;
  • À temps plein ;
  • Travaillant sur des systèmes interactifs ;
  • À architecture logicielle définie ;
  • Pour un projet à criticité faible ou modérée (si ça plante, ça tue des gens ou ça gène seulement quelques personnes temporairement ?) ;
  • Avec un management accommodant ;
  • Pour des nouveaux développements.
Si l'on n'est pas dans le coeur de cible, les méthodes agiles restent applicables à condition de :
  • connaître son environnement d'organisation ;
  • analyser le contexte spécifique du projet ;
  • sélectionner et adapter les pratiques selon ce contexte ;
  • établir un plan d'adoption des pratiques; le suivre et l'ajuster au cours du projet.
Un détail pour finir : l'amphi mis à disposition était archi-plein !


4.2. Les présentations (en format PDF)

Liste des présentations disponibles (PDF)

5. Etape Grenobloise du 9 octobre

Ce sont Alexandre Boutin et Patrice Petit qui ont accueilli les participants dans l'amphi nord de l'université de physique, sur le campus de Saint Martin d'Hères, pour cette étape organisée par le Club Agile Rhône-Alpes (CARA).

Cette étape fût un vrai succès du fait de tous les retours positifs reçus des participants.
Les 201 personnes présentes (soit 2 fois plus que l'objectif initial) ont plébiscité l'invité d'honneur qui a vraiment lancé la conférence sur de très bons rails (excellente prestation de Jérôme Barrand) puis se sont naturellement répartis dans les autres salles pour écouter les différents orateurs qui ont été globalement très appréciés.

Les craintes des organisateurs sur la gestion de l'accueil, la répartition entre les salles et le timing de l'évènement ne se sont pas transformées en problèmes, et les buffets gratuits, pause café et dînatoire, ont été appréciés par tous.


5.1. Introduction et Keynote


5.1.1. Commenté par Eric Lefevre

Après l'introduction par Alexandre (Boutin), nous avons eu droit à une bonne keynote par Jérôme Barrand que je ne connaissais pas, de l'Ecole de Management de Grenoble. Il semble avoir eu une réflexion parallèle à celle des Poppendieck et est tombé sur les mêmes conclusions, mais sans parler spécifiquement du domaine de l'informatique. En tout cas, il parle de Management Agile. Un bon orateur aussi.

Quelques extraits :
  • l'agilité, c'est gérer les ruptures en les anticipant
  • Tarzan est agile car c'est un roi de la jungle non imposé qui sait gérer les ruptures de lianes
  • dans les 30 glorieuses on vendait des objets avec des techniques "toutes choses étant égales par ailleurs", c'est à dire qu'on ne se préoccupait pas du devenir de l'objet ou de la satisfaction profonde du client. Maintenant, on vend du relationnel.
Il a conclu avec 8 principes et 6 attitudes qui ne choqueront pas les connaisseurs de Lean.


5.1.2. Commenté par Aline Paponaud

D'après Jérôme Barrand, l'entreprise et son système d'information, grâce aux informaticiens, c'est devenu un gros truc innommable, avec tout le monde qui est en relation avec tout le monde, où tout va à fond la caisse et bouge tout le temps.

Et puis malgré ça, on reste (trop) souvent dans une structure d'entreprise hiérarchique, avec tout en haut le grand chef qui réfléchit et qui détient l'information et le pouvoir, et qui donne des choses à faire à des exécutants en bas. Et ça c'est historique, c'était comme ça au vieux temps…

C'est pour ça qu'il faut trouver un nouveau truc. Un nouveau mode de pensée et de management des entreprises. Eh oui, l'agilité ce n'est pas que des geeks dans un bureau qui ont une super machine de build qui s'allume en rose. C'est aussi tout un mode de "pensée au boulot", admis et recommandé, et même par des gens qui en ont vu, des choses, dans leur vie.


5.1.3. Commenté par Laurent Farcy

3 faits et dires marquants ont plus particulièrement retenu mon attention lors de cette introduction :

  • Atos Origin, l'un des sponsors de la manifestation, réalise un projet stratégique sur 7 ans pour le compte d'ERDF (changement des 35 millions de compteurs électriques chez les particuliers) en mettant en oeuvre une démarche agile ;
  • Pyxis, l'invité canadien, qui déclare "faire du logiciel et s'éclater", tout cela grâce aux pratiques agiles ;
  • Tout le monde se (re)positionne sur l'agilité: c'est visiblement tendance et sans doute vendeur; ce qui est une bonne et une mauvaise chose à mon humble avis.
A suivi une 'performance' appréciée par le public de la part de Jérôme Barrand, "l'invité du 'dîner de con', toute chose égale par ailleurs...", sur l'agilité, un nouveau paradigme managérial. Mr Barrand ne s'est pas gêné pour accuser l'informatique et les technologies de l'information d'être la cause de tous les maux de notre société actuelle. Provocation qui a réussi à amuser et capter l'attention de l'assistance. Sans doute la séance la plus marquante de l'après-midi.


5.2. Introduction à Scrum (Eric Lefevre)


5.2.1. La session, par son auteur

Ma présentation Introduction à Scrum, en 1ère session, s'est bien déroulée. J'ai eu juste le temps d'introduire auprès d'une cinquantaine de personnes les concepts de base, montrer 3 retours d'expérience personnelle et donner quelques billes pour aller plus loin.


5.2.2. La session, commentée par Aline Paponaud

Bon ben voilà, c'est bon, je n'ai plus peur. En fait, on peut se faire le truc à notre sauce ! Pas besoin d'en faire trop d'un coup.

J'ai surtout noté des informations concernant les pratiques d'équipe plutôt que les techniques de gestion de projet avec sprints, backlogs et compagnie (parce qu'on avait vu ça en cours).

L'agilité pour une équipe c'est Partage, Responsabilité, Confiance (etc.). Effectivement, pour une équipe de basket ou d'improvisation, c'est une évidence. Mais pour du développement, on n'aurait pas imaginé... Et bien si, en fait c'est pareil ! Et on verra aussi dans la conférence sur les aspects psychologiques que c'est aussi un peu le même fonctionnement qu'en famille ...

  • Ce qui passe en premier c'est pas les outils et les procédures compliquées, c'est les gens. Le socle, c'est les individus et l'esprit d'équipe ;
  • Avoir quelque chose qui marche, c'est mieux qu'une doc super compliquée avec des 1.1.2.a.iv.B) alinéa 3 ;
  • Le client c'est notre partenaire (parce qu'on est motivés en vrai pour lui, on cherche pas à l'avoir) ;
  • On est capable de s'adapter au changement.
Et en fait tout ça, ça existe depuis longtemps, et les premiers à avoir imaginé quelque chose qui s'appelait "Lean Thinking", ce sont des américains. Lean Thinking a été mis en place par Toyota en 1950 pour la première fois. Et en 1987, il a été inventé un processus de développement "en spirale".

Dernière chose que j'ai notée, c'est que la réunion quotidienne préconisée par Scrum, c'est (moins de 15 minutes) :

  • Qu'est ce qui s'est passé la veille ?
  • Qu'est ce qui va se passer aujourd'hui ?
  • Quelles sont mes difficultés ?

5.3. Retour d'expérience - implémentation Scrum / XP (Bruno Orsier)


5.3.1. La session, par son auteur

La présentation que j'ai faite lors de Agile Tour Grenoble est disponible sous forme d'un fichier pdf à télécharger.

En complément, voici quelques notes pour comprendre les diapos :


5.3.1.1. Introduction

Pratiquer le développement agile sensibilise aux bénéfices de la transparence et de la coopération. Cette présentation est donc proposée dans l'idée de vous permettre de prendre en compte notre expérience et de vous éviter certains écueils que nous avons rencontrés. Elle devrait aussi nous permettre de recueillir des suggestions pour progresser. De toute manière, au minimum, faire cette présentation nous a déjà permis de clarifier certaines de nos idées !


5.3.1.2. Sondage

Pour des raisons de confidentialité il n'est pas possible de donner trop de détails sur les projets en cours. Comme je souhaitais faire tout de même une présentation assez factuelle, j'ai organisé ce sondage interne afin de pouvoir présenter un état des lieux de notre degré d'adoption de Scrum/XP après 3 ans. Le sondage est inspiré de la 3ème enquête annuelle de la société VersionOne (nous utilisons leur produit pour gérer nos backlogs). 29 personnes (sur les 36 concernées) ont bien voulu répondre à ce sondage anonyme.


5.3.1.3. Question 1 (bénéfices des méthodes agiles)

La première question est directement calquée sur une question similaire de l'enquête V1. Il y a avait 5 réponses possibles ; pour synthétiser j'ai additionné les réponses "il y a une amélioration" et "il y a une amélioration significative". Puis j'ai trié les diverses propositions par ordre décroissant, et pour faire apparaître des zones, j'ai coupé arbitrairement à 75% et 50%. Enfin j'ai ajouté une colonne avec les résultats obtenus par VersionOne afin de comparer notre situation avec celle de la communauté (plus de 2300 personnes ont répondu à VersionOne).

Dans la zone verte, nous avons en général un score plus élevé que dans le reste de la communauté, et c'est vrai en particulier pour "les développements sont faits de manière plus disciplinée" (90% chez nous contre 59% dans la communauté). Il est également très satisfaisant de voir que la R&D et le marketing travaillent mieux ensemble, que l'amélioration de la qualité est largement constatée par nos participants à l'étude.

Dans la zone intermédiaire, les 62% concernant la facilité de maintenance et d'extension sont un peu décevants - mais ils restent du même ordre que les 56% de la communauté. Contrairement à ce que nous imaginions (naïvement sans doute), ces facilités ne sont pas forcément obtenues "gratuitement" en pratiquant Scrum/XP.

Dans la zone orange, le faible score sur l'amélioration du moral de l'équipe (48% contre 74% dans la communauté) est un signal d'alarme fort. C'est d'autant plus inquiétant que c'était l'une des promesses de Scrum (avoir plus de "fun" à travailler). Dans le même ordre d'idée, nos participants ne constatent pas vraiment d'amélioration du temps de mise sur le marché, alors que la communauté voit des améliorations. Ces deux points sont des premières indications de nos points faibles actuels.

Les deux derniers points (réduction des coûts de développement, gestion des équipes distribuées) pourraient également sembler inquiétants, mais nous avons à peu près les mêmes scores que le reste de la communauté. Donc ce n'est pas une indication que nous faisons quelque chose de travers (mais ces faibles valeurs ne sont bien sûr pas satisfaisantes).


5.3.1.4. Question 2 (intérêt des diverses pratiques)

Pour cette deuxième question il n'a pas été possible de comparer nos résultats avec ceux de VersionOne. En effet la question correspondante de VersionOne était plutôt "employez-vous telle pratique ?" ; dans notre contexte il m'a semblé plus pertinent de savoir ce que mes collègues pensaient réellement de ces pratiques qu'ils emploient assez souvent. J'ai donc proposé quatre réponses possibles, et j'ai additionné les réponses "intéressant" et "très intéressant). J'ai également trié et fait apparaître des zones de couleur.

Ce qui saute alors aux yeux c'est que les zones opposées semblent correspondre exactement aux pratiques XP d'une part et Scrum d'autre part ! Grosso modo les pratiques XP sont jugées intéressantes, alors que les pratiques (ou "cérémonies") Scrum n'ont pas la faveur des participants. C'est bien sûr un autre signal d'alarme fort, et il va falloir comprendre rapidement ce qui cloche !

A ce stade il est encore difficile de donner une explication satisfaisante de cette faible adoption de Scrum. Il semblerait que l'aspect processus discipliné ne passe pas très bien, à moins que ce soit l'aspect amélioration continue (les rétrospectives).


5.3.1.5. Conclusion

En revenant aux 4 principes du manifeste agile, il semble maintenant clair que nous avons été faibles dans l'application du principe "favoriser les personnes et les interactions plutôt que les processus et les outils". En fait nous avons plutôt fait le contraire, en essayant de favoriser la mise en place d'un processus très discipliné. Nous l'avons fait pour de bonnes raisons (obtention de la certification ISO9001 version 2000, exigences de nos clients notamment dans le domaine pharmaceutique) mais ce faisant nous avons certainement négligé l'aspect humain (gestion du changement, passage d'un management directif à l'auto-organisation des équipes).

Remettre au premier plan ces aspects humains est donc l'un de nos principaux challenges actuels.

D'autre part il apparaît maintenant que les équipes de développement ont déjà fait beaucoup de chemin dans l'adoption de bonnes pratiques de développement. Les réserves de progrès sont maintenant peut-être situées plutôt au niveau de l'équipe de management, qui doit probablement adopter elle-même un mode de fonctionnement plus agile, avec plus de transparence, plus de communication, de coopération - tout cela afin de lever plus rapidement les obstacles rencontrés par les équipes. En effet il semblerait que les rétrospectives sont jugées peu intéressantes par les équipes car elles soulèvent régulièrement les mêmes obstacles qui ne sont pas levés suffisamment vite par le management.

Cette présentation illustre donc certaines des conséquences organisationnelles de la mise en place de Scrum/XP : l'équipe de management doit s'adapter !

Comme je fais partie de cette équipe... j'aurais certainement l'occasion d'écrire à nouveau sur la question !


5.3.2. La session commentée par Eric Lefevre

Bruno Orsier de la filiale de Grenoble (production de logiciels) de Varian a expliqué que Scrum & XP les ont aidé à améliorer la qualité, dont l'obtention de la certification ISO 9001. Par contre, ils n'ont pas pu encore amélioré le Time To Market.

Autre chose intéressante: les membres d'équipe apprécient les pratiques XP mais moins les pratiques Scrum. Contradictoire avec le fait que, parmi les inconvénients, ils citent des points d'ingénierie, alors que, parmi les avantages, ils citent des points de gestion de projet.

Une présentation ‘candide' de qualité.


5.4. Aspects Psychologiques des méthodes Agiles (Ramiro Sarmiento), commenté par Aline Paponaud

Il y a des aspects psychologiques bien sûr, car les méthodes agiles, comme on l'a vu, sont tournées vers l'être humain. Et l'objectif, c'est notre bien-être à tous !

Test-Driven Development = l'Apprentissage "Comme dans les réseaux Neuronaux" selon l'animateur.
Effectivement, commencer par le test, et s'améliorer pour réussir le test, c'est un entraînement ou un apprentissage. Cela permet de reconnaître notre objectif et de ne pas le lâcher, ne pas partir dans une autre direction non plus. "Amélioration Continue".

Binôme = Accepter de l'aide, échanger
"Vérifier" devient "S'entraider", "Concevoir" devient "Echanger avec l'autre" ... Que de belles choses !
Une alternative (vient de la méthode "Crystal"): le "Side By Side". On a chacun deux écrans, de manière à ce que le voisin puisse voir ce qui se passe chez l'autre et éventuellement intervenir.

Avantages du binôme :
  • Concentration soutenue (peut être aussi un inconvénient parce que ça fatigue)
  • Biorythmes psychologiques cumulés (en gros, si y'en a un qui est fatigué c'est l'autre qui gère. ça fait les vases communicants, comme dans un couple !)
  • Transparence
  • Assurance avec la relecture
  • Consensus, capacité à trouver un terrain d'entente
  • Apprentissage, partage de connaissance, erreurs
La rétrospective (le meeting quotidien de Scrum) = S'améliorer ensemble
A faciliter par un coach.
Equivalent à un conseil de famille où on propose des exercices à faire en famille pour s'améliorer (comprendre : le daily meeting de Scrum c'est comme Super Nanny !!!)
Impose le respect entre les membres de l'équipe... Ce que chacun dit est personnel et à prendre en compte.

Les artefacts... La machine de build qui s'allume en rose et la peluche sur l'ordi de ManUChenu ont un rôle !
Moi qui croyais que c'était juste pour le fun...
Nous les informaticiens on "fabrique" du vent (des opérations mathématiques basiques, finalement) Contrairement à un vendeur de légumes, un artisan ou un ouvrier. Les artefacts sont là pour matérialiser ce qu'on a fait (notamment les post-it avec les fonctionnalités à réaliser). Ce sont des symboles qui améliorent notre perception… Et donc on se sent mieux.


5.5. Mise en place d'outils pour industrialiser le développement (Emmanuel Hugonnet, Rémy Sanlaville)


5.5.1. La session, par ses auteurs

Notre présentation (slides au format pdf et ppt) est un retour d'expérience sur la mise en place de différents outils d'ingénierie logicielle qui constituent l'infrastructure de développement à Orange Labs (anciemment France Télécom R&D) ainsi que son utilisation par différents projets industriels.


5.5.1.1. Introduction

Pourquoi des outils d'ingénierie logicielle à Orange Labs ? Afin de répondre aux besoins de ses clients et du marché, France Télécom opère depuis plusieurs années une transformation pour devenir un opérateur de services au dessus de son infrastructure réseau. Pour cela, il est nécessaire de professionnaliser le développement afin d'offrir des services reconnus et de qualité.

Outils d'ingénierie logicielle et agilité ? Le manifeste agile indique en effet : Individuals and interactions over processes and tools. Nous sommes d'accord avec ce point et cela n'est pas contradictoire. Pour nous, l'humain reste au premier plan mais il a besoin d'outils pour réaliser au mieux ses tâches :

  • Les outils ne sont qu'un moyen et pas un but ;
  • Les outils pour une démarche d'amélioration continue.

5.5.1.2. Le Build

Après une rapide introduction de ce qu'est le build et sa problématique (reproductibilité dans le temps et dans l'espace), nous expliquons pourquoi nous avons choisi Apache Maven 2 comme outil de build. Nous présentons ensuite la plateforme Maven 2 que nous avons mis en place à Orange Labs, les difficultés rencontrées lors de cette mise en oeuvre et un premier bilan de l'apport d'une telle plateforme.


5.5.1.3. L'Intégration Continue

Après une introduction de ce qu'est l'intégration continue et sa problématique (détecter au plus tôt les problèmes pour les corriger au plus tôt), nous détaillons les différents concepts de l'intégration continue (triplet {évènements de déclenchement, appel d'actions, résultats (notifications, rapports, artefacts)}) et son workflow dans le cycle de développement. Nous abordons ensuite les objectifs de la mise en place d'un serveur d'intégration continue à Orange Labs, l'étude de comparaison que nous avons mené pour en faire une recommandation et qui a mené au choix d'Hudson et enfin un ensemble de bonnes pratiques que nous avons pu identifier.


5.5.1.4. Retour Projets

Nous montrons ici plusieurs retours d'éxpérience qui permet d'illustrer l'amélioration de la qualité sur différents projets industriels d'Orange.


5.5.1.5. Bilan et Perspectives

Nous finissons par un bilan :
  • au niveau de l'agilité : comment nous avons essayé de répondre au manifeste agile afin de passer de la compilation continue à l'exécution continue vers la production continue ;
  • au niveau d'Orange Labs : quels sont nos retours d'expérience sur les axes d'améliorations et les difficultés rencontrées pour la mise en place d'outils d'ingénierie logicielle pour industrialiser le développement.
Sur ce que nous avons mise en place, nous avons maintenant un socle qui nous permet d'envisager plusieurs perspectives :
  • mise en place d'un tracker pour gérer la traçabilité des exigences et pour structurer le développement (commit par issue...) ;
  • mise en place de sondes/capteurs (prévenir plutôt que guérir) sur l'ensemble de notre chaîne de développement (build, gestion de configuration, intégration continue, tracker...) ;
  • mise en place d'un tableau de bord afin d'améliorer la gestion de projet par le suivi quotidien de l'avancement et de la qualité du développement.

5.5.2. Commenté par Aline Paponaud

J'avais mal lu. Je croyais qu'on allait parler d'agile dans l'industrie... On arrive en retard... ça parle Java, Maven 2, ANT, Eclipse et NetBeans. Sympa, mais on a pas vu l'objectif du début parce qu'on était en retard... En gros :

  • Ils ont une chouette infrastructure, avec une appli web, de la doc en ligne, tout ça.
  • 5% des bugs (ceux découverts post-release) représentent 95% des coûts de production. Ah ben oui, là, on a peur.
  • Les outils qu'ils ont mis en place permettent d'avoir des retours les plus rapides possibles, et c'est la fin du "ça marche chez moi ! Dommage pour toi !!"

5.6. Agilité et avionique (Emmanuel Chenu)

Commentaire d'Emmanuel Hugonnet :
Depuis le temps que je voulais voir Emmanuel en vrai. C'est là qu'on voit le gouffre entre le monde de l'avionique et celui du SI. L'expression 'application critique' prend tout son sens. Une expérience intéressante car elle donne des clefs pour convaincre nos chers décideurs.

Commentaire d'Aline Paponaud :
Ben moi, XP ou pas XP, j'ai peur dans l'avion. Mais oui, malgré toute la complexité des normes imposées quand on fabrique un drone, un missile, un système de navigation GPS, ou toute machine de guerre destinée à être vendue pour ensuite aller tuer des millions d'innocents (ah oui pardon, on parlait *juste* des beaux systèmes pour les avions de ligne 1ère classe), une équipe d'irréductibles a réussi à appliquer de l'agilité, et ça marche mieux.
Ce que j'en retiens en tout cas c'est encore une fois que ce qui est primordial c'est d'avoir une équipe ultra motivée, qui a envie de faire ça.


5.7. Senteurs Agiles (T. Lissajoux), commenté par Emmanuel Hugonnet

Un atelier vraiment enrichissant et un jeu de cartes tout simplement génial. J'ai hâte de pouvoir en obtenir une version :o)).


5.8. Architecture Agile chez Yahoo!/Kelkoo (Arnaud Delafosse), commenté par Eric Lefevre

Pas de grandes révélations ici. L'approche est de “sortir de la tour d'ivoire de l'architecture et d'en faire un travail collectif”. Pour simplifier, ils délèguent autant d'autorité que possible aux équipes de développement, en exigeant tout de même un minimum. J'ai le sentiment qu'ils peuvent aller plus loin: bien qu'il explique que le point principal est d'avoir des logiciels modulaires et qui supportent bien la montée en charge, certaines exigences de l'architecture minimum comme les DAO me semblent aujourd'hui trop contraignantes (trop détaillées?). Par ailleurs, ils ne font pas encore d'itérations ou de réflexions régulières sur ce minimum.

Une citation à retenir: “L'architecture agile, c'est jouer au Tetris avec les exigences!” En gros, on prépare au mieux notre système à accepter des changements futurs, mais sans ajouter des fonctionnalités techniques précises.


5.9. eXtreme Programming - Retour d'expérience après 6 années de pratiques (J-M. Voisin), commentée par Emmanuel Hugonnet

Un retour d'expérience fort intéressant où j'ai pu m'apercevoir qu'Allianz était dans la même ligne qu'Orange Labs sur le choix des outils et des pratiques. Le chiffre du jour : un projet en XP entraîne un surcoût de 15% à la réalisation mais l'équipe qui passait de 50% de son temps en maintenance en est à moins de 10% (environ 1 bug par mois).


5.10. Développement Web Agile avec Ruby on Rails (G. Karékinian), commentée par Laurent Farcy

Il est toujours agréable de constater que d'autres font les mêmes paris que vous (en l'occurrence RoR) et ont une (courte) expérience assez similaire. Au sortir de cette présentation, on a pu sentir la curiosité et l'intérêt suscité par Rails au niveau régional, sans toutefois pouvoir dire si l'adoption augmente significativement.


6. Etape Valentinoise du 23 octobre

Le niveau des sessions, la qualité des échanges ainsi que le buffet ont été au rendez-vous. Le tout a été orchestré d'une main de maître par les organisateurs !
L'amphithéâtre de l'ESISAR était plein : environ 120 participants sont venu partager cet évènement.
Patrice Petit a ouvert les débats avec une introduction aux démarches agiles en 50 minutes.


6.1. Atelier « Artistes et Specifieurs » (Gery Derbier)

Commentaire d'Emmanuel Chenu :
Géry Derbier fait un carton en animant son atelier "Spécifieurs et Artistes".
Il démontre en pratique que le développement est bien un jeu coopératif d'invention et de communication.

Commentaire d'Emmanuel Etasse :
Cet atelier m'a énormément plu. On y découvre de façon ludique les écueils possibles dans la communication entre client et développeurs, et surtout les moyens pour arranger les choses. Je ne regrette pas d'y être allé !

Commentaire d'Alexandre Boutin :
Gery Derbier m'a fait jouer à “Artistes et Spécifieurs” pour me faire réaliser, en autres, qu'il n'y a pas de solutions parfaites pour spécifier quelque chose. Ce jeu Agile m'a beaucoup plu et je vais le travailler pour mieux le comprendre et le reproduire en interne.


6.2. Agile Dojo : L'art de grandir en équipe (Ramiro Sarmiento), commenté par Bruno Orsier

Cela fait plusieurs fois que j'entends parler de ces dojos, donc j'étais très curieux d'en voir un en pratique (avec l'idée d'en animer un moi-même plus tard). Ramiro nous a expliqué que les dojos se pratiquaient sous deux formes :

  1. le kata. C'est une séance préparée, durant laquelle quelqu'un programme en public - l'idée étant de montrer le geste parfait (terme évidemment emprunté aux arts martiaux)
  2. le randori. C'est une séance moins préparée, durant laquelle le public participe. Un binôme programme sur un PC relié à un projecteur, et un membre du public remplace un membre du binôme toutes les cinq minutes. C'est donc très rythmé et intensif.
J'ai noté quelques autres points de l'introduction de Ramiro :
  1. l'idée générale est de pouvoir (enfin !) programmer sans contrainte de type délai à respecter, et donc de pouvoir trouver la meilleure manière. Au minimum, le but est d'aimer ce qu'on a écrit !
  2. on essaie de respecter le principe KISS - pour lui Keep It Simple but not Stupid - je connaissais plutôt Keep It Simple, Stupid mais bon chacun a l'air d'avoir sa propre formule, et wikipedia mentionne aussi « Keep It Sweet & Simple » et « Keep It Short & Simple ».
  3. on peut passer par des phases appelées "spike", durant lesquelles on explore un sujet (par exemple pour trouver comment quelque chose fonctionne exactement - idéalement par des tests).
  4. en principe on ne passe pas trop de temps à faire de la conception, on laisse parler le code et les tests.
  5. durant ces séances, on explore aussi des voies d'amélioration comme la réduction de l'utilisation de la souris (et je suis bien d'accord car je vois de temps en temps des collègues perdre plusieurs minutes à faire des opérations qui pourraient se faire en secondes - le point ennuyeux n'étant pas la perte de temps mais plutôt la perte du fil de pensée).
Suite à cette introduction, nous démarrons sur l'exercice proposé (réaliser un jeu de démineur). Le démarrage est évidemment un peu poussif, d'autant plus que certains (comme moi) ne connaissent pas le langage utilisé (Java).

A la pause je dois malheureusement m'éclipser car je souhaitais écouter la présentation de Alexandre Boutin - c'est l'inconvénient de ces conférences où il y a plusieurs sessions intéressantes en parallèle, et des choix difficiles à faire. Je n'ai pas donc pu voir le randori dans son aspect le plus intensif, mais cette introduction m'a conforté dans l'envie d'en organiser un moi-même. Il y a un ensemble de règles à respecter, voir par exemple ce site qui me permettra de préparer la future séance.


6.3. Retour d'expérience YAHOO International (Alexandre Boutin)


6.3.1. La session, par son auteur

L'amphi était plein pour ma présentation du retour d'expérience Yahoo sur le passage d'une méthode Waterfall à Agile entre 2005 et 2008. Les premiers feedbacks à chaud étaient très positifs. Par contre, en tant qu'orateur, j'ai bien réalisé la difficulté de tenir sur un format de 50 minutes - ce que nous avions imposé à Grenoble.


6.3.2. Commenté par Emmanuel Etasse

Le retour d'expérience d'Alexandre Boutin sur l'implémentation de Scrum chez Yahoo ! en Europe, Asie et Canada m'a beaucoup plu ! Il y était question du choc des cultures. On relève au passage qu'Alexandre avait initialement tenté d'implémenter du cycle en V, mais a du retourner sa veste (du bon coté) en choisissant une démarche Agile. Je retiens aussi que la démarche initiale était un processus imposé visant à contrôler, alors que la forme Agile est un framework optionnel facilitant l'adoption de Scrum mais sans le rendre obligatoire : « On peut forcer quelqu'un à suivre un processus, on ne peut le forcer à être Agile... ». Enfin, une raison obligatoire au succès de la démarche est l'engagement du management.


6.3.3. Commenté par Emmanuel Chenu

Alexandre présente un retour d'expérience sur la transition vers l'agilité chez Yahoo!.
Pragmatisme et franc-parler sont au rendez-vous.


6.4. Le refactoring (Régis Medina)

Commentaire d'Emmanuel Chenu : Pendant 50 minutes, Régis Medina (Crossbow Labs) remanie du code en direct.
Cette session permet de recentrer l'attention des participants sur le (beau) code et les pratiques techniques.

Commentaire de Bruno Orsier : J'ai été très impressionné. En effet je suis familier depuis un moment avec le refactoring, mais je le pratique essentiellement à la main. Régis a fait une démonstration spectaculaire de remaniement de code Java grâce à IntelliJ IDEA. Il a aussi indiqué qu'il était un extrémiste du principe DRY - Don't Repeat Yourself - ca tombe bien, moi aussi (fr voir mon article qui essaie de promouvoir ce principe), mais j'ai trouvé mon maître.
Enfin, Régis a expliqué l'une des conséquences du refactoring constant (et impitoyable) sur un gros projet sur lequel il a travaillé : un concept de plate-forme réutilisable (non prévu au départ) à fini par émerger. Bref, après cette belle présentation, le retour à la réalité - Delphi 7 et son manque d'outils de refactoring - est bien difficile ces derniers jours.


6.5. La méthode Crystal (Gery Derbier)


6.5.1. Commenté par Alexandre Boutin

Retour en Amphi pour écouter Géry Derbier nous parler des principes de Crystal dont les 3 essentiels que sont la livraison fréquente, la communication dans l'équipe et la réflexion pour s'améliorer. Géry a indiqué que les équipes Crystal avaient tendance à abandonner au bout d'un certain temps les itérations à durée fixe pour du KANBAN (Lean). Ce que je retiens surtout de Crystal c'est qu'il faut adapter ses pratiques en fonction du contexte et donc de l'avancement du projet car les besoins sont différents et début, milieu et fin de projet. Cette approche, qui me semble maintenant être une évidence, ne se retrouve pas clairement dans Scrum, sûrement quelque chose à réfléchir et mûrir.


6.5.2. Commenté par Emmanuel Etasse

Gery Derbier a présenté la méthode Crystal de Alistair Cockburn décrite dans les livres Agile Software Developpement et Crystal Clear. J'y ai retenu que cette méthode pouvait s'apparenter à un framework où les pratiques concrètes doivent s'adapter en fonction du contexte et de la vie du projet. Ce framework s'appuie sur des points théoriques :

  • Le développement logiciel est un jeu coopératif d'invention et de communication avec deux objectifs antagonistes : livrer un produit et se préparer pour la partie suivante.
  • Le produit délivré par une équipe est à l'image de celle-ci
Crystal s'appuie 3 propriétés principales : livraison fréquente (au moins tous les 6 mois), communication de proximité entre tous les développeurs (moins de 30 sec pour obtenir une info), réflexion tactique pour s'améliorer (une fois minimum tous les 2 mois). Crystal me fait penser à une méta-méthode, relativement "universelle" en fait.


6.5.3. Commenté par Bruno Orsier

Cette présentation a été beaucoup appréciée par Emmanuel et d'autres participants.
Mais j'ai eu un peu de mal à voir les aspects concrets de cette méthode, et j'ai parfois perdu le fil de la présentation.

Crystal semble voir les choses de beaucoup plus haut que Scrum (Emmanuel en parle d'ailleurs comme d'une "méta-méthode"). Je suspecte que la grande réussite de Scrum vient de sa capacité à être rapidement comprise, et de sa mise en oeuvre assez directe. Crystal paraît moins "prescriptive".

En fin de séance, Emmanuel et moi avons interrogé Géry sur le rôle du manager dans un contexte agile. Géry nous a répondu que son rôle de manager, c'était de produire des équipes - et donc de travailler sur le recrutement, la formation, la communication. Encore un point à méditer, je ne pense pas que nous ayons atteint ce degré de maturité (comme je l'ai indiqué lors de ma présentation à Grenoble, pour nous le rôle de manager se superpose à celui de "pompier", expert technique etc.).


6.6. Forums ouverts

L'étape Valentinoise a été le lieu de plusieurs forums ouverts (Open Space), mais également des discussions de couloir ou autour du buffet.

Alexandre Boutin en a animé un pour les curieux et les sceptiques.
Une petite dizaine de personnes ont contribué à cette session. Les questions traitées concernaient la contractualisation Agile, le rôle et l'intervention des experts, et les difficultés rencontrés lors d'une itération.

Bruno Orsier dans les couloirs :
La pause a été l'occasion d'être présenté par Emmanuel à Laurent Bossavit, avec lequel j'avais été en contact par mail (il avait eu l'amabilité de relire fr mon tutoriel sur le TDD).
Laurent nous indique que son sujet de prédilection depuis plusieurs années est la rétrospective. Ca tombe bien, c'est l'un des sujets qui nous semble délicat dans notre implémentation Scrum/XP. Laurent nous explique une des leçons qu'il a tirées : les actions de la rétrospective ne doivent concerner que les participants à la réunion de rétrospective. Conséquence : il faut parfois inviter des personnes en plus des membres de l'équipe (décideurs, managers, etc.) A méditer, car nos rétrospectives sont en général limitées aux seuls membres d'équipe.


7. Conclusion et remerciements

L'entrain autour des différentes étapes de l'Agile Tour témoigne du succès de cette initiative.
Il est fort à parier que l'édition 2009 sera très attendue, et nous ne pouvons qu'inviter les partenaires locaux potentiels à se manifester auprès des organisateurs, ceci afin de couvrir encore davantage de zones, et pourquoi pas un passage par la Belgique !

Un grand merci donc aux organisateurs globaux et locaux, sans qui la diffusion des courants de pensée agiles n'aurait été possible.
Et bien entendu, merci à tous les contributeurs, directs ou indirects, à ce compte-rendu destiné à vous donner une couverture maximale de l'évènement.


8. Liens



            

Valid XHTML 1.1!Valid CSS!

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2008 Developpez.com Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.