FORMATION PROFESSIONNELLE

AGILE

Formateur:
Pr HIBA ASRI
Pour:
Forces Auxiliaires, Agadir

1
INTRODUCTION

2
 DÉFINITION (MÉTHODE AGILE)

• Approche itérative et incrémentale, menée dans un esprit collaboratif avec juste ce qu’il faut de
formalisme.
• Génère un produit de qualité
• Prend en considération l’évolution des besoins du client.
Concept d’agilité:
Formalisés en février 2001 (Etat Unis) par me manifest Agile (http://agilemanifesto.org)

3
 MANIFESTE

• Approche itérative et incrémentale, menée dans un esprit collaboratif avec juste ce qu’il faut de
formalisme.
• Génère un produit de qualité
• Prend en considération l’évolution des besoins du client.
Concept d’agilité:
Formalisés en février 2001 (Etat Unis) par me manifest Agile (http://agilemanifesto.org)

Kent Beck James Grenning Robert C. Martin

Mike Beedle Jim Highsmith Steve Mellor Nous découvrons comment mieux
Arie van Bennekum Andrew Hunt Ken Schwaber développer des logiciels par la pratique et
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
en aidant les autres à le faire.
Martin Fowler Brian Marick
4
MANIFESTE AGILE (4 VALEURS)

5
MANIFESTE AGILE (12 PRINCIPES)

6
 APPROCHE INCRÉMENTALE VS
ITÉRATIVE

Approche incrémentale:
Rajouter des briques fonctionnelles successives à l’application. E.g: un premier incrément va poser
la brique « se connecter » et un second ajoutera la brique « gérer son profil ».

Approche itérative:
Développer une fonctionnalité et de l’affiner par des itérations successives. On n’ajoute pas de
nouvelles fonctionnalités, on améliore l’existant.

Exemple: réalisation du Mona Lisa selon Jeff Patton en incrémental et en itératif

7
 APPROCHE INCRÉMENTALE VS
ITÉRATIVE

Approche incrémentale Approche itérative

8
 DÉVELOPPEMENT INCRÉMENTAL
ITÉRATIF

• Les équipes agiles combinent les deux.

• Il s’agit de partir d’une idée, d’abord précisée itérativement, ensuite partiellement développée en
un incrément fonctionnel, potentiellement livrable tel quel.
• Chaque incrément suivant étant susceptible d’affiner les fonctionnalités existantes, est également
itératif. Cette approche combinée est beaucoup plus puissante.

9
 AGILE VS CLASSIQUES

Méthode classiques:
La création d’applications est inscrite dans un processus séquentiel qui part d’un besoin ferme et qui
aboutit à la mise en place de la solution technique correspondante, sans possibilité de modification
en cours de développement.

Prédictive Adaptative
Classiques

Basée sur une Accepte le changement et

expression figée du l’évolution
besoin. Mise en place de l’application
par briques incrémentales et

Agiles
itératives.

10
AGILE VS CLASSIQUES

11
MÉTHODE XP / SCRUM

12
MÉTHODE XP

13
AGILE VS CLASSIQUES

14
 MÉTHODE XP

• Méthodologie de développement basée sur les valeurs, les principes et les pratiques de l’agilité
• Petites livraisons : entre 2 et 6 mois
• Itérations : entre 1 à 4 semaines

15
 MÉTHODE XP (5 VALEURS)

• la communication entre tous

les intervenants :
entre développeurs (programmation
en binôme), entre développeurs et
managers (tests, estimations), entre
développeurs et clients (tests,
spécifications).

• Se poser les bonnes

questions et de partager
l'information.
16
 MÉTHODE XP (5 VALEURS)

• Le respect pour les autres, ainsi que

le respect de soi.
• Les membres respectent leur
propre travail en cherchant toujours
la qualité et la meilleure conception
pour la solution.
• ne jamais valider les
modifications qui cassent la
compilation,
• ne jamais échouer les tests
unitaires existants
• ne jamais retarder le travail de
pairs.
17
 MÉTHODE XP (5 VALEURS)

• Le courage permet de sortir

d'une situation inadaptée.
• Certains changements
demandent beaucoup de
courage:
• changer l'architecture d'un
projet,
• jeter du code pour en
produire un meilleur
• essayer une nouvelle
technique.
18
 MÉTHODE XP (5 VALEURS)

XP encourage l'orientation vers

la solution la plus simple qui
puisse satisfaire les besoins du
client.

19
 MÉTHODE XP (5 VALEURS)

• Repérer et corriger les erreurs

plus facilement et d’accueillir les
changements.

• Des tests unitaires, fonctionnels

• Du client: Revue avec le client toutes les
deux à trois semaines
• De l’équipe: Grace à la communication
continuelle

20
MÉTHODE XP (12 PRATIQUE)

21
MÉTHODE XP (12 PRATIQUE)

22
MÉTHODE XP (12 PRATIQUE)

23
MÉTHODE XP (12 PRATIQUE)

24
 CYCLE DE VIE

Exploration
• Questions techniques : architecture du logiciel
• Besoins sous forme de user stories
• Estimation des User stories en terme de temps de développement.
25
 CYCLE DE VIE

Planning
• Définir Le planning de la première release (uniquement des fonctionnalités essentielles), à enrichir par
la suite.
• Durée du planning game : un ou deux jours
• Première release : deux à six mois plus tard.
26
 CYCLE DE VIE

Itérations jusqu'à la première release

• Phase de développement sous forme d'itérations d’une à quatre semaines.
• Chaque itération produit un ensemble de fonctionnalités passant avec succès les tests fonctionnels
associés.
• La première itération est dédiée à la mise en place de l'architecture du système.
• Des brèves réunions réunissent toute l'équipe quotidiennement pour mettre chacun au courant de
l'avancement du projet.
27
 CYCLE DE VIE

Mise en production
• Des itérations plus courtes pour renforcer le feedback.
• Au cours de cette phase, les développeurs procèdent à des réglages affinés pour améliorer les
performances.
• A la fin de cette phase, un produit réalisé avec toutes les fonctionnalités indispensables et parfaitement
fonctionnelles.
28
 CYCLE DE VIE

Maintenance
• Continuer à faire fonctionner le système
• Adjoindre des fonctionnalités secondaires.
• l'ajout de fonctionnalités secondaires donne lieu à des nouvelles releases, une nouvelle phase
d'exploration rapide doit avoir lieu.
29
 CYCLE DE VIE

Mort
• La fin d'un projet intervient quand le client n'arrive plus à écrire de user stories
supplémentaires.
30
 EQUIPE XP
Développeur Tracker
• Conception et programmation • Suivre le planning pour chaque itération.
• Interagir avec les développeurs pour le respect du planning
• Participe aux séances de planification, évalue les tâches
de l'itération courante
et leur difficulté
• Détection des éventuels retards et rectifications si besoin
• Définition des test unitaires
Manager
• Implémentation des fonctionnalités et des tests unitaire • Responsable du projet
Client • Apporte à l'équipe le courage et la confiance
• Vérification de la satisfaction du client
• Écrit, explique et maîtrise les scénarios
• Contrôle le planning
• Spécifie les tests fonctionnels de recette
Coach
• Définit les priorités
• Organise et anime les séances de planifications
Testeur • Favorise la créativité du groupe, n'impose pas ses solutions
technique
• Écriture des tests de recette automatiques pour valider
les scénarios clients • Au fur et à mesure de la maturation de l'équipe, sont rôle
diminue et l'équipe devient plus autonome.
• Peut influer sur les choix du clients en fonction de la
testabilité des scénarios
31
 CONCLUSION

Utiliser XP quand… Ne pas utiliser XP si…

 Besoins flous
 Besoins changeront peu
 Périmètre mal défini  Périmètre bien défini
 Petite équipe – 12 personnes maximum  Équipe de plus de 12 personnes
 Site unique  Développement multi-sites
 Développement offshore
 Projets critiques

32
MÉTHODE SCRUM

33
 SCRUM

• Cadre de travail (Framework) permettant de répondre à

des problèmes complexes et changeants, tout en livrant de
manière productive et créative des produits de la plus
grande valeur possible.
« Guide Scrum » de Ken Schwaber et Jeff Sutherland

34
 SCRUM

Scrum est un cadre de travail agile qui permet de produire la plus grande valeur
métier dans la durée la plus courte.

• Méthode itérative et incrémentale:

• Réalisation d’un ensemble de fonctionnalités par itération
• Itération d’une durée fixe (de 2 à 4 semaines) => Sprint
• Livraison d’un produit partiel fonctionnel par itération
• Participation du client
• Définition des fonctionnalités prioritaires
• Ajout de fonctionnalités en cours de projet

35
 PILIERS SCRUM

Pilier n°1 – La transparence Pilier n°2 – L’inspection Pilier n°3 – L’adaptation

• la transparence implique que • Utiliser Scrum implique de • L’adaptation est la
les variables les plus contrôler régulièrement conséquence logique de
importantes du processus sont l’état d’avancement du projet l’inspection. Elle intervient
à disposition de tous les et les différents outils Scrum pour limiter les risques liés
acteurs : avancement, (artefacts). aux écarts détectés et garder
ressources, risques, planning, le projet sur les bons rails.
etc. • L’objectif est de détecter
rapidement les écarts entre
• Tout le monde soit sur la même
les prévisions et la
longueur d’onde en termes de
réalisation.
partage et de compréhension
de l’information.

36
 ROLES SCRUM

Rôles
Equipe SCRUM
Organisationels
• La Development
Team Development
Management
Team

Scrum
• Le Product Client
Master
Owner

Product
Utilisateur
Owner 37
LE SCRUM MASTER

38
 SA FONCTION

• Protège l’équipe des turbulences

• Il n’est pas un membre de l’Équipe

• Il optimise la productivité de l’Équipe

• Il contrôle l’”Inspect-&-Adapt” de l’Équipe

• Il assure que les idéaux “agiles” soient bien compris et respectés

par tous les participants au projet.

• Il n’est pas responsable des déliverables.

39
 SA MISSION

• Protéger l’Équipe Scrum

• Lever les obstacles

• Exécuter le process

• Travailler avec le Product Owner

• Changer l’Organisation

40
LE PRODUCT OWNER

41
 SA FONCTION

• Il pilote le projet d’un point de vue métier

• Il communique une vision claire du produit et défini ses

caractéristiques

• Il accepte ou rejette le produit à la fin de chaque Sprint

• Il s’assure que l’Équipe se concentre sur les items du Backlog de plus
forte valeur ajoutée

• Il a le même objectif que l’Équipe

• Il est responsable du Retour sur Investissement et des livraisons.

42
 SA MISSION

• Se concentre sur le retour sur investissement

• Construit et communique la vision

• Entretien le Product Backlog

• Rend compte de l’acceptance des déliverables

• Établi et maintien le Plan de Livraison

43
L’ÉQUIPE

44
 SA FONCTION

• Elle délivre le produit et elle est responsable de sa qualité

• Elle travaille avec les utilisateurs-finaux, le client, le Product Owner

pour comprendre les exigences-métier.

• Elle s’engage volontairement

• Elle travaille continuellement avec le Product Owner pour définir la

direction stratégique du Produit.

45
 CONSTITUER L’ÉQUIPE

• 5/9 personnes

• Multidisciplinaire

• Autogérée

• Cross-fonctionnelle / transverse

• Plus orientée compétence que fonction

46
 COMMENT OPTIMISER LE TRAVAIL DE
L’ÉQUIPE...

• Créer une règle de vie de l’Équipe

• Ne jamais utiliser le “VOUS”

• Être à l’heure

• Utiliser un “bâton de parole”

• Ne jamais être nominatif

47
 COLLABORATION

• Le Product Owner n’est pas un ennemi

• D’autres équipes ont besoin de savoir que

nous avons besoin d’elles.

• Nous avons tous le même objectif

• Une Équipe = un espace dédié à l’Équipe

48
 SA MISSION
• Garantir la Qualité
• Livrer
• Livrer
• Livrer
• Estimer
• Estimer
• Estimer
• S’engager
• S’autogérer
• S’organiser .... Elle-même

49
Les Rôles Organisationnels
50
LE CLIENT

51
 SA FONCTION

• Il demande le produit

• Il contracte l’organisation pour le développement de son produit

• Typiquement, il s’agit d’un responsable qui achète un

développement de produit par un sous-traitant.

• Dans les projets internes, il s’agit principalement du sponsor au projet,

c’est à dire la personne validant le projet et le budget.

52
 SA MISSION

• Il commande le produit

• Il paye le développement du produit

• Il donne des feed-back et des révisions

53
LE MANAGER

54
 SA FONCTION

• Le management, la gestion, est primordial dans tout projet Scrum.

Il permet à l’Équipe de constituer un environnement optimal pour
le déroulement du projet Scrum.

• Le manager donne de la structure et de la stabilité.

• Il travaille de concert avec le ScrumMaster pour réorganiser

l’organigramme de la structure et donner de la guidance si
nécessaire.

55
 SA MISSION

• Il s’assure que l’organisation puisse survivre

en cas de défaillance.

• Il crée des règles et des lignes directrices.

56
L’UTILISATEUR FINAL

57
 SA FONCTION

• Ce rôle peut être joué par un grand nombre de

personnes.

• L'Utilisateur final est celui qui connaît les besoins et avec

cette connaissance, il définit le produit en disant à
l'équipe ce dont il a besoin comme fonctionnalités.

58
 SA MISSION

• Il connaît ses besoins et ses exigences

• Il donne son feed-back lors des revues

• Il participe au Sprint Planning 1

59
COMMENT CES RÔLES TRAVAILLENT- ILS
ENSEMBLE?

60
Rôles organisationnels

Scrum Team Roles

61
LE SCRUMMASTER TRAVAILLE AVEC LE
PRODUCT OWNER

62
LE SCRUMMASTER TRAVAILLE AVEC LA DEVELOPMENT
TEAM

63
LE PRODUCT OWNER TRAVAILLE AVEC LE CLIENT

64
LA DEVELOPMENT TEAM TRAVAILLE AVEC L’UTILISATEUR
FINAL

65
LE SCRUMMASTER TRAVAILLE AVEC LE MANAGER

66
LE PRODUCT OWNER A BESOIN DE CONNAÎTRE CE QUE
LE MARCHÉ (L’UTILISATEUR FINAL) SOUHAITE.

67
 SCRUM VS XP

XP (eXtreme Programming) : Gestion du développement logiciel : forte réactivité, travail

d’équipe, qualité du code , développement dirigé par les tests (TDD), intégration continue, simplicité…

SCRUM : Gestion de projet : définition de rôles, itérations courtes de durées fixes, participation active
du client, collaboration, communication, feedback, flexibilité aux changements, amélioration continue

Une distinction fondamentale entre Scrum

et XP est que le premier se concentre
exclusivement sur un modèle de gestion du
projet, alors que le second met l’accent sur
les pratiques et techniques de
développement de logiciels.
68
 SCRUM – CYCLE 4

Vision
du
Produit

1. Définition de la vision du produit

 Le cap
 Une ou deux phrases 69
 SCRUM – CYCLE 5

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 70
 SCRUM – CYCLE 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 71
 SCRUM – CYCLE

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 72

 SCRUM – CYCLE

5. Mêlée quotidienne
 Point de contrôle quotidien de l’équipe (max 15’)

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

73
 SCRUM – CYCLE 9

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

fin du sprint : donné aux utilisateurs finaux,
commerciaux, prospects 74
PROCESSUS SCRUM

1 4
75
 SPRINT PLANNING MEETING

◾ 2 PARTIES:
• Organisateur: ◾ Le QUOI?
◾ Le COMMENT?
Product Owner
◾ LE PRODUCT OWNER:
◾ Présente le Product Backlog priorisé par le client

• Participants: et/ou les utilisateurs

◾ Présente le Release Plan Initial
l’équipe (actif), le
◾ L’Equipe
ScrumMaster ◾ Présentation de la Vision
(passif) ◾ Estime le Product Backlog en fonction de sa faisabilité (estimation
fonctionelle)
◾ Découpe le Product Backlog en Sprint Backlogs avec le Product Owner
◾ Découpe le Sprint Backlog en tâches
• Durée: 8 heures ◾ Estime le Sprint Backlog

pour un Sprint de ◾ LE PRODUCT OWNER ET L’EQUIPE:

4 semaines
◾ Définissent l’objectif du Sprint
◾ Valident la Definition of Done 76
 POUR CHAQUE ITEM DU PRODUCT BACKLOG
(US)

• Quelle interface devons-nous designer?

• Quelle architecture devons-nous créer?
• Quelles tables devons-nous actualiser?
• Quels composants devons-nous mettre à jour ou
créer?

Sprint
Planning
2
Design
77
 • Synchronisation
DAILY SCRUM /
Daily Scrum Engagement sur les tâches

78
 DAILY SCRUM

• Organisateur:
l’équipe ◾ C’est l’inspect-and-adapt de
l’équipe: synchronisation et
engagement
• Participants: ◾ Les 3 questions:
l’équipe (actif), le 1. Qu’est-ce que tu as fait hier?
ScrumMaster 2. Quels sont les problèmes que tu as
rencontrés?
(passif), Product 3. Qu’est-ce que tu as prévu
Owner (passif) aujourd’hui?

• Durée: 15 min
79
 LA REVUE DE SPRINT
• Organisateur: Product
Owner
• Participants: l’équipe
(actif), le
ScrumMaster (passif),
le Management
(actif), le client (actif),
les utilisateurs (actifs)
• Durée: 4 heures pour
un Sprint de 4
semaines
◾ C’est l’inspect-and-adapt des utilisateurs, du
client et du management
◾ L’équipe présente les résultats du Sprint
◾ Utilisateurs/Client/ Management expriment
leurs remarques et trouvent un compromis
avec l’équipe
◾ Le Product Owner valide ou rejète les items
du Sprint Backlog en fonction de la
Definition of Done
◾ C’est le Product Owner qui a toujours le
dernier mot...
80
 SPRINT REVIEW

• Présentation (par l’équipe)

• Feedback (par l’utilisateur final)

• C’est l’inspect-&-adapt de l’utilisateur

permettant la création ou le changement des
items du Product Backlog
81
 LA RÉTROSPECTIVE

• Organisateur: ◾ Analyse du Process Scrum:

ScrumMaster
• Participants: l’équipe
(actif), le ◾ Points principaux de vérification:
ScrumMaster (actif),
le Product Owner
(actif en sa qualité de
membre de l’équipe)
◾ Comment cela c’est passé pendant le Sprint
◾ Comment s’améliorer
◾ La communication dans l’équipe
◾ Les relations entre les
• membres de l’équipe
◾ Les process et les outils

◾ Les besoins en formation

• Durée: 3 heures pour
un Sprint de 4
semaines
82
 RÉTROSPECTIVE

• Nous faisons un point après l’action en nous

posant deux questions:
– Qu’est-ce qui a bien fonctionné?
– Que devons-nous améliorer?

• Objectifs:
– Apprendre du passé pour préparer l’avenir
– Améliorer la productivité de l’équipe

83
 FINALITÉ DE LA RÉTROSPECTIVE

• Debriefing
• Amélioration
• Comprendre la réalité
Où allons-nous à partir d’ici?
• Apprendre
• “Input” pour le Sprint
Planning

84
LE PRODUCT BACKLOG

◾ Le Product Backlog répond

aux questions suivantes:
Quoi? Quand? Pour Qui?
85
GDP avec Scrum │ © Pierre E. Neis 71
 UN BACKLOG DE PRODUIT

Elément de backlog Estimation

Un invité peut faire une réservation 3
En tant qu'invité, j'annule une réservation 5
En tant qu'invité, je change les dates d'une
3
réservation.
En tant qu'employé de l'hôtel, je produis les
8
rapports de revenu par chambre
Améliorer la gestion des exceptions 8
... 30
... 50 86
 SPRINT BACKLOG

Tâches pour Les membres de

transformer le la Dev. Team Les équipes sont
Tâches estimées Le Sprint Backlog
Product Backlog s’engagent sur mesurées en
en heures est revu
en les tâches une fonction de leurs
journellement
fonctionnalité- fois que le Sprint engagements
produit a démarré

Une tâche ne De nouvelles

doit pas tâches sont
nécessiter plus identifiées,
d’un jour ou d’autres sont
deux pour être modifées ou
Done. supprimées. Et pas sur le
Les tâches ne temps
sont jamais nécessaire
assignées pour les
Les heures réaliser
Les grandes
restantes de
tâches sont travail
découpées pour chaque
ultérieurement tâche sont
dans le Sprint mises à jour

87
SPRINT BACKLOG / PRODUCT BACKLOG

88
 USER STORY

• Dans les méthodes agiles, un récit utilisateur ou user

story est une phrase simple dans le langage de tous les
jours permettant de décrire avec précision le contenu
d'une fonctionnalité à développer.
• La phrase contient généralement trois éléments
descriptifs de la fonctionnalité : Qui ? Quoi ? Pourquoi ?.
• En tant que <qui>, je veux <quoi> afin de <pourquoi>
• Le pourquoi est optionnel. Il permet cependant d'identifier
l'intérêt de la fonctionnalité.

89
 USER STORY

AFIN DE “RAISON”, EN TANT QUE “RÔLE”, JE VEUX “ FONCTIONNALITÉ”.

90
 USER STORY

• Exemple :
Afin d’obtenir de l’argent facilement, en tant que client de la banque, je veux retirer des billets à l’aide d’un
distributeur automatique de billets (DAB)
• En tant que responsable, je veux pouvoir rechercher mes clients par leur prénom et leur nom de famille afin
de les retrouver rapidement lorsque je reçois un appel de leur part.
• En tant que professeur, je veux pouvoir modifier mes emplois du temps mais pas ceux des autres utilisateurs
• En tant que Client, je veux réserver un billet de train pour me rendre à Paris
• En tant qu’utilisateur, je veux me connecter à Google afin d’accéder à tous mes services en lignes.
• En tant que consommateur, je veux une fonctionnalité de panier d’achat afin de pouvoir acheter facilement
des articles en ligne.
• En tant que cadre supérieur, je veux produire un rapport afin d’identifier les départements qui doivent
améliorer leur productivité.

91
 USER STORY

Une User Story contient généralement les informations suivantes :

• ID – un identifiant unique de US
• Nom – un nom court (entre 2 et 10 mots), descriptif de la fonctionnalité attendue par le client.
Le nom doit être suffisamment clair pour que les membres de l’équipe et le Product Owner
comprennent de quelle fonction il s’agit.
• Importance – un entier qui fixe la priorité des Stories. La priorité d’une story peut être
changée en cours de réalisation du projet.
• Estimation – La quantité de travail nécessaire pour développer, tester, et valider cette
fonctionnalité. L’unité de mesure peut être un nombre de jours idéaux (jours à 100% dédiés à
la fonctionnalité) ou un nombre de points.
• Critères d’acceptabilité ou Tests de validation.
• Notes –autre information : clarifications, références documentaires…
92
INVEST GUIDELINE

• Indépendante : assure l’indépendance d’une User Story

vis-à-vis des autres user stories du backlog;
• Négociable : une User Story doit être un support de
discussion en vue d’une amélioration du besoin initial;
• Valorisable : la réalisation d’une User Story doit rendre un
service à l’utilisateur. En un mot, une User Story n’a de
sens que si elle apporte une valeur métier;
• Estimable : une User Story doit être bien définie pour être
facilement chiffrable;
• Suffisamment petit : une User Story doit être réalisable sur
un sprint;
• Testable : une User Story doit être accompagnée de ses
critères d’acceptabilité pour faciliter sa validation.
93
 C O M B I E N D E U S E R STO R I E S ? ?

◾Au max 20 US au début, pour respecter le vœux agile «peu de stock »

◾Princ ipe :«ê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 »
◾ Ne pas les oublier 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

94
GRANULARITÉS DES USER STORIES

◾Une user story doit pouvoir être

implémentée en une itération (un sprint)
◾Une itération doit c omporter entre 4 et 6 User
Stories

95
 C O M M E N T O BT E N I R L E S U S

◾C ’est le problème du Produc t 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"

96
 22 DESCRIPTION DES US
NOTION DE ‘FINI’ (DOD)

◾Definition of Done
◾Une user story, c ’est :un résumé, une description, des tests
d’acceptation, etc.

◾Les tests d’acceptation permettent de définir le DONE, càd:

préciser quand une USsera considérée comme terminée :

◾«ç a marc he à peu près »: ???
◾«c ’ est OK pour 80%des data »
◾«c’est tout bon, mais la version Anglaise reste à faire » 97
 UN EXEMPLE DE USER STORIES

En tant que Pilote,

je peux régler le c ommutateur en mode «horizontal »

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

reste sur sa trajec toire

Rappel :les user stories proposées par le PO sont discutées avec

l’équipe pour lever toute ambiguïté de c ompréhension

98
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

99
 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 c ouverture d’assuranc e
automobile.

◾Qu’en pensez-vous ?

100
 KISS SUR UN EXEMPLE
En tant qu’internaute,
je peux naviguer sur le site, saisir mes
informations personnelleset c elles du
véhic ule, et soumettre une demande en
ligne,
Afin d ’obtenir une couverture
d’assurance automobile.
◾Trop de ‘c hoses à faire’ mentionnées
 pas simple
◾REGLE : pas de UserStory composée
◾ Éviter les ET(et OU)
◾ pour ‘je peux’
◾ sur les données :données personnelles, données véhicules
◾ Éviter les ‘à moins que’, ‘excepté pour’…
◾Les scinder
101
(c) V. Deslandres, IUTLyon
KISS ASSURANCE – RÉPONSE

◾Ic i 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 »

◾ «Entant 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 c ontrat »
102
 LEVER L’AMBIGUÏTÉ (RÈGLE 4)

◾ Ex., un Responsable du Stoc k éc rit la US:

En tant que Resp. du Stoc k,

je peux commander la bonne
quantité de produits que nous
allons vendre
Afin d’éviter d’avoir des c oûts de
stoc k 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, subjec tif -->valeur seuil

◾ «nous allons vendre »:quand ? demain, la semaine

proc haine ?
103
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 agenc e de voyage, Tim écrit :

En tant qu’opérateur du C entre d’Appel,

je peux saisir au moins 12 réservations par
heure en période de forte ac tivité
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 Votre avis ?
Afin de minimiser les abandons
téléphoniques 104
 RÉÉCRITURE – ANALYSE SUR L’EX (1)

En tant qu’opérateur du C entre d’Appel, je peux saisir

au moins 12 réservations par heure en période de
forte ac tivité
Afin de réduire le temps d’attente des clients

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

◾«opérateur du Centre d’Appel »ou «agent de voyage »?

 préférer le rôle (agent de voyage) plutôt que la fonction

◾«saisir »ou «effectuer »?  ‘effectuer’ est trop vague, à éviter !

◾«12 réservations »ou «12 demandes »?  préférer les termes métiers, réservation
105
 RÉÉCRITURE – ANALYSE SUR L’EX (2)

En tant qu’opérateur du C entre d’Appel, je peux saisir au

moins 12 réservations par heure en période de forte ac tivité
Afin de réduire le temps d’attente des clients

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

◾«en période de forte activité »signifiait pour TIM, ‘dans la journée’

◾Mais Léa introduit la notion de saisonnalité qui est intéressante : en période de

vacances, familles  réservations plus longues ! Ajouter une précision
106
 RÉÉCRITURE – ANALYSE SUR L’EX (3)

En tant qu’opérateur du C entre d’Appel, je peux saisir au

moins 12 réservations par heure en période de forte
ac tivité
Afin de réduire le temps d’attente des clients

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

«réduire le temps d’attente »  préc iser les attentes Métier

ou «minimiser les abandons tél. »? Ici :minimiser les abandons

107
 RÉCRITURE – FIN (4)

◾Nouvelle proposition pour c ette US:

En tant qu’agent de voyage,

je peux saisir au moins 12 réservations par
heure pendant le pic d’appels de la journée
(hors vac anc es)
Afin de réduire les abandons téléphoniques
dus à une attente trop longue

108
 GRANULARITÉ DU BESOIN

◾Vocabulaire SCRUM

◾ «Thème »:domaine Produit, grosse Feature

◾«Feature »:grosse fonc tionnalité Produit
◾ «Epic »:grosse story
◾«User Story »:besoin élémentaire d’un Utilisateur
◾«Task »:tâc he (technique) pour faire la US

109
(c) V. Deslandres, IUTLyon
THÈME / EPIC

110
THÈME / EPIC

111
 ARETENIR
◾Les features (fonc tionnalités) sont déc liné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…(ac tion) afin de
…(but)

RAPPELEZ-VOUS
◾Une user story doit être implémentée sur une seule itération
◾Un sprint doit c omporter au moins 4 US
◾J’applique les principes KISSpour écrire les US
◾La méthode de Réécriture permet de valider
mes US
 GRANULARITÉ DU BESOIN

◾Vocabulaire SCRUM

◾ «Thème »:domaine Produit, grosse Feature

◾«Feature »:grosse fonc tionnalité Produit
◾ «Epic »:grosse story
◾«User Story »:besoin élémentaire d’un Utilisateur
◾«Task »:tâc he (technique) pour faire la US

113
(c) V. Deslandres, IUTLyon
 WORKFLOW DU SPRINT

114
(c) V. Deslandres, IUTLyon
 ATELIER 1

◾Objectifs

1. Création d’un projet sous Jira:

https://www.atlassian.com/fr/try

2. Familiarisation avec le Software Jira

3. Création et planification des Sprints
4. Création d’Epics, Stories et Tâches
5. Assignation des rôles
4. Manipulation et personnalisation d’un Workflow

115
 BURN DOWN CHART

◾Artefact de Sprint
◾Chaque Sprint a son graphe individuel
◾Un graphique Burn-dow a deux zones:
◾Axe X: le nombre de jour pour le sprint
◾Axe Y: La quantité de travail/
◾La valeur du graphe est le le temps restant pour
effectuer le travail (heures, jours,…)

116
BURN DOWN CHART

117
BURN DOWN CHART

118
BURN DOWN CHART (JOUR 3)

119
BURN DOWN CHART (JOUR 6)

120
BURN DOWN CHART (DERNIER JOUR)

121
 BURN DOWN CHART
(CAPACITY BURN-DOWN LINE)

◾L’équipe a engagé un total de 110 heurs de travail pour un

sprint de 10 jours.
◾Supposons que l’équipe avait une capacité de 130 heures  13
heures par jour

122
 BURN DOWN CHART
(CAPACITY BURN-DOWN LINE)

123
 LIRE UN BURN DOWN CHART

1. Si la ligne réel se termine n’importe où au-dessus

de la ligne idéale
 Risque de ne pas terminer toutes les histoires durant la durée du Sprint.

Plus la distance est grande, plus le risque est grand ( les heures restants sont plus
que ce qui est censé être).

124
 LIRE UN BURN DOWN CHART

1. L’équipe a sous-estimé les tâches.

2. L’équipe ne met pas à jour correctement les heures restantes.
3. L’équipe reçoit de nouvelles histoires après la date de début du
sprint.
4. L’équipe réessimons les heures de
5. tâches, en augmentant les heures restantes

 Vérifier combien de jours dans le sprint il reste pour récupérer

le retard

125
BURN DOWN CHART
RISK

126
BURN DOWN CHART
RISK

127
BURN DOWN CHART
RISK

128
 BURN DOWN CHART
RISK AVEC LA LIGNE DE CAPACITÉ

129
 BURN DOWN CHART
RISK AVEC LA LIGNE DE CAPACITÉ

130
 LIRE UN BURN DOWN CHART

2. Si la ligne est toujours sous la ligne idéale

Bon signe
Mais s’il est trop bas => Sur estimation  L’équipe peut travailler
sur plus de travail durant le Sprint

131
 SCÉNARIOS

Scénario 1: Ajout d’une User Story Prioritaire au cours du Sprint

Cas Possibles:

- Ajouter la tâche Si la ligne réelle est au dessous de la ligne idéale

- Ajouter la tâche à condition d’enlever une tâche et la remettre dans le

Product Backlog.

- Ajouter la tâche Même si la ligne réelle est au dessus de la ligne idéale (

Réestimer les US restantes)

- L’équipe exprime qu’il sera risqué d’ajouter une US à la fin du Sprint

132
 SCÉNARIOS

Scénario 2: L’une des ressources doit partir en congé de maladie pour urgence
médicale pendant quelques jours.

- Vérifiez le graphique d’épuisement et analysez la position du point d’extrémité

de ligne réel. s’il se termine longtemps sous la ligne idéale, vous pouvez
accueillir les vacances imprévues.

- Vérifiez également au niveau individuel le nombre total d’heures de travail en

attente de la ressource et le nombre total de jours restants pour le sprint.

133
 SCÉNARIOS

- Vérifiez que tout autre membre d’une même compétence dispose de

suffisamment de bande passante pour combler l’écart.

- Si l’équipe estime qu’il y a une chance potentielle de ne pas terminer toutes

les histoires engagées  l’équipe doit immédiatement en informer PO, et
parvenir à une conclusion comme, identifier une histoire moins prioritaire
pour commencer la dernière chose du sprint, etc.

134
 SCÉNARIOS

Scénario 3: Au cours de la 2ème semaine du sprint, l’équipe de test a soulevé

trop de bugs, qui doivent être résolus dans la durée du sprint.

- Si le testeur soulève trop de bugs lors du test des user stories, ce qui n’est pas
un bon signe de développement mature
- Vérifiez votre différence réelle de ligne et de ligne de capacité.

À quel point l’équipe est à l’aise pour corriger les bugs, ainsi que le travail de
développement engagé en attente?

135
 SCÉNARIOS

- Vérifiez votre définition de done (DOD) à propos de la fermeture des défauts

- S’il est dit que tous les bogues P1 et P2 doivent être fermés pour faire une
histoire. Vérifiez le nombre de bogues P1 / P2, le temps supplémentaire
pour les corriger et la bande passante disponible dans votre burn-down.

- Envisagez de parler avec votre bon de commande, pour agir dans le pire des
cas et identifier l’histoire la moins prioritaire et les histoires les plus critiques.

136
 ATELIER 2

Réalisation du Burn Down Chart

137
 VELOCITÉ AGILE

- la quantité de travail qu’une équipe peut gérer dans une période de temps
définie (sprint).

- La vitesse à laquelle une équipe de développement Agile apporte de la valeur à

une entreprise.

la vélocité Scrum vous aidera à déterminer à quelle vitesse une équipe Scrum
peut effectuer le travail qui lui est assigné.

138
 VELOCITÉ AGILE

A. Estimer le temps de développement

- Les gestionnaires peuvent utiliser la vitesse de sprint pour prédire quand
l’équipe Agile sera en mesure d’expédier le produit final.

- Par exemple, si vous savez combien de travail une équipe peut terminer
pendant chaque sprint, vous saurez combien de sprints l’ensemble du
projet prendra.

Travail terminé par Sprint  Nombre de Sprint du projet

139
 VELOCITÉ AGILE

B. Identifier le potentiel de l’équipe

- L’équipe Agile est devenue plus efficace au cours du cycle de
développement?

- La vitesse de l’équipe augmente constamment après chaque sprint ? 

L’équipe apprend rapidement.

- L’augmentation de la vitesse indique également qu’ils sont prêts à gérer des

tâches plus complexes.

- Déterminer l’agilité de l’équipe lors de ses réunions de planification des

versions.
140
 GRAPHIQUE DE VÉLOCITÉ

Un graphique de vitesse/Vélocité est une représentation visuelle de l’avancement

de votre projet qui met en évidence :

- L’état d’avancement général d’un projet

- Combien de travail votre équipe Agile peut gérer dans les

futurs sprints

141
GRAPHIQUE DE VÉLOCITÉ

142
 GRAPHIQUE DE VÉLOCITÉ

Points d’histoire (Story Point)

C’est une mesure de l’effort dont vous aurez besoin pour mener à bien vos tâches
de projet (chaque user story).

Comment calculez-vous un story point?

1. Base de référence: Le temps nécessaire pour terminer la user story la plus

simple est pris comme base de référence et se voit attribuer 1 point.

2. US: les autres récits utilisateur se voient attribuer des points de récit
proportionnels à la ligne de base.

143
 GRAPHIQUE DE VÉLOCITÉ

Exemple:

- Une fonctionnalité qui prend 2 heures à développer se voit attribuer 1 point

d’histoire

- Une fonctionnalité qui prend 4 heures à compléter se voit attribuer 2 points

d’histoire.

……

144
 GRAPHIQUE DE VÉLOCITÉ

Estimation (barre grise)

Total des points d’histoire que l’équipe est censée compléter en un sprint.

Une fois le sprint démarré, les nouvelles user stories ou modifications ne

sont pas incluses dans ce total.

Terminé (barre verte)

Total des points d’histoire que l’équipe a réellement complétés en un sprint.

Les ajouts d’étendue après le début du sprint ne sont pas inclus dans ce
total.
145
 CALCUL DE LA VÉLOCITÉ

Comment ?

La vitesse du projet = la moyenne du total des points d’histoire terminés (barres

vertes) au cours des cinq derniers sprints.

Calculons la vitesse de l’équipe dans

le graphique précédent:

La vitesse de l’équipe est :

(82 + 85 + 100+ 80 + 90) / 5

87,4

146
 GRAPHIQUE DE VÉLOCITÉ

Résultat:

Le propriétaire du produit peut s’attendre à ce que son équipe complète au

moins 87,40 points d’histoire d’une valeur de travail lors du prochain
sprint.

Remarque:

La vitesse de sprint devient plus précise avec le temps.

147
 COMMENT UTILISER LA MÉTRIQUE DE VÉLOCITÉ
DANS DES PROJETS FUTURS ?

1. Consultez le rapport de vélocité d’un projet similaire pour

déterminer la vitesse moyenne de votre équipe Agile

2. Déterminez le nombre de user stories sur lesquels votre équipe

travaillera dans un projet particulier

3. Additionnez le story point pour chaque user story à terminer dans

ce projet

4. Divisez le nombre total de points d’histoire avec la vitesse de

votre équipe
148
 COMMENT UTILISER LA MÉTRIQUE DE VÉLOCITÉ
DANS DES PROJETS FUTURS ?

Scénario:

Supposons que votre équipe Agile ou Scrum doit travailler sur 3 user
stories dans un projet : A, B et C.

1. A et B valent 400 points d’histoire chacun, et C vaut 70 points

d’histoire.

 Votre équipe doit travailler sur (400 + 400 + 70) = 870 points
d’histoire en une seule itération.

149
 COMMENT UTILISER LA MÉTRIQUE DE VÉLOCITÉ
DANS DES PROJETS FUTURS ?

Vélocité de l’équipe : 87,40 points d’histoire (Graphe Précédent)

En divisant les deux métriques Agile, nous obtenons:

(870 / 87.40) ≈ 10

Résultats:

Il faudrait environ 10 sprints pour que l’équipe efface le backlog

produit.
150
 AVANTAGES DU GRAPHE DE VÉLOCITÉ

1. Meilleures prédictions sur la capacité de votre équipe

2. Souligne les problèmes avant qu’ils ne deviennent des

problèmes:

- Mauvaise communication d’équipe

- Faible productivité
- Bugs logiciels excessifs

151
 LIMLITES DU GRAPHE DE VÉLOCITÉ

1. Ce n’est pas une unité de mesure précise

La vélocité peut fluctuer pour plusieurs raison:

• Nouveaux membres rejoignant l’équipe

• Nouveaux processus introduits
• Changements dans la portée du projet

152
 LIMLITES DU GRAPHE DE VÉLOCITÉ

2. Impossible de comparer la vitesse de plusieurs équipes

 Il n’y a pas d’unités standard pour la vitesse.

1. La vitesse n’est pas toujours estimée avec une mesure de

point d’histoire standard. Vous pouvez utiliser diverses
mesures Agile telles que le travail terminé ou les heures en tant
qu’unité.

2. la vitesse est souvent subjective (chaque équipe travaille avec

une mesure)

153
 ATELIER 3

Objectifs:

• Définir des Stroy Points ( Points d’histoire)

• Réaliser un graphe de vitesse (Velocity Chart)

154