La méthode Scrum est un cadre méthodologique basé sur des cycles de développement courts dans lesquels l’équipe, qui travaille sur un produit, s’adapte constamment, tout en maintenant l’utilisateur au centre du processus. Elle permet un développement par itération, avec tous les avantages que cela apporte : une progression visible, des résultats quantifiables, et des solutions repensées de manière dynamique.
Pour bien comprendre cette méthode agile qui nous vient du domaine de l’informatique, il faut d’abord se pencher sur sa terminologie très anglophone. Product backlog, Burndown Chart, Scrum meetings et autres mots spécifiques n’auront plus de secrets pour vous à la fin de cet article !
Tout commence par un produit pour lequel le Product Owner (le détenteur du produit) va élaborer des User Stories, c’est-à-dire des expériences utilisateurs. Imaginons une application qui peut trier les œuvres d’art des musées en accédant à leur catalogue. Voici quelques User Stories possibles : “L’utilisateur décide de ne chercher que les tableaux d’un musée précis, de type portrait, réalisés dans une période donnée”, “L’utilisateur change la langue de l’application, puis l’utilise pour trouver les horaires d’un musée précis”, ou encore “L’utilisateur recherche tous les musées qui proposent des collections temporaires dans un rayon de 5 kms”.
Ainsi, le Product Owner définit le périmètre du projet et compile les fonctionnalités qu’il veut offrir à ses utilisateurs. Ces fonctionnalités sont ensuite ajoutées dans le Product Backlog, le journal de suivi du produit, qui décrit l’ensemble des tâches à accomplir pour chacune des User Stories. Ces éléments sont aussi classés de manière hiérarchique en fonction de l’importance de leur réalisation.
C’est le Scrum Master (ou coach agile) qui s’occupe du planning et de la réalisation du Backlog. Capitaine de l’équipe, c’est aussi la personne qui va organiser la répartition des tâches et structurer le travail par des réunions.
Lorsque l’équipe est prête à commencer à travailler, on lance une itération de travail, du nom de sprint. Cette période dure généralement de 2 à 4 semaines, et se divise de la manière suivante :
Le Product Owner va alors inspecter le travail reçu, puis faire des retours à l’équipe. Les modifications éventuelles sont ajoutées au Backlog du produit, et on peut alors envisager une nouvelle période de sprint.
Voilà, vous avez les grandes lignes : mais vous pouvez en apprendre davantage sur la terminologie Scrum en cliquant sur ce lien.
Lorsqu’on développe un produit avec la méthode Scrum, il est impossible de perdre de vue ses objectifs. La vision d’équipe est uniforme grâce aux réunions quotidiennes, qui doivent être dynamiques : il n’est pas rare que les meetings quotidiens se fassent debout pour que les gens restent concis dans leurs explications.
Cette méthode, contrairement à d’autres, ne compartimentalise pas les tâches : elle permet une vision globale à tous les membres de l’équipe.
Si le Backlog permet d’inventorier les tâches qu’il reste à accomplir, c’est grâce au Burndown Chart qu’on voit les avancées réalisées par l’équipe. Ce graphique permet d’établir ce qu’on appelle la vélocité du projet : le nombre de tâches réalisées par rapport à l’ensemble du projet dans un sprint. C’est le meilleur indicateur de la capacité de traitement des nouvelles demandes par l’équipe de développement.