Présentation

Article

1 - TEXTES FONDATEURS DES MÉTHODES AGILES

  • 1.1 - Pourquoi les méthodes agiles ?
  • 1.2 - Agilité dans le texte du manifeste AGILE – Les quatre valeurs de l'agilité
  • 1.3 - Douze principes de l'agilité dans le texte
  • 1.4 - Douze règles de bonnes pratiques de l'eXtreme Programming

2 - ÉLÉMENTS DE COMPARAISON DE QUELQUES MÉTHODES AGILES

  • 2.1 - Ouvrages fondateurs des leaders du manifeste AGILE
  • 2.2 - Domaines de l'agilité concernés par la méthode d'évaluation

3 - PERFORMANCE DES ACTEURS INDIVIDUELS

  • 3.1 - Programmation par paire programmeur-testeur PP
  • 3.2 - Chef de projet AGILE

4 - PERFORMANCE DE L'ACTION COLLECTIVE

  • 4.1 - Qu'est-ce qu'un expert ?
  • 4.2 - Communiquer avec son environnement

5 - RÔLE DE L'ARCHITECTURE ET DES ARCHITECTES

6 - PROCESSUS AGILES

7 - CONCLUSION : OMISSIONS ET LIMITES DES MÉTHODES AGILES

  • 7.1 - Omissions gênantes
  • 7.2 - Illusions

Article de référence | Réf : H3202 v1

Textes fondateurs des méthodes agiles
Méthodes agiles

Auteur(s) : Jacques PRINTZ

Date de publication : 10 févr. 2010

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

RÉSUMÉ

Le développement rapide des techniques dans les projets, particulièrement dans le domaine informatique, a conduit à l'amélioration des pratiques et des démarches. Le but étant de satisfaire les besoins du client en livrant rapidement et régulièrement des fonctionnalités à forte valeur ajoutée, un groupe de pratiques pragmatiques a été défini, nommé méthodes agiles. Celles-ci sont axées autour de quatre valeurs : l'équipe, l'application, la collaboration et l'acceptation du changement. Cet article propose de faire le tour de la question, en détaillant les fondamentaux des méthodes agiles. Les différents principes sont ainsi expliqués, de leurs caractéristiques à leurs enjeux, afin de donner la ligne de conduite des acteurs au sein d'un projet Agile.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

ABSTRACT

The rapid development of techniques in projects, particularly in the computing sector, has led to the improvement of practices and approaches. The aim is to meet the needs of the client by rapidly delivering high-value features consistently; a set of pragmatic practices has been defined named agile methods. They are built upon four values: the team, application, collaboration and acceptance of change. This article reviews the subject, by detailing the fundamentals of agile methods. The various principles are thus explained, from their characteristics to their challenges, in order to present the course of action of actors within an Agile project.

Auteur(s)

  • Jacques PRINTZ : Professeur au Conservatoire National des Arts et Métiers CNAM

INTRODUCTION

Les méthodes dites « agiles », qui apparaissent sous cette appellation dans les années 2000 ont cependant une histoire un peu plus ancienne. Comme souvent, et malheureusement, en informatique on change la terminologie à défaut de changer de concepts. Le seul résultat certain de cette pratique déplorable est la confusion dans les esprits, en particulier celui des décideurs qui ont fini par perdre toute confiance dans ce que leur racontent leur DSI et/ou leurs experts informatiques. Le scepticisme et la défiance règne.

À la fin des années 1980, James Martin, auteur prolixe, a publié en trois volumes, chez Prentice Hall, son Information Engineering, qui a donné naissance, quelques années plus tard au RAD (Rapid Application Development) vite connu sous l'appellation « Quick and Dirty » et complètement décrédibilisé suite aux mauvaises pratiques qu'il a engendré. Il y avait beaucoup de bonnes choses dans l'Information Engineering, mais comme on peut s'en souvenir, c'est l'époque de la rupture technologique, avec le développement fulgurant des architectures distribuées, du client-serveur avec ses différentes variantes (client lourd, client semi-lourd, client léger, etc.). Les langages « anciens » comme Cobol, même rénovés avec les générateurs d'applications et autres L4G qui fleurissent vers la fin des années 1980, n'intéressent plus grand monde (quand bien même il reste encore des milliards de lignes de codes en Cobol dans les banques, les assurances, dans les administrations...). La mode est désormais aux langages objets (C++, Java) et aux méthodes de conception orientées objets qui, dans les années 1990, donneront naissance au langage UML. On est encore dans l'euphorie de l'intelligence artificielle, dont le battage médiatique a réussi à faire croire à de nombreux décideurs que l'on va pouvoir mécaniser la fabrication des programmes (en se débarrassant des programmeurs, ces gêneurs qui font des erreurs et qui sont incapables de s'exprimer dans un langage compréhensible de tous) et enfin, connaître le meilleur des mondes informatiques où l'erreur a disparu comme par magie. Le réveil, qui prend les allures d'un crash, sera particulièrement brutal (cf. le rapport Chaos du Standish Group [Doc. H 3 200]).

