Vous êtes sur la page 1sur 32

Conservatoire National des Arts et Métiers (Rennes)

Enseignant : Mrs Dupuis eric

L e s M é t h o d e s Agiles
Génie logiciel 2004/2005
Dagorne emmanuel

J’ai commencé par bidouiller pas mal,

Ensuite, j’ai longtemps essayé de suivre des principes de génie logiciel,

J’ai changé d’avis et désormais je veux devenir extrêmement Agile.

Dessins et légendes page de garde Christophe THIBAUT praticien http://xp-france.net/ avec


son aimable autorisation
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Table des matières


1 Introduction 3

2 Evolution des méthodologies 4


2.1 Le chaos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Les méthodologies lourdes (dites prédictives) . . . . . . . . . 4
2.2.1 Le modèle en cascade Waterfall (Royce 1970) . . . . . 5
2.2.2 Le modèle en spiral (Bohem 1988) . . . . . . . . . . . 6
2.3 Les méthodologies modernes . . . . . . . . . . . . . . . . . . . 6
2.3.1 RAD (Rapid Application Development) . . . . . . . . 6
2.3.2 Les méthodes unifiées . . . . . . . . . . . . . . . . . . 7

3 Les méthodes Agiles (dites adaptatives) 7


3.1 Qu’est-ce que le développement Agile? . . . . . . . . . . . . . 7
3.2 Agile Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Les quatre valeurs . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4 Principes sous jacents du Manifest Agile . . . . . . . . . . . . 10

4 Les méthodologies 11
4.1 XP (Extrem programming) . . . . . . . . . . . . . . . . . . . 11
4.1.1 Les quatre valeurs . . . . . . . . . . . . . . . . . . . . 11
4.1.2 Les pratiques . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3 Cycle de vie idéal d’un projet XP . . . . . . . . . . . . 14
4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Crystal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Les valeurs . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Les trois phases . . . . . . . . . . . . . . . . . . . . . . 17
4.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 ASD (Adaptative Software Development) . . . . . . . . . . . 18
4.3.1 Les six caractéristiques . . . . . . . . . . . . . . . . . . 18
4.3.2 Les étapes . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.4.1 Les trois phases . . . . . . . . . . . . . . . . . . . . . . 21
4.4.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 23
4.5 FDD (Feature Driven Development) . . . . . . . . . . . . . . 23
4.5.1 Les cinq phases . . . . . . . . . . . . . . . . . . . . . . 23
4.5.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 25
4.6 DSDM (Dynamique Softwar Development Methode) . . . . . 25
4.6.1 Les neuf principes fondamentaux . . . . . . . . . . . . 26
4.6.2 Processus de développement . . . . . . . . . . . . . . . 27
4.6.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 29

1
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

5 Synthèse du thème 30

6 Références 31

2
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Les méthodes d’ingénierie offrent des modèles pour construire


les produits et des démarches pour guider les processus. Dans le
passé, les méthodes ont mis l’accent sur les modèles au détriment
des démarches. Aujourd’hui, l’intérêt porte d’avantage sur les
processus qui assurent le développement des produits de l’ingénierie.
C’est à travers le processus que les ingénieurs  injectent  la
qualité dans leurs produits, qu’ils peuvent réduire les délais de
mise sur le marché, qu’ils peuvent contrôler (et réduire) les coûts
de production (Rolland, 1996).

1 Introduction
D’après une étude américaine de The Standish Group menée en 1994 sur
8000 projets, 16% d’entre eux n’ont pas respecté les délais et le budget initial,
et pire, 32% n’ont jamais abouti. Une autre étude menée par le même groupe
en 2000 montre une amélioration par rapport à 1994 puisque le taux d’échec
des projets passe de 31 % à 23%. En revanche, la moitié des projet sont
hors délais ou/et hors budget, ce qui laisse un quart seulement des projets
réussis. Les méthodes de développement Agiles sont-elles une réponse au cli-
mat économique dans lequel nous vivons? Les temps de développement sont
trop longs. Lorsque le système informatique est enfin livré, l’environnement
de l’entreprise a lui déjà largement évolué. Si le système correspondait aux
besoins initiaux, il ne répond plus aux besoins actuels. Il est déjà obsolète
avant d’être utilisé. Les applications livrées ne répondent pas aux besoins
des utilisateurs, parce que les utilisateurs n’ont pas participé suffisamment
à l’élaboration de leur outil. Les équipes modernes doivent intégrer la lo-
gique du marché, ou encore le client en personne. Les personnes chargées du
développement sont trop rarement consultées par les analystes et les concep-
teurs. Le développeur a trop peu d’influence sur l’architecture du produit.
Une équipe responsable et décloisonnée doit prendre en compte les connais-
sances spécifiques de tous ses membres. Enfin, quand un produit connaı̂t
des difficultés de fonctionnement, personne n’est capable de diagnostiquer
le problème, dans la mesure où personne ne possède une vue complète de
l’outil depuis le système opératoire jusqu’à son application dans l’entreprise.
Les apports individuels à la réalisation du système sont trop fragmentés et
l’environnement de fonctionnement trop fragile. Il faut admettre que chaque
industrie a ses spécificités et tout particulièrement l’informatique, étrange
mélange de science et d’artisanat. Cependant, une chose est certaine, la
réalisation d’applications informatiques doit s’accélérer pour rattraper la vi-
tesse à laquelle les technologies et les marchés évoluent.

3
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

2 Evolution des méthodologies


2.1 Le chaos
Le chaos, issu de l’age préhistorique de l’informatique, et toujours ap-
pliqué dans certain cas, consiste à écrire l’application sans véritable plan
de développement. La conception du logiciel s’effectue avec une multitude
de décision à court terme avec comme activité principale,  le codage et le
debugage . Lorsqu’il s’agit d’une petite application, avec une ou deux per-
sonnes pour la développer et que le temps de développement ne dépasse pas
quelques semaines, cette manière de faire peut se montrer adéquate. Dans
ce type de développement, les développeurs ont déjà une vision d’ensemble
de ce qu’ils doivent faire. Ils avancent alors étape par étape en faisant des
retours vers l’utilisateur final pour une validation, des corrections de bugs
ou de petites erreurs de présentation.

Les avantages pour utiliser cette  non méthode  sont nombreux. Par
exemple, elle ne demande que des compétences d’un seul type, analyste pro-
grammeur, qui feront à la fois le travail de conception et le codage. Un autre
avantage est la simplification du suivi du projet.

