Quand on parle de complexité à une équipe, elle pense difficulté et elle pense temps pour résoudre la difficulté individuellement. Le débat devient vite :
- Quelle note donner à une tâche très longue mais simple ?
- C'est compliqué mais très rapide... je fais quoi ?
- C'est difficile à estimer, il faut découper
- Pour moi c'est rapide, je l'ai déjà fait... pour moi c'est long, je ne connais pas...
Dans cet article je vais essayer de vous présenter quelques réflexions sur ce sujet, mais tout d'abord commençons par le commencement : les User Story.
Les User Story (US)
Une US est la base d'une discussion autour d'un QUI, un QUOI et un POURQUOI.
Exemple : Afin de me rendre à mon travail sans transpirer (POURQUOI), en tant que salarié habitant à + de 2km de mon entreprise (QUI), je voudrais un moyen de transport (QUOI)
Mais souvent on se trouve face à des US qui ne sont que l'expression d'un QUOI.
Exemple : En tant que salarié habitant à + de 2km de mon entreprise (QUI), je veux une voiture climatisée (QUOI)
Ici, le POURQUOI est prédigéré dans la solution : la voiture climatisée. Celui qui a écrit cette US fait déjà le pari que seule la climatisation est la solution au besoin.
Je rencontre souvent des PO qui n'arrivent pas à écrire le POURQUOI des US car ils ont l'impression d'être redondant avec le QUOI : voilà une des raisons.
Clairement, estimer ces deux US est très différent. Dans le premier cas nous allons estimer la capacité de l'équipe à valider des hypothèses rapidement (type de refroidissement, moyen de transport motorisé ou non, autonomie...) alors que dans le deuxième cas, l'équipe va estimer la complexité associée à la création d'une voiture climatisée.
On imagine bien une première équipe qui bricolerait un réfrigérateur posé sur des roues, cette équipe validerait sa première hypothèse rapidement.
Pendant ce temps l'autre équipe serait probablement encore à discuter de la complexité des moteurs à piston !
Besoin ou solution ?
L'Agilité, le Lean Startup nous poussent à travailler sur des POURQUOI mais aussi à valider rapidement le bien fondé de ces POURQUOI.Mais pourquoi ça ?
- Parce que les MEILLEURES solutions ne sont pas toujours celles auxquelles nous pensons initialement, elles viennent de l'expérience et de la collaboration avec les clients.
- Parce que travailler sur des hypothèses sans les valider est un des plus gros facteur de risque d'un projet.
- Parce qu'avant tout nous voulons être certain que la solution va satisfaire le client
Au final la solution sera peut-être pour tout le monde de construire une voiture climatisée, mais dans le premier cas on est certain que cela satisfait le client et dans le deuxième on prend le risque que cela ne le satisfasse pas.
Estimer un besoin
Que signifie alors : estimer la complexité d'un besoin, un POURQUOI ?La complexité d'un POURQUOI n'a pas de lien avec la difficulté ni avec le temps pour faire, mais avec la collaboration nécessaire à l'émergence de la solution.
Cette collaboration est faite d'interactions, de disponibilité, de questions et elle est donc porteuse d'incertitude.
Quand on travaille avec les équipes sur les causes racines des échecs des projets, le manque de collaboration arrive toujours en premier - estimer l'incertitude associée à cette collaboration semble donc être une approche raisonnable.
Pour revenir à notre exemple nous allons estimer :
- La risque de mauvaise compréhension/expression du besoin
- La disponibilité de l'employé pour tester des solutions et fournir des retours
- La nécessité de prendre en compte des contraintes réglementaires
- Tiré de notre expérience, la capacité à finir un tel projet
- Notre maîtrise des éléments techniques quelque soit la solution proposée
- ...
Cette note d'incertitude associée à notre expérience va nous permettre de définir si oui ou non nous pouvons nous lancer dans un tel projet.
Si la réponse est négative, il faudra revenir vers le client pour mieux circonscrire son besoin - c'est une façon de challenger le besoin.
Estimer une solution
"Faire une voiture climatisée" pour toi c'est plutôt du 8 ou du 13 points ?Il n'est pas facile de répondre à cette question et la réaction de l'équipe va probablement être : "Cette US est trop grosse, nous ne pouvons pas l'estimer, il faut la découper"
Découper une US qui est déjà basée sur une hypothèse coûte cher, voyons cela :
- Temps pour le PO et le client pour définir la solution (hypothèse)
- Temps pour l'équipe de réaliser que la solution est trop "complexe" à estimer
- Temps pour le PO de découper la solution en plus petites solutions
- Temps pour l'équipe de tester que la solution est faisable (poc, spike..)
- Temps pour ré-estimer
- ...
Le travail (coût) nécessaire à rendre la solution "estimable" permet-il vraiment d'obtenir une meilleure solution ?
Nous pouvons nous poser la question, d'autant plus que si cette solution est basée sur une hypothèse, le risque de tout perdre est grand.
L'estimation de la complexité du QUOI (la solution) est donc mentalement un exercice difficile dont le résultat n'est pas vraiment créateur de valeur.
Estimation est prédictibilité
Un autre usage de l'estimation conjointement à la vélocité est la prédictibilité. Prédire le contenu d'un sprint ou la date de livraison d'un projet.
La prédictibilité est parfois un besoin impérieux, parfois la justification d'une organisation sous contrôle - quoiqu'il en soit c'est un besoin que l'on ne peut pas ignorer.
Prédire le contenu d'un Sprint ne pose pas trop de problèmes car les erreurs sont faciles à rattraper et très vite l'équipe trouve un équilibre entre l'estimation et ce qu'elle produit - la raison est qu'elle a la maîtrise de ces deux données.
Par contre lorsqu'il s'agit de la date de livraison finale, la formule simpliste Taille du Backlog restant / vélocité moyenne montre souvent ses limites !
Essayons de comprendre.
La taille du Backlog résulte de l'estimation d'une équipe à un instant T. Qu'elle estime de la complexité, de l'incertitude, des besoins ou des solutions, cette estimation est en elle même porteuse d'une incertitude qui va évoluer avec le temps.
Ce phénomène est décrit pas le cône d'incertitude. Il en résulte qu'en début de projet l'estimation ne nous donne pas de date précise mais une fourchette d'incertitude (ex: livraison au minimum dans 1 mois et au maximum dans 4 mois).
Mais il y a aussi un lien entre la taille des items du Backlog (temps nécessaire pour les réaliser) et l'incertitude associée. Il est facile de comprendre que le temps multiplie les facteurs de risque et d'incertitude. Donc plus notre projet est composé de petits items plus l'estimation qui en est faite est fiable.
Mais la vie n'est pas si facile, car réduire la taille des items demande un temps de conception et d'analyse qui a un coût.
Parlons maintenant de la vélocité moyenne : que dire de Sprints qui oscillent entre 2 et 40 points versus des Sprints toujours autour de 20 points ! La vélocité moyenne est la même mais l'écart type lui varie entre ~2 et ~20 !
Pour rappel, la loi normale nous indique que le niveau de confiance de 95% est obtenu entre +/-2 fois l'écart type !
En résumé un projet peut-être dit prédictible si les items sont rapides à réaliser et si l'écart type de la vélocité moyenne est faible, mais dans ce cas, à quoi sert l'estimation puisque le projet est intrinsèquement prédictible ! Mesurer le débit (Nb d'items Done par semaine) suffit largement !
Conclusion
L'Agilité nous pousse à traiter des besoins et non pas des solutions.
Estimer la complexité d'une solution est très fastidieux pour les développeurs et génère des tâches de découpage qui ne créent pas de valeur pour le client.
Estimer la complexité d'un besoin revient à parler de l'incertitude associée et c'est un exercice qui permet rapidement de challenger le client sur le POURQUOI.
Les projets sont dits prédictibles lorsque la taille des items est petite et que le contexte est faiblement porteur d'incertitude.
L'estimation dans un projet prédictible ne sert à rien, la mesure du débit (Cf. Kanban) est largement suffisante.
Dans les projets où l'incertitude est forte, l'estimation ne permet pas de donner de la prédictibilité, au mieux des fourchettes d’atterrissage qui se précisent avec le temps.
Estimer la complexité d'une solution est très fastidieux pour les développeurs et génère des tâches de découpage qui ne créent pas de valeur pour le client.
Estimer la complexité d'un besoin revient à parler de l'incertitude associée et c'est un exercice qui permet rapidement de challenger le client sur le POURQUOI.
Les projets sont dits prédictibles lorsque la taille des items est petite et que le contexte est faiblement porteur d'incertitude.
L'estimation dans un projet prédictible ne sert à rien, la mesure du débit (Cf. Kanban) est largement suffisante.
Dans les projets où l'incertitude est forte, l'estimation ne permet pas de donner de la prédictibilité, au mieux des fourchettes d’atterrissage qui se précisent avec le temps.
Limiter l'incertitude pour rendre un projet plus prédictible prend du temps et coûte de l'argent, cela revient à dire au client : "pour vous donner une date de fin précise, je vais devoir enlever des fonctionnalités, qu'en pensez-vous ?" - je vous laisse imaginer sa réponse !
L'entreprise doit prendre connaissance de tous ces paramètres pour décider où placer son effort et son investissement en fonction de ses priorités.
Aucun commentaire:
Enregistrer un commentaire