YVES CONSTANTINIDIS CONSULTANT

La grande mêlée du développement agile

Un mythe est en train de s’installer durablement dans le petit monde de l’ingénierie du logiciel : l’agilité consisterait en un ensemble de méthodes de développement « modernes », par opposition aux méthodes de développement « en cascade » qui, elles, seraient « classiques » ou « conventionnelles ». Modernité sous-entend nouveauté et efficacité, des arguments pour vendre des méthodes, techniques et outils divers et variés.

Rien à redire sur les méthodes et outils. On a besoin de méthodes. On a besoin d’outils. Mais on a aussi besoin de clarté et de précision dans le vocabulaire. Classique, en cascade, en V, en spirale, en agile … je suis perdu dans la mêlée !

Mettons les choses au clair …

Le développement en cascade (waterfall) n’est pas une méthode, c’est un modèle de cycle de développement. Une description la réalité. Pas une prescription d’activités.

L’agilité n’est pas une méthode non plus, encore moins LA méthode, comme le prétendent et l’écrivent certains. C’est avant tout une manière de penser la construction du logiciel. C’est aussi une manière de gérer les projets. Elle se décline en une myriade de démarches. Mais elle n’est pas nouvelle.

Ce qui est relativement nouveau, c’est le mot. Il date de 2002. Il y a vingt ans, des méthodologues de renom se sont regroupés pour écrire et publier le manifeste agile. Ils n’ont rien inventé, ils ont partagé entre eux, et avec un plus large public, des pratiques qui étaient les leurs.

Vingt ans, dans l’histoire de l’ingénierie du logiciel, c’est énorme. Mais attendez la suite !

Savez-vous qui a inventé le mot waterfall (en cascade) pour parler du cycle de développement ? C’est Barry Boehm, en 1981, dans son Software Engineering Economics. Quarante ans, oui, c’est très vieux.

Et qui, le premier, a formalisé le développement incrémental ? Oui, vous avez bien deviné : le même Boehm, dans le même livre, il y a quarante ans.

Boehm nous explique qu’on ne peut pas s’abstraire du modèle en cascade, quelle que soit la méthode de développement choisie, tout simplement parce qu’on ne peut pas tester ce qu’on n’a pas codé, qu’on ne peut pas coder ce qu’on n’a pas conçu, et qu’on ne peut pas concevoir avant d’avoir défini les besoins. Cette succession d’étapes est incontournable. Même avec un modèle en spirale, itératif, incrémental, et aussi agile que vous voudrez.

Boehm nous explique que le cycle de développement incrémental est fait d’un assemblage de petites cascades, comme illustré dans son ouvrage. Quoi qu’il en soit, comparer « agile » et « en cascade » est un non-sens.

Cascades et incréments (Boehm, 1981)

Pour ces raisons, on ne devrait pas parler de « méthodes agiles » et surtout, ne pas les opposer au modèle en cascade, sous-entendu « non agile », autrement dit engourdi, gauche, gourd, lent, lourdaud, mou (ce n’est pas moi qui le dis, c’est le dictionnaire des synonymes et antonymes).

On devrait parler de démarches prédictives et de démarches adaptatives. Et c’est encore Boehm qui utilise le mot predictive dans son ouvrage Balancing agility and discipline, publié plus de quarante ans après Software Engineering Economics.

On pourrait se dire que, comme pour la musique, une méthode « classique » est une méthode « écrite » faite de procédures et de conventions. C’est un peu vrai. Mais il suffit de parcourir les 788 pages du Rapid Application Development de James Martin (1991) pour constater que le développement agile était fortement procéduré il y a déjà trente ans. Juste pour comparer, je vous le montre à côté du guide de bonnes pratiques du SEI (CMMI Guidelines, 2003) qui ne comporte « que » 663 pages.

RAD (1991) et CMMI Guidelines (2003)

L’agilité n’est donc ni nouvelle, ni légère, ni facile. Alors pourquoi en parle-t-on autant aujourd’hui ?

L’agilité est à la mode parce qu’elle répond à un besoin et qu’elle est très bien adaptée au développement d’un certain type d’applications, en particulier (mais pas seulement) les applications de e-commerce.

Quant à CMMI, sa nouvelle version V2.0 se veut plus souple, extensible, conviviale et orientée vers la valeur du produit et le retour sur investissement. Autrement dit, plus agile.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

To top