Estimer et mesurer la performance des projets agiles avec les points de fonction Radenko Corovic, MBA [email protected]

1. Introduction Les méthodes agiles de développement des systèmes ont beaucoup progressé depuis ces quelques dernières années et, malgré certaines questions ouvertes, il n’y pas de doute que les méthodes agiles deviennent une réalité dans plusieurs organisations. Cette croissance a eu comme résultat la maturation des méthodes agiles qui deviennent plus structurées et commencent à incorporer certains éléments d’autres pratiques et méthodes de développement. Dans ce sens, la méthode agile a développé ses propres métriques d’estimation et de suivi d’avancement qui semblent donner de bons résultats et qui sont, selon les affirmations des acteurs principaux, très utiles pour les équipes agiles. Le portrait est cependant différent si l’on analyse ces métriques du point de vue des besoins au niveau de l’organisation. Une de limitations majeures de la méthode agile1 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 des méthodes standardisées d’estimation de projets agiles qui permettraient un suivi de la performance de projets agiles 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. Nous pensons que la solution peut être trouvée 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. La méthode qu’on propose est basée sur le concept COSMIC; elle est relativement facile à utiliser et peut être appliquée dans les différentes phases du cycle de vie d’un projet, peu importe sa méthodologie de développement. Elle est flexible, peut être adaptée à la réalité de chaque organisation et donne des résultats satisfaisants. 2. Estimation de projets agiles Quand on parle de possibilité d’utiliser les méthodes fonctionnelles d’estimation pour les projets agiles, on doit d’abord trouver la relation entre les notions de base dans l’estimation de la taille fonctionnelle, (projet, exigences du client, processus élémentaire, points de fonction, etc.) et celles du développement agile (release, sprint, user stories, story points, etc.). En fait, la notion de projet dans l’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

1

Dans cet article on va considérer la méthode Scrum

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ées 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 une mesure appelée Story Points (SP). 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. Il faut mentionner qu’une User Story peut être réalisée dans plus d’un 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. L’estimation de la taille (Story Points) est donc séparée de l’estimation des efforts (Planning Poker). 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. 3. Les limitations du concept d’estimation agile basée sur Story Points (SP) Certains auteurs proposent les Story Points (SP) comme la mesure de la taille fonctionnelle du logiciel. Sans effectuer une analyse profonde, il est évident que les SP ne présentent pas une mesure de la taille fonctionnelle du logiciel et cela pour les raisons suivantes:    

Le calcul de Story Points n’est pas basé sur une méthode standardisée. Il n’y pas de relation entre les Story Points et les points de fonction. Le calcul de Story Points ne repose pas sur les processus élémentaires qui est à la base de calcul des points de fonction. 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.

Le fait que le Sprint fait référence à une période de temps dans laquelle un nombre de fonctionnalités doit être développé et non à des fonctionnalités complétées et livrées, ce qui est d’ailleurs la norme dans le calcul de points de fonction, présente une autre difficulté pour l’application des points de fonction au développement agile. En fait, une fonctionnalité développée dans un Sprint peut être reprise et améliorée dans un Sprint subséquent de sorte que la somme de la taille fonctionnelle de tous les Sprint d’un projet est habituellement plus élevée que la taille fonctionnelle du logiciel mesurée à la fin du projet (fonctionnalités livrées). Les limitations mentionnées ne concernent pas nécessairement l’exactitude d’estimation de projets agiles et ne veulent pas dire que les projets agiles sont mal estimés. On voulait plutôt analyser dans quelle mesure les pratiques actuelles d’estimation de projets agiles sont alignées avec le besoin des organisations 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. Dans les points suivants, on peut voir comment les pratiques agiles actuelles répondent aux besoins des organisations en estimation de projets et en suivi de leur avancement.

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 le démarrage de projet, il est nécessaire d’en estimer les coûts et la durée. Il en est de même pour les processus d’appel d’offres et d’octroi de contrat. 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 les 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). Cela rend difficile, voire impossible, de faire des efforts pour améliorer les processus en se basant sur des données crédibles et documentées. 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 waterfall) 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 pas être utilisées 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 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é 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 parce que les Story points ne sont pas comparables d’une équipe à l’autre.

