Un mot sur les méthodes prédictives

Ce chapitre traite des méthodes agiles en gestion de projet. Ces méthodes agiles sont d’apparition récente. Elles se sont positionnées sinon en opposition, du moins en complément de méthodes plus anciennes que l’on appellera « prédictives ». Avant d’aller plus loin il est essentiel de bien comprendre la différence entre prédictif et agile. La meilleure façon d’éclairer ce point est de prendre un exemple de la vie courante : les vacances. Supposons que vous projetiez pour l’été prochain un périple en famille et en voiture. Ce voyage vous fera traverser plusieurs pays d’Europe. Mettons qu’au départ de France vous souhaitez parcourir l’Espagne, le Portugal et retour. Votre intention est de découvrir les paysages et les quelques villes de ces deux pays. La famille s’est décidée pour un circuit au départ de Toulouse et passant par Pampelune, Valladolid, Porto, Lisbonne, Séville, Valence, Barcelone et retour à Toulouse. Ceci en trois semaines. Je vous propose d’illustrer à partir de cet exemple les deux approches : prédictive et agile.
– Une façon de faire est de programmer ce périple de façon précise. Vous identifiez tous les lieux à visiter : Parcs nationaux, monuments historiques, musées… Vous décidez du nombre de journées passées dans chaque ville étape. Vous choisissez les hôtels et réservez les nuitées. Vous repérez les meilleurs restaurants et réservez une table. Vous commandez également vos billets pour les visites de lieux touristiques. Eh bien votre démarche est de type « prédictif » : Tout est organisé avant le départ, il ne restera plus qu’à gérer les inévitables aléas.
– Maintenant, organisons le projet en agile. Notez que cela ne change rien à notre objectif : c’est toujours trois semaines et le parcours reste le même. Simplement vous voulez décider au quotidien des lieux à visiter. Vous voulez aussi déterminer la durée passée dans chaque ville en fonction de votre bon plaisir. Donc pas question de réserver les hôtels avant de partir, ce sera au jour le jour. Vous allez néanmoins fixer une règle minimale : diviser votre périple en trois séquences (en agile on dirait en trois sprints). Le septième jour vous serez à Porto, le quatorzième à Séville et le vingt et unième à Toulouse.
Quel est le meilleur plan : prédictif ou agile ? dans le cas de vos vacances impossible de donner une réponse unique, c’est affaire de goûts. En mode prédictif c’est trois semaines sans aucun souci d’organisation. Par contre si un lieu vous plaît pas, pas question d’y rester plus que prévu. En mode agile plus de liberté mais la nécessité de trouver chaque soir un hôtel où passer la nuit.
Dans les projets du domaine professionnel le mode prédictif consiste, tout comme dans notre exemple à tout organisez avant le lancement du projet. A l’inverse en mode agile on s’autorise une certaine dose d’improvisation.
Notons que pour les projets du domaine professionnel le choix prédictif/agile dépend non pas du tempérament du chef de projet mais de la nature du projet.

Historique et raison d’être des méthodes agiles

Les projets informatiques ont longtemps été conduits comme les autre, sur la base du cycle de vie linéaire des méthodes classiques (que l’on préfèrera appelé « prédictives » dans ce chapitre). A l’issue de ce processus, d’une durée rarement maitrisée, l’utilisateur découvrait un résultat plus ou moins conforme à ses attentes (souvent moins !). Il s’agit là de l’effet tunnel, très connu en management de projets.
Au début des années 1980 sont apparues dans le monde du développement de logiciels de nouvelles méthodes de management de projet destinées à supprimer cet effet tunnel, à corriger les dérives de délai et surtout à livrer un produit de nature à satisfaire les utilisateurs. Aujourd’hui regroupées sous l’intitulé de « méthodes agiles » elles ont en commun de mettre l’utilisateur au centre de la démarche, de privilégier le respect du délai et de fonctionner suivant un cycle …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Prédictif ou agile ?

