Recherchez sur tout Techno-Science.net
       
Techno-Science.net : Suivez l'actualité des sciences et des technologies, découvrez, commentez
 A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | +
Scrum

Scrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer grandement la productivité dans les équipes auparavant paralysées par des méthodologies plus lourdes. Les racines de Scrum se retrouvent dans la publication de Takeuchi et Nonaka dans "The New New Product Development (Development est une revue scientifique bimensuelle à comité de lecture couvrant tous les champs de la génétique évolutive du développement allant de la...) Game"[1].

Son utilisation est prévue initialement pour la gestion de projets de développement, et elle a été utilisée avec succès pour englober Extreme Programming (L'Extreme Programming (XP) est une méthode agile de gestion de projet informatique adaptée aux équipes réduites avec des besoins changeants. Elle pousse à l'extrême des principes simples.) et d'autres méthodes de développement. Cependant, elle peut théoriquement s'appliquer à n'importe quel contexte (Le contexte d'un évènement inclut les circonstances et conditions qui l'entourent; le contexte d'un mot, d'une phrase ou d'un texte inclut les...) où un groupe de personnes ont besoin (Les besoins se situent au niveau de l'interaction entre l'individu et l'environnement. Il est souvent fait un classement des besoins humains en trois grandes catégories : les besoins...) de travailler ensemble (En théorie des ensembles, un ensemble désigne intuitivement une collection d’objets (les éléments de l'ensemble), « une multitude qui peut être comprise comme un tout », comme...) pour atteindre un but commun - comme gérer une petite école, des projets de recherche scientifique (La recherche scientifique désigne en premier lieu l’ensemble des actions entreprises en vue de produire et de développer les connaissances scientifiques. Par extension métonymique, la recherche scientifique désigne également le cadre...) ou planifier un mariage.

Bien que Scrum (Scrum est une méthode agile pour la gestion de projets. Elle a été conçue pour améliorer grandement la productivité dans les équipes auparavant paralysées par des méthodologies plus...) ait été conçue pour la gestion de projets de développement de logiciels, elle peut être utilisée dans des équipes en cours de maintenance, ou comme une approche de gestion de programmes plus vastes (on peut utiliser alors le Scrum de Scrums).

Introduction

