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
Coach Agile et Achitecte informatique
Excellent Billet, j’ai souris en lisant vos points. Je ne compte plus le nombre de fois que j’ai du fournir ce genre d’explications.
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.
L’idée fausse n°3 me parait… fausse.
Certes, toutes les méthodes agiles ne sont pas des méthodes de gestion de projet. XP, comme vous le soulignez, est plutôt une méthode d’ingénierie logicielle.
En revanche, Scrum est bien une méthode de gestion de projet:
– Il s’agit bien d’une méthode et pas seulement d’un ensemble de bonnes pratiques, puisque Scrum décrit un processus de cycle de vie du projet complet et précis.
– Elle recouvre les domaines classiques de l’intégration, du contenu, du temps, de la qualité, des RH, la communication. Les coûts, comme les risques, ne sont pas explicitement traités, mais rien ne s’oppose à mettre en place un indicateur de performance de coût (Technique de la valeur acquise), et d’autre part Scrum dans son ensemble peut être considérée comme une gestion de risques…
Entièrement d’accord avec Olivier! sauf pour le titre, je dirais pour le coup : l’idée reçue n°3 est bien vraie!
J’ai développé l’idée n°3 pour clarifier l’argumentation. Peut-être trouverons-nous un terrain d’entente…
Réponse à: L’idée fausse n°3 me parait… fausse
Merci d’avoir ouvert le débat sur ce point.
A propos de SCRUM, Ken Schwaber le dit lui-même « SCRUM isn’t a methodology » dans cette vidéo (http://www.youtube.com/watch?v=IyNPeTn8fpo avancer jusqu’à 11 min. 40 s.). Ce co-auteur de SCRUM le définit plutôt comme un ensemble des meilleures idées, un ensemble de pratiques et de règles, un framework… (autre source: http://www.scrumalliance.org/resource_download/227).
Loin d’affaiblir la valeur de SCRUM, cela la renforce car cela étend son domaine d’application. SCRUM est plutôt « inclassable », entre le processus de développement et le management d’équipe.
Retour sur l’idée fausse n°3
Si les méthodes agiles ne sont pas des méthodes de gestion de projet, pourquoi classer ce billet dans la catégorie « Gestion de projet 2.0 » ? 😉
[NDR] la catégorie a depuis été renommée « Gestion de Projet » tout court.
Encore l’idée fausse n°3
Pourquoi classer ce billet dans cette section du blog ?
Tout simplement parce qu’il y a une interdépendance très forte entre le processus de développement et la gestion de projet. C’est d’ailleurs pourquoi dans SCRUM la frontière entre les 2 domaines n’est pas toujours très claire.
Un nouveau type de processus développement conduit à changer notoirement la façon de gérer les projets, d’où le 2.0 qui marque une évolution majeure.
Enfin, si vous vous intéressez aux méthodes de gestion de projet, je vous recommande fortement Prince2.
Débat sur le point 3 et gestion des coûts
@Alexandre
Merci pour votre commentaire qui fait naturellement surgir la question suivante:
– Qui est le chef de projet dans SCRUM (c-à-d qui fait de la gestion de projet dans SCRUM), le Product Owner ou le SCRUM Master ?
Il est difficile de trancher. Personnellement, je pencherais plutôt vers le Product Owner, qui a le pouvoir de décision et les cordons de la bourse. Le SCRUM Master s’apparenterait alors à un Team Manager, tel que définit dans Prince2.
C’est un débat un peu théorique car en pratique les rôles se mélangent allègrement. 😉
Débat sur le point 3
Merci pour ce bilet. Il me donne du grain à moudre. Concernant le point 3, j’ai aussi quelques remarques. Je suis plutôt orienté SCRUM pour le moment. Je voudrais revenir sur la partie de gestion de budget. Si effectivement elle n’est pas présente pour le SCRUM Master, je pense que c’est uh point que dois gérer le Product Owner. Enfin, je n’ai pas fait la formation PO alors je m’avance peut-être un peu mais ça me semble être du bon sens. En tout cas, pour ma part, SCRUM peut tout à fait se substituer sur l’ensemble des points de gestion de projet classique. Du moins, c’est expérience que j’en ai.
Réponse à l’idée fausse N°3
Ma réponse se décompose en deux parties:
1. les méthodes agiles
2. Scrum
Concernant les méthodes agiles, je suis assez d’accord que celles-ci ne sont pas « une méthode » mais un ensemble de règles et de bonnes pratiques ayant eu comme support originel le développement de logiciels.
L’agilité peut être considérée comme un fil conducteur, une philisophie, le concept de base.
Pour Scrum, il s’agit en fait de tout autre chose.
Scrum est une méthode de Gestion de Projet, permettant de manager un projet de manière extrêment efficace. Dans cette structure où le rythme est le moteur de base, se joue la mise en place de l’agilité.
Si nous parlons de Gestion de Projet, nous parlons également de Responsable de Projet.
Dans Scrum, l’approche se fait de façon démocratique, càd:
– Le ScrumMaster est le responsable du Process (et de l’architecture/organisation in extenso)
– Le Product Owner est le responsable du produit
Ils sont tous les deux responsables, Pourquoi? Le Product Owner s’engage sur le Produit et sur la Release; le ScrumMaster s’engage à développer un Process « Industriel ».
Scrum fonctionne seulement si les deux « managers » co-habitent.
C’est pareil dans une entreprise: le PDG est responsable du Process, le DG est responsable du Produit; ou le PDG est responsable du Bilan et le DG est responsable du compte de résultat.
Idée n°3 vue au travers du guide PMBoK
Les méthodes agiles et scrum en particulier sont-elles des méthodes de gestion de projet ? On peut trouver des éléments de réponse à cette question dans le PMBoK guide.
Scrum est bien une méthode de gestion de projet, dans la mesure où elle propose des outils et des pratiques pour chacun des 5 process groups (§1.3). Il n’est écrit nulle part qu’une méthode doit proposer des solutions pour tous les items, bien au contraire, c’est au chef de projet de déterminer les outils et artefacts à utiliser, en fonction de leur coût d’utilisation et des contraintes du projet : l’éventail sera complet pour la construction d’une centrale nucléaire ou le développement d’un nouveau TGV, réduit à l’essentiel pour un site web développé sur moins d’un mois.
Un autre insight est apporté par le PMBoK guide : c’est l’explicitation de la différence entre les projets et les opérations. Ces dernières supportent les projets, mais se concentrent sur des productions et des services récurrents. Dans la mesure où Scrum fonctionne comme un flux, standardise les opérations, introduit une répétitivité au travers des sprints, la méthode peut être porté par les opérations. La construction du project charter doit prendre comme éléments d’entrée les pratiques et contraintes opérationnelles. Dans le charter d’un tel projet, on trouverait donc « le projet sera organisé et suivi avec la méthode scrum, le scrum master sera X, le sponsor sera Y, etc. »
Un chef de programme bâtit un planning et une structure de coût pour un projet donné sur la base du calcul de vélocité de projets antérieurs, et des planning-pokers, et un responsable d’un petit B.E software, owner des process opérationnels pour le dév software, pourrait remplir le rôle d’un scrum master sur ce projet.
Concernant les méthodes agiles, il faut voir au cas par cas:
XP représente juste des guidelines, et d’ailleurs on couple souvent l’extereme programming avec scrum pour avoir des éléments de suivi de projet.
Le Lean software development, en revanche, est typiquement un ensemble d’outils et de méthodes opérationnelles qui apporte ses process prêts à l’emploi pour la gestion de projets. Ainsi, le contrôle de l’avancement et du « product backlog » est déjà porté dans un système kanban.
Article traduit en anglais
http://dantotsupm.wordpress.com/2010/04/22/10-false-ideas-about-agile-methods/
J’ai enfin trouvé le temps de traduire cet intéressant article en Anglais. Michel.
J’ai voulu poster le même commentaire que j’ai posté sur votre version anglaise, mais malheureusement ça n’aurait pas de sens… car il faudrait qu’Olivier Destrade remette son commentaire pour que je dise que I completely agree with him 😉
Sur le terrain …
En soit bien documenter son code est une bonne chose (dedans), mais si c’est l’unique design comme suggéré par l’Xp, c’est du hack code, c’est à dire inmaintenable …
L’Xp dans la bouche de certains codeur c’est avoir le droit de faire du code spaghetti orienté … fonctionnel, de coder sans de presque de design et de test … ils te font des régressions et après ils disent je fais de l’Xp et ils font perdre du temps au team, qui eux suive le process classique (itératif cela dit) design/codage/test. D’où avez vous vu un cycle en V sans itération aujourd’hui (depuis 10 ans ..) ???
RE: Sur le terrain …
Pour la doc, je pense qu’il faut absolument différencier les specifications (description des exigences) de la documentation du produit final. Passer en agile permet d’avoir une spécification ‘légère’ et un retour rapide. Malgré tout prévoir une phase de documentation dans chaque story n’est pas un luxe car suivant nos interlocuteurs, n’avoir que des tests passant n’est que rarement suffisant. L’avantage c’est qu’on ne documente que les parties du soft validées.
Re: sur le terrain
La maintenabilité du code est à mon humble opinion supérieure en approche Agile pour les raisons expliquées au point n°5. Encore faut il suivre les pratiques agiles… Le fait de prétendre faire de l’Xp ne suffit pas.
Je suis à 100% d’accord avec vous sur votre dernière remarque. Personne ne pratique plus le cycle en V comme dans les années 70. Il y a quand même 2 différences majeures entre les itérations d’une approche par lots avec des cycles de design/codage/test et un mode Agile:
– la durée des itérations, beaucoup plus courte en mode agile,
– le fait d’inclure ou non l’expression de besoins + analyse + spécification dans le cycle.
Cela étant dit, il n’y a pas d’approche meilleure qu’une autre. Cela dépend du contexte du projet et surtout il est possible de faire un mix des deux.
RE: Re: sur le terrain
La grande force des pratiques Agiles, c’est arriver à organiser le projet sous forme d’exigences indépendantes (exercice beaucoup plus compliqué que l’organisation en phases). A mon avis c’est la que la différence se fait avec une méthode classique car elle permet d’avoir la souplesse recherchée tout en restant exigent.
Je travaille dans une SSII, et je constate de plus en plus que les clients considèrent souvent que la méthodologie agile permet en gros de changer d’avis fréquemment, en pouvant exiger du développeur qu’il réagisse rapidement aux changements sans protester (« puisque c’est la méthodologie agile qui le permet »), qu’elle évite de formaliser le besoin (« il n’y a plus de documentation à réaliser »), bref ce serait une méthodologie idéale pour le prototypage, pour les fonctionnalités qui évoluent du jour au lendemain selon les idées du donneur d’ordre, et pour ceux qui sont incapables de formaliser leur besoin et de respecter ensuite cette formalisation. Pouvez vous me confirmer que c’est là une vision erronée de la méthode Agile, et qu’elle exige en réalité une vraie rigueur (au moins autant que le cycle en V) ?
Agilité ne veut pas dire Chaos.
Un des principes fondamentaux de SCRUM est que l’utilisateur ou le client ne peut pas perturber le travail en cours des développeurs, i.e. le Sprint. C’est au Scrum Master de protéger l’équipe de ce type de perturbation.
Par contre, le product owner qui représente les utilisateurs (notez que c’est déjà un premier niveau de filtrage) peut modifier les fonctionnalités pour les sprints suivants.
Conclusion: il n’y a pas de modification du jour au lendemain pour les devs. Et le client peut quand même changer souvent d’avis puisqu’un Sprint a une durée courte, en général de 15 jours. Les specs sont donc figées pour les 15 jours à venir par contre tout est possible pour la suite.
Dernier détail, en mode Agile, le besoin est formalisé. C’est d’ailleurs une précondition pour le démarrage d’un Sprint. Pour le niveau de formalisation, cela peut varier mais en tout cas il correspond à ce qui est nécessaire et suffisant pour que l’équipe puisse bien comprendre le besoin, estimer le travail et avec des scénarios de tests de validation.
Intéressant!!!