Scrum (méthode)

En informatique et plus particulièrement en génie logiciel, Scrum est une méthode agile dédiée à la gestion de projets. Son objectif est d'améliorer la productivité des équipes auparavant ralenties par des méthodologies plus lourdes. La métaphore de Scrum (mêlée du rugby) apparaît pour la première fois dans une publication de Takeuchi et Nonaka intitulée The New New Product Development Game^[1] qui s'appliquait à l'époque au monde industriel. Les racines conceptuelles de Scrum se trouvent dans la rupture méthodologique qualifiée d'itérative, incrémentale (modèle en spirale de Barry Boehm (en)) et ensuite adaptative (par rapport à la recherche de prédictibilité du modèle en cascade) dont la première version opérationnelle a été publiée par James Martin^[2] en 1991 sous le nom de RAD (développement rapide d'applications), en ce qui concerne sa structure fondamentale.

La méthode Scrum a été conçue lors de projets de développement de logiciels. Elle peut aussi être utilisée par des équipes de maintenance. Dans le cas de très grands projets, les équipes se multiplient et on parle alors de Scrum de Scrums. La méthode Scrum peut théoriquement s'appliquer à n'importe quel contexte ou à un groupe de personnes qui travaillent ensemble pour atteindre un but commun comme planifier un mariage, gérer des projets de recherche scientifique, des écoles et même des églises comme le précise le site de son principal promoteur Jeff Sutherland.

En revanche, la méthode Scrum ne couvre aucune technique d'ingénierie du logiciel. Aussi, son utilisation dans le contexte du développement d'une application informatique nécessite de lui adjoindre une méthode complémentaire comme l' Extreme Programming ou la phase de Construction structurée, mais non extrême, de la méthode RAD, ou encore un ensemble de pratiques circonstanciées en matière d'obtention et de contrôle de la qualité du logiciel.

Sommaire 1 Historique 2 Caractéristiques 3 Quelques rappels sur les méthodes agiles 3.1 Origine 3.2 Grands principes 3.2.1 Individus et interactions contre processus et outils 3.2.2 Logiciel qui fonctionne contre documentation exhaustive 3.2.3 Collaboration du client contre négociation de contrat 3.2.4 Réponse au changement contre suivi d'un plan prédéfini 3.3 Idées clé 4 Rôles 4.1 Directeur de produit 4.2 Équipe 4.3 Facilitateur / Animateur 4.4 Intervenants 5 Planification 5.1 Sprints 5.2 Releases 5.3 Quotidien 6 Gestion des besoins 6.1 Backlog de produit 6.2 Backlog de sprint 7 Estimations 7.1 Items de backlog de produit 7.2 Calcul de vélocité 7.3 Items de backlog de sprint 8 Déroulement d'un sprint 8.1 Réunion de planification 8.2 Au quotidien 9 Revue de sprint 9.1 Rétrospective du sprint 10 Compléments 10.1 Lancement du projet 10.2 Vue globale 10.3 Burndown Charts 10.3.1 Sprint Burndown Chart 10.3.2 Release Burndown Chart 10.3.3 Interprétation 10.4 Qualité de l'environnement de travail 10.5 Risques de la méthodologie 10.5.1 Un Scrum Master directif 10.5.2 La communication constructive laisse la place aux reproches 10.6 Documentation de projet 10.7 Outils pour Scrum 10.7.1 Papier et crayon / tableur 10.7.2 Outils libres 10.7.3 Outils propriétaires 10.7.4 Autres outils 11 Conclusion 11.1 Scrum 11.2 Mise en garde 12 Glossaire 13 Voir aussi 13.1 Articles connexes 13.2 Liens externes 14 Notes et références

Historique

En 1986, Hirotaka Takeuchi et Ikujiro Nonaka décrivent une nouvelle approche holistique qui augmenterait la vitesse et la flexibilité dans le développement de nouveaux produits^[3]. Dans celle-ci les phases se chevauchent fortement et l'ensemble du processus est réalisé par une équipe aux compétences croisées à travers différentes phases. Ils ont comparé cette nouvelle approche au rugby à XV, où l'équipe essaye d'avancer unie, en faisant circuler la balle (« tries to go to the distance as a unit, passing the ball back and forth »). A part la métaphore de mélée (Scrum)de rugby, cette référence est étonnante car la méthode Scrum interdit formellement les lotissements, les phases et leurs chevauchements.

En 1991, DeGrace et Stahl, dans "Wicked problems, righteous solutions"^[4], font référence à cette approche sous l'appellation « Scrum » (mêlée, en anglais), un terme de rugby mentionné dans l'article de Takeuchi et Nonaka. Dans le début des années 1990, Ken Schwaber a utilisé une approche qui a conduit à Scrum au sein de son entreprise, Advanced Development Methods. En même temps, Jeff Sutherland, John Scumniotales et Jeff McKenna développent une approche similaire à Easel Corporation et sont les premiers à appeler cela Scrum^[5].

En 1995, Sutherland et Schwaber ont présenté conjointement un document décrivant Scrum à l'OOPSLA, à Austin, ÉUA. Schwaber et Sutherland ont collaboré au cours des années suivantes pour fusionner les publications, leurs expériences et les meilleures pratiques du secteur en ce qui est maintenant connu comme Scrum. En 2001, Schwaber fait équipe avec Mike Beedle pour décrire la méthode dans le livre « Agile Software Development With Scrum ». En France, le premier livre français entièrement consacré à Scrum est publié en février 2010 : « SCRUM : Le guide pratique de la méthode agile la plus populaire »^[6].

Caractéristiques

Le terme Scrum est emprunté au rugby à XV et signifie mêlée. Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée.

Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de minimiser les perturbations extérieures et de résoudre les problèmes non techniques de l'équipe.

Un principe fort en Scrum est la participation active du client pour définir les priorités dans les fonctionnalités du logiciel et pour choisir celles qui seront réalisées dans chaque sprint. Il peut à tout moment compléter ou modifier la liste des fonctionnalités à produire, mais jamais celles qui sont en cours de réalisation pendant un sprint. Cette interdiction va formellement à l'encontre du principe d'itération (revenir sur les caractéristiques de la fonctionnalité en cours de développement que le concept de "présence de l'utilisateur sur le site" permettrait de favoriser) et d'adaptabilité immédiate, telle la notion de conception émergente basée sur le feedback issu du travail en cours qui représente une des bases de l'Extrême Programming). En résumé, la notion d'incrément est une valeur facilitant le contrôle de pilotage du projet et la notion d'itération (Méthode itérative) est une valeur conduisant à l'adaptabilité ainsi qu'à la qualité fonctionnelle ou technique. Ces points représentent les principes fondamentaux d'une Méthode agile appliquée à la complexité de l'Ingénierie du logiciel.

