[Total : 1    Moyenne : 5/5]

La méthode SCRUM, la plus connue et la plus utilisée des méthodes Agile, propose une gestion pragmatique et efficace des projets.

Introduction

Le SCRUM est la principale méthode Agile. La première trace de la méthode SCRUM, nous la retrouvons en 19861 par Hirotaka Takeuchi et Ikujiro Nonaka. Leur objectif était d’apporter une nouvelle approche de management de projets, en considérant un projet comme une unité et non une multitude de tâches individuelles.

Ils ont tiré le terme SCRUM, traduit par “mêlée“, pour mettre en avant la nécessité d’avoir une équipe soudée vers un même objectif pour assurer l’obtention des résultats.

Une première standardisation de la méthode sera proposée en 19902. Mais, ce sera au cours des années 90, avec en particulier Jeff Sutherland, Ken Schwaber et Mike Beedle, que la méthode se déploiera dans les principales sociétés IT (Microsoft, Google, Yahoo…).

Pour faire un parallèle le Lean, le mode de gestion de projets SCRUM a nombre de similitudes avec les projets Lean. On retiendra 2 éléments que nous apprécions tout particulièrement que nous pourrions rajouter dans les standards de gestion de projets Lean :

  • Le meeting de rétrospective obligatoire.
  • La systématisation des itérations et des validations des Backlog.

La SCRUM Team

La méthode SCRUM repose sur une équipe dédiée, proche du concept d’Unité Autonome de Production. La SCRUM Team est autonome pour effectuer toutes les actions, prendre les décisions et est dédiée à temps plein temps sur un projet. La SCRUM Team travaille dans le même bureau avec l’ensemble des données du projet affiché sur les murs au même titre que l’Obeya.

Le Product Owner

C’est parfois le client lui-même, mais le plus souvent, il s’agit du chef de projet interne en charge de reporter au client. C’est lui qui fixe les besoins pour le mois à venir. C’est lui qui a la vision du produit, qui gère le Backlog, priorise les actions et valide les résultats. Il est disponible pour l’équipe, présent à de nombreux meetings)et est facilitateur au même titre que le Scrum Master. En terme Lean, cette fonction est à mettre en correspondance avec le Pilote ou le Sponsor.

Le Scrum Master

Il a le rôle de facilitateur et s’assure que le projet se déroule correctement. Il réduit au maximum les perturbations possibles et lève les barrières. En terme Lean, il s’apparente au Lean LeaderLean Practitioner ou Lean Expert.

La Scrum team

Ce sont eux qui font les différentes tâches et qui reporte au Product Owner. De 5 à 9 personnes, ils donnent leurs accords sur les objectifs de chaque itérations. Ils sont dédiés à temps plein au projet et ont des compétences cross-fonctionnelles leur permettant d’être autonome. A noter que les membres ne peuvent changer qu’au moment d’un changement de Sprint.

La structure SCRUM

Tout projet peut être piloté par la méthode SCRUM. Le travail réalisé par des équipes autonomes, s’effectue au travers de cycles courts appelés SPRINT. Au sein d’un Sprint, l’équipe réalise les Story Point du Backlog (ce que le client attend).

1 – Product Backlog

Les besoins sont gérés sous forme de Product Backlog. Il s’agit de la liste des besoins que l’on appelle le plus généralement Story Point. Les caractéristiques sont les suivantes :

  • Ils sont tous en lien avec un besoin exprimé du client.
  • Ils sont tous quantifiés au niveau de leur importance vis-à-vis de l’attente du client.
  • Ils sont facilement compréhensible et modifiable.
  • Un ou plusieurs critères d’acceptation sont identifiés pour chacun.

Dans le développement de logiciel, le Product Backlog se compose :

  • Des User Stories : les fonctions du logiciel
  • Les Technical Stories : les améliorations techniques et autres contraintes spécifiques.

C’est le Product Owner qui priorise les éléments du Backlog en fonction de la valeur ajoutée de chacun.

2 – Sprint planning

Il s’agit de la session en début de chaque Sprint où l’on va identifier, estimer, prioriser et composer le Backlog du sprint à venir (Attention, les dates des Sprints Planning sont identifiés en début de projet pour faciliter l’organisation générale). Ce meeting est animé par le Product Owner, et nécessite la présence de la Scrum Team et du ScrumMaster. Il peut durer une journée complète.

L’enjeu : s’engager sur les « Stories » qui devront être réalisées pendant le prochain sprint, en prenant en compte les capacités de l’équipe et les contraintes diverses (technique, vacance…).

Le processus est le suivant :

  1. Le ScrumMaster introduit l’équipe et le rôle de chacun.
  2. Le Product Owner propose les objectifs du prochain sprint, ce qu’il voudrait voir être accompli. Il précisera le pourquoi des priorités. Il s’appuiera sur la Vélocité pour identifier la quantité de travail possible.
  3. Le Product Owner revoit avec l’équipe le Product Backlog et détaille les Stories.
  4. Un échange a lieu pour détailler tous les points : périmètre…
  5. Une fois les Story Point identifiées, on les passe du Product Backlog à la phase “Plan” du Tableau Kanban.

