Cet article fait suite à ceux consacrés au cycle en V et au cycle itératif. Dans l’histoire des méthodes de gestion de projets informatiques, les méthodes agiles sont une évolution relativement récente qui tente de résoudre certains défauts des pratiques qui étaient en usage jusque-là.
Le manifeste agile
La définition de toutes les méthodes agiles est synthétisée par le Manifeste agile, qui a été rédigé en 2001 par plusieurs acteurs de ce domaine. Il distingue 4 valeurs fondamentales et 12 principes.
Les 4 valeurs
(traduction © Wikipedia et al)
- L’interaction avec les personnes plutôt que les processus et les outils.
- Un produit opérationnel plutôt qu’une documentation pléthorique.
- La collaboration avec le client plutôt que la négociation de contrat.
- La réactivité face au changement plutôt que le suivi d’un plan.
Les 12 principes
(traduction © Wikipedia et al)
- Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.
- Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.
- Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.
- Les gens de l’art et les développeurs doivent collaborer quotidiennement au projet.
- Bâtissez le projet autour de personnes motivées. Donnez leur l’environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.
- La méthode la plus efficace de transmettre l’information est une conversation en face à face.
- Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.
- Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.
- Une attention continue à l’excellence technique et à la qualité de la conception améliore l’agilité.
- La simplicité – l’art de maximiser la quantité de travail à ne pas faire – est essentielle.
- Les meilleures architectures, spécifications et conceptions sont issues d’équipes qui s’auto-organisent.
- À intervalle régulier, l’équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.
Application concrète
Il existe plusieurs méthodes qui suivent l’esprit du manifeste. Elles ont chacune leurs spécificités, mais de manière globale elles œuvrent toutes dans les mêmes voies.
- Le client, qu’il soit interne ou externe, est intégré au plus près du projet. Il est informé des avancements et des problèmes rencontrés. Le but est de produire un logiciel qui satisfasse le client, et non qui respecte à la lettre la spécification fonctionnelle rédigée plusieurs semaines ou mois auparavant. Il faut donc valider fréquemment que la direction prise soit celle qui mène à sa satisfaction effective.
- Les équipes sont réduites, avec peu de distinction hiérarchique, et les collaborateurs peuvent se faire confiance les uns les autres. L’analogie employée est celle d’une escouade de guérilla, plus rapide et efficace qu’un énorme bataillon d’infanterie. En diminuant le nombre d’intervenants, on optimise les communications.
- Les livraisons de logiciel sont rapides. Chaque version est ainsi plus « légère » : elle est plus rapide à installer et à tester. Il est plus facile de changer d’orientation sur un projet quand chaque évolution « coûte » peu, et évite d’avoir à modifier des fonctionnalités qui ont déjà été développées.
Comme pour toute méthode de gestion de projet, le but des méthodes agiles est de réussir à sortir de meilleurs logiciels (du point de vue du client) pour un coût moindre (principalement grâce à une réalisation rapide). Pour expliquer leur fonctionnement, je dis souvent qu’il s’agit de la mise en place d’un cycle itératif sous stéroïdes. Les développements restent itératifs, mais en tentant de raccourcir au maximum la durée du cycle.
Risques et écueils
Un des principaux écueils qui peuvent être rencontrés quand on décide de mettre en place ce type de méthode dans un groupe de projet, c’est que la frontière est parfois ténue entre l’application de la méthode et le « n’importe quoi » qui s’installe quand on laisse travailler une équipe sans méthode. Beaucoup de gens n’y voient qu’une structuration des plus mauvaises pratiques du monde de l’entreprise :
- La réactivité, c’est lorsque le client change sans arrêt d’avis, et qu’on s’efforce de le suivre comme une girouette.
- La mise en place d’une équipe réduite, c’est quand on n’a pas assez de développeurs et qu’on leur donne plus de travail à faire que ce dont ils sont capables.
- Les cycles de développement ultra-rapides, c’est quand on n’a pas le temps de tester correctement les nouvelles versions, et qu’on est obligé de faire des versions de correction en urgence quand le client découvre des bugs.
- Sans parler des développeurs incapables d’écrire la moindre documentation technique, des chefs de projet qui ne veulent pas faire de planning, ni des outils de suivi inexistants…
Cela est assez vrai. Mettre en place une méthode agile nécessite que tous les acteurs soient impliqués dans le processus, en connaissent les avantages et acceptent de jouer le jeu. Certaines personnes n’ont pas la flexibilité d’esprit nécessaire pour y arriver et ont besoin de méthodes plus directives (cf. cycle itératif).
Mais si vous réussissez à mettre en place les outils nécessaires et à former les gens, vous pourrez focaliser l’équipe sur un but commun : la réalisation du projet. C’est une grande avancée par rapport à d’autres méthodes, qui sont basées sur l’affectation de tâches à des employés (tels des robots) et leur surveillance par leur hiérarchie. L’objectif est de réussir le travail, pas de permettre à une ou plusieurs personnes de jouer les petits chefs en faisant claquer le fouet au-dessus des têtes.
Je reviens sur cet article que j’ai lu il y a quelques temps. Je pense que ces méthodes agiles ne peuvent pas s’appliquer aux grosses structures.
Cela débouchera inévitablement sur un joyeux bordel.
Une grosse SSII a besoin de processus précisément définis et d’une industrialisation poussée pour être compétitive. Et la satisfaction du client peut être également obtenue de cette façon.
Avoir des processus communs à toute l’entreprise permet une meilleur mobilité des collaborateurs et une plus grande efficacité.
Tu serais étonné, si tu savais à quel point les SSII sont justement les « locomotives » qui ont poussé l’usage des méthodes agiles (et plus particulièrement l’extrem programming, en fait).
Même dans les grosses SSII, la majorité des développements sont fait par des équipes de taille relativement réduite, pour lesquelles l’agilité est primordiale. Il ne faut pas oublier qu’en France, 84% des SSI ont moins de 50 employés (source Wikipédia). Les gros projets, ceux qui réclament des équipes de plusieurs dizaines de personnes restent une exception.
Sans compter qu’un grand nombre de SSII placent leurs employés chez leurs clients, que ce soit comme développeur, chef de projet ou consultant ; et dans ce cas les méthodes agiles montrent tout leur intérêt.
Il faut bien comprendre que le but premier des méthodes agiles est la satisfaction du client, plutôt que la conformité à un contrat. Et pour les SSII, un client satisfait est un client qui revient.
Maintenant, je concède que les méthodes agiles ne sont pas applicables dans tous les cas. Et les sociétés de services ont souvent mis au points leurs propres méthodes de gestion de projet, adaptées à leurs organisations. Mais bien souvent ces méthodes sont – ou évoluent vers – des méthodes itératives malgré tout.
C’est bien pour cela que j’ai précisé grosse SSII, car je sais bie qu’il en exste une multitude de taille réduite.
Et le travail en AT ou en régie dépend beaucoup des méthode de travail du client. En AT, c’est souvent une obligation de moyen sur laquelle on s’engage. Et le prestataire se plie lors aux processus métier du client.
Je suis bien placé pour voir ce qu’il se passe dans les groses SSII. Le maître mot aujourd’hui, c’est industrialisaton. Généraliser l’utilisation de mêmes pocessus et des même outils au sein de toute la société. Cela pemet pour chaque collaborateur d’être efficace tout de suite, quel que soit le projet sur lequel il est amené à travailler.
En cela, c’est donc difficilement compatible avec les méthodes agiles, qui par définition dépendent intrinsèquement du projet sur lequel on travaille. Je persite en disant que cela s’applique sans doute très bien aux petites structures, mais que ce n’est pas adapté aux grosses.
On ‘sentend donc.
Les méthodes agiles, ou plus simplement les processus itératifs, ne sont pas synonymes de joyeux bordel où chacun fait les choses à sa sauce dans son coin. Ce sont des sujets maintenant bien normalisés. Une rapide recherche sur Internet ou dans les rayons d’une librairie informatique permet de voir à quel point leur utilisation se répand dans les sociétés de service, qui les adaptent évidemment à leurs besoins.
La plupart d’entre-elles ont entamé leur mutation vers les méthodes agiles, et vont jusqu’à communiquer dessus (à l’image du « Accenture Agile Delivery Capability »).
Ce qui est par contre assez courant, c’est la résistance passive au changement :
- « Ça marche, ce truc ? »
- « OK, ça doit bien marcher chez les autres, mais nos besoins sont vraiment différents ! »
- « On a nos habitudes, rodées par 20 ans d’expérience, on peut pas faire mieux »
- « Bon, on va essayer sur un projet, pour voir »
Les grosses SSII qui forment leurs collaborateurs aux méthodes agiles mettent en place des méthodologies qui sont les mêmes pour tous, et qui sont utilisables sur tous les projets. Je connais des exemples chez Atos, Sopra, Accenture, Cap Gemini, IBM, …
En réponse à Drandran, je pense que au sein d’un proess global de l’entreprise on peut penser, particulièrement dans le domaine du GL, que les équipes appliquent de l’agile (Scrum est assez à la mode) pour le développement de leur sous-projet.
Il faut cependant ajouter que ça se passe sur des itérations courtes, de l’ordre de la semaine. En Scrum, on va simplement remplir le Backlog (liste des taches qu’il faut réaliser) avec l’info qui dérive du Process global de ta grosse SSII (disons Thalès, si ça te parait de taille suffisante). L’itération du Process externe à l’équipe, auquel elle se plie, englobe plusieurs itérations de scrum (1 mois = 4 itérations). On se fixe donc comme objectif (pas agile du tout) le délivrable spécifié par le process externe, mais on applique Scrum à l’échelle de l’équipe.
Ce qui reste agile, c’est la façon dont l’équipe attaque le problème, car à objectif fixe (le délivrable), les moyens de l’atteindre varient. La découpe du travail sur ses membres en fonction des besoins et des difficultés renconrées est également agile, et la visibilité du travail de chacun est augmentée par tout le travail sur l’action coopérative que préconise la méthode.
Bref, l’agile ne me parait pas exclusif de process plus lourds (voire avec nécessité de certification, et ça c’est bien lourd) autour.
Bonjour, chaque année apporte son lot de buzz words, et en 2009 c’était les « méthodes agiles ». qui s’en souvient aujourd’hui? la mise en place de nouvelles méthodes de gestion de projet exige une analyse des risques rigoureuse, et est demandée par la plupart des grandes entreprises. Des outils gratuits d’analyse des risques sont disponibles sur notre site Projiris.fr . Cordialement
Dans le monde des sociétés SSII, on parle de tout et de rien, cycle en V, cylce W, méthide agiles, analyses organiques, méthides experts, et que sais-je. Mais dès qu’il s’agit d’aborder les vrais projets dans toutes leurs définitions, problèmétqiues, ces gens disparaissent de la scène et commence à commenter tel ou tel principae n’a pas fonctionné. En France, notre problème en informtqiue et qu’on perds entre 20 et 30% dans des question inutiles alors qu’il faut se focaliser sur le conceptuel réel et non virtule, sur la créativité, sur la comppréhension directe des règles de gestion , éviter les méthodes inutiles, penser aux méthodes dites de perrtes et adapter à chaque projet ces algorithmes; Même dans les grandes domaines de la science qui dépasse largement cette discipline informatique, il n’existe pas une seule méthode mais bel et bien plusieurs méthodes et seuls les mieux placés svaent de quoi il’agit et quand et comment les adapter au lieu d’écouter des personnes qui viennet apllqiuer telle ou telle méthiode pour une périuode donnée pour justifier leur poste et leur présence. Il faut ques les entreprise qui souffrent de cela; pense avant à adapter des méthodes en fonction de son peojet qu’il soit compliqué ou commplexe et par éxpérience dans la conduite de projtes scientifiques et informatqiues de gestion, je sais de quoi je parle
MERCI
Le gros problème des méthodes agiles, c’est qu’elles servent trop souvent de prétexte à un nombre trop important de « pseudo chefs de projet » (aussi appelé « petits chefs »), pour ne plus rien faire. « Inutile d’établir un cdc, on fait du scrum, on doit être à l’écoute du client » et autres stupidités du même genre. Au contraire d’augmenter la qualité du produit, on augmente les coups et on bascule toutes les charges et toutes les responsabilités sur les développeurs.
Oui, c’est vrai. C’est bien pour ça que mon article parle aussi des risques et écueils des méthodes agiles.