Les 7 pièges des méthodes agiles

Les 7 pièges des méthodes agiles

Ce billet tente de synthétiser les principaux pièges des méthodes agiles, avec un focus plus particulier sur le développement logiciel. Omniprésentes, ces méthodes sont particulièrement adaptées pour le développement de produits Web et mobile. Même si le taux de réussite des projets agiles est meilleur qu’avec les méthodes dites traditionnelles, tous les retours d’expérience s’accordent à dire que la recette du succès est loin d’être triviale… Il n’est pas inutile de recenser les écueils à éviter pour pouvoir profiter des gains liés à ces méthodes.

  1. Manque de vision produit (ou non partagée)
  2. Sous-estimer la dette technique
  3. Ne plus faire de conception et mal interpréter le principe KISS
  4. Ne faire que du développement incrémental
  5. Manque de discipline
  6. Cycles de développement trop courts
  7. Vade retro Cycle en V !

Introduction

L’appellation de méthode agile est véritablement apparue en 2001 avec la rédaction du  manifeste Agile, regroupant un ensemble de bonnes pratiques de développement logiciel, l’objectif étant de mieux répondre aux contraintes et exigences des organisations en évolution rapide. A noter que même si ces méthodes réduisent significativement le Time To Market (TTM), elles ne permettent pas de développer plus vite ! Le phénomène s’explique essentiellement par leur capacité à livrer des scopes fonctionnels pertinents, au bon moment (pas de livrer le tout plus vite). Il existe un peu moins d’une dizaine de méthodes dont le périmètre diffère légèrement, plus ou moins complémentaires, les plus connues étant :

  • Scrum, la plus populaire, met plus l’accent sur l’organisation humaine,
  • Extreme Programming est très axée sur la construction de l’application,
  • Kanban (méthode Japonaise) met l’accent sur le workflow évolutif de développement en flux tendu et vise l’excellence en terme de qualité,
  • Lean (proche de Kanban) se focalise plus sur l’élimination du gaspillage et sur des livraions Just-In-Time

Les méthodes agiles ne sont pas nées du manifeste Agile mais ce dernier formalise leur dénominateur commun et précise que ces méthodes favorisent :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuelle
  • L’adaptation au changement plus que le suivi d’un plan

Seulement voilà, la définition même du manifeste reste floue, favoriser ne signifie pas remplacer, tout est subjectif, contextuel et affaire de compromis. Par ailleurs, même si les 12 principes sous-jacents à ces quatre règles semblent une évidence sur le papier, certains sont difficilement conciliables dans la pratique, pour n’en citer que deux :

  • Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • Une attention continue à l’excellence technique et à une bonne conception renforce l’agilité.

Dès lors que nous parlons d’un projet ambitieux techniquement, avancer rapidement pour avoir à chaque itération une livraison opérationnelle avec des fonctionnalités à grande valeur ajoutée permet difficilement l’excellence technique. Avec ce fonctionnement, cette excellence n’est atteignable qu’avec des refactorings de plus en plus fréquents et onéreux, rendant finalement ces livraisons rapides caducs. Autrement dit, cette excellence technique n’est possible que si ses conditions cadencent, en partie, le rythme des livraisons. Il y a donc ici un arbitrage sensible pour des projets complexes dont les décideurs doivent avoir conscience.

Les 7 pièges des méthodes agiles

Les 7 pièges des méthodes agiles : Manque de vision produit

1. Manque de vision produit (ou non partagée)

Les 7 pièges des méthodes agiles : Manque de vision

En opposition total avec les méthodes traditionnelles qui se veulent prévoyantes et prédictives (et où l’expérience montre que c’est utopique dans le domaine de l’informatique), les méthodes agiles amènent à réfléchir sur le court terme tout en s’adaptant constamment. Cela ne devrait en aucun cas concerner la vision produit, peut importe si celle-ci soit amenée à évoluer ou non, car elle est fondamentale pour toute l’équipe, à tout moment.

