La méthode Agile est une méthode de gestion de projet relativement moderne puisqu’elle a fait ses débuts en 2001. Elle est organisée d’une manière fondamentalement différente de la méthode dite du cycle en V que nous avons tous apprise à l’école. Elle priorise le besoin réel du client aux éléments contractuels définis au tout début du projet. Elle est parfaitement adaptée pour gérer les changements de dernière minute. Or, dans tous les projets, il y a toujours des changements de dernière minute. Comment est organisée cette méthode ? En quoi est-elle plus efficace que le cycle en V ? Analyse.

Le backlog

La méthode Agile prend sa source du backlog et s’organise en sprints.

Le backlog contient la liste des histoires qui doivent être réalisées pendant tout le projet. La première itération du projet consiste donc à constituer ce backlog. Celui-ci pourra être enrichi tout au long de la vie du projet.

Le backlog est géré par le responsable produit, qu’on appelle product owner dans la méthode. C’est en général la même personne que le donneur d’ordres, c’est-à-dire le client final. Il inscrit dans son backlog les histoires qui ont un intérêt pour son projet. Il sert également de point d’entrée pour toutes les demandes relatives à l’évolution de ce projet.

Les épics et les histoires

Un backlog est constitué d’épics et d’histoires. Les épics définissent une fonctionnalité qui sera découpée en histoires. Une histoire correspond à une phrase descriptive du type « En tant que …, je dois … ». Par exemple : « En tant qu’utilisateur non connecté, je peux me connecter à partir de l’écran de connexion après avoir saisi mon identifiant et mon mot de passe valide ». L’ensemble des évolutions nécessaires à l’application doivent être décrites ainsi. Les évolutions sont fonctionnelles et pas techniques. Ainsi, une histoire du type « En tant que développeur, je m’assure que le service de connexion fonctionne pour être mis à disposition de l’application » est à proscrire. L’histoire décrit un fonctionnement qui est suffisamment petit pour être réalisé dans la durée du sprint. Elle doit également être indépendante des autres histoires. Ainsi, lors du démarrage d’un sprint, on pourra choisir une histoire ou une autre, selon les priorités du moment, sans porter atteinte aux autres développements. La réalisation des histoires doit aboutir à un produit fini qui peut immédiatement être mis en production.

Les tâches

Une fois les histoires sélectionnées au début du sprint, elles sont découpées en tâches techniques qui devront toutes être réalisées avant la fin du sprint, tests compris, afin que l’histoire puisse être validée et potentiellement mise immédiatement en production.

Le sprint

Les histoires sont réalisées dans la durée d’un sprint. Le sprint correspond à l’unité de développement. Il peut être d’une à cinq semaines, les deux durées les plus souvent plébiscitées étant deux et quatre semaines. Choisir la durée de son sprint est une histoire de goûts mais elle est primordiale pour l’organisation du projet. Cette durée est en effet invariable, même si les développements prennent du retard ou si l’on est en période d’absentéisme important due aux vacances. Si vous envisagez de faire une mise en production toutes les six semaines, il est d’usage de choisir des sprints de deux semaines. Chaque mise en production sera alors constituée de trois sprints. C’est le rythme qui a été choisi par Google pour le développement du navigateur Chrome.

Le fonctionnement du sprint est très codifié. Il est dirigé par le scrum master qui est choisi parmi les développeurs. Ce dernier peut changer d’un sprint à l’autre. Il est responsable du bon déroulement du sprint et de toutes ses étapes.

La réunion de planification

Si le sprint commence un lundi, ce qui est souvent le cas, une réunion de planification du sprint d’une heure idéalement, deux heures au maximum, est organisée le vendredi après-midi. Le scrum master et le product owner vérifient ensemble les histoires qui sont mûres pour entrer dans le sprint. Une histoire est mûre si les pré-requis à sa bonne réalisation sont disponibles : expressions de besoins, écrans, chiffrages et tous les éléments nécessaires à la bonne réalisation de l’histoire.

Parmi les histoires candidates, le product owner choisit celles qu’il veut voir réaliser en priorité. Il peut choisir toutes les histoires qu’il souhaite dans la limite de la vélocité disponible de l’équipe. Il est préférable de choisir pour un sprint un ensemble d’histoires qui correspondent à une même thématique. Les développeurs pourront ainsi plus facilement passer d’une histoire à l’autre durant le sprint.

La vélocité est la capacité à faire des équipes. Elle s’affine au fur et à mesure que l’équipe mûrit. On se rend compte qu’avec l’expérience, la vélocité tend à devenir constante à effectif constant. La vélocité n’est pour autant pas constante d’un sprint à l’autre puisqu’elle doit tenir compte des disponibilités des équipes, notamment des départs en congés.

Une fois les histoires sélectionnées, le sprint peut commencer.

Le scrum

Le scrum est le rituel le plus connu de la méthode Agile car il a lieu chaque jour. Certains prétendent être agiles parce qu’ils pratiquent le scrum. Le scrum n’est qu’une des composantes de la méthode Agile.

C’est une réunion qui a lieu chaque jour, à la même heure, en général le matin à la première heure. Il réunit l’ensemble des développeurs et le product owner. Chaque développeur s’exprime tour à tour sur son avancement de la veille, ce qu’il planifie de faire aujourd’hui, et signale les difficultés qu’il rencontre. Un de ses collègues peut alors se proposer de lui venir en aide.

Il est vital que cette réunion ne dure que de dix à quinze minutes. Le temps de parole de chacun est donc divisé en conséquence. Exceptionnellement, un des membres d’équipes peut avoir un temps de parole supérieur, mais il ne faut pas que cela se généralise. Le scrum master ne doit pas hésiter à couper la parole aux trop bavards. Le dépassement de cette durée est préjudiciable à la méthode et au projet. Au-delà de quinze minutes, les membres de l’équipe commencent à s’ennuyer et vont déconsidérer l’intérêt du scrum. La fois suivante, ils n’auront qu’une oreille attentive. La fois d’après, ils n’écouteront plus ou ne participeront même plus à la réunion. Si un sujet s’éternise, il n’intéresse tout au plus que deux ou trois personnes de l’équipe. Elles développeront ensemble ce sujet après le scrum.

Le scrum n’est pas le lieu pour faire une réunion technique. Il ne sert qu’à faire un bilan d’étape du sprint. C’est par contre le moment idéal pour mettre à jour le reste à faire de chaque histoire et ainsi identifier au plus tôt si l’on prend du retard ou pas.

La démo

Il est important d’organiser une démo à la fin du sprint. Elle a lieu en général le dernier jeudi après-midi ou vendredi matin du sprint, toujours à heure fixe. Sont invités toutes les personnes intéressées par découvrir les dernières réalisations. Une histoire étant toujours un produit fini, il y a toujours quelque chose à montrer à l’occasion de cette démo.

La revue de fin de sprint

Autre élément primordial du sprint, la revue de fin de sprint est une réunion d’une demi-heure, organisée avec l’ensemble des développeurs et le product owner, le dernier jour du sprint. Le but est d’identifier ce qui s’est bien passé et ce qui s’est mal passé durant le sprint, non pas pour pointer du doigt celui qui a fauté, mais pour s’améliorer lors du prochain sprint. D’ailleurs, il n’y a pas de fautif car c’est l’ensemble de l’équipe qui prend la responsabilité de la bonne réalisation du sprint. Si faute il y a, elle incombe à toute l’équipe, sans distinction. Un focus tout particulier est donné aux histoires qui n’ont pu être finies à temps, s’il y en a. Pour rappel, la durée d’un sprint ne change pas. C’est donc son contenu qui peut potentiellement changer. En fonction de la difficulté rencontrée, l’histoire non finie sera inscrite pour le prochain sprint ou réintégrée dans le backlog pour une planification ultérieure. Les axes d’amélioration sont suggérés durant cette réunion. Puis un vote est effectué pour déterminer les trois axes les plus importants. Ce sont ceux-là qui seront améliorés pour le prochain sprint.

Cette revue de fin de sprint peut être organisée juste après la démo ou juste avant la réunion de planification du nouveau sprint pour profiter de la présence de tout le monde.

La notion de fini

La notion de fini est une notion très importante. Le chiffrage d’une histoire doit intégrer tous les travaux nécessaires jusqu’à ce qu’elle soit réellement finie. Ce n’est pas uniquement son développement, mais également les tests associés et son intégration au produit complet.

Une histoire finie est une histoire développée, testée et intégrée !

Le planning poker

Le chiffrage des histoires est réalisé lors du planning poker, une réunion où tous les développeurs et le product owner se réunissent en milieu de sprint ou quelques jours avant la fin du sprint. Chaque développeur dispose de cartes pour déterminer le temps de développement de chaque histoire, ainsi que les temps nécessaires pour les tests et l’intégration à l’application complète. Si les chiffrages de chacun des développeurs convergent, ce sera le coût de l’histoire. S’il y a de fortes divergences, celui qui a fait le plus petit chiffrage et celui qui a fait le plus grand chiffrage prennent la parole et développent leurs arguments. Les donneurs d’ordre sont là pour préciser leur besoin et choisir entre la solution la moins chère et celle qui est plus chère. Le vote peut alors reprendre jusqu’à ce que l’on arrive à un chiffrage à peu près convergent. Le chiffrage qui est finalement retenu est celui qui est le plus gros parmi les votants.

Plutôt que d’estimer en jour/hommes, il est préférable de faire un chiffrage en points. L’unité du point dépend des habitudes des équipes, mais cela correspond plus ou moins à un facteur de jours/homme. La vélocité d’une équipe est exprimée en points et varie en fonction des congés de ses membres ou des changements de membres. La vélocité est la capacité en points de développement de l’équipe pour un sprint.

La vélocité maximale de l’équipe est affectée à toutes les histoires dont les éléments sont insuffisants pour effectuer un chiffrage correct.

Des cartes de planning poker sont en vente sur http://www.crisp.se/planningpoker

La taille de l’équipe

Une équipe Agile ne peut fonctionner que si elle est à taille humaine. Elle est composée de trois à dix personnes au maximum, idéalement de quatre à sept. Si votre équipe est plus petite, l’intérêt de la méthode est réduit. Si votre équipe est plus importante, il est alors nécessaire de découper votre équipe en petites équipes de quatre à sept personnes. Chaque équipe aura son propre sprint et ses propres objectifs. Les membres des équipes pourront passer d’une équipe à l’autre à chaque changement de sprint. Si l’équipe représente plus de cinquante personnes, l’organisation devra être pyramidale. Les scrum masters de chaque équipe se réuniront dans un autre scrum de synchronisation des équipes. Hormis ce cas, chaque membre d’équipe participe chaque jour à un et un seul scrum. Les réunions de planification, les scrums, les démos et les revues de fin de sprint sont indépendants pour chaque équipe.

Faut-il faire des sprints courts ou longs ?

Une semaine, deux semaines, quatre semaines, c’est vraiment un choix qui dépend des projets et des personnes.

Un rythme de quatre semaines se rapproche plus de la durée d’un mois. D’ailleurs, certains ajustent leurs sprints à quatre ou cinq semaines en fonction des mois pour se caler exactement avec la durée d’un mois. Ils dérogent légèrement à la méthode, mais conservent la notion de semaine complète.

Un rythme de deux semaines, voire d’une semaine, limite les risques d’erreur. La durée étant plus courte, moins d’histoires sont réalisées et donc moins de complexité.

Il est interdit d’intégrer de nouvelles histoires urgentes durant la vie du sprint. Elles ne pourront être retenues que pour le sprint suivant. Un sprint plus court permet donc d’être plus réactif.

Pour gérer les urgences, il existe toutefois une autre technique : ne pas charger complètement le sprint. Cela permet, en fin de sprint, de rajouter les petites histoires urgentes qui font toujours plaisir au client. C’est justement cette flexibilité qui fait l’adhésion à cette méthode.

Post-it ou pas post-it ?

Les équipes qui utilisent la méthode Agile sont reconnaissables par l’utilisation massive de post-it collés au mur. Est-ce indispensable ou pas ? Tout dépend si vous êtes équipés d’un outil performant ou pas pour faire le suivi de projet. Si vous n’avez qu’Excel, alors les Post-it sont indispensables. Si vous avez un bon outil ou que vos équipes ne sont pas réunies au même endroit, alors vous pourrez vous en passer. C’est la simplicité de l’outil qui est à votre disposition qui déterminera votre choix. Il est beaucoup plus simple de mettre à jour un Post-it, mais le Post-it ne permet pas de rendre graphiquement l’avancement de l’équipe.

Quels outils ?

Excel est l’outil à bannir définitivement. Excel n’a jamais été un outil de gestion de projet et ne le sera jamais, bien que tous les chefs de projet s’en servent abondamment. Si vous n’avez pas d’autre choix, alors adoptez les Post-it. C’est plus efficace !

Se lancer dans le développement d’une application spécifique en interne est là encore une mauvaise piste. J’en ai fait l’expérience dans une de mes précédentes missions où j’étais partie intégrante de l’équipe d’expression de besoins et béta testeur. Cela a surtout abouti à une série de discussions stériles où chacun militait pour ses propres besoins, sans se soucier de la méthode Agile elle-même. Le résultat n’a pas été à la hauteur du nombre de réunions réalisées.

Dans le livre « Scrum : Le guide pratique de la méthode agile la plus populaire », l’auteur Claude Aubry préconise l’utilisation d’Ice Scrum qui est gratuit. Ne l’ayant pas testé, je ne me limiterai donc qu’à le citer.