Si la taille du projet a été mal estimée ou si le projet grossit avec le


temps, cette manière de faire n’est plus adaptée. En effet, plus un système
développé dans le  chaos  est important, plus il est difficile à débuger et
à tester. Le symptôme typique de cette maladie est une très longue phase
de test qui rend alors impossible toute planification, étant donné que les
activitées de test et de débugage sont imprévisibles.

Cette manière de faire est insuffisante si l’on veut obtenir des logiciels
de qualité. En effet, il faut une gestion d’équipe et une planification moyen
et long terme que n’offre pas cette  méthodologie  du chaos.

2.2 Les méthodologies lourdes (dites prédictives)


L’évolution mit à jours  les méthodologies  qui imposent un proces-
sus discipliné sur le développement logiciel avec comme objectif de rendre
le développement logiciel plus prévisible et plus efficace. On se base ici sur
un processus détaillé qui met en valeur la planification inspirée par d’autres
disciplines d’ingénierie. On met en avant la planification en détail de grosses
parts du processus logiciel pendant une durée importante avant la construc-
tion, ce qui fonctionne correctement quand il y a peu de changements.

4
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

On sépare donc deux activités fondamentalement différentes : le design


(la conception), difficile à prévoir et demande du personnel créatif et bien
formé et la construction qui demande des ressources moins qualifiées. Pour
que ce type d’organisation fonctionne, il faut que le design du logiciel per-
mette un codage relativement simple une fois que le travail est planifié. De
nos jours, la conception est souvent définie en formalisme de type UML.
Avec cette manière de penser, les personnes qui sont impliquées dans le pro-
jet peuvent être remplaçables ; ce sont leurs rôles qui ont une importance
(chef de projet, analyste, codeurs, testeurs). Etant donné que tout est bien
documenté, on peut supposer pouvoir placer des compétences sur des tâches
à effectuer : lors de la conception, on se concentre sur le type et le nombre
de ressources.

Ce type de méthodologie s’appuie toujours sur un même squelette clas-


sique : analyse des besoins, analyse technique, conception, intégration, tests.

2.2.1 Le modèle en cascade Waterfall (Royce 1970)


Ce modèle est extrêmement rigoureux et se base sur le fait qu’on a une
spécification compléte de la tâche à accomplir : il consiste à faire progresser
un projet étape par étape, de la conception initiale au déploiement, chaque
phase faisant l’objet d’un examen final avant de passer à la suivante. Il est
difficile de faire marche arrière.

Lorsqu’on utilise cette méthodologie, on a une très bonne visibilité des


différentes phases du processus. On travail de manière très structurée, ce
qui permet de placer des profils différents sur chaque étape. C’est parti-
culièrement intéressant pour de grandes équipes multi profils. Les étapes
peuvent être réparties dans le temps : il est tout à fait envisageable de faire
l’étude fonctionnelle visant à fournir le cahier des charges et d’attendre
ensuite relativement longtemps avant d’entamer le développement à pro-
prement parler. Le principe de travailler avec un but final connu a permis
d’envisager plus facilement l’application comme étant composée de plusieurs
modules distincts que l’on intègre à la fin.

Cette méthodologie est bureaucratique, le travail à fournir pour suivre


l’avancement du développement est tel qu’il ralenti le développement, et la
documentation à fournir est très importante. Un design sous un formalisme
actuel considéré comme livrable aux programmeurs peut être joli sur le pa-
pier mais difficile, voir absurde à programmer. De plus, il n’y a pas vraiment
de méthode de contrôle possible sur ce design, si ce n’est la relecture par un
autre designer et il n’est pas rare de ne trouver les incohérences ou erreurs
qu’au moment du codage, voir des tests.

5
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Dans de nombreux cas, le client n’a pas consacré assez de temps à la mise
en oeuvre de son cahier des charges, et en cours de route il se rend compte
souvent qu’il désire des modifications qui rendent les besoins fluctuants et
par conséquent imprévisibles au départ. L’autre possibilité est que, malgré
une expression des besoins correct, la fluctuation dans le monde du busi-
ness rend de nombreux changements imprévisibles et il se peut qu’une très
bonne expression des besoins ne se retrouve plus totalement en phase avec
le marché six mois plus tard.

Tout en restant dans le même ordre d’idée de méthodologies lourdes, une


variante de la cascade, le cycle en V apporte une évolution, en associant les
phases de la descente avec les phases de la remonté.

2.2.2 Le modèle en spiral (Bohem 1988)


Ce modèle tient compte de la possibilité de réévaluer les risques en cours
de développement; il présente le développement comme une succession de
cycles en waterfall, où à chaque itération les risques sont analysés, un pro-
totype est conçu, réalisé et testé. Grâce au prototypage itératif, le produit
prend la place centrale qu’il doit avoir dans le cadre d’un projet. le client peut
recevoir un rôle de choix, puisqu’il peut être plus facilement intégré dans le
processus de modélisation comme par exemple lors de la phase d’évaluation.

Cette approche offre beaucoup de réactivité et permet de s’assurer de la


rationalité d’un projet au fur et à mesure de sa réalisation, de plus il met
en avant la communication et l’échange avec le client.

La part importante accordée à l’analyse des risques apport cependant


une certaine complexité et nécessite des compétences externes aux informa-
ticiens. Enfin, le cycle en spirale peut donner l’impression que le projet n’est
jamais terminé.

2.3 Les méthodologies modernes


Développement itératif et incrémental :

L’approche itérative est fondée sur la croissance et l’affinement succes-


sifs d’un système par le biais d’itérations multiples, retour d’information
du client et adaptation étant les moteurs principaux permettant de conver-
ger vers un système satisfaisant. Le système croı̂t avec le temps de façon
incrémentale, itération après itération.

2.3.1 RAD (Rapid Application Development)

6
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Ce modèle de développement est né dans les année 1980, il a marqué le


début d’un renouveau méthodologique, en bousculant les classiques modèles
en cascade ou en V et a introduit les bases du développement itératif et
incrémentale. Il est basé sur le développement par interface.

Il tend à raccourcir le cycle de vie, voir à le supprimer. La phase de