Opposer méthodes agiles et méthodes prédictives serait une grave erreur. Le choix de la méthode dépend tout simplement de la typologie et du contexte du projet. Dans beaucoup de projet les exigences doivent être figées en totalité avant tout début des travaux. Aucune place ne peut être laissée à l’improvisation. C’est notamment le cas dans le batiment, les travaux publics, les projets d’infrastructures industrielles. Par ailleurs dans ces métiers, les solutions techniques pouvant être mises en oeuvre sont connues et éprouvées. Deux raisons pour lesquelles ces projets peuvent et doivent être gérés en mode prédictif. Pour une autre famille de projets il est à la fois très difficile de définir la totalité des exigences et d’estimer l’effort nécessaire pour réaliser chacune de ces exigences. On parle ici des projets informatiques mais aussi des projets d’innovation. Dans cette configuration les méthodes agiles ont toute leur place et donnent de meilleurs résultat que les méthodes prédictives.
Travailler en agile ne veut pas dire que l’on s’engage dans un projet « la fleur au fusil » sans exigences aucunes et sans savoir si on a la moindre chance d’aboutir. La zone rouge du schéma ci-contre illustre cette situation plus fréquente qu’on ne le pense.

Prédictif, agile, ou les deux à la fois ?

Prédictif et agile peuvent parfaitement cohabiter dans un même projet. Si vous avez parcouru le chapitre « structuration », vous avez compris qu’un projet se décompose le plus souvent en « lots de travaux », et que le contenu des différents lots est toujours de nature différente.
Le schéma de ce paragraphe illustre cette réalité. Le cas proposé est un projet visant à mettre sur le marché un bracelet connecté destiné au marché de la puériculture. Le projet est divisé en deux processus : marketing et technique. Et chaque processus comprend plusieurs lots portant chacun le nom de son livrable ; par exemple le lot maquette et le lot présérie. Dans cet exemple certains lots (en jaune) sont pilotés en prédictif et d’autres (en vert) sont pilotés en agile. Comme on a vu plus haut ce sont plutôt les lots informatiques (Logiciel embarqué et application smartphone) qui sont pilotés en agile. Certains lots technologiques ne peuvent être pilotés qu’en prédictif, par exemple la fabrication de la présérie ou la réalisation des supports de communication. Par contre pour d’autres lots comme la conception et le maquettage, ils pourraient fort bien être conduits en agile.

Le manifeste agile

Les principes communs aux différentes méthodes dites « agiles » ont été mis sur le papier en février 2001, aux États-Unis. Dix-sept spécialistes du développement logiciel s’étaient réunis pour débattre de leurs méthodes respectives. Parmi eux se trouvaient l’inventeur du Wiki et créateur de l’extreme programming ainsi que le fondateurs de Scrum. La synthèse de cette réunion est connue sous le nom de Manifeste agile. Le Manifeste agile est constitué de quatre valeurs et de 12 principes fondateurs.

Les 4 valeurs agiles

Préférer et favoriser :
1. Les individus et leurs interactions plus que les processus et les outils.
2. Du logiciel qui fonctionne plus qu’une documentation exhaustive.
3. La collaboration avec les clients plus que la négociation contractuelle.
4. L’adaptation au changement plus que le suivi d’un plan.

Les principes agiles

Le manifeste agile a établi une liste de 12 principes communs aux différentes méthodes, voici ces principes :

