Publié par

Il y a 12 ans -

Temps de lecture 5 minutes

Le wannabisme agile

Dans une récente interview sur InfoQ, que nous évoquions il y a peu dans notre revue de presse, Jeff Sutherland fait état d’un ensemble de tests que la société Nokia applique aux processus de développement logiciel pour déterminer s’ils utilisent réellement une approche itérative et incrémentale, et plus spécifiquement s’ils adhèrent ou non à la méthodologie Scrum. Je ne reviendrai pas sur ces tests – Jeff les explique mieux que moi – mais j’aimerais attirer votre attention sur un phénomène que j’observe depuis quelque temps chez certains de nos clients : le wannabisme agile.


A quoi reconnaît-on un projet wannabe agile ? Le plus souvent à la rupture sémantique qui s’opère entre l’équipe technique, chargée du développement, et la maîtrise d’ouvrage, cliente du développement. Les membres de la première s’évertuent à adopter les signes extérieurs de l’agilité – cycles courts, tests unitaires, intégration continue, contrôle qualité, etc. – quand les seconds ignorent tout des principes du développement itératif et incrémental, et ne voient dans l’organisation du projet qu’une aberration supplémentaire, qu’ils affublent le plus souvent d’un qualificatif d’ordinaire réservé aux maisons de joie : « ce projet, c’est le bordel! ».

Quelques signes permettent d’identifier rapidement le wannabisme agile.

Un projet wannabe agile fonctionne souvent par itérations courtes – d’une durée rarement inférieure au mois, cependant, et plus probablement de l’ordre de 6 à 8 semaines -, mais le contenu des itérations suit un plan précis, établi au préalable. On parle en général de lots. Chaque lot a été précisément circonscrit lors des phases de spécification, et son contenu a été contractualisé au même titre que sa date de livraison. Le démarrage d’un lot de développement est entièrement conditionné par la validation préalable des spécifications détaillées de son contenu, et il n’est pas rare, dans un projet wannabe agile, que la livraison d’un lot subisse certaines avaries : variation imprévue de périmètre, retard de livraison, qualité médiocre attribuée en générale au manque de temps.

L’équipe wannabe agile s’efforce d’utiliser l’outillage nécessaire au développement incrémental : test unitaires (généralement JUnit), tests fonctionnels (Fitness), refactoring, automates de build et d’assemblage (Maven), intégration continue (Hudson), contrôles qualités (CheckStyle, Metrics,etc.)… Mais ses efforts se heurtent très souvent aux contraintes du planning : sous la pression des livraisons, les tests unitaires se raréfient, puis disparaissent. Personne ne comprend plus vraiment à quoi peut bien servir Fitness, dont l’usage est tout bonnement abandonné. L’intégration continue a du mal à fonctionner, et est rapidement ressentie comme une lourdeur inutile. Checkstyle est temporairement désactivé : trop de rouge, on le réactivera quand on aura le temps de faire les corrections… Inéxorablement, le développement accumule une dette technique qui ne sera jamais épongée.

Le chef de projet de l’équipe wannabe agile est sommé, parfois à son corps défendant, de fournir un diagramme de Gantt complet et correctement ajusté sur les 6 prochains mois. Les jalons en sont bien sûr ceux du contrat initial de lotissement. Il utilise pour le bâtir la méthode dite du chausse-pied dont les résultats, bien que farfelus, ont le mérite de satisfaire son management.

Faute d’une organisation adéquate, l’équipe wannabe agile est incapable d’identifier le sponsor fonctionnel (celui que la littérature anglo-saxone désigne sous le nom Product Owner). Dans le meilleur des cas, il est identifié mais inaccessible… La mort dans l’âme (et encore, pas toujours !), elle attend donc la validation définitive des spécifications détaillées avant de démarrer ses développements.

Le projet wannabe agile est en général dysfonctionnel : faute d’un alignement global, compris et accepté de tous, sur les paradigmes du développement itératif et incrémental, l’introduction homéopathique des pratiques agiles risque de passer pour du simple amateurisme ; symétriquement, privé de ses poumons – collaboration étroite avec les utilisateurs, product backlog proprement alimenté, itérations de durée fixe et dont le contenu est déterminé en fonction de la capacité de production de l’équipe, feedback technique et fonctionnel permanent, mesure d’avancement systématique -, le développement wannabe agile est condamné à l’asthme, puis à l’asphyxie.

Que penser du wannabisme agile ? En règle général, les projets wannabe agiles sont le résultat d’une initiative exclusive d’une équipe de développement, voire d’un chef de projet, qui a obtenu l’accord plus ou moins tacite de sa direction. Il cherche à obtenir les fruits du développement incrémental – maîtrise des coûts, qualité de la production, tolérance au changement, adéquation aux besoins – sans bénéficier de l’écosystème indispensable à la réussite d’une telle initiative. Faute de soutien actif de sa hiérarchie et de la collaboration étroite de la maîtrise d’ouvrage, cette initiative est vouée à l’échec – au risque de la décrédibiliser durablement.

La mise en place de Scrum est l’affaire de quelques heures. Mais l’adoption d’une méthode de développement itératif et incrémental nécessite une véritable révolution culturelle dans la gestion de projet informatique, révolution qui déborde largement du cadre étroit de l’équipe de développement : les spécifications détaillées écrites doivent être abandonnées au profit des tests, la communication MOA-MOE doit être décloisonnée, les architectes sur piédestal doivent être mis à terre, les pratiques contractuelles castratrices du développement au forfait doivent être proscrites, le planning doit être ajusté en permanence… C’est à ce prix qu’une véritable pratique de développement agile est accessible. Et à ce prix seulement.

Publié par

Commentaire

4 réponses pour " Le wannabisme agile "

  1. Publié par , Il y a 11 ans

    Merci pour cette description, c’est hélas, l’exacte description de la réalité de mon ancien employeur.

  2. Publié par , Il y a 11 ans

    Je viens de tomber sur cet ancien billet et je trouve qu’il est encore d’actualité.
    A relire et à compléter avec nos expériences sur le terrain.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Xebian, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.