Atelier : Méthode Agile- Scrum

Intervenant: Amel Benabbou

2020/2021
 22/12/2022

Introduction #2

Modèles de cycles de vie

• Les cycles de vie linéaires
– Le modèle en tunnel
– Le modèle en cascade
– Le modèle en V
• Limites des cycles de vie linéaires
• Cycles de vie itératifs
 22/12/2022

#3

Le modèle en tunnel

t0 ?
 22/12/2022

Le modèle en cascade
#4

Analyse

Conception

Codage

Maintenance
 22/12/2022

Caractéristiques #5

Cycle de vie en cascade

• Linéaire, flot descendant

• Retour limité à une phase en amont
• Enchaînement depuis le cahier des charges
jusqu’à la réalisation
• Bien adapté lorsque les besoins sont
clairement identifiés et stables
 22/12/2022

#6
Risque du modèle en cascade

• Identification tardive des problèmes

• Preuve tardive de bon fonctionnement

Besoins Analyse Conception Codage Intégration

 22/12/2022

#7
Le modèle en V

7
 22/12/2022

#8
Que faire si les spécifications initiales sont dépassées ?
Si le besoin du client vient à changer, ou a été mal exprimé ?

Le cycle en V supporte donc mal les changements,

 Moins de réactivité par rapport au contexte technologique et

économique, aux demandes du client

L’effet tunnel :

- Le temps qui sépare l’expression du besoin de la recette du produit

final.
- Production de la documentation en début de projet, qui n’est plus
rectifiable par la suite
 22/12/2022

#9

Amélioration du cycle de vie

• Construction du système par incréments

• Chaque itération a pour but de maîtriser une partie des risques
et apporte une preuve de faisabilité ou d’adéquation
• Enrichissement d’une série de prototypes
• Les versions livrées correspondent à une étape de la chaîne
des prototypes
 22/12/2022

#10
Cycle de vie itératif et incrémental

• Itératif : le processus de développement est

appliqué plusieurs fois
• Incrémental : chaque itération augmente la
quantité d’information
• Une amélioration du modèle en cascade
 22/12/2022

#11
Une mini-cascade

11
 22/12/2022

#12
Détermination des prototypes
• Un prototype donné est construit avec des buts
précis et clairement exprimés
• L’évaluation du prototype est effectuée par
rapports à ces buts
• L’enchaînement des prototypes est décrit dans le plan
des prototypes
• Les priorités et l’ordonnancement des prototypes
peuvent changer avec le déroulement du plan
 22/12/2022

#13
Synchronisation des deux vues

• Itérations
– Chaque cycle donne une génération
– Chaque cycle est décomposé en phases
– Chaque phase comprend des itérations
• Incréments
– Le logiciel évolue par incrément
– Une itération correspond à un incrément
– Les itérations peuvent évoluer en parallèle
 22/12/2022

Le manifeste Agile #14

 22/12/2022

#15
Les méthodes Agile
 22/12/2022

Les 12 principes d’Agile #16

 22/12/2022

Comparaison #17
22/12/2022

#18
 22/12/2022

Les différentes méthodes Agiles #19

 22/12/2022

#20
La méthode Scrum
 22/12/2022

#21

La méthode Scrum
 22/12/2022

Principe #22

o Suivie coté client par Product Owner.

o Fonctionnalités souhaitées collectées dans un backlog de
produit,

o S’appuie sur le découpage des projets en itérations nommées

Sprints
o Un sprint peut avoir une durée qui varie généralement entre
deux semaines et un mois,
o Au cours de chaque sprint: effectuer des mêlées quotidiennes
o A la fin du sprint, l’équipe obtient un produit partiel
potentiellement livrable,
o Après plusieurs sprint: parler de version (release)
 22/12/2022

#23
Les caractéristiques
o Transparence: l’état du développement est visible par tous,

o Inspection: l’avancement du développement doit être inspecté

régulièrement (tableau de contrôle et mêlées),

o Adaptation: Ajustement des processus en fonction de l’inspection

o Planification et la revue de sprint : comparer la progression avec
l’objectif,