1. Priorité à la satisfaction du client
C’est le principe le plus important des méthodes agiles. Et pour savoir si le client est satisfait il faut l’impliquer dans le processus de développement,
2. Acceptation des changements
Dans les méthodes agiles la phase de définition du besoin est réduite au minimum. Le besoin se précise au cours du projet. Il est admis que le client fasse évoluer sa demande à tout moment. Chaque évolution est analysée, chiffrée, et priorisée.
3. Livraison précoce puis régulière de versions opérationnelles de l’application
Impliquer le client dans le processus de développement ne suffit pas, encore faut-il lui montrer très vite à quoi ressemblera son application. Il ne sait pas se prononcer sur du code informatique, par contre il verra très bien si telle fonctionnalité lui convient ou pas.
4. Coopération entre l’équipe de projet et les gens du métier
Ce devrait être un comportement normal quelle que soit la méthode utilisée, c’est encore plus vrai en agile.
5. Construction des projets autour de personnes motivées
Une équipe agile doit être motivée pour réussir. Cette motivation se construit notamment sur la stabilité de l’équipe afin que la confiance puisse s’installer.
6. Priorité au dialogue direct
Éviter les moyens de communication modernes mais impersonnels : mail ou plate-formes collaboratives. Préférer toujours les relations directes et verbales.
7. Mesure de l’avancement du projet en fonction de l’opérationnalité du produit
Il ne suffit pas de consommer des heures de travail pour progresser vers l’objectif. Plus que jamais la mesure de l’avancement doit se faire en fonction des livrables validés par le client.
8. Rythme constant et soutenable par tous les intervenants du projet
Inutile de surcharger l’équipe de développement en croyant …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous  Le schéma ci-contre met en lumière les profondes différences entre la gestion classique (dite aussi prédictive) et les méthodes agiles. Plus qu’une simple différence d’organisation il s’agit d’une façon nouvelle de penser les relations MOA-MOE. On passe clairement d’une logique de confrontation (méthodes classiques) à une logique de coopération (méthodes agiles). Par un effet de bascule assez habituel dans la vie des entreprises on revient à une époque où maître d’ouvrage et maître d’œuvre se parlaient d’égal à égal avec comme objectif commun le succès du projet.

Le « time boxing » des méthodes agiles

La particularité la plus marquante des méthodes agiles réside (paradoxalement) dans la rigidité du découpage du temps (d’où le nom de « time boxing »). A un premier niveau le projet est découpé en séquences de deux à trois semaines (notées « itérations » sur le schéma) et nommées « sprints » dans la méthode Scrum. L’équipe s’engage à livrer au client, à l’issue de chaque sprint, une ou plusieurs parties fonctionnelles du produit que le client va valider et qui font partie du système tel qu’il lui sera livré. A un niveau plus fin c’est quotidiennement, en début de journée, que l’équipe de projet va se réunir très brièvement (pas plus de 15 mn) pour faire le point du travail réalisé et des difficultés rencontrées la veille et pour distribuer le travail pour la journée qui commence. La contrainte de temps est prioritaire, de sorte que si le développement prend du retard, la décision pourra être de réduire le périmètre du projet plutôt que d’accorder un délai supplémentaire.

La nécessité d’une architecture modulaire

La contrainte de livrer très tôt des parties fonctionnelles du système peut amener à concevoir différemment la solution, sur un principe modulaire plutôt que monobloc. Le schéma ci-contre illustre cette différence. En haut l’application des méthodes classiques conduit à l’effet tunnel : Le produit s’élabore progressivement, le client ne verra le résultat qu’en toute fin du projet, et sera rarement satisfait ! En partie basse le processus agile. L’équipe montre très tôt des parties que le client peut valider ou pas. Ayant participé activement au processus il n’y a aucune raison qu’il ne soit pas satisfait du résultat final.

Voici une présentation sommaire des différentes méthodes agiles. Nous ne reprendrons pas pour chacune d’entre elles la totalité de ses caractéristiques mais seulement ce qui la différencie des autres méthodes agiles. Les liens à la fin de chaque paragraphe pointent vers des descriptions plus complètes.

RAD (Rapid Application Development)

A tout seigneur tout honneur, RAD est la première méthode de développement de logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des méthodes antérieures dites « en cascade ». Ce nouveau cycle qualifié d’itératif, d’incrémental et d’adaptatif, se retrouvera dans toutes les méthodes dites « agiles » publiées par la suite. Même s’il n’en est pas le seul inspirateur James Martin a le mérite d’avoir formalisé la méthode RAD et de l’avoir publiée en avril 1991.
RAD introduit des principes dont plusieurs feront florès par la suite :
– La « Timebox » et le « Timeboxing » constituent une innovation pour l’époque, qui consiste à fixer à l’avance une limite de durée à respecter absolument.
– Les « Focus de visibilité » sont des démonstrations de l’application en cours de développement.
– L' »Equipe SWAT » (Skilled With Advanced Tools ou en français « Qualifiée et pourvue d’outils avancés ») est une petite équipe (2 à 6 personnes) pour une meilleure réactivité et pour éviter les problèmes de communication.
– Le « GAR » (groupe d’animation et de rapport) a pour mission de faciliter les relations maitrise d’œuvre / maitrise d’ouvrage.
Pour le reste la méthode RAD est structurée de façon très classique en cinq phases : Initialisation, Cadrage, Design, Construction et Finalisation.

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur RAD :
La page Wikipedia sur RAD

XP (eXtreme Programming)

XP a été créée par Kent Beck entre 1996 et 1999, alors qu’il travaillait sur un projet pour Chrysler.
Voici quelques particularités de la méthode XP :
– Le coach XP (ce rôle correspond au Scrum Master dans la méthode SCRUM que nous présenterons un peu plus loin) est une sorte le leader de l’équipe de développeurs. C’est lui qui s’assure que la démarche XP est correctement implémentée, et que la méthode fonctionne comme il se doit dans le cadre du projet. Il fait en sorte que les embûches qui se dressent sur le passage de l’équipe soient éliminées.
– Dans XP les développeurs travaillent en binôme. C’est la notion de Pair programming. L’un écrit le code, l’autre regarde, propose, corrige et commente. Puis on change les rôles, et ainsi de suite. Les connaissances sont ainsi partagées, et les idées émanent plus facilement que dans d’autres types d’organisation. Par ailleurs grâce à cette mutualisation des connaissances l’absence de l’un des membres du binôme perturbe très peu l’avancement du projet.
– Autre principe de XP, la recherche de …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Crystal

Les méthodes agiles Crystal (car il s’agit d’une famille de méthodes) ont été créées au milieu des années 90 par Alistair Cockburn, un célèbre programmeur américain. Il a notamment participé à la rédaction du Manifeste Agile en 2001 et a publié plus d’une demi-douzaine de livres sur le développement agile. Pourquoi plusieurs méthodes ? Tout simplement parce qu’il y a des projets de différentes tailles et de nature différente, et que tous les organismes qui développent des projets ne se ressemblent pas. Crystal met l’accent sur les hommes, la compétence et la confiance plutôt que sur une méthodologie stricte.
Le plus populaire des méthodes Crystal est Crystal Clear, adaptée aux projets de petite taille. Néanmoins toutes les méthodes (Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond et Crystal Sapphire) fonctionnent sur les mêmes principes :
– Une équipe composée d’un facilitateur et de 2 à 7 développeurs
– Une grande salle dédiée équipée de tableau blanc et de paperboards. Ceci pour favoriser la communication osmotique : la communication orale et spontanée est le point fort de Crystal Clear. Tout le monde peut répondre à une question posée.
– La sécurité personnelle des membres de l’équipe. Ceci se concrétise par un environnement de travail sans perturbation. En pratique chaque développeur doit pouvoir coder deux heures d’affilée sans être dérangé. Pas de réunion intempestive, pas de téléphone. Jamais moins de deux journées à travailler sur le même projet.
– Un accès direct et rapide aux experts techniques et métier et aux utilisateurs.
– Un environnement technique performant, avec notamment les tests automatisés, le déploiement automatisé de la solution, la remontée automatique des anomalies, un outil de gestion de configuration…

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur Crystal :
Crystal sur le site wikipedia
Crystal sur le site de Thibaud Frichet
Crystal sur le site Nutcache

UP (Unified Process)

Autant les méthodes Crystal sont basées sur l’humain, autant UP et ses avatars sont basées sur une méthodologie stricte, à savoir la méthode UML et ses outils de modélisation : Diagramme des cas d’utilisation, Diagramme de séquence et Diagramme d’état. UP est malgré tout considérée comme une méthode agile car elle procède par itérations amenant progressivement au produit fini. Chaque itération est structurée comme un projet, en quatre phases successives : Etude préliminaire, Elaboration, Construction, Transition.
Les « avatars » de UP dont il est fait état plus haut sont essentiellement :
– RUP (pour Rational Unified Process) a été élaborée par Rational Software et plus tard par IBM. RUP est considérée comme un processus lourd.
– AUP (pour Agile Unified Process) est une version atténuée de UP mettant l’accent sur l’optimisation et l’efficacité sur le terrain plus que sur le modèle théorique.

Voici quelques liens qui vous permettrons d’en savoir un peu plus sur UP :
UP sur le site wikipedia
Un pdf d’Aurélien Tabart

DSDM (Dynamic Systems Development Method)

La méthode DSDM passe pour être une version anglo-saxonne de la méthode RAD.
Une originalité de DSDM est d’introduire quatre rôles :
– Le Visionnaire définit la … vision. Il donne la direction du projet à travers les objectifs métier.
– Le Sponsor ou « Product champion » est celui qui veut le produit et qui paie pour ça.
– L’Ambassadeur est le représentant des utilisateurs. Il prend les décisions sur le détail des exigences.
– Le Conseiller fournit de l’expertise métier à la demande de l’Ambassadeur.

FDD (Feature Driven Development)

FDD a été conçu par Jeff De Luca en 1997 pour répondre aux besoins spécifiques d’un projet de développement logiciel dans une grande banque de Singapour. Feature Driven Development se traduit en français par « Développement piloté par les fonctions »

APF (Adaptative Project Framework)

APF est un hybride des méthodes prédictives (ou classiques) auxquelles elle emprunte les outils de structuration comme la WBS ou le diagramme de Gantt et les méthodes agiles. La méthode a été créée par Robert K. Wysocki, expert de la gestion de projet et auteur de plusieurs ouvrages sur le sujet.

Voici un lien qui vous permettra d’en savoir plus sur APF :
APF sur le site Planzone

SCRUM

La méthode SCRUM jouit en France comme dans beaucoup d’autres pays d’une grande popularité. Raison pour laquelle cette méthode fait l’objet de la prochaine leçon.

Kanban

Le mot « Kanban » est très connu des spécialistes de la gestion de production (peu de chose à voir donc avec l’informatique). La méthode de gestion de production Kanban est née chez le constructeur automobile Toyota. Sa caractéristique essentielle, et qui nous intéresse ici est d’aboutir à une diminution drastique des stocks intermédiaires. L’application aux projets informatiques est très simple : il ne s’agit pas ici de limiter des stocks de marchandises mais de limiter le nombre de tâches « ouvertes » à un instant donné. La meilleure illustration est donnée dans la vidéo présente un peu plus bas dans cette page et que vous pouvez aussi visionner en suivant ce lien.

Voici un lien qui vous permettra d’en savoir plus sur la méthode Kanban :
Kanban sur le site My Agile Partner

Pour beaucoup de gens, agile est synonyme de SCRUM et inversement. La raison en est que la méthode SCRUM a dans beaucoup de pays éclipsé toutes les autres, jusqu’à être la seule enseignée dans les écoles d’informatique.

Le vocabulaire de la méthode Scrum

Artefact: (ou Artifact en anglais). Sont appelés artefacts les trois outils principaux de Scrum, qui concrétisent l’engagement de l’équipe vis-à-vis du client. Ce sont : le product backlog, le sprint backlog et l’incrément produit.
Backlog de produit : Le produit est décomposé en fonctionnalités, ou exigences, ou briques élémentaires, rédigées sous la forme de « stories ». L’ensemble de ces fonctionnalités est appelé backlog de produit. Chaque fonctionnalité est affectée d’un poids représentatif de sa complexité et d’un ordre de priorité.
Backlog de sprint : Ensemble des fonctionnalités prises dans le backlog de produit et que l’équipe se propose de réaliser au cours du sprint.
Burndown chart : Représentation graphique du reste à faire d’un sprint.
Burnup chart : Graphique d’avancement généralement utilisé pour suivre l’avancement d’une Release. La burnup chart comporte deux courbes : celle du travail réalisé, mais aussi du travail à faire : puisqu’on est en agile le périmètre est susceptible d’augmenter ou de diminuer à chaque fin de sprint.
EPIC : Une « EPIC » est une User Story de grande taille (une grande brique fonctionnelle) qui doit être décomposée en des User Stories plus petites pouvant quant à elles être embarquées dans un sprint,
Impediment list : liste de tous les obstacles qui nuisent à la productivité et à la qualité du produit, tenue à jour par le Scrum master.
Incrément produit : Il s’agit d’un résultat tangible, palpable, qui matérialise et rend visible le travail de l’équipe. Concretement, chaque fois qu’une user stoty est achevée, il en résulte un incrément produit.
Planning poker : Technique d’estimation en groupe utilisant un jeu de cartes. L’expression désigne à la fois le jeu de cartes et la séquence collective d’estimation des charges de travail. Les cartes s’inspirent de la suite de Fibonacci. Le but est de se mettre d’accord de manière collective sur un ordre de grandeur de l’estimation. Un jeu de cartes téléchargeable vous sera proposé un peu plus loin.
Product owner : C’est le porteur du projet. Il a une connaissance complète du produit, tant en ce qui concerne l’aspect fonctionnel que l’architecture et les solutions à mettre en œuvre. Le Product Owner définit les fonctionnalités du produit. Il représente les futurs utilisateurs. Il priorise les fonctionnalités à réaliser. Le Product Owner est assimilable au maître d’ouvrage des méthodes classiques.
Release : Une release est une nouvelle version du produit, livrée aux utilisateurs. Elle est le fruit de plusieurs Sprints. La release en agile est l’équivalent du projet dans les méthodes prédictives.
Release plan : Le plan de release correspond à un sous-ensemble de fonctionnalités du backlog produit qui doivent être développées sur l’ensemble des sprints d’une période définie (= la release)
Retrospective de sprint : Réunion de toute l’équipe en fin de sprint. L’équipe fait le point sur ce qui s’est passé dans le Sprint (inspecter) dans le but d’améliorer (adapter) les processus pour le prochain Sprint.
Roadmap produit : Objectifs à moyen-long terme de l’organisme porteur du projet (MOA) en matière d’évolotion du produit.
Scrum (méthode) : Le mot « scrum » désigne la mêlée au jeu de rugby. Scrum est un processus agile de gestion de projet pour construire un logiciel de façon incrémentale, itérative et adaptative.
Scrum board : Tableau de progression des travaux. Généralement présenté sous la forme de post-its collés sur un tableau.
Scrum daily meeting : ou « Daily stand-up » ou encore « Daily scrum meeting ». Réunion quotidienne de 10 à 15 minutes à l’occasion de laquelle l’équipe fait le point du travail réalisé la veille. Les participants de la réunion restent debout. Chaque membre répond à ces 3 questions : qu’ai-je fait hier, que vais-je faire aujourd’hui, quels sont les problèmes que je rencontre. Il revient ensuite (après la réunion) au Scrum Master de résoudre les problèmes soulevés.
Scrum master : C’est l’animateur d’une équipe scrum. Il encadre les les Team member et s’assurent qu’ils travaillent dans les meilleures conditions. Le Scrum Master est assimilable au chef de projet maîtrise d’œuvre des méthodes classiques.
Sprint : Période (ou itération) de 2 à 4 semaines à l’issue de laquelle un certain nombre de fonctionnalités auront été produites, validées par le client et intégrées dans le produit final.
Sprint Backlog : Liste des fonctionnalités (stories) à réaliser pendant le sprint.
Sprint planning : Réunion pendant laquelle l’équipe planifie le travail qui va être réalisé durant le sprint à venir (qu’est-ce qui va être fait, comment on va le faire, et quel est le but global du sprint) C’est aussi pendant le sprint planning que les tâches sont estimées collectivement en terme de …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Schéma général du développement agile SCRUM

Avant d’attaquer la description de cette « fresque », trois remarques importantes :
– Les termes utilisés comme « Epic », « User story » et autres sont définis juste au-dessus.
Les outils représentés en partie basse (planning agile et burndown chart) sont décrits avec plus de précision un peu plus bas sur cette page.
– Comme partout sur ce site vous pouvez cliquer sur l’image pour l’agrandir.
Nous allons commenter ce schéma en partant du haut vers le bas.

