📚Fiche de revision Professional Scrum Master 1 (PSM I)

Qu’est-ce que SCRUM ?

Scrum est un cadre de travail léger qui aide les individus, les équipes et les organisations à générer de la valeur grâce à des solutions adaptatives pour des problèmes complexes.

Vue d’ensemble

• Artefacts : Product Backlog, Sprint Backlog et Incrément.
• Événements : Sprint, planification de Sprint, Daily Scrum, Revue de Sprint et Rétrospective de Sprint.
• Responsabilités : Product Owner, Développeurs et SCRUM Master.

 

Scrum Guide

Le Scrum Guide est la norme officielle de Scrum !

Il est recommandé de le lire, c’est un document très condensé avec toutes les informations nécessaires pour comprendre SCRUM.

Scrum Guide (Anglais)

 

Manifeste Agile

Scrum est fortement basé sur le Manifeste Agile. Ce n’est pas obligatoire pour réussir l’évaluation PSM1, mais c’est bon à savoir.

Nous pouvons diviser les 12 principes du Manifeste Agile en quatre catégories différentes :

• Projet
• Produit
• Personnes
• Processus

Projet

• Notre plus haute priorité est de satisfaire le client par la livraison rapide et continue de logiciels fonctionnels et de valeur.
• Accueillir les changements de besoins, même tard dans le développement. Les processus agiles tirent parti du changement pour l’avantage concurrentiel du client.
• Livrer des logiciels fonctionnels fréquemment, de quelques semaines à quelques mois, avec une préférence pour la période la plus courte.
• Les processus agiles favorisent le développement durable. Les sponsors, les développeurs et les utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment.
• Un logiciel fonctionnel est la principale mesure du progrès.

Produit

• La simplicité est essentielle.
• Une attention continue à l’excellence technique et à une bonne conception améliore l’agilité.

Personnes

• La méthode la plus efficace et la plus efficiente pour transmettre des informations à et au sein d’une équipe de développement est la conversation en face-à-face.
• Les acteurs métier et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
• Les meilleures architectures, exigences et conceptions émergent des équipes auto-organisées.
• Construisez des projets autour d’individus motivés. Donnez-leur l’environnement et le soutien dont ils ont besoin, et faites-leur confiance pour accomplir le travail.

Processus

• À des intervalles réguliers, l’équipe réfléchit à la manière de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.

 

Théorie SCRUM

Scrum est fondé sur l’empirisme et la pensée Lean. L’empirisme affirme que la connaissance vient de l’expérience et de la prise de décisions basées sur ce qui est observé. La pensée Lean réduit le gaspillage et se concentre sur l’essentiel.

• Transparence : Le processus émergent et le travail doivent être visibles pour ceux qui effectuent le travail ainsi que pour ceux qui le reçoivent.
• Inspection : Les artefacts Scrum et les progrès vers les objectifs convenus doivent être inspectés fréquemment et avec diligence pour détecter les variances ou problèmes potentiellement indésirables. Pour faciliter l’inspection, Scrum fournit un rythme sous la forme de ses cinq événements.
• Adaptation : Une équipe Scrum est censée s’adapter dès qu’elle apprend quelque chose de nouveau par l’inspection.

Transparence permet l’inspection > Inspection permet l’adaptation > Adaptation

 

Valeurs SCRUM

L’utilisation réussie de Scrum dépend de l’amélioration de la maîtrise des cinq valeurs par les personnes.

• Engagement.
• Courage.
• Ouverture.
• Concentration.
• Respect.

 

Équipe SCRUM

Composée de :

• Product Owner (PO) [x1]
• Scrum Master (SM) [x1]
• Développeurs (Devs) [< x10]

Si l’équipe Scrum devient trop grande, elle devrait envisager de se réorganiser en plusieurs équipes cohésives, chacune se concentrant sur le même Produit. Elles devraient partager le même objectif de Produit, Product Owner et Product Backlog.

Product Owner.

• Maximise la chaîne de valeur délivrée.
• Gère le Product Backlog.
• Le Product Owner représente les intérêts des parties prenantes du produit (métier ou communauté) à travers le contenu et l’ordre du Product Backlog.
• Interaction avec le client.
• Principal responsable de l’engagement des parties prenantes, mais pas unique. Toute l’équipe Scrum est responsable.
• Inspection des progrès.
• Le Product Owner doit avoir de l’autorité.

Développeurs.

• Ils sont responsables de transformer l’idée reflétée dans le Product Backlog en Incréments.
• Auto-gérés et Polyvalents (Cross-Functional).
• Autorisés à mettre à jour le Product Backlog, mais le PO reste responsable.
• Estiment la taille du Product Backlog.

Scrum Master.