Quelques rappels sur les méthodes agiles

Origine

En 2001, 17 représentants des méthodes légères alternatives aux processus lourds traditionnels se sont réunis pour trouver les points communs à leurs méthodes "to find common ground". De cette réunion de quelques jours est né le Manifeste Agile^[7] : un texte bref énonçant des grands concepts, simples, mais qui proposent une nouvelle façon de penser un projet de développement informatique. Si certains dénoncent une certaine évidence de ces concepts, il n'en est pas moins que ce manifeste a pour lui le mérite de les formaliser et surtout de les structurer en un tout homogène et cohérent, par opposition aux pratiques semblables mais complètement hétérogènes d'une entreprise à l'autre et d'un projet à l'autre.

Grands principes

Le manifeste agile résume sa philosophie en quatre oppositions entre les concepts traditionnels et les concepts proposés.

Individus et interactions contre processus et outils

Ce sont les individus qui font la valeur du travail accompli, ce sont donc eux que l’on doit privilégier. Sans l’artisan, les meilleurs outils ne servent à rien. Les processus qui définissent ce que doit faire chaque personne brident le potentiel caché derrière chacun : faire interagir les gens au maximum est bien plus fructueux et permet d'améliorer grandement l'efficacité et la qualité du travail fourni, en rassemblant des visions différentes d'un même problème.

Logiciel qui fonctionne contre documentation exhaustive

Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambigüité du langage, coût de la rédaction, coût du maintien en accord avec la réalité, etc. Ces documents ne sont qu'une illusion d'avancement du projet. Même une conception technique initiale peut être complètement remise en cause en phase de codage (ou après) : comment peut-on alors déterminer l'avancement du projet ? Une régression ?

Dans les méthodes Agiles, un seul critère permet de mesurer l'avancement d'un projet : le logiciel qui fonctionne. La documentation n'est qu'un support concret qui aide à produire le logiciel.

Collaboration du client contre négociation de contrat

Dans tout projet, le but premier est de gagner de l’argent, autant pour le client (rentabilisation) que pour le fournisseur (prestation). Si la négociation protège plus ou moins des risques financiers, elle peut provoquer l’échec des projets (délais non respectés, budgets insuffisants) et engendrer d'interminables procès où tout le monde y perd au bout du compte (le client n'a pas son logiciel et le fournisseur ferme boutique).

Il faut sortir de la guerre client/fournisseur et penser en équipe qui veut atteindre un but commun : réussir le projet.

Réponse au changement contre suivi d'un plan prédéfini

Un plan prédéfini a tendance à nous rendre autistes aux événements qui surviennent pendant le projet. Il est en plus à l'origine des conflits client/fournisseur classiques sur les délais de livraison. Pour le client, pouvoir adapter les besoins en cours de projet est un atout concurrentiel : il est réactif aux fluctuations des marchés et s'assure en plus que le logiciel développé répond parfaitement à ses véritables besoins.