La Roadmap produit représente la vision à moyen-long terme des évolutions à venir du produit. Cette vision est celle de la maîtrise d’ouvrage (également appelé client). Le rectangle le plus à gauche, « Projet ou release en cours » correspond au périmètre (ou scope) du projet qui vient d’être confié à l’équipe de développement. Les étapes d’évolution du produit sont décrites dans la roadmap en terme d’objectifs fixés par le maitre d’ouvrage, rédigés par lu dans son vocabulaire métier. Par exemple si l’organisme est un cabinet-conseil opérant en France en B to B et disposant d’un site vitrine, les objectifs pourraient être : « Monétiser le site internet », « Se développer à l’international », « Se positionner sur les marchés publics » etc…

Le Backlog du projet correspond à la traduction des objectifs du projet sous une forme directement exploitable par l’équipe de projet. Chaque objectif est décliné en « Epics » et chaque Epic en « User stories ». Ces termes ont été décrits plus haut. Les user stories seront eux-même ultérieurement décomposés en tâches techniques, ces taches techniques sont ici représentées en pointillé puisqu’au stade du backlog elles ne sont pas encore décrites. Le projet se structure donc en quatre niveaux comme suit
– Objectif = Ce que veut le client
– Epic = Un bloc fonctionnel, une partie du système à livrer.
– User story : Une fonction, décrite avec un formalisme propre à la méthode SCRUM
– Tâche technique : La description précise de ce que doit faire le développeur
Les User stories sont évaluées en terme d’effort à fournir. Une façon de faire est de les évaluer en terme de points, par exemple par la méthode du planning poker.

Le Backlog du sprint est la sélection dans le backlog de projet des user stories qui seront traitées au cours du sprint qui va commencer. Bien entendu le total des points des user stories doit correspond à ce que l’équipe est raisonnablement capable d’achever au cours du sprint. Bien que l’on soit en mode agile, le périmètre du sprint ne doit pas varier en cours de réalisation, même s’il apparait que tout ce qui est demandé ne pourra pas être traité.

Le Planning agile va être l’outil de suivi au quotidien de la progression du sprint. Il prend la forme d’un tableau composé ici de quatre colonnes « A faire », « En cours », « à tester » et « Achevé ». Des variantes existent, mais le principe est touvours le même. Les user stories sont représentées chacune par une étiquette qui commence son parcours dans la colonne de gauche du tableau. On rappelle que chaque user storie…….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

L’expression du besoin : User stories et Backlog du produit

Un des aspects les plus intéressants de Scrum est la façon dont est recueilli et exprimé le besoin des utilisateurs, sous la forme de « user stories » (en français récits utilisateurs). Dans les méthodes classiques le besoin est exprimé par des fonctions. Prenons le cas d’un formulaire en ligne à l’usage des demandeurs d’emploi. L’expression d’une fonction pourrait être « (Le système doit) Permettre au candidat de limiter sa recherche aux départements de son choix ». En terme d’user storie cela donne : « En tant que demandeur d’emploi (rôle) je veux sélectionner les départements (fonctionnalité) dans le but d’obtenir les offres correspondant à mon périmètre de recherche (bénéfice). C’est la même chose mais c’est totalement différent : l’expression fonctionnelle se concentre sur ce que fait le produit, les user stories centrent l’attention sur ce que veut l’utilisateur. Il est beaucoup plus facile pour un individu de dire « je veux pouvoir bénéficier de ceci » que « le futur système doit faire ceci ». L’expérience montre que les réunions de travail en mode « user stories » sont plus dynamiques et productives, jusqu’à être parfois carrément ludiques.
Une bonne User Story doit aussi respecter les caractéristiques réunies sous le sigle INVEST :
– Indépendante : assure l’indépendance d’une User Story vis-à-vis des autres user stories du backlog;
– Négociable : une User Story doit être un support de discussion en vue d’une amélioration du besoin initial;
– Valorisable : la réalisation d’une User Story doit rendre un service à l’utilisateur. En un mot, une User Story n’a de sens que si elle apporte une valeur métier;
– Estimable : une User Story doit être bien définie pour être facilement chiffrable;
– Suffisamment petit : une User Story doit être réalisable sur un sprint;
– Testable : une User Story doit être accompagnée de ces critères d’acceptabilité pour faciliter sa validation.

