Comment fonctionne une équipe Scrum ? – Guide rapide

• Propriétaire de produit
• Master Scrum
• Équipe de développement

Auto-organisée et pluridisciplinaire

Dans Scrum, l’équipe est auto-organisée et pluridisciplinaire:

• Équipe auto-organisée choisit la meilleure façon de mener à bien son travail — plutôt que d’être dirigée par quelqu’un en dehors de l’équipe.
• Équipe pluridisciplinaire possède toutes les compétences nécessaires pour accomplir le travail, sans dépendre de personnes en dehors de l’équipe. Le modèle d’équipe Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité.

Comment les équipes Scrum collaborent-elles efficacement ?

Les équipes Scrum livrent le produit de manière incrémentale et itérative, maximisant les opportunités de retour d’information. Livrer une incrémentation de produit « terminée » garantit qu’une version potentiellement livrable est toujours disponible.

Scrum est défini par un ensemble de principes (ou les 5 valeurs Scrum), qui doivent être compris comme des guides simples pour travailler efficacement au sein de l’équipe. Ce sont :

• Courage – surtout lorsqu’il s’agit de résoudre des problèmes difficiles
• Concentration
• Engagementaux objectifs communs de l’équipe
• Respect pour les membres de l’équipe
• Ouverture au travail et à tout défi qui pourrait survenir

Concepts clés de Scrum

Scrum se compose d’une série deSprints ou itérations de développement. Chaque sprint Scrum implique le même processus : Rôles (personnes), Événements (réunions) etArtifacts (livrables tangibles).

• Un sprint est un cycle de développement répétitif jusqu’à ce que le projet soit terminé.
• Pendant chaque sprint, les exigences sont développées, testées, intégrées et approuvées (souvent sous forme d’histoires d’utilisateurs). Ce processus se poursuit d’un sprint à l’autre.

Comme mentionné précédemment, le cadre Scrum se compose de trois catégories distinctes :Rôles, Événements, etArtifacts:

Rôles Scrum

Le cadre Scrum est défini par trois rôles fondamentaux : l’équipe de développement, le maître Scrum et le propriétaire du produit.

Propriétaire du produit

Le propriétaire du produit est responsable de maximiser la valeur du produit et du travail de l’équipe de développement. La manière dont cela est réalisé peut varier selon l’organisation, l’équipe Scrum et l’individu.

Rôle du propriétaire du produit

Le propriétaire du produit est la seule personne responsable de la gestion duProduct Backlog. La gestion du Product Backlog inclut :

• Exprimer clairement les éléments du Product Backlog ;
• Classer les éléments du Product Backlog pour mieux atteindre les objectifs et les buts ;
• Optimiser la valeur du travail effectué par l’équipe de développement ;
• S’assurer que le Product Backlog est visible, transparent et clair pour tous, en montrant ce que l’équipe Scrum va travailler ensuite ; et
• Assurer que l’équipe de développement comprend les éléments du backlog produit au niveau requis.

Maître de cérémonie

Le maître de cérémonie est responsable d’assurer que le Scrum soit compris et mis en œuvre. Les maîtres de cérémonie y parviennent en veillant à ce que l’équipe Scrum respecte la théorie, les pratiques et les règles du Scrum.

Le maître de cérémonie est un leader servant pour l’équipe Scrum. Le maître de cérémonie aide les personnes extérieures à l’équipe Scrum à comprendre quelles interactions avec l’équipe sont utiles et lesquelles ne le sont pas. Le maître de cérémonie aide tout le monde à modifier ces interactions afin de maximiser la valeur créée par l’équipe Scrum.

Rôle du maître de cérémonie

Le maître de cérémonie soutient le propriétaire produit de diverses manières, notamment :

• Identifier des techniques efficaces de gestion du backlog produit ;
• Aider l’équipe Scrum à comprendre la nécessité d’avoir des éléments de backlog produit clairs et concis ;
• Comprendre la planification produit dans un environnement empirique ;
• S’assurer que le propriétaire produit sait comment ordonner le backlog produit afin de maximiser la valeur ;
• Comprendre et pratiquer l’agilité ; et
• FaciliterÉvénements Scrum selon les besoins.

Le maître de cérémonie soutient l’équipe de développement

Le maître de cérémonie soutient l’équipe de développement de diverses manières, notamment :

• Accompagner l’équipe de développement dans l’auto-organisation et la multidisciplinarité ;
• Aider l’équipe de développement à livrer des produits à haute valeur ;
• Éliminer les obstacles qui freinent la progression de l’équipe ;
• Faciliter les événements Scrum selon les besoins ; et
• Accompagner l’équipe de développement dans les organisations où le Scrum n’est pas encore pleinement adopté ou compris.

Le maître de cérémonie soutient l’organisation

• Le maître de cérémonie soutient l’organisation de multiples manières, notamment :
• Diriger et guider l’adoption du Scrum au sein de l’organisation ;
• Planifier la mise en œuvre du Scrum au sein de l’organisation ;
• Aider les employés et les parties prenantes à comprendre et adopter le Scrum et le développement produit empirique ;
• Piloter les changements pour améliorer la productivité des équipes Scrum ; et
• Collaborer avec d’autres maîtres de cérémonie pour améliorer l’efficacité du Scrum à travers l’organisation.

Équipe de développement

L’équipe de développement se compose de professionnels qui livrent un incrément produit « Terminé » potentiellement livrable à la fin de chaque sprint. Seuls les membres de l’équipe de développement peuvent créer cet incrément.

L’équipe de développement est autonome et dotée de pouvoirs par l’organisation pour organiser et gérer son propre travail. Cette synergie optimise l’efficacité et l’efficacité globales de l’équipe.

Rôle de l’équipe de développement

L’équipe de développement possède les caractéristiques suivantes :

• Ils sont autogérés. Personne (pas même le Scrum Master) ne dit à l’équipe de développement comment transformer les éléments du backlog produit en un incrément potentiellement livrable.
• L’équipe de développement est pluridisciplinaire, disposant de toutes les compétences nécessaires pour créer l’incrément produit.
• Scrum ne reconnaît aucun titre autre que « Développeur » pour les membres de l’équipe de développement, quelle que soit la tâche accomplie. Cette règle ne connaît aucune exception.
• Scrum ne reconnaît aucune sous-équipes au sein de l’équipe de développement, quelle que soit la spécialité traitée (par exemple, test ou analyse métier). Cette règle ne connaît aucune exception.
• Les membres individuels de l’équipe peuvent posséder des compétences et des expertises spécialisées, mais la responsabilité incombe à l’ensemble de l’équipe de développement.

Événements Scrum

Le cadre Scrum est marqué par cinq événements. Ce sont : Sprint, Planification du Sprint, Daily Scrum, Revue du Sprint, et Rétrospective du Sprint.

• Une Sprint (appelé aussi itération) est l’unité fondamentale de développement dans Scrum. Un Sprint est un effort limité dans le temps effort, ce qui signifie qu’il est limité à une durée précise. La durée de chaque Sprint est prédéterminée, généralement comprise entre une et quatre semaines, le plus souvent deux semaines.
• Planification du Sprint est un événement dans le cadre Scrum où l’équipe détermine quels éléments du backlog produit elle va traiter pendant le Sprint et discute de son plan initial pour les accomplir.
• Une Daily Stand-up (appelé aussi Daily Scrum) est une réunion courte et limitée dans le temps, tenue chaque jour. Cette réunion est généralement limitée à 5 à 15 minutes et est parfois appelée stand-up, huddle matinal ou synchronisation quotidienne.
• La Revue du Sprint a lieu après la fin du Sprint. Lors de la revue, le Product Owner explique ce qui a été accompli et ce qui n’a pas été accompli pendant le Sprint. Ensuite, l’équipe présente le travail accompli et discute des progrès, des défis et des moyens d’amélioration.
• Le Retrospective de Sprint a lieu après chaque Sprint, suivant la revue de Sprint. Elle offre à l’équipe l’occasion d’effectuer une auto-évaluation et de concevoir un plan d’amélioration pour le prochain Sprint.

Artifacts Scrum

Les artifacts sont des documents physiques qui fournissent des informations détaillées sur le projet. Les artifacts Scrum incluent le Product Backlog, Sprint Backlog, et les Increments de produit.

• Le Product Backlog est une liste priorisée de fonctionnalités, de bogues ou de travaux techniques qui ne sont actuellement pas en cours. Du point de vue du Product Owner, elle doit inclure tout travail pertinent.
• À mesure que les exigences du produit évoluent, le Product Owner et les autres membres de l’équipe examinent et ajustent conjointement le Product Backlog selon les besoins.
• Le Sprint Backlog est une liste de tous les éléments du Product Backlog sélectionnés pour le Sprint. Cette liste est établie en priorisant les éléments du Product Backlog jusqu’à ce que l’équipe estime avoir atteint sa capacité de Sprint. Les membres de l’équipe enregistrent les tâches dans le Sprint Backlog en fonction de leurs compétences et de leurs priorités, conformément au cadre Scrum auto-organisé.
• Le Product Increment est la somme de tout le travail produit accompli pendant le Sprint, ajouté au travail accompli dans les Sprints précédents. L’objectif du Sprint est de produire un increment de produit « Terminé ». L’équipe Scrum décide ce qui définit l’état « Terminé » de l’increment, mais tous les membres doivent être d’accord et comprendre cette définition.

Cycle de vie Scrum

Le cycle de vie Scrum commence par le Product Backlog, mais ne fournit aucune orientation sur la manière de le développer ou de le prioriser. À la place, il comprend une série de Sprints qui aboutissent finalement à un increment de produit potentiellement livrable, comme indiqué dans le schéma ci-dessous.

Pendant ces Sprints, toutes les activités nécessaires au développement du produit ont lieu sur une petite partie du produit global. Voici une explication des étapes clés du cycle de vie Scrum :

Cadre Agile Scrum

• Les entreprises priorisent, et l’équipe s’organise elle-même pour déterminer la meilleure façon de livrer les fonctionnalités les plus prioritaires.
• Le Product Owner représente l’entreprise, chargé de maintenir le Product Backlog (liste des fonctionnalités) et de fixer les priorités de développement.
• Pendant la planification du Sprint, l’équipe extrait une petite partie du haut du backlog, l’ajoute au Sprint Backlog et décide comment la livrer.
• Scrum repose sur des cycles itératifs appelés Sprints, généralement de 2 à 4 semaines, durant lesquels le produit est conçu, codé et testé, tandis que les réunions quotidiennes suivent les progrès (Daily Scrum).
• Pendant ce processus, le Scrum Master maintient l’équipe concentrée sur ses objectifs.
• À la fin du Sprint, le travail doit être prêt à être livré aux parties prenantes.
• Le sprint se termine par une revue de sprint et une rétrospective.
• Avec le prochain sprint, l’équipe sélectionne une autre partie du backlog produit et recommence.
• Le processus continue jusqu’à ce que tout le backlog soit terminé ou jusqu’à ce que le travail s’arrête en raison de contraintes de temps ou de budget.
• Cela continue jusqu’à ce que le projet soit considéré comme terminé, soit lorsque le travail s’arrête (date limite, budget, etc.), soit lorsque tout le backlog est terminé.