SlideShare une entreprise Scribd logo
La méthode
Scrum
Scrum - Présentation
Les méthodes Agile
• Le développement agile est une manière différente d'exécuter des équipes et des projets de développement logiciel. Il est
différent des méthodes développement de logiciels conventionnels, où les exigences du produit sont finalisées avant de
procéder au développement.
Modèle de cascade
• Le modèle de développement logiciel le plus couramment utilisé avec cette caractéristique. Cependant, dans la plupart des
cas, de nouvelles fonctionnalités sont ajoutées et les exigences antérieures peuvent également changer. Le modèle
Waterfall n'est pas structuré pour s'adapter à ces changements continus d'exigences
Modèle incrémental itératif
• Dans le modèle incrémental itératif, le développement commence avec un nombre limité d'exigences finalisées et
hiérarchisées. Le livrable est un incrément de travail du produit. Un ensemble d'activités allant des exigences au
développement de code est appelé une itération. Sur la base de la fonctionnalité de l'incrément et de tout ou partie des
exigences nouvelles, modifiées et en attente, le lot d'exigences suivant est attribué à l'itération suivante.
• L'utilisateur n'est généralement pas impliqué dans le travail de développement et cela peut entraîner des lacunes de
communication entraînant des fonctionnalités incorrectes.
Module 3 - Seance 1 - Scrum.pptx
Scrum - Présentation
Développement agile
Le développement Agile est basé sur un développement incrémental itératif, dans lequel les
exigences et les solutions évoluent grâce à la collaboration d'équipe. Il recommande une approche
itérative limitée dans le temps et encourage une réponse rapide et flexible au changement. Il s'agit
d'un cadre théorique et ne spécifie aucune pratique particulière qu'une équipe de développement
devrait suivre. Scrum est un cadre de processus agile spécifique qui définit les pratiques à suivre.
Scrum
C'est le framework agile le plus populaire, qui se concentre particulièrement sur la façon de gérer les
tâches dans un environnement de développement en équipe. Scrum utilise un modèle de
développement itératif et incrémental, avec une durée d'itérations plus courte. Scrum est
relativement simple à mettre en œuvre et se concentre sur des livraisons rapides et fréquentes.
Scrum - Cadre
Définition
• Scrum est un cadre dans lequel les gens peuvent
résoudre des problèmes adaptatifs complexes,
tout en fournissant de manière productive et
créative des produits de la plus haute valeur
possible.
• Le framework Scrum se compose des équipes
Scrum et de leurs rôles, événements, artefacts et
règles associés. Chaque composant dans le cadre
sert un objectif spécifique et est essentiel au
succès et à l'utilisation de Scrum.
• Les règles de Scrum lient les événements, les rôles
et les artefacts, régissant les relations et
l'interaction entre eux.
• Dans Scrum, les événements prescrits sont utilisés
pour créer de la régularité. Tous les événements
sont des événements temporisés, de sorte que
chaque événement a une durée maximale. Les
événements sont décrits plus en détail dans les
chapitres suivants.
Scrum - Cadre
• Le cœur de Scrum est un Sprint, une boîte de temps de deux semaines ou d'un mois au
cours de laquelle un incrément de produit potentiellement libérable est créé. Un nouveau
Sprint commence immédiatement après la fin du Sprint précédent. Les sprints
comprennent la planification du sprint, les mêlées quotidiennes, le travail de
développement, la revue du sprint et la rétrospective du sprint.
Scrum - Rôles
ScrumMaster
• Le ScrumMaster est le gardien du processus de mêlée. Il / elle est responsable de-
• faire fonctionner le processus sans heurts
• éliminer les obstacles qui ont un impact sur la productivité
• organiser et animer les réunions critiques
Scrum - Rôles
Product owner (Propriétaire du produit)
• Le Product Owner est responsable de maximiser la valeur du produit et le travail de l'équipe.
• Le Product Owner est la seule personne responsable de la gestion du Product Backlog. La gestion du backlog
produit comprend:
• Exprimer clairement les éléments du Backlog produit.
• Commander les articles du Backlog Produit pour atteindre au mieux les objectifs et les missions.
• Optimiser la valeur du travail effectué par l'équipe.
• S'assurer que le Backlog produit est visible, transparent et clair pour tous, et montre sur quoi l'équipe
travaillera plus loin.
• S'assurer que l'équipe comprend les éléments du Backlog produit au niveau requis.
Scrum - Rôles
L'équipe
• L'équipe est auto-organisée et interfonctionnelle. Cela signifie que l'équipe comprend des analystes, des
concepteurs, des développeurs, des testeurs, etc.,
• Les équipes interfonctionnelles possèdent toutes les compétences nécessaires pour accomplir le travail sans
dépendre d'autres personnes ne faisant pas partie de l'équipe, ce qui permet d'économiser du temps et des
efforts. Le modèle d'équipe dans Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité.
• La taille optimale de l'équipe est suffisamment petite pour rester agile et suffisamment grande pour effectuer
un travail important dans un sprint. La taille de l'équipe doit être comprise entre cinq et neuf personnes, si
possible.
• L'équipe Scrum travaille en étroite collaboration, au quotidien, pour assurer la fluidité des informations et la
résolution rapide des problèmes.
• L'équipe Scrum délivre le produit de manière itérative et incrémentielle, maximisant les opportunités de
feedback. Les livraisons incrémentielles d'un produit complet garantissent qu'une version potentiellement
utile du produit opérationnel est toujours disponible.
Scrum - Événements
• Scrum Framework peut être visualisé au moyen d'une séquence d'événements et des artefacts
correspondants.
• Les événements Scrum sont des événements temporisés. Cela signifie que, dans un projet, chaque
événement Scrum a une durée maximale prédéfinie. Ces événements permettent une
transparence sur l'avancement du projet à tous ceux qui sont impliqués dans le projet.
• Les événements vitaux de Scrum sont :
• Le Sprint
• Planification de sprint
• Réunions Scrum quotidiennes
• La revue de sprint
• La rétrospective Sprint
Scrum - Événements
Le Sprint
• Lors d'un Sprint, un incrément de produit fonctionnel est développé. Il est généralement d'une
durée de deux semaines ou d'un mois, et cette durée reste constante pour tous les sprints du
projet. Un nouveau Sprint commence immédiatement après la fin du Sprint précédent.
• Le Sprint Goal est un objectif fixé pour le Sprint. Il fournit des conseils à l'équipe sur les raisons
pour lesquelles elle construit l'incrément. Il est créé lors de la réunion de planification de sprint. La
portée du sprint est clarifiée et renégociée entre le Product Owner et l'équipe au fur et à mesure
que les exigences sont apprises. Ainsi, chaque Sprint lui est associé, une définition de ce qui doit
être construit, une conception et le plan flexible qui guidera sa construction, le travail de
développement et l'incrément de produit résultant.
• Un sprint doit être annulé si l'objectif de sprint devient obsolète. Cela peut se produire si
l'organisation change de direction ou si les conditions du marché ou de la technologie changent. Un
sprint ne peut être annulé que par le propriétaire du produit, bien que d'autres aient une influence
sur le même.
Scrum - Événements
Planification de sprint
• Le travail à effectuer dans le sprint est planifié lors de la réunion de planification du sprint. La
réunion de planification de sprint dure au maximum quatre heures pour les sprints de deux
semaines et huit heures pour les sprints d'un mois. Il est de la responsabilité du Scrum Master de
s'assurer que la réunion a lieu et que tous les participants requis sont présents et comprennent le
but de la réunion programmée. Le Scrum Master anime la réunion pour surveiller le maintien de la
discussion et la clôture à temps.
• La planification de sprint se concentre sur les deux questions suivantes :
• Qu'est-ce qui doit et peut être livré dans l'incrément de sprint?
• Comment le travail nécessaire à l'exécution du Sprint sera-t-il réalisé?
• Les inputs à cette réunion sont :
• Le backlog produit
• Le dernier incrément de produit
• Capacité projetée de l'équipe pendant le sprint
• Performances passées de l'équipe
Scrum - Événements
Planification de sprint
• L'équipe Scrum discute des fonctionnalités qui peuvent être développées pendant le Sprint. Le Product Owner
fournit des clarifications sur les éléments du Product Backlog. L'équipe sélectionne les éléments du Product
Backlog pour le Sprint, car ils sont les meilleurs pour évaluer ce qu'ils peuvent accomplir dans le Sprint.
• L'équipe Scrum propose ensuite un objectif de sprint. Le Sprint Goal est un objectif qui fournit des conseils à
l'équipe sur les raisons pour lesquelles elle construit l'incrément de produit. Les éléments du Backlog produit
sélectionnés pour ce Sprint ainsi que le plan pour les livrer sont appelés le Sprint Backlog.
• Le travail pendant un sprint est estimé lors de la planification du sprint et peut être de taille et / ou d'effort
variables. À la fin de la réunion de planification de sprint, le travail est divisé en tâches d'une durée d'un jour
ou moins. Cela permet de faciliter la répartition du travail et le suivi de l'achèvement. Si l'équipe se rend
compte qu'elle a trop ou pas assez de travail, elle peut renégocier les éléments du Backlog produit
sélectionnés avec le Product Owner.
• L'équipe peut également inviter d'autres personnes (ne faisant pas partie de l'équipe Scrum) à assister à la
réunion de planification de sprint pour obtenir des conseils techniques ou de domaine ou une aide à
l'estimation.
Scrum - Événements
Réunions Scrum quotidiennes
• La Daily Scrum Meeting est une réunion de 15 minutes pour l'équipe, menée
quotidiennement pour comprendre rapidement le travail depuis la dernière Daily
Scrum Meeting et créer un plan pour les prochaines 24 heures. Cette réunion est
également appelée réunion quotidienne debout.
• Le Daily Scrum Meeting se tient à la même heure et au même endroit chaque jour
pour réduire la complexité.
• Au cours de la réunion, chaque membre de l'équipe explique :
• Qu'a-t-il fait hier pour aider l'équipe à atteindre l'objectif de sprint?
• Que fera-t-il aujourd'hui pour aider l'équipe à atteindre l'objectif de sprint?
• Y a-t-il des obstacles qui l'empêchent, lui ou l'équipe, d'atteindre l'objectif de
sprint?
Scrum - Événements
Réunions Scrum quotidiennes
• La contribution à la réunion doit être la façon dont l'équipe fait pour atteindre l'objectif de
sprint, et le résultat doit être un plan nouveau ou révisé qui optimise les efforts de l'équipe
pour atteindre l'objectif de sprint.
• Bien que le Scrum Master coordonne la réunion Scrum quotidienne et s'assure que les
objectifs de la réunion sont atteints, la réunion est sous la responsabilité de l'équipe.
• Si nécessaire, l'équipe peut se réunir immédiatement après la réunion de mêlée quotidienne,
pour des discussions détaillées ou pour planifier à nouveau le reste du travail du sprint.
• Voici les avantages des réunions Scrum quotidiennes :
• Améliorer la communication au sein de l'équipe.
• Identifier les obstacles, le cas échéant, afin de faciliter une élimination précoce de ceux-ci,
afin de minimiser l'impact sur le Sprint.
• Mettre en évidence et favoriser une prise de décision rapide.
• Améliorer le niveau de connaissance de l'équipe.
Scrum - Événements
Revue de sprint
• Une revue de sprint a lieu à la fin de chaque sprint.
• Au cours de la revue de sprint, une présentation de l'incrément qui est en train d'être publiée est revue. Lors de cette réunion, l'équipe Scrum
et les parties prenantes collaborent pour comprendre ce qui a été fait dans le Sprint.
• Le Sprint Review se déroule normalement pendant deux heures pour les sprints de deux semaines et pendant quatre heures pour les sprints
d'un mois.
• Le Scrum Master s'assure que :
• La réunion a lieu.
• Les participants comprennent le but.
• La réunion se concentre sur l'ordre du jour requis et se termine dans la durée requise.
• La revue de sprint comprend les aspects suivants :
• Les participants incluent l'équipe Scrum et les principales parties prenantes, invitées par le Product Owner.
• Le Product Owner explique quels éléments du Product Backlog ont été terminés pendant le sprint et ce qui ne l'a pas été.
• L'équipe discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été résolus.
• L'équipe démontre le travail qu'elle a accompli et répond aux questions, le cas échéant, sur l'incrément.
• L'ensemble du groupe discute ensuite de ce qu'il faut faire ensuite. Ainsi, la revue de sprint fournit une contribution précieuse à la planification de
sprint du sprint suivant.
• L'équipe Scrum examine ensuite le calendrier, le budget, les capacités potentielles et le marché pour la prochaine version prévue de l'incrément
de produit.
• Le résultat du Sprint Review est un Product Backlog mis à jour, qui définit les éléments probables du Product Backlog pour le prochain Sprint..
Scrum - Événements
Rétrospective Sprint
• La rétrospective de sprint a lieu après la revue de sprint et avant la prochaine planification de sprint. Il s'agit généralement
d'une réunion d'une heure pour des sprints d'une durée de deux semaines et d'une réunion de trois heures pour des
sprints d'une durée d'un mois.
• Le but de la rétrospective Sprint est de :
• Combiner les apprentissages du dernier Sprint en ce qui concerne les personnes, les relations, les processus et les outils.
• Identifier les principaux éléments qui se sont bien déroulés et les améliorations potentielles.
• Créer un plan de mise en œuvre d'améliorations pour augmenter la qualité des produits.
• La rétrospective Sprint est une opportunité pour l'équipe Scrum d'introspecter et de s'améliorer dans le cadre du processus
Scrum afin de rendre le prochain résultat du Sprint plus efficace.
Scrum - Artefacts
Les artefacts
• Les artefacts Scrum fournissent des informations clés dont l'équipe Scrum et les parties prenantes doivent
être conscientes pour comprendre le produit en cours de développement, les activités réalisées et les
activités prévues dans le projet.
• Les artefacts suivants sont définis dans Scrum Process Framework -
• Backlog produit
• Backlog de sprint
• Tableau de combustion
• Increment
• Ce sont les artefacts minimum requis dans un projet Scrum et les artefacts de projet ne sont pas limités par
ceux-ci.
Scrum - Artefacts
Les artefacts
• Les artefacts Scrum fournissent des informations clés dont l'équipe Scrum et les parties prenantes doivent
être conscientes pour comprendre le produit en cours de développement, les activités réalisées et les
activités prévues dans le projet.
• Les artefacts suivants sont définis dans Scrum Process Framework -
• Backlog produit
• Backlog de sprint
• Tableau de combustion
• Increment
• Ce sont les artefacts minimum requis dans un projet Scrum et les artefacts de projet ne sont pas limités par
ceux-ci.
Scrum - Artefacts
Backlog produit
• Le Backlog du produit est une liste ordonnée des fonctionnalités nécessaires dans le cadre du produit
final et constitue la source unique d'exigences pour toute modification à apporter au produit.
• Le Backlog produit répertorie toutes les fonctionnalités, fonctions, exigences, améliorations et correctifs
qui constituent les modifications à apporter au produit dans les versions futures. Les éléments du
Backlog de produit ont les attributs d'une description, d'une commande, d'une estimation et d'une
valeur. Ces éléments sont généralement appelés User Stories. Le Product Owner est responsable du
Product Backlog, y compris son contenu, sa disponibilité et sa commande.
• Un backlog de produit est un artefact évolutif. La version la plus ancienne de celui-ci peut contenir
uniquement les exigences initialement connues et les mieux comprises. Le Product Backlog est
développé au fur et à mesure que le produit et l'environnement dans lequel il sera utilisé progressent.
Le Backlog produit change constamment pour intégrer ce qui est nécessaire pour le rendre efficace. Tant
qu'un produit existe, son Backlog produit existe également.
Scrum - Artefacts
Backlog produit
• Au fur et à mesure que le produit en cours de construction est utilisé et gagne en valeur, le Backlog Produit devient
une liste plus large et plus exhaustive. Les changements dans les exigences de l'entreprise, les conditions du marché
ou la technologie entraînent des changements dans le Backlog Produit, ce qui en fait un artefact en direct.
• Le raffinement du Backlog de produit signifie l'ajout de détails, d'estimations et d'un ordre de priorité aux éléments
du Backlog de produit. Il s'agit d'un processus continu exécuté par le Product Owner et l'équipe. L'équipe Scrum
décide comment et quand le raffinement doit être effectué.
• Les éléments du Backlog de Produit peuvent être mis à jour à tout moment par le Product Owner ou à la discrétion
du Product Owner.
• Les articles du Backlog de produit les plus élevés sont généralement plus clairs et plus détaillés que les articles de
commande inférieure. Des estimations plus précises sont faites en fonction de la plus grande clarté et de plus de
détails. Plus l'ordre est bas, moins le détail est important.
• Les éléments du backlog de produit susceptibles d'être les conditions requises pour le prochain Sprint sont affinés
afin que ces éléments puissent être développés pendant le Sprint. Les éléments du Backlog de Produit qui peuvent
être développés par l'équipe au cours d'un Sprint sont considérés comme prêts pour la sélection lors d'une réunion
de planification de Sprint.
Scrum - Artefacts
Backlog de sprint
• Le Sprint Backlog est l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan
pour livrer l'incrément de produit et réaliser l'objectif du Sprint.
• Le Sprint Backlog est une prévision de l'équipe sur les fonctionnalités qui seront mises à disposition dans le
prochain incrément et le travail nécessaire pour fournir cette fonctionnalité en tant qu'incrément de produit
fonctionnel.
• Le Sprint Backlog est un plan avec suffisamment de détails qui peuvent être compris mais l'équipe doit suivre
dans le Daily Scrum. L'équipe modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog émerge
pendant le Sprint. Cette émergence se produit lorsque l'équipe travaille sur le plan et en apprend davantage
sur le travail nécessaire pour atteindre l'objectif de sprint.
• Comme un nouveau travail est requis, l'équipe l'ajoute au Backlog Sprint. Au fur et à mesure que le travail est
exécuté ou terminé, le travail restant estimé est mis à jour. Lorsque des éléments du plan sont jugés inutiles,
ils sont supprimés. Seule l'équipe peut modifier son backlog de sprint pendant un sprint. Le Sprint Backlog est
une image en temps réel très visible du travail que l'équipe prévoit d'accomplir pendant le sprint, et il
appartient uniquement à l'équipe.
Scrum - Artefacts
Backlog de sprint
• Le Sprint Backlog est l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan
pour livrer l'incrément de produit et réaliser l'objectif du Sprint.
• Le Sprint Backlog est une prévision de l'équipe sur les fonctionnalités qui seront mises à disposition dans le
prochain incrément et le travail nécessaire pour fournir cette fonctionnalité en tant qu'incrément de produit
fonctionnel.
• Le Sprint Backlog est un plan avec suffisamment de détails qui peuvent être compris mais l'équipe doit suivre
dans le Daily Scrum. L'équipe modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog émerge
pendant le Sprint. Cette émergence se produit lorsque l'équipe travaille sur le plan et en apprend davantage
sur le travail nécessaire pour atteindre l'objectif de sprint.
• Comme un nouveau travail est requis, l'équipe l'ajoute au Backlog Sprint. Au fur et à mesure que le travail est
exécuté ou terminé, le travail restant estimé est mis à jour. Lorsque des éléments du plan sont jugés inutiles,
ils sont supprimés. Seule l'équipe peut modifier son backlog de sprint pendant un sprint. Le Sprint Backlog est
une image en temps réel très visible du travail que l'équipe prévoit d'accomplir pendant le sprint, et il
appartient uniquement à l'équipe.
Scrum - Artefacts
Incrément
• L'Incrément est la somme de tous les éléments du Backlog Produit complétés au cours d'un Sprint combiné avec les incréments de tous les
Sprints précédents. À la fin d'un sprint, le nouvel incrément doit être un produit fonctionnel, ce qui signifie qu'il doit être dans un état
utilisable. Il doit être en état de fonctionnement, que le Product Owner décide ou non de le libérer.
• L'équipe Scrum doit avoir un consensus sur ce qui est considéré comme un incrément. Cela varie considérablement d'une équipe Scrum, mais
les membres de l'équipe doivent avoir une compréhension commune de ce que cela signifie pour que le travail soit terminé. Ceci est utilisé
pour évaluer la fin du travail sur l'incrément de produit.
• La même compréhension guide l'équipe dans la connaissance du nombre d'éléments de backlog produit qu'elle peut sélectionner au cours
d'une planification de sprint. Le but de chaque Sprint est de fournir des incréments de fonctionnalités potentiellement libérables.
• Les équipes fournissent un incrément de fonctionnalité du produit à chaque sprint. Cet incrément est utilisable, donc un Product Owner peut
choisir de le libérer immédiatement. Si la compréhension d'un incrément fait partie des conventions, normes ou directives de l'organisation
de développement, toutes les équipes Scrum doivent la suivre au minimum. S'il ne s'agit pas d'une convention de l'organisation de
développement, l'équipe Scrum doit définir une définition d'Incrément adaptée au produit.
• Chaque incrément s'ajoute à tous les incréments précédents et est minutieusement testé, garantissant que tous les incréments fonctionnent
ensemble.
• Au fur et à mesure que les équipes Scrum mûrissent, on s'attend à ce que leurs définitions des incréments s'étendent pour inclure des critères
plus stricts pour une meilleure qualité. Tout produit doit avoir une définition d'incrément qui est une norme pour tout travail effectué dessus.
Scrum - Artefacts
Graphique Burn-Down Sprint
• À tout moment dans un Sprint, le travail total restant dans le Sprint Backlog peut être additionné. L'équipe
suit ce travail total restant pour chaque Daily Scrum pour projeter la probabilité d'atteindre l'objectif de
Sprint. En suivant le travail restant tout au long du Sprint, l'équipe peut gérer sa progression.
• Sprint Burn-Down Chart est une pratique pour suivre l'évolution du travail effectué par l'équipe Scrum. Cela
s'est avéré être une technique utile pour suivre la progression du Sprint vers l'objectif du Sprint.
Module 3 - Seance 1 - Scrum.pptx
Module 3 - Seance 1 - Scrum.pptx
Scrum – User stories
Définition
• Dans le développement de logiciels, les fonctionnalités du produit jouent un rôle crucial. Ce sont les fonctionnalités
que l'utilisateur aime finalement utiliser dans le produit final.
• Les User Stories sont couramment utilisées pour décrire les fonctionnalités du produit et feront partie des Artefacts
Scrum - Product Backlog et Sprint Backlog.
• une User Story est racontée du point de vue de l'utilisateur concernant ce qu'il ou elle veut avoir plutôt que ce que
le système peut faire pour lui.
• Dans les projets Scrum, le Product Backlog est une liste de user stories. Ces User Stories sont hiérarchisées et
intégrées dans le Sprint Backlog lors de la réunion de planification de Sprint.
• L'estimation est également basée sur les user stories et la taille du produit est estimée en User Story Points.
Structure
• La structure de la User Story est la suivante :
• En tant que <Type d'utilisateur> ,
• Je veux <Effectuer une tâche> ,
• Pour que <je puisse atteindre un objectif / un avantage / une valeur> .
Scrum – User stories
Exemple
• Exemple de user story 1 : développement de produits
• En tant que chef de produit, je souhaite que les membres d’équipe puissent comprendre en quoi leurs
tâches individuelles contribuent aux objectifs commerciaux globaux afin de booster leur motivation.
• Exemple de user story 2 : expérience client
• En tant que client récurrent, je souhaite que mes informations soient sauvegardées afin que mon
expérience de paiement soit plus fluide.
• Exemple de user story 3 : application mobile
• En tant qu’utilisateur régulier de l’application, je souhaite consulter les informations pertinentes le plus
vite possible.
Scrum – User stories
Méthode INVEST
• L’acronyme anglais INVEST signifie Independent (indépendant), Negotiable (négociable), Valuable (utile), Estimable, Small
(petit) et Testable. Passons en revue ces éléments et voyons en quoi cette méthode peut vous aider à rédiger des user
stories plus efficaces :
• Independent (indépendant) : la user story doit être indépendante. Elle doit être complètement autonome et ne pas
dépendre d’autres tâches.
• Negotiable (négociable) : la user story doit être négociable et laisser place à la discussion.
• Valuable (précieux) : la user story doit apporter une valeur ajoutée à l’utilisateur final
• Estimable : l’équipe de développement doit pouvoir donner une estimation de l’effort requis pour réaliser cette user story,
afin d’en définir correctement la priorité et de vérifier qu’elle peut être terminée au cours du sprint.
• Small (petit) : une user story doit représenter une petite portion de travail pouvant être accomplie en peu de temps.
• Testable : pour une qualité optimale, la user story doit être soumise à des tests d’utilisabilité et répondre à des critères
prédéterminés en la matière.
Scrum – User stories
Gérer les user stories
• Les User Stories sont gérées dans le Product Backlog et sont classées par priorité.
• Les user stories les plus prioritaires sont affinées au niveau granulaire, tandis que les user stories les moins
prioritaires sont conservées à un niveau de détail moindre.
• Pour chaque sprint, les user stories les plus prioritaires et donc les plus granulées sont intégrées dans le
backlog de sprint.
• Si une user story doit être ajoutée au backlog du produit, sa priorité est d'abord déterminée, et elle est placée
en fonction de sa place selon la priorité.
• Les user stories peuvent être redéfinies à tout moment. Il est également possible de supprimer n'importe
laquelle des user stories si nécessaire.
Scrum – User stories
Avantages
• Le principal avantage de User Story réside dans la définition centrée sur l'utilisateur elle-même. En effet, en
fin de compte, c'est l'utilisateur qui utilisera le produit dans les scénarios utilisateur pertinents. Il connecte les
utilisateurs finaux aux membres de l'équipe.
• La syntaxe de la User Story elle-même garantit la capture de l'objectif, du bénéfice ou de la valeur que
l'utilisateur souhaite atteindre.
• Il est possible d'apporter des modifications à une user story au cours de l'exécution du projet. Si la portée de
la user story devient grande, elle doit être divisée en user stories plus petites. Les conditions du critère
d'acceptation peuvent également être modifiées.
Scrum – User stories
Exercice 1
• Titre: Créer une fonctionnalité de recherche avancée pour les produits
• Description: La fonctionnalité de recherche avancée permettra aux clients de rechercher des produits en
utilisant plusieurs critères de recherche, tels que la marque, la couleur, la taille, le prix, etc. Les résultats de la
recherche doivent être présentés sous forme de liste, avec la possibilité de trier les résultats par pertinence,
prix, popularité, etc.
• User Story: En tant que client, je souhaite pouvoir effectuer une recherche avancée sur les produits afin de
trouver rapidement les produits qui répondent à mes besoins spécifiques, tels que la couleur, la taille ou le prix.
Je veux également être en mesure de trier les résultats de ma recherche en fonction de différents critères pour
faciliter la comparaison des produits.
Scrum – User stories
Exercice 2
• Titre: Ajouter une fonctionnalité de paiement en ligne pour les utilisateurs
• Description: La fonctionnalité de paiement en ligne permettra aux utilisateurs d'effectuer des
achats sur la plateforme en utilisant une carte de crédit ou un compte PayPal. Les utilisateurs
pourront ajouter leurs informations de paiement en toute sécurité et effectuer des transactions en
quelques clics.
Scrum – User stories
Exercice 2
• User Story: En tant qu'utilisateur, je souhaite pouvoir effectuer des achats en ligne sur la plateforme
en utilisant une carte de crédit ou un compte PayPal. Je veux pouvoir ajouter mes informations de
paiement en toute sécurité et effectuer des transactions en quelques clics.
Scrum – User stories
Exercice 2
Critères d'acceptation:
1. La fonctionnalité de paiement en ligne doit être facile à utiliser pour les utilisateurs finaux.
2. Les utilisateurs doivent être en mesure d'ajouter leurs informations de paiement de manière sécurisée, sans risque de
fraude ou de vol de données.
3. Les utilisateurs doivent être en mesure de voir un récapitulatif de leur commande avant de finaliser leur achat, afin de
vérifier les détails de la commande et le montant total.
4. Le processus de paiement doit être rapide et sans accroc, sans temps d'attente excessif ou de ralentissement du système.
5. Les utilisateurs doivent recevoir une confirmation de leur paiement une fois la transaction effectuée, pour s'assurer que leur
commande a été traitée avec succès.
6. La fonctionnalité de paiement en ligne doit être conforme aux réglementations en matière de protection des données et de
sécurité des paiements en ligne.
7. Les utilisateurs doivent être en mesure de signaler tout problème ou erreur de paiement, et obtenir de l'aide rapidement
pour résoudre tout problème.
8. La fonctionnalité de paiement en ligne doit être testée en interne avant d'être déployée pour s'assurer de son bon
fonctionnement et éviter les bugs.
Scrum – User stories
Les critères d’acceptation affinent la User Story, de sorte que les développeurs comprennent les objectifs de
l’application et que les testeurs identifient clairement les éléments à tester. Le product owner est tenu de définir
l’expérience métier attendue de la User Story et d’en approuver les critères d’acceptation. Les critères
d’acceptation d’une User Story doivent être rédigés en termes non ambigus, faciles à comprendre par les
utilisateurs métier (et par les membres non techniques de l’équipe).
Ils doivent être formulés en termes de résultat, et non sous forme d’instructions techniques destinées à l’équipe
de développement. Ils doivent être délibérément négociables, et préserver ainsi pour l’équipe de
développement une marge de manœuvre lui permettant de réaliser la solution en coopération avec les
utilisateurs métier. Mais, même négociables, les critères d’acceptation doivent être suffisamment précis pour
pouvoir être testés.
Scrum – User stories
Les critères d'accepation
• L'interface utilisateur pour la recherche avancée doit être intuitive et facile à utiliser pour l'utilisateur final.
• La recherche avancée doit inclure plusieurs critères de recherche, tels que la marque, la couleur, la taille, le prix, etc.
• Les résultats de la recherche doivent être précis et pertinents en fonction des critères de recherche sélectionnés.
• Les résultats de la recherche doivent être présentés sous forme de liste avec des informations claires et concises sur chaque
produit, telles que la description, la photo, le prix, etc.
• Les utilisateurs doivent être en mesure de trier les résultats de leur recherche en fonction de différents critères, tels que le
prix, la popularité, la pertinence, etc.
• Le temps de réponse de la recherche ne doit pas être trop long et la fonctionnalité doit être performante même avec un
grand nombre de produits.
• La fonctionnalité de recherche avancée doit être testée en interne avant d'être déployée pour s'assurer de son bon
fonctionnement et éviter les bugs.
• La fonctionnalité doit être compatible avec les différents navigateurs et appareils utilisés par les utilisateurs.
Scrum - Estimation
Dans les projets Scrum, l'estimation est effectuée par toute l'équipe lors de la réunion de planification du sprint.
L'objectif de l'estimation serait de considérer les User Stories pour le Sprint par priorité et par la capacité de
l'équipe à livrer pendant la Time Box du Sprint.
Le Product Owner s'assure que les User Stories prioritaires sont claires, peuvent être soumises à une estimation
et qu'elles sont placées au début du Product Backlog
Planification de la technique de poker
• Il existe plusieurs types d'échelles utilisées dans l'estimation Scrum. Voici quelques exemples -
• Dimensionnement numérique (1 à 10)
• T-shirts Tailles (XS, S, M, L, XL XXL, XXXL)
• Séquence de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc.)
• Races de chiens (Chihuahua, ………, Dogue Allemand)
• Le modérateur lit la user story. Si l'équipe a des questions, le product owner donne des clarifications.
• Chaque membre de l'équipe donne une estimation à la user story en utilisant les valeurs 1, 2 , 3, 5, 8, 13, 20,
40, 100. Les membres avec les valeurs minimales ou maximales peuvent être sollicités pour justifier leurs
réponses
Travail à faire : Etude de cas
Contexte
L'entreprise LaCite est une entreprise de développement de logiciels qui travaille sur un
projet pour développer un système de gestion de bibliothèque pour son client.
Objectifs du projet
Le but du projet est de développer un système de gestion de bibliothèque qui permettra au
client de gérer les ressources et le personnel.
Déroulement du projet
• L'équipe de développement est composée de 6 personnes : un Product Owner, un Scrum
Master et quatre développeurs.
• Le projet doit être complété en deux sprints
• La durée du sprint est deux semaines
Travail à faire : Etude de cas
Travail à faire
• Élaborer un backlog produit en collaboration avec le Product Owner.
Livrer un product backlog
 Utilisateur, travail à réaliser, objectif, critères d'accepataion, story points, priorité des user stories