spécification/conception est remplacée par une phase de prototypage menée
conjointement avec le client. Cette phase de prototypage débouche sur une
interface validée par le client. A l’aide d’outil, les squelettes de fonctions,
classes, sont générés. Le comportement de chaque objet de l’interface est
ensuite décrit dans un langage approprié et ses fonctionnalités programmées.

RAD a été un des premier modèle a utiliser le développement itératif


et incrémentale, à mettre en évidence l’importance de la communication en
mettant en place le groupe d’animation et de rapport (GAR); ce modèle
accorde aussi une place particulière aux développeurs avec une équipe de
développement autonome le (SWAT). On peut donc le considérer comme
l’un des précurseurs de l’agilité, même si certaines écoles agiles lui reproche
une phase de conception et de modélisation encore trop importante.

2.3.2 Les méthodes unifiées


Les années 1990 ont vu s’affirmer deux lignées de méthodes, les unes
dites unifiée (UP, RUP, EUP, 2TUP, etc.) et les autres agiles. Certains des
principes fondamentaux à la base de ces méthodes trouvent leurs racine dans
le RAD. C’est principes sont le développement itératif et incrémentale, faire
du développement à base de composants, é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 , et de recourir fréquemment au tests.

3 Les méthodes Agiles (dites adaptatives)


3.1 Qu’est-ce que le développement Agile ?
Les méthodes de développement de type agile suivent un mode de dévelop-
pement itératif et incrémental, une planification de projet évolutive et en-
couragent les livraisons fréquentes au client. Leur but est d’augmenter le ni-
veau de satisfaction des clients tout en rendant le travail de développement
plus facile. Les fondements des méthodes agiles résident essentiellement dans
deux caractéristiques.
– Les méthodes agiles sont adaptatives plutôt que prédictives.

Ce type de méthodologie s’efforce de créer des processus qui s’adaptent


et s’épanouissent au changement afin de donner toute leur puissance

7
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

dans des environnements qui demandent de s’accommoder de change-


ments réguliers.

L’idée qui sous-tend à ces méthodologies est que de nombreux pro-


cessus étant imprévisible, il faut pouvoir se doter d’un retour d’in-
formation (feedback) qui nous donne un tableau de bord de la situa-
tion à intervalles fréquents. La clé de ce retour d’informations est le
développement itératif, c’est à dire produire fréquemment une version
du système qui marche mais qui ne possède qu’une partie des fonction-
nalités demandées. Les attentes pour ces versions intermédiaires sont
les mêmes que pour le système final au niveau tests et intégration.

Avec cette manière de travailler, on voit directement les défauts éventuels


et on peut les corriger sans conséquence pour la suite.

– Les méthodes agiles sont orientées vers les personnes plutôt que vers
les processus.

Un pilier de ces méthodologies est de mettre en avant l’idée que les


développeurs eux-mêmes (et pas leurs rôles) sont la pierre angulaire
de la méthodologie.

Prendre cette décision demande un certain changement d’esprit par


rapport aux idées classiques de  ressources ; il ne s’agit plus d’avoir
des designers qui font le travail inventif et des développeurs qui font le
reste, mais bien de ne plus avoir que des développeurs avec plusieurs
compétences qui partagent les responsabilités avec les gestionnaires de
projet.

Le travail du gestionnaire de projet migre quant à lui en partie vers


de la relation avec le client, qui doit s’impliquer beaucoup plus dans
ce type de méthodologie.

3.2 Agile Alliance


En février 2001, les principaux représentants de chacune de ces méthodo-
logies se sont réunis pendant deux jours à Snowbird Utha afin de former
l’Agile Alliance. Il en est ressorti  le manifest pour le développement agile
d’applications , un document à propos des valeurs communes et des prin-
cipes des processus agiles.

8
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Le Manifest

Nous sommes à découvrir de meilleurs manières pour développer


des logiciels en aidant les autres et en développant nous même.
A travers ce travail nous en sommes venus à valoriser:

Individuals and interactions over processes and tools


Personnes et interactions par dessus procédures et outils

Working software over comprehensive documentation


Applications fonctionnelles par dessus documentation pléthorique

Customer collaboration over contract negotiation


Collaboration avec le client par dessus négociation de contrat

Responding to change over following a plan


Acceptation du changement par dessus Planification

En fait, bien que les éléments de droite soient importants,


nous considérons que les éléments de gauche le sont encore plus.

3.3 Les quatre valeurs


L’accent est mis sur les individus et sur une forte cohésion de l’équipe
de développement. Même si les processus et les outils sont importants, l’être
humain doit rester le coeur d’un projet.

La priorité est donnée à la production du logiciel même incomplet, mais


entièrement testé et fonctionnel. La documentation sera réduite au minimum
mais mise à jour régulièrement et d’une documentation permanente du code
lui-même.

Le client collabore directement avec l’équipe de développement en définis-


sant les objectifs importants pour lui et en fournissant un feedback régulier
sur ce qui a été produit afin de réajuster les spécifications.

Une méthode agile doit être conçue pour se nourrir du changement plutôt
que suivre un plan. Déterminer avec précision l’ensemble des besoins dès
le début du projet et un exercice délicat : le développement agile vise à
atteindre un compromis entre les spécifications initiales, sur lesquelles se
fonde le planning, et le résultat final qui bien souvent s’en éloigne un peu,
voir beaucoup.

9
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Figure 1 - Positionnement des méthodes


par rapport aux quatre critères agiles
( source : Business Interactif ).

3.4 Principes sous jacents du Manifest Agile


• Notre plus haute priorité est de satisfaire le client en lui livrant rapi-
dement, et ce, de façon continue un logiciel de qualité.

• Accepter les changements de besoins, même lors du développement.


Les processus agiles exploitent les changements pour augmenter les
avantages compétitifs du client.

• Livrer fréquemment un logiciel fonctionnel, en visant les délais les plus


courts, de quelques semaines à quelques mois.

• Gestionnaires et développeurs doivent travailler ensemble, de façon


quotidienne, sur toute la durée du projet.

• Bâtir des projets autour d’individus motivés. Donner leur l’environne-


ment et le support qu’ils nécessitent et ayez confiance qu’ils feront le
travail.

• La méthode la plus efficace de transmettre l’information à l’équipe de


développement et à l’intérieur de celle-ci est par conversation de per-
sonne à personne.

10
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

• Un logiciel fonctionnel est la mesure principale de l’avancement.

