Gestion de Projet - Framework SCRUM

Epharos

Je suis à peu près certain que vous avez déjà lancé ou participé à un projet de mod ou serveur moddé qui n’a jamais abouti. Les raisons de cet échec sont souvent diverses et variées, manque de motivation, manque d’organisation, … Pour palier à la majorité desdites raisons, il convient de mettre en place une méthode de gestion de projet. Il en existe des dizaines, mais nous nous concentrerons ici sur le framework SCRUM.

Avant d’entrer dans le vif du sujet, je tenais à rappeler que ce tutoriel n’a pas pour but de vous apprendre à lancer un projet (cahier des charges, recrutement, …), mais à le maintenir, à maintenir votre équipe productive et faire en sorte que votre projet aboutisse.

Introduction au Framework SCRUM

Le framework (ou cadre en français) SCRUM (mêlée en français) a été présenté pour la première fois en 1995 puis mis à l’écrit en 2001. Il fait partie des méthodes dites “AGILE” (2001).

Au cours de ce tutoriel nous allons voir les 3 éléments principaux du framework (les rôles, les évènements et les artefacts) sous forme théorique, puis nous verrons un cas concret fictif.

Les éléments de SCRUM

Les rôles

Dans le framework SCRUM on différencie trois rôles :

Le Product Owner (Propriétaire du Produit en français)

Il est généralement le client du projet, c’est lui qui a passé commande auprès de votre équipe. Dans le cadre d’un projet de serveur moddé, le Product Owner est généralement le propriétaire du serveur (ou son gestionnaire). Il rédige le Product Backlog, que nous aborderons plus tard.

L’équipe de développement

Ce sont toutes les personnes qui contribuent au développement du projet, qu’ils soient développeurs, graphistes, musiciens, … Ils transforment les idées du Product Owner en fonctionnalités utilisables. La taille idéale pour l’équipe de développement se situe entre 3 et 9 membres.

Le Scrum Master (Maître de Mêlée en français)

Son objectif est de faciliter la communication au sein de l’équipe de développement. Il est également le pont qui relie l’équipe de développement avec le Product Owner. Il doit bien maîtriser le framework ainsi qu’avoir des connaissances dans chaque domaine exploité par l’équipe de développement. Il est un peu le “chef d’équipe” mais il ne dirige pas l’équipe, il l’accompagne et vérifie que toutes les règles de SCRUM sont respectées.

Les évènements

Les sprint

Il s’agit d’une itération durant généralement entre 2 et 4 semaines. Il est vivement déconseillé de dépasser une durée d’un mois. La durée d’un sprint est fixée au début du projet et reste constante jusqu’à la release (c’est-à-dire une fois que tous les objectifs du Product Backlog sont atteints).

Chaque sprint comporte une liste d’objectifs à atteindre d’ici la fin du sprint, ceux-ci étant tirés du Product Backlog. A la fin du sprint, cette liste d’objectifs doit, idéalement, être achevée. Dès qu’un sprint est terminé, un nouveau commence, il n’y a pas de pause entre les deux.

Il y a 3 règles principales lors d’un sprint :
On n’altère pas la qualité du produit, on ne peut pas modifier la liste d’objectifs à réaliser et enfin l’équipe de développement ne change pas au cours d’un sprint.

Ce qui fera de votre équipe une équipe efficace sera le respect des règles énoncées ci-dessus. La rigueur dans un projet en fera sa réussite et sa stabilité (comme on peut le voir, par exemple, avec la rigueur des conventions de développement).

La mêlée quotidienne

Afin de tenir un compte rendu de l’avancement du projet, vous devrez réaliser une mêlée quotidienne. C’est une courte réunion, d’un quart d’heure environ, dans laquelle chacun fait état de ce qu’il a réalisé dans les dernières 24 heures, ce qu’il compte réaliser dans les prochaines 24 heures, et les éventuelles difficultés rencontrées. Il est important d’ailleurs de faire cette réunion tous les jours à la même heure et que tout le monde soit présent. Là encore c’est un travail de rigueur dans l’organisation, et si elle est faite, votre projet avancera correctement.

L’objectif de cette réunion n’est pas de blâmer ceux qui n’ont rien fait dans les 24 heures (et de toute manière le framework SCRUM ne laisse aucune place à une forme de hiérarchie, tout le monde est au même rang), mais de tenir compte du rythme d’avancement sous forme d’un Burndown Chart, que nous aborderons dans les artefacts.

La planification du sprint

Cette réunion (durant environ deux heures par semaine de sprint) doit être réalisée juste avant de commencer un sprint. Elle a pour but de planifier les objectifs à atteindre durant le sprint ainsi qu’une quantité de travail et une vélocité pour chacun d’eux.

Pour estimer une quantité de travail (que je qualifierais plus volontiers de complexité de l’objectif (ou de la tâche)), on utilise généralement les premiers termes de la suite de Fibonacci (à savoir 1, 2, 3, 5, 8 et 13). Ce ne sont aucunement des unités de temps et ça permet de bien estimer la complexité de la tâche sans être ambigüe (par exemple entre 7 et 8).

Vous pouvez également estimer la vélocité du travail, en estimant le temps que vous mettrez à réaliser une tâche. Au premier sprint, cette vélocité est théorique (on pense mettre n heures à réaliser telle tâche), mais à partir du deuxième, cette vélocité doit être estimée selon la vélocité des sprint précédents (finalement j’ai mis n+5 heures à la réaliser, donc j’en tiens compte pour les tâches de même complexité).

La revue du sprint

La revue de sprint dure environ une heure et réunit l’équipe de développement (et le Scrum Master) et le Product Owner. L’équipe de développement présente au Product Owner les fonctionnalités réalisées et terminées durant le sprint (les fonctionnalités non finies ou n’ayant pas passer le test de validation établi dans le Product Backlog ne sont pas présentées).