• Planning de tous les événements
 Livrer un calendrier montrant tous les événements des deux sprints
• Tenir les réunions de chaque sprint : sprint planning, daily scrum, sprint review et sprint retrospective.
Livrer les deux sprint backlog
Livrer un rapport du sprint review
Livrer un rapport du sprint retrospective
 Start doing : 3 actions
 Continue doing : 3 actions
 Stop doing : 3 actions
Inputs
• Document du Besoin client
• Réponses aux questions des étudiants en classe
Travail à faire : Etude de cas
Travail à faire : Etude de cas

Contenu connexe

Similaire à Module 3 - Seance 1 - Scrum.pptx

Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
Sirine Barguaoui
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
Dominic Danis
 
Scrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de RémyScrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de Rémy
antony_guilloteau
 
Guide scrum
Guide scrumGuide scrum
Guide scrum
Yannick Quenec'hdu
 
Evenements scrum
Evenements scrumEvenements scrum
Evenements scrum
MICHRAFY MUSTAFA
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
Guillaume LAURIE
 
intelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdfintelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdf
SteevePaladin
 
La méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdfLa méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdf
anwermannai
 
Gestion de projet agile avec Scrum
Gestion de projet agile avec ScrumGestion de projet agile avec Scrum
Gestion de projet agile avec Scrum
Daniel Rene FOUOMENE PEWO
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
Nicolas Perriault
 
SCRUM AGL.pptx
SCRUM AGL.pptxSCRUM AGL.pptx
SCRUM AGL.pptx
khairyhattour
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
Olivier Patou
 
Pechakucha scrum-0.1.0-alpha
Pechakucha scrum-0.1.0-alphaPechakucha scrum-0.1.0-alpha
Pechakucha scrum-0.1.0-alpha
Emmanuelle Souillat
 
Agility with scrum
Agility with scrumAgility with scrum
Agility with scrum
Abdeslam Menacere
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
Benjamin ACHAB
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
Frantz Degrigny
 
presentationSCRUM.pptx
presentationSCRUM.pptxpresentationSCRUM.pptx
presentationSCRUM.pptx
FaouziRBEIHI
 
a Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les fluxa Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les flux
DanielMohamed4
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
ChaymaMghazli
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
ChaymaMghazli
 

Similaire à Module 3 - Seance 1 - Scrum.pptx (20)

Scrum les principes de base
Scrum les principes de base Scrum les principes de base
Scrum les principes de base
 
Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010Communaute dot net Montreal juin2010
Communaute dot net Montreal juin2010
 
Scrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de RémyScrum cook and go, les astuces de Rémy
Scrum cook and go, les astuces de Rémy
 
Guide scrum
Guide scrumGuide scrum
Guide scrum
 
