Ecrit pour RUP par Karl Wiegers (www.processimpact.com), avec l'autorisation de Software Development Magazine.
Adapté par Rational Software Corporation.
Introduction
Ces instructions 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é. Tout d'abord, elle permet d'établir une liste complète de tâches ou une structure de répartition du
travail pour les tâches principales, car chaque participant réfléchira aux diverses 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 autoproclamé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 tâche 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 tâche complexe.
Mise en oeuvre de la méthode Wideband Delphi
La méthode Wideband Delphi peut être utilisée 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 tâches du projet : une liste de tâches associées de qualité, de processus et supplémentaires ; des
hypothèses d'évaluation, ainsi qu'un ensemble de tâches et d'évaluations globales de projet, à raison d'une par
participant.
La figure 1 illustre le flux 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 de tâches 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 de tâches plus complète, ainsi que d'un ensemble d'estimations révisé. Le modérateur ou le
responsable 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.
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 de tâches initiales. Au cours de la réunion d'évaluation, plusieurs cycles mènent à la mise
en place d'une liste de tâches 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
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 la
tâche 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 la tâche, le responsable 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
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 à la tâche
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 responsable de projet est en mesure de participer à la session.
-
Les évaluateurs disposent des informations dont ils ont besoin pour y participer efficacement.
Préparation individuelle
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 tâches, car quelqu'un devra fusionner les listes de tâches 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.
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 responsable 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 tâches 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 tâches 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 tâches 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 servi à 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 instructions suivantes :
-
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
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 divergentes. 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.
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 divergentes.
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 leurs 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". On
peut faire 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 divergentes, 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'à ce
que les conditions suivantes soient réunies :
-
vous arrivez à la fin des quatre cycles
-
un écart acceptable (défini par avance) sépare les différentes évaluations
-
le temps attribué à la réunion est écoulé (deux heures, en général)
-
les participants ne veulent pas modifier leurs évaluations finales
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 divergentes, 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
Le travail n'est pas fini une fois que la réunion est terminée. Le modérateur ou le responsable 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 tâches 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 responsable 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é la tâche de façon différente. Par
exemple, deux personnes peuvent avoir la même tâche appelée "implémenter une classe". Cependant, un évaluateur peut
avoir inclus les tests d'unité et la revue du code dans la tâche, tandis qu'un autre pensait seulement à l'effort de
codage. Tous les évaluateurs doivent définir leurs tâches 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
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 responsable 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 à la tâche 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
responsable 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
Le processus d'évaluation est terminé lorsque les critères d'achèvement spécifiés sont remplis ; vous pouvez alors être
satisfait 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 correspond probablement à ce que la personne qui a
demandé l'évaluation veut 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)
L'un des aspects attrayants de cette méthode réside dans le fait 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, certaines hypothè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 haute, cela constitue un avertissement clair pour le
responsable de projet qu'il y a un risque et que ce risque doit être maîtrisé immédiatement.
Wideband Delphi évalué
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
tient compte de l'intérêt qu'il y a à 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.
|