Les méthodes « agiles »

Les systèmes d’information ont beau gagner en complexité, les temps de

développement n’en sont pas pour autant extensibles. L’amélioration du
processus de production logicielle tient un peu de la révolution perma-
nente. Du moins, depuis les années 1980, quand l’émergence du RAD a
marqué le début d’un renouveau méthodologique, bousculant les modes de
gestion classique du cycle de vie logiciel en cascade ou en « V ». Les
anciennes pratiques ont ainsi dû s’effacer devant des approches plus adap-
tées aux nouvelles technologies, soucieuses de qualité et souvent rompues
au traitement itératif.

26. Société de conseil en management.

Manager un projet informatique

Cette relative diversité méthodologique n’est pas surprenante, car l’idée

d’une méthode universelle semble illusoire. Ainsi, si l’on souhaite
simplement rationaliser et documenter le processus de déve- loppement de
l’entreprise, l’approche EFQM27, fondée sur les préceptes de la norme ISO
9001, est un bon point de départ. Si l’on souhaite se lancer dans une
modélisation UML, soigner l’architecture de ses projets, forma- liser
toutes les tâches, RUP (voir page 68) et ses milliers de pages de docu-
mentation HTML s’avèrent alors approprié. À l’inverse, si l’on doit
conduire des projets très évolutifs, on peut s’intéresser à XP (Extreme
Programming). Ainsi, il est aisé de comprendre qu’une remise en question
périodique permet de rester au plus près des besoins du client.

Méthodes classiques :
Résultats
Début planifiés

Résultats
attendus

Méthodes agiles :
Résultats
Début planifiés

Résultats
attendus
Conformité au planning Conformité aux résultats attendus
 Figure 20. Comparatif des modèles


B ON A SAVOIR
Le résultat obtenu peut présenter un écart important avec
l’expression des besoins initiaux.

27. European Foundation for Quality Management. La fondation européenne pour le manage-
ment par la qualité a pour objectif de promouvoir un cadre méthodologique pour l’évaluation
de l’amélioration de la qualité.
 Gérer un projet de A à Z – Les cycles de vie

Les années 1990 ont donc vu s’affirmer deux lignées de méthodes, les
unes dites « unifiées » (UP, RUP, EUP, 2TUP, etc.), les autres appe- lées
« agiles » (XP, Crystal, ASD, Scrum, etc.). Néanmoins, certains des
principes fondamentaux à la base de toutes ces méthodes trouvent leurs
racines dans la méthode RAD.

C ONSEIL Ces méthodes nécessitent de développer de façon itérative

et incré-mentale sur la base de composants, d’établir une bonne communication
entre
les acteurs de l’équipe de développement, de gérer les exigences et les risques
tout au long du projet, enfin de recourir fréquemment au test logiciel.

Les méthodes actuelles tendent à recréer artificiellement la coupure entre

le processus de développement et la démarche qualité. C’est notamment
vrai pour les méthodes agiles, qui considèrent le test comme une
discipline propre au processus de fabrication logicielle et préconisent d’y
recourir de façon intensive dans toutes les itérations de développement.
Ceci est tout autant valable pour les méthodes unifiées. En définitive, la
ligne de partage entre méthodes unifiées et agiles est d’autant moins
perceptible que la tendance est au rapprochement, voire à l’hybridation
des méthodes. À ce titre, Rational Software avait tenté de marier la
rigueur architecturale de RUP à la souplesse de XP, en complétant le
premier par une extension du second.
Apparue dans les années 2000, la méthode agile est un outil de dévelop-
pement informatique permettant de concevoir des logiciels en impli-
quant au maximum le demandeur (maître d’ouvrage), ce qui permet
d’offrir une grande réactivité à ses demandes.


B ON A SAVOIR
Les méthodes agiles se veulent plus pragmatiques que les
méthodes traditionnelles. Elles visent la satisfaction réelle du besoin du client
et non d’un contrat établi préalablement.

Les valeurs composant ces méthodes sont les suivantes :

 priorité aux personnes et aux interactions sur les processus et les outils ;
 applications fonctionnelles plutôt que documentation exhaustive ;
 priorité à la collaboration avec les utilisateurs plutôt qu’aux négocia-
tions contractuelles ;
 acceptation des changements plutôt que planning détaillé.
 Manager un projet informatique

