Ecrit pour RUP par Karl Wiegers (www.processimpact.com), avec l'autorisation du Software Development Magazine. Adapté par Rational Software Corporation.

Rubriques

Introduction Haut de la page

Ces principes et conseils décrivent une technique qui peut être utilisée pour évaluer l'effort de développement logiciel. La méthode Wideband Delphi peut être résumée comme suit :

  • Sélectionnez une équipe d'experts, et fournissez à chacun d'entre eux une description du problème à évaluer.
  • Demandez à chaque expert de fournir une évaluation (souvent anonyme) de l'effort, qui décompose le problème en une liste de tâches et évalue l'effort pour chaque tâche.
  • Les experts collaborent alors, révisant leurs évaluations de façon itérative, jusqu'à ce qu'un consensus ait été atteint.

L'utilisation de la méthode Wideband Delphi présente plusieurs avantages par rapport à une évaluation réalisée par un individu isolé. D'abord, cela permet d'établir une liste complète de tâches ou une structure de répartition du travail pour les activités principales, du fait que chaque participant aura l'idée de certaines tâches. L'approche consensuelle a pour effet d'éliminer les partis pris que l'on retrouve dans les évaluations réalisées par des experts auto-proclamés, des évaluateurs inexpérimentés ou des individus influents poursuivant des buts inavoués et/ou divergents. Les gens sont généralement plus respectueux des évaluations auxquelles ils ont apporté leur concours qu'à celles qui ont été produites par d'autres. Aucun des participants à une activité d'évaluation ne connaît la "bonne" réponse, et la création d'évaluations multiples tient compte de cette incertitude. Au bout du compte, ceux qui ont utilisé l'approche Delphi reconnaissent l'intérêt de l'itération pour toute activité complexe.

Utiliser Wideband Delphi Haut de la page

Wideband Delphi peut être utilisé pour évaluer pratiquement n'importe quoi - le nombre de mois de travail nécessaires à l'implémentation d'un sous-système spécifique, les lignes de code ou le nombre de classes contenues dans un produit entier, ou les litres de peinture qu'il faudrait pour redécorer la maison de Bill Gates, ou bien encore l'effort que devrait consentir une organisation donnée pour atteindre le niveau deux du Modèle de maturité de capacité.

La méthode Delphi vous aide à développer une structure détaillée de répartition du travail, qui forme la base de l'effort ascendant et permet de faire une estimation de la taille ou du calendrier du projet. Le point de départ d'une session Delphi peut être un document Vision, une spécification plus détaillée des exigences du problème à évaluer ou une description architecturale initiale de haut niveau, ou encore un calendrier de projet. Il en ressort une liste plus détaillée des activités du projet ; une liste d'activités associées de qualité, de processus et supplémentaires ; des hypothèses d'évaluation ; ainsi qu'un ensemble d'activités et d'évaluations globales de projet, à raison d'une par participant.

La figure 1 illustre le flot de processus pour une session Wideband Delphi. Durant la planification, on définit le problème à évaluer et on sélectionne les participants. La réunion de lancement sensibilise tous les évaluateurs au problème. Chaque participant prépare alors individuellement ses estimations et listes d'activités initiales. Ils apportent ces éléments à la réunion d'évaluation, au cours de laquelle plusieurs cycles d'évaluation mènent à la mise en place d'une liste d'activités plus complète, ainsi que d'un ensemble d'estimations révisé. Le modérateur ou le chef de projet regroupe alors les différentes informations d'estimation, puis l'équipe revoit les résultats. Quand certains critères d'achèvement prédéterminés sont atteints, la session prend fin. La gamme d'évaluations qui en résulte prédira vraisemblablement l'avenir de manière plus réaliste que n'importe quelle évaluation individuelle. Observons maintenant chacune des étapes de ce processus.

Diagramme montrant le flot de processus Wideband Delphi.
Lorsque l'on planifie une session Wideband Delphi, le problème est défini et les participants sélectionnés. La réunion de lancement sensibilise tous les évaluateurs au problème. Chaque participant prépare alors individuellement ses estimations et listes d'activités initiales. Au cours de la réunion d'évaluation, plusieurs cycles mènent à la mise en place d'une liste d'activités plus complète, ainsi que d'un ensemble d'estimations révisé. Les informations sont alors regroupées et l'équipe révise les résultats de l'estimation. Quand les critères d'achèvement sont satisfaits, la session prend fin.

Planification Haut de la page

