Scrum

Voici une présentation rapide mais très complète de l’approche Scrum dans la gestion de projet.

Pour rappel Scrum est une méthode agile dédiée à la gestion de projet. Cette méthode de gestion à pour objectif d’améliorer la productivité de son équipe.

Scrum-Overview-Diagram-575x359

Répartitions des rôles dans Scrum, Les métiers

Le ScrumMaster

Le ScrumMaster est responsable de la méthode. Il doit s’assurer que celle-ci est comprise, et bien mise en application.
Ce n’est pas un chef de projet, ni un intermédiaire de communication avec les clients.

  • S’assure que les principes et les valeurs de Scrum sont respectés
  • Facilite la communication au sein de l’équipe
  • Cherche à améliorer la productivité et le savoir faire de son équipe

quelques vidéos

L’équipe

L’équipe ne comporte pas de rôles prédéfinis, elle est auto-organisée et pluridisciplinaire.

  • Pas de rôle bien déterminé : architecte, développeur, testeur
  • Tous les membres de l’équipe apportent leur savoir faire pour accomplir les tâches
  • Taille de 6 à 10 personnes en général et pouvant aller jusqu’à 200 personnes

Le Product Owner

Le Propriétaire du produit (Product Owner) est le représentant des clients et des utilisateurs.
Son objectif est de maximiser la valeur du produit développé.

  • Expert métier, définit les spécifications fonctionnelles
  • Etablit la priorité des fonctionnalités à développer ou corriger
  • Valide les fonctionnalités développées
  • Joue le rôle du client

methode-gestion-projet-scrum-575x223

quelques vidéos

Les événements qui rythme le scrum

Les sprints

Le cycle de vie Scrum est rythmé par des itérations de quelques semaines, les sprints.

Le sprint

Le sprint est une période d’un mois au maximum, au bout de laquelle l’équipe délivre un incrément du produit, potentiellement livrable.
Une fois la durée choisie, elle reste constante pendant toute la durée du développement.
Un nouveau sprint démarre dès la fin du précédent.

Le product backlog

Le référentiel des exigences initiales est dressé et hiérarchisé avec le client. Il constitue ce que l’on nomme le product backlog. Il ne doit pas nécessairement contenir toutes les fonctionnalités attendues dès le début du projet, il va évoluer durant le projet en parallèle des besoins du client.

User Story

Les fonctionnalités décrites portent le nom de User Stories et sont décrites en employant la terminologie utilisée par le client.

Une User Story ou Story contient généralement les informations suivantes :

  • ID – un identifiant unique
  • Nom – un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client (ex. Export / Import Standard Sales Item). Le nom doit être suffisamment clair pour que les membres de l’équipe et le Product Owner comprennent de quelle fonction il s’agit. Le nom ne doit pas introduire d’ambigüités.
  • Importance – un entier qui fixe la priorité des Stories. La priorité d’une story peut être changée en cours de réalisation du projet.
  • Estimation – La quantité de travail nécessaire pour développer, tester, et valider cette fonctionnalité. L’unité de mesure peut être un nombre de jours idéaux (jours à 100% dédiés à la fonctionnalité) ou un nombre de points. Les estimations se font en relatif en comparant les estimations des stories terminées avec la story à estimer.
  • Demo – Un test relativement simple (ex : exporter un objet en XML puis l’effacer de la base, l’importer depuis le XML, à la fin l’objet doit être dans la base). Ce test constitue un test de validation.
  • Notes – toute autre information : clarifications, références documentaires…

le sprint planning meeting

Réunion de planification

Tout le monde est présent à cette réunion, qui ne doit pas durer plus de 8 heures pour un sprint d’un mois.
Pour un sprint plus court, la durée est réduite proportionnellement.

On organise, avant chaque sprint, une réunion de planification, le sprint planning meeting. Ce planning sélectionne dans le product backlog les exigences les plus prioritaires pour le client. Elles seront développées, testées et livrées au client à la fin du sprint. Elles constituent le sprint backlog, un sous ensemble du product backlog.