Les méthodes sont donc orientées vers la satisfaction du client en privilé-

giant la coopération, la simplicité et la communication. La motivation et
la confiance des équipes d’experts techniques permettent de maintenir un
effort continu tout au long du projet. Le tableau suivant permet d’identi-
fier la situation des différentes méthodes connues à ce jour.

Maturité Description Méthode

Émergence Apparue il y a peu de temps, Agile Modeling28
pas encore assez de retour
d’expérience sur le sujet.
Qualification Reconnues grâce à de nom- FDD, Crystal, Scrum, ASD
breuses expériences et métho-
des identifiables.
Une communauté est en cours
de constitution.
Active Largement diffusées, ces métho- XP, DSDM
des ont déjà été éprouvées.

Figure 21. Synthèse des méthodes « agiles »

Le modèle « ASD »
Le modèle ASD (Adaptative Software Development) s’adresse tout
particulièrement aux projets e-business. Ceux-ci doivent souvent être
réalisés en des temps très courts, supporter de nombreux changements
et incertitudes.
1. Les principes
Les principes qui guident ce modèle sont au nombre de cinq :
 Focalisation : il est nécessaire de viser les résultats à obtenir plutôt
que les tâches.
 Itération : la conception se fait de façon itérative et incrémentale, ce
qui permet aux composants d’évoluer en fonction des retours
d’information des utilisateurs.

28. Non traitée dans le présent ouvrage.

 Gérer un projet de A à Z – Les cycles de vie

 Échéances (timeboxing) : le temps est découpé de manière à obtenir

des dates butoirs de livraison. Chaque échéance correspond à la fin
d’une itération ou du projet. Ce procédé permet de forcer la prise de
décisions difficiles, ainsi que de réévaluer constamment la validité de
la mission.
 Gestion des risques : ils sont nécessaires dans la mesure où le type deprojet
géré répond à des contraintes de délais serrés, absence totale de
stabilité dans les besoins et des exigences de qualité. Il est donc
impératif d’analyser tous les risques critiques qui pourraient mettre le
projet en péril.
 Changement : la capacité à supporter un changement fonctionnel ou
technique en cours de développement est considérée comme un
avantage concurrentiel par la méthode ASD.
2. Cycle de vie
Il est composé de trois phases : spéculer, collaborer et apprendre.
La phase de spéculation comprend les tâches d’initiation et de planification
réparties en sept étapes.
 Conduite de la phase d’initiation du projet : l’initialisation du projet
se rapproche des méthodes traditionnelles. Elle prend en compte les
objectifs, l’étude des contraintes, le plan opérationnel du projet,
l’identification des intervenants, les exigences de la maîtrise
d’ouvrage, une première estimation de la charge relative au projet,
ainsi que les risques critiques. La bonne méthode consiste à centra-
liser toutes ces informations.
 Détermination de la date de fin de projet : à partir du travail
d’initialisation, il sera nécessaire de définir le temps imparti au
projet.
 Détermination du nombre optimal d’itérations et de leurs échéances :
le nombre d’itérations idéal est défini par les intervenants auxquels est
associée une durée (à titre indicatif, de l’ordre de quatre à huit
semaines) à adapter à chaque projet.
 Définition du contenu de chaque itération : la thématique abordée
dans chacune permet de donner une visibilité globale du projet.
 Manager un projet informatique

 Définition des composants : chaque cycle produit un composant

visible par la maîtrise d’ouvrage.
 Affectation des technologies à chaque itération : l’affectation d’un
composant à une itération se fait de telle sorte que la maîtrise
d’ouvrage y trouve une fonctionnalité utile à chaque livraison et que
le maître d’œuvre puisse optimiser la gestion des ressources.
 Inventaire des tâches à réaliser : pour en assurer une bonne réparti-
tion, la meilleure façon de procéder consiste à définir un tableau
présentant les composants à réaliser et les itérations. Par expérience,
lorsque le tableau est réalisé par l’ensemble des intervenants et non
pas seulement par le chef de projet, la compréhension du projet est
améliorée.
C’est au bout de cette première phase que sont livrés les composants.
Toutefois, les développeurs ne sont pas les seuls à travailler. En effet, le
chef de projet doit s’assurer que la collaboration est optimale et que la
communication circule bien entre les membres de l’équipe. Sa tâche
est d’autant plus difficile lorsque le personnel est disséminé (localisé ou
situé) en des lieux différents. Le schéma idéal préconiserait la proxi-
mité de tous les membres de l’équipe pour accroître l’efficacité de la
production.
Enfin arrive la phase d’apprentissage. Le modèle ASD base ses fondements
sur la qualité, base indéniable de retours d’expériences collectives. Ainsi,
en fin de cycle d’itération, le recueil d’apprentissage peut être enrichi de
quatre types de connaissances.
 Vue de la maîtrise d’ouvrage : le principe consiste à donner une certaine
