La méthodologie Scrum

Après vous avoir présenté l'agilité dans l'article "Agilité/agile késako ?", je vous présente aujourd'hui la méthodologie Scrum pour laquelle je suis certifiée.

Scrum ne se définit pas comme étant une méthode mais plutôt un cadre de travail.

Une méthode dit généralement « comment » faire les choses, or Scrum ne dit pas comment surmonter les obstacles, comment développer, comment spécifier, etc. Il offre un cadre composé de rôles, d'événements, d'artéfacts et de règles associées.

Le terme "artefacts" est souvent difficile à maîtriser, nous pouvons dire que se sont des objets que nous créons, comme un outil pour résoudre un problème.

Scrum repose sur 3 piliers :

• Transparence

L’équipe Scrum et les parties prenantes doivent avoir accès et partager les informations en se basant sur un langage et des définitions communs. La transparence fait aussi référence à des valeurs comme le courage : courage de dire les choses difficiles, reconnaître et apprendre de ses erreurs, savoir dire non…

• Inspection

L’équipe Scrum doit se consulter régulièrement pour détecter rapidement d’éventuels écarts entre l’objectif du sprint et le travail réalisé.

• Adaptation

Si des écarts sont constatés lors d'une phase d'inspection, un ajustement doit être entrepris au plus vite afin d’atteindre les objectifs du Sprint.

Nous verrons un peu plus loin 4 événements formels d'inspection et d'adaptation.

Scrum est fondée sur les 5 valeurs suivantes :

L'équipe Scrum

L'équipe Scrum est constituée de 3 rôles :

• un Product Owner

• une Development Team

• un Scrum Master.

Ils se réunissent autour de différents événements.

L'équipe Scrum est :

• auto-organisée, elle prend donc les décisions sur la manière dont le travail sera réalisé pour atteindre l’objectif du sprint.

• non hiérarchisée, c’est-à-dire qu'il n'y a pas de chef qui dirige les membres de l'équipe.

• pluridisciplinaire de manière à posséder toutes les compétences requises à la réalisation des tâches.

Product Owner [PO]

Le Product Owner est responsable de la partie fonctionnelle, il est responsable du « QUOI » faire ?

Mais afin de bien comprendre et transmettre, communiquer le « QUOI », le PO doit également bien maîtriser le « POURQUOI », la raison pour laquelle on doit faire chaque chose.

Il est :

• garant du produit, il a la charge d'en maximiser sa valeur

• seul responsable de la gestion du Product Backlog

Chez CreativMinds, en tant que Business Analyst, nous pouvons officier en tant que PO.

Development Team [DT]

L'équipe de développement est composée idéalement de 3 à 9 personnes. Suffisamment grande pour avoir un maximum de compétences et suffisamment petite pour ne pas perdre trop de temps en coordination.

Elle s'occupe du « COMMENT » faire (choix techniques, qualité du code, etc. ), elle s'organise et gère son travail comme elle le souhaite.

Scrum Master [SM]

Le Scrum Master est un facilitateur. Il aide tout le monde à comprendre la théorie, les pratiques, les règles et les valeurs de Scrum.

Le Scrum Master doit :

• faciliter le processus

• être au service de l'équipe Scrum pour maximiser la valeur créée par celle-ci

• lever les obstacles

• protéger l’équipe des perturbations extérieures

• être le garant du temps lors des événements Scrum.

Il ne fait généralement pas partie de l'équipe de développement, il n'est pas là pour produire, il est là pour accompagner l'équipe.

Les événements Scrum

Tous les événements sont limités dans le temps à une durée maximale. Si la durée du Sprint ne peut être modifiée à partir du moment ou celui-ci a démarré, les autres événements peuvent se terminer dès que leurs objectifs sont atteints.

Chaque événement Scrum est une occasion formelle d'inspecter et d'adapter. Ces événements sont spécifiquement conçus pour permettre la transparence et l'inspection.

Le Sprint

Le Sprint est le cœur de Scrum, il a une durée d'un mois ou moins, au cours de laquelle un Incrément publiable du produit est créé. Publiable ne veut pas nécessairement dire mettre en production, le produit délivré est au moins utilisable.

Un nouveau Sprint commence dès la conclusion du Sprint précédent.

L'objectif du Sprint est fixe. Le périmètre peut-être clarifié et négocié entre le PO et la DT, mais les changements qui remettent en cause l'objectif du Sprint ne sont pas permis.

Seul le PO a le pouvoir d'annuler un Sprint avant son échéance. Cette action étant bouleversante pour l'équipe et chronophage, les annulations sont très rares.

Le Sprint est le conteneur pour tous les autres événements Scrum.

Sprint planning

Chaque Sprint démarre avec un Sprint Planning lors duquel l'équipe doit déterminer le travail à effectuer pendant le Sprint.

L'équipe :

• détermine l'objectif du Sprint (Sprint Goal)

• sélectionne les éléments du Product Backlog permettant d'atteindre l'objectif

• détermine comment atteindre cet objectif en élaborant un plan à partir des éléments sélectionnés

Le Sprint Planning à une durée maximum de 8h (2h pour un Sprint d'1 semaine), et l'équipe Scrum au complet y participe (PO, DT, SM).

Les éléments nécessaires pour le démarrage de la séance sont le Product Backlog, le dernier incrément du produit, la capacité projetée par la DT pendant le script et les performances passées de la DT.

Daily Scrum

Le Daily Scrum d'une durée maximum de 15 mn est destiné à la DT uniquement, tous les jours du Sprint.

L'équipe planifie le travail pour les 24h à venir.

En général chaque membre de l'équipe indique ce qu'il a fait depuis le dernier Daily Scrum, ce qu'il compte faire et surtout s'il a rencontré des difficultés.