Une session Wideband Delphi commence par la définition du problème et de sa portée : vision, modèle de cas d'utilisation, système existant, architecture préliminaire. Les grands problèmes sont fragmentés en portions gérables qui peuvent être évaluées avec plus de précision, éventuellement par différentes équipes. La personne responsable de l'activité d'évaluation met en place une spécification du problème qui permettra aux participants de disposer de suffisamment d'informations pour produire des évaluations crédibles en connaissance de cause.

L'équipe d'évaluation compte un modérateur, qui planifie et coordonne l'activité, le chef de projet ainsi qu'un groupe de deux à quatre évaluateurs. Le modérateur doit avoir assez de compétences pour participer en tant qu'évaluateur, mais tient le rôle d'un organisateur impartial qui ne laisse pas ses partis-pris ou ses intuitions influer sur les résultats. Les participants sont sélectionnés en fonction de leur compréhension du problème ou du projet, ainsi que des questions d'évaluation qui lui sont associées.

Mise en route Haut de la page

Une réunion initiale de mise en route d'environ une heure met tous les participants au diapason du problème de l'évaluation. Le modérateur explique ce qu'est Wideband Delphi aux membres de l'équipe qui ne connaissent pas cette méthode et fournit aux autres évaluateurs la spécification du problème ainsi que toute hypothèse ou contrainte de projet. Il s'efforce de leur donner suffisamment d'informations pour leur permettre de faire du bon travail sans influer indûment sur leurs évaluations.

L'équipe révise les objectifs de l'évaluation et discute du problème. Les participants s'accordent sur les unités d'évaluation qu'ils utiliseront (semaines, heures de travail, dollars, lignes de code, etc.). Lorsque le modérateur décide que tous les membres de l'équipe sont suffisamment renseignés pour apporter leur contribution à l'activité d'évaluation, le groupe peut se mettre au travail. Sinon, il se peut que les participants aient besoin d'être un peu plus informés sur le problème qu'ils se proposent d'évaluer, ou bien d'être remplacés par d'autres qui seront plus à même de produire des évaluations précises.

Pour déterminer si vous êtes prêt à vous lancer dans une session Wideband Delphi, vérifiez vos critères d'entrée - c'est-à-dire les conditions préalables qui doivent être remplies pour que vous puissiez enchaîner sur les étapes suivantes du processus. Avant de plonger dans l'exercice d'évaluation, assurez-vous que les conditions suivantes sont remplies :

  • Les membres de l'équipe ont été sélectionnés (ils sont compétents).
  • La réunion de mise en route a eu lieu.
  • Les participants se sont mis d'accord sur le but et les unités de l'évaluation.
  • Le chef de projet est en mesure de participer à la session.
  • Les évaluateurs disposent des informations dont ils ont besoin pour y participer efficacement.

Préparation individuelleHaut de la page

Supposons que vous souhaitiez évaluer la quantité de travail totale (généralement exprimée en heures de travail) nécessaire pour mener à bien un projet donné. Le processus d'évaluation commence, chaque participant élaborant indépendamment une liste initiale de tâches qui devront être effectuées pour atteindre l'objectif de projet qui a été déterminé, cela au moyen d'un formulaire semblable à celui présenté dans la figure 2. Chaque participant évalue alors l'effort qui devra être consenti pour chaque tâche. Fragmentez chaque tâche en activités suffisamment simples pour une estimation précise. Définissez clairement les activités, car quelqu'un devra fusionner les listes d'activités de tous les participants en une seule liste composite. Faites la somme des évaluations que vous produisez pour chaque tâche de projet, en utilisant les unités choisies, afin de générer votre évaluation globale initiale.

Graphique présentant un exemple de formulaire d'estimation Delphi
Au début du processus d'évaluation, chaque participant utilise un formulaire de ce type pour dresser individuellement une liste initiale des tâches qui devront être effectuées afin d'atteindre l'objectif de projet qui a été fixé.

Votre évaluation ne doit pas tenir compte de l'idée que vous vous faites de la réponse attendue par le chef de projet ou les autres intervenants. Il y a de bonnes chances que l'évaluation excède les limites acceptables du projet en termes de calendrier, d'effort ou de coût, une situation qui suppose que l'on négocie et qui pourrait mener à revoir à la baisse l'envergure du projet, à allonger les délais ou à ajuster les ressources. Mais ne laissez pas la pression extérieure influencer votre estimation de la façon dont le projet se déroulera.

