Présentation
Les dieux du Scrum
Scrum veut dire “mêlée” en anglais. Hé oui, cette méthodologie de projet vient du Rugby ! La méthode utilise les valeurs et l’esprit du Rugby pour les adapter au développement de logiciel. Le sens de l’équipe, du contact, du travail bien fait ! Comme le pack pendant un ballon porté, l’équipe est soudée pour atteindre l’objectif. Le ScrumMaster est, quant à lui, similaire au demi de mêlée qui répartit les membres de l’équipe et les réorganise pour assurer la réussite du projet.
Alors, comment ça fonctionne ? Voyons ça dans le détail !
Sprinter, marquer un essai et boire une bière
Au début du projet, le projet est découpé en fonctionnalités qui sont listées dans un backlog, une sorte de grand tableau.
Puis nous allons nous intéresser à la première version qui sera mise en ligne. Elle sera volontairement minimale, se concentrant sur les fonctionnalités essentielles qui ont été indiquées comme prioritaires dans le backlog. Chaque mise en production est appelée release et est constituée de plusieurs sprints.
Un sprint dure entre une et deux semaines et sert à développer une ou plusieurs fonctionnalités. Elles sont décidées par l’équipe et le Product Owner (dont nous parlerons plus tard). Chaque sprint est découpé en Stories mais nous verrons tout cela en détails plus tard. Pour l’instant, gardons en tête que le·a développeur·se de chaque story produira les mêmes livrables que ceux que nous avons vus dans les méthodologies séquentielles mais à l’échelle d’une story et non du projet tout entier.
Il / Elle aura donc à :
créer des spécifications fonctionnelles,
concevoir l’architecture de la story,
coder et tester.
Pendant un sprint, des points sont effectués lors des mêlées quotidiennes. Cela permet au ScrumMaster, l’animateur chargé de faire appliquer Scrum, de déterminer l’avancement par rapport aux engagements de chacun et éventuellement d’apporter des ajustements.
À la fin de chaque sprint, l’équipe ajoute une nouvelle brique au projet qui devient ainsi, de sprint en sprint, de plus en plus complet. Son évaluation et le feedback récolté permettent d’ajuster le backlog pour le sprint suivant. Cela s’appelle l’inspection.
Puis l’équipe passe à un nouveau sprint, constitué de stories, et ainsi de suite !
Rôles
Les responsabilités et les missions des intervenants d’un projet agile sont très différentes en comparaison avec un projet séquentiel car l’accent est mis sur l’appropriation du projet par chaque membre de l’équipe et sur la collaboration.
Le Product Owner
Il représente les utilisateurs finaux (ou clients) du projet. Il est responsable de la définition du contenu du produit et de la gestion des priorités. C’est pourquoi il alimente régulièrement le backlog en nouvelles fonctionnalités et trie les anciennes par ordre de priorité. Le Product Owner définit l’objectif d’une release et prend les décisions sur son contenu.
Idéalement il est disponible à plein temps pour mettre à jour le backlog, répondre aux questions sur le produit, définir les tests d’acceptation (dont nous parlerons plus tard) et passer les tests.
Le ScrumMaster
Il n’y a pas de chef de projet dans Scrum ! Chaque membre s’approprie le projet et l’équipe s’auto-organise en conséquence. Le Scrum Master aide l’équipe à appliquer les principes de Scrum, en la guidant sur la rédaction de User Stories par exemple. Il fait également en sorte d’éliminer tout obstacle qui pourrait entraver le projet. On dit souvent que le ScrumMaster “protège” l’équipe car toute demande provenant de l’extérieur doit auparavant passer par le processus Scrum.
L’équipe
Il s’agit du rôle principal ! C’est elle qui réalise le produit. Elle doit, par conséquent, posséder toutes les compétences nécessaires à son bon développement. Les membres sont choisis par le Scrum Master en fonction de leur motivation et de leurs compétences. C’est l’équipe qui définit elle-même la façon dont elle organise ses travaux, ce n’est pas le Scrum Master ni le Product Owner. Chaque membre de l’équipe apporte son expertise. Les responsabilités de l’équipe sont donc essentielles !
Débuter un projet : sprint 0
On appelle “Sprint 0” la période précédant le premier sprint. Elle est dédiée à l’organisation du projet : prise de connaissance avec le produit et avec les attentes des utilisateurs, recrutement de l’équipe et création du backlog.
Vision
Nous avons vu que la responsabilité majeure du Product Owner est de faire en sorte que le produit développé réponde à un besoin des utilisateurs. Il doit posséder une vision très forte du produit qu’il souhaite pour être capable de la transformer.
Cette vision répond à la question toute simple (et pourtant souvent complexe) du “pourquoi ?”. Pourquoi notre utilisateur va-t-il se servir de l’application que nous développons ? La réponse doit être limpide.
Utilisateurs
Le Product Owner se doit de connaître parfaitement les utilisateurs qu’il représente. Garder en tête leurs besoins est une première étape mais connaître leurs usages actuels est encore mieux.
Pour cela, le Product Owner crée une ou plusieurs personas et les partage au reste de l’équipe.
Qu’est-ce qu’une persona ?
Il s’agit du portrait-robot de l’utilisateur de notre produit. Nous lui donnons un prénom, un âge, nous lui construisons une histoire et lui donnons des habitudes qui reflètent ce que nous savons déjà de notre utilisateur.
L’objectif est de rendre plus tangible le développement de chaque fonctionnalité. Il est plus facile de penser à Lisa que de penser à l’utilisatrice Y !
Vous pouvez en savoir plus dans le chapitre Partez à la découverte de votre audience du cours Lancez une campagne Facebook Ads.
Backlog
Puis le Product Owner remplit le backlog.
Le Backlog est un grand tableau listant les fonctionnalités prévues pour le produit et leur état d’avancement (en attente de développement, prévu, en cours, fini, …). Chacune est placée par ordre de priorité de haut en bas, celle en haut étant la prochaine fonctionnalité à développer. Découvrez un backlog d’exemple créé par Brian Cervino.
En général un tableau de backlog contient les colonnes suivantes :
Product backlog : les fonctionnalités qui ont été priorisées par le Product Owner et qui sont en attente de développement.
Development : User Stories en développement
Done : User Stories qui ont été mises en production.
À ce stade, il n’y a que la colonne Product Backlog qui est remplie. C’est normal car nous n’avons pas encore démarré le premier sprint ! L’équipe va analyser la première fonctionnalité, la découper en user stories et déterminer le scope du premier sprint. Nous voyons tout cela dans le prochain chapitre !
------
Crédits des illutrations : jeu de poker par LAFS, mis à disposition par The Noun Project.