• Les processus agiles favorisent le développement maintenable. Les res-


ponsables, développeurs et les usagers devraient pouvoir conserver un
rythme constant indéfiniment.

• Une attention continue à l’excellence technique et un bon design aug-


mentent l’agilité.

• La simplicité –l’art de minimiser la quantité de travail fait inutilement


–est essentielle.

4 Les méthodologies
Les principales méthodes agiles sont : Extrem Programming (XP), Crys-
tal Clear, Adaptative Software Development (ASD), Scrum, Feature Dri-
ven Development (FDD), Dynamic Software Development Method (DSDM).
Elles ont toutes des caractéristiques en commun, mais il y a des différences
significatives.

4.1 XP (Extrem programming)


Kent Beck et Ward Cunningham ont adopté XP pour la première fois
en 1996, afin de sauver le projet C3, dans la division ressource humaine de
Crysler . XP préconise un déroulement par itération courte et géré collecti-
vement, avec une implication constante du client.
Pour cela, XP repose sur quatre valeurs fondamentales déclinées en principes
et mises en oeuvre par le biais de douze pratiques qui devront être poussées
au maximun.

4.1.1 Les quatre valeurs


1 . La communication

C’est le moyen fondamental d’éviter les erreurs. Le moyen à privilégier


est la conversation direct, en face à face. Les moyens écrits ne sont que
des supports et des moyens de mémorisation.

2 . Simplicité

En extreme programming, la façon la plus simple d’arriver à un résultat


est la meilleure. Prévoir préalablement des évolutions futures n’a pas

11
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

de sens. Ce principe est résumé en une phrase YAGNI (You Arent


Gonna Need It) qui préconise de supprimer tout ce qui est inutile.

3 . Feedback

les itérations sont basées sur les retours d’informations du client, per-
mettant une adéquation totale entre l’application finale et sa demande.

4 . Le courage

Il est nécessaire à tous les niveaux et de la part de tous les intervenants,


notamment chez les développeurs (quand des changements surviennent
à un stade avancé du projet, ou quand des défauts apparaissent) et chez
le client (qui doit donner une priorité à ses demandes).

4.1.2 Les pratiques


– Le jeu de planning

Le client crée des scénarios d’utilisation  user stories . Ces scénarios


seront ensuite classés par valeur apportée au client et par risque de
développement. Ensuite, un certain nombre de scénario seront sélection-
nés pour être développés au cours de l’itération à venir. Puis le plan-
ning de la prochaine release (version) est mis à jour.

– Petites livraisons

Les livraisons doivent être les plus fréquentes possibles, afin d’obtenir
un feedback le plus rapidement possible, tout en offrant des fonction-
nalités complètes. La fréquence de livraison est donc de quelques se-
maines.

– Utilisation de métaphores

on utilise des métaphores et des analogies pour décrire le système et


son fonctionnement, ce qui permet de le rendre compréhensible par les
non-informaticiens, comme les utilisateurs ou les commerciaux.

– Conception simple

L’objectif est de produire une application qui réponde aux attentes


du client. Mieux vaut donc arriver à ce résultat de la manière la plus

12
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

simple possible, en rendant le code simple à comprendre et facile à


modifier, afin de faciliter les évolutions futures. De même, la docu-
mentation doit être minimale, c’est à dire ce qui est demandé par le
client.

– Tests unitaires et fonctionnels

Tests unitaires : Avant d’implémenter une fonctionnalité, il convient


d’écrire un test qui validera l’implémentation (first-test).

Testes fonctionnels : A partir de critères définis par le client, on crée des


procédures de test, souvent automatisées, qui permettent de vérifier
fréquemment le bon fonctionnement de l’application.

– Refactoring du code

Amélioration continue de la qualité du code sans en modifier le com-


portement (commentaire du code, respect des règles de nommage, sim-
plification,etc).

– Programmation en binôme

La programmation se fait par deux. Le premier, appelé  driver , a le


clavier. C’est celui qui va travailler sur la portion de code à écrire. Le
second, appelé  partner , est là pour aider, en suggérant de nouvelles
possibilités ou en décelant d’éventuels problèmes. Les développeurs
changent fréquemment de partenaires, ce qui permet d’améliorer la
connaissance collective de l’application et d ’améliorer la communica-
tion au sein de l’équipe.

– Responsabilité collective du code

L’équipe est collectivement responsable de l’application et est supposée


connaı̂tre l’intégralité du code. Chacun peut également faire des mo-
difications dans toutes les portions du code, même celles qu’il n’a pas
écrit.

– Intégration continue

L’intégralité de ce qui est développé est assemblée à chaque fois qu’une


tâche est terminée, ce qui permet d’avoir toujours une version à jour,
notamment comme livrable ou pour le démarrage de nouvelles tâches.

13
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

– Heures de travail

Afin d’éviter de surcharger l’équipe, elle ne fait pas d’heures supplément-


aires deux semaines de suite. Si le cas se présentait, cela signifierait
qu’il faut redéfinir le planning.

– Client sur site

Afin d’assurer une meilleure réactivité et un feedback rapide, un représen-


tant du client doit être présent pendant toute la durée du projet. Ce
représentant doit avoir les connaissances d’un utilisateur final, mais en
même temps une vision globale du résultat à obtenir.

– Règles de codage

Dans l’optique d’appropriation collective du code et de facilitation de


la communication, il est indispensable d’établir et de respecter des
normes de nommage pour les variables, méthodes, objets, classes, fi-
chiers, etc.

4.1.3 Cycle de vie idéal d’un projet XP

Figure 2 - Les grandes lignes


du cycle de vie d’un projet XP
( source : Business Interactif ).
– Exploration

14
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Les développeurs explorent différentes architectures systèmes. Le client


commence à exprimer ses besoins avec les scénarios d’utilisation.

– Planning

Le jeu du planning est mis en place.

– Itération jusqu’à la première release

C’est la phase de développement. Les fonctionnalités liées à chaque


itération doivent passer les tests avec succès.

– Mise en production

Mise au point de l’application pour pouvoir la mettre au mains des


utilisateurs.

– Maintenance

Il s’agit dans cette phase de continuer à faire fonctionner l’application


et de lui adjoindre les fonctionnalités secondaires qui avait volontai-
rement été mises de coté jusque là . A chaque nouvelle livraison, une
nouvelle phase d’exploration rapide doit avoir lieu.