En plus d'identifier les tâches du projet, notez séparément les tâches relatives à d'éventuelles activités associées ou de support. N'oubliez pas de tenir une liste des tâches ayant trait à la gestion générale, à la gestion de la configuration, ainsi qu'aux activités de processus du premier cycle. Assurez-vous d'inclure les activités de rectification qui suivent celles de test ou d'inspection. Retravailler à la correction des défauts fait partie des choses de la vie, donc vous devez vous y préparer. Si vous évaluez un calendrier, pensez également aux activités supplémentaires qui ne sont pas spécifiques au projet mais que vous pourriez être amené à intégrer à votre planning. On pense ici aux réunions, vacances, formations et autres affectations de projets, ainsi qu'à une multitude d'autres choses qui empiètent sur vos journées.

Etant donné que des hypothèses radicalement différentes peuvent avoir pour conséquence de grandes variations dans les estimations, gardez une trace de chaque hypothèse que vous aurez formulée au cours de la préparation de vos évaluations. Par exemple, si vous envisagiez d'acheter une bibliothèque de composants spécifique ou bien au contraire d'en réutiliser une ayant servie à un projet précédent, notez-le. Un autre évaluateur pourrait supposer que le projet développera cette bibliothèque, ce qui mènerait à une non-concordance entre vos deux évaluations globales.