D’un point de vue fonctionnel, elle permet :

  • de conserver une cohérence globale par rapport à un cap fonctionnel. L’ objectif d’aboutir à un livrable opérationnel à chaque itération doit s’inscrire harmonieusement dans cette vision globale et pas comme une étape temporaire jetable. Cette cohérence globale s’exprime aussi par une ergonomie pertinente du produit qui n’a de sens que lorsque l’on a une vision complète du produit.
  • de détecter plus rapidement les incohérences fonctionnelles. Plus le projet évolue, plus les fonctionnalités sont complexes et les changements nombreux. Il peut devenir difficile pour le Project Owner, dans le cadre de Scrum, de détecter ces incohérences. En plus d’être force de proposition, les développeurs peuvent et doivent aussi avoir ce rôle de garde-fou, encore faut-il qu’ils aient connaissance de cette vision produit.

D’un point de vue technique :

  • de mieux détecter la dette technique et de mieux prioriser les actions qui en découlent. En effet la vision produit permet de distinguer les éléments techniques pérennes de ceux qui le sont moins et ainsi engager des refactorings au bon moment, au meilleur coût. Sans vision, les doutes de s’engager dans des travaux inutiles prévalent toujours et l’on ne fait rien jusqu’au moment où il est trop tard pour remettre en cause l’existant, à moins de faire exploser les délais et les coûts.
  • de faire des choix plus pertinents en termes d’architecture, technologies, frameworks et conception logicielle tout au long du projet.

Les 7 pièges des méthodes agiles : Manque de vision

Manquer de vision produit (ou mal la partager) est sans aucun doute l’un des pièges des méthodes agiles dont il faut avoir le plus conscience. Il a un impact négatif sur l’équipe (baisse de motivation notamment), sur la qualité du produit, les délais et les coûts (engendre du travail supplémentaire).

Les 7 pièges des méthodes agiles : Sous-estimer la dette technique

2. Sous-estimer la dette technique

Les 7 pièges des méthodes agiles : Sous-estimer la dette technique

Au-delà de la méthodologie utilisée, la dette technique (qui ne doit pas être confondue avec les bugs) a toujours été conflictuelle :

  • Les équipes techniques généralement plus perfectionnistes ne cessent de rappeler aux décideurs, quelque soit l’époque, qu’il ne faut pas sous-estimer la dette technique et qu’il faut s’en occuper (maintenant ! tout de suite si possible !)
  • Quant aux décideurs, beaucoup plus préoccupés par la réussite business qu’importe la manière, pensent toujours avoir plus de recul que les équipes techniques, leur permettant de mieux évaluer les priorités (avec, éventuellement, le soutient d’un développeur fourbe !) et ainsi n’engager les travaux sans business value que si vraiment on ne peut faire autrement.

Évidement, tout est affaire de compromis, il faut trouver le juste milieu car autant il est normal d’avoir de la dette technique (la dette saine est récente) autant lorsque celle-ci s’accumule trop, les conséquences sont sévères, le coût du changement est exponentiel et le risque d’échec du projet est réel.

Dans le cadre des méthodes agiles, la dette technique est un sujet dont il faut avoir particulièrement conscience : le mode itératif à court terme en développement incrémental implique nécessairement l’apparition d’une dette technique importante, c’est inhérent à la méthode. Il ne suffit plus d’avoir un simple arbitrage à un instant donné, il faut anticiper ce fonctionnement et y consacrer du temps :

  • A chaque itération, le développement de nouvelles fonctionnalités doit inclure des réflexions et actions pour réduire cette dette au fil de l’eau,
  • Toutes les N itérations, la dette technique doit être mesurée et les actions sur les éléments les plus structurants doivent être priorisés (ce travail pourrait-être fait à chaque itération, pourvue qu’elles soient suffisamment longues)

Même si cette dette peut-être identifiée et globalement mesurée, penser qu’elle est quantifiable précisément, c’est la sous-estimer. Des outils comme Sonar donneront quelques indicateurs, mais ceux-là ne constituent que la face visible de l’iceberg : ces outils se concentrent sur des problématiques bas niveau (nomenclature, dépendances, etc). Alors certes c’est toujours utiles (l’erreur est humaine) mais s’il y a déjà des alertes critiques à ce niveau, vous pouvez vous inquiéter sur la modélisation et donc la robustesse de l’application, autrement dit sa capacité à accepter les futurs changements.