– Mort

Le projet est considéré comme achevé quand le client n’est plus en


mesure de trouver de nouveau scénario ou lorsque il n’est plus possible
de le modifier.

4.1.4 Conclusion
Extreme Programming offre une véritable opportunité d’assouplir des
méthodes trop rigides en injectant une dose de pragmatisme. L’émergence
et l’enthousiasme soulevé par XP interpelle en tout cas sur la nécessité de
faire évoluer les méthodes traditionnelles pour qu’elles prennent davantage
en compte les contraintes et la réalité du terrain. De part l’autonomie et le
degré de responsabilité élevé attribués aux développeurs, ainsi qu’une place
prédominante donnée à la communication, XP conseil de limiter la taille des
équipes à une douzaine de personnes.

15
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

4.2 Crystal
Plus qu’une méthode, Crystal est avant tout une famille de méthodes.
D’après Alistair Cockburn, le fondateur de cette famille de méthodologie,
plusieurs types de projets demandent différentes types de méthodologies.
Pour ce mémoire nous nous intéresserons à une déclinaison de Crystal, Crys-
tal Clear.

4.2.1 Les valeurs


– Communication

La communication est omniprésente pour réussir le  jeu coopératif


 que représente un projet comme le fait remarquer le créateur de cette

méthode  Software development is a cooperative game, in which the


participants help each other in reaching the end of the game - the de-
livery of the software .

Le nombre de membres d’une équipe est limité à six personnes afin que
l’équipe soit solidaire. Tout les membres de l’équipe doivent travailler
dans une même pièce afin de faciliter la communication par proximité.
Les schémas de modélisation doivent être réalisés en groupe et sur un
tableau blanc car cela améliore la communication et la collaboration.

La collaboration avec le client est elle aussi très importante, notam-


ment grâce à de nombreuses conversations entre utilisateurs et dévelop-
peurs.

– Release fréquentes

Livrer des parties exécutables de l’application le plus fréquemment


possible afin que le client se rende compte du travail en cours et pro-
pose des changements.

– Souplesse

Crystal reste très souple tant au niveau des procédure à suivre que des
normes à utiliser (comme par exemple les normes de codage). Cette
méthode possède une procédure découpée en différentes étapes.

16
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

4.2.2 Les trois phases

Figure 3 - Processus Crystal


( source : Business Interactif ).

– Spécifications

Cette première phase consiste à recueillir les besoins du client et des


utilisateurs et de produire les spécifications qui sont collectées sous
forme de cas d’utilisation rangées par ordre de priorité.

– Conception et planning

Une ébauche de conception est réalisée au tout début du projet, cela in-
clu les choix des technologies à utiliser et implique une ébauche d’archi-
tecture. Le planning consiste à prévoir vers quelles dates les itérations
vont se suivre, Crystal recommande des itérations de 2 à 3 mois, cha-
cune produisant un produit à livrer fonctionnel.

– Itérations

C’est la phase de réalisation de l’application, constituée par les phases


suivantes :

17
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Clarification des spécifications : les spécifications sont affinées lors de


réunion entre utilisateurs et développeurs.
Conception collective : Les développeurs définissent la conception du
système et se répartissent les différentes parties à réaliser. Ensuite une
maquette est produite pour faire plusieurs démonstrations aux utilisa-
teurs durant toute l’itération, afin de réajuster les besoins exprimés.
Rédaction du manuel utilisateur : Fin de l’itération avec intégration et
mise en production de l’application.

Tout au long de l’itération on retrouve des pratiques communes avec


XP, comme les tests omniprésent et le refactoring du code en binôme.

4.2.3 Conclusion
Crystal présente tous les avantage des méthodes agiles : flexibilité par
rapport au changement, rapidité, livraison fréquente, etc. Elle convient tout
à fait pour des petites structures (taille inférieure à six personnes), mais ce
qui fait son efficacité dans les projets de petite taille cause son inadéquation
pour des projets plus importants.

4.3 ASD (Adaptative Software Development)


ASD est une méthode développé par Jim Highsmith, il est avec Martin
Flower l’un des principaux fondateurs du manifeste des méthodes agiles.
ASD met l’accent sur les points délicats du développement adaptatif, en
particulier comment faire naı̂tre la collaboration et l’apprentissage collectif
et individuel dans le projet. Le cycle de vie préconisé par ASD comporte six
valeurs fondamentales et s’appuie sur trois étapes.

4.3.1 Les six caractéristiques


1 . Focaliser sur une mission (mission focussed).
2 . Se baser sur des composants (component-based).
3 . Itérer.
4 . Découper le temps et fixer les deadlines (timeboxing).
5 . Gérer le risque (risk-driven).
6 . Tolérer le changement.

18
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

4.3.2 Les étapes

Figure 4 - Le cycle de vie selon ASD


( source : Business Interactif ).

– Spéculer

La première phase de cette étape est l’initialisation du projet. Au cours


de réunion JAD (Joint Application Development), les données concer-
nant le projet sont collectées afin de déterminer les objectifs du projet,
d’étudier les contraintes, d’identifier les collaborateurs clefs, de rédiger
l’expression des exigences, d’avoir une première estimation de la taille
du projet et d’identifier les risques critiques. La deuxième phase de
cette étape est l’établissement du planning du cycle adaptatif. En pre-
mier lieu, il faut déterminer la date butoir de fin de projet. Ensuite
l’équipe doit décomposer le projet en un nombre optimal d’itération
avec une date de fin pour chacune d’elle. Puis donner une thématique
à chaque itération afin d’apporter une visibilité au projet. Enfin, il
faut affecter les différents composants à développer aux différentes
itérations. La décision de cette affectation se fait en s’assurant que
chaque itération produit quelque chose d’utile au client. Cette phase
est réalisée par l’équipe et non juste par un chef de projet ce qui
améliore la compréhension du projet.

– Collaborer

 Le bénéfice prédominant, le plus puissant, indivisible et révolutionnaire,


dans le cycle de développement adaptatif, est qu’il nous force à confron-
ter les modèles mentaux qui sont à la racine de notre mise en erreur.
Il nous force à estimer de manière plus réaliste nos capacités. 

Jim Highsmith