• Est responsable de faire en sorte que Scrum se déroule sans accroc.
• Responsable de l’établissement de Scrum.
• Provoque l’élimination des obstacles (impediments).
• Coaching.
• Facilitation des réunions.
• Actions qui peuvent être entreprises au début de la mise en œuvre de Scrum :
  • Demander aux développeurs de se présenter les uns aux autres et de parler de leurs compétences et de leur parcours.
  • Demander au Product Owner d’expliquer le produit, ses besoins métier, son historique, ses objectifs…
  • Demander aux développeurs de discuter et d’identifier la manière dont ils vont développer le produit.
• Facilite la collaboration des parties prenantes selon les besoins ou les demandes.

 

Staled Scrum (Scrum Échelonné ou à l’échelle) :

• Plusieurs équipes Scrum travaillant sur un seul produit.
• Seulement un Product Owner par objectif de Produit, donc par Product Backlog.
• Un Incrément intégré unique.
• Pas besoin d’être synchronisées.
• Une Definition of Done pour les équipes, mais chaque équipe peut avoir sa propre DoD. La DoD de l’équipe est un minimum que chaque équipe doit suivre.

 

Artefacts SCRUM

Chaque artefact contient un engagement :

Artefact	Engagement
Product Backlog	Objectif de Produit
Sprint Backlog	Objectif de Sprint
Incrément	Définition de Terminé (Definition of Done)

 

Product Backlog

• Représente le travail à faire.
• Il n’est jamais complet.
• Engagement : Objectif de Produit (Product Goal)
  • Il est possible d’avoir plusieurs objectifs de produit, mais l’équipe Scrum se concentrera sur un seul objectif de produit à la fois.
• Le Product Backlog est une liste émergente et ordonnée de ce qui est nécessaire pour améliorer le produit.
• Il liste toutes les fonctionnalités, fonctions, exigences, améliorations et corrections qui constituent les changements à apporter au produit dans les futures versions.
• C’est la source unique de travail entreprise par l’équipe Scrum.
• Un Produit a un seul Product Backlog, sans exception.
• Épopées (Epics) -> User Stories.
• Le Raffinage (Refinement) du Product Backlog est nécessaire au fur et à mesure que le temps est nécessaire.
• Le Product Owner l’ordonne en considérant ce qu’il/elle juge approprié. L’ordre est déterminé par 4 facteurs :
  • Taille
  • Risque
  • Valeur
  • Dépendances

Suivi des progrès :

Trois façons différentes proposées par le Scrum Guide pour contrôler/surveiller les progrès :

• Burn-down chart : de haut en bas avec le travail restant à faire et le travail restant estimé à faire (comme les story points) par unité de temps (comme les sprints ou les jours).

  

• Burn-up chart : de bas en haut. Identique au graphique burn-down mais avec la quantité de travail accompli et la quantité de travail à faire.
• Cumulative flow chart (Diagramme de flux cumulatif).

 

Sprint Backlog

• Représente le travail à faire.

Le Sprint Backlog est composé de l’objectif de Sprint (pourquoi), de l’ensemble des éléments du Product Backlog sélectionnés pour le Sprint (quoi), ainsi que d’un plan d’action pour livrer l’Incrément (comment).

• Par et pour les développeurs. Seuls les développeurs peuvent modifier le Sprint Backlog.
• L’objectif de Sprint est fixe, mais le Sprint Backlog pourrait subir des changements sans changer l’objectif de Sprint.

Incrément

• Représente la valeur.
• Chaque Incrément s’ajoute à tous les Incréments précédents et est minutieusement vérifié, garantissant que tous les Incréments fonctionnent ensemble. Afin de fournir de la valeur, l’Incrément doit être utilisable.
• Le travail ne peut pas être considéré comme faisant partie d’un Incrément à moins qu’il ne réponde à la Definition of Done.
  • Definitions of Done (DoD) (Définitions de Terminé) :
    

    Une description formelle de l’état de l’incrément lorsqu’il répond aux mesures de qualité requises pour le produit.

  • Chaque Incrément n’a qu’une seule DoD.
  • L’organisation définit la DoD ; si l’organisation n’en a pas, l’équipe Scrum doit en définir une appropriée.
• Vous n’avez pas besoin de livrer un Incrément à la fin de chaque sprint.
• Le Sprint n’est pas une porte, une livraison peut être effectuée pendant un sprint.

 

Événements SCRUM

• Durées :
  • Sprint : Pas plus d’1 mois.
  • Planification de Sprint : Maximum de 8 heures pour un Sprint d’un mois.
  • Daily Scrum : 15 minutes.
  • Revue de Sprint : Maximum de 4 heures pour un Sprint d’un mois.
  • Rétrospective de Sprint : Maximum de 3 heures pour un Sprint d’un mois.
• Les événements sont une occasion formelle d’inspecter et d’adapter quelque chose.

Planification de Sprint :

• Qui :
  • L’équipe Scrum.
  • Les parties prenantes invitées si nécessaire.
• Sujets :
  1. Pourquoi ce Sprint est-il de valeur ? (Objectif de Sprint – Le Product Owner propose la manière dont le produit pourrait augmenter sa valeur et son utilité lors du Sprint actuel).
  2. Qu’est-ce qui peut être fait ce sprint ? (Sprint Backlog – Les développeurs sélectionnent les éléments du Product Backlog qui peuvent être complétés dans le Sprint).
     • Mesure : Performance passée, leur capacité à venir, et leur Definition of Done.
  3. Comment le travail choisi sera-t-il accompli ? (Incrément – Les développeurs planifient le travail nécessaire pour créer un Incrément qui répond à la Definition of Done).

Sprint

• Le Cœur de Scrum.
• Défini avant la Planification de Sprint et ne peut pas être modifié par la suite (sauf si le sprint est annulé).
• Doit avoir des durées fixes.
• Pendant le sprint :
  • Aucun changement n’est effectué qui mettrait en péril l’Objectif de Sprint.
  • Les objectifs de qualité ne diminuent pas.
  • Le Product Backlog est raffiné si nécessaire.
• Seul le Product Owner a l’autorité d’annuler le Sprint.
• Sprints invalides :
  • Sprints de durcissement, de stabilisation…
  • Sprint 0
  • Sprint de mise en production (Release Sprint)
  • Sprint de conception (Design Sprint)

Daily Scrum

• Où les développeurs discutent de leurs progrès vers l’objectif de sprint et adaptent le Sprint Backlog si nécessaire.
• Le Scrum Master doit seulement s’assurer que la réunion a lieu.
• Le Product Owner ne participe pas non plus à la réunion.
• Si le SM ou le PO participent, ils le font en tant que développeurs.
• Pas de temps pour discuter de la solution à un problème. Ce n’est pas une réunion technique.
• Sujets :
  1. Obstacles (Impediments)
  2. Quel travail j’ai fait hier pour atteindre l’objectif ?
  3. Quel travail je vais faire aujourd’hui pour atteindre l’objectif ?

Revue de Sprint

• L’objectif est d’inspecter l’incrément ou tout autre résultat du Sprint.
• Adapter le Product Backlog si nécessaire.
• Le travail non terminé n’est PAS présenté lors de la Revue de Sprint.
• La Revue de Sprint est basée sur la transparence et la collaboration.

Rétrospective de Sprint

• Toute l’équipe Scrum participe.
• Le but de la Rétrospective de Sprint est de planifier des moyens d’augmenter la qualité et l’efficacité.
• L’équipe Scrum inspecte comment le dernier Sprint s’est déroulé en ce qui concerne les individus, les interactions, les processus, les outils et leur Definition of Done.
• Après la Revue de Sprint, et conclut le Sprint.
• Qu’est-ce qui a bien fonctionné / n’a pas bien fonctionné pendant le sprint ?
• Comment pouvons-nous nous améliorer ?
• Discuter de la DoD.
• Discuter de la composition de l’équipe.

Définitions

• SCRUM :
  • Un mécanisme pour optimiser le système de livraison de valeur.
  • Un mécanisme pour guider les changements.
• Efficacité :
  • Livrer le bon produit.
• Efficience :
  • Faire en sorte que l’équipe, les personnes, travaillent de la meilleure façon.
• IKIWISI :
  • I Know It When I See It (Je le saurai quand je le verrai).
• YAGNI :
  • You Ain’t Gonna Need It (Vous n’en aurez pas besoin).
• Agilité ou être agile :
  • L’agilité signifie réagir au changement.
• Definition Of Ready :
  • Ensemble de critères qui définissent quand un élément du Product Backlog est prêt à être exécuté.
• Bottom-up intelligence :
  • L’intelligence ascendante ; la prise de décision et l’information remontent des niveaux inférieurs de l’organisation.
• Produit :
  • Un produit est un véhicule pour délivrer de la valeur. Il a une frontière claire, des parties prenantes connues, des utilisateurs ou clients bien définis. Un produit peut être un service, un produit physique ou quelque chose de plus abstrait.
• Vision Produit :
  • Ce qui motive tous les efforts pour construire un produit, décrivant la raison ultime de sa création.
• Stratégie Produit :
  • C’est là que nous définissons comment la vision sera réalisée.
• Épopées (Epics) :
  • De courts rappels de ce que le produit aura.
  • Décrivent brièvement les fonctionnalités du produit.
• User Stories :
  • Pour décrire de petits éléments du Product Backlog.
• Story Point :
  • Les story points sont une unité de mesure pour exprimer une estimation de l’effort global qui sera nécessaire pour implémenter entièrement un élément du Product Backlog ou toute autre tâche.
• Planning Poker :
  • Est une technique de gamification basée sur le consensus pour l’estimation.
• Capacité à venir (Upcoming Capacity) :
  • Combien d’heures les Développeurs ont disponibles pour ce Sprint.
• WIP :
  • Work In Progress (Travail en Cours).
• Cône d'Incertitude :
  • Décrit la réduction de l’incertitude concernant la portée (scope) après chaque itération.
• Dette technique :
  • Conséquences de mauvaises pratiques de développement logiciel.