o Rétrospective: quelles améliorations prévoir dans les prochains

sprints
 22/12/2022

#24

Les caractéristiques
• Une approche empirique
L’inspection quotidienne qui oriente les décisions.

• Une méthode itérative 

Découper le projet en plusieurs cycles identiques ou itérations.
 
•Un développement incrémental
La partie du projet réalisée doit être utilisable.

•Une pratique agile

Le client est impliqué dans la gestion de projet.
22/12/2022

#25
 22/12/2022

#26
Sprints et Release
 22/12/2022

#27
Composants de Scrum
 22/12/2022

#28
Composants de Scrum
 22/12/2022

Le product Owner #29

Rôle : Aspects métier et rôle du projet

•L'expression des besoins avec l’équipe
•La priorisation des besoins pour l'équipe
•La validation des résultats de l'équipe
22/12/2022

#30
 22/12/2022

#31

Le Scrum Master
Rôle : Remplacer le chef de projet classique
Guider l’auto gestion de l’équipe
 22/12/2022

L’équipe #32

Le groupe des personnes qui vont travailler ensemble pendant les sprints pour développer un
produit de valeur. 

Caractéristiques:

• Les équipes doivent être auto-organisées : il n’y a pas de figure de chef d’équipe ou de
responsable.
Les équipes doivent être inter-fonctionnelles. l’équipe doit disposer de toutes les
connaissances et compétences nécessaires au développement du produit.

• Une équipe Scrum n’a pas plus de 9 membres. Toutes les compétences requises pour
livrer un produit ou un service doivent être obtenues par ces 9 personnes maximum.
Le groupe doit être suffisamment petit pour faciliter la communication

• Ses membres ont de multiples compétences.

• Ses membres sont pluridisciplinaires.
 22/12/2022

User story #33

L'expression des besoins se fait sous forme de user stories.

Une phrase simple et compréhensible pour décrire une fonctionnalité du produit .
Par exemple :
En tant que <utilisateur>, je veux <une fonctionnalité> afin de <répondre à mon besoin>
 22/12/2022

#34
Backlog de Produit
La liste de l'ensemble des stories constitue le product backlog
(carnet de produit ).
- Un document qui peut évoluer constamment au cours du projet.
(Contrairement au cahier des charges).

Le product backlog est une liste ordonnée de tout ce

qui pourrait être requis dans le produit et est l’unique
source des besoins pour tous les changements à
effectuer sur le produit.
 22/12/2022

#35
Backlog de Produit

• Le product owner est l'unique responsable de

l'actualisation du product backlog.
• Le product owner priorise les user stories formulées dans le
product backlog.
• Le product owner prend des décisions structurantes à partir
du product backlog.
• Le product owner surveille le budget et le planning grâce au
product backlog.
• Le product owner participe à la transparence du projet avec
le product backlog. 
 22/12/2022

#36
Le sprint dans le modèle Scrum

L'itération ou sprint est une boîte de temps d'une à quatre

semaines (maximum).
• C'est la période au cours de laquelle une fonctionnalité
complète du produit sera développée et incrémentée.

•La durée des sprints est la même pendant toute la durée du

projet.
•Le nombre de sprints dépend de la capacité de l’équipe à
couvrir les besoins.
•Un nouveau sprint commence dès que le précédent est terminé.
 22/12/2022

#37
Préparer un Sprint

5 règles à respecter pendant les sprints :

1. Ne peut pas modifier l'objet du sprint.

2. L’équipe doit rester constante et régulière.
3. Ne négociez jamais à la baisse la qualité du travail.
4. Aidez l'équipe de développement à renégocier le nombre de
tâches avec le product owner.
5. Limitez en amont la complexité des solutions et donc les
risques de dérives liés au sprint.
 22/12/2022

#38

La vélocité de l’équipe à partir des story points et

la date de fin du projet

• La vélocité est définie comme le nombre de points d'efforts

finalisés lors d'un ou sprint terminé.

• Elle détermine et évalue l'effort qu'une équipe de

développement peut fournir pour réaliser des tâches planifiées
dans un sprint.

= la somme totale du nombre de points d’efforts en fin de sprint

réalisé par les Product Backlog
 22/12/2022

#39
Exemple 1
Exemple : 22/12/2022

#40
- Une équipe prévoit de développer 3 user stories estimées à 4 points
chacune au cours de la première itération (une semaine).

- À la fin du sprint, 2 user stories sont terminées et la troisième est

incomplète.
 La vélocité de l'itération est donc de 8 points.

- Si le total des estimations du projet est égal à 56 points, alors il faut

planifier 7 semaines de travail.

- Encourager l’équipe à choisir un lot d'user stories équivalent à plus ou

moins 8 points lors du sprint suivant.

- Recalculer la vélocité chaque semaine afin de mesurer rigoureusement

la progression de l'équipe. 
 22/12/2022

Le sprint 0 #41

- Un sprint d'échauffement afin de calculer la vélocité de l'équipe.

- Penser à satisfaire des prérequis avant de démarrer le

développement:

• Constitution de l’équipe Scrum

• Choix des solutions les plus structurantes
• Installation des outils collaboratifs
• Mise en place de l’environnement de travail

Le scrum master aide le product owner à prioriser le product backlog,

anticiper les tâches opérationnelles avec l'équipe ... Le "sprint 0" est
quasiment obligatoire !
22/12/2022

#42
22/12/2022

#43
 22/12/2022

#44
Le sprint backlog dans le modèle Scrum

• Un extrait du product backlog correspond à tout le périmètre qui doit

être produit au cours du prochain sprint.

• Représenté sous la forme d'un tableau kanban (ou scrum board) pour
rendre visible toute la gestion de l'itération.

• Afficher au mur les user Stories du sprint, ainsi que les tâches décrivant les
actions définies par l'équipe de développement.

• Le Sprint Backlog est une vue en temps-réel, très visible du

travail que l’équipe planifie d’accomplir durant le Sprint.
 22/12/2022

#45
L'incrément dans le modèle Scrum

• L'incrément correspond au résultat opérationnel du sprint Une version

intermédiaire du produit final.

• L’incrément du sprint est réalisé sur la base des user stories terminées.

L’incrément du sprint intègre les incréments réalisés lors des sprints
précédents.
• L’incrément du sprint peut être livré ou mis en attente pour intégrer une
version.
L’incrément du sprint est opérationnel (ce n’est pas une maquette ou une
preuve de concept).
 22/12/2022

#46
La daily scrum 

• Réunion quotidienne a pour objectif de partager l’état

d'avancement du sprint et signaler les obstacles
rencontrés
 22/12/2022

Cycle de vie de Scrum #47

 22/12/2022

Pratiques agiles complémentaires #48

 
1.Le planning poker
estimer la complexité de chaque user story avec le product owner.
utiliser un jeu de cartes représentant différentes valeurs pour l'estimation en points des user
stories. Découvrez simultanément les cartes des participants et lancez un débat à partir des
valeurs les plus extrêmes. Si nécessaire, répéter le jeu jusqu'à obtenir un consensus.
 
2.Le tableau kanban
représenter chaque user story sur des affichettes sur un tableau divisé en 3 colonnes : "à
faire", "en cours" et "terminé". Actualisez ce tableau lors des réunions quotidiennes afin de
visualiser la progression de l'équipe. Remettez-le à zéro en début d'itération afin d'ajouter de
nouvelles user stories.
 
3.L'attribution des tâches
lister les tâches de chaque user story pour développer les fonctionnalités du produit.
A ne pas désigner un chef de projet chargé d'affecter ces tâches aux membres de l'équipe.
Répartissez plutôt les user stories sur la base de la discussion lors des réunions quotidiennes.
 
 22/12/2022

#49

Exemple
 22/12/2022

#50

Les User Stories 

Doit seulement contenir 3 éléments descriptifs :

Qui ❔ Quoi ❔ Pourquoi ❔

1.Le contexte → en tant que <utilisateur>.

2.La fonction → je veux <fonctionnalité>.
3.Le bénéfice → afin de (pour) <raison>.
 22/12/2022

