SFEIR, la métamorphose Agile

Le 18 juin dernier s'est tenu notre dernier Laboratoire Agile dans les locaux de SFEIR à Suresnes. Au programme :

1. Une présentation de GTD (Getting Things Done) par Jonathan VERRECCHIA.
2. Une présentation de Scrum et Kanban par Ganiyou AKADIRI
3. Un bref retour d'expérience par Djamel FERRADJI
4. Notre traditionnel Agile Game de fin de session proposé par Oana JUNCU : le Ball Point Timing
   
   

Atteindre "l'état de Zénitude totale" ?

C'est en appliquant au quotidien GTD que Jonathan arrive à cet état. La méthode GTD peut s'appliquer aussi bien dans la vie professionnelle que dans la vie privée. Elle est adaptée dès lors que l'on accumule les facteurs favorisant le stress : toutes ces choses que l'on doit faire, toutes ces "petites boucles" (ces taches que l'on doit réaliser et qui nous reviennent en mémoire au cours de la journée et qui polluent notre vie quotidienne.)
GTD permet de supprimer ces "petites boucles", de réduire le stress et de ce fait d'augmenter la productivité au quotidien. On est plus serein : la créativité revient alors, et le temps pour les choses importantes est au rendez vous.
Comment GTD permet cela ? Lister toutes les taches à réaliser, puis les organiser par thème :

• Les TODO : TODO Home, TODO Work, TODO Home ou Work (=TODO Commun)
  
• Celles à mettre dans un agenda (les Rendez vous, les taches ponctuelles)
  
• La liste "Un jour peut être"
  

Quand l'ensemble des listes est vide, il est possible d'aller voir dans la liste "Un jour peut être" : C'est celle où nos envies, où nos souhaits sont répertoriés.
Des outils sont à disposition pour pouvoir gérer ces listes : Google Task Canevas (au travers de Gmail), des plugins navigateurs, des applications mobiles.
Quelques conseils donnés par Jonathan :

• limiter le nombre de point d'entrée (idéalement garder le mail et bannir la messagerie du téléphone mobile)
  
• si une tache prend mois de 2 minutes, la réaliser immédiatement
  
• savoir déléguer si on n'est pas la personne la plus qualifiée pour réaliser une tache
  
  

Ainsi, lorsque la liste de tache est vide, on arrive à un sentiment de libération. Le potentiel créatif est augmenté, le stress disparait et le sentiment de "zenitude totale" s'installe.

Jonathan nous a également parlé de la technique du Pomodoro : afin d'éviter toute interruption extérieure (source de diminution de productivité), chacun dans un groupe se met à travailler durant 25 minutes (c'est la durée où l'on est le plus efficace). Un outil pour mesurer le temps commun est à disposition à l'adresse suivante : tomatoi.st

Merci à Jonathan pour sa présentation : il était vraiment convaincu par GTD et très enthousiaste. Le sentiment général des participants était que GTD paraissait plutôt être une méthode de motivation.

Scrum vs Kanban par Ganiyou

Qu'est-ce que Scrum ?'' Il s'agit d'une Méthode Agile dédiée à la gestion de projet et qui focalise l'équipe sur un même but. Elle intègre le client durant tout le projet Elle permet d'augmenter la productivité des équipes et de coller au plus prêt des besoins du client Elle est constituée de Sprint et se base sur du développement itératif et incrémental. Un produit sera découpé en plusieurs petites fonctionnalités (les User Stories) et le temps sera découpé en périodes (les Sprints) Elle repose sur une organisation constituée des rôles suivants : le Product Owner (le client), le Scrum Master (une personne de l'équipe de dev) et l'équipe de dev A la fin de chaque Sprint le produit est livrée et prêt à être testé.

'' Qu'est-ce que Kanban ?'' Kanban, mot d'origine japonaise (fiche ou étiquette), car mis au point par les usines Toyota. Le principe est une gestion de production à zéro stock. Il s'agit également d'une méthode Agile Il est "Just in Time", i.e. faire ce qu'il faut et pas plus (le "minimum syndical", à un moment précis). Des cycles de production sont mis en œuvre. Contrairement au Scrum, il n'y a pas de rôles

'' Scrum et Kanban sont tous les 2... :''

