La méthode Agile - Optimisation de la relation "client / fournisseur"

Le principe de base des méthodes « Agile » est qu’il est contre-productif qu’avant de développer un produit, il faille le planifier et en spécifier les moindres détails. En effet, prévoir tous les aspects de la production entraîne dans la plupart des cas frustrations et pertes de temps car les aléas surviennent fréquemment. C’est cette approche prédictive et séquentielle de type waterfall ou cycle en V que les tenants des méthodes « Agile » veulent casser. Ainsi, au lieu de fixer les objectifs lointains, le mieux serait de procéder par étapes c’est-à-dire fixer des objectifs à court terme et commencer le développement sans perdre de temps. Chaque fois que cet objectif est atteint, on passe au prochain et ainsi de suite jusqu’à atteindre le but ultime. Au niveau d’un développement de logiciel, c’est le client qui transmet à l’équipe de développeurs sa vision du produit avec la liste des fonctionnalités qu’aurait ce produit. Il communique ainsi directement avec l’équipe et ensemble ils estiment le coût de chaque fonctionnalité pour aboutir à une idée approximative du budget final. De ce fait, on raisonne plus « produit » que « projet », d’où l’utilisation du terme « gestion de produit » au lieu de « gestion de projet ».

Ces méthodes « Agile » se sont beaucoup développées et on a pu en recenser une dizaine de variantes jusqu’au début des années 2000. Conscientes qu’une certaine uniformisation était devenue nécessaire, 17 grandes figures du développement logiciel s’étaient réunies aux Etats-Unis en 2001 pour déterminer les critères communs et les principes fondamentaux de ce qui allait devenir un « Manifeste Agile ». D’après ce manifesto, les méthodes « Agile » demandent une plus grande implication du client et permettent une meilleure réactivité des développeurs face à ses demandes. Ce manifeste prône 4 valeurs fondamentales inhérentes aux méthodes « Agile » : l’équipe, l’application, la collaboration et l’acceptation du changement. De ces valeurs découlent 12 principes généraux qui se basent essentiellement sur une relation privilégiée entre le client et les développeurs. La priorité est ainsi donnée à la satisfaction du client et pour y arriver, une implication totale de l’équipe est requise. Cette équipe doit être capable de réagir très vite face aux éventuels changements requis par le client ou aux modifications de la méthode de travail face à des obstacles imprévus. Elle doit également être capable de se remettre en cause et de rechercher perpétuellement à évoluer.

La première étape consiste à effectuer une première planification de l’itération ou Sprint dans le jargon des développeurs. Cette réunion fera ressortir les éléments prioritaires de la liste des exigences fonctionnelles du produit. Chaque exigence représente une user storie (US) ou "histoire utilisateur". Une US doit être rédigée dans un bon français et décrit e fonctionnement ainsi que le parcours de l'utilisateur de la fonctionnalité. Elle doit également contenir les cas de tests ainsi que les critères de validation de la fonctionnalité développée.

En accord avec le client, aussi appelé Product Owner, les premières livraisons devraient être effectuées à la fin de cette itération (une itération à une durée d'environ 2 à 3 semaines suivant le nombre d'US présentent dans le backlog). Le backlog est l'ensemble des US à développer durant l'itération en cours.

Une autre réunion appelée Revue de Sprint est organisée à la fin de chaque Sprint durant laquelle les développeurs présentent au client les fonctionnalités développées. Ce dernier pourra ainsi tout de suite donner son feedback, ce qui présente l’avantage de gagner beaucoup de temps et d’ajuster les fonctionnalités ou les méthodes de travail le cas échéant.

Vient ensuite une rétrospective de Sprint qui permet à tous les acteurs d’améliorer des choses et de s’améliorer également. Une autre particularité de la méthode « Agile » est la réalisation de mêlées quotidiennes qui permettent à l’équipe de développeurs de synchroniser leur travail. Appelée aussi Stand Up meeting, cette réunion qui ne dure pas plus de 15 minutes permet à chacun de déterminer ce qu’ils ont réalisé depuis la dernière mêlée, de ce qu’ils auront à terminer avant la prochaine Stand Up meeting et d’identifier les obstacles qui pourraient les bloquer. En effet, les trois questions "phares" du scrum master sont :

De nombreux outils d’aide à la gestion d’une équipe « Agile » ont fait leur apparition ces dernières années. On peut en citer pêle-mêle Agilefant, IceScrum, Agilo, eXPlainPMT ou encore XPlanner. D’autres sont apparus dernièrement comme le JIRA Agile qui a l’avantage d’être facilement utilisable même pour les débutants. Il permet d’élaborer des tableaux de tâches, de créer et d’estimer les user stories (US), d’identifier l’engagement et la vélocité de l’équipe ou encore de créer divers rapports sur l’état d’avancement des projets. En outre, un outil comme PMTool offre un large choix de rapports dans une interface simple mais très complète. Ainsi, les développeurs tout comme les chefs de projet (Scrum master) dispose d'une interface simple pour saisir leur feuille de temps et rendre compte de leurs activités. Un tableau de bord personnalisable est également disponible pour permettre à l’utilisateur d’avoir sous ses yeux les principaux indicateurs pour le suivi de son projet/développement tout en prenant en compte l'itération en cours. Les questions/incidents pourront enfin être gérés de manière très aisé car cette action est centralisée et se fait en un seul clic grâce à un menu très discret qui s'affiche partout (quel que soit la rubrique en cours de consultation).