C'est également la période de tous les excès issus d'une démarche qualité mal comprise, qui va vite se transformer en bureaucratie, dont l'objectif est de satisfaire à des normes souvent ineptes (la norme du DOD 2167, tristement célèbre, est encore dans les mémoires de certains), inventées par des « experts » n'ayant jamais réalisé un système de leur vie. Comme on le sait, l'échec sera au rendez-vous, avec en plus un discrédit général sur la qualité dont on n'ose même plus prononcer le nom dans les entreprises qui se veulent sérieuses et informées.

Il faut également signaler le cycle de développement dit « en spirale » popularisé par B. Boehm dans son article de la revue IEEE Computer, vol. 21, no 5, mai 1988, A spiral model of software development and enhancement. Comme tout ce qu'a publié B. Boehm, c'est intelligent et profond, fondé sur la vraie expérience de l'auteur en matière de système logiciel. L'idée de Boehm est de coupler le processus de développement classique « en cascade » avec une gestion de risque qui donne des critères de convergence permettant de réaliser le système attendu par les parties prenantes. C'est une façon élégante de gérer les rétroactions sur une base réellement objective : quel décideur sensé pourrait refuser de prendre en compte les risques identifiés qui mettraient le projet en échec ?

Sur toute cette période, le lecteur intéressé peut consulter le recueil de textes, sélectionnés par D. Reifer, Software management, publié par l'IEEE en 1993, qui donne une bonne photo des problématiques de l'époque.

En fait, rien de vraiment nouveau dans la démarche agile, si ce n'est, comme on dit au football, une remise de la balle au centre.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-h3202


Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

1. Textes fondateurs des méthodes agiles

1.1 Pourquoi les méthodes agiles ?

On peut s'interroger sur l'apparition d'un phénomène socio- culturel comme les méthodes agiles et « l'eXtreme Programming » dans les années 2000. Constatons la concomitance de plusieurs phénomènes, sans qu'il y ait un quelconque lien causal entre eux, mais qui tous amènent un surcroît de complexité dans les systèmes informatiques.

La taille des applications n'a fait que croître tout au long de ces 20 dernières années. L'arrivée des PC sur le marché, à des prix défiant toute concurrence, a permis de diffuser la technologie informatique dans tous les corps de métiers. La majorité des usagers de l'informatique ne connaît rien à la technologie sous-jacente, mais pour rendre cette technologie acceptable, il a fallu développer des IHM dont le volume se chiffre aujourd'hui en centaines de milliers d'instructions. Ces logiciels IHM, inexistants jusqu'au milieu des années 1980, sont très complexes car événementiels et dépendants du niveau culturel et de la maturité de l'usager : ils doivent être conviviaux et respecter les règles de l'ergonomie (en fait, c'est la seule vraie bonne retombée de l'IA). Il y a une véritable co-évolution du couple usager/IHM, au sens biologique du terme.

La frénésie technologique a complètement déstabilisé les interfaces traditionnelles permettant de mettre les applications à l'abri des innovations et des évolutions des plates-formes. Aujourd'hui, tout est instable, ce qui fait que si le programmeur ne sait pas organiser son programme pour le protéger des évolutions des plates-formes, il aura la durée de vie de la plate-forme, ce qui est inacceptable d'un point de vue économique. Si le prix du hardware s'est effondré, celui du software n'a fait que croître. L'assurance qualité, les modèles de maturité des années 1980 avaient comme raison d'être d'optimiser des processus eux-mêmes relativement stabilisés, et évidemment pas de résoudre les problèmes à la place des concepteurs ; cela aussi a été oublié, et l'on a fait jouer à tous ces modèles un rôle que, par définition, ils ne pouvaient pas tenir. Il faut ne rien avoir compris au logiciel pour ramener la qualité du logiciel d'une part a) à l'épaisseur de la documentation ou aux plans types des documents, et d'autre part b) à des choix d'outils que certains vendeurs présentaient comme tellement « intelligents » qu'ils dispensaient leurs...

Cet article est réservé aux abonnés.
Il vous reste 94% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Textes fondateurs des méthodes agiles
Sommaire
Sommaire

BIBLIOGRAPHIE

  • (1) - COMTE-SPONVILLE -   Petit traité des grandes vertus.  -  PUF (1995).

  • (2) - OZ (E.) -   When professional standards are lax : the CONFIRM failure and its lessons.  -  Communications of the ACM, vol. 37, no 10 (1994).

  • (3) - EWUSI-MENSAH (K.) -   Software development failures.  -  MIT Press (2003).

  • (4) - HOCK (D.) -   Birth of the chaordic age.  -  Berrett-Koehler (1999).

  • (5) - HIGHSMITH (J.) -   Adaptive software development, a collaborative approach to managing complex systems.  -  Dorset House (1999).

  • (6) - SKROWRONSKI (V.) -   Do agile methods marginalize problem solvers ?  -  IEEE Computer, oct. 2004.

  • (7)...

1 Sites Internet

Site du Manifeste AGILE http://www.agilealliance.org

HAUT DE PAGE

2 Normes et standards

IEEE std 1058 - 1998 - Software project management plan - -

IEEE std 1490 - 2003 - A guide to the project management body of knowledge (PMBOOK) - -

HAUT DE PAGE

Cet article est réservé aux abonnés.
Il vous reste 93% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Technologies logicielles Architectures des systèmes

(233 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS