Les approches « traditionnelles » de la gestion de projet attendent du client, en amont du projet, une expression détaillée de son besoin. Cette approche laisse peu de place au changement. C’est tout le contraire de l’agilité.
La réalisation du projet dure ensuite le temps qu’il faut. Enfin, rendez-vous est repris avec le client pour 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. #frictions
En définitive, un nombre certain de projets se terminent dans la douleur (surtout dans le cadre d’un contrat au forfait classique). Au risque de compromettre la relation client-prestataire.
Enfin, il n’est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l’usage. Et d’autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.
Partant de ce constat, 17 experts du développement d’applications informatiques ont rédigé le Manifeste pour le développement Agile de logiciels. En découlent plusieurs méthodes dites agiles. Ces experts estimaient notamment que le traditionnel cycle de développement en cascade ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide.
On pourrait résumer rapidement le manifeste sur l’agilité par les phrases suivantes :
L’approche Agile propose au contraire de réduire considérablement – voire complètement – cet effet tunnel. En :
Cette méthode considère que le besoin ne peut être figé. Elle propose au contraire de s’adapter aux changements de ce dernier. Mais pas sans un minimum de règles !
Les méthodes agiles postulent que spécifier et planifier dans les détails l’intégralité d’un produit avant de le développer (approche prédictive) est contre-productif. Prenons l’exemple.
Cela revient à planifier dans les détails un trajet « Paris – Narbonne » en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l’heure de passage associée, chaque rue empruntée dans les agglomérations, litres d’essence consommés, kilomètres parcourus, etc.
Les imprévus ne manqueront pas d’arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes.
Combien de temps aurez vous passé à planifier cet itinéraire ? Comment réagirez vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ?
L’idée consiste à se fixer un premier objectif à court terme (une grande ville par exemple). Puis de se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite, jusqu’à atteindre la destination finale. On parle donc d’une approche empirique.
Dans le cadre d’un projet de développement logiciel, le client élabore d’abord sa vision du produit à réaliser. Et liste les fonctionnalités ou exigences de ce dernier.
Ensuite, il soumet cette liste à l’équipe de développement, communique directement avec elle. L’équipe estime le coût de chaque élément de la liste. C’est ce qu’on appelle le Product Backlog.
Puis, l’équipe sélectionne une portion des exigences à réaliser dans une portion de temps courte appelée itération ou sprint.
Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c’est nécessaire, de développement et de test.
A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l’alignement sur le besoin !
L’utilisateur final quant à lui peut – déjà – se projeter dans l’usage du produit. Il peut émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clé.
Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur dans le sens où le client fait partie de l’équipe.
Les risques quant à eux sont levés très tôt.
On peut se faire une idée approximative du budget global à partir du Product Backlog. Néanmoins, avec l’agilité, on peut avoir 2 approches budgétaires :
Si le Product Owner a priorisé avec soin son besoin, il peut saisir l’opportunité 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é, grâce à l’agilité, de changer en cours de route la priorité des fonctionnalités qui n’ont pas encore été développées (prévues pour les itérations futures).
Afin de retarder une fonctionnalité dont le besoin n’est pas mûr, on peut ajouter une nouvelle fonctionnalité cruciale. En échange du retrait d’une autre (respectant ainsi budget et délais), etc.
Cette souplesse ainsi offerte par l’agilité est un véritable atout pour le client.
Les phrases suivantes sont fausses !
Sur un projet agile, il n’y a pas de spécifications, de plan, de processus, d’outil et même pas de contrat. »
Un projet Agile ne fonctionne que sur des projets de développement web, qu’avec une dizaine de personnes maximum, qu’avec des super développeurs. »
Sur un projet en agilité, le client change d’avis tout le temps et on tourne en rond à faire et défaire des choses.
MVP ou Minimum Viable Product. Un MVP (ou Minimum Viable Product) est la plus petite chose que vous pouvez construire, qui délivre de la valeur client (et qui, comme bonus, capture une partie de cette valeur en retour). Le but d’un MVP est d’apprendre, valider ou invalider […]
SCRUM EST CONSIDÉRÉ COMME UN CADRE OU « FRAMEWORK » POUR RÉALISER UN PROJET. CE CADRE EST CONSTITUÉ D’UNE DÉFINITION DES RÔLES, DE RÉUNIONS ET D’INCRÉMENTS ET VOUS PERMET DE PRODUIRE VOTRE APPLICATION DE FAÇON ITÉRATIVE. Les 4 rôles Scrum • Le […]
105 av.de la
République,
59110 La Madeleine
99 A bd C. Descat
59200 Tourcoing
