Scrum -Concept de base-

Nous allons voir dans cet article une vue rapide de l’approche Scrumdans la gestion de projet

Scrum est un cadre de travail permettant de répondre à des problèmes complexes et changeants, tout en livrant de manière productive et créative des produits de la plus grande valeur possible.

Scrum est ;

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

Scrum est utilisé depuis le début des années 1990 pour gérer le développement de produits complexes. Scrum n’est pas en soi un processus ni une méthode de développement de produits. Il s’agit d’un canevas pour l’application de divers procédés et techniques de développement. Scrum met en évidence l’efficacité relative des pratiques de gestion et de développement de produit en place, de sorte que ces dernières puissent être améliorées

Théorie de Scrum

Scrum se base sur la théorie du contrôle empirique de processus ou l’empirisme. L’empirisme soutient que les connaissances proviennent de l’expérience et d’une prise de décision basée sur des faits connus. Scrum utilise une approche itérative et incrémentale pour optimiser la prédictibilité et pour contrôler le risque.

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

Le Product Owner

Le Product Owner est responsable de maximiser la valeur du produit et du travail de l’équipe de développement. Il est la seule personne responsable de gérer le Product Backlog. La gestion de ce Product Backlog comprend :

• Exprimer clairement les items du Product Backlog
• Ordonner les items du Product Backlog pour mieux réaliser les objectifs et missions
• 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

Afin que le Product Owner réussisse dans sa démarche, tous les intervenants de l’entreprise doivent respecter ses décisions. Les décisions du Product Owner sont visibles dans le contenu et l’ordonnancement du Product Backlog. Nul n’est permis de demander à l’équipe de développement de travailler à partir d’un autre ensemble de beosin

L’équipe de développement

L’équipe de développement est constitué de professionnels qui livrent à chaque Sprint un incrément terminé et potentiellement livrable du produit. Seuls les membres de l’équipe de développement créent l’incrément.

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

• Elle est auto-organisée. Nul (même pas le Scrum Master) n’indique à l’équipe de développement comment transformer les items du Product Backlog en incréments de fonctionnalités potentiellement livrables
• Elle est pluridisciplinaire avec toutes les compétences nécessaires pour créer un incrément du produit.

Taille de l’équipe de développement

La taille optimale de l’équipe de développement est suffisamment petite pour que l’équipe soit flexible et réactive tout en étant grande pour qu’elle soit en mesure d’accomplir un travail significatif durant le sprint. Lorsque l’équipe de développement est composée de moins de trois personnes le niveau d’interaction est réduit et les gains de productivité moins importants. Une telle équipe peut rencontrer des difficultés à livrer un incrément de logiciel en raison de compétences limitées. à l’opposé, une équipe de plus de neuf membres implique trop de coordination. Les grandes équipes de développement engendrent des interactions trop complexes pour être gérées efficacement par un processus empirique. Le Scrum Master et le Product Owner ne sont pas pris en compte dans la taille de l’équipe.

Le Scrum Master

Le Scrum Master est responsable de s’assurer que Scrum est compris et mis en oeuvre. Les Scurm Masters remplissent leur rôle en s’assurant que l’équipe Scrum adhère à la théorie, aux pratiques et aux règles de Scrum.

Le Scrum Master est un leader au service de l’équipe Scrum.

1. Le Scrum Master au service du Product Owner : ses services consistent à :
   • Trouver des techniques de gestion efficace du Product Backlog
   • Aider l’équipe Scrum à comprendre la nécessité d’avoir des items de Product Backlog clairs et concis
   • S’assurer que le Product Owner sait comment constituer le Product Backlog pour maximiser la valeur du produit
   • Comprendre et mettre en oeuvre l’agilité et facilité les événements Scrum lorsque requis ou demandé
2. Le Scrum Master au service de l’organisation : ses services consistent à :
   • Accompagner l’organisation dans son adoption de Scrum
   • Planifier les mises en oeuvre de Scrum dans l’organisation
   • Causer des changements qui augmentent la productivité de l’équipe Scrum

Les événements Scrum

Les événements prescrits par Scrum créent de la régularité et minimisent la nécessité d’autres réunions non prévus. Tous les événements sont limités dans le temps, de telle sorte chaque événement ait une durée maximale. Une fois le Sprint commencé, sa durée est fixe et ne peut être écourtée ou prolongée. Les autres objectifs peuvent se terminer une fois les objectifs de ceux-ci atteints. Ces événements sont conçus spécifiquement pour permettre transparence et inspection

Le Sprint

Au cœur de Scrum, le Sprint a une durée d’un mois ou moins au cours duquel une version terminée, utilisable et potentiellement livrable du logiciel est créée. Il est préférable que les Sprints gardent une durée constante tout au long de l’initiative de développement. Un nouveau Sprint débute immédiatement après la conclusion du précédent.

Les Sprints contiennent et sont constitués de la planification du Sprint (Sprint Planning), des mêlées quotidiennes (Daily Scrums), des activités de développements, de la revue du Sprint (Sprint Review) et de la rétrospective du Sprint (Sprint Retrospective)

Pendant le Sprint :

• L’objectif du sprint est fixe, les changements qui le remettent en cause ne sont donc pas permis
• Les objectifs de qualité sont maintenus, ils ne sont jamais revus à la baisse
• Le périmètre peut être clarifié et renégocié entre le Product Owner et l’équipe de développement.

Chaque Sprint peut être considéré comme un projet qui dure au maximum un mois. à l’instar du projet, le sprint est utilisé pour réaliser un objectif. La définition des fonctionnalités à développer, la conception et le plan flexible qui guidera le développement, l’activité de développement en soi et le produit résultant sont associés au Sprint.

1.Planification de Sprint

Le travail à effectuer durant le Sprint est élaboré à la réunion de planification de Sprint. Ce plan est créé de manière collaborative par tous les membres de l’équipe Scrum.

La planification d’un Sprint d’un mois est limitée à 8 heures. Le Scrum Master veille à ce que l’événement ait lieu et que les participants en comprennent le but

2.Revue du Sprint

Une revue de Sprint est tenue à la fin du Sprint pour inspecter l’incrément réalisé et adapter le Product Backlog si nécessaire. Pendant la réunion de revue de Sprint, l’équipe Scrum et les parties prenantes échangent sur ce qui a été fait durant le Sprint. En se basant là-dessus et en considérant les changements au Product Backlog effectués durant le Sprint, les participants collaborent pour déterminer les prochains items ayant le plus de valeur qui pourraient être faits. Cette réunion est limitée à une boite de temps de quatre heures pour un Sprint d’un mois. LE Scrum Master s’assure que la revue a lieu et que les participants en comprennent le but

La revue du Sprint comprend les éléments suivants :

• Le Product Owner explique les items du Product Backlog qui ont été terminés et ceux qui ne l’ont pas été
• L’équipe de développement discute de ce qui s’est bien déroulé durant le Sprint, quels problèmes ont été rencontrés et comment ces problèmes ont été résolus
• L’équipe de développement démontre le travail terminé et répond aux questions sur l’incrément
• L’ensemble du groupe convient de ce qu’il faut faire pour la suite, de sorte que la revue de Sprint fournisse une contribution précieuse aux réunions de planification de Sprint subséquentes

Le résultat de cette revue est un Product Backlog révisé qui définit les items probables pour le prochain Sprint.

3.Rétrospective de Sprint

Il s’agit d’une occasion pour l’équipe Scrum de s’inspecter et de créer un plan d’amélioration qui sera mis en place au cours du Sprint suivant. La rétrospective de Sprint survient après la revue de Sprint et avant la prochaine réunion de planification de Sprint. C’est une réunion limitée à trois heures pour les Sprints d’un mois

Le but de la rétrospective de Sprint est :

• D’inspecter la manière dont le dernier Sprint s’est déroulé en ce qui concerne les personnes, les relations, les processus et les outils
• D’identifier  et ordonner les éléments majeurs qui se sont bien déroulés et les améliorations potentielles
• De créer un plan pour améliorer les processus de travail de l’équipe Scrum

Product Backlog

Le Product Backlog est une liste ordonnée de tout ce qui pourrait être requis dans le produit et l’unique source des besoins pour tous les changements à effectuer sur le produit. Le Product Owner est responsable du Product Backlog dans son contenu, sa disponibilité et son ordonnancement.

Le Product Backlog liste toutes les fonctionnalités, besoins, améliorations et correctifs correspondant aux changements devant être appliqués au produit lors de livraisons futures. Les items du Product Backlog incluent une description, un ordre, une estimation de l’effort et de valeur.

Sprint Backlog

Le Sprint Backlog est l’ensemble des items sélectionnées pour le Sprint plus un plan pour livrer l’incrément du produit et réaliser l’objectif du Sprint.

Le Sprint Backlog rend visible tout le travail que l’équipe de développement identifie comme nécessaire pour atteindre l’objectif du Sprint. Il s’agit d’un plan suffisamment détaillé pour que la progression soit compréhensible lors de la mêlée quotidienne

Référence : Le guide Scrum