Les méthodes Agiles sont conçues pour s’adapter au changement, en assurant un plan macroscopique précis et adaptatif.

Idées clé

• Le client au cœur du projet
• Esprit d’équipe
• La communication est la clé
• Simplicité, efficacité et qualité
• Flexibilité aux changements
• Avancement basé sur le concret

Rôles

Scrum définit trois rôles principaux : le directeur de produit, le facilitateur / animateur et l'équipe. Des intervenants peuvent s'intégrer également au projet de façon plus ponctuelle.

Directeur de produit

Le directeur de produit (Product Owner) est le représentant des clients et utilisateurs. C'est lui qui définit l'ordre dans lequel les fonctionnalités seront développées et qui prend les décisions importantes concernant l'orientation du projet. Le terme directeur n'est d'ailleurs pas à prendre au sens hiérarchique du terme, mais dans le sens de l'orientation.

Dans l'idéal, le directeur de produit travaille dans la même pièce que l'équipe. Il est important qu'il reste très disponible pour répondre aux questions de l'équipe et pour lui donner son avis sur divers aspects du logiciel (interface par exemple).

Équipe

L'équipe ne comporte pas de rôles prédéfinis, elle est auto-gérée. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble et personne ne donne d'ordre à l'équipe sur sa façon de procéder. Contrairement à ce que l'on pourrait croire, les équipes auto-gérées sont celles qui sont les plus efficaces et qui produisent le meilleur niveau de qualité de façon spontanée.

L'équipe s'adresse directement au directeur de produit. Il est conseillé qu'elle lui montre le plus souvent possible le logiciel développé pour qu'il puisse ajuster les détails d'ergonomie et d'interface par exemple.

Facilitateur / Animateur

Le facilitateur / animateur (ScrumMaster) joue un rôle capital : c'est lui qui est chargé de protéger l'équipe de tous les éléments perturbateurs extérieurs à l'équipe et de résoudre ses problèmes non techniques (administratifs par exemple). Il doit aussi veiller à ce que les valeurs de Scrum soient appliquées, mais il n'est pas un chef de projet ni un intermédiaire de communication avec les clients.

On parle parfois d'équipe étendue, qui intègre en plus le ScrumMaster et le directeur de produit. Ce concept renforce l'idée que client et fournisseur travaillent d'un commun effort vers le succès du projet.

Intervenants

Les intervenants (Stakeholders) sont les personnes qui souhaitent avoir une vue sur le projet sans réellement s'investir dedans. Il peut s'agir par exemple d'experts techniques ou d'agents de direction qui souhaitent avoir une vue très éloignée de l'avancement du projet.

Planification

Scrum propose une planification opérationnelle à trois niveaux : release/projet, sprint et quotidien.

Sprints

Scrum est un processus itératif : les itérations sont appelées des sprints et durent en théorie 30 jours calendaires. En pratique, les itérations durent généralement entre 2 et 4 semaines. Chaque sprint possède un but et on lui associe une liste d'items de backlog de produit (fonctionnalités) à réaliser. Ces items sont décomposés par l'équipe en tâches élémentaires de quelques heures, les items de backlog de sprint.

Pendant un sprint, les items de backlog de sprint à réaliser ne peuvent pas être changés. Les changements éventuels sont pris en compte dans le backlog de produit et seront éventuellement réalisés dans les sprints suivants.

Il y a une exception à cela : il se peut que l'équipe se rende compte en cours du sprint qu'elle n'aura pas le temps de terminer un item du backlog de sprint ou au contraire qu'elle aura fini en avance. Dans ce cas, et seulement d'un commun accord entre l'équipe et le directeur du produit, on peut enlever ou ajouter un item à ce qui a été prévu.

Releases

Pour améliorer la lisibilité du projet, on regroupe généralement des itérations en releases. Bien que ce concept ne fasse pas explicitement partie de Scrum, il est utilisé pour mieux identifier les versions. En effet, comme chaque sprint doit aboutir à la livraison d'un produit partiel, une release permet de marquer la livraison d'une version aboutie, susceptible d'être mise en exploitation.

Il est intéressant de planifier à l'échelle d'une release, en répartissant les items du backlog de produit sur les sprints, en respectant leur priorité. Bien entendu, ce qui est planifié au-delà du sprint courant peut changer à tout moment, rien n'est figé à l'avance.

Quotidien

Au quotidien, une réunion, le ScrumMeeting (appelé également réunion Post-it), permet à l'équipe et au ScrumMaster de faire un point d'avancement sur les tâches et sur les difficultés rencontrées.

Gestion des besoins