A la fin de cette revue, le Product Backlog est modifié en conséquence (en enlevant ce qui a été réalisé lors du sprint).

La retrospective du sprint

La rétrospective est théoriquement la continuité de la revue du sprint. Elle met en lumière les point forts de l’équipe de développement et ses points faibles lors du dernier sprint. L’objectif étant que l’équipe de développement prépare alors un plan d’action afin d’être plus efficace lors du sprint arrivant.

Les artefacts

Le Product Backlog (Carnet de produit en français)

Il s’agit de la liste hiérarchisée des besoins du projet. Elle répertorie tous les besoins initiaux du projet et évolue au fur et à mesure que le projet avance. Elle est maintenue par le Product Owner.

Le Sprint Backlog (Carnet de sprint en français)

Il répertorie tous les objectifs à atteindre durant le sprint en cours, avec leur complexité et leur vélocité. Ce carnet est mis à jour quotidiennement par le Scrum Master après la mêlée.

Chaque entrée du carnet ne doit pas dépasser deux jours de travail, dans le cas échéant, on décompose l’entrée en plusieurs entrées.

L’incrément

Il s’agit là de tous les objectifs réalisés lors du sprint en cours et des sprints précédents. Il est maintenu à jour par le Scrum Master.

Le Burndown Chart (Graphique d’avancement en français)

C’est la version graphique du travail effectué et du travail restant pour le sprint en cours. Il se présente sous forme de régression linéaire. Une première droite correspond au rythme de travail idéal et une seconde ligne correspond à l’avancement du sprint en cours. Le Burndown Chart est donc mis à jour quotidiennement par le Scrum Master après la mêlée.

Cas fictif concret

Maintenant que nous avons discuté de la théorie, voyons un cas concret (fictif mais concret).

Voici les participants au projet :

Michel : créateur du serveur FictiCraft, Product Owner
Olivier : développeur, Scrum Master
Camélia : développeuse
Julien : développeur
Ophélie : graphiste
Aurélien : musicien

En premier lieu, Michel, va mettre en place le Product Backlog initial, on va imaginer un PB simple et efficace prenant quelques lignes pour illustrer cet exemple :

Ajouter un bloc “mob catcher” au jeu
Ajouter une recette permettant de crafter ce bloc
L’utilisateur ne peut placer ce bloc que s’il n’y a aucune bloc au dessus
Le bloc attrape les entités hostiles dans les 16 blocs de rayon
Le bloc doit être alimenté en RF et ne fonctionne qu’avec 200RF/tick
Ajouter un item “range upgrade” au jeu
Ajouter une recette permettant de crafter cet item
Le “mob catcher” gagne 2 blocs de rayon par “range upgrade” inséré
En cliquant droit sur le “mob catcher” avec un “range upgrade” en main, le “range upgrade” est inséré dans le “mob catcher”

C’est un PB très court et évidemment le votre sera certainement plus long. D’ailleurs je vous invite à vous renseigner sur les User-Story, qui sont une excellente méthode pour rédiger un PB pour une méthode AGILE (pas forcément SCRUM du coup) et qui sera traité dans un second tutoriel.

Le PB étant établi, tous les participants au projet se mettent d’accord sur la durée du sprint. Le projet étant simple, les sprint seront plus court que dans un projet habituel. Dans notre cas ils décident qu’un sprint durera 1 semaine.

Ceci étant fait, l’équipe de développement (et Olivier qui en fait également partie, même s’il est aussi Scrum Master) font la réunion de Planification du Sprint. Ils décident pour ce premier Sprint d’ajouter le bloc au jeu, ainsi que son craft. Ils décident d’ajouter la condition de pose du bloc, de faire son fonctionnement et gérer l’apport énergétique dont à besoin le bloc pour fonctionner.

Ils travailleront pendant une semaine sur ce sprint en veillant à faire une mêlée par jour, tous les jours à 19 heures sur Discord. Olivier prend soin de mettre à jour le Sprint Backlog chaque jour, et de proposer ainsi un Burndown Chart accessible à toute l’équipe. Au bout d’une semaine de sprint, l’équipe fait donc la revue puis la rétrospective du sprint. Le travail est validé, le Product Owner met alors à jour le Product Backlog et l’équipe réitère la planification du sprint, et ainsi de suite …

Je vous met à titre d’exemple un excel illustrant tout ce qui a été annoncé précédemment. Il n’est volontairement pas fini, comme si le projet était toujours en cours.

N’hésitez pas à utiliser les différents onglet en bas du tableur pour naviguer entre les fichiers.

Trucs & Astuces

Le framework SCRUM a été imaginé pour des espaces de co-working avec des équipes travaillant à 100% sur un projet. Dans le cas d’un projet autour de Minecraft il est difficile d’imaginer cela possible, ainsi je vous invite à mettre en place un Discord/TeamSpeak que les membres de l’équipe pourront utiliser quand ils travaillent sur votre projet.

Normalement, c’est prévu pour une équipe comportant entre 3 et 9 personnes. C’est l’idéal, mais vous pouvez assez facilement l’adapter pour une équipe plus grande. Pour une équipe plus petite, c’est difficilement envisageable (mais pas impossible !).

Licence et attribution

Ce tutoriel rédigé par Epharos ~~corrigé par personne~~ et publié sur Minecraft Forge France est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International

Sommaire des tutoriels

Flow Arg

Je trouve ce topic hyper intéressant : maitriser la méthodologie SCRUM est pas mal demandé sur le marché du développement et entre un profil qui le maitrise et l’autre non, ça peut faire la différence.