• "Just in Time"
• Agile et Lean (=réduction de tous ce qui n'apporte pas de valeur Ajouté)
• Pour la limitation du travail à faire
• Pour la livraison rapide et fréquente du produit
• Pour l'auto organisation des équipes
• En organisation du travail par la division des éléments
  

'' Les différences entre Scrum et Kanban :''

• Il n'y a pas d'itération de durée fixe
• Scrum gère le temps en Sprint (de ce fait un livrable est attendu en fin de Sprint) alors que Kanban est en livraison continue du produit
• Scrum ne permet pas l'ajout de User Story en cours de Sprint, alors que Kanban le permet à condition de prioriser les nouvelles tâches.
  
  

Après un bref retour d'expérience sur la mission de Djamel, nous avons clôturé notre Laboratoire Agile par le traditionnel Agile Game. Le jeu proposé par Oana, le Ball Point Timing, consistait à passer dans un temps donné un maximum de balles à chacun des membres de l'équipe. Au delà de l'aspect jeu, nous avons pu nous améliorer au cours des différentes itérations (nous sommes passés de 13 à 45 balles !!) et constater que l'équipe apprend des erreurs pour s'améliorer. On peut faire confiance à une équipe auto organisée : elle est responsable et peut évoluer.

La troisième séance des laboratoires agile SFEIR s’est décomposée en trois parties : Tout d’abord une présentation sur la méthode pour rendre une entreprise agile, puis une seconde qui nous a fait découvrir les rétrospectives et pour clore cette session un nouvel Innovation Game « Le jeu des Concepteurs et des Artistes ».

Partie 1 : Comment rendre une entreprise agile

Rendre une entreprise n’est pas chose aisée. L’agilité se construit par des démarches collaboratives à travers des actions concrètes managées de manière agile.Tout ceci peut se décomposer suivant ces différentes étapes :

• Démarrer un projet agile : Au cours de cette étape il faut intéresser le client à l’agilité. Pour que le projet puisse aboutir les différents acteurs doivent avoir un bon état d’esprit mais aussi un esprit critique et combatif. L’ensemble des éléments doivent être compatibles. Les jalons sont posés et les différents outils sont présentés comme par exemple le backlog, le paper board et les post-its, ainsi que les process de communications
• Bootcamp sur cinq jours : Décor, Story board, Casting, Story board et l’outillage
• Accompagnement Agile sur 5 jours : Cet accompagnement nécessite d’avoir un rôle d’observateur afin de pouvoir recadrer et/ou préconiser. Il permet aussi de contrôler qu’il n’y a pas de désaccord dans les échanges MOA et MOE mais qu’il y a surtout une dynamique d’équipe.

Partie 2 : la rétrospective

La rétrospective est le pivot central de l’agilité, elle permet d’améliorer la productivité de l’équipe et s’inscrit dans une démarche d’amélioration continue. Les idées de chacun sont mises à profit. Elle se décompose ainsi :

• Check-in : un stand up où chaque participant peut évoquer ce qu’il attend de cette rétrospective. Cette étape permet d’impliquer chacun des participants et donc de conserver un esprit d’équipe.
• Collecte des données où est fait le bilan de l’itération précédente. Sont alors identifiés les points forts mais aussi les points faibles.
• Explorer : pour chaque fiche, un maximum d’informations doit être recueillies afin d’identifier les axes d’amélioration à mettre en place. Cette analyse des fiches permet de découvrir ce qui a bien fonctionné, comprendre ce qui n’a pas fonctionné et trouver des moyens pour s’améliorer.

Les différentes fiches sont ensuite classées en fonction de leur importance et ce par l’intermédiaire d’un vote.

• Plan d’action : lister les actions à mettre en place pour les futurs itérations et qui seront transmises par mail avec

QUOI : l’action à mener QUI : personne chargée de réaliser l’action QUAND : date à laquelle l’action devra être réalisée

• Check-out : vote de confiance

A lire:

Agile Rétrospective : Making Good Teams de Esther Derby, Diana Larsen et Ken Schwaber

       Project retrospective de Norman L. Kerth

Partie 3 : Jeu - Les Concepteurs et les Artistes

Dans une équipe il y a deux 2 concepteurs qui décrivent un tableau à réaliser et plusieurs artistes qui dessinent. Trois itérations ont été réalisées afin d’identifier les points forts et les points faibles.

Première itération :

• Les concepteurs écrivent en français la description du tableau
• La description est soumise aux artistes
• Si les artistes ont des questions, ils les soumettent par écrit aux concepteurs
• La transmission des documents écrits se fait par un représentant désigné de chaque groupe
• L’échange oral n’est pas permis

Deuxième itération :

• La description écrite se fait par chaque élément du tableau
• Quand les concepteurs sont satisfaits d’un élément du dessin exécuté, ils passent au prochain.

Troisième Itération :

• Les concepteurs regardent le dessin le temps nécessaire pour le retenir
• Les concepteurs décrivent le dessin aux artistes qui doivent le dessiner
• Tout type d échange est permis, sauf l’échange de rôles
• Après le début de l échange, les concepteurs ne peuvent plus regarder le dessin

Pour la première itération la rétrospective a fait apparaître qu’un seul artiste était moteur et donc pour la seconde itération l'action a été mise sur la participation de l'ensemble des artistes. Au cours de la troisième itération différents artistes ont participé à la réalisation de chaque élément du tableau ce qui a désorienté l’artiste dessinant le tableau final.

Le 31 mars dernier s’est tenu le scrum day 2011, organisé par le French Scrum User Group. Plus de 25 sessions étaient programmées, il a donc fallu, pour les près de 500 personnes annoncées, faire des choix. Le titre de cet article est inspiré des conférences auxquelles j’ai assistées, où ce qui ressort est l’importance de l’humain dans la gestion des projets. Car si dans chaque session, le cadre Agile a été rappelé, l’accent a finalement été porté sur la ressource première : les collaborateurs. Au-delà des outils utilisés, ou non utilisés, comme pour Harvey Wheaton, qui nous a présenté son retour d’expérience sur l’intégration de l’agilité dans le monde du développement de jeux vidéo, et pour qui rien ne vaut l’affichage sur le mur, même pour le backlog (uniquement photographié, pas même mis sous Excel) : Rien ne sera efficacement réalisé sans une vraie adhésion des intervenants. Comme le rappelle Véronique messager (conférence « ScrumMasters, devenez le coach agile de votre équipe ») : « Les personnes font le succès du projet ». Sa session était orientée plus sur l’aspect psychologique que méthodologique de l’agile : recentrer le rôle du ScrumMaster sur son coté de faciliteur et de protection, devenant la personne qui permet à l’équipe et à chacun de ses membres de s’élever et à prendre confiance en ses capacités. « Confiance », voilà un autre des mots clés de la journée : confiance des membres de l’équipe entre eux, et vis-à-vis du ScrumMaster ; confiance du Product Owner vis-à-vis de l’équipe de réalisation, Confiance du client… Autant d’éléments primordiaux pour être en situation de réussite. Ainsi, lors de son retour d’expérience sur la mise en place d’un proxy PO, Bertrand Dour (conférence « Le product Owner « proxy » . Mise en place de l’agilité dans un environnement à forte culture « cycle en V ») nous expose les difficultés rencontrées quand cette confiance manque à un ou plusieurs niveaux. Dans le cas exposé, le sponsor pour la mise en place de l’agilité était très faible, le métier peut disponible et divisé en plusieurs entités « concurrentes ». La place du PO dans ce contexte n’a pas semblé aisée et, malgré les premiers résultats positifs et un bilan qui l’est tout autant, le climat n’est pas encore optimal pour un « mode agile » tel que décrit dans l’idéal par les intervenants de la journée. Ceci étant surement très liés aux habitudes ancrées de travail en cycle V. Dans tout domaine il est difficile d’admettre que ce que l’on a appris et appliqué depuis longtemps n’est peut-être pas la meilleure façon de faire. Là encore, on frôle des domaines bien éloigné de ce que l’on étudie dans les parcours « informatique ». Dans sa conférence intitulée « Quarante ans de crise, dix ans d’agilité », Laurent Bossavit, de[ l’Institut Agile|http://institut-agile.fr/], nous met face à ces paradoxes : aucune formation Agile existante actuellement, des jeunes diplômés qui doivent « désapprendre pour réapprendre » … Il présente l’Agile comme une évolution de « rupture ». C’est-à-dire comme un produit de niche, se développant à un moment où il n’est considéré comme adéquat par le public, et qui d’évolution en évolution fini par détrôner l’ancien produit phare, en entrainant sa chute (l’exposé est basé sur la comparaison avec le développement des appareils photos numérique, et la « mort » des appareils classiques). Ceci rend l’adhésion plus difficile encore… Et malgré ces discours « humanistes » il est peu probable, que dans des contextes commerciaux demandant toujours plus de rapidité, l’ensemble des conseils de la journée puissent être appliqués et suivi… A chacun d’y piocher ce qu’il peut pour avancer dans ce sens !

Pour entamer ma journée au ScrumDay, et parce que je n'avais pas encore pu assouvir ma curiosité sur les principes Kanban, je me suis rendue à la conférence Scrum et Kanban, tirer le meilleur des deux, animée par Antoine Vernois, le renommé Claude Aubry et Fabrice Aimetti. Présentation plutôt interactive avec passage de témoin entre les 3 animateurs, mais qui a parfois manqué de peps. ROTI 3/5.

Le pitch : Scrum est la méthode agile la plus populaire. La transition à Scrum représente souvent un changement radical pour certaines organisations. Venant directement du Lean, le Kanban appliqué au développement de logiciel s’affirme comme une pratique alternative intéressante, en particulier pour les activités de support. La présentation, faite par les traducteurs du minilivre de Kniberg et Skarin, montre comment tirer le meilleur de Scrum et Kanban, selon le contexte.

Scrum et Kanban sont toutes les deux des méthodes Agiles, basées sur l'empirisme (mode itératif), Scrum étant plus cadré, Kanban plus ajustable. Chaque itération se décompose ainsi :

• Planifier (au plus près du début de Faire car il est facile d'estimer ce qui peut être fait dans la période immédiatement à venir),
• Faire (en projet informatique, Scrum s'adosse souvent à XP - eXtreme Programming)
• Livrer (avec revue de sprint),
• Améliorer le processus (Kaizen, Inspection et Adaptation : feedback et rétrospective)

...et reprendre au début.

Les différences majeures entre les deux méthodes sont :

• d'abord la fréquence différente des actions listées ci-dessus :
  

quand Scrum impose un enchainement de l'ensemble de ces tâches, Kanban permettra de planifier chaque action à des fréquences différentes (et qui resteraient logiques, ex : livrer chaque semaine, planifier tous les 15 jours, rétrospective tous les mois)

• ensuite la gestion du périmètre du sprint :
  

Scrum aurait tendance à vouloir se conformer au périmètre initial du planning, tandis que Kanban permettrait le remplacement d'une tâche par une autre (si équivalente en terme de complexité et si non entamée) en cours d'itération et selon la priorisation

• - puis la gestion du taskboard :
  

réinitialisé à chaque itération Scrum via le planning game, il est en Kanban plus simplement conservé et alimenté au fil de l'eau. Cependant, pour conserver un volume "à faire" stable par itération, en Kanban, des règles de limitation de l'en-cours sont mises en place pour que le stock de chaque état d'en-cours soit fluide et ne risque pas de devenir un point de blocage. On en profite pour rappeler que les tâches doivent traitées intégralement (état "done").

La gestion des perturbations :
Nos 3 animateurs conseillent Scrum pour une équipe projet qui est ainsi,en cours d'itération, à l'abri de toute perturbation extérieure (impactant la prochaine itération), tout en recommandant plutot Kanban pour les équipes de support ou opérationnelles : la gestion des perturbations est prévue (impact immédiat).
Dans le cas d'une équipe gérant plusieurs projets, le taskboard est unifié. Des codes couleur ou des couloirs peuvent être mis en place, et les sprints successifs seront :

• en Scrum, composés de tâches d'un seul projet, pour éviter les perturbations liées au switch de projet/de produit
• en Kanban, composés à l'envi, mais de façon équilibrée, de tâches d'un seul ou de plusieurs projets selon les priorités.
  
  

Le parallèle entre ces deux méthodes finit par nous mener à la conclusion logique : il faut adopter la méthode choisie à la réalité du projet.

Antoine Vernois, Claude Aubry et Fabrice Aimetti concluent par ces quelques assertions :

Soyez agiles pour la mise en oeuvre du projet
Essayez les choses par vous même
Ne soyez pas trop dogmatiques
Soyez et restez Agiles

Nous sommes heureux de vous relater le BootCamp du Laboratoire Agile SFEIR le 18 mars 2011 !

C'est l'occasion également de vous présenter notre groupe du 1er jour : Cédric, Djamel, Gaëlle, Ganiyou, Michelle, Nicolas, Oana, Tariq, Thierry et moi, un harmonieux mélange d'Agile ready, d'Agile followers, d'Agile users et d'Agile promoteurs (présentés en ordre aléatoire...)!

Sur notre agenda:

1- Thierry rappelle les principes de l'Agilité

2- L'équipe liste et cible ses attentes quant au Laboratoire Agile SFEIR

3- Démo de l'outil de gestion de projets agiles RALLY - Impressions

4- Le traditionnel Shi fu mi

Tour Flash sur l'Agilité

Thierry décrit les grandes lignes de l'agillité en passant par le manifeste Agile qui a fêté ses 10 ans en février (http://agilemanifesto.org/iso/fr/).

Je retiens comme points d'attention les éléments suivants :

- Itérations

il est ardu d'avoir une idée précise du produit final, et qui reste en adéquation avec le besoin actualisé du client, dès le début d'un projet. Le découpage en lots n'est pas forcément la bonne solution pour s'assurer d'obtenir un outil utilisable, car s'il manque une pile au pont, le pont est fragilisé. En revanche, esquisser le pont dans son ensemble peut être une bonne première étape.

- Livraisons régulières

l'importance d'avoir une application toujours opérationnelle et bien commentée : cet argument fort pour la promotion de l'Agile permet aussi un gain important de la confiance du client, et donc facilite la collaboration avec lui, avec les utilisateurs : les tests automatisés, les outils de build automatique, les itérations, ... concurrent à cet état. Alors, est-ce faciliter l'accompagnement au changement ?

- Daily Standup

établit pour chacun une forme de contrat moral passé avec et pour l'équipe du projet auquel on appartient : engagement de contenu, de délais, échange d'information. C'est un rappel quotidien de la poursuite d'un but commun qui sera plus facilement atteint avec la bonne volonté de tous.

- Rétrospectives

où l'on fait un bilan sur la période (le sprint, l'itération) écoulée, mènent l'équipe à la maturité : il faut du courage dans l'échange pour dire et savoir dire, et le faire dans le but d'améliorer l'itération suivante. Même si l'on se sent en terrain connu, que tout avance bien, se demander comment améliorer encore cet état de fait, ou bien comment le transposer à une autre partie du projet qui elle fonctionne moins bien. Ne pas rester dans sa zone de confort, source de stagnation, alors que la zone d'efforts est source de réussite !

- La défense du pair programming

on constate que la concentration du duo en pair programming est largement plus intense, surtout si l'on se coupe des perturbations extérieures (internet, messagerie). Plus spécifique lorsque l'on peut s'attendre à des difficultés pour une tâche particulière : le DOJO : une équipe de développement est constituée pour un sujet donné, et se concentre autour d'un poste de développement sur lequel chacun tour à tour prend la main sur le clavier et participe à son échelle à la réalisation de la tâche.

Qu'attendez-vous des Laboratoires Agile?

Les sujets qui nous chatouillent sont là, sur les post-it, et certains se recoupent et recueillent de nombreux suffrages : ils seront abordés lors des tous prochains Laboratoires Agiles : Comment lancer un projet Agile ? (ASD, TTR, OJU) et Quel outillage Agile pour SFEIR ? (GSA, NTO, OJU)
Suivez-nous, nous entrerons dans les détails bientôt...

RALLY Software

Oana a organisé avec Phillip McKenzie (Rally Software) une conférence téléphonique avec démonstration par prise en main à distance de l'outil RALLY : Rally permet de gérer plusieurs projets Agile par la même interface, et même de suivre la répartition des équipes sur l'un et l'autre projet. La seule contrainte : que chaque projet suive la même périodicité d'itérations.
Il est très intégré, s'interconnecte avec la majorité des outils des grands acteurs du marché : Clear Quest, Mantis, Bugzilla pour le reporting de fiches d'anomalies ou autres, Quality Center, Fitnesse pour les tests automatisés, Hudson, anthillpro pour le build automatique, etc... et reste ouvert à d'autres outils par un simple script
A la fin de la présentation, une floppée de questions est posée à Phillip qui répond bien volontiers. Lorsqu'il aura raccroché, la discussion se poursuit quelques instants.

(RALLY SOFTWARE : http://www.rallydev.com/)

Déjà décrit par Thierry dans un précédent billet comme un des outils les plus polyvalents et de référence, pour le suivi de projets Agile, (sources rapport Forrester), il a quand même suscité l'étonnement (est-il Agile-friendly de permettre de prévoir les surcharges de travail pour un équipier donné, à qui des tâches peuvent donc être affectées ?), mais recueille les faveurs de ceux ayant utilisé d'autres outils en situation réelle, comme Agilo.

Shi Fu Mi

Le débrief sur ce premier après-midi se traduit par une majorité de votes 4 et deux votes 5. Les deux 5 s'expliquent par une adhésion à l'acte fondateur des Laboratoires Agile : la voie est ouverte ! (Ce n'est pas pour rien que ce blog s'appelle On Agile Way) Pour tous, une bonne occasion d'échanger, de progresser, etc...

La TMA, un centre de services

Le rythme de fonctionnement de la TMA est naturellement proche de l'agilité.

!Quels sont les principe de fonctionnement TMA? Chiffre et approuver le développement des évolutions, Planifier les livraisons avec le client, Gérer des nouvelles versions du logiciel dans des nouvelles releases; Gérer le changement par le contrôle continu de la non-régression, Livrer fréquement, etc;

Comment travaillons-nous en projet SCRUM?

Capacité de changement du périmètre en fin de chaque sprint; Définition du périmètre du logiciel sous forme de liste d'user stories (le très populaire backlog) Définition de l'effort de développement pour chaque user story ( compexité vs. charge) Planification du sprint Livraisons sur un rythme itératif d'un logiciel testable

le rapprochement est évident. la mise en place l'est peut-être moins. C'est pour cela que nous oeuvrons avec l'équipe TMA pour "l'agilisation" du plateau TMA. Qui sont nos sponsors? Les Product Owners internes, ceux qui ont le lien opérationnel avec le client.

!!Le plan de bataille

Créer le backlog  : sur un plateau multi-projet, quel est le contenu du backlog le plus pertinent? Nous avons décidé de créer le backlog par équipe.c'est un backlog multi-projet. L'estimation ou le planning poker : c'est la clé du succès. Le planning poker est l'activité primordiale pour partager entre les membres de l'équipe de développement la même compréhension de ce qui doit être développé. C'est aussi une pratique hors pair pour responsabiliser les développeurs sur le contenu et la qualité du logiciel qu'ils vont coder. Les sprints . de sprints courts semblent plus pertinents que des sprints longs. La durée choisie est une semaine. En début de sprint, l’incontournable sprint planning aura lieu. Le stand-up meeting (le daily Scrum) - Les 10 minutes pour faire le tour des 3 questions: "Qu'ai-je fait hier, quelles sont les difficultés que j'ai rencontrées, qu'est-ce que je compte faire aujourd'hui?", est aussi une activité incontournable? Le bilan du sprint : mise en place du protocole de réception de la nouvelle version du logiciel La rétrospective : Nous allons nous focaliser sur des formats rapides, l'objectif de chaque rétrospective est de fournir un plan d'action à suivre. Ce qui est important dans les rétrospectives est d'avoir une suite applicable.

Nos défis__ Comment gérer l"adaptabilité et l'implication du client sur des cycles aussi courts? Quels sont les tests d'acceptations pertinents? Comment gérer la non-régression dans un dispositif qui n'a pas été pensé "test-compatible"?

...Mais nous sommes prêts à les relever !

Bonne question souvent posée, mais souvent évitée... Essayons de voir ce qu'il en est.

Quelle est l'origine de cette question ? Dans les différentes DSI, on souffre souvent du clivage MOA/MOE. La MOA voyant le côté utilisation par l'utilisateur final d'un produit; La MOE souhaitant y apporter des améliorations techniques. La méthodologie Agile se veut fédératrice en amenant tous les intervenants à partager une vision produit. C'est pourquoi le backlog contient généralement des stories apportant une vision "utilisation finale" du produit. Mais pour définir un produit ne faut il pas se poser au moins deux questions : à quoi ça sert ? De quoi est-il fait ? En effet, son utilisation peut être optimisée si sa matière suit les avancées technologiques. Une raquette c'est fait pour jouer au tennis, mais c'est bien mieux en matériaux composites plutot qu'en bois...

Alors pourquoi hésite-t-on à mettre des stories techniques dans le backlog ? Tout simplement parce que l'on parle de "user stories" et que cette connotation de user est purement fonctionnelle. On pense immédiatement à l'utilisateur final du produit. Le développeur, le futur exploitant du produit ou simplement un batch peuvent pourtant être définis comme des users du produit. Ils ont dans ce cas pleinement leur place dans le backlog en tant que users. Dans une application, créer un service qui sera utilisé par un batch peut être considéré comme une storie technique, et elle doit bien figurée dans le backlog. On obtient alors : "En tant que batch bidule, je récupère les données blabla à l'aide du service truc afin de les agréger". Néanmoins, il faut conserver la vision produit et amélioration de celui ci. Une storie technique doit amener quelque chose en plus, que ce soit une facilité d'exploitation ou de maintenance. Par exemple, des états faits sous poi et/ou itext peuvent être refondus en Jasper, qui apporte, via eReports, une facilité d'utilisation et de l'indépendance en termes de design de l'état. Le backlog demeure la responsabilité du Product Owner et il s'agit de le convaincre de l'utilité de cette storie technique. Charge à lui de l'inscrire au backlog. Bonne négociation....

·  Pouvez-vous vous présenter rapidement ?

Ma participation à des projets de grande dimension (refonte du SI de TF1 Publicité menée par Accenture), puis mon rôle de Responsable Etudes et Développement d’AIG Marketing Europe France (Marketing Direct dans le monde de l’Assurance), ont été des expériences significatives dans la recherche d’une méthode projet optimale. En intégrant la DSI de M6, j'ai mis en pratique les méthodes Agiles (Scrum et XP). Convaincu par cette vision projet, j'intègre SFEIR an avril 2010 en tant que Directeur de projets et Coach Agile.

·  Qu'est-ce que l'agilité pour vous ?

Une méthodologie qui permet de fournir un produit très rapidement et le plus en accord possible avec les besoins métier, dans un contexte d'échanges, de confiance et de découverte.

·  Le manifeste agile prône les valeurs suivantes:

1.      Les individus et les interactions plutôt que les processus et les outils

2.      Un logiciel qui fonctionne plutôt qu’une documentation détaillée

3.      La collaboration avec le client plutôt que la négociation de contrats

4.      Accepter le changement plutôt que suivre le plan

Laquelle de ces valeurs est la plus importante selon vous ?

Les "individus et les interactions" car de ce principe les autres peuvent en découler. 

·  Quelles méthodologies agiles connaissez-vous ?

Scrum et XP pour la mise en pratique. Lean pour quelques notions.

·  L'agilité, est-ce plus : de la gestion de projet, de l'ingénierie logicielle, de l'organisation d'entreprise ?

C'est une façon de penser et de faire. C'est donc adaptable à tout type de contexte que ce soit MOA, MOE en informatique ou un autre secteur de l'entreprise. Scrum est plus de la gestion de projet et XP plus côté développement. Le lean a souvent été employé dans les organisations de type industriel (né chez Toyota).

·  Qu'est-ce que l'agilité change pour le développeur ?

Il devient autonome, prend part aux décisions, dialogue avec le client et est facteur d'amélioration et de qualité.

Il a désormais une vision complète du besoin, connait les objectifs et les contraintes. Dans un cycle classique, on lui attribuait une tache à effectuer dans un certain temps...

·  Qu'est-ce que l'agilité change pour le manager ?

Le suivi est quotidien; Il connait exactement l'état d'avancement de son application et ce n'est plus un chiffre sur un planning donné un peu au pifomètre (le célèbre "on en est à 80 %"...)

·  Qu'est-ce que l'agilité change pour l'utilisateur ?

Le produit devient ce dont il a besoin à l'instant t et non une demande formalisée il y a 6 mois, voir plus. Le produit colle au métier et donc répond précisément à ces attentes.

·  Qu'est-ce que l'agilité change pour vous, à votre poste chez sfeir ?

Si j’ai rejoint sfeir, c’est pour pratiquer l’agilité…

·  Comment les technologies RIA peuvent-t-elles faciliter la mise en place de l'agilité ?

Je ne suis pas sûr du lien entre technologie et agilité. Elles introduisent un facteur d'échange plus important avec l'utilisateur car les possibilités de mise en place graphique sont variées, ce qui n'est pas le cas avec un écran type AS400...

·  Quelles évolutions avez-vous vu dans le paysage informatique avec l'apparition des méthodes agiles?

Les échanges entre SSII et client final n'étaient auparavant basés que sur des contrats. L'agilité a amené de la confiance et des échanges plus intenses et si possible sur du long terme. Mais c'est surtout du point du développeur qui n'est plus un pion dans un espace de travail mais une personne avec un nom qui échange directement avec le client.

·  Voyez-vous des convergences ou des divergences entre l'agilité et CMMI ?

Je ne connais pas trop CMMI, je passe ;)

·  Que pensez-vous du "lean software development" ?

Je (re)passe...

·  Quelles sont les différentes prestations agiles proposées par Sfeir ?

Tout ce qui concerne l'agilité, de la découverte et la formation, à la mise en place d'un centre de services en passant par du coaching.

·  Comment abordez-vous les aspects contractuels d'une prestation agile ?

Nous prônons un système de confiance et si possible à long terme avec le client. Le mode régie est donc le bienvenu.

S’il y a un rôle déterminant dans la méthodologie Agile, c’est celui de Product Owner. Il doit être présent et à disposition de l’Equipe, prioriser, spécifier et valider les stories. Tout ceci dans un laps de temps d’une itération. Son implication et sa capacité à alimenter l’Equipe sont les facteurs majeurs de réussite du projet.

Dans ces conditions, doit-il se consacrer à 100 % à son projet ou peut-il être multi projets? Et dans ce cas, comment être multi taches ?

Au cours d’une précédente expérience professionnelle, j’ai appris à pratiquer la méthodologie Agile. Pour débuter, j’étais Product Owner d’une application à développer « from scratch ». Je me suis consacré à ce projet à 100 % pendant une durée de 9 mois environ avant de devoir prendre dans mon escarcelle d’autres projets en cours, orphelins de PO.

Cette phase d’apprentissage a fait ressortir quelques points :

• le PO a au moins une itération d’avance de spécification sur l’Equipe ;
  

• il doit toujours avoir à l’esprit la vision et la version de son produit à livrer et le partager avec l’Equipe ;
  

• plus il teste l’application tôt (si possible dès la livraison de la fonctionnalité), moins il a à gérer les retours.
  

L’augmentation du volume de mon portefeuille projets m’a amené à travailler de la façon suivante :

• constituer une équipe de « Product Owners »
  

• de ce fait, déléguer un certains nombres de taches (par exemple écriture des cas de test)
  

• au fil de l’eau, se désengager des projets « qui roulent »
  

Pour se faire, j’ai recruté un analyste, pour qui le métier était inconnu, mais avec un esprit clair, ouvert et vif. Je l’ai formé sur le « projet qui roule » en méthode Agile :

• Au début de chaque itération, je spécifie les règles de gestion métier, les cas de test à la marge. Il se charge alors d’établir les cas de test ;
  

• Nous itérons également sur un passage de connaissance métier lié au différentes stories à traiter.
  

• Il participe aux ateliers de travail utilisateurs afin de s’imprégner de leur vision, de leurs besoins et d’un langage métier.
  

• Petit à petit, il prend en charge la recette des fonctionnalités livrées par l’Equipe.
  

A ce stade, je reste encore le PO, mais nous entrons dans une phase où nous pouvons être considérés comme backup l’un de l’autre. Les seules différences entre nous deux sont :

• Une connaissance métier plus approfondie due à mon passif (difficile à changer…) ;
  

• Je suis interne et il est externe. Mais est-ce une condition nécessaire pour être PO ? A priori non dès l’instant où il peut s’appuyer sur une MOA interne à forte disponibilité.
  

Etant donné cet état de fait, je me positionne désormais en backup et le nomme PO du projet. Il le prend dorénavant en charge de bout en bout, et sait qu’il peut compter sur moi en cas de besoin.

Ce cycle de formation à la méthode, passage de connaissances métier et endossement de la cape de PO a pris environ 3 mois.

Il est évident qu’il s’agit d’une charge de travail supplémentaire, mais étant donné qu’il a pu monter en compétence rapidement sur la rédaction des cas de test (Fitnesse) et recetter les stories, c’était aussi une charge de travail en moins. La constitution d’une équipe PO s’est avérée comme étant une stratégie payante. Il faut cependant être très claire en termes de communication vis-à-vis de l’Equipe (qui est le PO référent ?) et savoir se coordonner précisément sur les fonctionnalités à embarquer.

26/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe

La méthodologie satisfait très majoritairement tous ceux qui la pratiquent et sa prise d’ampleur le confirme. Peut-on alors parler de succès limité à la conduite/gestion de projet ou étendre ce succès aux clients/sponsors des applications ? En particulier le « client final » (utilisateur de l'application) s’y retrouve-t-il ?

Chaque cas est bien évidemment particulier sachant que la mise en place de la méthodologie peut être soit portée par la gestion de projet (scrum) soit portée par le développement (XP).

Même si dans la majorité des cas ce sont les deux qui vont de paire...

Je fais donc le choix d'utiliser ma propre expérience afin de mettre en exergue les difficultés rencontrées et les succès majeurs de cette méthode. Tout d'abord, plantons le décor : nous avons appliqué Scrum (AMOA) combiné avec XP (plateau de développement composé de prestataires). Je suis client (chef de projet / product owner) de plusieurs applications :

• 1er cas : un projet de refonte d’une brique du SI,
  

• 2ième cas : un nouveau projet (application from scratch),
  

• 3ième cas : un projet « purement technique » (mise en place d’un ESB).
  

Les utilisateurs concernés sont des populations métiers bien différentes et ont une vision distincte des applications.

Considérons chaque cas :

Dans le 1er cas, l’application souffre d’un comparatif avec l’existant en plus de nouveaux besoins à implémenter. Dans un premier temps, l’application a été découpée en 3 lots distincts afin de pouvoir délivrer en 3 phases l’application complète. Un suivi de projet utilisateur en alternance avec les planning games est mis en place. Les utilisateurs sont porteurs et très enthousiastes quant au fait de voir l’application grossir en emportant leurs besoins. Cette satisfaction va de paire avec la volonté de voir leurs nouveaux besoins apparaître sachant que la refonte (éléments de base) n’est pas encore terminée… Puis vient la date fatidique de mise en production du lot n°1. Et là patatra : « on ne peut pas mettre en production une application qui ne couvre pas tout le périmètre ! ». Est-ce un problème de communication de la part de l’Informatique ? A priori non, car ce découpage et ce lot de livraison sont en permanence rappelés. Il s’avère que l’utilisateur n’est finalement prêt à basculer que si son environnement de travail bascule d’un coup. Il ne conçoit pas de gérer une partie des données dans l’ancien système et l’autre dans le nouveau. La méthodologie a dans ce cas complètement satisfait les utilisateurs, même s’ils n’ont pas eu l’occasion de profiter de mise en production incrémental plutôt qu’une bascule complète vers cette application. L’Equipe quant à elle, est surmotivée par cette application qui leur permet de s’exprimer pleinement avec des interfaces riches, et une méthodologie de développement ultra communicante en accord avec leur façon de voir les choses.

Dans le 2ième cas, il s’agit de mettre en place une application, qui par la même occasion, met à plat les interactions entre trois services allant du back au front office. L’application est rapidement développée mais sa mise en place est décalée, ceci à cause d’un point purement business. Une fois en place, elle est vécue dans un premier temps un peu comme une contrainte car chaque service voit alors clairement les dépendances les uns vis-à-vis des autres, puis elle devient enrichissante car facilite les échanges et évolue très rapidement. Cette facilité de l’Agile est exploitée de façon très poussée par les utilisateurs et donc répond très bien à leur besoin. Par contre, l’Equipe le vit beaucoup moins bien car ils ont l’impression de faire et défaire en permanence : « pourquoi se presser puisque de toute façon on va revenir dessus… ». Même si, en tant que Product Owner, je remonte le fait que l’application est très satisfaisante pour les utilisateurs, le moral de l’équipe est difficilement maintenable au beau fixe et la lassitude se fait souvent sentir. De ce fait, la méthodologie est de temps en temps ressentie comme une contrainte (peu de binômage), même si de leur point de vue, aucune autre méthode n’est envisageable.

Enfin le 3ième cas est plus un projet technique et je suis donc l’utilisateur final est tant que PO et chef de projet. Chacun des deux premiers exemples entrainent un besoin à mettre en place dans cet ESB. De ce fait, la méthodologie Agile répond parfaitement car on ne sait pas réellement ce que l’on doit mettre en place dans cette application et on le « découvre » pour la prochaine itération. La façon de concevoir cet ESB sous forme de scénarios a satisfait d’une part le client dont le besoin émergeant est pris rapidement, et d’autre part l’Equipe qui voit les fruits de ses efforts utilisés peu de temps après leur développement.

En conclusion chaque projet a été ressenti de façon différente :

• par les utilisateurs finaux selon le périmètre de l’application, l’impact sur les process métier. Le point commun remonté est le fait que, grâce aux livraisons itératives, ils ont à disposition un produit fonctionnel qui leur permet de valider rapidement la conformité avec le business ;
  

• par l’Equipe, selon la variété du produit, l’utilisation du refactoring et le résultat de leur travail qui était utilisé rapidement ou non.

La méthodologie a fait l’unanimité, même s’il convient de bien réfléchir à la façon de la vendre auprès des différents intervenants afin de ne pas les frustrer quand à la rapidité avec laquelle sera mise en place la produit.

11/05/2010 - Thierry TREPIED Directeur de projets – Coach Agile SFEIR Groupe