Arriver chez un nouveau client et mettre en place les méthodes agiles est l’occasion de voir remis en question un certain nombre de certitudes. Votre client sera bien sûr renseigné sur les cérémoniaux, les artefacts et les avantages d’adopter une démarche agile. Et sera également convaincu du potentiel bénéfice sur son organisation (autrement, il ne ferait pas appel à vous !). Parmi les différents outils proposés par le cadre Scrum, ce sont les points de complexité en agile qui ont alors soulevé le plus de questionnements chez mon dernier client. Petit récap’ sur le sujet.
Comment quantifier les points de complexité en agile ?
“Cette tâche, c’est une demi-journée ?”. Si vous travaillez dans l’IT, cette phrase doit certainement vous être familière. Elle est pourtant le signe d’une adoption biaisée de l’agilité, où l’on n’arrive pas à se défaire de l’unité la plus employée par les méthodes de développement traditionnelles : le jour-homme.
Les méthodes agiles prennent cette logique à contrepied, et utilisent notamment des points d’effort pour estimer les tâches à accomplir. Ils ont pour avantage d’appréhender la complexité via un ensemble de paramètres :
- l’effort à faire pour accomplir la tâche
- la complexité de la tâche
- les risques identifiés
- les dépendances extérieures à la Scrum team (besoin d’information, prérequis sur l’environnement de développement, etc)
Certaines sources parlent également de point de complexité, mais ce n’est qu’une composante parmi les quatre paramètres d’une estimation plus “éclairée”.
Les points d’effort sont donc effectivement liés au temps, mais ils ne sont pas traduits en unité de temps. En revanche, il sera possible de faire des prédictions de plus en plus précises à mesure que l’équipe scrum gagne en maturité sur le projet.
L’estimation des points de complexité en agile
L’estimation est un moment important du cycle de développement. Elle est réalisée au moment du sprint planning (ou en amont lors de la présentation d’une User Story, ou grooming). Elle permet notamment de :
- identifier et réduire l’incertitude : les échanges entre le product owner et la dev team lors de l’estimation permettent d’identifier les zones d’ombre au plus tôt, et de décider d’une stratégie pour y répondre (compléter les éléments requis pour entamer les développements, collecter de l’information et monter en compétence afin de pouvoir pleinement répondre à la demande)
- prioriser les demandes : en maximisant le ratio valeur ajoutée/estimation, le demandeur s’assure de produire plus de valeur
- fluidifier l’information : l’équipe se bâtit un référentiel commun (toponymie des tâches, prérequis au développement)
Puisque l’équipe qui monte en compétences sur un nouveau projet n’a encore qu’une vague idée de toutes les tâches qu’implique un développement, s’engager sur un périmètre ferme n’a pas de sens lors des premières itérations de développement.
De plus, l’US peut être amenée à évoluer (vous le savez aussi !), donc il est important de prendre une marge de risque.
Enfin, l’estimation en temps est relative au développeur qui prendra la tâche ! Un junior la fera en 2 jours, tandis que votre meilleur expert mettra moitié moins de temps. Il faut donc trouver un système plus performant.
Alors, comment on estime ?
Plusieurs échelles existent :
S, M, L, XL
La suite de Fibonacci : 1, 2, 3, 5, 8… où n = (n-1)+(n-2)
L’idée est de prendre comme étalon la tâche la moins complexe d’un sprint. Ce sera le S ou le 1. Puis les autres tâches d’un sprint peuvent mécaniquement s’estimer par rapport à celle-ci, selon leur complexité. La seconde tâche la plus simple devient alors le M ou le 2, et ainsi de suite.
La suite de Fibonacci a pour avantage d’être non-linéaire : l’intervalle entre deux échelons est croissant. Plus la tâche est complexe, plus le chiffre est grand, donc l’estimation inclut naturellement la marge de risque.
Sprint après sprint, l’équipe monte en compétence et est à même d’effectuer plus rapidement les tâches similaires. Cette efficacité permet un gain de temps, qui peut être mis à profit pour :
- adopter un critère du Done plus restrictif afin d’augmenter la qualité du produit : gain de qualité
- augmenter la cadence en prenant plus de tâches. On parle alors de gain de vélocité
Conclusion
C’est en abandonnant le traditionnel jour-homme, afin de bâtir un référentiel propre à l’équipe, qu’une vraie culture agile s’installe. Voir l’équipe progresser et le nombre de points réalisés augmenter (que ce soit quantitativement ou à travers les critères de qualité du produit) sera la plus belle des récompenses !
Merci à Jordan qui a co-écrit cet article !
_____________________________________________________________________________
Tout simplement “Agile Fan” !
N’hésitez pas à me faire un retour sur cet article ou à me contacter sur LinkedIn pour partager nos actualités!
Nidhal