Jira est un outil connu pour la gestion des anomalies. Le plugin Greenhoper ajoute à Jira le nécessaire à la pratique Agile : backlog, épics, histoires, sprints, tâches, tout y est. Le déplacement des histoires se fait par un simple glissé-déplacer, ce qui est très ergonomique. Un autre outil intégré, Confluence, est un wiki permettant, comme tout wiki, de créer les pages que l’on veut. Il est possible d’intégrer dans ces pages des requêtes automatiques sur Jira. La gestion de projet en est simplifiée. De plus, il est possible d’exporter les pages en pdf en un clic afin d’envoyer les rapports par E-mail. Tout n’est certes pas parfait, mais ces outils sont très pratiques au quotidien.

La méthode Agile peut-elle s’appliquer à tous les projets ?

En un mot : oui ! Et pas uniquement aux projets informatiques. Tout projet qui consiste à réaliser quelque chose peut gagner à utiliser la méthode Agile. Seules les activités récurrentes, comme gérer un service client par téléphone, ne sont pas concernées.

Qu’en est-il des forfaits ? Un forfait consiste à signer à l’avance un contrat pour réaliser un besoin précis. Le principe du forfait est qu’il est impossible de faire autre chose que ce que le contrat précise. L’expérience montre que, bien que les entreprises aiment signer des forfaits, elles n’apprécient pas leur déroulement, justement parce qu’il n’est pas possible de modifier la donne en cours de forfait. C’est ainsi qu’en général, un forfait est doté d’une contingence qui est un stock de jours facturables à l’usage pour gérer les sujets qui ne sont pas inclus dans le forfait. Et quand cette contingence est entièrement consommée, le client demande lui-même de modifier les modalités du forfait pour supprimer certains sujets au profit d’autres, ou, s’il a le budget nécessaire, de signer un avenant au contrat. Même dans le cadre d’un forfait, la méthode Agile est donc profitable.

Le consommé

Le consommé n’est pas le fort de la méthode Agile. En effet, la méthode ne s’intéresse qu’à ce qu’il reste à faire, pas à ce qui est fait. S’il est impératif de faire le suivi du consommé, ceci doit donc être réalisé hors du cadre de la méthode Agile. Libre au chef de projet de s’organiser en conséquence.

En quoi la méthode Agile est-elle meilleure que le cycle en V ?

Il est humainement impossible de penser à tout avant de commencer le moindre développement. C’est pourtant ce qu’exige le cycle en V. La phase de conception ne peut démarrer qu’une fois la phase de spécifications terminée, et le développement, une fois que les deux premières phases ont abouti. Il est interdit de faire chevaucher deux phases successives.

Avec la méthode Agile, à chaque nouveau sprint, on recommence une nouvelle phase de spécifications, de conception, de développement, d’intégration et de tests. Le nombre d’éléments traités étant plus réduit et la réalisation étant immédiate, le choix de conception est fait au plus près du besoin, ce qui est plus efficace. Revers de la médaille, la documentation est moins touffue, mais malgré tout plus fidèle à la réalité du terrain.

Cela ne veut pas pour autant dire que la méthode Agile fait travailler à courte vue. La méthode ne fait pas l’impasse de la phase d’architecture générale de l’application. C’est d’ailleurs l’objet du premier sprint du projet : définir cette architecture générale et les premières épics et histoires qui serviront de fil rouge à l’ensemble des sprints suivants.

Dans le cadre d’un projet de refonte du système d’information, il est nécessaire de faire un sprint off, c’est-à-dire un sprint qui ne contiendra aucun développement. Ce sprint permet de prendre du recul et définir la nouvelle architecture qui sera mise en place. Sans architecture saine, aucun projet ne peut fonctionner. À l’issue de ce sprint, l’architecture sera présentée au titre de la démo.

L’adhésion à la méthode Agile

L’adhésion à la méthode Agile est probablement la tâche la plus complexe à réaliser.

Il est nécessaire d’expliquer clairement les tenants et les aboutissants aux développeurs qui appliqueront cette méthode. Sans explication, la méthode sera perçue comme une méthode de flicage, alors que le fond de la méthode, c’est l’appropriation des développeurs à l’organisation du projet. Des séances de présentation sont donc impératives avant de commencer à appliquer cette méthode.

Autre difficulté : faire comprendre à une entreprise qui est habituée depuis tant d’années à travailler en cycle en V l’intérêt d’une méthode Agile. En effet, ces habitués sont en attente au plus tôt d’un document de spécifications que la méthode est bien incapable de fournir à la date demandée.

Il est donc là encore nécessaire d’expliquer la méthode et ses intérêts. Les personnes qui doivent adhérer en premier à cette méthode sont justement celles qui ne l’utiliseront pas : la hiérarchie. Ce n’est pas une mince affaire et est un projet en soi.

À défaut, il est toujours possible d’appliquer partiellement cette méthode, un exercice qui aura ses limites. Ensuite, ce n’est qu’une question de compromis…

Franck Beulé
Chef de projet Agile, expert des technologies de l’Internet et en ergonomie du Web