Backlog de produit

Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs. L'objectif est d'établir une liste de fonctionnalités à réaliser, que l'on appelle backlog de produit (NDT : Le terme backlog peut être traduit par cahier, liste ou carnet de commandes, qui ne collent pas bien avec l'esprit du terme anglais qui évoque aussi une réserve, un retard accumulé ; aussi ce terme a été gardé tel quel).

À chaque item de backlog sont associés deux attributs : une estimation en points arbitraires (voir Estimation) et une valeur client, qui est définie par le directeur de produit (retour sur investissement par exemple). Ce dernier définit dans quel ordre devront être réalisés ces items. Il peut changer cet ordre en cours de projet et même ajouter, modifier ou supprimer des items dans le backlog.

La somme des points des items du backlog de produit constitue le reste à faire total du projet. Cela permet de produire un release burndown chart, qui montre les points restant à réaliser au fur et à mesure des sprints.

Remarque : il arrive souvent qu'on utilise dans Scrum les User Stories de la méthode Extreme Programming, qui proposent des pratiques et des techniques intéressantes (le Planning poker pour les estimer par exemple).

Backlog de sprint

Lorsqu'on démarre un sprint, on choisit quels items du backlog de produit seront réalisés dans ce sprint. L'équipe décompose ensuite chaque item en liste de tâches élémentaires (techniques ou non), chaque tâche étant estimée en heures et ne devant pas durer plus de 2 jours. On constitue ainsi le backlog de sprint.

Pendant le déroulement du sprint, chaque équipier s'affecte des tâches du backlog de sprint et les réalise. Il met à jour régulièrement dans le backlog du sprint le reste à faire de chaque tâche. Les tâches ne sont pas réparties initialement entre tous les équipiers, elles sont prises au fur et à mesure que les précédentes sont terminées.

La somme des heures des items du backlog de sprint constitue le reste à faire total du sprint. Cela permet de produire un sprint burndown chart qui montre les heures restantes à réaliser au fur et à mesure du sprint.

Estimations

Scrum ne définit pas spécialement d'unités pour les items des backlogs. Néanmoins, certaines techniques se sont imposées de fait.

Items de backlog de produit

Les items de backlog de produit sont souvent des User Stories empruntées à Extreme Programming. Ces User Stories sont estimées en points relatifs, sans unité. L'équipe prend un item représentatif et lui affecte un nombre de points arbitraire. Cela devient un référentiel pour estimer les autres items. Par exemple, un item qui vaut 2 points représente deux fois plus de travail qu'un item qui en vaut 1. Pour les valeurs, on utilise souvent les premières valeurs de la suite de Fibonacci (1,2,3,5,8,13), qui évitent les difficultés entre valeurs proches (8 et 9 par exemple).

L'intérêt de cette démarche est d'avoir une idée du travail requis pour réaliser chaque fonctionnalité sans pour autant lui donner une valeur en jours que le directeur de produit serait tenté de considérer comme définitivement acquise. En revanche, on utilise la vélocité pour planifier le projet à l'échelle macroscopique de façon fiable et précise.

Calcul de vélocité

Une fois que tous les items de backlog de produit ont été estimés, on attribue un certain nombre d'items à réaliser aux sprints successifs. Ainsi, une fois un sprint terminé, on sait combien de points ont été réalisés et on définit alors la vélocité de l'équipe, c'est-à-dire le nombre de points qu'elle peut réaliser en un sprint.

En partant de cette vélocité et du total de points à réaliser, on peut déterminer le nombre de sprints qui seront nécessaires pour terminer le projet (ou la release en cours). L'intérêt, c'est qu'on a une vision de plus en plus fiable (retours d'expérience de sprint en sprint) de la date d'aboutissement du projet, tout en permettant d'aménager les items de backlog du produit en cours de route.

Items de backlog de sprint

Les items de backlog de sprint sont généralement exprimés en heures et ne doivent pas dépasser 2 journées de travail, sinon il convient de les décomposer en plusieurs items. Par abus de langage, on emploie le terme de tâches, les concepts étant très proches.

Déroulement d'un sprint

Réunion de planification

Tout le monde est présent à cette réunion, qui ne doit pas durer plus de 4 heures. La réunion de planification (Sprint Planning) consiste à définir d'abord un but pour le sprint, puis à choisir les items de backlog de produit qui seront réalisés dans ce sprint. Cette première partie du sprint planning représente l'engagement de l'équipe. Compte tenu des conditions de succès énoncées par le directeur de produit et de ses connaissances techniques, l'équipe s'engage à réaliser un ensemble d'items du backlog de produit.

Dans un second temps, l'équipe décompose chaque item du backlog de produit en liste de tâches (items du backlog du sprint), puis estime chaque tâche en heures. Il est important que le directeur de produit soit présent dans cette étape, il est possible qu'il y ait des tâches le concernant (comme la rédaction des règles métier que le logiciel devra respecter et la définition des tests fonctionnels).

