|
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 mais de permettre des débats sains. En effet, chez Time Performance, nous sommes convaincus qu'il n'y a pas de méthode bonne dans l'absolu. Et c'est d'ailleurs pourquoi notre logiciel de gestion de projet a été conçu pour être souple tout en s'inspirant des meilleures pratiques et outils, agiles ou classiques.
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, voir 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
D'une part, l'objet des méthodes agiles est le développement logiciel et non la gestion de projet. Si certains sujets de la gestion de projets sont évoqués comme les estimations et la planification, d'autres sont tout bonnement absents (par exemple la gestion des coûts).
D'autre part, les méthodes agiles ne sont pas des méthodes. Les auteurs de XP et de SCRUM les définissent comme des ensembles de bonnes pratiques.
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.
Trackback(0)
 |
Blog 
TrackBack URI for this entry
Subscribe to this comment's feed
Show/Hide comments
Show/Hide comment form
Je vous dirais continuer, la connaissance d'agile grand publique est encore jeune. Conséquence, il y a beaucoup de fausses idées. Ensemble, nous finirons par expliquer mais surtout faire comprendre la vrai réalité des méthodes (approches) Agiles.