Agile Grenoble 2010 – 10 Messages que j’ai retenu

“Nombre de WTF par minute = métrique représentant la qualité du code”

– Aslak Hellesoy - WTF = What the fuck

_

“Loi de Little : Moins on en fait à la fois, plus on va vite”

– Hervé Lourdin, Cyril Mégard

_

“Il faut garder du mou pour absorber la variabilité”

- Hervé Lourdin, Cyril Mégard

_

“L’Agilité est un long voyage. Elle évolue depuis la fin des années 90 et va continuer à évoluer”

– Claude Aubry – Laurent Bossavit

_

“Le TDD dans le Legacy Code, c’est possible et bénéfique”

– Bernard Huguet, Cyrille Roy, Johan Martinsson, Luc Jeanniard ;o)

_

“La programmation fonctionnelle permet de résoudre des problèmes de façon élégante et efficace”

– Emmanuel Gaillot

_

“Bonjour Mr Orsier, je vous apporte le cahier des charges (un énorme classeur) – c’est presqu’ … le définitif”

– Rémy Sanlaville, Bruno Orsier

_

“Il faut commencer le dev le plus tôt possible pour obtenir du feedback rapidement”

– Alexandre Boutin

_

“Portfolio agile : synchroniser les releases pour être réactif au changement”

- Jean Dupuis, Jean-François Jagodzinski

_

“'jcQualitystreet #agilegrenoble: On est loin mais on attend des tweets et du feedback! @NicoRuffel @claudeaubry @agilex @LucJeanniard @jfjago @calton13”

– Jean Claude GROSJEAN via Twitter !

_

Il y a très certainement d’autres messages importants mais c’est la loi de ce genre d’événement, il faut faire des choix, on ne peut pas tout voir, tout entendre, tout retenir … Rendez-vous en 2011 !

Le programme complet est sur http://agile-grenoble.org/

.

La gestion des défauts

Face à la réalité

Le meilleur des mondes serait celui où les défauts n'existent pas, où les bugs n'empêcheraient jamais nos clients de travailler. En attendant d'en arriver à cet idéal, nous devons apprendre à gérer les défauts que nous produisons.

Un des piliers de Scrum est la "Visibilité", alors ne pas les gérer devient un péché. Quoi de pire qu'une version de logiciel planifiée sur 6 mois avec, par exemple, une trentaine de défauts à corriger non estimés en effort, et un release burndown qui montre que tout va bien, nous sommes dans les temps? Cela revient à conduire dans le brouillard avec un oeil caché!

Il y a, selon moi, 3 aspects à considérer pour sortir du brouillard:

• Est-ce bien un défaut et non une amélioration? Une limitation, bien que gênante, n'est pas un défaut.
• La criticité pour nos clients. Elle va nous aider à décider quand corriger le défaut.
• La taille du défaut. Elle va nous donner plus de précision sur l'avancement du projet.

Chaque projet, chaque équipe doit trouver le moyen le plus adapté à son contexte pour gérer les défauts. Néanmoins, il convient d'avoir les éléments suivant en tête:

• Il n'y a pas de Scrum sans IPPS (Incrément de Produit Potentiellement Shippable/Livrable).
• Plus un défaut est corrigé tard, plus il coûte cher.

Quelques pistes à considérer

Je trouve intéressante la solution décrite par Mitch Lacey car elle permet une correction plus ou moins immédiate suivant 4 niveaux de criticité P0 à P4 :

- P0 Catastrophique : Fonctionnalités majeures du système ne fonctionnent pas. Il y a aucun moyen de contourner le défaut.

- P1 Haute : Fonctionnalités majeures du système ne fonctionnent pas. Il existe un moyen de contourner le défaut.

- P2 Modéré : Utilisabilité du système diminuée

- P3 Basse : Peu d'impact; défaut d'aspect, désagrément

Quand un défaut est identifié, il est rapidement classifié et deux scénarios peuvent être suivis:

--> Soit c'est un P2 ou P3 et le défaut est ajouté au product backlog avec tous les éléments nécéssaires à sa reproduction afin d'être priorisé par le Product Owner.

