Cours1 2 Vision Bklog SB

Cours 2
Développement agile
La méthode SCRUM
Vision, cycle, backlog Produit
Saber BHAR
2
Sommaire de ce cours
¡ Scrum : présentation rapide

¡ Le cycle -6
¡ La vision produit - 12
¡ Le backlog Produit - 20
3
SCRUM : les rôles
Scrum – Cycle 1/6 4
Vision du
Produit
1. Définition de la vision du produit

◼ Le cap
◼ Une ou deux phrases
2. Backlog produit (ou carnet de produit, catalogue des besoins)

◼ Besoins priorisés par le product owner
◼ Besoins estimés par l’équipe, qui évoluent et sont affinés
6
Scrum – Cycle 3/6
3. Planning Game : élaboration du backlog de sprint

◼ Sélection des besoins à réaliser sur le sprint, extrait du
backlog produit
◼ Découpage en tâches, répartition de l’effort, planification
7
Scrum – Cycle 4/6
4. Sprint
◼ Développement des fonctionnalités du backlog de sprint
◼ Pas de modification du backlog de sprint possible
◼ Affinage du backlog Produit : une fois par semaine

Durée de Sprint (1/2) 8
¡ Scrum : la durée des Sprints peut varier de 2 à 4 semaines.
¡ Certains voudraient 1 semaine, mais c'est court ! À