Cela ne signifie pas que les pratiques actuelles de mesure d’état 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 à cause 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’obtenir un logiciel opérationnel, la documentation est souvent négligée. Cela résulte souvent par les coûts supplémentaires de maintenance du logiciel. 4. Estimer/mesurer la taille fonctionnelle des projets agiles Malgré plusieurs essais et propositions quant à l’application de la méthode de mesure de taille fonctionnelle (points de fonction) pour le développement agile, il n’y a pas encore d’approche standardisée décrivant l’utilisation des points de fonction pour mesurer la taille de projets agiles. Afin d’estimer et de mesurer la taille et les efforts de projets agiles avec une mesure fonctionnelle, nous proposons une méthode2 qui est basée sur la méthode COSMIC. La méthode COSMIC (originellement Full Function Points) est une méthode de mesure fonctionnelle du logiciel qui est internationalement reconnue et qui est standardisée ISO. Elle est basée sur le principe suivant: la taille fonctionnelle du logiciel est directement proportionnelle au nombre de ses mouvements de données. Les principaux avantages de ce modèle sont sa simplicité et sa clarté. En fait, le transfert de données COSMIC est précisément défini et les interprétations ambiguës sont très rares. En plus des raisons mentionnées précédemment, on a choisi la méthode COSMIC parce qu’elle est plus appropriée pour mesurer la taille de projets agiles que la méthode IFPUG. Le processus élémentaire définit par COSMIC est plus granulaire qu’avec la méthode IFPUG, ce qui permet de mesurer les petites fonctionnalités du logiciel. En plus, la méthode COSMIC est plus facile à automatiser, car elle associe un point à chaque mouvement de données et n’utilise pas les niveaux de complexité des composants comme dans IFPUG. Les caractéristiques de la méthode proposée : 2

Les détails de la méthode ainsi que l'outil que la supporte seront présentés dans un prochain article



 





Elle peut être performée dans les différentes phases du projet : phase d’avant-projet (estimer la taille et les efforts du projet pour le besoins du budget), avant chaque Sprint (estimer la taille et les efforts du Sprint) et à la fin du projet (taille finale pour les besoins de benchmarking et d’amélioration du processus). Étant basée sur la méthode standardisée du calcul de la taille applicative, cette méthode permet l’application de la valeur acquise pour le suivi d’avancement des projets agiles. Elle est facile à utiliser et ne demande pas une formation en calcul de points de fonction. L’estimation est très facile et très conviviale pour les développeurs. Ils doivent juste répondre aux questions concernant les fonctionnalités du logiciel et l’outil calcule lui-même la taille et les efforts. Les points de fonction sont calculés automatiquement, ce qui ne devrait pas freiner ou bousculer la dynamique des équipes agiles. Le calcul des points de fonction COSMIC est basé sur les exigences du client ce qui est à la base de l’estimation des User Stories. On peut donc bien estimer la taille fonctionnelle des User Stories dans la phase d’avant-projet. La méthode permet l’estimation des efforts/coûts du projet en utilisant les données historiques de l’organisation (effort unitaire).

L’approche du calcul est basée sur les étapes suivantes : 1. Obtenir les exigences fonctionnelles du client (US) Les exigences fonctionnelles du client sont obtenues dans la forme d’User Stories. Comme les User Stories sont parfois présentées avec une ou deux phrases seulement, il est conseillé de demander un peu plus d’explication de la part du client afin qu’il exprime ses besoins de façon claire. Dans cette phase, il ne faut pas insister sur le langage technique; le client peut exprimer ses besoins dans ses propres termes. 2. Identifier les processus fonctionnels Dans cette étape, les exigences (besoins) du client sont traduites en processus fonctionnels. L’identification des processus fonctionnels est définie dans la phase « maping » de la méthode COSMIC. Cependant, étant donné que les User Stories sont présentées comme un regroupement de processus fonctionnels et qu’on n’a pas assez d’information pour les distinguer, il n’est pas toujours possible d’identifier chaque processus élémentaire dans cette phase du cycle de projet. Pour surmonter cet obstacle, l’approche qu’on recommande permet d'estimer la taille des User Stories quel que soit le niveau de granularité (agrégation) des processus fonctionnels. 3. Déterminer la taille fonctionnelle de chaque US en termes de points de fonction COSMIC - CFP Les difficultés associées avec l’estimation de la taille fonctionnelle dans la phase d’avant-projet, ne sont pas une exclusivité de la méthode agile. Les méthodes traditionnelles de développement, telle que Waterfall, connaissent les mêmes problèmes. Les méthodes de calcul de la taille fonctionnelle sont basées sur le processus élémentaire; elles visent donc les plus petites fonctionnalités du logiciel. Étant donné que, dans la phase d’avant-projet, les fonctionnalités ne sont définies que de façon sommaire, il est très difficile d’appliquer la méthode de la taille fonctionnelle à ce stade-ci. De l’autre côté, il est primordial d’estimer la