19
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Lors de cette phase les composants sont réalisés. Durant cette phase
l’accent est particulièrement mis sur la collaboration des acteurs du
projet afin de s’accommoder de l’incertain. L’attention du chef de pro-
jet doit se porter moins sur la dictée de ce que les gens doivent faire,
que sur l’encouragement de la communication afin que les individus ap-
portent eux-même des réponses créatives. Cette collaboration peut être
complétée par l’utilisation de certaines pratiques issues d’XP, comme
par exemple la programmation en binôme ou la propriété collective du
code.

– Apprendre

 Dans un environnement adaptatif, l’apprentissage remet en question


tous les intervenants, ”les développeurs et les utilisateurs” pour qu’ils
examinent leurs suppositions et qu’ils utilisent les résultats de chaque
itération du cycle de développement pour adapter le cycle suivant. 

Jim Highsmith

L’apprentissage est un aspect important et continuel, on peut aussi


supposer que la conception change au fur et à mesure que le développem-
ent progresse. Pour cela ASD préconise la capitalisation des connais-
sances. A la fin de chaque itération, véritable point de synchronisation,
quatre catégories de connaissances peuvent être complétées.

La qualité du point de vue du client: Lors de réunions appelées  cus-


tomer focus group  une version fonctionnelle de l’application est ex-
plorée afin d’obtenir un feedback du client.

La qualité du point de vue technique: A l’aide de revue technique


 technical review  la qualité d’un point de vue technique est évaluée.

Les performances de l’équipe: Au cours de réunion appelé  postmor-


tems , l’équipe et leurs pratiques sont évaluées, afin de forcer les
collaborateurs à apprendre sur eux même et sur la manière dont ils
travaillent.

L’état d’avancement du projet: Il s’agit plus ici de regarder où en


est le projet par rapport au prévision et d’apporter les modifications
nécessaire pour s’adapter aux changements.

4.3.3 Conclusion

20
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

ASD donne les bases fondamentales pour manipuler un processus de


développement adaptatif et appréhender ses conséquences au plus haut ni-
veau notamment sur les plans de l’organisation et du management. Son
caractère très générique demandera d’adapter la méthode au contexte du
projet et éventuellement de l’enrichir avec d’autres pratiques issues d’autre
méthodes. Pour terminer, un point extrêmement intéressant dans ASD et la
phase d’apprentissage. L’auto-adaptativité est réalisée a l’aide de différentes
réunions de fin d’itération, ainsi les pratiques et les processus du projet sont
améliorés, et d’un point de vue plus global, les projets futur aussi. Etant
donné son caractère très générique, la taille des équipes de développement
sera étudiée au cas par cas.

4.4 Scrum
Scrum est née de la coopération de deux sociétés spécialisées dans le
développement objet, ADM et WMARK software, avec la volonté de mettre
en place des processus empiriques, contrôlés par des mesures quantitatives.
Scrum est divisé en trois phases.

4.4.1 Les trois phases

Figure 4 - Vue globale du processus Scrum


( source : Business Interactif ).

– Phase initiale

21
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

La phase initiale est un processus linéaire donc le premier objectif est


de produire un Backlog global regroupant l’ensemble des tâches à effec-
tuer et des fonctionnalités à réaliser, le tout classé par ordre de priorité
décroissante. Ce Backlog sera ensuite mis à jour après chaque itération
afin de réajuster le développement. Dans un second temps, la date de
livraison est défini et l’équipe de développement est mise en place.
Ensuite Les aspects liés aux risques et au budget sont étudiés. C’est
aussi une phase de conceptualisation, où l’architecture du système est
définie.

– Les sprints

C’est une phase non linéaire. Les sprints sont le coeur du développement.

Lors d’une réunion de planification, l’équipe sélectionne un sous-ensemble


du Backlog global. Ce sous-ensemble est choisi par ordre de priorité
ou suivant les besoins d’un module commun. Si plusieurs équipes tra-
vaillent en parallèle , un Backlog est établi pour chacune d’entre elles de
manière cohérente. Tout au long du sprint, chaque membre de l’équipe
a la responsabilité de mettre à jour les éléments du Backlog dont il est
le propriétaire, ceci dans un souci de suivi permanent de l’avancement
du projet.

La durée d’un sprint est de trente jours, pendant lesquels l’équipe qui
développe est protégé de toutes perturbations extérieures, c’est à dire
qu’aucun travail supplémentaire ne peut être ajouté et que le Back-
log ne peut pas être modifié. C’est un processus empirique, beaucoup
des processus de la phase de sprint sont inconnus et non identifiés.
Ce n’est pas pour autant qu’il n’existe aucune surveillance, tout au
long du sprint des contrôles et des mesures doivent être mis en place
pour évaluer l’avancement du projet ou les déviations afin d’apporter
les réglages nécessaires. Cette évaluation est faite à l’aide de quatre
variables : coût, planning, fonctionnalités et qualités.
Chaque jour, l’équipe de développement organise une réunion nommée
Scrum  mêlée de rugby  d’où le nom de la méthode. Cette réunion
dure 30 minutes, elle a pour but de synchroniser l’équipe et de parta-
ger les connaissances.

A la fin d’un sprint, une réunion de démonstration est mise en place.


L’équipe présente et commente le travail réalisé pendant le sprint
puis fait une démonstration de l’application. A la fin de la réunion
la décision de publier ou non une release du logiciel est prise et les
objectifs de l’itération suivante sont définis.

22
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

– Phase de clôture

C’est une phase linéaire qui prépare le produit pour une livraison. :
intégration, tests systèmes, documentation utilisateur, préparation de
supports de formation, préparation de supports marketing, etc..

4.4.2 Conclusion
Scrum présente de manière claire les caractéristiques fondamentales d’une
méthode agile. Par ailleurs, bien que flexible, cette méthode se veut ri-
goureuse puisque le contrôle des processus est omniprésent, le projet est
constamment dirigé à la lumière des quatre variables précédemment citées
que sont délais, coûts, fonctionnalités, et qualités. Du point de vue de la pro-
gression, Scrum accorde une place importante au partage des connaissances
au sein d’une équipe, notamment au cours des réunions quotidiennes. Ceci
est bien entendu un facteur qui améliore la productivité et la capitalisation
des savoirs mais limite la taille de l’équipe de développement.

4.5 FDD (Feature Driven Development)