chaque Sprint, il faut faire 3 réunions (rituels de Scrum) :
¡ une Planification du Sprint (avec l'équipe),
¡ une Revue de Sprint (équipe et parties prenantes)
¡ une Rétrospective (équipe).
¡ Donc si les Sprints sont trop courts

¡ ce temps lié aux rituels risque de pénaliser la productivité du
projet.
¡ À l'inverse si les Sprints sont trop longs

¡ le risque de ne pas détecter à temps une anomalie est plus
élevé.
Durée de Sprint (2/2) 9
¡ Il faut donc un bon compromis sur la durée des

Sprints. Cette durée est fonction :
¡ du projet
¡ de la maturité de l'équipe avec l’approche Scrum
¡ Attention au Sprint 0 et au dernier Sprint

¡ leur durée peut être différente de celle des Sprints ‘normaux’
5. Mêlée quotidienne
◼ Point de contrôle quotidien de l’équipe
◼ Interventions régulées – 2 min. par personne

6. Incrément logiciel : livré au Product Owner à la

fin du sprint : donné aux commerciaux,
prospects
Caractéristiques Méthodes 12
Agiles
¡ Les itérations sont bornées dans le temps
¡ Les réunions sont bornées dans le temps
¡ Tout est borné !
¡ Et donc le coût est prévisible et a

moins de chance d’être dépassé
13
ÉTAPE 0 : LA VISION
¡ Le cap : si vous ne savez pas où vous voulez aller, oùirez-vous?
¡ Sans vision, les retards sont pris en tout début de projet ; l’équipe est
alors hésitante, refusant de prendre le risque de se tromper de
direction…
¡ Objectifs :
¡ Situer le produit dans l’organisation
¡ Lui donner un sens (raison d’être du produit)
14
La vision : comme un titre
¡ Imaginer un exercice où on doit spécifier un dessin à faire, par

ex. une maison
¡ On va expliquer : un toit rouge, 2 fenêtres, une porte bleue, un

banc et des fleurs à droite de la porte, etc.
Vision
modèle
Architecte
Vision
Dessin Animé
15 Exemple de vision
Dans un contexte de SAV, pour un
système de gestion de tickets :
Ici, JIRA
« Le système permettra de voir d’un seul coup d’œil les

tâches à faire, avec l’urgence, le demandeur (client),
qui le prend en charge, la date du ticket, l’état
d’avancement du ticket »
16
Vision = un attracteur
¡ Selon la théorie de l’auto organisation, la vision est un attracteur

de tous les éléments épars qui participent à réaliser une activité
¡ Elle réunit tous les points de vue vers un objectif commun connu
de tous
¡ Même de façon inconsciente
17
Ex. d’attracteur…. visuel
¡ Que voyez-vous sur cette image?
¡ Et sur celle-ci?
¡ Et celles-là?
18 Un attracteur visuel :
la mémoire
¡ Une fois qu’un objet a été identifié par le cerveau, les
stimuli visuels activent la mémoire
¡ l'ensemble des stimuli s'organise alors par rapport à cet
attracteur
¡ Un effort est nécessaire pour tenter de voir l’autre

image
¡ La vision Produit crée cet attracteur au sein de

l’équipe, pour toutes les étapes :
¡ Planification, Affinage du backlog
¡ Choix des Solutions techniques
¡ Codage
¡ Améliorations
19
EN SAVOIR PLUS
sur la vision …
Créer une vision pour un nouveau système d’écoute
musicale en ligne (UK, 9’)
https://www.youtube.com/watch?v=6h3avYCgh9Q
20
Backlog Produit
la CAPTURE des EXIGENCES
21 Backlog Produit
(Carnet de Produit)
¡ Contient des User Stories (Scrum)

¡ DEF User Story
¡ Une demande fonctionnelle d’un utilisateur
¡ Apporte de la valeur business au produit
¡ Ecrite en langage naturel
¡ Exemple : « En tant que client, je souhaite

pouvoir ajouter un produit dans mon
panier afin de pouvoir l’acheter »
22 Combien d’User Stories ?
¡ Au max 20 US au début, pour respecter
le vœux agile « peu de stock »
¡ Principe : « être précis à court terme,
grossier à long terme »
¡ Attention : imprécision pour le long terme

ne signifie pas “inutile”
¡ Permet d’estimer le « reste à faire »
¡ On ne les oubliera pas plus tard
¡ Une US = un résumé formaté, pour avoir

une vision rapide de la demande
¡ Elle sera détaillée ensuite avec l’équipe

23
Granularité des US ?
¡Une user story doit pouvoir être

implémentée en une itération
¡ Une itération doit comporter au
moins 4 User Stories
24
Comment obtenir les US ?
¡ C’est le problème du Product Owner
¡ Méthodes possibles : Brainstorming, définition de personnae,

identification des scénarios utilisateur,...
¡ Par exemple, pour un logiciel de gestion de carnet d'adresses,

un scénario est :
¡ "Je rentre un nom ou prénom, et le logiciel affiche la liste de toutes
les personnes qui possèdent ce nom ou ce prénom"
¡ "Je peux choisir d’exporter mon carnet d'adresses au format HTML
ou XML"
25 Description des US
Notion de ‘Fini’ (DoD)
¡ Une user story pourra contenir : une
description, des tests d’acceptation, un
résumé simple, etc.
¡ Les tests d’acceptation permettent de définir le

DONE, càd. expliciter quand une US sera considé-
rée comme terminée :
¡ « ça marche à peu près » : ???
¡ « c’est OK pour 80% des data »
¡ « c’est tout bon, mais la version Anglaise reste à faire »
26 Format des User Stories
En tant que… (rôle)
Je peux …. (tâche)
Afin de …. (but)
En tant que Pilote,
je peux régler le commutateur en mode « horizontal »
afin de maintenir les ailes à l'horizontal pour que l'avion

reste sur sa trajectoire
• Les user stories proposées par le PO sont discutées avec

l’équipe pour lever toute ambiguïté de compréhension
27 Exemples de User Story
ETQ Assureur, je peux

récupérer des contrats
d’assurance sur le site web
afin de vérifier leur précision
et leur légalité
ETQ Assureur, je peux

chercher les infos du permis
Source : chaîne YouTube: de conduire du candidat
BA-Experts chez la préfecture
(Business Analysis)
concernée afin de vérifier
leur exactitude
28 Règles pour écrire des US
correctes
¡ REGLE 1 : rester simple (principe KISS)
¡ REGLE 2 : parler du QUOI (pas du COMMENT)

¡ REGLE 3 : rester dans le périmètre du projet
(vision!), et dans le champ de responsabilités de
l’organisation / du service
¡ REGLE 4 : lever l’ambiguïté des termes
¡ REGLE 5 : pratiquer si possible la réécriture des US

29 Rester simple : principe KISS
(Keep It Simple & Stupid)
¡ Voici une user story définie pour un logiciel
d’assurance auto :
En tant qu’internaute,
je peux naviguer sur le site, saisir mes informations
personnelles et celles du véhicule, et soumettre une
demande en ligne,
Afin d’obtenir une couverture d’assurance
automobile.
¡ Qu’en pensez-vous?
30
KISS sur un exemple
¡ Trop de ‘choses à faire’ mentionnées

En tant qu’internaute,
je peux naviguer sur le site,
→ pas simple
saisir mes informations
personnelles et celles du ¡ REGLE : pas de User Story composée
véhicule, et soumettre une
demande en ligne, ¡ Éviter les ET (et OU)
Afin d’obtenir une ¡ pour ‘je peux’
couverture d’assurance
automobile. ¡ sur les données : données personnelles,
données véhicules
¡ Éviter les ‘à moins que’, ‘excepté pour’…
¡ Les scinder
31
KISS Assurance - réponse
¡ Ici on découpe en 3 User Stories :
¡ « En tant qu’internaute, je peux naviguer sur le site,

Afin de choisir la couverture d’assurance automobile
qui me convient »
¡ « En tant qu’internaute, je peux saisir mes

informations personnelles et celles du véhicule,
Afin de comparer les offres d’assurance automobile »
¡ « En tant qu’internaute, je peux soumettre une

demande d’assurance automobile en ligne,
Afin d’obtenir un contrat »
32
Lever l’ambiguïté (Règle 4)
¡ Ex., un Responsable du Stock écrit la US :
En tant que Resp. du Stock,
je peux commander la bonne
quantité de produits que nous
allons vendre
Afin d’éviter d’avoir des coûts de
stock trop élevés
¡ Qu’est-ce qui est ambigu ici ?
¡ « la bonne quantité » : quelle valeur ? Quelle unité ?

(produit unitaire, palette, chargement camion,…)
¡ « coûts trop élevés » : idem, subjectif --> valeur seuil
¡ « nous allons vendre » : quand ? demain, la

semaine prochaine ?
33 Pratiquer la réécriture des US
(Règle 5)
¡ Par un collègue, si possible très différent de soi
¡ Consigne : ne reprendre aucun nom / verbe
identique
¡ On discute des différences
¡ Ex.: pour une agence de voyage, Tim écrit :

En tant qu’opérateur du Centre d’Appel,
je peux saisir au moins 12 réservations par
heure en période de forte activité
Afin de réduire le temps d’attente des clients
Et Léa propose la réécriture suivante :
En tant qu’agent de voyage,
je suis capable d’effectuer un minimum de
12 demandes de voyages en 60 min durant
la partie de l’année la plus chargée
Afin de minimiser les abandons
téléphoniques Votre avis ?
34
Granularité du besoin
¡Vocabulaire SCRUM
¡ « Thème » : domaine Produit, grosse Feature
¡ « Feature » : grosse fonctionnalité Produit
¡ « Epic » : grosse story
¡ « User Story » : besoin élémentaire d’un Utilisateur
¡ « Task » : tâche (technique) pour faire la US
BACKLOG de PRODUIT: Je retiens….
¡ Les features (fonctionnalités)

sont déclinées en epic, elles-
mêmes en User Stories, et les US
en tâches
¡ Les US suivent le format:
ETQ…(rôle) je peux…(action) afin de
…(but)
RAPPELEZ-VOUS
¡ Une user story doit être implémentée sur une
seule itération
¡ Un sprint doit comporter au moins 4 US
¡ J’applique les principes KISS pour écrire les US
¡ La méthode de Réécriture permet de valider
mes US
36
EN SAVOIR PLUS
sur le découpage
agile
Comment disposer de plusieurs user stories alors
que le client n’a exprimé qu’un seul besoin ?
http://coach-agile.com/2014/09/coach-agile-decouper-ses-user-
stories/

Cours1 2 Vision Bklog SB

Transféré par

Droits d'auteur :

Formats disponibles

Cours1 2 Vision Bklog SB

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours1 2 Vision Bklog SB

Transféré par

Droits d'auteur :

Formats disponibles

Cours 2

Vision, cycle, backlog Produit

¡ Scrum : présentation rapide

1. Définition de la vision du produit

2. Backlog produit (ou carnet de produit, catalogue des besoins)

3. Planning Game : élaboration du backlog de sprint

◼ Pas de modification du backlog de sprint possible

◼ Affinage du backlog Produit : une fois par semaine

¡ Scrum : la durée des Sprints peut varier de 2 à 4 semaines.

¡ Certains voudraient 1 semaine, mais c'est court ! À

¡ Donc si les Sprints sont trop courts

¡ À l'inverse si les Sprints sont trop longs

¡ Il faut donc un bon compromis sur la durée des

¡ Attention au Sprint 0 et au dernier Sprint

◼ Interventions régulées – 2 min. par personne

6. Incrément logiciel : livré au Product Owner à la

¡ Et donc le coût est prévisible et a

¡ Le cap : si vous ne savez pas où vous voulez aller, oùirez-vous?

La vision : comme un titre

¡ Imaginer un exercice où on doit spécifier un dessin à faire, par

¡ On va expliquer : un toit rouge, 2 fenêtres, une porte bleue, un

« Le système permettra de voir d’un seul coup d’œil les

¡ Selon la théorie de l’auto organisation, la vision est un attracteur

¡ Un effort est nécessaire pour tenter de voir l’autre

¡ La vision Produit crée cet attracteur au sein de

¡ Contient des User Stories (Scrum)

¡ Exemple : « En tant que client, je souhaite

¡ Attention : imprécision pour le long terme

¡ Une US = un résumé formaté, pour avoir

¡ Elle sera détaillée ensuite avec l’équipe

¡Une user story doit pouvoir être

¡ C’est le problème du Product Owner

¡ Méthodes possibles : Brainstorming, définition de personnae,

¡ Par exemple, pour un logiciel de gestion de carnet d'adresses,

¡ Les tests d’acceptation permettent de définir le

En tant que Pilote,

je peux régler le commutateur en mode « horizontal »

afin de maintenir les ailes à l'horizontal pour que l'avion

• Les user stories proposées par le PO sont discutées avec

ETQ Assureur, je peux

ETQ Assureur, je peux

¡ REGLE 1 : rester simple (principe KISS)

¡ REGLE 2 : parler du QUOI (pas du COMMENT)

¡ REGLE 4 : lever l’ambiguïté des termes

¡ REGLE 5 : pratiquer si possible la réécriture des US

KISS sur un exemple

¡ Trop de ‘choses à faire’ mentionnées

¡ « En tant qu’internaute, je peux naviguer sur le site,

¡ « En tant qu’internaute, je peux saisir mes

¡ « En tant qu’internaute, je peux soumettre une

¡ Qu’est-ce qui est ambigu ici ?

¡ « la bonne quantité » : quelle valeur ? Quelle unité ?

¡ « nous allons vendre » : quand ? demain, la

¡ Ex.: pour une agence de voyage, Tim écrit :

¡ Les features (fonctionnalités)

Vous aimerez peut-être aussi