Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 Les 22 & 23 novembre : Accès 100% GRATUIT
à la Bibliothèque Numérique ENI. Je m'inscris !
  1. Livres et vidéos
  2. Gestion de projet agile
  3. Estimer et prioriser le besoin
Extrait - Gestion de projet agile De la définition du besoin à la livraison d'un produit de qualité
Extraits du livre
Gestion de projet agile De la définition du besoin à la livraison d'un produit de qualité Revenir à la page d'achat du livre

Estimer et prioriser le besoin

Introduction

Dans un contexte d’agilité, les activités d’estimation et de priorisation sont primordiales et incontournables pour la réussite d’un projet et l’organisation du travail des équipes. Malheureusement, nous verrons que ces activités sont souvent mal réalisées et qu’il existe de multiples pièges dans leur mise en œuvre. Après un rappel des raisons d’être de ces activités, nous présenterons quelques techniques et verrons comment prioriser les besoins sur la base d’estimations, suivant la valeur et suivant l’effort de réalisation. Cette priorisation sera également un point d’entrée à l’activité de planification, qui sera abordée dans le chapitre Planifier et suivre les livraisons du produit.

Pièges à éviter dans l’estimation

L’estimation est une tâche complexe, et avant de rentrer plus dans le détail de cette activité, il est important de rappeler qu’il existe certains pièges et de nombreuses idées reçues sur l’estimation en agile. La méconnaissance de ces pièges amène souvent les organisations à commettre des erreurs et prendre de mauvaises décisions.

Piège #1 : Penser qu’une estimation est exacte

Au risque de décevoir certains d’entre vous, une estimation est, par définition, fausse : c’est une approximation. En effet, pour ne pas se tromper sur une estimation et sa fiabilité, il faudrait soit attendre la fin de la réalisation d’une tâche, soit avoir déjà réalisé la même tâche, dans les mêmes conditions. Avouez que cela n’est pas possible et que cela n’arrive pour ainsi dire jamais. Nous travaillons effectivement souvent dans des environnements complexes et chaotiques, et nous sommes très rarement confrontés aux mêmes situations.

Deux choix s’offrent à vous : soit vous estimez plus ou moins rapidement en sachant que votre évaluation sera fausse, mais vous aurez néanmoins un ordre de grandeur, soit vous n’estimez pas.

Piège #2 : Penser pouvoir...

Estimer la valeur

1. Intérêt de l’estimation de la valeur

Dans le chapitre Contexte de l’agilité, nous avons défini la notion de valeur, que l’on peut résumer au bénéfice que l’on peut retirer (ou attendre) de quelque chose ou au contraire le bénéfice à ne pas faire quelque chose. Pour une organisation, la notion de valeur peut être très diverse, elle peut être par exemple d’ordre commercial. Pour un produit, elle peut être une mesure de la satisfaction que l’utilisateur ressent à l’usage du produit.

Cette satisfaction peut être appréciée en fonction des fonctionnalités délivrées, de leur couverture par rapport aux besoins métier, de la performance de la solution utilisée, de l’expérience utilisateur vécue… Pour l’entreprise, la valeur peut également être d’ordre financier, lorsque le produit est censé rapporter du chiffre d’affaires, des gains, ou bien lorsque ce dernier permet de diminuer les dépenses, de réduire les coûts de réalisation d’une activité métier ou de réduire les coûts de maintenance des applications informatiques, par exemple.

Si vous étiez un manager responsable du développement d’un produit, quelle information souhaiteriez-vous avoir pour mesurer les bénéfices produits ? En tant que manager responsable d’un budget, sur quelle information vous baseriez-vous pour prioriser les ressources disponibles ? Avec l’expérience du terrain, nous nous rendons compte que l’estimation de la valeur est un travail qui n’est pas trivial et qu’il existe des manières de faire qui sont très différentes d’une organisation à une autre, soit dans le choix des techniques utilisées, soit dans les critères pris en compte dans l’évaluation : le niveau d’impact, le niveau de satisfaction, la criticité temporelle…