Les 7 pièges des méthodes agiles : Dette technique saine et toxique

Un des pièges des méthodes agiles est de sous-estimer la dette technique, bien plus enclin à grossir en développement incrémental itératif. Le véritable challenge étant en amont, au niveau de l’architecture technique et logicielle et de leur remaniement permanent : une bonne communication avec les équipes techniques est essentielle et devrait concrétiser la mise en place, idéalement à chaque itération, de Technical Stories.

Les 7 pièges des méthodes agiles : Ne plus faire de conception et mal interpréter le principe KISS

3. Ne plus faire de conception et mal interpréter le principe KISS

Les 7 pièges des méthodes agiles : Mal comprendre le principe KISS

Avec les méthodologies agiles, l’équipe est amené à avancer rapidement, la phase de conception est réduite à son minimum voir même devient inexistante, tout comme la documentation qui a tendance à se réduire au code source. Pourtant, plus le système à mettre en place est complexe plus l’effort de conception devrait-être important.

Dans un monde idéal, l’équipe est composée de développeurs de très haut niveau et alors la conception se traduit immédiatement par quelques Design patterns en tête, juste ce qu’il faut pour répondre au besoin, juste assez bien découpé pour pouvoir facilement refactoriser certains bouts de codes sans en impacter d’autres. Ainsi la conception telle qu’on l’entend habituellement devient effectivement beaucoup moins utile, on peut faire du développement incrémental et suivre le principe KISS (Keep It Simple and Stupid) en toute sérénité. Sauf que… nous ne sommes pas dans ce monde idéal.

Note : Le principe KISS est souvent mal interprété car chacun se positionne selon son référentiel de complexité, mais en aucun cas ce principe invite les développeurs à coder sans utiliser des Design Pattern ou sans réflexion en amont ! L’idée est simplement de ne pas construire un bazooka pour tuer une mouche, de limiter la construction d’éléments génériques complexes dont l’utilité est incertaine.

Dans la pratique, le niveau des développeurs est toujours hétérogène, tous pensent faire une belle conception mais rares sont les développeurs qui ont immédiatement le réflexe d’appliquer au fil de l’eau des patterns simples rendant le code plus flexible et interchangeable, sans perte de temps supplémentaire. Les refactorings peuvent alors devenir complexes entrainant de nombreuses régressions, le développement incrémental se transformant en la construction d’une usine à gaz.

Le seul remède est la conception et le partage des connaissances : en mode agile elle peut se traduire par des tâches et/ou via la mise en place d’ateliers de conception logicielle, en petits comités. Les développeurs séniors doivent coacher les juniors en présentant et en expliquant les bons réflexes à avoir dès lors que l’on est confronté à un même type de problème.

Les 7 pièges des méthodes agiles : Se réduire à ne faire QUE du développement incrémental

4. Ne faire que du développement incrémental

Les 7 pièges des méthodes agiles : Ne faire que du développement incrémental

Ce point est très lié au précédent. Le développement incrémental consiste à réaliser successivement des éléments fonctionnels utilisables (plutôt que des composants techniques transverses) avec des refactorings réguliers. Typique des méthodes agiles, cette pratique a pourtant ses limites dans les projets complexes techniquement dans le sens où les refactorings peuvent parfois ressembler à une refonte complète.

Généralement, il y a toujours des briques ou éléments techniques transverses qu’il est facile de détecter, même dès le début du projet et il sera toujours moins couteux de les anticiper un minimum. Pendant le développement, l’indicateur le plus pertinent est la duplication de code (ou code très proche) et plus on attend, plus les subtilités difficilement perceptibles sont nombreuses et plus le refactoring engendrera de régressions.

Ces éléments transverses doivent agir comme des boites noires et être utilisées par toutes les autres briques du projet. Au delà de rendre le code plus homogène et donc maitrisé plus facilement par l’équipe, cela permet d’instaurer des points de contrôles transverses. La détection et la mise en place de ce type d’élément ne peut se faire que si l’on sort du développement incrémental, ce dernier ne traitant, dans la pratique, que de refactoring locaux (comprendre : se limitant essentiellement au périmètre de la fonctionnalité implémentée).

