De l'entretien de sa propre estime
18 mai 2006 Olivier Azeau En français 4
Claude Aubry récapitule ce que l'on peut faire avant la première itération pour bien démarrer un projet. L'élément qui a le plus retenu mon attention est "un plan initial de la release" qui suppose d'avoir estimé les exigences et défini les priorités.
Ce point est toujours délicat. Une absence de plan peut entrainer une absence de confiance de la part du sponsor et mettre en danger la poursuite du projet. Un plan trop précis ou pas assez expliqué peut être trop rapidement entériné et faire disparaître un des principes de l'agilité : "we have come to value responding to change over following a plan".
Alors, où peut-on raisonnablement situer la limite ?
Définir les priorités n'est jamais la partie la plus compliquée. Développement logiciel agile ou pas, la plupart des organisations ont l'habitude de rédiger des cahiers des charges dans lesquels les attentes du client sont pondérées par une priorité (en général sur 3 ou 4 échelons).
Il en est tout autrement quand il s'agit de passer à l'estimation des exigences.
J'ai travaillé dans une organisation où la culture était de quantifier chaque exigence en donnant une fourchette en jours : l'effort optimiste et l'effort pessimiste. Ayant des problèmes pour concrétiser les spécifications et avoir des planifications réalistes, j'ai voulu introduire une notion de vélocité dans mon projet. Je suis donc passé à des estimations en "demi journée idéale".
Nous nommions "point" cet nouvelle unité d'estimation et, pendant un temps, j'ai utilisé un artifice pour masquer cette pratique : anticipant que ma vélocité ne sortirait pas de la fourchette 50%-200%, j'ai systématiquement traduit les estimations des développeurs en effort optimiste et effort pessimiste. Ainsi, une histoire évaluée en interne à 8 points était exposée comme prenant entre 2 et 8 jours.
Cela dura un temps mais des demandes de justification sur l'écart entre les effort optimistes et pessimistes ne tardèrent pas à arriver.
Effectivement dresser deux plan initiaux, un optimiste et un pessimiste avec un facteur 4 entre les durées, n'est pas chose aisée à faire passer, même si cela correspond à une réalité : un plan initial est forcément flou et ce facteur 4 ne me semblait pas si extraordinaire. J'ai toutefois décidé de reconsidérer ma position en rendant publique la notion de 'point'.
En oubliant les remarques gentilles digne d'un jury de concours Eurovision que cela a engendré ("Royaume-uni douze points, United Kingdom, twelve points"), l'incompréhension était indubitablement évidente. Les gens voulaient un plan avec des dates, avec des dates fixes, pas une explication sur un système de planification adaptatif.
La solution fut radicale. J'ai donné les efforts pessimistes comme seule et unique évaluation des exigences : les demi journées idéales "internes" étaient devenues des jours pleins "externes". Et tout le monde en a été très satisfait !
Un bon exemple d'agilité en action : plan de plan figé et une réactivité aux évolutions du contexte !
J'ai tiré plusieurs enseignements de cette histoire :
Dès que ce dernier point est acquis, un développement en mode agile peut commencer.
Ce point est toujours délicat. Une absence de plan peut entrainer une absence de confiance de la part du sponsor et mettre en danger la poursuite du projet. Un plan trop précis ou pas assez expliqué peut être trop rapidement entériné et faire disparaître un des principes de l'agilité : "we have come to value responding to change over following a plan".
Alors, où peut-on raisonnablement situer la limite ?
Définir les priorités n'est jamais la partie la plus compliquée. Développement logiciel agile ou pas, la plupart des organisations ont l'habitude de rédiger des cahiers des charges dans lesquels les attentes du client sont pondérées par une priorité (en général sur 3 ou 4 échelons).
Il en est tout autrement quand il s'agit de passer à l'estimation des exigences.
J'ai travaillé dans une organisation où la culture était de quantifier chaque exigence en donnant une fourchette en jours : l'effort optimiste et l'effort pessimiste. Ayant des problèmes pour concrétiser les spécifications et avoir des planifications réalistes, j'ai voulu introduire une notion de vélocité dans mon projet. Je suis donc passé à des estimations en "demi journée idéale".
Nous nommions "point" cet nouvelle unité d'estimation et, pendant un temps, j'ai utilisé un artifice pour masquer cette pratique : anticipant que ma vélocité ne sortirait pas de la fourchette 50%-200%, j'ai systématiquement traduit les estimations des développeurs en effort optimiste et effort pessimiste. Ainsi, une histoire évaluée en interne à 8 points était exposée comme prenant entre 2 et 8 jours.
Cela dura un temps mais des demandes de justification sur l'écart entre les effort optimistes et pessimistes ne tardèrent pas à arriver.
Effectivement dresser deux plan initiaux, un optimiste et un pessimiste avec un facteur 4 entre les durées, n'est pas chose aisée à faire passer, même si cela correspond à une réalité : un plan initial est forcément flou et ce facteur 4 ne me semblait pas si extraordinaire. J'ai toutefois décidé de reconsidérer ma position en rendant publique la notion de 'point'.
En oubliant les remarques gentilles digne d'un jury de concours Eurovision que cela a engendré ("Royaume-uni douze points, United Kingdom, twelve points"), l'incompréhension était indubitablement évidente. Les gens voulaient un plan avec des dates, avec des dates fixes, pas une explication sur un système de planification adaptatif.
La solution fut radicale. J'ai donné les efforts pessimistes comme seule et unique évaluation des exigences : les demi journées idéales "internes" étaient devenues des jours pleins "externes". Et tout le monde en a été très satisfait !
Un bon exemple d'agilité en action : plan de plan figé et une réactivité aux évolutions du contexte !
J'ai tiré plusieurs enseignements de cette histoire :
- Dans une organisation où les gens ne raisonnent pas toujours selon des principes d'agilité, il faut être prudent quand on veut amener un projet dans cette direction.
- Les personnes qui gèrent des projets macroscopiquement depuis leur nuage n'ont que faire des estimations approximatives et de leurs modalités de réévaluation. Elles veulent des estimations pour tout de suite.
- Ces estimations deviennent inévitablement parole d'évangile.
- Un bon plan initial, c'est celui qui prend les estimations des développeurs, les multiplie par 2, 3 ou plus, et publie seulement la somme globale.
Dès que ce dernier point est acquis, un développement en mode agile peut commencer.
La démarche pour introduire de l'agilité est extraordinairement bien menée. Pour ma part, nous avons décider de mettre en place un projet directement en Scrum de A à Z. C'est plus facile pour la démarche, mais peut-être plus difficile pour faire changer les mentalités.
L'estimation initiale reste effectivement un point délicat. Je n'y vois que 2 solutions : soit le commanditaire accepte de jouer le jeu de l'agilité et de ne pas se cramponner à un ensemble contenu+délais+couts fixé ; soit il ne l'accepte pas et alors il faut se blinder.
A mon avis, l'aspect "calcul au plus juste" ne joue que lorsqu'on veut décrocher un contrat pour être, par exemple, mieux référencé quitte à y laisser quelques plumes.