Scrum est le fruit (En botanique, le fruit est l'organe végétal protégeant la graine. Caractéristique des Angiospermes, il succède à la fleur par...) de l'effort entre Ken Schwaber et Jeff Sutherland qui, au début des années 1990, ont mis au point (Graphie) les grands principes de Scrum. Mais ce n'est qu'en 1996, que Scrum est né officiellement avec la publication du premier article[2] définissant cette méthodologie.

Le terme Scrum est emprunté au rugby et signifie mêlée. Ce processus s (Le processus S (avec S pour slow, lent en anglais) est un processus de nucléosynthèse de capture de neutrons par des noyaux atomiques qui permet ainsi de...)'articule en effet autour (Autour est le nom que la nomenclature aviaire en langue française (mise à jour) donne à 31 espèces d'oiseaux qui, soit appartiennent au genre Accipiter, soit...) 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 de façon itérative sur un ensemble de fonctionnalités à réaliser, dans des itérations de 30 jours, appelées Sprints. Chaque Sprint (SPRINT est une méthode d'analyse de risque, créée en 1995 par Information Security Forum.) possède un but à atteindre, défini par le Directeur de produit, à partir duquel sont choisies les fonctionnalités à implémenter dans ce sprint. Un sprint aboutit toujours sur la livraison d'un produit partiel (Le mot partiel peut être employé comme :) fonctionnel. Pendant ce temps (Le temps est un concept développé par l'être humain pour appréhender le changement dans le monde.), le ScrumMaster a la charge (La charge utile (payload en anglais ; la charge payante) représente ce qui est effectivement transporté par un moyen de transport donné, et qui donne lieu à un paiement ou un...) de réduire au maximum 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 (Le mot client a plusieurs acceptations :) pour définir les priorités dans les fonctionnalités du logiciel (En informatique, un logiciel est un ensemble d'informations relatives à des traitements effectués automatiquement par un appareil informatique. Y sont inclus les...), et choisit lesquelles seront réalisées dans chaque sprint. Il peut à tout (Le tout compris comme ensemble de ce qui existe est souvent interprété comme le monde ou l'univers.) moment compléter ou modifier la liste des fonctionnalités à réaliser, mais jamais ce qui est en cours de réalisation pendant un sprint.

Quelques rappels sur les méthodes Agiles

Origine

En 2001, 17 représentants des méthodes légères alternatives (Alternatives (titre original : Destiny Three Times) est un roman de Fritz Leiber publié en 1945.) aux processus lourds traditionnels se sont réunis pour comprendre ce qui est à l'origine des très nombreux échecs des projets informatiques, et pour proposer des concepts qui permettraient d'éviter ces échecs. De cette réunion de quelques jours est né le Manifeste Agile[3] : un texte bref énonçant des grands concepts, simples, mais qui proposent une nouvelle façon de penser un projet (Un projet est un engagement irréversible de résultat incertain, non reproductible a priori à l’identique, nécessitant le concours et...) de développement informatique (L´informatique - contraction d´information et automatique - est le domaine d'activité scientifique, technique et industriel en rapport avec le...). 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 (Le complètement ou complètement automatique, ou encore par anglicisme complétion ou autocomplétion, est une fonctionnalité informatique permettant à l'utilisateur de limiter la...) 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 vs. 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 (Servent est la contraction du mot serveur et client.) à 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 prolifique et permet d'améliorer grandement l'efficacité et la qualité du travail fourni (Les Foúrnoi Korséon (Grec: Φούρνοι Κορσέων) appelés plus communément Fourni, sont un archipel de petites îles...), en rassemblant des visions différentes d'un même problème.

Logiciel qui fonctionne vs. Documentation exhaustive

Les processus lourds génèrent une documentation qui se veut exhaustive avec tous ses inconvénients : ambiguïté 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 (Le mot phase peut avoir plusieurs significations, il employé dans plusieurs domaines et principalement en physique :) de codage (De façon générale un codage permet de passer d'une représentation des données vers une autre.) (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 vs. Négociation (La négociation est la recherche d'un accord, centrée sur des intérêts matériels ou des enjeux quantifiables entre deux ou plusieurs interlocuteurs (on ne négocie pas avec soi-même, on délibère), dans un temps...) de contrat

Dans tout projet, le but premier est de gagner de l?argent (L’argent ou argent métal est un élément chimique de symbole Ag — du latin Argentum — et de numéro atomique 47.), 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 (Le mot monde peut désigner :) 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 vs. 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 (La communication concerne aussi bien l'homme (communication intra-psychique, interpersonnelle, groupale...) que l'animal (communication intra- ou inter- espèces) ou la machine (télécommunications, nouvelles technologies...),...) est la clé
  • Simplicité, Efficacité, et Qualité
  • Flexibilité aux changements
  • Avancement basé sur le concret

Rôles

Rôles dans Scrum
Rôles dans Scrum

Scrum définit trois rôles principaux : le Directeur de produit, le ScrumMaster, 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 (Au sens littéral, l'orientation désigne ou matérialise la direction de l'Orient (lever du soleil à l'équinoxe) et des points cardinaux (nord de la boussole) ;) du projet. Le terme Directeur n'est d'ailleurs pas à prendre au sens (SENS (Strategies for Engineered Negligible Senescence) est un projet scientifique qui a pour but l'extension radicale de l'espérance de vie humaine. Par une évolution progressive...) hiérarchique du terme, mais dans le sens de l'orientation.

Dans l'idéal (En mathématiques, un idéal est une structure algébrique définie dans un anneau. Les idéaux généralisent de façon féconde l'étude de la...) 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 (Anderlik-Varga-Iskola-Sport (Anderlik-Varga-Ecole-Sport) fut utilisé pour désigner un projet hongrois de monoplace de sport derrière lequel se cachait en fait un monoplace...) 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 pourraît 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 (Les adresses forment une notion importante en communication, elles permettent à une entité de s'adresser à une autre parmi un ensemble d'entités. Pour qu'il n'y ait pas d'ambiguïté,...) 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 (Une interface est une zone, réelle ou virtuelle qui sépare deux éléments. L’interface désigne ainsi ce que chaque élément a besoin de connaître de l’autre...) par exemple.

ScrumMaster

Le ScrumMaster joue (La joue est la partie du visage qui recouvre la cavité buccale, fermée par les mâchoires. On appelle aussi joue le muscle qui sert principalement à ouvrir et fermer la bouche et à mastiquer.) 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 (Un chef de projet, en informatique est la personne chargée de contrôler le bon déroulement du développement d'un logiciel informatique. Par extension, le terme chef de projet s'applique dans d'autres...) 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 (La vue est le sens qui permet d'observer et d'analyser l'environnement par la réception et l'interprétation des rayonnements lumineux.) 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 (La planification est la programmation d'actions et d'opérations à mener)

Exemple de planification en Scrum
Exemple de planification en Scrum

Scrum utilise une planification à 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 (Le mot théorie vient du mot grec theorein, qui signifie « contempler, observer, examiner ». Dans le langage courant, une théorie est une idée ou une connaissance spéculative, souvent basée sur l’observation ou...) 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 (L'heure est une unité de mesure  :), 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 Scrum, 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 (En mathématiques, le terme fonctionnelle se réfère à certaines fonctions. Initialement, le terme désignait les fonctions qui en prennent d'autres en argument. Aujourd'hui, le...) 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 ou liste, qui ne collent pas bien avec l'esprit du terme Anglais ; aussi ce terme a été gardé tel quel).

A chaque item de backlog sont associées 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 ( Total est la qualité de ce qui est complet, sans exception. D'un point de vue comptable, un total est le résultat d'une addition, c'est-à-dire...) du projet. Cela permet de produire un release burndown chart, qui montre les points restant à réaliser au fur (Fur est une petite île danoise dans le Limfjord. Fur compte environ 900 hab. . L'île couvre une superficie de 22 km². Elle est située...) 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 (Le jour ou la journée est l'intervalle qui sépare le lever du coucher du Soleil ; c'est la période entre deux nuits, pendant laquelle les rayons du Soleil éclairent le ciel....) 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 (La notion de nombre en linguistique est traitée à l’article « Nombre grammatical ».) 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 (Leonardo Fibonacci (Pise, v. 1170 - v. 1250) est un mathématicien italien. Fibonacci (de son nom moderne), connu à l'époque sous le nom de Leonardo...) (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 1 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 (Le mot « route » dérive du latin (via) rupta, littéralement « voie brisée », c'est-à-dire creusée dans la roche, pour ouvrir le chemin.).

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, auquel cas 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 du produit qui seront réalisés dans ce sprint. C'est le directeur de produit qui prend ces décisions, en accord avec l'équipe, qui possède l'expertise technique pour juger de la faisabilité.

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 que des tâches le concernent (comme la rédaction des règles métier (Les règles métier (ou règles de gestion, ou « business rules ») sont des déclarations de haut niveau structurées, qui permettent de contraindre, contrôler et...) que le logiciel devra respecter et la définition (Une définition est un discours qui dit ce qu'est une chose ou ce que signifie un nom. D'où la division entre les définitions réelles et les définitions nominales.) des tests fonctionnels).

Au quotidien

Chaque journée de travail commence par une réunion de 15 minutes ( Forme première d'un document : Droit : une minute est l'original d'un acte. Cartographie géologique ; la minute de terrain...) maximum appelée 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). Le ScrumMaster pose 3 questions à chaque équipier, à tour de rôle :

  • Qu'est-ce que tu as fait hier ?
  • Qu'est-ce que tu vas faire aujourd'hui ?
  • Quelles difficultés as-tu rencontrées ?

Le tour de parole (La parole, c'est du langage incarné. Autrement dit c'est l'acte d'un sujet. Si le langage renvoie à la notion de code, la parole renvoie à celle de...) 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.

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é de son environnement (L'environnement est tout ce qui nous entoure. C'est l'ensemble des éléments naturels et artificiels au sein duquel se déroule la vie humaine. Avec les enjeux écologiques actuels, le terme environnement tend actuellement à prendre une...). 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. 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

A 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 (En mathématiques, une démonstration permet d'établir une proposition à partir de propositions initiales, ou précédemment démontrées à partir de propositions...) 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 (En France, ce nom désigne un médecin, un pharmacien ou un chirurgien-dentiste, à la fois en activité et en formation à l'hôpital ou en cabinet pendant une...) à 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 (Le SNLE Vigilant (S30) de la Royal Navy est le 3eme des 4 sous-marin de la classe Vanguard.) à 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 (En mathématiques et en logique, une variable est représentée par un symbole. Elle est utilisée pour marquer un rôle dans une formule, un...) 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é (Le terme d'activité peut désigner une profession.).

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 (Un cahier des charges est un document visant à définir exhaustivement les spécifications de base d'un produit ou d'un service à réaliser. Outre les...). 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 (En informatique, on appelle identifiants (également appelé parfois en anglais login) les informations permettant à une personne de...) 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

Vue synthétique du processus Scrum
Vue synthétique du processus Scrum

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 échances futures.

Sprint Burndown Chart

Exemple de Sprint Burndown Chart
Exemple de Sprint Burndown Chart

Ce graphique représente la quantité (La quantité est un terme générique de la métrologie (compte, montant) ; un scalaire, vecteur, nombre d’objets ou d’une autre manière de dénommer la valeur d’une collection ou un groupe de choses.) 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

Exemple de Release Burndown Chart
Exemple de 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 (En géométrie, le mot courbe, ou ligne courbe désigne certains sous-ensembles du plan, de l'espace usuels. Par exemple, les droites, les segments, les lignes polygonales et les cercles...) 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 passé est d'abord un concept lié au temps : il est constitué de l'ensemble des configurations successives du monde et s'oppose au futur sur une échelle des temps centrée sur le présent. L'intuition du...) 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érais, 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 la criticité des fonctionnalités à développer. Ces décisions importantes relèvent complètement du directeur de produit.

Une dernière chose importante : la fiabilité (Un système est fiable lorsque la probabilité de remplir sa mission sur une durée donnée correspond à celle spécifiée dans le cahier des charges.) 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 (Tableau peut avoir plusieurs sens suivant le contexte employé :) blanc (Le blanc est la couleur d'un corps chauffé à environ 5 000 °C (voir l'article Corps noir). C'est la sensation visuelle obtenue avec un spectre lumineux continu, d'où...) et/ou en liège
  • Un bon outil (Un outil est un objet finalisé utilisé par un être vivant dans le but d'augmenter son efficacité naturelle dans l'action. Cette augmentation se traduit par la simplification des actions...) 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 (La Sereine est un cotre bermudien de 12,50 mètrès dessiné par le charpentier de marine Henri Dervin et lancé en 1952 en Bretagne. Propriété des Glénans, elle est...) et efficace

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 (Le mot utilitaire peut désigner :).

Produire de la documentation, c'est souvent utile, mais c'est aussi souvent inutile. En plus, il faut la maintenir à jour (Le jour ou la journée est l'intervalle qui sépare le lever du coucher du Soleil ; c'est la période entre deux nuits, pendant laquelle les rayons du Soleil éclairent le ciel. Son...), et c'est quelque chose qui est rarement fait sur le terrain. Pour savoir s'il faut rédiger un document (Dans son acception courante un document est généralement défini comme le support physique d'une information.), 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...), associé au backlog de produit : uniquement si la logique (La logique (du grec logikê, dérivé de logos (λόγος), terme inventé par Xénocrate signifiant à la fois raison, langage, et raisonnement) est...) métier du client qui concerne l'application est vraiment complexe. Dans ce cas, l'équipe devrait produire ce document avec lui.
  • Diagramme (Un diagramme est une représentation visuelle simplifiée et structurée des concepts, des idées, des constructions, des relations, des données statistiques, de l'anatomie etc. employé dans...) 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 (L’architecture peut se définir comme l’art de bâtir des édifices.) 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 (La vidéo regroupe l'ensemble des techniques, technologie, permettant l'enregistrement ainsi que la restitution d'images animées, accompagnées ou non de son, sur un support...) de démonstrations commentées est une solution efficace.
  • Les FAQ pour la hotline : 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 de la hotline, 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 (Le panel est un groupe de personnes interrogées régulièrement sur leurs opinions ou leurs attitudes. Les personnes peuvent participer aux enquêtes par courrier, téléphone ou, de plus en plus souvent, via un...) des possibilités.

Papier (Le papier (du latin papyrus) est une matière fabriquée à partir de fibres cellulosiques végétales et animales. Il se présente sous forme de feuilles minces et est...) 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 (Une mise à jour, souvent abrégé en MAJ ou MàJ, est l'action qui consiste à mettre « à jour », ou bien « à niveau », un outil informatique, un...) des données (Dans les technologies de l'information (TI), une donnée est une description élémentaire, souvent codée, d'une chose, d'une transaction d'affaire, d'un événement, etc.) est simplement un peu moins agréable.

Outils libres

Outils propriétaires

Autres outils

Voir les ressources AgileAlliance.

Conclusion

Scrum

Scrum est un processus de développement de logiciels qui s'intéresse plutôt à l'organisation (Une organisation est) du projet qu'aux aspects techniques. Son cadre de travail est sa force (Le mot force peut désigner un pouvoir mécanique sur les choses, et aussi, métaphoriquement, un pouvoir de la volonté ou encore une vertu morale « cardinale » équivalent au courage (cf. les articles...), si bien que cette méthode pourraît être appliquée à d'autres domaines. Son approche itérative 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.

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 (Un commercial (une commerciale) est une personne dont le métier est lié à la vente.) à 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 faire admettre aux organes décideurs 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 (Un budget est un document comptable prévisionnel distinguant les recettes et les dépenses.) 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 (En mathématiques, la différente est définie en théorie algébrique des nombres pour mesurer l'éventuel défaut de dualité d'une application...) 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.
ScrumMaster 
Membre de l'équipe dont l'objectif principal est de la protéger des perturbation 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 (Le facilitateur peut être utile dans diverses situations telles que de face à face, au sein d'un réseau professionnel par exemple de type...) 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.
Scrum 
Réunion quotidienne de 15 minutes, qui a pour but de faire le point sur ce qui a été fait depuis le dernier Scrum, ce qui est prévu de faire jusqu'au prochain 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.
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).
Source: Wikipédia publiée sous licence CC-BY-SA 3.0.

Vous pouvez soumettre une modification à cette définition sur cette page. La liste des auteurs de cet article est disponible ici.