visibilité du projet à la maîtrise d’ouvrage, puis de recueillir ses impres-
sions. Cette action peut être réalisée lors de réunions destinées à analyser
l’aspect fonctionnel de l’application, ainsi que les nouvelles demandes
qui en émanent.
 Revue technique : elle permet d’évaluer la qualité technique de la
solution. Les tests ne font pas partie de cette étape, dans la mesure
où ils sont réalisés tout au long du processus de dévelop- pement.
 Gérer un projet de A à Z – Les cycles de vie

 Vue de l’équipe : il s’agit d’analyser le mode de fonctionnement de

l’équipe afin de répondre à quatre questions (« qu’est-ce qui fonc-
tionne bien ? », « qu’est-ce qui ne fonctionne pas encore ? », « sur quoi
devons-nous insister ? », « que devons-nous réduire ? »). Ce procédé
permet à tous les intervenants de faire leur propre bilan.
 Vue de progression du projet : pour cet aspect non qualitatif, il faut
déterminer l’état d’avancement du projet en réétudiant le planning.
Les questions à se poser pourraient être : « où en est le projet ? »,
« où en est-il par rapport à ce qui était prévu ? », « où devrait-on
être ? ».
L’approche « composant » permet de faciliter cette analyse. Mais celle- ci
ne doit pas se contenter de stipuler si un composant est terminé ou non,
mais bien de préciser l’état réel d’avancement.

finale

Figure 22. Cycle ASD (d après Adaptative Software Development)

Le modèle ASD est une méthode « agile » dans la mesure où il en reprend

les caractéristiques essentielles : souplesse dans le changement, rapidité,
respect des délais, implication de la maîtrise d’ouvrage, etc.


B ON À SAVOIR
Cette méthode nécessite toutefois d’être adaptée à chaque
projet et, selon le contexte, d’être enrichie d’autres caractéristiques des
diverses méthodes « agiles ».
 Manager un projet informatique

Le modèle « DSDM »
Le modèle « DSDM » (Dynamic Software Development Method) date
de 1994. Son principe de fonctionnement est basé sur une étroite colla-
boration entre les utilisateurs et les équipes de développement. Ces
dernières doivent disposer d’un pouvoir de décision de façon à pouvoir
s’adapter aux besoins et aux délais, ce qui permet de réaliser la livraison
rapide des fonctionnalités demandées.


B ON A SAVOIRLe modèle « DSDM » facilite la réversibilité des évolutions
fonctionnelles mises en place.

Ce mode de fonctionnement permet un développement itératif et

incrémental garantissant une solution au plus près des attentes des
utilisateurs. Les livraisons rapprochées dans le temps nécessitent des tests
plus fréquents des fonctionnalités mises en place et évitent ainsi des tests
finaux susceptibles de présenter des dysfonctionnements pouvant
s’avérer désastreux pour le projet. La gestion du temps (time- boxing)
constitue la caractéristique principale de ce cycle de vie, dans la mesure
où toute itération est définie par une date de début et une autre de fin.

Expression
des besoins

Faisabilité

Spécifications Mise en

Développement
itératif

Figure 23. Cycle DSDM

 Gérer un projet de A à Z – Les cycles de vie

Le cycle de vie « DSDM » propose une gestion de projets très efficace et

rapide. Selon le consortium DSDM, 80 % d’une solution finale d’un
projet sont réalisés en 20 % de temps. Cette méthode permet d’améliorer
les performances de développement, mais aussi de perfectionner la
gestion de projet grâce à un meilleur management humain.

C ONSEIL Le modèle « DSDM » ne préconise pas de règles de conduite

strictes, mais doit être adapté à chaque nouveau projet.

Sa mise en œuvre peut toutefois s’avérer difficile si toutes les personnes