Gardez à l'esprit les principes et conseils suivants :

  • Faites comme si une seule personne (vous) devait effectuer toutes les tâches.
  • Faites comme si toutes les tâches devaient être effectuées de façon séquentielle ; ne vous préoccupez pas pour l'instant de l'ordre des tâches ni des tâches précédentes.
  • Faites comme si vous pouviez fournir un effort ininterrompu pour chaque tâche (cela peut sembler relever d'un optimisme absurde, mais le processus d'évaluation s'en trouve simplifié).
  • En unités de temps calendaire, faites la liste de toutes les périodes d'attente auxquelles vous vous attendez à faire face entre deux tâches. Cela vous aidera par la suite à transformer vos évaluations d'effort en évaluation de calendrier.

Réunion d'évaluation Haut de la page

Le modérateur commence la réunion d'évaluation en recueillant les évaluations individuelles de chaque participant et en créant un graphique comme celui de la figure 3. L'estimation totale de chaque participant est représentée par un X sur la ligne "Cycle 1". Chaque évaluateur peut voir où sa valeur initiale s'insère le long du spectre. Les évaluations initiales seront extrêmement divergeantes. Imaginez les différentes conclusions que vous auriez pu rassembler si vous aviez demandé à un seul participant son évaluation et l'aviez utilisée pour planifier le projet.

Graphique représentant l'évaluation initiale suite à une session Wideband Delphi.
Le modérateur commence la réunion d'évaluation en recueillant et en représentant sous forme de graphique les évaluations individuelles des participants. L'évaluation totale de chaque participant est représentée par un X sur la ligne "Cycle 1". Les évaluations initiales seront extrêmement divergeantes. 

Dans certaines organisations, le modérateur n'indique pas qui a créé chaque évaluation. Cet anonymat est ressenti comme un aspect important de la technique Delphi. L'anonymat empêche ainsi un collègue qui a son franc-parler d'intimider les autres participants pour qu'ils voient les choses à sa façon. Cela veut dire également que les membres de l'équipe sont moins enclins à s'en remettre au jugement du participant le plus respecté lorsque leur propres analyses mènent à des conclusions différentes. Toutefois, l'anonymat n'est pas obligatoire.

Chaque évaluateur lit sa liste de tâches initiales, identifie les hypothèses et soulève des problèmes et les questions, sans dévoiler quelle était son évaluation. Chaque participant aura listé des tâches différentes à accomplir. Le fait de mettre toutes ces listes de tâches individuelles en commun conduit à une liste plus complète que n'importe quel évaluateur pourrait fournir. Cette approche fonctionnera pour plusieurs dizaines de tâches individuelles. Si vous avez plus de tâches, il se peut qu'elles soient trop détaillées. Vous devrez peut-être diviser le problème en sous-problèmes et les évaluer séparément.

Pendant cette discussion initiale, les membres de l'équipe parlent aussi de leurs hypothèses, de leurs problèmes d'évaluation et de leurs questions par rapport au problème. A la fin, l'équipe commencera à se mettre d'accord sur un ensemble d'hypothèses et sur une liste de tâches communes. Il faut retenir cette liste de tâches finale et l'utiliser comme point de départ la prochaine fois que vous évaluerez un projet similaire.

Après cette discussion initiale, tous les participants modifient leurs évaluations simultanément (et en silence) dans la salle de réunion. Ils peuvent réviser leurs listes de tâches à partir des informations partagées pendant la discussion et modifier leurs propres évaluations des tâches en fonction de leur nouvelle conception de l'étendue des tâches ou des nouvelles hypothèses. Tous les évaluateurs peuvent rajouter de nouvelles tâches à leurs listes ou faire les modifications qu'ils considèrent opportunes à leurs évaluations initiales. Le changement net pour toutes les tâches est égal au changement dans l'évaluation du projet global de ce participant.

Le modérateur réunit toutes les évaluations corrigées et les reporte sur le même graphique, sur la ligne "Cycle 2". J'ai fait cela sur un tableau blanc pour que ce soit plus clair. Comme on peut le voir dans la figure 4, le deuxième cycle doit conduire à des évaluations moins divergeantes, autour d'une moyenne supérieure à la moyenne des valeurs du cycle 1. Des cycles supplémentaires devraient affiner davantage la distribution. Le cycle de revue de la liste des tâches, de discussion des problèmes et des hypothèses et de préparation de nouvelles évaluations continue jusqu'à arriver à :

  • la fin des quatre cycles ;
  • un écart acceptable (défini par avance) entre les différentes évaluations ;
  • l'épuisement du temps dévolu à la réunion d'évaluation (normalement deux heures) ; ou
  • un satde où les participants ne veulent pas modifier leurs évaluations finales.
Graphique d'évaluation avec trois cycles d'une session Wideband Delphi.
Après la discussion concernant leurs évaluations initiales, tous les participants modifient leurs évaluations. Le modérateur réunit toutes les évaluations corrigées et les reporte sur le même graphique, sur la ligne "Cycle 2". Ces derniers cycles conduisent à des évaluations moins divergeantes, autour d'une moyenne supérieure à celle des valeurs du Cycle 1. 

Le modérateur pilote la discussion du groupe, et limite la durée des discussions à 15 ou 20 minutes pour éviter les digressions. Le modérateur doit suivre des pratiques d'organisation efficaces, par exemple commencer et finir la réunion à l'heure, encourager tous les participants à se faire entendre et maintenir un climat impartial et sans jugements. Même si l'anonymat des premières évaluations individuelles peut s'avérer important pour les premiers cycles, les membres de l'équipe doivent finir par jouer cartes sur table et arriver à une conclusion à l'issue d'une discussion ouverte. C'est l'occasion de discuter des tâches pour lesquelles les évaluations variaient de façon considérable. Sinon, le modérateur ne doit pas identifier l'individu qui a produit chaque évaluation finale jusqu'à la fin de la session.

Regroupement des tâches Haut de la page

Le travail n'est pas fini une fois que la réunion est terminée. Le modérateur ou le chef de projet regroupe les tâches du projet et leurs évaluations individuelles dans une seule liste des tâches. Cette personne fusionne également les listes d'hypothèses individuelles, les activités concernant la qualité et les processus, les tâches supplémentaires et les temps d'attente.

Le processus de fusion inclut la suppression des tâches en double et l'obtention d'une moyenne raisonnable des différentes évaluations des tâches individuelles. "Raisonnable" ne veut pas dire que les évaluations de l'équipe vont être remplacées par les valeurs que le chef de projet préfère. D'importantes différences d'évaluation pour des tâches à première vue similaires peuvent indiquer que les évaluateurs ont interprété l'activité de façon différente. Par exemple, deux personnes peuvent avoir la même activité appelée "Implémenter une classe." Cependant, un évaluateur peut avoir inclu les tests unitaires et la révision du code dans la tâche, tandis qu'un autre pensait seulement à l'effort de codage. Tous les évaluateurs doivent définir leurs activités clairement afin de limiter la confusion pendant l'étape de fusion. L'étape de fusion doit retenir une plage d'estimations pour chaque tâche, mais si une évaluation de la tâche est complètement différente de celle des autres évaluateurs, essayez de comprendre pourquoi et/ou envisagez de l'écarter et/ou de la modifier.

Revue des résultats Haut de la page

Lors de l'étape finale, l'équipe d'évaluation revoit le résumé des résultats et parvient à un accord sur le résultat final. Le chef de projet fournit aux autres évaluateurs la liste des tâches finale, les évaluations individuelles, les évaluations cumulées, la liste d'hypothèses et toute autre information. Réunissez à nouveau l'équipe pour une réunion de revue de 30 à 60 minutes pour mettre un terme à l'activité d'évaluation. Cette réunion est également l'occasion pour l'équipe d'examiner cette exécution du processus Wideband Delphi et de suggérer des moyens de l'améliorer pour de futures applications.

Les participants doivent s'assurer que la liste finale des tâches est aussi complète que possible. Ils peuvent avoir pensé à d'autres tâches depuis la réunion d'évaluation, lesquelles pourraient être ajoutées à la liste de tâches à ce stade. Assurez-vous que les tâches pour lesquelles les évaluations individuelles divergeaient fortement ont été fusionnées de manière censée. L'objectif de l'évaluation est de produire une plage d'évaluation qui permette au chef de projet et aux autres parties prenantes de passer à la planification et à l'exécution du projet avec un niveau de confiance acceptable.

Finalisation de l'évaluation Haut de la page

Le processus d'évaluation est terminé lorsque les critères d'achèvement spécifiés sont remplis ; vous pouvez alors êtresatisfait et passer à autre chose. Parmi les critères d'achèvement Wideband Delphi classiques, on peut citer :

La liste globale des tâches a été constituée.

Vous disposez d'une liste résumée des hypothèses d'évaluation.

Les évaluateurs sont parvenus à un consensus sur la façon dont leurs évaluations individuelles ont été synthétisées dans un seul ensemble, constituant une plage acceptable.

Maintenant, vous devez décider de ce que vous allez faire des données. Vous pourriez simplement faire une moyenne des évaluations finales pour parvenir à une évaluation unique, ce qui est ce que la personne qui a demandé l'évaluation veut probablement entendre. Toutefois, une simple moyenne sera probablement trop basse et la conservation de la plage d'évaluation présente un certain nombre d'avantages. Les évaluations sont des prévisions sur le futur, et la plage reflète l'incertitude inhérente au fait de regarder dans une boule de cristal. Vous pourriez présenter trois chiffres : la moyenne des évaluations en tant que cas prévu, la valeur minimum comme le meilleur cas et la valeur maximum comme le pire cas. Ou vous pourriez présenter la valeur moyenne comme le résultat nominal escompté, plus la valeur maximum-moins-la-moyenne, et moins la valeur moyenne-moins-la-valeur-minimum.

Chaque évaluation a une certaine probabilité de se révéler vraie, ainsi un ensemble d'évaluations forme-t-il une répartition de probabilité. Au chapitre 6 de "A Discipline for Software Engineering" (Addison-Wesley, 1995), Watts Humphrey décrit une façon mathématiquement précise de combiner des évaluations multiples et leurs incertitudes pour générer une évaluation globale avec des intervalles de prédiction supérieur et inférieur. Une autre approche complexe consiste à exécuter une simulation Monte Carlo pour générer une répartition de la probabilité des résultats d'évaluation éventuels en fonction des valeurs d'estimation finales.

Alors que les résultats d'une session Delphi pourraient ne pas être ce que les grands pontes veulent entendre, ils peuvent décider s'ils veulent planifier leurs projets avec un niveau de confiance de 10 pour cent, un niveau de confiance de 90 pour cent ou un niveau qui se situe quelque part entre les deux. N'oubliez pas de comparer les résultats réels du projet avec vos évaluations pour améliorer votre précision d'évaluation à l'avenir.

Répétition (Itération) Haut de la page

L'un des aspects attrayants de cette méthode, c'est qu'après une évaluation de départ plutôt approximative (par exemple, pendant le lancement), les évaluations peuvent s'affiner à chaque phase (ou même à chaque itération). Le processus peut être plus rapide si les mêmes évaluateurs sont disponibles, et s'ils reprennent leur cycle d'évaluation là où ils l'avaient précédemment laissé. On dispose de davantage d'informations sur le problème, certaineshypothèses ont été modifiées, une architecture est en place pour décomposer l'effort.

La nouvelle estimation peut donner une plage moins large, mais pas nécessairement dans la plage d'estimation précédente : elle peut se trouver plus haut ou plus bas. Si elle est plus haut, cela est un avertissement clair pour le chef de projet qu'il y a un risque et que ce risque doit être maîtrisé immédiatement.

Wideband Delphi évalué Haut de la page

Aucune méthode d'estimation n'est parfaite ; si c'était le cas, on l'appellerait méthode de prédiction, non pas d'évaluation. Toutefois, la technique Wideband Delphi intègre de solides principes d'évaluation. L'approche par équipe prend en compte l'intérêt de combiner les avis de divers experts. La plage des évaluations produite reflète la variabilité intrinsèque au processus d'évaluation.

Bien qu'elle prenne du temps et nécessite un panel d'évaluateurs chevronnés, la méthode Wideband Delphi permet d'éliminer les aspects politiques de l'évaluation, ainsi que certaines valeurs de départ extrêmes.

RUP (Rational Unified Process)   2003.06.15