Les méthodes Agiles sont-elles une arnaque ?
Plutôt que :
On fait :
L’approche traditionnelle consiste en l’expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. Le client reçoit à la fin du process la solution afin de réaliser la recette. . Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l’application réalisée. On se rapporte alors aux spécifications validées et au contrat. Ainsi, certains projets se retrouvent en inadéquation avec le besoin réel du client. En effet, durant le process de développement, certaines fonctionnalités demandées se révèlent finalement inutiles à l’usage alors que d’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.
L’approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus de développement itératif et incrémental.
Qu’est-ce que l’agilité ?
Les méthodes agiles sont apparues en 2001 lors du rassemblement de 17 spécialistes du développement logiciel. De cette réunion devait émerger le Manifeste agile, considéré comme la définition canonique du développement agile et de ses principes sous-jacents1.
Le Manifeste agile est constitué de 4 valeurs et de 12 principes fondateurs :
- L’équipe et la communication avant les outils et processus : Selon la vision agile,il est préférable d’avoir une équipe soudée et dont les membres communiquent entre eux, composée de développeurs de niveaux différents, plutôt qu’une équipe composée d’experts qui travaillent de manière isolée.
- L’application avant la documentation : La documentation technique n’est pas la finalité d’un projet. Il est parfois préférable de simplement commenter abondamment le code lui-même.
- La collaboration avant la négociation : le client doit être impliqué dans le développement. Le fournisseur ne doit pas se contenter de négocier un contrat au début du projet, puis de refuser l’évolution des besoins du client. Le client doit collaborer avec l’équipe et fournir des comptes rendus réguliers sur l’adaptation du logiciel à ses attentes.
- L’acceptation du changement et la flexibilité avant la planification : la planification initiale et la structure du projet doivent être flexibles afin de permettre les évolutions attendues par le client.
Le cycle de développement itératif et incrémentale instaure des similarités entre les différentes méthodes agiles. Ainsi le mode opératoire est similaire.
- Le responsable fonctionnel définit et ordonne la production des composants de l’application.
- Le projet est structuré en incréments de 1 à 6 semaines suivant les nécessités (taille, réactivité, visibilité…).
- Une réunion initiale définit les objectifs de l’incrément et organise les tâches à réaliser.
- De courtes réunion d’avancement permettent de donner à l’équipe une vision globale de l’avancement du projet, met en évidence les éventuels problèmes et permet de factoriser les solutions.
- Un incrément achevé est synonyme de livraison complète, développée, approuvée et testée.
- A la fin du projet, une réunion finale permet une rétrospective technique du projet. Ainsi, sont établis des règles de bonne pratique et améliore la cohésion des équipes.
- Le responsable fonctionnel valide le travail de l’équipe et ajuste les besoins entre chaque incrément.
De plus, l’avantage de ce cycle de développement est de livrer l’opportunité au client d’accélérer le « time to market » s’il estime que le produit en l’état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement, il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développées.
Les méthodes Agiles les plus répandus sont au nombre de 5 :
- RAD, méthode de développement rapide d’applications, consiste en la segmentation du projet en 3 phases Cadrage, Design et Construction) dans un délai idéal de 90 jours et de 120 jours au maximum.
- DSDM, Dynamic Software Development Method, représente une version amélioré de la RAD avec notamment une meilleure implication du client, des tests à chaque étape et une fréquence de livraison plus élevée.
- UP, Unified Process, le projet est découpé en phases très courtes à l’issue de chacune desquelles une nouvelle version incrémentée est livrée. Cette méthode repose sur la modélisation UML notamment avec la rédaction des cas d’utilisation.
- XP, eXtreme Programming, est une méthode Agile reposant sur des principes plaçant le client au cœur même du process. Les développeurs sont en lien direct avec le client. Les premières livraisons se font très tôt et à une fréquence élevée afin de maximiser l’impact des retours utilisateurs. Le Pair Programming est recommandé (l’équipe de développement travaille sur la base de binômes).
- Scrum, dont le nom est un terme emprunté au rugby qui signifie « la mêlée ». Elle s’appuie sur le découpage des projets en itérations encore nommées « sprints ». Un sprint peut avoir une durée qui varie généralement entre deux semaines et un mois.
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. Ainsi, chacune de ces méthodes peut être adaptée dans un type et cadre de mission de développement particuliers.
Exigences
Cependant, ces résultats sont atteignables grâce à des exigences collectives et individuelles très fortes. I y a d’abord une exigence en matière de compétences techniques afin de produire un logiciel de qualité, évolutif et maintenable, bien testé etc. Afin de collaborer, communiquer et s’autogérer, une exigence de savoir-être et de discipline personnelle est primordiale. Etant donné que les méthodes Agiles fonctionnent en mode équipe, une réorganisation des postes est de rigueur (chef de projet, scrum master etc…). De plus, étant enclin aux changements « à la demande » des besoins client, un manque de visibilité à moyen et long termes est à prévoir. Ainsi, la budgétisation des projets pose un souci majeur à la planification des projets en eux-mêmes. Enfin, l’Agilité repose sur une exigence forte de Transparence. Cela peut avoir des implications lourdes pour les organisations et les individus.
Apports des méthodes Agiles
1) Côté client
Dans son rapport concluant une enquête effectuée en 2007, sur 70 entreprises (Total economic impact studies), le cabinet Forrester constate 4 améliorations conséquentes pour les entreprises interrogées :
- 49% d’entre elles ont constaté une diminution des coûts d’opération
- 83% d’entre elles ont constaté une amélioration de la satisfaction du client
- 88% d’entre elles ont constaté une augmentation du niveau de qualité
- 93% d’entre elles ont constaté une hausse de la productivité
7 points d’amélioration ont d’ailleurs pu être soulevé par les entreprises :
- Le changement est facilité, grâce à une meilleure communication entre l’équipe de développement et le client.
- La productivité augmente, le développement par incrémentation permet de se focaliser sur les aspects importants de l’application
- Les ressources humaines sont motivées grâce à une meilleure cohésion de l’équipe.
- La qualité s’améliore.
- Les risques diminuent. Le développement en concordance avec les besoins réels du client permet de répondre précisément à la demande.
- Le « Time to market » se réduit. Le temps de livraison de la version de production est amélioré.
- Cohérence entre développeur et utilisateur
2) Côté prestataire
Par rapport aux autres méthodes, un avantage des méthodes agiles est de faciliter la montée en compétences rapide des membres de l’équipe. Grâce aux cycles itératifs très courts qui permettent des retours rapides sur la performance et de s’améliorer sur l’itération suivante. Par ailleurs, des pratiques comme le Pair Programming (développement en binomes) et le Daily Scrum (réunions quotidiennes informelles) facilitent grandement la transmission de connaissances entre les membres du projet.
En principe: moins l’équipe est expérimentée, plus le « Coach » doit l’être.
La documentation est allégée mais elle est tout de même présente. 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. D’autre part, 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. 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.
Retour d’expérience Prestataire
Les avis par rapport à l’agilité sont divers. Cependant, en général, un manque de conformité aux méthodes tel quels ont été conçus est à l’origine de la plupart des critiques.
Ci-dessous deux témoignages sur le Journal Du Net à propos des méthodes Agiles. L’avantage indéniable de ces méthodes sont de se recentrer sur le client et son besoin. En contrepartie, dans la pratique, les développeurs peuvent se plaindre d’un certain manque de documentation rendant la reprise d’un projet pensé et développé dans un environnement Agile, très laborieuse.
1) Manuel Vacelet le 22 décembre 2011 sur JDN
Quid des avantages et inconvénients des méthodes agiles ?
Les deux principaux avantages d’une démarche agile sont:
v Le recentrage sur le client (par rapport à la fourniture d’un produit)
v L’autonomisation et la prise de confiance de l’équipe de développement.
Cette démarche est au coeur de l’activité d’Enalean pour le développement de la suite Tuleap.
Le principale inconvénient c’est que des générations d’acheteurs et de vendeurs sont formés/habitués à vendre du waterfall traditionnel et qu’ils ne comprennent pas cette nouvelle démarche.
2) Devguy le 17 juillet 2009
Quid des avantages et inconvénients des méthodes agiles ?
A mon avis, l’inconvénient majeur des méthodes agiles est le manque de documentation sur le projet…
Ainsi les difficultés arrivent lorsque l’équipe de projet change ou lorsque la maintenance logicielle doit être faite par une autre équipe…
De même, cette méthode demande un client toujours disponible et prêt à s’impliquer a tout moment…
Et finalement, les méthodes agiles reposent beaucoup sur les individus. Si l’équipe n’est pas homogène (imaginez des conflits entre les développeurs qui travaillent en binôme avec le Pair Programming), le projet ne finira jamais.
Retour d’expérience Client
1) Thierry Roche, DSI de l’Apec
Quels ont été les avantages de ces méthodes pour votre projet ?
Déjà, on voit concrètement l’évolution du projet car après chaque itération, les utilisateurs peuvent visualiser un « bout » de projet qui fonctionne, ça brise l’effet tunnel des méthodes classiques. Cette évolution nous permet de prioriser nos réels besoins, l’application s’enrichit selon nos demandes. Le surplus n’existe pas, on ne développe pas des fonctionnalités qui ne nous serviront jamais comme c’est régulièrement le cas en adoptant des méthodes classiques. On atteint un bénéfice utilisateur plus rapidement mais aussi un gain financier non négligeable. Nous n’imaginons même pas un retour avec des méthodes classiques.
Source : Le Monde Informatique | Dossier méthodes agiles : Le renouveau des relations client/fournisseurs.
Limites des méthodes Agiles
Dans la réalité de leur mise en œuvre, toutes les méthodes ne respectent pas à l’identique les principes fondamentaux agiles.
Les méthodes Agiles sont des méthodes de développement et non de gestion de projet. Ainsi il est indispensable de faire appel à d’autres méthodes pour assurer la qualité et la fiabilité des développements informatiques. De même, lors de projets complexes, il est nécessaire d’ajouter à Scrum comme à eXtrême Programming les pratiques de structuration des exigences qui leur font défaut.
Le mode itératif et l’acceptation des changements a ses limites. En effet, l’ergonomie d’un produit ne peut pas être efficace si de nouvelles fonctionnalités sont définies « à la petite semaine » pour alimenter les itérations à venir. Il est donc important de maintenir des phases de conception suffisamment longues pour permettre un réel mûrissement du besoin et éviter une réflexion basée uniquement sur les réactions face à ce qui a été développé, qui peuvent entrainer beaucoup de retravail.
La collaboration et l’interaction entre SSII et et le client peut être difficile. Etant donné, la qualité informelle de la plupart des échanges, SSII comme le client pourront s’incriminer mutuellement en cas de retards, de difficultés de recettes, de manquements aux obligations de compétence, d’alerte …
Le client aura bien du mal à se prévaloir des obligations de résultats mises à la charge de la SSII. Le client peut se voir demander réparation du préjudice que la SSII pourrait prétendre supporter : équipes mobilisées à ne rien faire ou pour se substituer aux carences du client …
Ces méthodes sont basées sur un fonctionnement collaboratif ce qui remet en cause le mode d’organisation hiérarchique. Ce bouleversement d’organisation est généralement très difficile à mettre en place dans des sociétés où l’attachement à la structure hiérarchique est fort. La résistance au changement en sera exacerbée. De plus, l’implication de la direction est nécessaire à l’agile et la collaboration avec le client est essentielle au bon déroulement du projet.
Par ailleurs, l’agilité fonctionne sur la motivation des ressources humaines. Si le projet est mal appréhendé par les utilisateurs, la résistance au changement sera forte et le mode d’organisation agile sera dur ou plus long à mettre en place.
La contractualisation d’un projet Agile n’est pas la partie la plus facile étant donné que le périmètre est par définition variable. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Cela ne veut pas dire qu’il n’existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d’arrêter le contrat à la fin de chaque itération est assez intéressant. Ainsi que le principe de troc d’exigence : réalisation d’une exigence imprévue en échange du retrait d’une autre moins importante, de priorité faible et de même coût.
Bibliographie:
http://www.dsi.cnrs.fr/methodes/gestion-projet/methodologie/bi-methodes-agiles.pdf
http://blog.beule.fr/contenus/2012/04/Agilite-vs-Cycle-en-V.pdf
www.agiliste.fr