La mêlée

Au quotidien, une réunion, la mêlée quotidienne (Daily Scrum), permet aux développeurs de faire un point de coordination sur les tâches en cours et sur les difficultés rencontrées.
Cette réunion dure 15 minutes au maximum. Le Scrum Master s’assure que la réunion ait lieu à heure fixe. Le propriétaire du produit n’est pas présent.

Une vidéo très drôle qui montre toutes les choses folles qui pourraient se produire au cours de la réunion quotidienne Agile / Scrum stand-up! Regardez la version dysfonctionnelle alors comment l’équipe se déplace à une fonction stand-up!
https://www.youtube.com/watch?v=q_R9wQY4G5I

Au cours du sprint, organisé, chaque jour,  avec tous les membres de l’équipe afin de s’assurer que les objectifs du sprint seront tenus, c’est le Scrum ou mêlée. Chaque jour, après la réunion Scrum, le Scrum Master maintient un graphique appelé sprint burndown chart. Ce graphique donne une très bonne vision de ce qui a été fait et du rythme de travail de l’équipe. Il permet également d’anticiper si toutes les stories du Sprint Backlog seront terminées à la fin de l’itération ou non.
burndownchart-575x358

Cette réunion n’a pas seulement un but purement informatif, mais aussi de stimuler l’esprit travail en équipe et le niveau d’engagement de chaque membre de l’équipe dans le projet. Durant la réunion chaque membre de l’équipe doit prendre la parole et présenter principalement les choses suivantes :

  • Ce que j’ai fait hier et les éventuels problèmes rencontrés
  • Ce que je vais faire aujourd’hui
  • Est ce que j’ai des difficultés pour continuer mon travail.
  • En faisant cet exercice quotidiennement chaque membre de l’équipe est au courant de ce que font ses collègues et il peut coordonner son travail et aider ou se faire aider en cas de difficultés.

Le Scrum Meeting n’est pas une réunion pendant laquelle on cherche à résoudre les problèmes, mais uniquement à les identifier et les exprimer. Le Scrum Master a pour rôle d’apporter des solutions ou de déléguer à un autre membre de l’équipe la résolution des problèmes soulevés durant le Scrum Meeting. A la suite de cette réunion le Scrum Master met à jour le burndown chart.
A la fin d’un sprint, on fait une démonstration au client des derniers développements, le Sprint Review Meeting. C’est aussi l’occasion de faire un bilan, sur le fonctionnement de l’équipe et de trouver des points d’amélioration.

De part ses valeurs, Scrum prône l’adaptabilité, sous l’effet de l’expérience acquise et des spécificités du projet ce qui le rapproche de la méthode de production de Toyota (Lean). La visibilité, pour évaluer les résultats du processus. L’inspection, qui consiste à vérifier les écarts par rapport à l’objectif initial.

Revue de sprint

À la fin du sprint, tout le monde se réunit pour effectuer la revue de sprint, qui dure au maximum 4 heures.
L’objectif de la revue de sprint est de valider le logiciel qui a été produit pendant le sprint.
L’équipe commence par énoncer les items du carnet de produit qu’elle a réalisé.
Elle effectue ensuite une démonstration du logiciel produit.
C’est sur la base de cette démonstration que le directeur de produit valide chaque fonctionnalité planifiée pour ce sprint.

Rétrospective

La rétrospective du sprint est faite en interne à l’équipe (incluant le ScrumMaster).
Elle dure 3 heures pour un sprint d’un mois, et réduit selon la durée du sprint.

Outil

backlog

Scrum utilise une approche fonctionnelle pour récolter les besoins des utilisateurs.
L’objectif est d’établir une liste de fonctionnalités à réaliser, que l’on appelle carnet du produit

Planning Poker

Scrum Board

Burndown Charts

 

Manifeste pour le développement Agile de logiciels

TV scrumday

Soft pour faire le Scrum

Quelques modèles Google Docs :

Source

 

(Visited 83 times, 1 visits today)