#51

La grille des critères INVEST 

• permet de juger de la qualité d'une User Story

• elle conduira éventuellement à reformuler son énoncé, voire à

modifier en profondeur la Story
 22/12/2022

#52

Une bonne User Story est :

• Indépendante des autres
• Négociable initialement, plutôt qu'un engagement ferme
• Valuable, un besoin est y toujours associé
• Estimable en termes de complexité relative
• Suffisamment petite (en anglais Small)
• Testable en principe, ce qu'on vérifie en écrivant un test
 22/12/2022

#53

• Indépendante des autres

Exemple:

La Story sur la prise de commande implique d'avoir ouvert un compte 

réaliser en premier la story « identification ».

 22/12/2022

#54

Négociable

La User Story peut être arbitrée par le client et l'équipe

Une story Peut être modifiée, ou ajustée
 ne formuler dans un premier temps que l'essentiel (l'objectif fonctionnel)

Éviter de spécifier dans une User Story des éléments techniques

Exemple: "En tant qu'acheteur, lorsque j'écris dans le champ texte puis que je
clique sur le bouton Recherche, la liste à gauche du champ de recherche est
renseignée avec les articles correspondants". 
 22/12/2022

#55
Valuable
Un besoin est toujours associé à la User Story

représenter un incrément réellement utile pour l'utilisateur final

Exemple,
"réaliser le schéma de la base de données pour la facturation" n'est pas un
incrément ayant de la valeur en soi, mais une tâche technique.

La story "émettre une facture pour les achats d'articles en France"

Puis la Story "émettre une facture pour des achats livrés depuis l'étranger« 

Un bon découpage: chaque incrément permet de réaliser une partie distincte du

chiffre d'affaires.
 22/12/2022

#56

Estimable

donner une estimation de l’effort requis pour réaliser une user story.

Cela permet entre autres de définir correctement la priorité de la user story et

de vérifier qu’elle peut être terminée au cours du sprint. 

exemple
"Optimiser le calendrier de livraison des achats".

Les conditions de satisfaction doivent être suffisamment précises et restreintes

pour que l'équipe de développement puisse quantifier l'effort d'implémentation,
 22/12/2022

#57

Small

Plus l’Epic est découpée, plus les User Stories seront “petites” et plus elles
seront simples à développer, tester et déployer à découper en plusieurs
variantes une User Story trop large.
exemple :
•« En tant que joueur, je veux visualiser le plan du jeu d'évasion afin de
m'orienter » :
• « En tant que joueur, je veux visualiser ma position dans le jeu (...) » ;
• « En tant que joueur, je veux visualiser un itinéraire dans le jeu (...) ».

Un bon découpage aura une influence réelle sur le déroulé du projet.

 22/12/2022

#58

Testable
Des critères de tests doivent être mis en place pour chaque user story,

afin de permettre à l’équipe d’évaluer la conformité du développement réalisé.

Il s’agit de l’incontournable « definition of done » ou critères d’acceptation, qui

permettent à toutes les parties prenantes de valider une livraison et de clôturer la
user story dans le Product Backlog.
 22/12/2022

#59
 Objectif : de produire de la valeur en priorité! 

Analysez chaque tâche du

product backlog en
fonction de cette valeur

Sinon revoir la grille INVEST

 22/12/2022

#60
Méthode de MoSCoW

priorisier les besoins ou les exigences du Product Backlog.

Objectif : accorder l'importance à certaines fonctionnalités à

réaliser

4 niveaux de cette échelle :

1. “Must have”, les fonctionnalités indispensables.
2. “Should have”, les fonctionnalités importantes.
3. “Could have”, les fonctionnalités de confort.
4. “Want to have but Won’t have”, les fonctionnalités
souhaitables, mais reportées.
 22/12/2022

#61

MoSCoW est subjective!!!

Un nombre conséquent de "Should" et de "Could" procure plus de

flexibilité dans le projet.

Une majorité de Must présente un risque : tout devient prioritaire, avec 

des problèmes budgétaires et de charges à venir .
 22/12/2022

#62
Estimation de la complexité