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.
Le manifeste agile
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 :
Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuel
L’adaptation au changement plus que le suivi d’un plan
Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.
Une gestion de produit et non de projet
L’approche Agile propose au contraire de réduire considérablement – voire complètement – cet effettunnel. En :
Donnant davantage de visibilité
Impliquant le client, du début à la fin du projet
Adoptant un processus itératif et incrémental.
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 ?
Dans les faits, ça se passe comment?
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.
Et d’un point de vue budget?
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 :
On sait que ce qu’on va avoir correspondra à 200% au besoin. Mais on ne sait pas réellement combien cela va coûter, ni combien de temps cela va prendre de le produire.
On sait combien cela va coûter et combien de temps cela va prendre. Mais on ne sait pas ce qu’on aura réellement au final.
Quels sont les bénéfices à pratiquer l’agilité?
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.
Attention aux idées reçues !
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.
D'autres articles dans la même catégorie : Methodologie
Nous utilisons des cookies sur notre site Web pour vous offrir l'expérience la plus pertinente en mémorisant vos préférences et en répétant vos visites. En cliquant sur « Tout accepter », vous consentez à l'utilisation de TOUS les cookies. Cependant, vous pouvez visiter « Paramètres des cookies » pour fournir un consentement contrôlé.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Durée
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.