Au quotidien

Chaque journée de travail commence par une réunion de 15 minutes maximum appelée mêlée quotidienne (Daily Scrum). Seuls l'équipe, le directeur de produit et le ScrumMaster peuvent parler, tous les autres peuvent écouter mais pas intervenir (leur présence n'est pas obligatoire). A tour de rôle, chaque membre répond à 3 questions :

• Qu'est-ce que j'ai fait hier ?
• Qu'est-ce que je compte faire aujourd'hui ?
• Quelles sont les difficultés que je rencontre ?

Le tour de parole doit être scrupuleusement respecté pour éviter que le Scrum dérive sur des discussions techniques et déborde des 15 minutes. Si le besoin s'en fait sentir, des discussions sont alors menées librement après le Scrum.

Cette réunion a un but de synchronisation pour l'équipe et ne doit pas être vécue comme un reporting d'activité. C'est le niveau quotidien du principe inspect and adapt de Scrum.

L'équipe se met ensuite au travail. Elle travaille dans une même pièce, dont le ScrumMaster a la responsabilité de maintenir la qualité d'environnement. Les activités se déroulent éventuellement en parallèle : analyse, conception, codage, intégration, tests, etc. Scrum ne définit volontairement pas de démarche technique pour le développement du logiciel : l'équipe s'auto-gère et décide en toute autonomie de la façon dont elle va travailler.

Remarque : Il est assez fréquent que les équipes utilisent la démarche de développement guidé par les tests (Test Driven Development en anglais). Cela consiste à coder en premier lieu les modules de test vérifiant les contraintes métier, puis à coder ensuite le logiciel à proprement parler, en exécutant les tests régulièrement. Cela permet de s'assurer entre autres de la non-régression du logiciel au fil des sprints.

Revue de sprint

À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au maximum 4 heures. L'objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint. L'équipe commence par énoncer les items du backlog de produit qu'elle a réalisés. Elle effectue ensuite une démonstration du logiciel produit. C'est sur la base de cette démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint.

Une fois le bilan du sprint réalisé, l'équipe et le directeur de produit proposent des aménagements sur le backlog du produit et sur la planification provisoire de la release. Il est probable qu'à ce moment des items soient ajoutés, modifiés ou réestimés, en conséquence de ce qui a été découvert.

Rétrospective du sprint

La rétrospective du sprint est faite en interne à l'équipe (incluant le ScrumMaster). L'objectif est de comprendre ce qui n'a pas bien marché dans le sprint, les erreurs commises et de prendre des décisions pour s'améliorer. Il est tout à fait possible d'apporter des aménagements à la méthode Scrum dans le but de s'améliorer. Il faut être très vigilant à ne pas retomber dans des pratiques rigides des méthodologies plus classiques.

Compléments

Lancement du projet

Scrum présuppose que le backlog de produit est déjà défini au début du projet. Une approche possible pour constituer ce backlog est de réaliser une phase de lancement. Cette phase de lancement s'articule autour de deux axes de réflexion : l'étude d'opportunité et l'expression initiale des besoins.

L'étude d'opportunité est très variable d'un projet à l'autre, tout dépend du contexte de l'entreprise, de la nature du projet (sous-traitance ou interne), etc. Chaque entreprise a sa propre politique sur cette activité.

L'expression initiale des besoins n'est pas un élément défini dans Scrum et n'est surtout pas une activité de contractualisation d'un cahier des charges. L'esprit d'une telle activité dans les méthodes Agiles est de définir d'une part le cadre du projet (pour que l'équipe s'imprègne du contexte métier) et d'autre part une première analyse globale des besoins. L'objectif est d'identifier un maximum de fonctionnalités que le logiciel devra implémenter, en se limitant à un niveau de précision assez grossier. On peut par exemple utiliser une approche par raffinages successifs, en partant des secteurs métiers concernés par l'application, puis en identifiant les activités métier, qu'on décompose en tâches métier qui correspondent à des fonctionnalités que l'on doit/peut ou non implémenter dans le logiciel final.

L'objectif pour Scrum est de produire la première version du backlog de produit.

Vue globale

Burndown Charts

