Gestion de projets agiles avec Scrum - Cycle de formation

Cette formation couvre les fondamentaux de la gestion de projets agiles avec Scrum, un cadre de travail empirique utilisé pour le développement de produits. Elle s’inscrit dans un cursus de base destiné à comprendre la théorie, les rôles, les artefacts et les pratiques essentielles de Scrum afin de pouvoir démarrer et piloter un projet Scrum efficacement.

Introduction à Scrum et contexte historique

Scrum est un cadre de travail agile qui repose sur un modèle empirique, c’est-à-dire basé sur l’inspection fréquente et l’adaptation continue. Il s’oppose aux méthodes traditionnelles dites en cascade, souvent rigides et séquentielles. Le modèle en cascade, popularisé par Winston W. Royce en 1970, répondait à des exigences réglementaires strictes, notamment pour le département américain de la Défense, mais il s’est avéré risqué et sujet à l’échec.

En 1986, Hirotaka Takeuchi et Ikujiro Nonaka ont proposé une approche plus holistique, comparant le développement de produit à un jeu de rugby où l’équipe avance ensemble en passant la balle en arrière, favorisant la vitesse et la flexibilité. Cette idée a inspiré la philosophie agile et Scrum.

Le développement logiciel est souvent trop complexe pour être décrit par un processus strict et répétable. Le modèle empirique de Scrum accepte cette complexité et mise sur des contrôles fréquents par inspection et adaptation afin d’atteindre les objectifs du projet.

Les fondements et principes de Scrum

Scrum repose sur trois piliers essentiels : la transparence, l’inspection et l’adaptation. Ces piliers garantissent que l’équipe peut régulièrement évaluer son avancement et ajuster son travail en conséquence.

Les dix pratiques de base de Scrum comprennent notamment :

• Une vision claire et partagée du produit
• Un Product Backlog entretenu et priorisé selon la valeur métier
• Des Daily Scrums pour synchroniser et coordonner les efforts
• Des Sprints protégés des interruptions par le management ou les clients
• Une équipe qui ne délivre que des items « terminés » selon une définition claire
• Des revues de Sprint collaboratives
• Des rétrospectives axées sur l’amélioration continue
• L’utilisation de Burndown Charts pour suivre le reste-à-faire

Scrum s’inscrit dans la philosophie agile, dont le Manifeste pour le développement agile de logiciels valorise :

• Les individus et leurs interactions plus que les processus et les outils
• Les logiciels opérationnels 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 principes sous-jacents insistent sur la satisfaction rapide du client, la collaboration quotidienne, la simplicité, l’excellence technique, et l’auto-organisation des équipes.

Les rôles dans Scrum

Scrum distingue trois rôles principaux au sein de la Scrum Team, ainsi que plusieurs rôles organisationnels :

La Scrum Team

• Le ScrumMaster : il protège l’équipe des perturbations extérieures, optimise sa productivité, veille au respect des principes agiles, anime les réunions et facilite l’inspection et l’adaptation. Il n’est pas responsable des livrables et n’est pas un membre actif de l’équipe de développement.
• Le Product Owner : il pilote le projet du point de vue métier, communique la vision du produit, gère et priorise le Product Backlog, accepte ou rejette les livrables à la fin de chaque Sprint, et est responsable du retour sur investissement.
• L’Équipe de développement : composée de 5 à 9 personnes multidisciplinaires, autogérées et cross-fonctionnelles, elle délivre le produit et en garantit la qualité. Elle collabore étroitement avec le Product Owner et les utilisateurs finaux pour comprendre les besoins métier et définir la direction stratégique.

Les rôles organisationnels

• Le Client : il commande et finance le produit, donne des retours et valide les évolutions.
• Le Manager : il crée un environnement stable et structuré, travaille avec le ScrumMaster pour adapter l’organisation et s’assure de la pérennité de l’équipe.
• L’Utilisateur final : il connaît ses besoins et exigences, participe aux revues et au Sprint Planning, et donne des retours essentiels pour la définition du produit.

Les artefacts Scrum

Scrum utilise quatre artefacts principaux pour gérer le travail :

• Product Backlog : liste priorisée de toutes les exigences et travaux souhaités pour le produit, maintenue par le Product Owner. Chaque item doit apporter une valeur métier claire.
• Sprint Backlog : ensemble des tâches sélectionnées pour un Sprint, découpées et estimées par l’équipe.
• Burndown Charts : graphiques qui montrent le reste-à-faire au cours d’un Sprint (Sprint Burndown) ou d’une release (Release Burndown), permettant de visualiser les progrès et d’anticiper les risques de retard.
• Definition of Done : critère clair qui définit quand un item est considéré comme terminé. Il inclut des exigences telles que le code conforme aux normes, propre, refactoré, testé unitairement, intégré et validé.

