Scrum est un cadre de gestion de projet qui met l’accent sur le travail d’équipe, la responsabilité et les progrès itératifs vers des objectifs clairement définis. Il commence par une hypothèse simple : commencez par ce que vous pouvez voir ou connaître. Ensuite, suivez les progrès et ajustez selon les besoins.
Les trois piliers de Scrum
Scrum repose sur l’empirisme, qui affirme que les connaissances proviennent de l’expérience et que les décisions doivent être fondées sur ce qui est connu. Ces trois piliers unissent Scrum.
Pourquoi Scrum ?
Scrum livre la fonctionnalité de manière incrémentale, tandis que Waterfall ne le fait que par phases. Le développement traditionnel en cascade est un processus séquentiel basé sur des phases, où la valeur n’est livrée qu’à la fin du projet. Scrum transforme ce modèle en livrant de nouvelles fonctionnalités à chaque sprint — généralement toutes les 2 à 4 semaines — plutôt que de se concentrer sur un grand lancement futur.
Scrum décompose le travail complexe en éléments gérables, divise les grandes organisations en petites équipes et transforme les projets significatifs en une série de sprints courts et limités dans le tempssprints.
Grâce au développement itératif et incrémental, les entreprises peuvent livrer plus rapidement et plus efficacement les produits et services dont les clients ont réellement besoin. Avec Scrum, vous pouvez recevoir et intégrer les retours des clients à la fin de chaque sprint, ce qui signifie que vos résultats sont façonnés par l’utilisation réelle plutôt que par des hypothèses. Cela facilite le maintien des clients et des parties prenantes clés activement impliqués.
Agile vs Scrum
Agile est une pratique qui permet l’itération continue dans le développement et les tests tout au long du cycle de vie du logiciel. Agile divise les produits en composants plus petits et gérables.Scrum est simplement l’un des nombreux processus de développement logiciel Agile itératifs et incrémentaux qui nous permettent de nous concentrer sur la livraison de valeur commerciale dans le délai le plus court possible.
Scrum traite généralement des exigences qui peuvent changer ou être inconnues au début d’un projet. Scrum se caractérise par :
- Léger
- Facile à comprendre
- Difficile à maîtriser
Les avantages de Scrum
Voici les avantages que Scrum apporte aux organisations, aux équipes, aux produits et aux individus :
- Meilleure qualité: Il existe un cadre pour atteindre une vision ou des objectifs. Scrum fournit un retour continu et une visibilité pour garantir que la qualité soit aussi élevée que possible. Scrum aide à assurer la qualité grâce à des pratiques telles que :
- Réduction du délai de mise sur le marché: Scrum s’est avéré livrer de la valeur aux utilisateurs finaux 30 % à 40 % plus rapidement que les méthodes traditionnelles.
- Rendement supérieur sur investissement (ROI): Un délai de mise sur le marché plus court est une raison clé pour laquelle les projets Scrum atteignent un ROI plus élevé. L’accumulation précoce de revenus et de bénéfices signifie des rendements totaux plus élevés. Cela repose sur le principe fondamental des calculs de la valeur actualisée nette (VAN).
- Plus haut moral d’équipe: Travailler avec des individus heureux et engagés est satisfaisant et productif. La gestion autonome place les décisions habituellement prises par les gestionnaires ou les organisations entre les mains desÉquipe Scrum membres.
- Collaboration renforcée entre les équipes: Lorsque les équipes Scrum prennent en charge le projet et le produit, elles peuvent atteindre de très bons résultats. Les équipes Scrum collaborent et améliorent la qualité et les performances du projet grâce à une implication et une communication renforcées.
Cadre Scrum
Scrum est simple. Ce n’est pas un ensemble de mandats rigides et interconnectés. Scrum n’est pas une méthodologie. Scrum incarne la méthode scientifique de l’empirisme. Il remplace les approches algorithmiques procédurales par des méthodes heuristiques, en respectant les personnes et l’autogestion pour faire face à l’imprévisibilité et résoudre des problèmes complexes. Le schéma ci-dessous montre Scrum en action, tel que décrit par Ken Schwaber et Jeff Sutherland dans leur livre « Scrum : L’art de faire deux fois le travail en moitié le temps », illustrant le parcours du planification à la livraison du logiciel.
Composants du processus Scrum
Le cadre Scrum lui-même est simple. Il définit seulement quelques principes généraux, avec un petit nombre de règles, rôles, artefacts, et événements. Toutefois, chacun de ces composants est crucial pour des objectifs spécifiques et essentiel pour utiliser avec succès le cadre.
Les principaux composants du cadre Scrum sont :
- Rôles Scrum: Master Scrum, Propriétaire du produit, et l’équipe Scrum
- Artefacts: Backlog de sprint, Backlog produit, Graphique de combustion, journaux, etc.
- Événements Scrum: Planification de sprint, Revue de sprint, Scrum quotidien, Retrospective de sprint, etc.
- Sprints
Le schéma ci-dessous montre les éléments clés du cadre Scrum. Le processus a été visualisé à l’aide du Tableau de processus Scrum provenant des outils logiciels Agile de Visual Paradigm.
Rôles Scrum
Lorsqu’une organisation adopte Scrum, la première chose à comprendre est la différence entre les rôles Scrum et les rôles traditionnels de gestion de projet. Bien qu’il n’y ait que trois rôles principaux dans Scrum, ils ne s’alignent pas automatiquement sur des titres de poste familiers. Commençons par des définitions brèves de chacun :
Propriétaire de produit
Le propriétaire de produit est le rôle Scrum chargé de représenter l’entreprise ou la communauté des utilisateurs. Il travaille étroitement avec les utilisateurs pour définir les fonctionnalités dans le backlog produit. Les principales responsabilités incluent :
- Définir la vision et la stratégie du produit, y compris les objectifs à court et à long terme ;
- Fournir ou recueillir des connaissances sur le produit ou le service ;
- Comprendre et communiquer les besoins des clients à l’équipe de développement ;
- Recueillir, prioriser et gérer les exigences du produit ou du service ;
- Assumer la responsabilité du budget du produit ou du service, y compris la rentabilité ;
- Déterminer les dates de mise en production du produit ou du service ;
- Répondre aux questions et prendre des décisions quotidiennement avec l’équipe de développement ;
- Accepter ou rejeter le travail terminé du sprint ;
- Présenter les principaux livrables de l’équipe à la fin de chaque sprint ;
- Gérer le backlog produit.
Master Scrum
Le Master Scrum est le facilitateur de l’équipe de développement Agile. Scrum permet aux équipes de s’organiser elles-mêmes et de s’adapter rapidement selon les principes Agile. Le Master Scrum gère le flux d’information. Principales responsabilités :
- Agir comme coach pour aider l’équipe à suivre les valeurs et pratiques Scrum ;
- Aider à éliminer les obstacles et protéger l’équipe des distractions extérieures ;
- Faciliter une bonne collaboration entre l’équipe et les parties prenantes ;
- Promouvoir le bon sens et la transparence au sein de l’équipe ;
- Protéger l’équipe des perturbations organisationnelles.
Équipe Scrum
L’équipe Scrum (également connue sous le nom d’équipe de développement) se compose de 3 à 9 membres qui doivent posséder collectivement toutes les compétences techniques nécessaires pour livrer le produit ou le service. Elle est guidée directement par le Maître Scrum, mais non gérée au sens traditionnel. Elle doit être auto-organisée, pluridisciplinaire et responsable de la réalisation de toutes les tâches nécessaires.
L’équipe de développement est responsable de livrer un incrément de produit potentiellement livrable à la fin de chaque Sprint — couvrant l’analyse, la conception, le développement, les tests et la rédaction technique. Les caractéristiques importantes d’une équipe Scrum incluent :
- Auto-organisation: Tous les membres de l’équipe gèrent leurs propres tâches pour accomplir les missions assignées. Dans Scrum Agile, il n’y a pas de chef d’équipe ni de manager hiérarchique. Chacun doit s’engager suffisamment pour piloter ses propres activités et contribuer au succès de l’équipe. Si l’un échoue, tout le monde échoue.
- Pluridisciplinaire: Tous les membres de l’équipe doivent posséder toutes les connaissances et compétences nécessaires pour livrer un produit de haute qualité, prêt à être livré. Des experts peuvent être sollicités pour des conseils, mais uniquement pour transmettre leurs connaissances à l’équipe afin de combler les lacunes de compétences.
- Le Product Owner doit avoir une vision commerciale: Le Product Owner représente la voix du client et doit traduire leurs besoins en éléments actionnables pour le Maître Scrum et l’équipe de développement. Il s’agit généralement d’un poste à temps plein.
- Le Maître Scrum n’est pas un manager hiérarchique: Ils aident à encadrer l’équipe de développement et éliminent les obstacles qui freinent la progression.
Les artefacts Scrum
Les artefacts Scrum aident à définir le travail entrant dans l’équipe et celui actuellement en cours. Bien qu’il existe d’autres artefacts — comme les user stories, les listes de livraison, les graphiques de combustion — ici, nous nous concentrons sur les trois principaux :
Backlog produit
Le Backlog produit est une liste priorisée d’histoires d’utilisateur représentant les fonctionnalités que l’équipe produit doit ou attend. En général, c’est le Product Owner qui maintient cette liste.
Backlog de Sprint
Le Backlog de Sprint contient un ensemble d’éléments sélectionnés à accomplir durant le Sprint en cours. Deux points clés à noter concernant la relation entre le Backlog de Sprint et le Backlog produit :
1. L’équipe décide ce qu’elle ajoute au Sprint. Par conséquent, l’équipe est propriétaire et responsable de la livraison de ces éléments.
2. Avant de déplacer un élément du Backlog produit vers le Backlog de Sprint, l’équipe doit s’assurer qu’elle dispose de toutes les informations nécessaires. L’équipe établit généralement une liste de contrôle des critères à remplir avant qu’un élément ne puisse être ajouté.
Backlog produit vs Backlog de Sprint
Le Backlog de Sprint est la liste des tâches que l’équipe Scrum s’engage à accomplir durant le Sprint. Lors de la réunion de planification du Sprint, l’équipe sélectionne généralement quelques Éléments du Backlog produit sous forme d’histoires d’utilisateur et détermine les tâches nécessaires pour accomplir chacun d’eux, comme indiqué ci-dessous :
Graphique de combustion
Un graphique de combustion est une représentation graphique du travail restant au fil du temps. Le travail restant (ou le travail du backlog) est indiqué sur l’axe vertical, avec le temps sur l’axe horizontal. Il s’agit d’un graphique en continu du travail restant à accomplir. Il peut être utilisé pour prévoir quand tout le travail sera terminé. Il est couramment utilisé dans les méthodes de développement logiciel Agile comme Scrum, mais peut s’appliquer à tout projet présentant une progression mesurable au fil du temps. Le travail restant peut être mesuré en temps ou en points histoire.
Événements Scrum
La communication est essentielle ! Le Scrum repose sur la transparence dans tous les aspects (Pilier du Scrum #1). Étant donné ce principe fondamental, le cadre est construit autour d’une série d’événements clés pour assurer les deux autres piliers — Inspecter et Adapter — comme indiqué dans le tableau ci-dessous :
| Événement | Inspecter | Adapter |
|---|---|---|
| Planification de Sprint |
|
|
| Daily Scrum |
|
|
| Revue de Sprint |
|
|
| Rétrospective de Sprint |
|
|
Remarque : Au cours de chaque Sprint, il y a cinq réunions clés dans le Scrum, comme indiqué ci-dessous :
Planification du Sprint
Chaque Sprint commence par une planification. L’équipe doit déterminer et s’engager à ce qu’elle livrera dans le cadre du Sprint. Les éléments possibles sont toujours extraits du Backlog du Sprint, comme indiqué ci-dessous :
C’est là que le Maître d’Agilité peut briller. Le Product Owner définit ce qui est nécessaire du point de vue métier ou client, l’équipe Scrum détermine ce qu’elle estime pouvoir livrer, et le Maître d’Agilité veille à ce que les deux parties soient bien alignées.
Réunion quotidienne de Scrum
Dès que l’équipe s’engage à livrer ce qui fait partie du Sprint, elle organise une réunion quotidienne. L’objectif principal est de s’assurer que chaque membre de l’équipe (et éventuellement les observateurs) comprend pleinement l’état et l’avancement du travail :
- Qu’ai-je fait hier ?
- Qu’est-ce que je ferai aujourd’hui ?
- Qu’est-ce qui me bloque ?
Cette mise à jour quotidienne fournit un retour immédiat à l’équipe. Les réunions sont brèves — pas plus de 3 minutes par personne.
Remarque : Les observateurs sont là pour observer. Le Maître d’Agilité doit minimiser les distractions externes et internes.
Réunion de revue du Sprint
La revue du Sprint ou la démonstration a lieu à la fin du Sprint pour inspecter l’Increment. L’équipe démontre l’Increment selon la définition de « terminé », en se concentrant sur l’objectif du Sprint. Le Product Owner examine et accepte l’Increment livré.
Rétrospective du Sprint
La rétrospective du Sprint est généralement la dernière activité du Sprint. De nombreuses équipes la mènent immédiatement après la revue du Sprint. Toute l’équipe — y compris le Maître d’Agilité et le Product Owner — doit participer. Une rétrospective d’une heure est généralement suffisante. Cette réunion permet à l’équipe de réfléchir à :
- Qu’est-ce qu’on devrait commencer à faire ?
- Qu’est-ce qu’on devrait cesser de faire ?
- Qu’est-ce qu’on devrait continuer à faire ?
L’objectif est d’améliorer continuellement l’efficacité de l’équipe.
Affinage du backlog
Pensez au backlog produit comme à la carte routière du projet. Au fur et à mesure que l’équipe collabore, elle crée et met à jour une liste de tous les éléments nécessaires pour finaliser le projet, en veillant à ce que toutes les exigences soient satisfaites.
Sprints
Dans le cadre de Scrum, toutes les activités nécessaires pour mettre en œuvre un élément du backlog produit Scrum sont effectuées au cours d’un Sprint (également appelé « itération »). Les Sprints sont toujours courts — généralement de 2 à 4 semaines. Chaque Sprint suit un processus défini, comme indiqué ci-dessous :
Comme indiqué, les éléments du backlog produit sont prioritaires et sélectionnés pour le backlog du Sprint. Un Sprint ne contient que quelques éléments majeurs — toute sous-estimation du travail pour un seul élément peut avoir un impact significatif sur le Sprint. Étant donné que les éléments plus grands sont souvent plus difficiles à estimer et à comprendre, le risque d’échec du Sprint augmente. Les équipes Scrum expérimentées consacrent du temps et des efforts à décomposer les éléments complexes ou volumineux (par exemple, des fonctionnalités utilisateur ou des Épisodes) en petites histoires utilisateur (ou encore en tâches ou sous-tâches).
Épisode
Un Épisode capture un grand volume de travail. Il s’agit essentiellement d’une « grande histoire utilisateur » qui peut être décomposée en de nombreuses petites histoires. La réalisation d’un Épisode peut prendre plusieurs Sprints. Par conséquent, lors de l’utilisation d’Épisodes dans le développement, ils doivent être décomposés en petites histoires utilisateur.
Les Épisodes sont introduits tôt dans le cycle de vie du projet. Ils sont de niveau élevé, presque centrés sur le marketing et les fonctionnalités.
Nous appelons les grandes histoires « Épisodes » pour indiquer leur ampleur. Pensez-y comme un film. Si je vous dis qu’un film est un « film d’action-aventure », vous avez une idée de ce à quoi vous attendre — peut-être des poursuites en voiture, des fusillades, etc. De même, étiqueter une histoire comme « Épisode » peut parfois transmettre un contexte supplémentaire.
Histoire utilisateur
Une histoire utilisateur est une brève déclaration d’une exigence produit ou d’un cas commercial. Elle est généralement rédigée dans un langage simple pour aider les lecteurs à comprendre ce que le logiciel doit faire. Le Product Owner crée l’histoire. Ensuite, les membres de l’équipe Scrum la décomposent en une ou plusieurs tâches Scrum.
Les histoires d’utilisateurs sont généralement des fonctionnalités visibles pour l’utilisateur final. Elles suivent le format : « Je veux [faire quelque chose] afin que [je puisse atteindre un objectif]. » Elles apportent de la valeur au client/utilisateur. Il s’agit de la demande du produit du client.
Exemple : « En tant que client, je souhaite créer un compte afin de pouvoir consulter mes achats de l’année dernière pour m’aider à planifier mon budget l’année prochaine. »
Tâche
En revanche, une tâche est plus technique. Les tâches impliquent souvent du code, de la conception, la création de données de test, de l’automatisation, etc. Ce sont généralement des responsabilités individuelles. Les tâches ne sont pas rédigées selon le format d’histoire utilisateur. Elles sont plus techniques.
Exemple : « Évaluer l’angle de l’interface utilisateur en utilisant Material Design » ou « Soumettre l’application à l’App Store. »
English
Arabic
Chinese (Simplified)
Dutch
French
German
Italian
Japanese
Korean
Portuguese
Russian
Spanish