Les burndown charts (graphiques d'avancement) permettent de visualiser graphiquement l'avancement du travail. Une interprétation simple permet d'avoir une idée sur les échéances futures.

Sprint Burndown Chart

Ce graphique représente la quantité totale d'heures restantes à faire dans le sprint, au fil des jours. Il permet d'avoir une vue sur l'avancement du sprint.

Release Burndown Chart

Ce graphique représente la quantité totale de points restant à faire dans la release, au fil des sprints. Il permet d'avoir une vue sur l'avancement de la release.

Interprétation

Ces graphiques sont très intéressants à analyser et interpréter. Outre le fait de montrer l'avancement concret du travail, ils permettent d'anticiper de façon relativement fiable les échéances futures en cours du sprint ou de la release.

On peut observer de légères augmentations du reste à faire sur le burndown chart du sprint. Cela correspond généralement à une réestimation à la hausse, suite à la prise en compte de contraintes techniques que l'on n'avait pas vues lors de l'estimation initiale. Si c'est le cas, il est indispensable de comprendre la cause de ces augmentations. Le même phénomène peut s'observer sur des légères diminutions, pour les mêmes raisons.

On peut utiliser en cours du sprint la tendance de la courbe pour avoir une idée approximative de la fin du sprint. Cela consiste à prendre un segment de droite dont la pente est représentative des valeurs déjà recensées et de le prolonger jusqu'à son point d'intersection avec l'axe des abscisses. Cela nous donne alors la date a priori de la fin du sprint et nous permet alors de prendre une décision sur la suppression (ou l'ajout) d'un item de backlog du produit à réaliser dans ce sprint. C'est ce qui s'est probablement passé le 15 mai 2002 sur le graphique de sprint ci-dessus : le reste à faire diminue dans ce cas assez brutalement.

C'est exactement la même chose pour les burndown charts de release. Si la date de publication de la release est clairement au-delà de ce que l'on espérait, on peut aviser en enlevant des items de backlog du produit ou changeant leur ordre, de sorte que les fonctionnalités les moins importantes soient celles qui risquent de ne pas être développées à temps.

Cette approche, bien que basée sur des tendances approximatives, permet d'identifier très tôt les risques de défaillance et d'agir en conséquence, en conservant à l'esprit le caractère critique des fonctionnalités à développer. Ces décisions importantes relèvent complètement du directeur de produit.

Une dernière chose importante : la fiabilité de la vélocité de l'équipe et des estimations qu'elle a faites augmente au fil des sprints. On élimine de cette façon les risques majeurs au plus tôt dans le projet.

Qualité de l'environnement de travail

Un concept fort de Scrum est la qualité de l'environnement de travail de l'équipe. Cela inclut :

• Pas de changements imposés pendant un sprint
• Toute l'équipe dans une même pièce
• Un tableau blanc et/ou en liège
• Un bon outil de suivi du projet
• Prévenir des interventions extérieures (téléphone, irruption dans la pièce, etc.)
• Tout ce qui peut rendre l'équipe plus sereine et efficace

Risques de la méthodologie

Dans Scrum, les risques, en particulier de dérives sont multiples. Ils ne sont pas présents et dans la même proportion dans tout projet. Néanmoins, ces risques deviennent de plus en plus courant avec la montée de Scrum. Le risque majeur dans l'utilisation de Scrum est avant tout une application allant à l'encontre même des principes fondateurs de son fonctionnement. On peut en citer deux, mais il en existe bien d'autres :

• un Scrum Master directif.
• La communication constructive laisse la place aux reproches.

Un Scrum Master directif

L'un des plus graves risques de Scrum est la violation du principe même de son fonctionnement qui met l'équipe de développement au cœur même du processus. Il n'est pas rare que le Scrum Master soit un chef de projet déguisé ou officiel et qu'il applique un contrôle trop strict sur les membres de son équipe^[8].

Dans ce contexte, on demande aux développeurs de s'impliquer comme s'ils étaient responsables du projet mais en réalité ils ne le sont pas, puisque le Scrum Master qui est le chef de projet a le dernier mot pour tout et peut effectuer des choix arbitraires. Ce qui peut apporter des frustrations côté développeur. En outre, dans ce type de configuration, le Scrum Master qui n'en est plus un, n'endosse plus les responsabilités du Scrum Master : être le protecteur de l'équipe, objectif, garde-fou, garant de la méthodologie appliquée, etc... Les bénéfices de l'agilité peuvent ainsi disparaître : défiance de l'équipe vis-à-vis du Scrum Master, conflit à l'intérieur même de l'équipe, non-dit, désengagement qui engendre baisse de la qualité et absence de bonnes pratiques.

La communication constructive laisse la place aux reproches

La surexposition dans Scrum prend sa source dans les différentes réunions d'équipe telles que la quotidienne matinale, censée informer et apporter des solutions aux problèmes de la veille. Sur certains projets, ces réunions se transforment en blâme des membres n'ayant pas réussi à mener à bien leurs tâches de la veille. Les conséquences dans ce cas peuvent prendre la forme de discussions houleuses et ou de conflits plus ou moins durables entre membres de l'équipe. On constate aussi parfois à l'inverse une manière différente d'appréhender la réunion quotidienne : non-dit ou propos vagues en ce qui concerne les problèmes rencontrés. Ainsi, les réunions peuvent se passer de façon plus courtoises mais un risque de ne plus chercher le support de l'équipe en cas de difficultés se développe. Ce qui va à l'encontre même des principes de Scrum.