3 – Les Sprints Backlog

Les Sprint Backlog, résultant des sprints planning, contiennent la liste des Stories à réaliser pendant le sprint.

En fonction des résultats des Daily meeting, le sprint Backlog pourra être ré-estimé en fonction des nouvelles informations.

4 – Estimating meeting

L’estimating meeting se déroule dans la foulée du Sprint planning (si possible dans la même journée pour s’assurer de la présence du Product Owner). Sa durée est d’environ 2hr. La Scrum Team va travailler ensemble, en s’appuyant sur le Planning Poker Card et le Wall Planning Poker, pour :

  1. Détailler et découper les Stories en tâches à réaliser (Story Point).
  2. Estimer les délais de réalisation de chacune des Story Point.

 

Pour faire ces estimations, l’équipe devra avoir les compétences et capacités nécessaire pour y répondre. Car les estimations seront confrontés à la demande du client pour validation. S’il y a des Gaps, le ScrumMaster devra négocier avec le Product Owner pour revoir les délais du client ou demander de nouvelles ressources.

5 – Les sprints

La méthode SCRUM propose de faire progresser les projets via une série de « Sprint ». Le sprints sont d’une durée identique, de 2 à 6 semaines. On ne peut clôturer un sprint que si toutes les actions sont réalisé et validé. A noter qu’aucun changement important dans le projet ne peut intervenir lors d’un sprint.

6 – Daily Meeting

La méthode repose sur une mise à jour très réactive des données permettant d’améliorer la communication dans les projets. Pour cela, elle propose la mise en place de réunion quotidienne, les Daily Meeting, permettant de faire le point sur les avancées et les problèmes. On notera que les autres acteurs du projet peuvent y participer et intervenir pour apporter des changements vis-à-vis du besoin, du contexte…

Comme son nom l’indique, la réunion a lieu tous les jours avec toute l’équipe et dure environ 15 mn. Elle repose sur 3 questions :

  • Qu’as-tu fait hier ?
  • Que vas-tu faire aujourd’hui ?
  • Rencontres-tu des obstacles ?

 

En fonction des réponses, si des problèmes sont avérés, on devra remettre à plus tard ou revoir la définition de certaines Stories.

L’ensemble des indicateurs sont mis jour lors de ce meeting : Burn Down Chart, Vélocité, Kanban.

7 – Sprint Review Démo

A la fin de chaque Sprint, la Scrum Team (tous présent) présente les résultats réels (pas de powerpoint) des résultats au Product Owner. Ce meeting ouvert à tous et d’une durée de 4hr, est le moment où l’on valide les Stories et que l’on compare les résultats avec les objectifs du Sprint.

On pourra calculer la Vélocité* du sprint (somme des Storie Point que l’on a accepté), et calculer une Vélocité moyenne nous permettant de planifier plus facilement.

On met à jour le tableau Kanban et le Product Backlog. Les résultats doivent être affichés, visibles et compréhensibles par tous.

*Pour améliorer artificiellement la Vélocité, une pratique consiste alors à accumuler de la dette technique : cela consiste à prendre des raccourcis pour gagner du temps (typiquement faire des copier-coller de code informatique), mais par conséquent générant des problèmes qui seront alors traités ou non… ultérieurement.

8 – Sprint Review Retrospective

Réserver à l’équipe et d’une durée de 4 heures, il s’agit d’une introspection vis-à-vis du déroulement de chaque sprint (les + et les -). Planifié en début de projet, il y en a un à la fin de chaque Sprint. L’enjeu est ici d’identifier des améliorations possibles pour optimiser le sprint suivant. C’est le ScrumMaster qui anime cette réunion.

Chaque élément remonté est discuté et commenté en équipe jusqu’à obtenir le consensus. Si des actions sont identifiées (formation…), un pilote avec un délai et un livrable doivent être identifiés.

Les supports

Le tableau d’avancement

C’est sur ce tableau visuel que l’on retrouve l’ensemble des avancées du projet. Les User Story sont mises sur des post-it et positionnées sous forme de Kanban dont voici un exemple :

Le burn down chart

Le burn down chart représente, sous forme de graphique, l’évolution du nombre de story dans le temps. Il existe 2 types de Burndown :

  • Le burndown de product backlog : dans ce cas le nombre de story initial est celui du projet.
  • Le burndown de sprint backlog : dans ce cas le nombre de story initial est celui du sprint.

On retiendra la vélocité (la pente de la courbe du Product Backlog) comme étant le principal indicateur de l’agilité.

Source

1 – H. Takeuchi, I. Nonaka (1986) – The new new product development game

2 – P. De Grace, L. Hulet Stahl (1990) – Wicked problem, righteous solutions : a catalog of modern engineering paradigms

3 – http://agilemanifesto.org

Share This