En agile, l’objectif doit être de livrer en premier ce qui apporte le plus de valeur aux utilisateurs du produit. Contrairement à une approche traditionnelle, où la valeur n’est délivrée qu’à...

Estimer l’effort

1. Pourquoi estimer l’effort ?

L’estimation de la valeur est primordiale en agile, mais elle ne suffit pas à elle seule pour réaliser une planification efficace. Certes, le pilotage macroscopique doit être réalisé sur la base de l’estimation de la valeur, mais rapidement, les équipes qui réalisent le produit vont devoir s’appuyer sur la notion d’effort demandé pour réaliser le produit. Nous allons voir pourquoi et comment il faut prendre en compte cet aspect.

Lorsque nous souhaitons réaliser quelque chose nécessitant un investissement financier, nous faisons des estimations. Ces dernières servent à répondre à des questions telles que « Combien de temps cela prend-il ? », « Quand est-ce que ce sera fini ? ».

Dans une approche traditionnelle, il s’agit d’évaluer une charge de travail par le nombre de jours nécessaires pour réaliser une tâche ou un ensemble de tâches donné. Comme déjà vu au cours du chapitre Besoins et exigences, dans une approche prédictive, nous partons de la définition du périmètre à réaliser pour estimer le délai et le coût. Dès lors, pour estimer le budget, nous utilisons la formule magique "Temps de réalisation estimé * Coût journalier = Budget nécessaire"… et le tour est joué. Pour le délai, connaissant la charge, on peut envisager plusieurs scénarios et tenter de définir une date de fin. L’estimation du temps nécessaire à la réalisation est généralement faite par des personnes compétentes telles que des chefs de projet ou des analystes. Néanmoins, malgré tous les efforts et les qualités des personnes qui les réalisent, ces estimations s’avéreront inexactes. Nonobstant, ces estimations sont nécessaires à la planification.

Dans des environnements complexes, il y a nécessairement des aléas, des obstacles et d’autres imprévus. Par conséquent, il faut très souvent réévaluer la situation. Rappelons que dans ce contexte, l’agile, qui est une approche empirique basée...

Prioriser le besoin

La priorisation existe dans les approches traditionnelles, cette activité n’est donc pas nouvelle en agile, mais elle devient primordiale. Les besoins pouvant évoluer très vite, il faut sans cesse réévaluer la situation et donc prioriser les choses à faire.

1. Pourquoi prioriser ?

La priorisation est nécessaire dans tout projet, car on ne peut pas tout faire en même temps. Une organisation a besoin de ressources pour exécuter les tâches du quotidien et ces ressources peuvent être humaines, matérielles ou logicielles. Or, pour l’organisation, ces dernières sont nécessairement limitées.

En agile, la priorisation est nécessaire car elle permet d’adapter en permanence le périmètre pour respecter les objectifs budgétaires ou calendaires, tout en conservant un ensemble utile de fonctionnalités (MMF - Minimum Marketable Features) et en délivrant toujours plus de valeur.

images/fig4-26.png

Figure 26 - Liste priorisée de choses à faire

Dans la figure ci-dessus, les contraintes (dont la capacité à faire) nécessitent de "couper" la liste des choses à faire à un certain niveau, tout en conservant une livraison d’un ensemble cohérent de fonctionnalités (MMF).

La priorisation fournit également un cadre pour décider s’il faut et quand intégrer les changements de périmètre, en demandant à la partie prenante à l’origine du changement si une chose est plus importante qu’une autre. Le nouveau changement est alors inséré à l’endroit approprié dans la liste priorisée.

images/fig4-27.png

Figure 27 - Insertion d’une nouvelle chose à faire dans la liste priorisée

Les approches agiles offrent une grande flexibilité grâce à la capacité à accepter les changements de dernière minute. Il ne faut pas oublier que, malgré cet avantage, une équipe agile doit nécessairement faire des choix et des renoncements, car l’ajout d’une nouvelle chose à faire a inévitablement une répercussion sur le déclassement des choses les moins prioritaires. Donc oui, en agile, nous pouvons accepter des changements même tard dans un projet, mais cela...