L’idée reste néanmoins de conserver cette approche itérative en mettant en place ces boites noires le plus simplement possible au départ mais qui se complexifieront à chaque itération. Si l’anticipation dès le départ n’est pas envisageable, on peut entrevoir d’effectuer ce travail régulièrement, toutes les trois ou quatre itérations par exemple.

En résumé, un des pièges des méthodes agiles consiste à donner trop de crédits aux refactorings, jamais sans risques, d’autant s’ils sont de grandes ampleurs. Par ailleurs, penser que les tests unitaires et d’intégration suffiront à palier aux régressions est, dans la pratique, une utopie. Il est nécessaire d’anticiper et mettre en place certains éléments transverses évidents en avance de phase.

Les 7 pièges des méthodes agiles : Manque de discipline

5. Manque de discipline

Les 7 pièges des méthodes agiles : Manque de discipline

Favoriser les individus et leurs interactions est l’un des quatre pilier des méthodes agiles. Il peut rassembler différentes activités selon les méthodes, comme le daily, le pair programming, code review, sprint review, etc. Cela permet beaucoup plus d’interaction entre les membres de l’équipe, facilite la collaboration et la passation de connaissances. Ces éléments sont très importants (certains vont jusqu’à parler de philosophie agile) mais lorsque les énergies ne sont plus canalisées, cela peu devenir contre productif.

En effet, l’aspect démocratique et autogéré, les activités qui peuvent s’apparenter à des jeux, amènent un environnement plus cool, plus libéré, mais peut aussi conduire à moins de discipline, plus de tergiversations et à des conflits internes difficilement détectables. Le directeur de projet et le Scrum Master dans le cadre de Scrum ont leur rôle de manager à jouer et ne doivent pas avoir une confiance aveugle envers l’équipe et son bon fonctionnement. Ils doivent instaurer un climat de confiance et de transparence tout en étant ferme et en rappelant qu’il y a des consignes à respecter, par tous les membres de l’équipe.

Les 7 pièges des méthodes agiles : Cycles de développement trop court

6. Cycles de développement trop courts

Les 7 pièges des méthodes agiles : Cycles de développement trop courts

Les cycles de développement, le temps que dure une itération, doivent être le plus court possible afin de valider l’avancement régulièrement et concrètement. Mais ces cycles doivent avant tout être en accord avec la nature du projet et la taille de l’équipe. Même si Scrum et XP préconisent des cycles de quelques semaines, ceux-là peuvent s’étaler sur une plus longue durée.

Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
Manifeste Agile

Un cycle trop court peut faire basculer l’équipe dans un état d’urgence permanent d’une part et grandement réduire la qualité du produit d’autre part. Les priorités sont si fortes que la moindre décision nécessite des justifications pointues, mais les développeurs n’ont pas toujours l’habileté des commerciaux à l’argumentation aiguisée… Finalement cela devient contre productif.

D’autres effets pervers découlent des cycles de développement trop courts :

  • L’effet démo : la précipitation aboutit à des scénarios déroulés de manière trop hasardeuse car mal préparés faute de temps, avec des comportements inattendus qui finalement seront vendus comme étant l’effet démo et qu’il ne s’agit là que d’erreurs exceptionnelles
  • La livraison d’un produit faussement opérationnel : si la démo présente parfaitement bien certaines fonctionnalités, cela ne signifie pas qu’elles sont réellement terminées. Cet effet est d’autant plus pervers que toute l’équipe à tendance à se voiler la face, même inconsciemment, pour vite commencer l’itération suivante.

Les 7 pièges des méthodes agiles : Vade retro Cycle en V !

7. Vade retro Cycle en V !

Les 7 pièges des méthodes agiles : Vade retro Cycle en V !

Avec la démocratisation des méthodes agiles, les méthodes dites traditionnelles (cycle en V notamment) ont fortement été critiquées et même complètement caricaturées. Au delà du fait que ces méthodologies fonctionnent très bien dans l’industrie, il faut rappeler que la plupart des gros projets informatiques sont découpés en lots et finalement organisés sous forme de petites itérations. Un client qui débourse 10 millions d’euros et ne revient que 2 ans après voir le résultat sans aucun suivi : ça n’existe pas. L’effet tunnel dont tout le monde parle est exagéré.