Le développement orienté-fonctionnalité, ou encore FDD a été développé
par Jeff de Luca et Peter Coad. Comme les autres méthodologies adapta-
tives, il se concentre sur des itérations courtes qui fournissent un résultat
tangible sous forme d’une fonctionnalité logicielle. Dans le cas de FDD, les
itérations durent deux semaines, ce qui est très motivant pour les développeurs,
et permet une meilleur visibilité de l’état d’avancement du projet pour les
managers. FDD a cinq processus. Les trois premiers sont réalisés en amont
du projet et les deux derniers sont réalisés pendant chaque itération. Chaque
processus est décomposé en tâches et assigné à des critères de vérification.

4.5.1 Les cinq phases

23
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

Figure 5 - Les cinq phases d’un projet Feature Driven development


( source : Business Interactif ).

Chacune des phases est validée par un critère d’entré qui est en général la
vérification que la phase prècèdente est bien terminée, puis validée en sortie
par l’architecte et le chef de projet.

– Développer un modèle global

Il, s’agit ici de former l’équipe de modélisation, d’étudier le domaine et


d’élaborer une liste de feature. Une feature designe une fonctionnalité
du système susceptible d’être implémentée en deux semaines. Les fea-
tures  features sets  sont regroupées en groupe qui participe à une
fonction plus globale. Enfin un modèle est développé et les alternatives
sont étudiées. A la fin de cette étape le diagramme de classe doit être
réalisé.

– Construire une liste de fonctionnalité

Lors de cette phase les features sont regroupées en features sets et


classées par ordre de priorité.

– Plannifier par fonctionnalité

24
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

C’est la phase où les features sont plannifiées puis affectées aux développeurs
séniors. Il en ressort un planning détaillé et une date butoir pour
chaque itération.

– Concevoir à partir des features

Former les équipes DBF (design by feature) : Les équipes DBF sont
constituées de deux types de développeur : le propriétaire de classe et
le programmeur en chef. Le programmeur en chef est un développeur
senior, il identifie quelles classes sont impliquées dans le codage d’une
fonctionnalité et rassemble les propriétaires de ces classes pour former
une équipe fonctionnelle, il agit en tant que coordinateur, concepteur
tandis que les propriétaires des classes font le plus lourd du codage de
la fonctionnalité. En sortie on doit avoir les diagrammes de séquence
détaille et les diagrammes de classe mis à jours.

– Construire à partir des features

Lors de cette phase les classes et les méthodes sont implémentées,


le code est inspécté, les modifications sont apportées, les tests uni-
taires sont effectués puis l’intégration est préparée. A la fin de cette
phase l’équipe doit délivrer un composant fonctionnel, conforme aux
spécifications.

4.5.2 Conclusion
FDD fournit un cadre de travail beaucoup plus développé et beaucoup
plus abouti que la plupart des méthodes agiles notamment en terme
de formalisation des différentes étapes.
La propriété du code revenant aux propriétaires de classes permet de
gérer les risques au niveau des modifications au dépend de la rapidité
de modification.
FDD constitue probablement l’une des méthodes agiles les plus abou-
ties et aussi l’une des plus aptes à maı̂triser les risques, cependant
c’est aussi l’une des plus lourdes a mettre en place. FDD à déjà été
utilisé avec des équipes de taille conséquente pouvant aller jusqu’à une
vingtaine de développeurs.

4.6 DSDM (Dynamique Softwar Development Methode)


La méthode DSDM est née en grande Bretagne en 1994. Ayant été
adoptée par de grandes organisations telles que, British Airway, Bar-
clays Bank, Norwitch Union, etc., DSDM a connu une croissance ex-
ponentielle ainsi qu’un développement international (Bénélux, Dane-

25
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

mark, USA). DSDM s’appuie aujourd’hui sur une association loi 1901
et est formalisé aujourd’hui dans sa version 4.2.

4.6.1 Les neuf principes fondamentaux


– L’implication active des utilisateurs est indispensable

Les utilisateurs ne sont pas externes au développement mais au


contraire ils doivent être placés au sein du processus de dévelop-
pement avec une forte implication. De ce fait ils ne sont plus là
juste pour fournir des informations et contrôler les résultats, mais
deviennent de réels acteurs de l’équipe de développement, et ainsi
favorisent les prises de décision.

– Pouvoir de décision des équipes DSDM

Une équipe DSDM regroupe donc les développeurs et les utili-


sateurs. Elle doit pouvoir prendre des décisions au niveau des
besoins, évolutions, modifications et au niveau des fonctionna-
lités sans avoir besoin de l’aval de leur supérieur.

– Livraison fréquente de produits

Pour des raisons de flexibilité DSDM demande des livraisons


fréquentes de produits, avec des délais courts (2 à 6 semaines)
afin de permettre à l’équipe de décider quelles activités sont
nécessaires et suffisantes pour leur réalisation.

Le terme produit comprend les produits de développement in-


termédiaires, et pas uniquement les systèmes livrés.

– L’adéquation aux besoins est le critère essentiel pour que les pro-
duits livrés soient acceptés

L’objectif de DSDM est de livrer à temps des fonctions métier qui


permettent de satisfaire les besoins de l’entreprise. Le système
pourra être amélioré ultérieurement.

– Il est nécessaire d’utiliser un développement itératif et incrémental


pour obtenir une solution adaptée aux besoins.

Cette manière de procéder permet un retour permanent des uti-


lisateurs vers les développeurs. De plus, il est possible de livrer

26
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

des solutions partielles pour répondre à des besoins urgents.

– Toutes les modifications effectuées au cours du développement


sont réversibles

La gestion de configuration du logiciel en développement doit


être maı̂trisé de manière à ce que tout changement effectué soit
réversible. Le  backtracking  retour en arrière étant une ca-
ractéristique de DSDM.

– Les besoins sont définis à un niveau global

Sert à déterminer et à geler les objectifs et le périmètre du système.

– Les tests sont intégrés à toutes les étapes du cycle de vie

– Une approche basée sur la collaboration et la coopération entre


toutes les personnes intéressées par le projet est essentielle

Les spécifications détaillées n’étant pas définies dés le départ.


La direction que doit prendre le projet devra donc être décidée
rapidement, ce qui implique la nécessité d’avoir une procédure de
gestion des modifications peu contraignante.

4.6.2 Processus de développement

Figure 6 - Cycle de vie d’un projet DSDM


( source : Business Interactif ).

27
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

DSDM se définit plus comme un  canevas  que comme une méthode,