A l'inverse, sur les projets cycle en V, on dispose d'un effet de lissage, qui permet de compenser un jour ce qu'on a moins bien fait la veille. En outre, les difficultés rencontrées un jour par un membre de l'équipe ne sont pas mises en avant aux yeux de tous. Le membre en question peut trouver une solution seul le lendemain ou demander de l'aide auprès de collègues. En clair, il a le choix de choisir sa solution et de ne pas être potentiellement rabaissé par les autres membres de l'équipe.

Documentation de projet

Scrum n'impose aucune documentation particulière pour les projets. Des documents sont implicitement produits (backlogs, burndown charts), mais ils ont une vocation avant tout utilitaire.

Produire de la documentation, il souvent utile mais aussi souvent inutile. En plus, il faut la maintenir à jour, quelque chose est rarement fait sur place. Pour savoir s'il faut rédiger un document, on peut se poser une question très simple : Est-ce que ce document va m'être vraiment utile et tout de suite ?

Voici quelques exemples de documents utiles et dans quels cas :

• diagrammes métiers (processus, objets, etc.), associé au backlog de produit : uniquement si la logique métier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'équipe devrait produire ce document avec lui ;
• diagramme de séquence, associé à un item du backlog du produit : uniquement si la fonctionnalité aura une utilisation complexe, tant au niveau métier qu'applicatif ;
• diagrammes d'architecture du logiciel (classes, modules, composants, etc.), pour le projet : indispensable pour avoir toujours sous les yeux une vue de l'architecture et s'assurer ainsi qu'elle est de qualité ;
• les manuels utilisateur, à chaque sprint : les manuels sont produits à chaque sprint et pas en fin de projet. Utiliser des vidéos de démonstrations commentées est une solution efficace ;
• les FAQ pour le centre d'appel : des cas classiques où les utilisateurs ne vont pas comprendre un comportement métier. Cela permet de traiter un maximum de problèmes au niveau du centre d'appel, avant que cela n'arrive aux équipes de développement/maintenance.

Bref, un document ne doit être produit que si son utilité est réelle et immédiate.

Outils pour Scrum

Un bon artisan n'est rien sans un bon outil. Il n'y a pas aujourd'hui d'outil ultime pour Scrum. Voici un petit panel des possibilités.

Papier et crayon / tableur

Scrum peut être mis en pratique avec trois fois rien : deux listes suffisent. La liste des items du backlog de produit et la liste des items du backlog de sprint. La saisie et la mise à jour des données est simplement un peu moins agréable.

Outils libres

• Aldon Agile Manager Aldon Agile Manager est gratuit
• IceScrum (open-source et démo en ligne)
• theSCRUM open-source et démo en ligne, implémente un tableau blanc virtuel
• EPF Eclipse Process Framework intègre un plug-in Scrum (open-source)
• OpenERP OpenERP intègre un module Scrum (open-source)

Outils propriétaires

• Youkan (Gratuit pour l'utilisation en ligne)
• AccuRev (Solutions de gestion de configuration logicielle intégrant les méthodes Agile et Scrum)
• ScrumDesk (gratuit pour 5 utilisateurs maximum)
• Intra'Know PROJET (cette solution collaborative intégre les grands principes de la méthode AGILE )
• ScrumWorks (gratuit sous conditions)
• VersionOne (gratuit sous conditions)
• RallyDev
• GreenHopper (licence 10 utilisateurs pour 10$, combinable avec les autres produits Atlassian)
• Microsoft eScrum Version 1.0 pour Visual Studio Team Foundation Server
• Scrumy (Démonstration en ligne gratuite)
• ScrumEdge (Démonstration en ligne gratuite)
• Serena Agile On Demand Entièrement en mode SAAS. Aucune installation nécessaire. Essai gratuit 60j.
• Urban Turtle Plugin for TFS web Access (Essai gratuit 30 Jours).
• Virtual SCRUM Board (Essais gratuit de 60 Jours)

Autres outils

• Voir les ressources ScrumAlliance.

Conclusion

Scrum

Scrum est un processus de développement de logiciels qui s'intéresse plutôt à l'organisation du projet qu'aux aspects techniques. Son cadre de travail est sa force, si bien que cette méthode pourrait être appliquée à d'autres domaines. Son approche incrémentale et basée sur les besoins priorisés du client lui confèrent une flexibilité extrême. Elle incarne bien par là l'état d'esprit de la mêlée de rugby : avancer tous ensemble vers un but commun, la réussite du projet.

Les pratiques de Scrum sont essentiellement orientées sur la maîtrise d’une livraison d’incréments (sprint) mais réfutent la possibilité de modifier les fonctionnalités en cours de réalisation (dans le backlog de sprint). Cette limite interdit la mise en œuvre d’une conception émergente comme celle d'XP ainsi que celle d' itération, base de l'adaptabilité (possibilité d'affinement par modification permanente). Scrum, ne disposant pas de métrique de gestion du changement à ce niveau, nécessite donc une importante spécification préalable à la mise en production (backlog produit) et, du fait de cette prédictibilité imposée, ne peut pas être considéré comme réellement itératif, donc adaptatif.