Estimer l’effort avec le planning poker

Le planning poker est l’outil d’estimation utilisé pour le développement des applications informatiques avec la méthode Scrum. Le planning poker est une variante intelligente et ludique des méthodes à dire d’expert. Il s’inspire de la méthode Delphes pour ce qui est de l’estimation secrète précédant la recherche du consensus. Le but n’est pas d’estimer les charges de travail mais de classer les différentes fonctionnalités par rang de complexité. La traduction en charge de travail se fait ultérieurement par le biais de la vélocité. Comme la plupart des outils des méthodes agiles, le planning poker est parfaitement transposable à tous types de projets en dehors du seul domaine des projets informatiques. On peut faire une séance de Planning Poker au début du projet, puis en refaire d’autres plus tard quand le groupe a acquis une meilleure connaissance du contenu.
Le matériel nécessaire se compose de jeux de 11 cartes de valeurs 0 – 0,5 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100, plus une carte joker et une carte infini. Chaque participant dispose d’un jeu de cartes. Un tableau mural, divisé en autant de colonnes que de valeur possible permettra …….. Pour lire la suite souscrivez un abonnement PREMIUM ou si vous êtes déjà abonné connectez-vous 

Planning agile : le Scrum board

Dans la méthode Scrum les travaux sont pilotés à l’aide d’un planning constitué d’un simple tableau (board) sur lequel sont collés des étiquettes de type « Post-it » représentant chacune l’une des tâches à accomplir. La version manuelle utilise un vrai tableau mural et de vrais post-it. Les nombreuses solutions informatiques développées autour de Scrum reproduisent à l’écran ce tableau et ces étiquettes. Bien entendu la version informatique permet d’automatiser les calculs de temps passé et de reste à faire. Le tableau est partagé en colonnes verticales de façon à créer un flux d’étiquettes de la gauche (à faire) vers la droite (en production) en passant par les étapes intermédiaires « en cours » et « à l’approbation ». Une forme particulière de planning agile, nommée « Kanban » ajoute un perfectionnement supplémentaire : le nombre d’étiquettes figurant dans la colonne « à faire » est volontairement limitée de façon à éviter l’effet d’engorgement et de surcharge de travail des contributeurs.
Voici une variante très proche de la version précédente : une couleur a été affectée à chaque membre de l’équipe, et les données nécessaires au suivi de l’avancement figurent en bas de tableau.

La « Burndown chart »

La burndown chart est une représentation graphique de l’évolution de quantité de travail restante (le reste à faire) par rapport au temps. Le travail restant se situe sur l’axe vertical et le temps sur l’axe horizontal. L’axe vertical (reste à faire) est gradué en points de complexité. Les valeurs sont issues des séances de planning poker. Lorsque l’équipe de projet est employée à plein temps sur le projet, le profil idéal est une droite diagonale descendante. La position des valeurs réelles au-dessus ou au-dessous de la diagonale renseigne immédiatement sur la tendance : Valeurs réelles au-dessus signifie que l’on prend du retard et qu’il faut prendre immédiatement des mesures correctives. La burndown chart donne lieu à deux visions suivant le niveau de granularité : l’un pour chaque sprint (sprint burndown chart) et l’autre globale au niveau du projet (Release burndown chart)

Ne ratez pas cette vidéo explicative sur les méthodes agiles. Son auteur est Henrik Kniberg et elle a été doublée en français par Florent Lothon du site l’agiliste

Autres ressources sur le web

• Le site Aubryconseil, dédié à la méthode Scrum
• Le site de Florent Lauthon, l’agiliste
• La chaine youtube de Scrum Life
• Le blog myagilepartner

Quelques solutions informatiques pour la gestion agile

• Le logiciel PMA de Time performance, dédié aux projets agiles
• L’application en ligne scrumwise avec une interface simple, agréable et ergonomique. (uniquement en anglais)
• De même, Leankit également en anglais et très réussi

Plus de liens vers les logiciels agiles à la page Comment choisir un logiciel de gestion de projet