Rien ne sert d’estimer, il faut partir à point
L’estimation du travail à réaliser est très commune dans les équipes. Elle est faite en équipe ou bien par une seule personne, qui n’a pas forcément les connaissances nécessaire ou qui n’interviendra pas dans le développement.
Mais, finalement … Estimer, est-ce vraiment nécessaire ?
Pourquoi ce besoin d’estimer ?
Des raisons principales
- Pour fluidifier l’information en présentant les fonctionnalités à l’équipe,
- Pour réduire l’incertitude et se sécuriser,
- Pour définir la taille globale d’une story et d’une fonctionnalité,
- Pour partager la notion d’effort (de développement et de test), de complexité,
- Pour gérer les risques éventuels,
- Pour prioriser les demandes sur ce qui apportera le plus de valeur et s’engager.
L’estimation est basée sur un compromis obtenu entre les membres de l’équipe projet. Lors d’une estimation, toutes les personnes susceptibles d’apporter quelque chose au projet sont conviées et impliquées. Pour le reste, il n’est pas nécessaire de les inviter.
L’intérêt principal d’estimer est de permettre à l’équipe de se réunir, de discuter et de partager … bref de collaborer.
Sachez qu’aucune méthode d’estimation ne fonctionne s’il n’existe pas de compréhension mutuelle du produit et de communication entre l’équipe de réalisation (c’est à dire les développeurs et les testeurs) et l’équipe Produit. Comme l’explique Jeff Patton dans son livre “Le Story Mapping”, le partage “d’une compréhension mutuelle pour bien estimer ne devrait pas être un secret bien gardé”.
“Les meilleures estimations proviennent des développeurs qui comprennent vraiment ce qu’ils ont à estimer.” — Jeff Patton.
Une estimation qui change, avec une part d’approximation
Les estimations impliquent une part importante d’approximations et de prédictions qui reposent avant tout sur l’expérience et la maturité de l’équipe.
Cependant, l’équipe aura beau mettre tous ses efforts, son engagement, la mutualisation des qualités de chacun pour avoir une estimation qui soit au plus proche de la réalité … Malgré tout, une grande partie de ses conclusions s’avérera inexactes au fil du temps.
Et cela pour différentes raisons :
- L’équipe qui monte en compétences sur un nouveau projet et n’a encore qu’une vague idée de toutes les tâches qu’implique le développement,
- L’instabilité de l’équipe, avec l’arrivée possible de nouveaux membres en plein projet,
- Des problèmes techniques qui n’auraient pas pu être vus pendant la phase d’analyse,
- Des besoins qui se précisent lors de leurs maturations et qui peuvent modifier des fonctionnalités initialement prévues,
- De nouveaux aspects règlementaires, de sécurité …
La loi de Hofstadter est aussi là pour nous rappeler que :
« Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter… » —Loi de Hofstadter
Vous souvenez-vous du cône d’incertitude ?
Ce fameux cône indique que plus vous vous approchez de la mise en Production, plus votre prédictibilité sera juste. Il représente très bien cette part d’approximation lorsque l’on est en phase d’estimation.
Comme vous pourrez le comprendre, s’engager sur un périmètre ferme n’a pas de sens lors des premières itérations de développement.
Limiter le temps d’estimation
Au final, nous n’obtiendrons jamais la meilleure estimation, la plus juste et la plus réaliste, malgré tous nos efforts. L’estimation n’apporte donc pas une réelle plus-value sur le projet, aussi les ateliers doivent prendre le moins de temps possible.
Combien d’équipes passent des heures à estimer chaque stories, à s’interroger sur une taille “L” ou “XL”, en sachant pertinemment que l’estimation ne sera pas exacte, au lieu de dédier leur temps sur leur cœur de métier : l’analyse, le développement et le test.
“Plus l’élément à estimer est gros, plus il est difficile de l’estimer précisément.” — Mike Cohn.
Et si on estimait différemment …
On remarque bien que l’idée essentielle de ce type d’atelier n’est pas le fait de noter des points ou des tailles de t-shirt, mais bien de partager avec l’équipe et de s’engager avant de développer.
En favorisant le travail collaboratif au plus tôt, ou le “partir à point”
Préconisez la collaboration de l’équipe dès la phase de cadrage d’un sujet, en favorisant l’intervention des équipes Produit, de Réalisation (développeurs, testeurs, OPS), les architectes pour les raisons suivantes :
- Pour fluidifier l’information
Les équipes sont en relation directe avec le métier pour comprendre le besoin et les objectifs de l’entreprise,
Elles partagent le même vocabulaire,
Elles sont impliquées de l’élaboration de la solution à sa mise en production.
- Pour réduire l’incertitude et se sécuriser
En décomposant les projets en éléments plus petits pour mesurer plus souvent,
En intervenant dès la phase de cadrage, les équipes peuvent remonter la faisabilité et les risques au plus tôt.
Les risques et les incertitudes sont les choses susceptibles de faire exploser le budget et le planning. Il est donc essentiel de les connaitre et de les traiter au plus tôt.
- Pour prioriser et s’engager
Elles participent à l’élaboration de la Roadmap et au découpage des fonctionnalités et des stories.
Une mise en place de livraisons régulières et cadencées pour obtenir du feedback au plus tôt et s’adapter rapidement.
5 ateliers collaboratifs
En estimant par le nombre de stories (userstory, technical story, bug)
Plusieurs raisons :
- Le découpage des stories est déjà fait par l’équipe lors des ateliers collaboratifs (Story Mapping, Event Modeling) : plus besoin de se poser la question de savoir si une userstory est trop grosse car cela aura été anticipé en amont,
- On constate aussi que la taille des User Stories se compense très souvent entre elles, à savoir que des stories de grande taille étaient souvent compensées par des stories de petite taille. De ce fait, la vélocité de l’équipe pourra être déduite uniquement par le nombre de stories livrées dans un temps donné … Vous aussi, regardez vos indicateurs, vous pourriez être surpris.e !
L’estimation par le nombre de stories permet de libérer du temps aux équipes.
En étant prédictible, grâce aux indicateurs de votre squad
Par exemple, l’indicateur sur le débit vous permet de déterminer, en moyenne ou par semaine, le nombre de stories traitée par votre équipe.
Mais il existe aussi d’autres indicateurs tels que le Cumulative Flow Diagram, ou la Prédictibilité.
“Un des secrets d’une bonne estimation (…) : Plus vous mesurez souvent, meilleure sera votre prévision.” — Jeff Patton, Le Story mapping.
Pour en savoir plus : Série “les indicateurs d’équipe” : le débit | by Silvere Duval | Just-Tech-IT | Medium
En se remettant en question régulièrement
Dans une approche d’amélioration continue, la Rétrospective est un bon moyen d’analyser, avec honnêteté, notre collaboration lors de la maturation nos sujets, le découpage de nos stories et notre delivery afin d’en tirer des solutions et des actions pour nous améliorer.
Sources de cet article
Notre rythme Estime mieux !. Pourquoi on estime ? | by Jamal BOUNASSEH | Medium | Just-Tech-IT
“Le Story Mapping” — Jeff Patton
“Agile Estimating and Planning” — Mike Cohn