--> Soit c'est un P0 ou P1 et sa correction doit-être entreprise immédiatement. Sachant que certain défauts sont parfois grave mais ne prennent que quelques dizaines de minutes à corriger, la solution décrite permet de ne pas créer de travail administratif si en une heure, le défaut est corrigé.

Claude Aubry décrit une approche similaire appliquée au projet IceScrum

J'aime aussi la pratique d'Alexandre Boutin lorsqu'il accupait la fonction de Process Group Manager; je cite : "Si le backlog comptabilise plus de 10 défauts, je vais voir l'équipe et lui demande d'arrêter tous les travaux en cours et de diminuer ce nombre pour qu'il soit en dessous de 10". Cette pratique très Lean, permet de maîtriser le coût des défauts et de les corriger avant que d'autres fonctionnalités soit ajoutées sur une base défectueuse.

Le coût des défauts

Pour finir, j'aimerais mettre l'accent sur le coût des défauts. Il est bien connu que plus le défaut est trouvé tard dans le cycle de développement, plus son coût de correction est important. Un bug trouvé lors de la phase de développement sera moins cher à corriger qu'un défaut identifié juste avant le déploiement. Évidemment, chez les clients, c'est encore pire. Ensuite, tout défaut devant être corrigé avant la sortie d'un logiciel va apporter un retard sur l'amortissement de son développement. On peut imaginer la catastrophe si un concurrent commercialise un logiciel similaire pendant que nous corrigeons des défauts ... le coût des défauts devient extrêmement important.

Une fois le défaut identifié, là encore, nous pouvons faire monter la facture en fonction du délai de correction. La gestion administrative des défauts a un coût, ils "polluent" le backlog, il nous gênent dans l'avancement du projet. Ainsi, un défaut P0 critique corrigé en 2 jours dès son identification pourra coûter moins cher qu'un défaut P3 moins important corrigé en 2 heures mais 10 semaines plus tard. Pour mesurer la portée de ces propos, nous pouvons imaginer une nouvelle unité pour mesurer le coût des défauts : le "$Day". En reprenant l'exemple ci-dessus, en considérant qu'une heure de travail vaut 100$, le défaut P0 vaut 1600 $Day alors que P3 vaut 16000 $Day soit 10 fois plus. Cette unité est à considérer de manière relative comme l'effort des éléments du Backlog, elle reflète un coût mais n'est pas directement convertible en dollars.

Que pensez-vous de ces approches? Comment gérez-vous les défauts?

Optimisation globale des équipes SCRUM (V2)

 

Suite à une réorganisation interne et au départ d'un collègue pour de nouvelles aventures, deux de nos équipes SCRUM ont vu leurs effectifs réduit d'une personne :

Équipe G:

• 3 développeurs
  
• 2 représentants utilisateurs --> 1 représentant utilisateurs
  
• 1 ScrumMaster
  
• 1 ProductOwner
  

--> Avant le changement, les deux représentants utilisateurs n'étaient pas pleinement occupés sur les projets de leur équipe. Cependant le passage à 1 représentant utilisateurs a inversé les contraintes. Maintenant, les développeurs doivent parfois ralentir leur flux de développement.

Équipe D:

• 3 développeurs --> 2 développeurs
  
• 1 représentant utilisateurs
  
• 1 ScrumMaster
  
• 1 ProductOwner

--> Avant le changement, il y avait un certain équilibre de charge de travail entre les développeurs et le représentant utilisateurs. Le passage à deux développeurs laisserait très probablement du temps libre au représentant utilisateurs.

Les équipes ont les contraintes suivantes:

• Le projet D devra être terminé avant l'été, bien qu'il y ait un développeur en moins
  
• Le projet D devra être maintenu et nous devrons être réactif aux demandes de nos clients; et ce, même pendant les congés annuels de cet été.
  
• L'équipe G doit produire une release du projet G pour mi-mai.
  
• L'équipe G doit maintenir d'autres projets : S, P, etc.
  
• L'équipe D devra aider l'équipe G une fois le projet D terminé.
  

Un brainstorming nous a permis d'imaginer les solutions suivantes:

1. On ne fait rien, et nous ferrons face aux retards possibles sur Projet D et G
   
2. Un développeur de l'équipe G rejoint l'équipe D pour terminer le projet D avant l'été aux frais de l'équipe G et de la release du projet G.
   