Les événements Scrum

Scrum organise le travail en cycles appelés Sprints, chacun comprenant plusieurs réunions clés :

Sprint Planning Meeting

Réunion de planification divisée en deux parties :

• Le QUOI (organisé par le Product Owner) : définition des objectifs du Sprint, évaluation et découpage du Product Backlog en items réalisables.
• Le COMMENT (organisé par l’équipe) : découpage des items en tâches techniques, estimation et planification détaillée.

Durée totale : environ 8 heures pour un Sprint de 4 semaines.

Daily Scrum

Réunion quotidienne de 15 minutes où l’équipe synchronise ses actions et s’engage sur les tâches. Chaque membre répond à trois questions :

• Qu’as-tu fait hier ?
• Quels obstacles as-tu rencontrés ?
• Que prévois-tu de faire aujourd’hui ?

Sprint Review

Réunion de fin de Sprint où l’équipe présente les résultats aux utilisateurs, clients et management. Ces derniers donnent leur feedback, et le Product Owner valide ou rejette les items selon la Definition of Done.

Durée : environ 4 heures pour un Sprint de 4 semaines.

Rétrospective

Réunion d’analyse du processus Scrum et des pratiques de l’équipe. Elle vise à identifier les points d’amélioration pour les prochains Sprints, en se concentrant sur le travail de l’équipe et l’organisation.

Les User Stories et la gestion du Product Backlog

Les exigences sont souvent exprimées sous forme de User Stories, qui suivent le format :

En tant que [rôle utilisateur]
Je veux [fonctionnalité]
De sorte que je reçoive [valeur métier]

Les bonnes User Stories respectent le modèle INVEST :

• Indépendantes
• Négociables
• Valorables
• Estimables
• Suffisamment petites (Sized appropriately)
• Testables (testables)

Chaque Story est décrite sur une carte avec une brève description, les risques et les critères d’acceptation clairs, qui permettent de valider la fonctionnalité.

Collaboration et dynamique d’équipe

Scrum encourage les équipes auto-gérées, multidisciplinaires et orientées client, en opposition aux organisations traditionnelles hiérarchiques et cloisonnées. La communication est largement partagée, avec peu de niveaux de management et un fort engagement des membres de l’équipe.

Pour optimiser le travail collectif, il est recommandé de créer des règles de vie d’équipe, éviter le tutoiement nominatif, respecter la ponctualité et utiliser un « bâton de parole » pour faciliter les échanges.

Le Product Owner n’est pas un adversaire, et la collaboration entre équipes est essentielle. Chaque équipe doit disposer d’un espace dédié pour travailler efficacement.

Interactions entre les rôles

• Le ScrumMaster travaille étroitement avec le Product Owner pour s’assurer que ce dernier remplit bien son rôle, en le coachant et en le protégeant des pressions extérieures.
• Le ScrumMaster soutient également l’équipe en éliminant les obstacles et en veillant au respect des engagements.
• Le Product Owner collabore avec le client pour garantir le retour sur investissement, en équilibrant les demandes du client et les capacités de l’équipe.
• L’équipe travaille avec l’utilisateur final pour comprendre ses besoins et développer un produit conforme aux attentes.
• Le ScrumMaster coopère avec le manager pour adapter les processus et garantir que l’équipe dispose des ressources nécessaires.
• Le Product Owner doit bien connaître les besoins du marché et des utilisateurs finaux pour prioriser efficacement le Product Backlog.

Key points

• Scrum est un cadre empirique basé sur l’inspection, l’adaptation et la transparence.
• Les rôles clés sont le ScrumMaster, le Product Owner et l’équipe de développement, chacun avec des responsabilités distinctes.
• Le Product Backlog est une liste priorisée d’exigences exprimées souvent sous forme de User Stories.
• Les événements Scrum (Sprint Planning, Daily Scrum, Sprint Review, Rétrospective) rythment le travail et favorisent la collaboration.
• La Definition of Done garantit la qualité et la complétude des livrables.
• La collaboration étroite entre les rôles organisationnels, l’équipe et les utilisateurs finaux est essentielle pour le succès du projet.
• Les équipes Scrum sont auto-gérées, multidisciplinaires et orientées vers la création de valeur pour le client.