Apprendre facilement à utiliser la méthodologie Scrum

Qu’est-ce qu’une méthode agile ?

Si vous n’avez encore jamais entendu parler des méthodes agiles, nous allons faire ensemble un bref résumé.

Les méthodes agiles sont des méthodologies utilisées lors de la réalisation de projets informatiques. Elles reposent sur des cycles de développement itératifs et adaptatifs en fonction des besoins évolutifs du client. Elles permettent de rapidement cerner les attentes de celui-ci et d’y répondre au mieux en l’impliquant au maximum dans le processus de développement. Ainsi, il peut se rendre compte de l’état de l’avancement du projet et décider de le stopper quand il estime que le produit est fini.

Les méthodes agiles ont 4 valeurs et 12 princes de base communs. Ils ont été définis dans le manifeste Agile, rédigé en 2001 par 17 spécialistes du développement logiciel.

Les quatre valeurs :

Les individus et leurs interactions plus que les processus et les outils.
Du logiciel qui fonctionne plus qu’une documentation exhaustive.
La collaboration avec les clients plus que la négociation contractuelle.
L’adaptation au changement plus que le suivi d’un plan.

Les douze principes sont à lire ici.

Il existe plusieurs méthodes agiles. Les plus utilisées sont les méthodes Scrum et XP (Extreme Programming) qui peuvent être appliquées complémentairement. Nous allons ici parler de la première.

La méthode Scrum :

Scrum est la méthode agile la plus utilisée. Elle est donc la plus documentée et supportée. Elle est aussi simple à comprendre et c’est donc pour ça que beaucoup de gens l’apprécient.

La méthode Scrum a été créée en 2002, son nom est un terme emprunté au rugby qui signifie « la mêlée ». Elle s’appuie sur le découpage des projets en itérations encore nommées « sprints ». Un sprint peut avoir une durée qui varie généralement entre deux semaines et un mois.

Les différents rôles de Scrum :

La méthode Scrum définit trois rôles :

Le product owner, celui qui est au courant des caractéristiques du produit. Peut-être le client ou un intermédiaire.

Le Scrum master, celui qui s’assure que la méthodologie Scrum est respectée, que l’on ne s’en éloigne pas. Nous estimerons dans ce tutoriel que vous revêtez ce rôle.

L’équipe de développement qui réalise le produit.

Un environnement de travail adapté

C’est-à-dire :

Pas de changements imposés pendant un sprint ;
Toute l’équipe dans une même pièce ;
Un tableau blanc et/ou en liège ;
Un bon outil de suivi du projet ;
Prévenir des interventions extérieures (téléphone, irruption dans la pièce, etc.) ;
Tout ce qui peut rendre l’équipe plus sereine et efficace.

Les étapes de la méthode Scrum :

Vue globale de la méthodologie Scrum. Référez-vous à ce graphique tout au long de ce tutoriel pour visualiser les différentes étapes.

1. Backlog du produit :

Avant de commencer tout travail de développement, il faut vous renseigner sur les attentes du product owner. Avec votre équipe de développement, vous allez le rencontrer lors d’une réunion.

Il faut lister les exigences du product owner en fonction de leur complexité et de leur priorité. Vous définirez les « user stories », les descriptions des fonctionnalités du point de vue utilisateur. Une user story prendra toujours la forme : « En tant que… Je veux… afin de… ».

Vous vous réfèrerez à cette liste durant toute la durée du projet, elle est donc très importante. La complexité de la tâche ne devra pas exprimée par des € ou des heures mais par une unité quelconque (ex. : des points), ce qui souligne le fait que ce n’est qu’une estimation et pas un chiffrage en tant que tel. Grâce à cette liste, vous pourrez avoir une estimation du prix et du temps de travail nécessaire à la réalisation du projet

2. Backlog du sprint :

En collaboration avec le product owner et votre équipe, vous allez réaliser la liste des tâches à accomplir pendant le sprint en fonction de leur importance et les répartir entre les différents membres de l’équipe. Il est fortement recommandé de créer un tableau des tâches comportant plusieurs colonnes qui permettra d’avoir un visuel sur l’état d’avancement :

3. Sprint :

C’est la période durant laquelle vous et votre équipe allez réaliser les tâches prévues lors du backlog. Un sprint dure entre deux semaines et un mois (la durée est définie avec le product owner et sera la même pendant tout le travail de développement). Il est important de privilégier des périodes plus courtes pour éviter de s’éloigner trop de la nature du projet. Pendant le sprint :

Les tâches prévues ne peuvent être modifiées ;
La composition de l’équipe reste constante ;
La qualité n’est pas négociable ;
La liste des tâches est sujette à négociations entre le product owner et l’équipe de développement.

Chaque jour pendant la période du sprint, il y a le « daily scrum », la mêlée quotidienne, qui dure 15 minutes et se déroule à la même heure chaque jour. Votre équipe se rejoindra pour parler de l’état d’avancement de leur travail. Chacun abordera les points suivants :

Ce qu’il a réalisé la veille,
Ce qu’il compte réaliser aujourd’hui pour atteindre l’objet du sprint,
Les obstacles qui empêchent l’équipe d’atteindre le but du sprint.

Pour visualiser l’état d’avancement du sprint, vous pouvez créer un « burn down chart », un graphique permettant de suivre le « reste à faire » (RAF). Il possède en abscisse le temps et en ordonnée les tâches à réaliser (points d’histoire). Il sera mis à jour tous les jours. Cela permet d’anticiper les dérives et les ruptures de charge. L’idéal étant bien sûr d’arriver à zéro tâches le dernier jour du sprint.

4. Sprint review :

Au bout du sprint, vous et votre équipe avez un produit relativement avancé et il est temps de le présenter au product owner qui pourra alors se rendre compte de la productivité de l’équipe et décider ou non de changer les priorités. Cette transparence peut apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Si le produit convient à celui-ci, il peut lancer le produit en production et accélérer le « time to market », il peut ainsi obtenir un premier retour sur investissement en attendant les prochaines mises à jour pour perfectionner encore plus le produit.

À éviter :

Scrum master trop directif :

Attention à ne pas vouloir trop être directif avec votre équipe, tout le monde est censé être responsable. Le scrum master est seulement le garant de la méthodologie, mais en aucun cas il doit prendre toutes les décisions tout seul. Cela pourrait créer des tensions dans votre équipe et entraîner une baisse de la qualité du produit

Les reproches remplacent les discussions constructives :

Lors des mêlées journalières, certains membres de votre équipe en arriveront peut-être à critiquer ceux qui n’ont pas mené à bien leurs tâches de la veille. Cela peut entraîner des conflits dans votre équipe mais aussi, certains membres pourraient ne plus avoir envie de participer aux réunions de peur d’être un nouvelle fois blâmés et restent enfermés dans leurs problèmes, ce qui va à l’encontre de la méthodologie scrum.

Les liens utiles :

Antoine 14 février 2017

agile / méthodologie / scrum /