NDLR – Il existe plusieurs méthodes de développement agile, tels : Kanban, Scrum, Lean, Extreme Programming, etc. L’article est basé sur la méthode la plus répandue soit : l’approche Scrum.
Les méthodes agiles de développement des systèmes ont beaucoup progressées ces dernières années et, malgré certaines questions ouvertes, il n’y pas de doute qu’elles deviennent une réalité appliquée dans plusieurs organisations. Cette croissance a permis la maturation de méthodes agiles plus structurées car elles ont incorporé certains éléments d’autres pratiques et démarches de développement.
Dans le même temps, elles ont développé leurs propres métriques d’estimation et de suivi d’avancement qui semblent donner de bons résultats et qui sont, aux dires de certains de ses acteurs principaux, très utiles pour les équipes agiles. Le portrait est cependant différent si ces métriques sont analysées dans la perspective plus globale de l’organisation.
Une limitation majeure de la méthode est l’estimation de la taille et des efforts ainsi que le suivi de performance de projets agiles. En effet, il n’y pas encore de méthodes standardisées d’estimation de projets agiles qui permettraient un suivi de la performance basé sur une méthode normalisée. Cela rend très difficile, voire impossible, la mesure et la comparaison de productivité de développement entre les projets d’une même organisation, ainsi qu’entre les projets d’une organisation et ceux de l’industrie.
L’estimation agile fonctionne bien pour l’équipe agile
Quand on parle d’estimation de projets agiles, on utilise les notions (release, sprint, user stories, story points, etc.) qui ne sont pas utilisées dans les pratiques conventionnelles de développement des systèmes, telles que le projet, phase, baseline, etc.
En fait, la notion de projet dans l’approche agile n’est pas celle définie par le PMBOK. La méthode agile parle plutôt de « release » qui désigne le logiciel final livré et prêt à être déployé. Pour les besoins d’estimation, on peut considérer le « release » comme un projet et, dans cet article, on va les utiliser comme des synonymes.
Dans le développement agile, les User Stories (US) sont utilisés pour capturer les exigences fonctionnelles du client et leur somme définit le produit à développer. La taille des US est basée sur la complexité relative de chaque User Story et elle est exprimée par Story Points (SP) ou Ideal Days. Les équipes agiles sont encouragées de ne pas passer trop de temps dans l’estimation de la taille des items (épics, US, etc.) parce que les estimations plus détaillées des efforts seront faites plus tard lors de planification des itérations.
Les User Stories sont priorisées selon plusieurs éléments, comme la valeur d’affaires ou leur complexité relative. Elles sont ensuite décomposées en éléments de travail (« Work Items ») qui sont regroupés et réalisés dans une itération appelée Sprint. Les efforts de chaque Work Item sont estimés avec un concept d’estimation basé sur les méthodes Delphi (Planning Poker) afin de planifier les efforts d’un Sprint. Une fois les premiers Sprints terminés, on détermine la vélocité de l’équipe, c’est-à-dire le nombre de points qu’elle peut réaliser en un Sprint. La vélocité est réévaluée régulièrement. En mettant en relation la vélocité et le nombre de points à réaliser (le Backlog du produit), l’équipe peut estimer le nombre de Sprints nécessaires pour terminer le projet. On peut alors avoir une idée de la date de fin du projet/release.
Comme on peut le voir, l’estimation de projets agiles reconnaît en premier lieu les besoins des équipes agiles d’avoir une rapide et simple estimation des efforts de développement. Les erreurs et l’imprécision d’estimation seront toutefois corrigées par la vélocité expérimentée après quelques sprints.
L’estimation agile, fonctionne-elle pour les organisations?
Sans avoir effectué une analyse en profondeur, il est évident que les Story Points ou Ideal Days sont une mesure relative de la taille du logiciel dont le calcul n’est pas basé sur une méthode standardisée. Les Story Points diffèrent considérablement d’une équipe/projet à l’autre et ont une signification seulement aux membres de l’équipe qui les estiment. À cause de cela, les Story Points ou Ideal Days ne peuvent être utilisés au niveau organisationnel comme mesure de taille du logiciel.
Les limitations mentionnées ne concernent pas nécessairement l’exactitude d’estimation de projets agiles et ne veulent pas dire que les projets sont mal estimés. Elles concernent plutôt la capacité des pratiques actuelles d’estimation de projets agiles d’être alignées avec le besoin des organisations. En fait, les organisations ont besoin d’avoir une méthode d’estimation et de mesure standardisée qui peut être appliquée sur tous les projets, peu importe leur méthodologie de développement.
À partir des points suivants, on peut voir comment les pratiques actuelles d’estimation de projets agiles répondent aux besoins des organisations.
1.Obtenir et analyser l’estimé d’un projet dans la phase d’avant-projet
Dans la plupart des organisations, avant d’autoriser le budget et passer au processus d’appel d’offres et ensuite au démarrage de projet, il est nécessaire d’en estimer les coûts et la durée.
Lors de la phase de conception (avant-projet) du développement agile, il est difficile d’estimer les efforts du projet et de déterminer les budgets appropriés. La difficulté vient du fait que les fonctionnalités (backlog du produit) sont estimées très sommairement via des User Stories dont la taille est exprimée en Story points. Cette taille est relative et ne peut pas être utilisée pour estimer les efforts/coûts du projet. Le but de l’équipe agile est d’avoir une idée de la taille relative de chaque item sans lui associer une valeur en termes d’effort.
2.Comparer la performance/productivité des projets – benchmarking interne et externe
En l’absence d’une mesure de taille standardisée, il n’est pas possible de comparer la productivité de développement de projets agiles avec la productivité d’autres projets d’une organisation (benchmarking interne) et encore moins avec les projets de l’industrie (benchmarking externe). Pour les mêmes raisons, la vélocité (le nombre de points qu’une équipe peut réaliser dans un Sprint), ne peut être utilisée comme la mesure de productivité de développement. En fait, elle peut être utilisée dans ce sens, mais seulement pour mesurer la productivité d’une équipe dans le cadre d’un projet. Par conséquent, il est inutile de comparer la vélocité des différentes équipes, car chaque équipe peut avoir différente approche d’estimation.
3.Intégrer les projets agiles dans la gestion de portefeuille de projets
Aujourd’hui, quand on parle de développement agile, un des plus grands défis concerne l’intégration des projets agiles dans la gestion de portefeuille de projets. Les outils d’estimation et de suivi de projets agiles sont utiles pour l’équipe du projet, mais ils ne permettent pas d’avoir une « vue portefeuille » et d’assurer une gestion stratégique des investissements. Pour le faire, il faut constituer le portefeuille de tous les projets dans l’organisation sans égard à la méthodologie de développement (agile ou séquentiel/cascade) et de suivre sa performance au niveau stratégique. Cela suppose qu’on gère tous les projets du portefeuille en se basant sur les mêmes métriques standardisées. Il est clair que les Story Points, malgré leur utilité dans l’estimation de projets agiles, ne peuvent être utilisés comme une mesure de taille au niveau du portefeuille.
4.Suivre l’avancement de projets agiles
Même s’il y a des travaux qui recommandent utilisation de la méthode de la valeur acquise pour les projets agiles en faisant l’adéquation entre les mesures utilisés dans le Scrum avec celles de la valeur acquise, il n’y a pas de preuves concluantes concernant l’applicabilité intégrale de cette méthode pour les projets agiles. La principale difficulté est due au fait que la valeur acquise est basée sur les fonctionnalités livrées (terminés) et non développées comme dans l’agile. Aussi, il est difficile d’utiliser les Story Points pour mesurer l’avancement du projet développé par plusieurs équipes parce que les Story Points ne sont pas comparables d’une équipe à l’autre.
Cela ne signifie pas que les pratiques actuelles de suivi d’avancement de projets agiles donnent des résultats erronés, mais il est crucial que cet état d’avancement soit visible au niveau de l’organisation et que la méthode et le calcul de cet avancement soient harmonisés avec les autres projets qui n’utilisent pas la méthode agile.
5.Collecter les données sur les projets réalisés afin d’améliorer la performance de futurs projets
Dans le développement agile, les données historiques sont rarement collectées parce que l’équipe du projet est plus intéressée par ce qui reste à développer (Product Backlog) que par ce qui a été développé. D’un autre côté, même si l’on décide de collecter les données du projet agile (ex. effort par Story Point, nombre de Story Points par mois de développement, etc.), leur utilité pour d’autres projets serait très limitée du fait qu’elles ne reposent pas sur une méthode de calcul standardisée.
Le fait que les Story Points ne peuvent pas être utilisées pour le calcul de qualité comme on le fait avec les points de fonction (ex. nombre d’anomalies par point de fonction), rend très difficile la comparaison de la qualité du logiciel entre les projets.
6.Diminuer le coût de possession (TCO – Total Cost Ownership)
La méthode agile n’encourage pas la production systématique de la documentation. L’équipe peut produire la documentation qu’elle juge pertinente, mais comme l’accent est mis sur la rapidité d’obtention d’un logiciel opérationnel, elle est souvent négligée. Cela résulte souvent par des coûts supplémentaires de maintenance du logiciel.
Conclusion
On voit que les pratiques actuelles d’estimation de projets agiles sont relativement satisfaisantes au niveau d’équipe agile, mais beaucoup moins au point de vue de l’organisation.
La solution qui conviendrait aux deux niveaux se trouve dans l’application des méthodes de mesure basées sur la taille fonctionnelle. Ce sont les méthodes standardisées qui reposent sur les exigences du client et permettent à l’organisation d’estimer et de suivre la performance de ses projets/portefeuille sur une base comparable. Cependant, pour appliquer ces méthodes à l’agile, il ne faut pas « cascadiser » la méthode agile, c.à.d. adapter l’approche agile aux méthodes de mesure fonctionnelle. Au lieu de cela, il faut plutôt les simplifier et adapter le calcul de la taille fonctionnelle à la méthodologie agile. Seulement de cette façon, on arrivera à standardiser la mesure de taille de projets agiles et, en même temps, à profiter de tous ses bénéfices et de la dynamique de ses équipes.
Présentation de l’auteur
Radenko Corovic, B.Sc.A, MBA, possède plus de 20 ans d’expérience dans le domaine des technologies de l’information (TI), tant dans les secteurs publics que privé. Il est spécialiste des pratiques de gestion de projet, des mesures de performance de projet et de la performance des TI. Plus particulièrement, M. Corovic s’est spécialisé dans les mesures de productivité, les pratiques d’estimation ainsi que le benchmarking de projets informatiques.
M. Corovic a rédigé plusieurs articles, notamment sur la mesure de performance de projet basée sur la valeur acquise, et nombre d’entre eux ont été publiés dans des revues spécialisées. Il a également fait plusieurs présentations sur la gestion du portefeuille de projets (PMI-Project World, Colloque MGP – UQAR 2008, IT Management Forum). Actuellement, M. Corovic est président de RSM Technologies.