Ma compréhension de SCRUM: le déroulement d'un projet

Dans mon billet précédent, j'ai présenté les fondamentaux du framework SCRUM. Aujourd'hui, je continue sur les aspects théoriques avec le déroulement d'un projet SCRUM.

Comment se déroule un projet SCRUM?

Dans les grandes lignes, un projet SCRUM se déroule en 5 étapes que je détaillerais dans la suite du billet:

1. Etape 1: la Réunion de Planification de version ou Sprint 0,
2. Etape 2: la Réunion de Planification du Sprint,
3. Etape 3: le Sprint, cette étape ainsi que la précédente sont itératives. Elles peuvent donc être reproduites N fois jusqu'à la décision par le PO de terminer le produit.
4. Etape 4: la Revue de Sprint,
5. Etape 5: La Rétrospective.

Le schéma ci-dessous résume, visuellement, ces 5 étapes.

Que fait-on pendant pendant la Réunion de Planification de version (Sprint 0) et qui sont les acteurs présents ?

Dans la réalité, avant la réalisation d'un projet SCRUM, il faut commencer, comme pour un projet traditionnel, par une analyse plutôt high level des besoins. La Réunion de Planification de version peut alors avoir lieu. L'objectif de celle-ci est d'élaborer le backlog initial et planifier la release. Pour cela on mettra en œuvre des pratiques comme la vision du produit, la priorisation du Backlog, l'identification des risques, la décomposition en user stories, l'estimation de l'effort en points, la définition de fini et de la durée des itérations, le planning de la release, la formation de l'équipe (s'il y a lieu), l'organisation de l'espace de travail. Pour chaque User Story, on devrait pouvoir calculer un ratio Valeur Business de la US / Effort qui est le ROI.

Que fait-on pendant pendant la Réunion de Planification du Sprint et qui sont les acteurs présents ?

Une fois le Backlog initial élaboré, la Planification du Sprint peut alors commencer. L'équipe sous la Direction du SM (Direction dans le sens orientation) choisit les US qui ont les ROI les plus élevés comme premières à réaliser dans le premier Sprint. Une fois ce que l'équipe a accumulée une somme d'effort qu'elle est capable de fournir pendant la durée d'un Sprint, elle positionne les autres US dans les Sprints suivants. L'équipe construit alors le Sprint Backlog qui représente l'ensemble des fonctionnalités à réaliser pendant le Sprint. Chaque US est alors découpée en tâches techniques élémentaires qui seront à leur tour estimée. L'élaboration de cet artefact est le principal objectif de cette Réunion. Le PO peut y assister à titre consultatif.

Comment se déroule un Sprint ?

Le Sprint est l'étape de réalisation du projet SCRUM par excellence. Il peut durer de 2 semaines à 2 mois en fonction du contexte de projet et de sa complexité. Ceci dit il faut bien garder à l'esprit que le principe est de livrer à la fin du Sprint une première version du logiciel qui fonctionne incluant l'ensemble des fonctionnalités contenues dans le Sprint Backlog. Pendant le Sprint, tous les matins (de préférence), pendant 15 mins maximum, un Daily Scrum Meeting a lieu pour voir l'état d'avancement des tâches. Chacun doit répondre à trois questions: quelles sont la(les) tâche(s) terminée(s) la veille s'il y en a ? quelles sont la(les) tâche(s) du jour ? quels problèmes ont été rencontrés ? En cas de problème, le SM doit mettre en oeuvre des actions pour les résoudre au plus vite. Pendant toute la durée du Sprint, les résponsabilités suivantes sont attribuées:

• le SM doit garantir que l'équipe n'est pas perturbée par des sollicitations extérieures. Il doit aussi garantir qu'elle a sa disposition tous les moyens pour travailler et faire avancer les différentes tâches.
• le reste de l'équipe réalise concrètement chacune des tâches qu'il a indiqué effectuer pendant le Daily Scrum Meeting.

A quoi sert la Revue de Sprint et qui sont les acteurs présents ?

La Revue de Sprint sert principallement à faire une démonstration du produit réalisé pendant le Sprint. Ceci même si le produit n'impémente pas toutes les fonctionnalités ciblées dans le Product Backlog. En ce basant sur ce dernier comme support, l'objectif est de montrer les fonctionnalités terminées à 100%, les fameuses User Stories afin de déterminer celles qui sont achevées. Dans l'idéal, c'est au PO de faire cette démonstration mais n'importe quel membre de l'équipe pourra la faire. Dans tous les cas, l'équipe doit être présente afin d'écouter, en direct, les remontées de l'assistance et d'intéragir avec elle. Il faudra veiller à bien préparer la démonstration avant que le public n'arrive. Ceci afin d'éviter les temps d'attente trop long avant le début de la démonstration. Celle-ci est destinée à un public parfois extérieur au projet, il faudra donc bien expliquer son contexte, celui de la démonstration, les données utilisées (données les plus explicites possibles), les fonctionnalités implémentées, etc... En cas de bug ou de problème lors de la démonstration, il faut le dire explicitement, éviter les "ça marchait il y a 10 minutes". La transparence est une valeur importante de la Revue de Sprint. Elle permet aussi de voir les fonctionnalités qui marchent bien et celle qu'il faudra revoir pendant le Sprint suivant ou tout simplement abandonner à l'initiative du PO.

A quoi sert la Retrospective et qui sont les acteurs présents ?

A la fin du Sprint, l'équipe dans son ensemble se réunit avec les développeurs, le SM, le PO et même le client. Cette réunion permet de faire un point sur le Sprint qui vient de se dérouler dans sa globalité. Les éléments suivants sont discutés:

• ce qui s'est bien passé pendant le Sprint,
• ce qui ne n'est pas bien passé et qu'il faudra améliorer:mettre en place un plan d'actions à la charge de l'équipe à suivre pour cette amélioration,
• ce qui reste de l'ordre de l'inconnu.

Cette réunion est un axe d'amélioration important pour l'équipe toujours dans le but de satisfaire au mieux, non seulement, les exigences du client mais aussi le travail de l'équipe elle-même.