Evenements scrum
Evenements scrumEvenements scrum
Evenements scrum
 
Formation Professional Scrum Master I
Formation Professional Scrum Master IFormation Professional Scrum Master I
Formation Professional Scrum Master I
 
intelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdfintelco Méthodes agiles - Scrum_2021.pdf
intelco Méthodes agiles - Scrum_2021.pdf
 
La méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdfLa méthode de gestion de projet agile.pdf
La méthode de gestion de projet agile.pdf
 
Gestion de projet agile avec Scrum
Gestion de projet agile avec ScrumGestion de projet agile avec Scrum
Gestion de projet agile avec Scrum
 
Methodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XPMethodologies de Developpement Agiles : Scrum et XP
Methodologies de Developpement Agiles : Scrum et XP
 
SCRUM AGL.pptx
SCRUM AGL.pptxSCRUM AGL.pptx
SCRUM AGL.pptx
 
20mn scrum
20mn scrum20mn scrum
20mn scrum
 
Pechakucha scrum-0.1.0-alpha
Pechakucha scrum-0.1.0-alphaPechakucha scrum-0.1.0-alpha
Pechakucha scrum-0.1.0-alpha
 
Agility with scrum
Agility with scrumAgility with scrum
Agility with scrum
 
Agile presentation
Agile presentationAgile presentation
Agile presentation
 