Scrum est un processus intéressant comme premier pas vers les méthodes Agiles : il est facile à comprendre et à pratiquer. La seule difficulté relève plutôt de l'environnement organisationnel (voir la mise en garde ci-dessous).

Mise en garde

On entend de plus en plus de sociétés clamer qu'elles sont Agiles, comme argument commercial à la mode, parce qu'elles utilisent quelques pratiques des méthodes Agiles. Mais être Agile, c'est bien plus que de mettre en pratique une méthode. L'Agilité requiert des dispositions particulières qui sont loin d'être faciles à mettre en place :

• Une organisation adaptée : il est très difficile de convaincre les organes décisionnels d'une entreprise de travailler de façon Agile. En effet, cela signifie de ne pas disposer dès le départ d'une date et d'un budget très précis, mais plutôt d'un ordre de grandeur.
• Un état d'esprit : être Agile, c'est privilégier l'esprit d'équipe et pas seulement dans la réalisation technique. Le client doit comprendre que l'on attend de lui un investissement personnel bien supérieur à celui des méthodes plus classiques, en testant le logiciel souvent et en participant à toutes les réunions.
• Un environnement favorable : éliminer les contraintes dans une entreprise n'est pas toujours évident. Comment limiter les appels téléphoniques trop fréquents, les irruptions dans la pièce de l'équipe, les opérations "urgentes" demandées aléatoirement par la direction, etc. ?

Bref, utiliser une méthode comme Scrum au niveau de l'équipe technique ne suffit pas. L'Agilité est une façon de travailler différente de ce dont on a l'habitude, c'est l'attitude du changement, de la flexibilité, de l'adaptation et de l'amélioration continue. Ce n'est pas aussi simple qu'une méthode…

Glossaire

Directeur de produit (Product Owner) 

personne responsable de produire et maintenir à jour le backlog de produit. C'est lui qui en détermine les priorités et qui prend les décisions concernant l'orientation du projet.

Chef de mélée (ScrumMaster) 

membre de l'équipe dont l'objectif principal est de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe.

Backlog de produit (Product Backlog) 

liste des fonctionnalités qui devront être réalisées par le logiciel.

Backlog de sprint (Sprint Backlog) 

liste des tâches à accomplir pendant un sprint. Elles correspondent à la réalisation des items de backlog du produit affectés au sprint.

Mêlée quotidienne (Daily Scrum) 

réunion quotidienne de 15 minutes qui a pour but de faire le point sur ce qui a été fait depuis la dernière mêlée, ce qui est prévu de faire jusqu'à la prochaine et quelles sont les embûches rencontrées durant le travail.

Sprint 

nom d'une itération dans Scrum. Cette itération dure 30 jours calendaires en théorie, mais en pratique on utilise plutôt entre 2 et 4 semaines. Pendant une itération, l'équipe doit développer une liste d'items du backlog de produit qui a été définie au début de ce sprint.

Graphique d'avancement (Burndown Chart) 

graphique qui montre la tendance du reste à faire total de jour en jour (pour les sprints) ou de sprint en sprint (pour les releases).

Voir aussi

Articles connexes

• Cycle de développement
• Méthode agile
• Extreme programming

Liens externes

• (en) Site officiel Scrum
• (en) Agile Alliance : Communauté autour des méthodes Agiles
• (en) Scrum Alliance : Communauté autour de Scrum
• (en) Liste de discussion par mail
• (fr) Liste de discussion par mail francophone
• (fr) Introduction à Scrum en licence CreativeCommons, traduction par Claude Aubry à partir de la version de Mike Cohn. La traduction des termes Scrum anglais de cette présentation a été utilisée dans cet article.
• (fr) Planification et gestion de projet informatique : SCRUM : Conférence vidéo de Christian Trotobas enregistrée aux Intellicore Tech Talks au sujet de la méthode SCRUM et de ses applications
• (fr) Le French Scrum User Group : le groupe d'utilisateurs de Scrum en France.
• (en) Vidéo "Scrum in the real World": Une Vidéo sur l'application de la méthode Scrum sur un projet Web.
• (en) Processus "Scrum Process Asset Library": Un moyen facile de naviguer la methodologie Scrum

Notes et références

• Portail de l’informatique