Module 3 - Seance 1 - Scrum.pptx

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.

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

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.

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

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.

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?

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.

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..

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
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
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.

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> .

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.

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.

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.

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.

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.

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.

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.

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.

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.

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
• É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

Module 3 - Seance 1 - Scrum.pptx

Recommandé

Recommandé

Contenu connexe

Similaire à Module 3 - Seance 1 - Scrum.pptx

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

Module 3 - Seance 1 - Scrum.pptx