Cet article va vous présenter un résumé du guide de référence de Scrum. Vous y trouverez la définition des rôles, des événements, des artefacts ainsi que les règles de Scrum. Le but est de comprendre Scrum en moins de 10 min.

La version complète du guide Scrum en français est disponible sur la page de téléchargement du guide officiel de Scrum.

But du Guide Scrum

Scrum est un cadre de travail ou framework en anglais pour le développement, la livraison et la maintenance  de produits complexes. Ce guide contient la définition de Scrum. Cette définition comprend les rôles, les événements, les artefacts et les règles de Scrum. Ken Schwaber  et Jeff Sutherland ont développé Scrum et ont écrit le guide Scrum.

Définition de Scrum

Scrum(n) : Un cadre de travail (framework) dans lequel les personnes peuvent aborder des problèmes complexes et adaptatifs tout en livrant de manière efficace et créative des produits de la plus grande valeur possible.

Scrum est :

  • Léger
  • Simple à comprendre
  • Difficile à maîtriser

Usages de Scrum

Scrum a été initialement développé pour la gestion et le développement de produits. Depuis le début des années 1990, Scrum a été largement utilisé dans le monde entier pour :

  1. Rechercher et identifier des marchés, des technologies et des caractéristiques produit viables ;
  2. Développer des produits et des améliorations ;
  3. Publier des produits et des améliorations, jusqu’à plusieurs fois par jour ;
  4. Développer et maintenir des environnements Cloud (en ligne, sécurisé, à la demande) et d’autres environnements d’exploitation de produits ; et,
  5. Maintenir et renouveler des produits.

Scrum a été utilisé pour développer des logiciels, du matériel, des logiciels embarqués, des réseaux de fonctions interactives, des véhicules autonomes, des écoles, des gouvernements, du marketing, de la gestion opérationnelle des organisations et presque tout ce que nous utilisons dans notre vie quotidienne.

Théorie de Scrum

Scrum est fondé sur la théorie du contrôle empirique de processus, ou l’empirisme. L’empirisme affirme que la connaissance provient de l’expérience et la prise de décisions est basée sur des faits connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et le contrôle de risque.

Trois piliers soutiennent l’implémentation d’un contrôle empirique de processus: la transparence, l’inspection et l’adaptation.

Transparence

Les aspects importants du processus doivent être visibles à tous ceux qui sont responsables des résultats. La transparence requiert la définition d’un standard commun pour ces aspects afin que les observateurs partagent une compréhension commune de ce qui est observé.

À titre d’exemple :

  • Un langage commun faisant référence au processus doit être partagé par tous les participants ; et,
  • Ceux qui effectuent le travail et ceux qui inspectent l’incrément résultant doivent partager une définition commune de « Fini » (Definition of Done).

Inspection

Les utilisateurs de Scrum doivent fréquemment inspecter les artefacts Scrum et l’état d’avancement par rapport à un Objectif de Sprint (Sprint Goal) afin de détecter les écarts indésirables. La fréquence de ces inspections ne devrait pas gêner le travail en cours. Ces inspections sont plus bénéfiques lorsqu’elles sont effectuées avec diligence par des inspecteurs qualifiés sur les lieux de travail.

Adaptation

Si un inspecteur détermine qu’un ou plusieurs aspects du processus dérivent hors des limites acceptables, et que le produit qui en résulte ne sera pas acceptable, le processus ou le matériel utilisé par le processus doit être ajusté. Un ajustement doit être fait dès que possible afin de minimiser le risque d’autres dérives.

Scrum prescrit quatre événements formels d’inspection et d’adaptation, tels que décrit dans la section événements Scrum :

  • Planification du Sprint (Sprint Planning)
  • Mêlée Quotidienne (Daily Scrum)
  • Revue de sprint (Sprint Review)
  • Rétrospective de Sprint (Sprint Retrospective)

Valeurs Scrum

Lorsque les valeurs d’engagement, courage, focus, ouverture et respect sont incarnées et vécues par l’équipe Scrum, les piliers Scrum de transparence, d’inspection et d’adaptation émergent et consolident la confiance entre tout le monde. Les membres de l’équipe Scrum apprennent et explorent ces valeurs au fur et à mesure qu’ils travaillent avec les événements, les rôles et les artefacts de Scrum.

La bonne application de Scrum repose sur des personnes de plus en plus à même de vivre avec ces cinq valeurs. Ces personnes s’engagent, personnellement, à atteindre les objectifs de l’équipe Scrum. Les membres de l’équipe Scrum ont le courage de faire les bonnes choses et de résoudre les problèmes difficiles. Tout le monde se concentre et se focalise sur le travail à faire durant le Sprint et les objectifs de l’équipe Scrum. L’équipe Scrum et ses parties prenantes acceptent d’être ouvertes sur tout le travail et les défis impliqués par l’accomplissement de ce travail. Les membres de l’équipe Scrum se respectent mutuellement en tant que personnes compétentes et indépendantes.

Équipe Scrum

Une équipe Scrum comprend un Product Owner, une équipe de développement (Development Team) et un Scrum Master. Les équipes Scrum (Scrum Teams) sont auto-organisées et pluridisciplinaires. Les équipes auto-organisées choisissent la meilleure façon d’accomplir leur travail, au lieu d’être dirigées par des personnes externes à l’équipe. Les équipes pluridisciplinaires ont toutes les compétences nécessaires pour effectuer le travail sans dépendre d’autres personnes n’appartenant pas à l’équipe. Scrum définit un modèle d’équipe optimisant la flexibilité, la créativité et la productivité. L’équipe de Scrum s’est révélée être de plus en plus efficace dans toutes les précédentes applications, ainsi que dans tout autre travail complexe.

Les équipes Scrum livrent des produits de manière itérative et incrémentale, maximisant ainsi les opportunités de retour d’information. Les livraisons incrémentales d’un produit « Fini » assurent la disponibilité d’une version potentiellement utile du produit fonctionnel.

Le Product Owner

Le Product Owner est responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement. La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus.

Le Product Owner est le seul responsable de la gestion du Backlog Produit (Product Backlog). La gestion du Backlog Produit comprend :

  • L’expression claire des éléments du Backlog produit ;
  • L’ordonnancement des éléments dans le Backlog produit pour mieux réaliser les objectifs et les missions ;
  • L’optimisation de la valeur du travail effectué par l’équipe de développement ;
  • L’assurance que le Backlog produit est visible, transparent et clair pour tous, et montre sur quoi l’équipe de développement travaillera prochainement ; et,
  • L’assurance que l’équipe de développement comprend adéquatement les éléments du Backlog produit.

Le Product Owner peut lui-même accomplir les tâches susmentionnées ou les déléguer à l’équipe de Développement. Toutefois, le Product Owner en demeure responsable.

Le Product Owner est une personne, et non un comité. Le Product Owner peut représenter les désirs d’un comité dans le Backlog Produit, mais ceux qui veulent changer la priorité d’un élément du Backlog Produit (Product Backlog Item PBI) doivent consulter le Product Owner.

Afin que le Product Owner réussisse dans sa démarche, toute l’organisation doit respecter ses décisions. Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du Backlog produit. Nul ne peut forcer l’équipe de développement à travailler à partir d’un autre ensemble d’exigences.

L’équipe de Développement

L’équipe de développement se compose de professionnels qui fournissent un incrément « Fini » potentiellement publiable (Releasable) à la fin de chaque Sprint. Un incrément « Fini » est requis à la revue de sprint. Seuls les membres de l’équipe de développement créent l’incrément.

Les équipes de développement sont structurées et habilitées par l’organisation à s’organiser et gérer leur propre travail. La synergie résultante optimise l’efficience et l’efficacité globale de l’équipe de développement.

Les équipes de développement ont les caractéristiques suivantes :

  • Elles sont auto-organisées. Nul (pas même le Scrum Master) n’indique à l’équipe de développement comment transformer les éléments du Backlog Produit en incréments de fonctionnalités potentiellement publiables ;
  • Elles sont pluridisciplinaires, avec toutes les compétences nécessaires, en tant qu’équipe, pour créer un incrément produit ;
  • Scrum ne reconnaît aucun titre aux membres de l’équipe de développement, indépendamment du travail effectué par une personne ;
  • Scrum ne reconnaît pas d’équipes au sein de l’équipe de développement indépendamment des domaines qui doivent être couverts tels que l’exécution de tests, l’architecture, la gestion opérationnelle ou l’analyse fonctionnelle ; et,
  • Les membres de l’équipe de développement peuvent détenir individuellement des compétences et des centres d’intérêt spécifiques, mais c’est l’équipe de développement dans son ensemble qui est tenue responsable.

Taille de l’équipe de développement

La taille optimale de l’équipe de développement doit être suffisamment petite pour rester réactive et assez grande pour accomplir un travail significatif durant le Sprint. Le fait d’avoir une équipe de développement de moins de trois membres, réduit l’interaction et produit de faibles gains de productivité. Durant un Sprint, les petites équipes de développement peuvent rencontrer des contraintes liées aux compétences ce qui les empêchent à livrer un incrément potentiellement publiable. À l’opposé, une équipe de plus de neuf membres implique trop de coordination. Les grandes équipes de développement engendrent trop de complexité pour qu’un processus empirique soit utile. Les rôles de Product Owner et Scrum Master ne sont pas inclus dans l’équipe de développement, à moins qu’ils aient également des tâches dans le Backlog Sprint.

Le Scrum Master

Les événements Scrum

Le Sprint

Planification du Sprint

Daily Scrum

Revue de sprint

Rétrospective de Sprint

Les artefacts de Scrum

Backlog Produit

Backlog Sprint

Incrément

Artefact de Transparence

Définition de « Fini »

Note de Fin

Liens