SCRUM

SCRUM (mélée en Anglais) est une méthode AGILE dédiée à la gestion de projets informatiques. SCRUM fait partie des méthodes dites incrémentales, et appuie son découpage sur des sprints, périodes intenses de conception d'une durée maximale d'1 mois.

Chaque équipe de projet est composée :

d’un “product owner” qui est responsable du projet. Il définit le besoin ;
d’un “scrum master” qui a pour rôle de vérifier que la méthode de gestion de projet est correctement appliquée. Il a un rôle de « coach » ;
de plusieurs “team member” chargés de transformer le besoin exprimé par le “product owner” en fonctionnalités utilisables.

Un projet est composé de plusieurs “sprints” au terme desquels une ou plusieurs fonctionnalités (correspondants à une ou plusieurs tâches) doivent être livrables.

A chaque nouveau sprint, la séance débute obligatoirement par une réunion appelée “revue de sprint” (sprint review) pour faire le point par rapport au sprint précédent. Au cours de chaque sprint, une ou plusieurs autres réunions, appelées “mêlées” seront lancées par le “scrum master” de façon aléatoire.

Une mêlée est une réunion très importante qui se fait debout pour éviter de s’éterniser. Elle permet aux membres de l’équipe de se synchroniser, de remonter les obstacles rencontrés, de s’entraider et de vérifier l’avancement du sprint. Au cours de chaque mêlée, chaque “team member” répond à 3 questions :

Qu’ai-je terminé depuis la dernière mêlée ?
Qu’est ce que je vais terminer d’ici la prochaine mêlée ?
Quelles difficultés je rencontre ou je pense rencontrer ?

Une première planification de projet se fait durant le premier sprint appelé “sprint 0”. Il est dédié aux travaux préparatoires et permet d’établir un tableau de tâches appelé “product backlog” qui pourra évoluer tout au long du projet. L’estimation de la durée de chaque tâche s’effectue via un “planning poker”.

Les sprints suivants sont précédés de 15 minutes de revue de sprint permettant un recadrage et une ré-évaluation du “product backlog”.

L'ensemble du travail à réaliser est découpé fonctionnellement en user story (histoire d'utilisateur).

Une user story correspond à la réalisation d'une fonctionnalité pour 1 utilisateur.

La formulation d'une User story peut utiliser la matrice Rôle-Fonctionnalité-Bénéfice :

En tant que <rôle>
Je veux que <fonctionnalité>
Afin de <bénéfice>

Par exemple:

En tant que client de la banque
Je veux retirer de l'argent à un guichet automatique
Afin de ne me soucier ni des horaires d'ouverture ni de l'affluence en agence

Cette formulation permet d'équilibrer les préoccupations: non pas seulement ce que le logiciel doit faire, mais également pour qui et afin de satisfaire quel objectif de la personne en question.

Les user stories sont établies suivant un mode oral et collaboratif, avec le client.

La validité d'une user story et sa qualité peuvent être estimés au travers de la matrice INVEST

Liens :