3. Nous fusionnons le deux équipes pour finir le projet D, terminer la release du projet G et faire au mieux sur les autres projets.
   

Toutes ces solutions ont leurs avantages et inconvénients:

• La première solution à pour avantage de ne pas trop perturber les équipes qui ont un bon équilibre et qui sont devenues performantes mais on comprend bien que l'objectif de date du projet D sera difficile à tenir car le "product backlog" a déjà été sérieusement raffiné. De plus, dans l'objectif de maintenir le produit, concentrer la connaissance sur trois personnes parait une option assez risquée.

• La deuxième solution serait valable pour terminer le projet D mais ça serait déshabiller l'équipe G déjà réduite pour habiller l'équipe D. D'un point de vu maintenance, cette option est guère mieux que la précédente. De plus, terminer la release du projet G pour mi-mai serait difficile.

• La dernière solution, quant à elle, a pour inconvénient de bouleverser complètement les deux équipes dont les pratiques au quotidien sont différentes, et dans lesquelles une complicité c'est formée. Cependant, la connaissance de tous les projets se diffuserait vers plus de personnes et le projet D pourrait être privilégié afin d'être terminé avant l'été. Le projet G pourra aussi bénéficier de tous les membres de la nouvelle équipe pour valider la release d'ici à mi-mai. 
  

Auriez-vous d'autres idées? Quelle option choisiriez-vous?

Avec une approche Lean, il faut rechercher une optimisation globale plutôt qu'une optimisation locale. Les deux premières options où rien n'est changé et où un développeur change d'équipe sont des optimisations locales avec au mieux le projet D pouvant être terminé dans les temps. Dans ces options, on refuse de changer radicalement pour ne pas casser les dynamiques des deux équipes. Cependant, on conserve de gros risques sur tous les projets que ce soit sur les dates ou la connaissance commune pour la maintenance. La fusion des deux équipes, aux delà du changement complet des équipes parait une solution plus pérenne dans le temps alors s'il faut changer, autant y aller franchement!

Nous avons donc choisi la fusion avec une certaine appréhension face à ce changement mais nous sommes convaincus que c'est la meilleure solution.

Voyons donc maintenant les changements que nous devons mener:

• Reconstruire une équipe : Cela va prendre du temps car pour arriver à la performance nous devrons passer par une certain nombre d'étapes (http://blog.octo.com/stades-de-developpement-dune-equipe/)
  
• Nous allons devoir travailler avec deux ProductOwner tant que le projet D n'est pas terminé
  
• L'un des product owner est aux Etats-Unis avec 6 heures de décalage. Les cérémoniesSCRUM vont donc devoir être adaptées en conséquence
  
• L'équipe D perd son ScrumMaster
  
• Nous devrons faire des choix de pratiques
  
• Nous allons devoir fusionner les "product backlogs" (en gardant des sous-projets) pour avoir une meilleure visibilité
  
• Chacun va devoir apprendre à travailler sur tous les sous-projets.
  
• Nous allons très probablement centraliser les sources des différents projets et fusionner les plates-formes d'intégration continue pour une maintenance plus facile.
  

Dans un prochain billet, j'essayerai d'approfondir la théorie des contraintes sur ces deux équipes afin d'expliquer le choix qui a été fait de façon plus analytique. Je ne manquerai pas aussi de vous faire un retour sur ce choix avec les succès et difficultés rencontrés avant l'été ...

Mémo Lean

La lecture du livre "Implementing Lean Software Development - From Concept To Cash" m'a donné l'envie d'appliquer l'un des conseils exprimé dans le livre : 

"Le rapport A3"

Synthétiser un principe ou un concept sur une feuille simple  permet de filtrer et raffiner ses pensées. C'est aussi un très bon moyen de créer de la connaissance dans son organisation.  D'ailleurs certains collègues ont adopté cette pratique suite à la lecture de l'article PRATIQUES D'EQUIPE lors d'un dojo organisé par Bruno

Voici donc un poster qui a pour but de rappeler en un coup d'oeil les 7 principes du Lean ainsi que les 7 types de gaspillage.

Lean Mémo

Publish at Scribd or explore others: