Les termes Agiles et Scrum sont très souvent liés pourtant ils possèdent chacun une définition bien distincte : - Agile est un ensemble de méthodes et de pratiques basées sur les valeurs et les principes du manifest Agiles créé en 2001. - Scrum est un framework (cadre de travail) implémentant la méthode Agile au travers de la mise en place de procédure concrètes. Il est défini est travers du Scrum guide.
Ainsi que sur cinq valeurs :
- Focus : signifie que chaque membre de l'équipe connait et se concentre sur l'objectif lors de chaque événement SCRUM.
- Ouverture aux changements, cette valeur s'inscrit dans le cadre de l'adaptation et de l'agilité.
- Respect mutuel entre chaque membre de l'équipe. Les décisions sont prises collégialement par l'ensemble de l'équipe et non par un seul dirigeant.
- Courage d'entreprendre et de se tromper. L'amélioration continue et l'empirisme se base sur les erreurs passées, sans nouvelles expériences l'équipe ne progresse pas.
- Engagement chaque membre de l'équipe doit être motivé dans la réussite du projet commun.
Le Product Owner est une personne (et non un comité, même s’il peut en représenter les désirs) responsable de maximiser la valeur du produit résultant du travail de l’équipe de développement. C'est le seul responsable du Product backlog, ou “Backlog produit” en français (liste des tâches à développer dans le(s) prochain(s) sprint). La façon de jouer ce rôle peut varier grandement selon les organisations, les équipes Scrum et les individus. Il a donc pour responsabilité les actions suivantes :
- L’expression claire des éléments du Product backlog, afin que ceux-ci soient facilement compréhensibles par l'ensemble des membres de l'équipe.
- L’assurance que l'équipe de développement comprend adéquatement les éléments du Product backlog. Le PO doit s'assurer que l'équipe ai compris les éléments du Product Backlog.
- L’ordonnancement des éléments dans le Product backlog pour mieux réaliser les objectifs et les missions. En fonction de la valeur ajoutée (d'un point de vue client) apporté par chacun des éléments.
- L’optimisation de la valeur du travail effectué par l'équipe de développement. Grace au ratio temps nécessaire développement / valeur ajoutée de l'élément développé.
- L’assurance que le Product backlog est visible, transparent et clair pour tous, et montre sur quoi l’équipe de développement travaillera prochainement. Le PO doit avoir et montrer une vision claire sur le travail réalisé et en cours de réalisation par l'équipe.
Afin que le projet soit correctement mené, toute l'équipe doit respecter les décisions du PO et l'équipe ne doit travailler uniquement que sur les éléments indiqués dans le Product Backlog par le PO.
Les développeurs désigne toutes les personnes faisant partie de l'équipe et nécessaires à la réalisation de l'incrémentdu sprint.
Les incréments doivent être “fini” et potentiellement livrable/publiable à la fin de chaque Sprint. Un sprint ne peut pas se terminer sans incrément.
Les équipes de développement sont autonomes et habilitées à se structurer d'elle-même selon leurs propres besoins et ce dans l'objectif d'améliorer leur efficience ainsi que leur efficacité.
Une équipe développement possède les caractéristiques suivantes :
- Auto-gérée : personne, ni même le Scrum master ne doit dire à l'équipe comment s'organiser, il peut cependant apporter son aide et son expérience en terme d'organisation mais c'est bien l'équipe qui choisie in fine comment s'organiser pour développer au mieux les éléments du backlog.
- Pluridisciplinaire : l'équipe rassemble toutes les compétences nécessaires à la réalisation des éléments du backlog.
- Pas de distinction entre les membres d'une même équipe : aucun titre n'existe au sein de l'équipe Scrum en dehors du travail effectué par une personne.
- Une seule équipe : Il n'existe qu'une seule équipe de développement, il ne peut pas y avoir de sous équipe au sein de la même équipe. Cependant des personnes de l'équipe peuvent être affecté à un domaine particulier tel que l’exécution des tests, l'architecture, l'analyse fonctionnelle, ...
- Responsabilité commune : Les personnes composant l'équipe peuvent disposer à titre individuelle de compétences spécifique mais c'est bien l'équipe dans son ensemble qui est responsable de l'avancement du projet.
Concernant la taille de l'équipe de développement, celle-ci doit être suffisamment petite pour rester réactive sans que cela n'implique trop d'organisation et de coordination et être suffisamment grande pour pouvoir disposer des compétences nécessaires tout en produisant des résultats conséquents à la fin de chaque Sprint.
Le Scrum Guide recommande donc que les équipes de développement soient composées de 3 à 9 membres. Le Product Owner ainsi que le Scrum Master ne sont compté comme membres de l'équipe de développement à moins que ceux-ci traitent également des tâches du back log.
Véritable chef d'orchestre, il porte la méthodologie Scrum et aide chacun (Product Owner, équipement de développement, ...) à en comprendre la méthodologie ainsi que les différentes cérémonies et artefact. Il est par conséquent responsable du bon respect de la méthodologie.
Il sert d'intermédiaire unique au près des partenaires externes, il assiste le Product Owner et aide l'équipe de développement dans son travail quotidien sans disposer d'aucun pouvoir managérial.
Rôle du Scrum Master auprès du Product Owner
Le Scrum Master aide le Product Owner sur plusieurs points dont notamment :
• S'assurer que les objectifs, le périmètre et le domaine du produit sont compris par tous les membres de l'équipe Scrum de la meilleure façon possible ;
• Trouver des techniques pour une gestion efficace du Backlog produit ;
• Aider l'équipe Scrum à comprendre le besoin de clarté et concision des éléments du Backlog produit ;
• Comprendre la planification de produits dans un contexte empirique ;
• S'assurer que le Product Owner sait comment organiser le Backlog produit pour maximiser la valeur ;
• Comprendre et mettre en œuvre l'agilité ; et,
• Faciliter les événements Scrum, en cas de demande ou nécessité.
Rôle du Scrum Master auprès de l'équipe de développement
Le Scrum Master aide l'équipe de développement sur plusieurs points dont notamment :
• Coacher l'équipe de développement en matière d'auto-organisation et de pluridisciplinarité ;
• Aider l'équipe de développement à créer des produits de grande valeur ;
• Supprimer les obstacles à la progression de l'équipe de développement ;
• Faciliter les événements Scrum, en cas de demande ou nécessité ; et,
• Coacher l'équipe de développement dans des environnements organisationnels où Scrum n'est pas encore complètement adopté et compris.
Rôle du Scrum Master auprès de l'organisation
Le Scrum Master travail aide l'organisation sur plusieurs points dont notamment :
• Accompagner l'organisation dans son adoption de Scrum ;
• Planifier les implémentations de Scrum au sein de l'organisation ;
• Aider les employés et les parties prenantes à comprendre et adopter Scrum ainsi que le développement empirique de produits ;
• Provoquer les changements qui augmentent la productivité de l'équipe Scrum ; et,
• Collaborer avec d'autres Scrum Masters pour accroître l'efficacité de l'application de Scrum au sein de l'organisation
| SPRINT | |
|---|---|
| Durée | Jusqu'à un mois |
| Objectif | C'est l'évenement conteneur. Le sprint contient tous les autres événements et se termine par un incrément de produit potentiellement livrable. |
| Personnes | Toute l'équipe SCRUM (PO + développeurs + SCRUM Master) |
| Entrée | Aucunne, un nouveau sprint commence dès que le précédent se termine |
| Sortie | Le sprint se termine dès sa durée expirée. Un incrément de produit potentiellement déployable doit être produit durant le Sprint. |
| SPRINT PLANNING | |
|---|---|
| Durée | 2 heures par semaine de Sprint (soit 8H pour un Sprint de 4 semaines) |
| Objectif | Premier événement du Sprint, le Sprint planning permet d'identifier et de planifier la charge de travail pouvant être faite durant le Sprint par les développeurs. En fonction de ces éléments l'équipe SCRUM peut définir et s'engager sur l'objectif de Sprint (Sprint Goal). Les éléments à développer sont discutés et affinés avec le PO durant cet événement. Le Sprint planning doit aborder les trois thèmes suivants : - Pourquoi le Sprint est important ? - Que peut-on faire durant le Sprint ? -Comment le travail choisit sera réalisé ? |
| Personnes | Obligatoirement les PO et les développeurs, le SCRUM Master est optionnel. L'équipe peut également demander la présence de membres externes à l'équipe afin d'obtenir des conseils. Mais seul les développeurs disent comment transformer un élément du product backlog en incrément personne d'autre ne peut leur dire comment travailler. |
| Entrée | Le SCRUM Guide n'indique aucun élément comme étant obligatoire. Cependant, il conseille à ce que les participants soient prêt à discuter sur les éléments les plus importants du backlog. |
| Sortie | Le Sprint backlog doit être suffisamment alimenté et détaillé pour que les développeurs puissent commencer à travailler. Le but du Sprint (Sprint Goal) doit être défini pour la fin de l'événement. |
| DAILY | |
|---|---|
| Durée | 15 minutes peu importe la taille de l'équipe et la durée du Sprint |
| Objectif | Inspecter la progression vers l'objectif du Sprint, identifier les points de blocage, améliorer la communication et favoriser la prise de décision rapide. Si nécessaire adapter le Sprint backlog en ajustant les futurs travaux planifiés. |
| Personnes | Obligatoirement les développeurs. Le PO et le scrum master peuvent également y assister notamment si travaillent activement sur des taches du Sprint backlog, ils y participent alors en tant que développeur. Parcontre aucune personne externe à l'équipe ne peut assister au daily scrum. |
| Entrée | Aucunne, le daily est quotidien, à heure fixe et au même endroit |
| Sortie | Produire un plan d'action pour la prochaine journée de travail. |
| REVIEW | |
|---|---|
| Durée | Un maximum de 4 heures pour un sprint d'un mois, et moins pour les sprints plus court |
| Objectif | La review permet de présenter l'incrément produit durant le sprint à l'ensemble des parties prenantes. Elle ne se limite pas à une simple démonstration, mais consiste en une véritable session de travail avec notamment le client pour identifier la progression vers l'objectif du produit. Les réflexions sont portées sur le développement du produit et les futures fonctionnalités. Le product backlog peut par conséquent être ajusté durant cet événement. |
| Personnes | Toute l'équipe SCRUM (PO + développeurs + SCRUM Master), ainsi que tous les intervenants externes désirant y participer. |
| Entrée | Le résulat du travail du Sprint, c’est-à-dire l'incrément du Sprint |
| Sortie | Amélioration de la vision des clients sur l'avancée des développements (transparence). Le product backlog peut être affiné et réajusté. |
| RETROSPECTIVE | |
|---|---|
| Durée | Un maximum de 3 heures pour un sprint d'un mois, et moins pour les sprints plus court |
| Objectif | Réfléchir à des pistes pour améliorer la qualité et l'efficacité de l'équipe. |
| Personnes | Obligatoirement toute l'équipe SCRUM (PO + développeurs + SCRUM Master). Aucun intervenant externe ne doit être invité à la retrospective. |
| Entrée | Aucune |
| Sortie | Rien d'obligatoire depuis la version du SCRUM Guide 2020 même si cela reste recommandé. |
Le Sprint Goal est défini durant le Sprint Planning quand les développeurs ont identifiés ce qu'il est possible de réaliser durant le Sprint.