Initiation Scrum
Initiation ScrumInitiation Scrum
Initiation Scrum
 
presentationSCRUM.pptx
presentationSCRUM.pptxpresentationSCRUM.pptx
presentationSCRUM.pptx
 
a Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les fluxa Supply Chain a pour mission de gérer de bout en bout les flux
a Supply Chain a pour mission de gérer de bout en bout les flux
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 
Méthode d'Agile: Scrum
Méthode d'Agile: ScrumMéthode d'Agile: Scrum
Méthode d'Agile: Scrum
 

Module 3 - Seance 1 - Scrum.pptx

  • 2. Scrum - Présentation Les méthodes Agile • Le développement agile est une manière différente d'exécuter des équipes et des projets de développement logiciel. Il est différent des méthodes développement de logiciels conventionnels, où les exigences du produit sont finalisées avant de procéder au développement. Modèle de cascade • Le modèle de développement logiciel le plus couramment utilisé avec cette caractéristique. Cependant, dans la plupart des cas, de nouvelles fonctionnalités sont ajoutées et les exigences antérieures peuvent également changer. Le modèle Waterfall n'est pas structuré pour s'adapter à ces changements continus d'exigences Modèle incrémental itératif • Dans le modèle incrémental itératif, le développement commence avec un nombre limité d'exigences finalisées et hiérarchisées. Le livrable est un incrément de travail du produit. Un ensemble d'activités allant des exigences au développement de code est appelé une itération. Sur la base de la fonctionnalité de l'incrément et de tout ou partie des exigences nouvelles, modifiées et en attente, le lot d'exigences suivant est attribué à l'itération suivante. • L'utilisateur n'est généralement pas impliqué dans le travail de développement et cela peut entraîner des lacunes de communication entraînant des fonctionnalités incorrectes.
  • 4. Scrum - Présentation Développement agile Le développement Agile est basé sur un développement incrémental itératif, dans lequel les exigences et les solutions évoluent grâce à la collaboration d'équipe. Il recommande une approche itérative limitée dans le temps et encourage une réponse rapide et flexible au changement. Il s'agit d'un cadre théorique et ne spécifie aucune pratique particulière qu'une équipe de développement devrait suivre. Scrum est un cadre de processus agile spécifique qui définit les pratiques à suivre. Scrum C'est le framework agile le plus populaire, qui se concentre particulièrement sur la façon de gérer les tâches dans un environnement de développement en équipe. Scrum utilise un modèle de développement itératif et incrémental, avec une durée d'itérations plus courte. Scrum est relativement simple à mettre en œuvre et se concentre sur des livraisons rapides et fréquentes.
  • 5. Scrum - Cadre Définition • Scrum est un cadre dans lequel les gens peuvent résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive et créative des produits de la plus haute valeur possible. • Le framework Scrum se compose des équipes Scrum et de leurs rôles, événements, artefacts et règles associés. Chaque composant dans le cadre sert un objectif spécifique et est essentiel au succès et à l'utilisation de Scrum. • Les règles de Scrum lient les événements, les rôles et les artefacts, régissant les relations et l'interaction entre eux. • Dans Scrum, les événements prescrits sont utilisés pour créer de la régularité. Tous les événements sont des événements temporisés, de sorte que chaque événement a une durée maximale. Les événements sont décrits plus en détail dans les chapitres suivants.
  • 6. Scrum - Cadre • Le cœur de Scrum est un Sprint, une boîte de temps de deux semaines ou d'un mois au cours de laquelle un incrément de produit potentiellement libérable est créé. Un nouveau Sprint commence immédiatement après la fin du Sprint précédent. Les sprints comprennent la planification du sprint, les mêlées quotidiennes, le travail de développement, la revue du sprint et la rétrospective du sprint.
  • 7. Scrum - Rôles ScrumMaster • Le ScrumMaster est le gardien du processus de mêlée. Il / elle est responsable de- • faire fonctionner le processus sans heurts • éliminer les obstacles qui ont un impact sur la productivité • organiser et animer les réunions critiques
  • 8. Scrum - Rôles Product owner (Propriétaire du produit) • Le Product Owner est responsable de maximiser la valeur du produit et le travail de l'équipe. • Le Product Owner est la seule personne responsable de la gestion du Product Backlog. La gestion du backlog produit comprend: • Exprimer clairement les éléments du Backlog produit. • Commander les articles du Backlog Produit pour atteindre au mieux les objectifs et les missions. • Optimiser la valeur du travail effectué par l'équipe. • S'assurer que le Backlog produit est visible, transparent et clair pour tous, et montre sur quoi l'équipe travaillera plus loin. • S'assurer que l'équipe comprend les éléments du Backlog produit au niveau requis.
  • 9. Scrum - Rôles L'équipe • L'équipe est auto-organisée et interfonctionnelle. Cela signifie que l'équipe comprend des analystes, des concepteurs, des développeurs, des testeurs, etc., • Les équipes interfonctionnelles possèdent toutes les compétences nécessaires pour accomplir le travail sans dépendre d'autres personnes ne faisant pas partie de l'équipe, ce qui permet d'économiser du temps et des efforts. Le modèle d'équipe dans Scrum est conçu pour optimiser la flexibilité, la créativité et la productivité. • La taille optimale de l'équipe est suffisamment petite pour rester agile et suffisamment grande pour effectuer un travail important dans un sprint. La taille de l'équipe doit être comprise entre cinq et neuf personnes, si possible. • L'équipe Scrum travaille en étroite collaboration, au quotidien, pour assurer la fluidité des informations et la résolution rapide des problèmes. • L'équipe Scrum délivre le produit de manière itérative et incrémentielle, maximisant les opportunités de feedback. Les livraisons incrémentielles d'un produit complet garantissent qu'une version potentiellement utile du produit opérationnel est toujours disponible.
  • 10. Scrum - Événements • Scrum Framework peut être visualisé au moyen d'une séquence d'événements et des artefacts correspondants. • Les événements Scrum sont des événements temporisés. Cela signifie que, dans un projet, chaque événement Scrum a une durée maximale prédéfinie. Ces événements permettent une transparence sur l'avancement du projet à tous ceux qui sont impliqués dans le projet. • Les événements vitaux de Scrum sont : • Le Sprint • Planification de sprint • Réunions Scrum quotidiennes • La revue de sprint • La rétrospective Sprint
  • 11. Scrum - Événements Le Sprint • Lors d'un Sprint, un incrément de produit fonctionnel est développé. Il est généralement d'une durée de deux semaines ou d'un mois, et cette durée reste constante pour tous les sprints du projet. Un nouveau Sprint commence immédiatement après la fin du Sprint précédent. • Le Sprint Goal est un objectif fixé pour le Sprint. Il fournit des conseils à l'équipe sur les raisons pour lesquelles elle construit l'incrément. Il est créé lors de la réunion de planification de sprint. La portée du sprint est clarifiée et renégociée entre le Product Owner et l'équipe au fur et à mesure que les exigences sont apprises. Ainsi, chaque Sprint lui est associé, une définition de ce qui doit être construit, une conception et le plan flexible qui guidera sa construction, le travail de développement et l'incrément de produit résultant. • Un sprint doit être annulé si l'objectif de sprint devient obsolète. Cela peut se produire si l'organisation change de direction ou si les conditions du marché ou de la technologie changent. Un sprint ne peut être annulé que par le propriétaire du produit, bien que d'autres aient une influence sur le même.
  • 12. Scrum - Événements Planification de sprint • Le travail à effectuer dans le sprint est planifié lors de la réunion de planification du sprint. La réunion de planification de sprint dure au maximum quatre heures pour les sprints de deux semaines et huit heures pour les sprints d'un mois. Il est de la responsabilité du Scrum Master de s'assurer que la réunion a lieu et que tous les participants requis sont présents et comprennent le but de la réunion programmée. Le Scrum Master anime la réunion pour surveiller le maintien de la discussion et la clôture à temps. • La planification de sprint se concentre sur les deux questions suivantes : • Qu'est-ce qui doit et peut être livré dans l'incrément de sprint? • Comment le travail nécessaire à l'exécution du Sprint sera-t-il réalisé? • Les inputs à cette réunion sont : • Le backlog produit • Le dernier incrément de produit • Capacité projetée de l'équipe pendant le sprint • Performances passées de l'équipe
  • 13. Scrum - Événements Planification de sprint • L'équipe Scrum discute des fonctionnalités qui peuvent être développées pendant le Sprint. Le Product Owner fournit des clarifications sur les éléments du Product Backlog. L'équipe sélectionne les éléments du Product Backlog pour le Sprint, car ils sont les meilleurs pour évaluer ce qu'ils peuvent accomplir dans le Sprint. • L'équipe Scrum propose ensuite un objectif de sprint. Le Sprint Goal est un objectif qui fournit des conseils à l'équipe sur les raisons pour lesquelles elle construit l'incrément de produit. Les éléments du Backlog produit sélectionnés pour ce Sprint ainsi que le plan pour les livrer sont appelés le Sprint Backlog. • Le travail pendant un sprint est estimé lors de la planification du sprint et peut être de taille et / ou d'effort variables. À la fin de la réunion de planification de sprint, le travail est divisé en tâches d'une durée d'un jour ou moins. Cela permet de faciliter la répartition du travail et le suivi de l'achèvement. Si l'équipe se rend compte qu'elle a trop ou pas assez de travail, elle peut renégocier les éléments du Backlog produit sélectionnés avec le Product Owner. • L'équipe peut également inviter d'autres personnes (ne faisant pas partie de l'équipe Scrum) à assister à la réunion de planification de sprint pour obtenir des conseils techniques ou de domaine ou une aide à l'estimation.
  • 14. Scrum - Événements Réunions Scrum quotidiennes • La Daily Scrum Meeting est une réunion de 15 minutes pour l'équipe, menée quotidiennement pour comprendre rapidement le travail depuis la dernière Daily Scrum Meeting et créer un plan pour les prochaines 24 heures. Cette réunion est également appelée réunion quotidienne debout. • Le Daily Scrum Meeting se tient à la même heure et au même endroit chaque jour pour réduire la complexité. • Au cours de la réunion, chaque membre de l'équipe explique : • Qu'a-t-il fait hier pour aider l'équipe à atteindre l'objectif de sprint? • Que fera-t-il aujourd'hui pour aider l'équipe à atteindre l'objectif de sprint? • Y a-t-il des obstacles qui l'empêchent, lui ou l'équipe, d'atteindre l'objectif de sprint?
  • 15. Scrum - Événements Réunions Scrum quotidiennes • La contribution à la réunion doit être la façon dont l'équipe fait pour atteindre l'objectif de sprint, et le résultat doit être un plan nouveau ou révisé qui optimise les efforts de l'équipe pour atteindre l'objectif de sprint. • Bien que le Scrum Master coordonne la réunion Scrum quotidienne et s'assure que les objectifs de la réunion sont atteints, la réunion est sous la responsabilité de l'équipe. • Si nécessaire, l'équipe peut se réunir immédiatement après la réunion de mêlée quotidienne, pour des discussions détaillées ou pour planifier à nouveau le reste du travail du sprint. • Voici les avantages des réunions Scrum quotidiennes : • Améliorer la communication au sein de l'équipe. • Identifier les obstacles, le cas échéant, afin de faciliter une élimination précoce de ceux-ci, afin de minimiser l'impact sur le Sprint. • Mettre en évidence et favoriser une prise de décision rapide. • Améliorer le niveau de connaissance de l'équipe.
  • 16. Scrum - Événements Revue de sprint • Une revue de sprint a lieu à la fin de chaque sprint. • Au cours de la revue de sprint, une présentation de l'incrément qui est en train d'être publiée est revue. Lors de cette réunion, l'équipe Scrum et les parties prenantes collaborent pour comprendre ce qui a été fait dans le Sprint. • Le Sprint Review se déroule normalement pendant deux heures pour les sprints de deux semaines et pendant quatre heures pour les sprints d'un mois. • Le Scrum Master s'assure que : • La réunion a lieu. • Les participants comprennent le but. • La réunion se concentre sur l'ordre du jour requis et se termine dans la durée requise. • La revue de sprint comprend les aspects suivants : • Les participants incluent l'équipe Scrum et les principales parties prenantes, invitées par le Product Owner. • Le Product Owner explique quels éléments du Product Backlog ont été terminés pendant le sprint et ce qui ne l'a pas été. • L'équipe discute de ce qui s'est bien passé pendant le Sprint, des problèmes rencontrés et de la manière dont ces problèmes ont été résolus. • L'équipe démontre le travail qu'elle a accompli et répond aux questions, le cas échéant, sur l'incrément. • L'ensemble du groupe discute ensuite de ce qu'il faut faire ensuite. Ainsi, la revue de sprint fournit une contribution précieuse à la planification de sprint du sprint suivant. • L'équipe Scrum examine ensuite le calendrier, le budget, les capacités potentielles et le marché pour la prochaine version prévue de l'incrément de produit. • Le résultat du Sprint Review est un Product Backlog mis à jour, qui définit les éléments probables du Product Backlog pour le prochain Sprint..
  • 17. Scrum - Événements Rétrospective Sprint • La rétrospective de sprint a lieu après la revue de sprint et avant la prochaine planification de sprint. Il s'agit généralement d'une réunion d'une heure pour des sprints d'une durée de deux semaines et d'une réunion de trois heures pour des sprints d'une durée d'un mois. • Le but de la rétrospective Sprint est de : • Combiner les apprentissages du dernier Sprint en ce qui concerne les personnes, les relations, les processus et les outils. • Identifier les principaux éléments qui se sont bien déroulés et les améliorations potentielles. • Créer un plan de mise en œuvre d'améliorations pour augmenter la qualité des produits. • La rétrospective Sprint est une opportunité pour l'équipe Scrum d'introspecter et de s'améliorer dans le cadre du processus Scrum afin de rendre le prochain résultat du Sprint plus efficace.
  • 18. Scrum - Artefacts Les artefacts • Les artefacts Scrum fournissent des informations clés dont l'équipe Scrum et les parties prenantes doivent être conscientes pour comprendre le produit en cours de développement, les activités réalisées et les activités prévues dans le projet. • Les artefacts suivants sont définis dans Scrum Process Framework - • Backlog produit • Backlog de sprint • Tableau de combustion • Increment • Ce sont les artefacts minimum requis dans un projet Scrum et les artefacts de projet ne sont pas limités par ceux-ci.
  • 19. Scrum - Artefacts Les artefacts • Les artefacts Scrum fournissent des informations clés dont l'équipe Scrum et les parties prenantes doivent être conscientes pour comprendre le produit en cours de développement, les activités réalisées et les activités prévues dans le projet. • Les artefacts suivants sont définis dans Scrum Process Framework - • Backlog produit • Backlog de sprint • Tableau de combustion • Increment • Ce sont les artefacts minimum requis dans un projet Scrum et les artefacts de projet ne sont pas limités par ceux-ci.
  • 20. Scrum - Artefacts Backlog produit • Le Backlog du produit est une liste ordonnée des fonctionnalités nécessaires dans le cadre du produit final et constitue la source unique d'exigences pour toute modification à apporter au produit. • Le Backlog produit répertorie toutes les fonctionnalités, fonctions, exigences, améliorations et correctifs qui constituent les modifications à apporter au produit dans les versions futures. Les éléments du Backlog de produit ont les attributs d'une description, d'une commande, d'une estimation et d'une valeur. Ces éléments sont généralement appelés User Stories. Le Product Owner est responsable du Product Backlog, y compris son contenu, sa disponibilité et sa commande. • Un backlog de produit est un artefact évolutif. La version la plus ancienne de celui-ci peut contenir uniquement les exigences initialement connues et les mieux comprises. Le Product Backlog est développé au fur et à mesure que le produit et l'environnement dans lequel il sera utilisé progressent. Le Backlog produit change constamment pour intégrer ce qui est nécessaire pour le rendre efficace. Tant qu'un produit existe, son Backlog produit existe également.
  • 21. Scrum - Artefacts Backlog produit • Au fur et à mesure que le produit en cours de construction est utilisé et gagne en valeur, le Backlog Produit devient une liste plus large et plus exhaustive. Les changements dans les exigences de l'entreprise, les conditions du marché ou la technologie entraînent des changements dans le Backlog Produit, ce qui en fait un artefact en direct. • Le raffinement du Backlog de produit signifie l'ajout de détails, d'estimations et d'un ordre de priorité aux éléments du Backlog de produit. Il s'agit d'un processus continu exécuté par le Product Owner et l'équipe. L'équipe Scrum décide comment et quand le raffinement doit être effectué. • Les éléments du Backlog de Produit peuvent être mis à jour à tout moment par le Product Owner ou à la discrétion du Product Owner. • Les articles du Backlog de produit les plus élevés sont généralement plus clairs et plus détaillés que les articles de commande inférieure. Des estimations plus précises sont faites en fonction de la plus grande clarté et de plus de détails. Plus l'ordre est bas, moins le détail est important. • Les éléments du backlog de produit susceptibles d'être les conditions requises pour le prochain Sprint sont affinés afin que ces éléments puissent être développés pendant le Sprint. Les éléments du Backlog de Produit qui peuvent être développés par l'équipe au cours d'un Sprint sont considérés comme prêts pour la sélection lors d'une réunion de planification de Sprint.
  • 22. Scrum - Artefacts Backlog de sprint • Le Sprint Backlog est l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan pour livrer l'incrément de produit et réaliser l'objectif du Sprint. • Le Sprint Backlog est une prévision de l'équipe sur les fonctionnalités qui seront mises à disposition dans le prochain incrément et le travail nécessaire pour fournir cette fonctionnalité en tant qu'incrément de produit fonctionnel. • Le Sprint Backlog est un plan avec suffisamment de détails qui peuvent être compris mais l'équipe doit suivre dans le Daily Scrum. L'équipe modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog émerge pendant le Sprint. Cette émergence se produit lorsque l'équipe travaille sur le plan et en apprend davantage sur le travail nécessaire pour atteindre l'objectif de sprint. • Comme un nouveau travail est requis, l'équipe l'ajoute au Backlog Sprint. Au fur et à mesure que le travail est exécuté ou terminé, le travail restant estimé est mis à jour. Lorsque des éléments du plan sont jugés inutiles, ils sont supprimés. Seule l'équipe peut modifier son backlog de sprint pendant un sprint. Le Sprint Backlog est une image en temps réel très visible du travail que l'équipe prévoit d'accomplir pendant le sprint, et il appartient uniquement à l'équipe.
  • 23. Scrum - Artefacts Backlog de sprint • Le Sprint Backlog est l'ensemble des éléments du Product Backlog sélectionnés pour le Sprint, plus un plan pour livrer l'incrément de produit et réaliser l'objectif du Sprint. • Le Sprint Backlog est une prévision de l'équipe sur les fonctionnalités qui seront mises à disposition dans le prochain incrément et le travail nécessaire pour fournir cette fonctionnalité en tant qu'incrément de produit fonctionnel. • Le Sprint Backlog est un plan avec suffisamment de détails qui peuvent être compris mais l'équipe doit suivre dans le Daily Scrum. L'équipe modifie le Sprint Backlog tout au long du Sprint, et le Sprint Backlog émerge pendant le Sprint. Cette émergence se produit lorsque l'équipe travaille sur le plan et en apprend davantage sur le travail nécessaire pour atteindre l'objectif de sprint. • Comme un nouveau travail est requis, l'équipe l'ajoute au Backlog Sprint. Au fur et à mesure que le travail est exécuté ou terminé, le travail restant estimé est mis à jour. Lorsque des éléments du plan sont jugés inutiles, ils sont supprimés. Seule l'équipe peut modifier son backlog de sprint pendant un sprint. Le Sprint Backlog est une image en temps réel très visible du travail que l'équipe prévoit d'accomplir pendant le sprint, et il appartient uniquement à l'équipe.
  • 24. Scrum - Artefacts Incrément • L'Incrément est la somme de tous les éléments du Backlog Produit complétés au cours d'un Sprint combiné avec les incréments de tous les Sprints précédents. À la fin d'un sprint, le nouvel incrément doit être un produit fonctionnel, ce qui signifie qu'il doit être dans un état utilisable. Il doit être en état de fonctionnement, que le Product Owner décide ou non de le libérer. • L'équipe Scrum doit avoir un consensus sur ce qui est considéré comme un incrément. Cela varie considérablement d'une équipe Scrum, mais les membres de l'équipe doivent avoir une compréhension commune de ce que cela signifie pour que le travail soit terminé. Ceci est utilisé pour évaluer la fin du travail sur l'incrément de produit. • La même compréhension guide l'équipe dans la connaissance du nombre d'éléments de backlog produit qu'elle peut sélectionner au cours d'une planification de sprint. Le but de chaque Sprint est de fournir des incréments de fonctionnalités potentiellement libérables. • Les équipes fournissent un incrément de fonctionnalité du produit à chaque sprint. Cet incrément est utilisable, donc un Product Owner peut choisir de le libérer immédiatement. Si la compréhension d'un incrément fait partie des conventions, normes ou directives de l'organisation de développement, toutes les équipes Scrum doivent la suivre au minimum. S'il ne s'agit pas d'une convention de l'organisation de développement, l'équipe Scrum doit définir une définition d'Incrément adaptée au produit. • Chaque incrément s'ajoute à tous les incréments précédents et est minutieusement testé, garantissant que tous les incréments fonctionnent ensemble. • Au fur et à mesure que les équipes Scrum mûrissent, on s'attend à ce que leurs définitions des incréments s'étendent pour inclure des critères plus stricts pour une meilleure qualité. Tout produit doit avoir une définition d'incrément qui est une norme pour tout travail effectué dessus.
  • 25. Scrum - Artefacts Graphique Burn-Down Sprint • À tout moment dans un Sprint, le travail total restant dans le Sprint Backlog peut être additionné. L'équipe suit ce travail total restant pour chaque Daily Scrum pour projeter la probabilité d'atteindre l'objectif de Sprint. En suivant le travail restant tout au long du Sprint, l'équipe peut gérer sa progression. • Sprint Burn-Down Chart est une pratique pour suivre l'évolution du travail effectué par l'équipe Scrum. Cela s'est avéré être une technique utile pour suivre la progression du Sprint vers l'objectif du Sprint.
  • 28. Scrum – User stories Définition • Dans le développement de logiciels, les fonctionnalités du produit jouent un rôle crucial. Ce sont les fonctionnalités que l'utilisateur aime finalement utiliser dans le produit final. • Les User Stories sont couramment utilisées pour décrire les fonctionnalités du produit et feront partie des Artefacts Scrum - Product Backlog et Sprint Backlog. • une User Story est racontée du point de vue de l'utilisateur concernant ce qu'il ou elle veut avoir plutôt que ce que le système peut faire pour lui. • Dans les projets Scrum, le Product Backlog est une liste de user stories. Ces User Stories sont hiérarchisées et intégrées dans le Sprint Backlog lors de la réunion de planification de Sprint. • L'estimation est également basée sur les user stories et la taille du produit est estimée en User Story Points. Structure • La structure de la User Story est la suivante : • En tant que <Type d'utilisateur> , • Je veux <Effectuer une tâche> , • Pour que <je puisse atteindre un objectif / un avantage / une valeur> .
  • 29. Scrum – User stories Exemple • Exemple de user story 1 : développement de produits • En tant que chef de produit, je souhaite que les membres d’équipe puissent comprendre en quoi leurs tâches individuelles contribuent aux objectifs commerciaux globaux afin de booster leur motivation. • Exemple de user story 2 : expérience client • En tant que client récurrent, je souhaite que mes informations soient sauvegardées afin que mon expérience de paiement soit plus fluide. • Exemple de user story 3 : application mobile • En tant qu’utilisateur régulier de l’application, je souhaite consulter les informations pertinentes le plus vite possible.
  • 30. Scrum – User stories Méthode INVEST • L’acronyme anglais INVEST signifie Independent (indépendant), Negotiable (négociable), Valuable (utile), Estimable, Small (petit) et Testable. Passons en revue ces éléments et voyons en quoi cette méthode peut vous aider à rédiger des user stories plus efficaces : • Independent (indépendant) : la user story doit être indépendante. Elle doit être complètement autonome et ne pas dépendre d’autres tâches. • Negotiable (négociable) : la user story doit être négociable et laisser place à la discussion. • Valuable (précieux) : la user story doit apporter une valeur ajoutée à l’utilisateur final • Estimable : l’équipe de développement doit pouvoir donner une estimation de l’effort requis pour réaliser cette user story, afin d’en définir correctement la priorité et de vérifier qu’elle peut être terminée au cours du sprint. • Small (petit) : une user story doit représenter une petite portion de travail pouvant être accomplie en peu de temps. • Testable : pour une qualité optimale, la user story doit être soumise à des tests d’utilisabilité et répondre à des critères prédéterminés en la matière.
  • 31. Scrum – User stories Gérer les user stories • Les User Stories sont gérées dans le Product Backlog et sont classées par priorité. • Les user stories les plus prioritaires sont affinées au niveau granulaire, tandis que les user stories les moins prioritaires sont conservées à un niveau de détail moindre. • Pour chaque sprint, les user stories les plus prioritaires et donc les plus granulées sont intégrées dans le backlog de sprint. • Si une user story doit être ajoutée au backlog du produit, sa priorité est d'abord déterminée, et elle est placée en fonction de sa place selon la priorité. • Les user stories peuvent être redéfinies à tout moment. Il est également possible de supprimer n'importe laquelle des user stories si nécessaire.
  • 32. Scrum – User stories Avantages • Le principal avantage de User Story réside dans la définition centrée sur l'utilisateur elle-même. En effet, en fin de compte, c'est l'utilisateur qui utilisera le produit dans les scénarios utilisateur pertinents. Il connecte les utilisateurs finaux aux membres de l'équipe. • La syntaxe de la User Story elle-même garantit la capture de l'objectif, du bénéfice ou de la valeur que l'utilisateur souhaite atteindre. • Il est possible d'apporter des modifications à une user story au cours de l'exécution du projet. Si la portée de la user story devient grande, elle doit être divisée en user stories plus petites. Les conditions du critère d'acceptation peuvent également être modifiées.
  • 33. Scrum – User stories Exercice 1 • Titre: Créer une fonctionnalité de recherche avancée pour les produits • Description: La fonctionnalité de recherche avancée permettra aux clients de rechercher des produits en utilisant plusieurs critères de recherche, tels que la marque, la couleur, la taille, le prix, etc. Les résultats de la recherche doivent être présentés sous forme de liste, avec la possibilité de trier les résultats par pertinence, prix, popularité, etc. • User Story: En tant que client, je souhaite pouvoir effectuer une recherche avancée sur les produits afin de trouver rapidement les produits qui répondent à mes besoins spécifiques, tels que la couleur, la taille ou le prix. Je veux également être en mesure de trier les résultats de ma recherche en fonction de différents critères pour faciliter la comparaison des produits.
  • 34. Scrum – User stories Exercice 2 • Titre: Ajouter une fonctionnalité de paiement en ligne pour les utilisateurs • Description: La fonctionnalité de paiement en ligne permettra aux utilisateurs d'effectuer des achats sur la plateforme en utilisant une carte de crédit ou un compte PayPal. Les utilisateurs pourront ajouter leurs informations de paiement en toute sécurité et effectuer des transactions en quelques clics.
  • 35. Scrum – User stories Exercice 2 • User Story: En tant qu'utilisateur, je souhaite pouvoir effectuer des achats en ligne sur la plateforme en utilisant une carte de crédit ou un compte PayPal. Je veux pouvoir ajouter mes informations de paiement en toute sécurité et effectuer des transactions en quelques clics.
  • 36. Scrum – User stories Exercice 2 Critères d'acceptation: 1. La fonctionnalité de paiement en ligne doit être facile à utiliser pour les utilisateurs finaux. 2. Les utilisateurs doivent être en mesure d'ajouter leurs informations de paiement de manière sécurisée, sans risque de fraude ou de vol de données. 3. Les utilisateurs doivent être en mesure de voir un récapitulatif de leur commande avant de finaliser leur achat, afin de vérifier les détails de la commande et le montant total. 4. Le processus de paiement doit être rapide et sans accroc, sans temps d'attente excessif ou de ralentissement du système. 5. Les utilisateurs doivent recevoir une confirmation de leur paiement une fois la transaction effectuée, pour s'assurer que leur commande a été traitée avec succès. 6. La fonctionnalité de paiement en ligne doit être conforme aux réglementations en matière de protection des données et de sécurité des paiements en ligne. 7. Les utilisateurs doivent être en mesure de signaler tout problème ou erreur de paiement, et obtenir de l'aide rapidement pour résoudre tout problème. 8. La fonctionnalité de paiement en ligne doit être testée en interne avant d'être déployée pour s'assurer de son bon fonctionnement et éviter les bugs.
  • 37. Scrum – User stories Les critères d’acceptation affinent la User Story, de sorte que les développeurs comprennent les objectifs de l’application et que les testeurs identifient clairement les éléments à tester. Le product owner est tenu de définir l’expérience métier attendue de la User Story et d’en approuver les critères d’acceptation. Les critères d’acceptation d’une User Story doivent être rédigés en termes non ambigus, faciles à comprendre par les utilisateurs métier (et par les membres non techniques de l’équipe). Ils doivent être formulés en termes de résultat, et non sous forme d’instructions techniques destinées à l’équipe de développement. Ils doivent être délibérément négociables, et préserver ainsi pour l’équipe de développement une marge de manœuvre lui permettant de réaliser la solution en coopération avec les utilisateurs métier. Mais, même négociables, les critères d’acceptation doivent être suffisamment précis pour pouvoir être testés.
  • 38. Scrum – User stories Les critères d'accepation • L'interface utilisateur pour la recherche avancée doit être intuitive et facile à utiliser pour l'utilisateur final. • La recherche avancée doit inclure plusieurs critères de recherche, tels que la marque, la couleur, la taille, le prix, etc. • Les résultats de la recherche doivent être précis et pertinents en fonction des critères de recherche sélectionnés. • Les résultats de la recherche doivent être présentés sous forme de liste avec des informations claires et concises sur chaque produit, telles que la description, la photo, le prix, etc. • Les utilisateurs doivent être en mesure de trier les résultats de leur recherche en fonction de différents critères, tels que le prix, la popularité, la pertinence, etc. • Le temps de réponse de la recherche ne doit pas être trop long et la fonctionnalité doit être performante même avec un grand nombre de produits. • La fonctionnalité de recherche avancée doit être testée en interne avant d'être déployée pour s'assurer de son bon fonctionnement et éviter les bugs. • La fonctionnalité doit être compatible avec les différents navigateurs et appareils utilisés par les utilisateurs.
  • 39. Scrum - Estimation Dans les projets Scrum, l'estimation est effectuée par toute l'équipe lors de la réunion de planification du sprint. L'objectif de l'estimation serait de considérer les User Stories pour le Sprint par priorité et par la capacité de l'équipe à livrer pendant la Time Box du Sprint. Le Product Owner s'assure que les User Stories prioritaires sont claires, peuvent être soumises à une estimation et qu'elles sont placées au début du Product Backlog Planification de la technique de poker • Il existe plusieurs types d'échelles utilisées dans l'estimation Scrum. Voici quelques exemples - • Dimensionnement numérique (1 à 10) • T-shirts Tailles (XS, S, M, L, XL XXL, XXXL) • Séquence de Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, etc.) • Races de chiens (Chihuahua, ………, Dogue Allemand) • Le modérateur lit la user story. Si l'équipe a des questions, le product owner donne des clarifications. • Chaque membre de l'équipe donne une estimation à la user story en utilisant les valeurs 1, 2 , 3, 5, 8, 13, 20, 40, 100. Les membres avec les valeurs minimales ou maximales peuvent être sollicités pour justifier leurs réponses
  • 40. Travail à faire : Etude de cas Contexte L'entreprise LaCite est une entreprise de développement de logiciels qui travaille sur un projet pour développer un système de gestion de bibliothèque pour son client. Objectifs du projet Le but du projet est de développer un système de gestion de bibliothèque qui permettra au client de gérer les ressources et le personnel. Déroulement du projet • L'équipe de développement est composée de 6 personnes : un Product Owner, un Scrum Master et quatre développeurs. • Le projet doit être complété en deux sprints • La durée du sprint est deux semaines
  • 41. Travail à faire : Etude de cas Travail à faire • Élaborer un backlog produit en collaboration avec le Product Owner. Livrer un product backlog  Utilisateur, travail à réaliser, objectif, critères d'accepataion, story points, priorité des user stories • Planning de tous les événements  Livrer un calendrier montrant tous les événements des deux sprints • Tenir les réunions de chaque sprint : sprint planning, daily scrum, sprint review et sprint retrospective. Livrer les deux sprint backlog Livrer un rapport du sprint review Livrer un rapport du sprint retrospective  Start doing : 3 actions  Continue doing : 3 actions  Stop doing : 3 actions Inputs • Document du Besoin client • Réponses aux questions des étudiants en classe
  • 42. Travail à faire : Etude de cas
  • 43. Travail à faire : Etude de cas