La grande diversité des méthodes agiles et de leur pratique génère de nombreuses idées fausses à leur sujet. L’objet de cet article est de démystifier les idées fausses les plus courantes trouvées dans les débats sur le Web en y répondant factuellement.
L’arrivée des Méthodes Agiles est en train de générer un fossé entre leurs partisans et ceux des méthodes traditionnelles. Cette rupture est renforcée par le fait que les 4 principes fondateurs des méthodes agiles sont des contre-pieds vis à vis de l’approche classique:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
(cf. le Manifeste Agile, site officiel: http://agilemanifesto.org/)
L’idée ici n’est pas de prendre parti pour les méthodes agiles contre l’approche classique. Chez Time Performance, nous pensons que chaque approche peut être bonne ou moins bonne selon le contexte.
Idée fausse n°1: Les Méthodes Agiles sont réservées aux « petits » projets
Faux, faux et archi-faux… C’est pourtant l’idée la plus répandue. C’est aussi la plus fausse.
1) Les Méthodes Agiles ont pour raison d’être de permettre au projet de s’adapter facilement aux changements (« Reponding to change.. »). Cela n’a de sens que pour les projets de durée plutôt longue, car le risque de changement est d’autant plus fort que le projet s’éternise. De plus, la durée est nécessaire pour rentabiliser l’investissement lourd qui est fait dans les tests, leur automatisation et la qualité du code, qui sont au coeur des méthodes agiles.
D’ailleurs les méthodes Agiles ont été conçues pour le développement de produit logiciel (d’où le terme de Product Owner qu’on trouve dans SCRUM), dont la durée de vie s’étend sur plusieurs années voir plusieurs décennies.
Cette idée fausse a peut-être été inspirée par la brièveté des cycles de développement. Or un développement itératif a pour but d’éviter le risque d’effet tunnel, qui est d’autant plus important que le projet est long.
Donc les méthodes Agiles sont particulièrement adaptées, voire recommandées, pour les projets de longue durée et non pour les projets courts.
2) Concernant la taille de l’équipe, il est vrai que SCRUM limite la taille des équipes à 8 ou 9 individus, et XP le recommande en pratique, car c’est le fonctionnement optimal. Mais rien n’interdit de constituer plusieurs équipes qui travailleront chacune sur un sous-projet. D’ailleurs SCRUM le prévoit avec un mécanisme de coordination qui s’appelle le SCRUM de SCRUMs. Une équipe de plusieurs dizaines de personnes peut être ainsi constituée.
Idée fausse n°2: La classification « Méthode Agile » détermine un groupe homogène
Les méthodes Agiles sont très différentes les unes des autres. Elles sont même parfois presque totalement complémentaires, comme XP et SCRUM. Si ces 2 dernières méthodes marquent une réelle rupture par rapport à l’approche classique, certaines comme le Unified Process constituent des chaînons intermédiaires de l’évolution des méthodes au cours des 20 dernières années.
Toutes ces méthodes ne s’entendent que sur les 4 principes, ce qui est peu. De plus, le Manifeste Agile offre certaines latitudes en matière d’interprétation. Il est donc hasardeux de parler des Méthodes Agiles en général. Il vaut mieux parler des pratiques proposées par telle ou telle méthode.
A cela, il faut ajouter que les mises en oeuvre de ces méthodes sont encore plus hétéroclites.
Idée fausse n°3: Les Méthodes Agiles sont des méthodes de gestion de projet
Cette partie a été réécrite suite au débat né avec les nombreux commentaires ci-dessous afin de préciser les arguments. Si cette idée est vraiment fausse, comme nous le croyons, elle semble difficile à combattre 😉 .
L’objet principal des méthodes agiles est le processus de développement (logiciel) depuis la définition du besoin jusqu’à la livraison d’un produit. Ceci est attesté par le Manifeste Agile qui représente l’âme de ces méthodes et qui commence par Nous découvrons comment mieux développer des logiciels… (source manifeste agile).
La notion même de projet n’est pas requise pour utiliser SCRUM ou XP. Ce qui compte dans ces méthodes, c’est le développement d’un produit. Or on peut développer un produit en dehors du cadre formel d’un projet et utiliser SCRUM ou XP.
Si une méthode agile est utilisée sur un projet, cela ne remplace pas la mise en place d’une vraie gestion, ne serait-ce qu’au niveau des coûts. Il y a plusieurs autres domaines non couverts par l’agilité: l’établissement d’un cas d’affaire (business case), la gestion des parties prenantes, la gestion des risques, la conduite du changement, les phases amont et aval d’un projet…
Notons que cette idée fausse n’existe pas dans le monde anglo-saxon. Nous n’avons pas trouvé d’exemple parmi toutes les vidéos disponibles sur Internet ou dans des articles en anglais où SCRUM était présenté comme « a project management method » ou « a project management framework ». Amusant, dans la traduction en français du manifeste agile, le principe Welcome changing requirements, even late in development est devenu Accueillez positivement les changements de besoins, même tard dans le projet plutôt que même tard dans le développement. Bizarre, non ?
Idée fausse n°4: Les Méthodes Agiles sont des méthodes de développement rapide ou de prototypage
Des cycles de livraison courts ne signifient pas que les développements sont rapides. Cela implique simplement de valider l’avancement régulièrement et concrètement.
Il y a même fort à parier que les développements seront moins rapides au départ par rapport à un cycle en V, à cause des exigences en matière de qualité de code et de couverture de tests, incluant de nombreux refactorings (redéveloppements). Ce n’est donc pas une bonne approche pour faire du prototypage.
Les projets Agiles sont des marathoniens et non des sprinters. C’est pourquoi ils voyagent légers. Et sur la distance, ils sont en général les plus rapides et consomment moins.
Idée fausse n°5: Les développements agiles sont difficilement maintenables à cause du manque de documentation
La crainte de voir la connaissance du fonctionnement du logiciel partir avec les développeurs à l’issue du projet est parfaitement légitime lorsque la documentation est insuffisante.
Cependant c’est une erreur de considérer qu’il n’y a pas de documentation. A l’instar de l’Open Source, dans une approche Agile, la principale documentation est le code source. Et comme de nombreuses livraisons sont réalisées tout au long du projet, tout est fait pour garantir une parfaite maintenabilité.
D’une part, les règles de codage sont très strictes et leur validation automatisée. Plusieurs pratiques au coeur des méthodes Agiles (le refactoring, l’absence de Code Ownership, le Pair Programming etc.) garantissent au final un code source propre, bien conçu, lisible et bien documenté.
D’autre part, dans code source il faut inclure les tests (unitaires, intégration, fonctionnel etc.). Les tests sont comme un document de spécifications détaillées et un outil de validation intégrés. C’est un investissement non négligeable mais indispensable pour la maintenabilité et l’évolutivité.
Dans une approche agile, le code source et les tests tiennent lieu respectivement de conception détaillée et de spécification détaillée, exprimées en langage naturel dans les commentaires et en langage informatique. Le gros avantage est de garantir que la documentation est toujours à jour par rapport au code, et que le code reste conforme aux spécifications grâce à l’exécution quotidienne des tests avec l’intégration continue. Un développement agile devrait donc être très facile à maintenir.
En réalité, la vraie question est: « Entre une documentation complète (spécification, analyse, conception etc.) et un code source propre et bien testé que choisiriez-vous? »
Les méthodes agiles donnent la priorité au code source et aux tests. Le cycle en V favorise dans la pratique les documents qui sont générés en amont du projet, au détriment du code et des tests situés en aval du cycle lorsque la pression pour aller vite, trop vite, est beaucoup plus forte.
Cet article a maintenant une suite: 5 autres idées fausses sur les Méthodes Agiles
Dans la méthode SCRUM, il n’y a plus de Chef de Projet mais un Product Owner (Directeur Produit) et un Scrum Master.
A la moindre difficulté, le projet risque de devenir le terrain d’une lutte où les 2 clans se retranchent derrière leurs positions: la MOA réclamant les fonctions indispensables pour les utilisateurs et la MOE invoquant la faisabilité technique ou les délais trop courts.