elle ne fournit que l’ossature du processus global et une description des pro-
cessus et produits qui devront être adaptés à un projet. Le processus de
développement est constitué de cinq phases.

– Etude de faisabilité

Cette première tâche considère si DSDM est appropriée au projet.


Ensuite le problème à résoudre est posé, les coûts sont évalués et on
regarde si le système est apte a résoudre le problème métier. Il en res-
sort un plan global de développement et éventuellement un prototype.

– Etude de business

L’étude de business ou étude métier a pour but de permettre la compré-


hension des besoins et des contraintes techniques. Pour cela des ate-
liers de travail sont organisés pour comprendre les domaines métier
concernés par le développement. Elle débouche sur un diagramme de
haut niveau de l’architecture système et un plan global de prototypage
qui décrit le mode de développement ainsi que le mode de contrôle et
de tests à mettre en oeuvre.

Le reste du processus forme trois cycles imbriqués.

les deux premiers cycles reposant sur quatre activités :


1 . Identifier ce qui doit être produit
2 . Décider comment et à quel moment le faire
3 . Créer le produit
4 . Vérifier qu’il a été développé de manière appropriée

– Le cycle du modèle fonctionnel itératif

Produit l’analyse de la documentation et des prototypes. Les proto-


types ou modules logiciels répondent aux principaux besoins, y compris
les besoins non fonctionnels comme la sécurité ou la facilité d’utilisa-
tion. Il subissent des tests unitaires et des tests de recette effectués
directement par les utilisateurs.

– Le cycle conception et réalisation itératives

Produit l’ingénierie du système en vue de l’utilisation opérationnelle.


Le système testé n’est pas forcément complet sur le plan fonctionnel

28
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

mais il doit satisfaire les besoins définis comme prioritaires pour l’étape
en cours.

– Le cycle de mise en oeuvre

Produit le déploiement pour l’utilisation opérationnelle. Le document


de capitalisation de projet est l’autre produit de cette phase. Il permet
de faire le point sur les besoins exprimés et la manière dont le système
y répond. Quatre résultats sont possibles :
1 . Tous les besoins ont été satisfaits. Aucune tâche supplémentaire
n’est donc nécessaire.
2 . Un aspect fonctionnel important a été provisoirement ignoré. Il
faut dans ce cas revenir à la phase étude du business et re-dérouler
le processus à partir de là.
3 . Une fonctionnalité à faible priorité a été délibérément ignorée.
Pour l’ajouter, il suffit de revenir à la phase modèle fonctionnel
itératif.
4 . Un aspect technique mineur a également été délaissé, il peut à
présent être traité en revenant à la phase conception et réalisation
itératives.

4.6.3 Conclusion
L’approche DSDM est particulièrement séduisante, dans la mesure où
elle rassemble beaucoup de règles de bon sens, sans forcément prendre de
positions extrêmes par rapport à des pratiques. DSDM se présente comme un
canevas qui peut être complété en intégrant des éléments méthodologiques
issus d’autres approches en fonction du contexte méthodologique de l’entre-
prise. La spécialisation des acteurs permet d’adapter DSDM à de grosses
équipes de développement

29
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

5 Synthèse du thème
L’art de la production logiciel est difficile. La nature même du pro-
duit rend son élaboration délicate. La complexité, la taille des systèmes
et le durcissement économique du marché ajoutent encore à la difficulté
de développer un logiciel de manière profitable. C’est dans ce contexte et
aussi en réaction à des méthodes classiques lourdes, critiquées pour leure
difficultés à conduire à bon port le développement logiciel, que toutes ces
méthodologies Agiles se sont développées ces dernières années.

Les méthodes Agiles définissent un ensemble de pratiques permettant de


gérer plus facilement la communication entre les acteurs d’un projet, les exi-
gences du client et les risques de développement, dans un environnement de
changement perpétuel. Elles mettent en évidence la nécessité d’utiliser une
démarche itérative et incrémentale avec des cycles courts, afin de réajuster
rapidement les besoins du client en cours de développement et de mieux
appréhender les risques. Elles accordent une importance toute particulière
aux tests, en préconisant d’y recourir de façon intensive. Elles permettent
aux développeurs de participer à la conception et enfin, elles proposent une
focalisation sur le code source et une utilisation intelligente des efforts des
participants.

Même si les méthodes Agiles font preuve d’innovation, elles ne peuvent


prétendent à elles seules résoudre les différentes problématiques de la concep-
tion logicielle. Au regard des nombreuses méthodes existantes, il serait illu-
soire de trouver un jour une méthode ou un groupe de méthodes universelles.
Ce qui importe le plus en ce qui concerne le développement logiciel, c’est
de choisir une méthodologie approprié au contexte (par exemple : un cycle
de vie en cascade dans un environnement peu réactif, RUP pour des pro-
jets de grande taille demandant un formalisme élevé ou une méthode Agile
dans un environnement évolutif). En second lieu, ce sont les hommes qui
font un projet, la méthodologie n’est donc qu’un point de départ, un cadre
structurant. Il faut ensuite que l’équipe s’approprie le processus, le surveille
et l’adapte aux circonstances, pour devenir à la fin un cycle de vie propre à
l’équipe.

30
Dagorne emmanuel Les Méthodes Agiles CNAM 2004/2005

6 Références
Ce mini-mémoire a été réalisé dans le cadre d’un projet de rédaction
d’un document de synthèse pour le cours Génie Logiciel. Il a été rédigé à
l’aide de deux documents, le livre blanc sur les méthodes Agiles de buissness
Interactif http://www.businessinteractif.fr et un article de Martin Flower
http://www.martinfowler.com/articles/frNewMethodology.html

Liens Internet :

– Extreme Programming :
http://extremeprogramming.free.fr
http://www.idealx.org/doc/xp-synthese.fr.html
http://www.xp-france.org/
http://www.extremeprogramming.org/

– Crystal :
http://alistair.cockburn.us

– ASD :
http://www.adaptivesd.com

– SCRUM :
http://www.controlchaos.com/
http://www.mountaingoatsoftware.com/scrum/

– FDD :
http://www.featuredrivendevelopment.com/

– DSDM :
http://www.dsdm.org
http://www.dsdmfrance.com

– RAD :
http://www.rad.fr

– Agile Alliance :
http://agilealliance.org/home
http://agilemanifesto.org/

31