Dans le domaine de l’informatique, le TTM est oppressant impliquant des changements rapides, dès la phase de développement. C’est justement le point faible des méthodes comme le cycle en V qui se veulent prévoyantes à tous niveaux, les changements sont extrêmement coûteux car impactant le planning, les diagrammes de conception, les contrats, ressources… et engendrent souvent des conflits contractuels. Cela ne veut pas dire que la méthode n’est qu’un regroupement de mauvaises pratiques !

Ainsi, par soucis de ne pas être pleinement en mode agile ou par crainte de retomber dans les processus lourds des méthodes traditionnelles, les décideurs peuvent être tentés de faire une totale abstraction de tous les aspects positifs des méthodes traditionnelles et ainsi aboutir dans un mode de fonctionnement un peu trop start-up, beaucoup plus hasardeuse.

Conclusion

En conclusion, il est indispensable d’avoir en tête que les méthodes agiles ne sont que des méthodes de développement : les hommes changent moins vites que les méthodes ! La conception doit rester une phase à part, même si intégrée itérativement, et un réel pilotage de projet doit être mis en place. Si l’on garde ces éléments à l’esprit on peut tirer tout le profit de ces méthodes : une communication efficace entre métier et technique, des gains de qualité considérables et une meilleure prise en compte des problématiques techniques dans les projets.

5 réponses

  1. Cher visiteur, n’hésitez pas à parler de votre expérience ! Partagez-vous les points abordés dans cet article ?

  2. Patrick Thazard dit :

    Merci pour cette synthèse sur les méthodes agiles.
    Pour compléter votre analyse, il me semble que la gestion des priorités est un autre élément critique.
    Par exemple, dans les années 90, j’ai vu la méthode DSDM – ancêtre des méthodes agiles – être appliquée de manière catastrophique à un grand projet informatique pour un ministère.
    Il fallait reprendre une énorme base de données dans la nouvelle application, avec un modèle de données bien diférent, mais cela n’a pas été considéré comme prioritaire.
    La priorité était de livrer aux représentants des utilisateurs une nouvelle version du logiciel toutes les 3 semaines, en développement itératif.
    Résultat : quand il a fallu au bout de 12 mois injecter les anciennes données dans la nouvelle base, fondement de tout ce qui avait été développé, et bien, tout a explosé… Les erreurs et incompatibilités entre l’ancienne et la nouvelle base étaient ingérables.
    Dis comme cela, cela parait évident, et pourtant, croyez-moi, le projet était mené par des personnes compétentes et brillantes, mais trop convaincues du bien fondé de DSDM…

  3. Merci pour votre commentaire, je suis totalement d’accord. Cela me fait penser qu’en plus d’erreurs graves de priorisation technique sur le long termes comme vous l’évoquez, il y a l’accumulation de petits éléments soit disant importants et donc fortement priorisés qui en réalité ne sont pas du tout indispensables et finalement entravent la réalisation du projet plus qu’autre chose. D’où la méthode Lean d’ailleurs ! Ces situations cachent malheureusement un aspect politique pas évident à gérer.

  4. Luc PdM dit :

    Merci pour cet article sur les écueils ou dérives possibles du mode agile.

    Juste un point de désaccord, pour ce qui est du cycle en V. Je ne partage pas vraiment votre analyse. D’abord, je vous invite vraiment à regarder ce que fait l’industrie en la matière (automobile ou aérospatiale), cela fait longtemps qu’ils ne font plus d’ingénierie séquentielle. La taylorisation séquentielle du travail sur des systèmes complexes ne fonctionne tout simplement pas (cf. toutes les études sur l’ingénierie des systèmes complexes). Ensuite, en mode agile, et surtout, agile à l’échelle (j’y inclus tous les principes Lean) on retrouve bien des principes d’anticipation, de synchronisation qui sont présent dans le cycle en V. Donc on ne jète pas tout, mais on pense le travail (et l’organisation du travail) vraiment différemment.

Laisser un commentaire

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