SCRUM A LA LOUPE

Après avoir posé les bases et détaillé les fondements de Scrum, attardons-nous davantage sur ses rituels. Scrum est composé de certains éléments indéfectibles de cette approche :

  • 3 rôles principaux 
    • Le Product Owner
    • Le Scrum Master
    • La Dev Team
  • 5 événements
    • Le Sprint Planning
    • Le Sprint
    • Les Daily Scrum
    • Le Sprint Review (Delivery)
    • La Sprint Retrospective
  • 3 “artefacts”:
    • Le Product Backlog
    • Le Sprint Backlog
    • L’Increment

La Scrum Team

  • Le Product Owner (PO) Il porte la vision du produit à concevoir. Il apporte sa connaissance du marché et les besoins des utilisateurs. C’est lui qui rédige et maintient à jour le Product Backlog qui recense toutes les fonctionnalités du produit.
  • Le Scrum Master (SM) Il n’est pas toujours présent dans les équipes Scrum, le Product Owner portant parfois cette casquette. Il est garant du framework, veille à ce que les différents évènements de Scrum ai bien lieu dans les temps. Il a également un rôle de facilitateur.
  • La dev team : l’équipe de développeurs. Ils sont un groupe de 5 à 10 “faiseurs” qui développe le produit.

 

Ils interviennent aussi :

  • Les stakeholders / les parties-prenantes Il s’agit du client et/ou des usagers du produit qui est développé. Ils interviennent lors de certains événements ou via l’intermédiaire du Product Owner.
  • L’UX designer C’est une tendance que l’on observe de plus en plus : l’intégration d’un UX design dans une équipe Scrum fait un bon duo avec le Product Owner et permet de garder l’utilisateur au centre du processus de création.

Dans une Scrum Team il n’y a pas d’hiérarchie, chacun est l’égal de l’autre, les décisions sont collégiales. L’équipe est auto-organisée et pluridisciplinaire.

 

Scrum à la loupe

Tout commence du Product Backlog

Tout débute par le premier artefact : le Product Backlog.
Il s’agit un document écrit contenant toutes les fonctionnalités, les besoins et améliorations liés au produit. Il est rédigé et mis à jour par le Product Owner.

Les fonctionnalités sont écrites sous forme de parcours utilisateur : des User Stories.

Exemple pour une application de VTC : “En tant que client je souhaite être localisé sur un plan afin de ne pas avoir à renseigner l’adresse de ma position.”

Le 1er rituel : le Sprint Planning pour préparer le sprint

L’équipe se réunie lors du Sprint Planning pour sélectionner les User Stories (US) qui seront développées lors du Sprint. Comme tous les événements de Scrum, le Sprint Planning a une “timebox”, c’est-à-dire une durée maximale. Pour lui, la durée maximale est de 8h (pour un sprint de 4 semaines).

À la fin du Sprint Planning, chaque User Story doit être claire et estimée et les membres de la dev team doivent savoir quel plan d’action mettre en place pour accomplir le Sprint Goal (l’objectif du sprint).

Comment sont estimées les User Stories ?
Pour estimer une User Story, les membres de l’équipe organisent un Planning Poker, il s’agit d’un jeu de cartes qui permet à chacun de voter et d’estimer l’effort à fournir pour la réaliser.
Exemple : une tâche très facile mais qui va être longue à faire n’équivaut pas en points à une tâche très facile et rapide à faire.

Les User Stories sélectionnées pour le sprint forment le Sprint Backlog.

Des User-Stories à l’Incrément : le Sprint

L’objectif d’un Sprint est de développer une pièce fonctionnelle du produit à réaliser : un Incrément.
C’est à l’équipe de définir sa durée qui ne doit pas dépasser 4 semaines. Quand un sprint se termine, un nouveau commencera.

Chaque jour du sprint l’équipe se retrouve lors des mêlées quotidiennes : les Daily Scrum.
Généralement en début de journée et d’une durée de 15 minutes, l’objectif est de renforcer la transparence et la réactivité de l’équipe. Chacun partage ses actions du jour ainsi que les difficultés qu’il rencontre ou que le projet rencontre. L’équipe peut donc s’ajuster et mettre en place des plans d’action.

 

Livrer, tester, ajuster : la Sprint Review

À la fin du Sprint, une Sprint Review est organisée, on parle aussi de phase de Delivery. D’une durée de 4 heures maximum, elle réunit l’équipe Scrum et les parties-prenantes (le client) et/ou des usagers.

Une démonstration de l’incrément développé est faite. L’équipe Scrum récupère alors de précieux feedbacks qui seront ajoutés au Product Backlog. C’est aussi souvent l’occasion de déceler des bugs, qui seront corrigés lors d’un prochain Sprint.

C’est un moment important car c’est la rencontre entre ceux qui font et ceux qui utilisent. L’équipe Scrum comprend pour qui et pourquoi elle travaille et les utilisateurs se sentent écoutés et impliqués dans le processus de création.

S’analyser soi-même : la rétrospective de sprint

Dernier évènement : la Sprint Retrospective
C’est un rendez-vous d’1 heure qui permet à l’équipe Scrum de s’analyser en mettant en lumière ce qui à fonctionné durant le Sprint, ce qui n’a pas fonctionné et de mettre en place un plan d’amélioration continue avec des actions concrètes.

25 septembre 2019
top

Tous droits réservés.