taille durant cette phase et cela non seulement à cause des exigences budgétaires et contractuelles, mais aussi pour planifier la réalisation du projet et surtout pour estimer la taille de l’équipe de développement. Afin de donner la meilleure estimation possible à ce stade du cycle de vie du projet, nous avons automatisé le calcul de la taille des User Stories en simplifiant le calcul de la taille fonctionnelle avec la méthode COSMIC. En fait, comme une User Story est un regroupement de processus fonctionnels, sa taille est estimée à un niveau d’agrégation plus élevé que le processus élémentaire. Cette taille n’est donc pas calculée, mais plutôt estimée avec une marge d’erreur déterminée par le niveau de granularité des fonctionnalités. 4. Estimer les efforts/coûts du projet (release) Afin de calculer les efforts nécessaires pour développer les fonctionnalités définies via US, une valeur en termes d’effort par Cosmic Function Point – CFP est associée à chaque CFP. Cette valeur (heures ou $ par point de fonction) présente la productivité moyenne de développement de l’organisation. Elle peut être basée sur les projets développés dans l’organisation ou sur les données de l’industrie. En additionnant les efforts/coûts de toutes les User Stories estimées, on obtient les efforts/coûts estimés du projet (release). Il est important de mentionner qu’on peut avoir différents coûts unitaires à l’intérieur d’une organisation. Même si la taille du logiciel ne dépend pas de la méthodologie de développement, de la technologie utilisée ou de la productivité des développeurs, la productivité de développement dépend de ces facteurs ainsi que d’autres facteurs qu’on n’a pas mentionnés. Si, par exemple, les deux parties du logiciel sont développées avec deux technologies différentes, il est fort probable que l’effort/coût unitaire va être différent pour chaque partie du logiciel. 5. Raffiner l’estimation pour mesurer la taille et l’effort de chaque Sprint Les paramétrés détaillés d’estimation permettent de raffiner l’estimation de la taille faite précédemment et d’estimer les petites fonctionnalités du logiciel. Il faut mentionner que, à ce stade, on ne refait pas l’estimation faite auparavant, on la simplement raffine afin d’obtenir des résultats plus précis. 6. Calculer la taille finale du logiciel À la fin du projet, on peut faire le calcul de la taille finale (livrée) du logiciel. On avait déjà mentionné que la taille finale du logiciel n’est pas la somme des tailles des Sprints. Il est donc nécessaire d’obtenir la taille livrée du logiciel livré afin de calculer le coût/effort unitaire du projet et de comparer sa performance avec la performance d’autres projets. Il est aussi utile de comparer la taille finale (réelle) du logiciel avec la taille estimée dans la phase avant-projet. Les éventuels écarts vont nous permettre d’améliorer le processus d’estimation et de mieux calibrer ses paramètres.

Auteur : M. Radenko Corovic possède plus de 25 ans d'expérience dans le domaine des technologies de l’information (TI), tant dans les secteurs publics que privés. Il est spécialiste en pratiques de gestion de projet, en mesures de performance de projet et en performance des TI. Il a rédigé plusieurs articles, notamment sur la mesure de performance de projets basée sur la valeur acquise; nombre d’entre eux ont été publiés dans des revues spécialisées du PMI. M. Corovic a également donné plusieurs présentations sur la valeur acquise et la gestion du portefeuille de projets (PMI-Project World, Colloque MGP –UQAR 2008, IT Management Forum, Colloque 2012 du PMI-Lévis Québec). Il est actuellement président de RSM Technologies, une compagnie spécialisée en gestion de portefeuille, en estimation de projets TI, ainsi qu’en performance de projets.