Aperçu de Scrum

Aperçu de Scrum

Dans Scrum, le chef de projet s’appelle le Maître de Scrum, et l’équipe de projet s’appelle l’équipe Scrum. Il y a un propriétaire de produit qui priorise les fonctionnalités et les exigences à développer dans le Backlog du produit.

La méthodologie Scrum utilise des sprints pour livrer de petits incrémentes de travail et recueillir des retours des clients.

Il y a trois (3) piliers de Scrum :

SCRUMmet en œuvre une approche empirique (parfois appelée empirisme) pour s’adapter aux besoins changeants des clients. L’empirisme consiste à prendre des décisions fondées sur l’expérience concrète. Une approche empirique signifie travailler de manière fondée sur des faits, sur l’expérience et sur des preuves — en particulier lorsque l’avancement repose sur l’observation de la réalité plutôt que sur des plans détaillés élaborés à l’avance basés sur des exigences initiales étendues.

En résumé, nous apprenons et nous nous améliorons à partir des erreurs et des expériences passées. Les trois piliers de Scrum qui soutiennent le contrôle empirique des processus dans chaque mise en œuvre sont : la Transparence, l’Inspection et l’Adaptation, comme indiqué dans le schéma ci-dessous :

The Three Pillars of Scrum

  • Transparence — Un langage commun et des normes pour assurer la cohérence et une compréhension partagée.
  • Inspection — Revue fréquente de l’avancement de Scrum et des livrables pour obtenir des retours. Il est important de ne pas cacher l’avancement du projet.
  • Adaptation — Intégrer facilement les retours reçus et traiter les problèmes dès qu’ils surviennent.

Composants du processus Scrum

Le cadre Scrumlui-même est très simple. Il définit seulement quelques principes généraux, ainsi qu’un petit ensemble de règles, rôles, artefacts, et événements. Cependant, chacun de ces composants est important, remplit un objectif spécifique et est essentiel pour utiliser avec succès le cadre.

Les principaux composants du cadre Scrum sont :

Le diagramme ci-dessous illustre les éléments clés du cadre SCRUM. Ce processus a été mis en œuvre dans le Outil logiciel Agile — Planche de processus Scrum.

Scrum Framework
Cadre Scrum

Rôles Scrum

Lorsqu’une organisation décide d’adopter Scrum, l’une des premières choses à comprendre est la différence entre les rôles Scrum et les rôles traditionnels d’exécution de projet. Bien que Scrum ne comporte que trois rôles principaux, ils ne s’alignent pas automatiquement avec les titres auxquels la plupart d’entre nous sont familiers. Commençons par une brève définition de chacun :

Propriétaire du produit

Le propriétaire du produit est le rôle Scrum chargé de représenter l’entreprise ou la communauté des utilisateurs et de collaborer avec les groupes d’utilisateurs pour déterminer quelles fonctionnalités seront incluses dans les versions du produit. Les principales responsabilités du propriétaire du produit sont :

  • Définir la direction et la stratégie du produit ou du service, y compris les objectifs à court et à long terme ;
  • Fournir ou obtenir des connaissances sur le produit ou le service ;
  • Aider l’équipe de développement à comprendre et à interpréter les besoins des clients ;
  • Recueillir, prioriser et gérer les exigences du produit ou du service ;
  • Assumer la responsabilité de toutes les tâches liées au budget du produit ou du service, y compris sa rentabilité ;
  • Déterminer les dates de mise en production des fonctionnalités du produit ou du service ;
  • Répondre aux questions et prendre des décisions quotidiennement avec l’équipe de développement ;
  • Accepter ou rejeter les fonctionnalités terminées liées au Sprint ;
  • Démontrer les livrables clés de l’équipe de développement à la fin de chaque Sprint ;
  • Être responsable du Product Backlog.

Master Scrum

Le Master Scrum est le facilitateur de l’équipe de développement agile. Scrum est une méthode qui permet aux équipes de s’auto-organiser et de réaliser des changements rapides conformément aux principes agiles. Le Master Scrum gère le processus d’échange d’informations. Les principales responsabilités du Master Scrum sont :

  • Agir en tant que coach pour aider l’équipe à respecter les valeurs et les pratiques Scrum ;
  • Aider à éliminer les obstacles et protéger l’équipe contre les interférences extérieures ;
  • Faciliter une bonne collaboration entre l’équipe et les parties prenantes ;
  • Promouvoir le bon sens au sein de l’équipe ;
  • Protéger l’équipe contre les interférences organisationnelles.

Équipe Scrum

L’Équipe Scrum (également appelée Équipe de développement) se compose de 3 à 9 personnes qui possèdent collectivement toutes les compétences techniques nécessaires pour livrer le produit ou le service. Elles sont directement accompagnées par le Master Scrum mais ne sont pas directement gérées. Elles doivent être auto-organisées, polyvalentes et suffisamment responsables pour accomplir toutes les tâches requises.

L’Équipe de développement est responsable de la livraison d’incréments de produit potentiellement livrables à chaque Sprint — de l’analyse, à la conception, au développement, aux tests, jusqu’à l’écriture technique. Les caractéristiques clés de l’Équipe Scrum incluent :

  • L’équipe doit être auto-organisée. Tous les membres de l’équipe doivent gérer leurs propres efforts pour accomplir les tâches assignées. Dans Scrum agile, il n’existe pas de chef d’équipe ou de figure de gestion hiérarchique. Chacun doit être suffisamment engagé pour mener à bien ses activités et contribuer au succès de l’équipe. Si l’un échoue, tout le monde échoue.
  • L’équipe doit être pluridisciplinaire. Tous les membres de l’équipe doivent posséder les connaissances et les compétences nécessaires pour livrer un service ou un produit complets et prêts à être utilisés. Des experts peuvent être utilisés si nécessaire, mais uniquement comme coachs pour transmettre des connaissances à l’équipe et combler des lacunes spécifiques.
  • Le Product Owner doit avoir une vision commerciale. Le Product Owner représente la voix du client et doit transmettre leurs besoins au Master Scrum et à l’Équipe de développement. Il s’agit généralement d’un poste à temps plein.
  • Le Master Scrum n’est pas un gestionnaire hiérarchique. Ils fournissent le coaching nécessaire à l’Équipe de développement et aident à éliminer tous les obstacles auxquels l’équipe est confrontée.

Product Backlog

Il s’agit d’une liste ordonnée de tous les travaux à accomplir sur le projet. Elle est présentée sous forme d’histoires, communément appelées user stories.

User Stories — Des représentations différentes de la manière dont les utilisateurs interagissent avec les livrables du projet (produit, service ou résultat). À travers les user stories, l’équipe identifie les fonctionnalités et caractéristiques nécessaires aux livrables.

Par conséquent, le Product Backlog contient des user stories prioritaires (fonctionnalités et caractéristiques) pour le produit/service/résultat. Le Product Owner est responsable de la priorisation du backlog.

Remarque : Vous n’avez pas besoin de créer toutes les histoires pour l’ensemble du projet avant de commencer le travail (c’est l’un des avantages de l’approche agile). Commencez par les histoires que vous connaissez, et au fur et à mesure que vous en apprenez davantage, ajoutez des éléments à la liste de backlog et réorganisez les priorités selon les besoins.

Planification du Sprint

Contrairement à l’approche en cascade, les équipes agiles ne planifient pas tout à l’avance. Ici, l’équipe planifie un peu : ce qui est nécessaire pour le Sprint en cours (les Sprints durent généralement de 2 à 4 semaines), le livrable, en tire des enseignements, puis planifie à nouveau le prochain Sprint.

L’équipe Scrum examine le backlog produit et sélectionne le nombre d’histoires utilisateur qu’elle peut accomplir dans le délai du Sprint. Les histoires utilisateur sélectionnées deviennent le backlog du Sprint. Le backlog du Sprint représente l’objectif du Sprint.

La définition de « terminé » est également établie. La définition de « terminé » peut être considérée comme les critères d’acceptation des éléments du backlog.

Planifiez uniquement le travail qui correspond à la capacité de l’équipe, c’est-à-dire le travail que l’équipe peut réellement accomplir durant chaque Sprint.

Réunion quotidienne Scrum (stand-up quotidien)

L’équipe utilise cette réunion pour s’engager mutuellement sur de petits objectifs, identifier les problèmes et s’assurer que le travail du Sprint se déroule sans heurt au sein de l’équipe. Elle dure généralement 15 minutes. L’équipe répond aux questions suivantes :

  • Qu’ai-je terminé depuis la dernière réunion Scrum ?
  • Quel est mon plan pour aujourd’hui ? Qu’est-ce que je compte terminer entre maintenant et la prochaine réunion Scrum ?
  • Y a-t-il des obstacles (problèmes, difficultés ou risques) qui me bloquent ?

Souvenez-vous, cette réunion n’est pas une réunion de suivi des statuts — elle n’est pas destinée à résoudre les problèmes, mais à prendre conscience des problèmes (le cas échéant). Si une réunion est nécessaire pour résoudre les problèmes, organisez-la séparément.

Réunion de revue du Sprint

À la fin de chaque Sprint, l’équipe démontre tous les éléments de travail terminés. Cette réunion de revue sert à recevoir des retours des parties prenantes du projet et toute demande de modification.

Il est important de noter que les éléments de travail non entièrement terminés selon la définition de « terminé » établie lors de la planification ne seront pas démontrés, car ils ne sont pas « terminés ».

Réunion de rétrospective du Sprint

Cela a lieu après la réunion de revue du Sprint. L’objectif est d’aider l’équipe à tirer des enseignements du Sprint. Le processus se concentre sur l’amélioration continue plutôt que sur le blâme de l’équipe si les choses ne se sont pas bien déroulées pendant le Sprint.

L’équipe réfléchit sur la manière de devenir plus efficace et identifie d’autres domaines d’amélioration.

Le Maître Scrum classe l’importance de chaque élément d’amélioration, puis l’équipe choisit un nombre approprié d’éléments d’amélioration à mettre en œuvre dans le prochain Sprint.

Leave a Reply