impliquées dans le projet ne sont pas formées à la méthode ou n’adhè-
rent pas au projet.


B ON A SAVOIR
Le cycle « DSDM » convient pour des projets de tailles
moyenne et grande, dès lors qu’une seule personne expérimentée en assure
la conduite.

Le modèle « FDD »
Pour réduire les risques dans les projets de développement, le modèle
« FDD » (Feature Driven Development) propose la mise en place
d’itérations très courtes (deux semaines environ) avec, à chaque fois, la
production d’un livrable fonctionnel. À plus d’un titre, ce modèle est
intéressant pour :
 les développeurs : motivant, car chaque livrable est rapidement
utilisable ;
 le chef de projet : sécurisant, car l’état d’avancement est directement
visible au gré des itérations ;
 le client : satisfaisant, car concret, donnant une vision claire du plan-
ning et des différentes étapes du projet.
Les caractéristiques (features) de l’application constituent les princi- pales
bases de la méthode « FDD » pour la conception et le dévelop- pement.
Le découpage applicatif en fonctions élémentaires permet à la maîtrise
d’ouvrage d’exprimer simplement ce qu’elle attend et aux développeurs
de mieux comprendre le domaine et la façon dont les choses sont liées.
 Manager un projet informatique

Définition d’un
modèle global

fonctionnalité

Développement

Linéaire Itération
Figure 24. Cycle FDD

Les principes de la méthode « agile » sont bien perceptibles à travers cette

méthode. Vous y retrouverez les caractéristiques de gestion des risques, de
flexibilité par rapport au changement, de rapidité, de livraisons fréquentes.
Chaque composant étant souvent réalisé par des personnes différentes,
la maintenance de l’ensemble peut parfois se muer en un challenge
quotidien. La programmation des composants par binôme peut donc
s’avérer une solution plus souple et moins risquée.

Le modèle « Crystal »
Il présente tous les avantages des méthodes « agiles » : flexibilité par
rapport au changement, rapidité, livraisons fréquentes, etc. Ce modèle
est plus particulièrement adapté aux petites structures (moins de six
personnes), ce qui augmente son efficacité dans les petits projets, mais
cause son inadéquation pour des projets plus importants.
1. Valeurs
Les valeurs partagées par les équipes reposent sur différents paramètres.
Ainsi, la communication, la promiscuité des développeurs et les
rencontres avec les utilisateurs sont encouragées pour améliorer la qualité
des échanges.
 Gérer un projet de A à Z – Les cycles de vie

Les livraisons périodiques, elles, permettent aux utilisateurs de prendre

progressivement possession des fonctionnalités mises à leur disposition.
La souplesse, enfin, est le dernier paramètre. Vu la taille de l’équipe,
les normes et les procédures sont peu, voire quasi inexistantes, ce qui
autorise plus de latitude à chaque développeur pour agir dans ses
réalisations.
2. Processus
Le processus utilisé par le modèle Crystal se décline en quatre étapes :
 Spécification : l’utilisateur est observé dans son « élément naturel »pour
recueillir les besoins. Ces derniers sont classés, puis priorisés, ce qui
permet de valoriser (aux yeux des utilisateurs) les fonctionnalités à
mettre en œuvre.
 Conception : le choix des technologies et de l’architecture est défini
pour donner une première vision globale du projet.
 Planning : la planification des fonctionnalités est réalisée de façon àne
pas dépasser une période de deux à trois mois.
 Itération de développement.

La conception détaillée est affinée avec les utilisateurs au cours de

discussions informelles. Cette phase permet d’établir le plan d’action
des développeurs qui, au bout de deux semaines, présente- ront une
maquette aux utilisateurs pour valider le scénario fonc- tionnel retenu.
Les développements sont ensuite terminés par une équipe de deux ou
trois personnes pour augmenter la qualité du code écrit et garantir des
tests unitaires et d’intégration fonction- nelle optimale.
Au cours d’un cycle d’itération, deux ou trois présentations aux utilisa-
teurs viennent recadrer le projet pour éviter toute dérive et assurer la
conformité avec les exigences des utilisateurs. De plus, un manuel destiné
à ces derniers est rédigé avant le lancement de l’itération suivante. Enfin,
une dernière vague de tests est réalisée avant la mise en production.
 Manager un projet informatique

détaillée

Conception

Figure 25. Cycle Crystal