Introduction à

SCRUM
Réalisé par Amira Zarga
 Plan de la présentation

1 2 3

La gestion de Les methodes Scrum

projet de gestion de
projet
• Qu’est ce que scrum?
• Avantages
• Pilliés
• Le cadre scrum
• Processus logiciel scrum
• Acteurs: l’equipe
• Les objets de scrum
• Les indicateurs
• Les activité propres à scrum
Qu'est-ce qu'un projet ?
• Un projet est une entreprise temporaire qui a
pour objectif de créer quelque chose d'innovant.

• Dans un contexte professionnel, il s'agit de la

réalisation d'un nouveau produit ou d’un
nouveau service.
Qu'est-ce qu'un projet ? -suite
• En principe un projet n'est pas une simple idée jetée en l'air, mais suppose
d'être décrit et planifié, par exemple selon la méthode QQCOQCCP :

• Quoi (les actions)

• Qui (les gens concernés)
• Où (les domaines touchés par le projet, voire les lieux)
• Quand (programmation dans le temps, plannig)
• Comment (moyens, méthodes...)
• Combien (le budget)
• Pourquoi (les motifs et les objectifs)
Qu'est-ce qu'un projet ? -suite

• On appelle projet un ensemble finalisé d’activités et

d’actions entreprises dans le but de répondre à un

besoin défini dans des délais fixés et dans la limite de

l’enveloppe budgétaire allouée.

Un projet remplit les conditions suivantes
• Il génère un résultat unique (produit ou service).
• Il est limité dans le temps: les dates de début de fin sont définies.
• Il est développé pas à pas (du concept global au concept détaillé).
• Il possède un mandant (commanditaire) qui fixe les objectifs du projet
en fonction des exigences des parties prenantes.
• Il est géré par un chef de projet.
• Il suit un processus de management de projet,
 qu'est-ce qu'un projet/livrable ?

• le résultat tangible d'une production réelle, compréhensible, mesurable attendue

par le client final.

• Un projet peut, bien sûr, avoir plusieurs livrables.

 Exemple de livrables
 Destinés aux clients finaux Propres au processus de gestion de
projet
•  Application logicielle •  Plan projet
• Produit physique : construction, • Étude de faisabilité
machine, procédé... • Étude de risques
• Maquette fonctionnelle • Plan de communication
• PV de recette • Plan d'assurance qualité
• Rapports d'audit • Appel d'offres
• Rapports d'étude • Note de cadrage
• Documentation et modes d'emploi • Compte rendu
• Plan de formation • Support de présentation
La gestion de projet
définition 

• La gestion de projet ou conduite de projet est une démarche visant à

structurer, assurer et optimiser le bon déroulement d’un projet.
 La triple contrainte de la gestion de projet

1. Les projets doivent être

livrés dans les temps.
2. Les projets doivent respecter les
coûts.
3. Les projets doivent délivrer le
contenu prévu.
4. Les projets doivent respecter les
besoins de qualité requis par les
clients
Les étapes de la gestion de projet
Outils, Méthodes, techniques de Gestion de
Projet.
Plusieurs frameworks et méthodologies de gestion du projet ont été introduits
au fil des ans pour assurer une gestion et une collaboration efficaces des équipes
sur le lieu de travail.
Les méthodes traditionnelles
• C’est sont les méthodes les plus utilisées en gestion de
projet.
• Elle sont aussi appelées « en cascade » car chaque étape doit
être terminée pour passer à la suivante.
• En appliquant cette méthodologie, l'équipe projet suit le
cahier des charges à la lettre et travaille sur la totalité du
projet jusqu'à sa livraison. 
• Il n'y a pas d'interaction avec le client qui recevra son projet
une fois que celui-ci est terminé.
Les méthodes traditionnelles -suite
• Tout doit être prévu:
• L'équipe s'engage sur un planning précis
• et définit l'ensemble des tâches à réaliser.
• Il n'y a pas de place pour les changements et les imprévus

-> Au final, le client est souvent déçu car ses attentes ont évolué ou le
contexte a changé. Des imprévus sont survenus, et des ajustements
doivent être effectués, ce qui implique des retards et des coûts
supplémentaires.
Le Framework Waterfall

• Ce framework a été emprunté pour le développement de logiciels aux industries du

construction et du fabrication strictement structurées.

• Il offre une gestion linéaire et directe avec un grand respect pour la planification, la

documentation et les accords antérieurs.

• C’est aussi la raison pour laquelle des anciennes entreprises comptent encore sur elle.
Le Framework Waterfall
• Waterfall est simple,
• directe et prévisible.
• manque de souplesse et de tolérance pour les changements.
• L’idée principale est de planifier l’ensemble du projet dés le
début, puis de suivre les étapes prévues jusqu’à la livraison du
produit.
• Cela signifie que l’équipe parcourt chaque étape de manière
linéaire et ne peut ni avancer sans terminer la tâche
précédente, ni reculer,
La méthodologie agile
• La méthodologie Agile est une pratique qui aide à itérer en
permanence le développement et les tests.
• Agile divise le produit en versions plus petites.
• Les activités de développement et de test sont concurrentes,
contrairement aux autres méthodologies de développement de
logiciels.
• Il encourage également le travail d’équipe et la communication en face
à face.
• Les entreprises, les parties prenantes, les développeurs et les clients
doivent travailler ensemble pour développer un produit.
Avantages du modèle Agile:
• Il s'agit d'un processus client ciblé. Il garantit ainsi une implication
continue de l'utilisateur à chaque phase.
• Les équipes agiles sont très motivées et auto-organisées, elles produiront
probablement de meilleurs résultats dans les projets de développement.
• La méthode de développement logiciel Agile garantit la qualité du
développement.
• Le processus est entièrement basé sur des connaissances avancées. C'est
pourquoi l'utilisateur et l'équipe savent exactement ce qui a été réalisé et
ce qui ne l'a pas été. Cela réduit les risques dans le processus de
développement.
Limites du modèle agile
• Ce n'est pas une méthode utile pour les petits projets de
développement.
• Un expert doit prendre des décisions importantes lors de la réunion.
• Les coûts de mise en œuvre d’une méthode Agile ne sont pas
inférieurs à ceux des autres méthodologies de développement.
• Le projet peut facilement dérailler si le propriétaire du produit ne sait
pas quel résultat il souhaite.
Conclusion
• Waterfall fonctionne mieux pour les projets réalisés de manière
linéaire et ne permet pas de revenir à une phase antérieure. Agile se
concentre sur des flux de travail adaptatifs et simultanés. Les
méthodes agiles divisent les projets en périodes plus courtes et
itératives, tandis que Scrum s’efforce de faire plus de travail plus
rapidement.
Le manifeste agile -Valeurs
• Les individus et leurs interactions plus que les processus et
les outils
• Des logiciels opérationnels plus qu’une documentation
exhaustive
• La collaboration avec les clients plus que la négociation
contractuelle
• L’adaptation au changement plus que le suivi d’un plan

claude.godart@loria.fr
30
Polytech Nancy
Le manifeste agile -Principes
• Satisfaction des clients
• Accepter le changement du besoin
• Livraison fréquentes
• Implication du client
• Motivation des équipes
• Le dialogue face à face
• Opérationnel sinon rien
• Rythme soutenable
• Excellence technique
• La simplicité
• Equipes auto-organisées
• Amélioration continue
claude.godart@loria.fr
31
Polytech Nancy
Scrum
• Qu’est ce que scrum?
• Avantages
• Piliés
• Le cadre scrum
• Processus logiciel scrum
• Acteurs: l’equipe
• Les objets de scrum
• Les indicateurs
• Les activité propres à scrum
•Scrum est un processus agile qui permet de
Scrum en
produire la 100
plus grande valeur métier dans
lamots
durée la plus courte.
•Du logiciel qui fonctionne est produit à
chaque sprint (toutes les 2 à 4 semaines).
•Le métier définit les priorités. L'équipe
s'organise elle-même pour déterminer la
meilleure façon de produire les exigences
les plus prioritaires.
•A chaque fin de sprint, tout le monde peut
voir fonctionner le produit courant et
décider soit de le livrer dans l'état, soit
de continuer à l'améliorer pendant un sprint
Utilisations de Scrum
• Logiciel commercial
• Développement interne
• Développement contractuel
• Projets au forfait
• Applications financières
• Applications certifiées ISO
9001
• Systèmes embarqués
• SI avec exigences de fiabilité
24x7 99.999%
• le Joint Strike Fighter(DoD)
• Développement de jeux
vidéo
• Systèmes critiques type
FDA
• Logiciel de contrôle de
satellite
• Sites Web
• Logiciels pour PDA
• Téléphonie mobile
• Infrastructure de
réseaux
• Applications ISV
• Quelques-unes des plus
grandes applications en
utilisation
Utilisateurs de Scrum
•Microsoft •Intuit
•Yahoo •Nielsen Media
•Google •First American Real Estate
•Electronic Arts
•BMC Software
•High Moon Studios
•Ipswitch
•Lockheed Martin
•John Deere
•Philips •Lexis Nexis
•Siemens •Sabre
•Nokia •Salesforce.com
•Capital One •Time Warner
•BBC •Turner Broadcasting
•Oce
Les avantages de scrum
• Une gestion intelligente du travail qui engendre plus d’efficacité et de
productivité
• Une meilleure visibilité et communication des équipes sur les sujets en
cours
• La valorisation et autonomie de chaque membre du groupe 
• Une cohésion d’équipe, une réflexion constante pour dépasser les difficultés
• Une meilleure performance, 
• La vélocité: C’est l’idée de dire que l’équipe est capable de faire une certaine
quantité de travail en un temps donné, plus que de prédire une date finale
de livraison.
LES TROIS PILIERS DE SCRUM

Scrum est un processus empirique: il se base sur

l’expérience du terrain. Il s’appuie sur trois piliers: 
• La transparence
• L’inspection
• L’adaptation
PILIERS DE SCRUM

• La transparence, Scrum met l’accent sur le fait

d’avoir un langage commun entre l’équipe et le
management. Il doit permettre à tout observateur
d’obtenir rapidement une bonne compréhension du
projet.
PILIERS DE SCRUM

• L’inspection, fait a intervalle régulier mais

pas trop fréquemment, permet d’inspecter
les problèmes rencontrer.
PILIERS DE SCRUM

•L’adaptation, grâce à cette inspection,

on pourra alors s’adapter grâce à des
actions visant à améliorer la situation.
Le cadre Scrum
Rôles
•Product
Owner
•ScrumMaster
•Equipe Cérémoni
al
• Planification du
sprint
•Revue du sprint
•Rétrospective
•Scrum quotidien
Artefact
sBacklog de
•
produit
•Liste des tâches
•Burndowns
Processus logiciel Scrum
Client- User
Projet
Vision/Idéation Sprint 0

Manager
Release
r
ou
1j

Planification de Solidification Validation

la release d’une release d’une release
Product owner

Sprint
s
ur

ur
ur

j o

jo

1h
jo

1 0 Scrum master

4
8-
2

1:
Revue Rétrospective
1/

Planification Exécution
d’un sprint d’un sprint d’un sprint d’un sprint

2-4 semaines
Développeur
claude.godart@loria.fr
44
Polytech Nancy
Processus logiciel SCRUM (sprints et
releases)

Besoins Analyse Codification Tests

Cycle séquentiel

sprint 1 sprint 2 sprint 3 sprint 4 sprint 5

Besoin Besoins Besoins Besoins Besoins
Analyse Analyse Analyse Analyse Analyse
Codification Codification Codification Codification Codification
Tests Tests Tests Tests Tests
Cycle SCRUM

claude.godart@loria.fr
45
Polytech Nancy
Processus logiciel SCRUM

• Une phase d’idéation

• Une succession de sprints de taille fixe
• Chaque sprint produit un logiciel fonctionnel
• Chaque sprint réalise toutes les activités de développement logiciel
• Les sprints sont groupés en Releases (de taille fixe)

claude.godart@loria.fr
46
Polytech Nancy
Release SCRUM vs. Release traditionnelle
• Traditionnellement, une release (livrable) correspond à une nouvelle
version d’un logiciel
• Incrément fonctionnel (une release correspond à la réalisation d’un objectif
fonctionnel)
• Evolution technique
• SCRUM
• Une release :
• correspond à la livraison d’une feature (fonctionnalité)
• travail réalisé pendant une période de temps fixe qui comprend plusieurs sprints
• pour faire coïncider ces deux objectifs, on décompose/regroupe les features
• Mais une nouvelle version du produit (livrable) peut-être produite à la fin de
n’importe quel sprint
claude.godart@loria.fr
47
Polytech Nancy
Périodes d’une Release
• La période avant le premier sprint de développement, appelée
« sprint zéro » : planification de la release en plusieurs sprints
• La période des sprints (de développement)
• La période après le dernier sprint et avant la fin de la release

claude.godart@loria.fr
48
Polytech Nancy
Sprint
• Chaque release est décomposée en sprints au cours de l’activité de
planification de la release (la première fois « sprint zéro »)
• Un sprint est une période de développement de taille fixe (en moyenne 2 à 4
semaines)
• Durée fixe, équipe stable
• Un sprint se décompose en un ensemble de tâches
• Mêlée journalière : réunion d’équipe pour faire le point sur le travail réalisé
depuis le début du sprint et le travail à réaliser avant la fin du sprint
• Chaque sprint termine par :
• une revue du produit
• une rétrospective sur le processus

claude.godart@loria.fr
49
Polytech Nancy
Sprint

Backlog: carnet, liste ordonnée de « choses » à faire

(user stories, tâches)
claude.godart@loria.fr
50
Polytech Nancy
Les acteurs
Des créateurs de valeur

claude.godart@loria.fr
52
Polytech Nancy
Rôles

Manager
Client- User Expert

Product owner Scrum master Développeurs

Equipe SCRUM

claude.godart@loria.fr
53
Polytech Nancy
L’équipe
• Composition:
• 1 Product Owner
• 1 Scrum Master
• 2 à 7 développeurs
• Le product owner et le Scrum master peuvent aussi prendre le rôle de développeur
• Principes
• Auto-organisation
• Pluridisciplinarité
• Stabilité
• Valeurs communes

claude.godart@loria.fr
54
Polytech Nancy
Product owner
• Responsabilités
• Fait partager la vision globale du produit
• Gère le backlog du produit (liste ordonnée des « choses » à faire)
• Définit les priorités
• Accepte ou rejette les Releases (livrables)

claude.godart@loria.fr
55
Polytech Nancy
Scrum master
• Responsabilités
• n’est pas « le chef », mais un facilitateur
• Motive l’équipe
• Fait appliquer les bonnes pratiques de Scrum
• Gère les obstacles

claude.godart@loria.fr
56
Polytech Nancy
Processus logiciel Scrum
Client- User
Projet
Vision/Idéation Sprint 0

Manager
Release
r
ou
1j

Solidification Validation
Planification de
d’une release d’une release
la release Product owner

Sprint
s
ur

ur
ur

j o

jo

1h
jo

1 0 Scrum master

4
8-
2

1:
Revue Rétrospective
1/

Planification Exécution
d’un sprint d’un sprint d’un sprint d’un sprint

2-4 semaines
Développeur
claude.godart@loria.fr
57
Polytech Nancy
Les objets de SCRUM
Feature, Story, Tâche, Backlog

claude.godart@loria.fr
58
Polytech Nancy
Feature
• Une feature (fonctionalité) est un service ou une
fonctionnalité du produit à développer
• Elle se décompose en stories (histoires) de tailles différentes.
On distingue :
• les stories complexes (épiques) qui seront affinées en stories plus
simples
• Les stories atomiques qui ne se décomposent pas et sont réalisées
dans les sprints

claude.godart@loria.fr
59
Polytech Nancy
Feature (exemple)

un site pour propriétaires d’animaux domestiques

Des features (fonctionalités, chapites …)

https://pablopernot.fr/2017/01/cartographie-plan-action/

claude.godart@loria.fr
60
Polytech Nancy
Workflow d’une feature
opportunité prévue pour la release en affinage minimisée testée déployée

Tableau des features

claude.godart@loria.fr
61
Polytech Nancy
Workflow d’une feature
• Opportunité : idée de feature qui présente une opportunité pour le
produit
• Prévue pour la release : l’étude d’opportunité a abouti, et la feature est
prévue pour la release en cours
• En affinage : initialement sous forme d’épique, est décomposée en
stories
• Minimisée : Minimal Maketable Feature
• Testée : … avec des stories finies
• Déployée : utilisable par des utilisateurs qui peuvent fournir du feedback

claude.godart@loria.fr
62
Polytech Nancy
 Story map :
décomposition d’une feature en stories

Séquence d’usage

Feature 1 Feature 2 Feature 3

Story A Story B Story C Story G Story I Story H Story J Story K

Nécessité

Story O Story P Story D Story E Story F

Story R Story S Story Q

claude.godart@loria.fr
63
Polytech Nancy
Exemple

claude.godart@loria.fr
64
Polytech Nancy
Exemple :

claude.godart@loria.fr
65
http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html
Polytech Nancy
Story
• Une story est une exigence du système à développer, formulée en une
ou deux phrases dans le langage de l’utilisateur.
• Les Stories émergent au cours d’ateliers de travail menés avec le
Métier, le Client et/ou les Utilisateurs.
• On distingue :
• Story fonctionnelle
• Story technique
• Correction de bug
• Remboursement de la « dette technique »

claude.godart@loria.fr
66
Polytech Nancy
Story
• Les 3C
• Carte : l’histoire est courte et sa description tient sur une carte (demi-page)
• Conversation : l’histoire est définie avec les gens du métier
• Confirmation : l’histoire est confirmée par des tests d’acceptation rédigés au
même moment que celle-ci
• Workflow de la story
• Idée d’une story rédigée sur une Carte (1/2 feuille)
• Conversation dirigée par le product owner qui inclut les gens du métier
• L’équipe apporte sa Confirmation que la story est prête
• L’équipe réalise la story
• Le product owner apporte sa Confirmation que la story est finie
claude.godart@loria.fr
67
Polytech Nancy
Description type d’une story
• Plan type
• En tant que <acteur>, je veux <un but> [afin de <une justification>]
• En tant que client, je veux pourvoir accéder au site de ma banque afin de gérer mon compte sur Internet
• Priorité
• Nombre de points
• Représente le niveau de difficulté intrinsèque, en fonction de la taille et de la valeur métier
• Corrélées en moyenne, mais pas toujours (en fonction d’une forte valeur métier, de la réutilisation
possible de composants …)
• Conditions d’acceptation
• Etant donné <le contexte> quand je <événement> alors <résultat>
• Etant donné que je suis sur la page de connexion et que j’ai entré un login et un mot de passe dans le
formulaire et que le login et le mot de passe correspondent à un utilisateur enregistré, quand je clique
sur le bouton “Se connecter” alors j’arrive sur la page d’accueil du site.

claude.godart@loria.fr
68
Polytech Nancy
Post-it de story

S03, S06 Numéro des stories

Numéro de story S12 pré-requises

ti cul ie r, je veux
e par
En tant qu
an d e r u n conseil e r mon
dem e s o ig n
u n éle ve ur afin d
à
aboie
chien qui
ps
tout le tem

Importance
5
2 pour le client (/5)
Durée estimée 4H

Points/Difficulté (/5)
claude.godart@loria.fr
69
Polytech Nancy
Estimation des points d’une story

•Une note moyenne associée à un story: calculée à partir de 3 facteurs suivants

Impact •
• Confidence
• Ease
• Planning Poker (source Wikipedia)
• Les participants s'installent autour d'une table, placés de façon que tout le monde puisse se voir.
• Le responsable de produit explique à l'équipe un scénario utilisateur (user story).
• Les participants posent des questions au responsable de produit, discutent du périmètre du scénario, évoquent les conditions de satisfaction qui
permettront de le considérer comme "terminé".
• Chacun des participants évalue la complexité de ce scénario, choisit la carte qui correspond à son estimation et la dépose, face vers le bas, sur la table
devant lui.
• Au signal du facilitateur, les cartes sont retournées en même temps.
• S'il n'y a pas unanimité, la discussion reprend.
• On répète le processus d'estimation jusqu'à l'obtention de l'unanimité.
• Une procédure optimisée consiste, après la première "donne", de demander aux deux acteurs ayant produit les évaluations extrêmes d'expliquer leurs
points de vue respectifs. Ces explications achevées et comprises de tous, une nouvelle estimation est produite et c'est alors la moyenne arithmétique de
ces estimations qui est prise en compte.
claude.godart@loria.fr
70
Polytech Nancy
Tâche
• A l’exécution, une story se décompose en tâches

Sprint 2 : 21/08, 14/09

Objectif : gérer les inscriptions

Stories à faire à finir fini

Story A Tâche 4 Tâche 2 Tâche 3 Tâche 1

Story B Tâche 6 Tâche 7 Tâche 5

Story C Tâche 8 Tâche 9

Tâche 10

claude.godart@loria.fr
71
Polytech Nancy
Tableau de la Story
• Le tableau de la story décrit son état.

claude.godart@loria.fr
72
Polytech Nancy
Indicateurs
• Sprint
• Burndown de sprint (orienté reste à faire)
• Burnup de sprint (orienté ce qui a été déjà fait)
• Release
• Burndown de release
• Burnup de release
• Equipe
• Vélocité (capacité de l’équipe)
• Suivi des obstacles
• Perturbations exogènes ou endogènes qui perturbent le bon déroulement du sprint
• Peut de générer de nouvelles tâches (dette) et/ou leur réorganisation

claude.godart@loria.fr
73
Polytech Nancy
Burndown graphe

claude.godart@loria.fr
74
Polytech Nancy
Burnup graphe

claude.godart@loria.fr
75
Polytech Nancy
Vélocité
• Estime la capacité de l’équipe en nombre de points de stories par
sprint
• Utilisé pour la planification de la release
• Affinée à la fin de chaque sprint
• Tendance à la stabilité

claude.godart@loria.fr
76
Polytech Nancy
Les activités propres à SCRUM
Les mêlés et les cérémonies

claude.godart@loria.fr
77
Polytech Nancy
Idéation
• Définition d’une vision commune
• Identification des features
• Impact mapping
• Identification des parties prenantes
• Acteurs

• Création d’un backlog de haut niveau du produit

• Tableau ordonné des features
• (éventuellment Story map haut niveau)

claude.godart@loria.fr
78
Polytech Nancy
Sprint « Zéro »
• Affinage du backlog
• Story mapping (feature  stories)(partiel)
• Description des stories (description, conditions d’acceptation)
• Ordonnancement des stories
• Planification de la première release
• Approvisionnement du bac d’affinage
• Approvisionnement du bac de départ du sprint 1
• Peut durer plusieurs journées

claude.godart@loria.fr
79
Polytech Nancy
Le backlog (carnet de route)
• Liste ordonnée des choses (stories) à faire
• En pratique, plusieurs (sous-)backlogs
• On peut distinguer le backlog de produit et le backlog de sprint

stories d’une stories prêtes stories en

Idée de release en cours de stories
affectées à
story de cours d’affinage réalisation réalisées
un sprint de
story claude.godart@loria.fr de story 80
Polytechstory
Nancy
Story mapping
• Ordonnancement des features
• Décomposition en stories
• (Organisation des releases)

claude.godart@loria.fr
81
Polytech Nancy
Exemple

https://pablopernot.fr/2017/01/cartographie-plan-action/)
claude.godart@loria.fr
82
Polytech Nancy
Exemple :

claude.godart@loria.fr
83
http://winnipegagilist.blogspot.com/2012/03/how-to-create-user-story-map.html
Polytech Nancy
Planification des releases
• Affiner les risques, les incertitudes en fonction des retours de la revue
et de la rétrospective du dernier sprint
• Ajuster la vélocité de l’équipe (capacité de travail de l’équipe en
nombre de points de story)
• Affiner, (re-)planifier le(s) prochain(s) sprint(s)
• Définition de prêt et fini
• Nombre de points
• Affiner, (re-)planifier la future release

claude.godart@loria.fr
84
Polytech Nancy
Affinage du backlog

1. Approvisionner le bac de départ en stories prêtes

2. Identifier les epics à décomposer en stories simples
3. Identifier les stories du bac à sable qui peuvent entrer dans le bac d’affinage
4. Evaluer les éléments du bac d’affinage
5. Réordonner le bas d’affinage
6. Purger les bacs
claude.godart@loria.fr
85
Polytech Nancy
Planification d’un Sprint
• Confirmer les stories prêtes
• Définition de prêt et fini
• Evaluer la nombre de points d’une story
• Ponts de récit ou journée idéale (homme/jour)
• Organisation de l’essaimage (plusieurs stories en parallèle, répartition
des ressources)
• Décomposition des stories en tâches
• Affectation des tâches aux développeurs

claude.godart@loria.fr
86
Polytech Nancy
Exécution d’un sprint
• Conception, réalisation et test des stories
• Organisation, affectation des tâches
• Inclut les sprints journaliers

claude.godart@loria.fr
87
Polytech Nancy
La mêlée quotidienne
• Courte : ~15mn
• Bilan: mise à jour du tableau de la story
• Qu’est-ce que j’ai fait hier ?
• Qu’est que je vais faire aujourd’hui ?
• Quels sont les obstacles que j’ai rencontrés ?
• Objectif :
• Rythmer le sprint (stories finies, prêtes)
• Recenser les obstacles

claude.godart@loria.fr
88
Polytech Nancy
Revue d’un sprint
• Démonstration de chaque story finie
• Collecte du feedback
• Evaluation du niveau de réalisation de l’objectif
• Evaluation de l’impact du travail réalisé et décision d’une release
(livraison) ou pas

claude.godart@loria.fr
89
Polytech Nancy
Rétrospective d’un sprint
• Collecter les information sur le sprint passé par rapport à la pratique
SCRUM
• Ce qui c’est bien passé, moins bien passé
• Identifier les choses à améliorer
• Décider d’améliorer certaines choses

• Combinée à la revue, de courte durée

claude.godart@loria.fr
90
Polytech Nancy
Rétrospective de sprint : « Starfish »

claude.godart@loria.fr
91
Polytech Nancy
Solidification d’une release
• Tests de qualité de services (performances, coût, sécurité …)
• Documentation
•…

claude.godart@loria.fr
92
Polytech Nancy
Validation d’une release
• Test d’usage avec le client, des utilisateurs

claude.godart@loria.fr
93
Polytech Nancy
Outils
• Confluence
• Jira
•…

claude.godart@loria.fr
94
Polytech Nancy
Différence entre Agile et Scrum

• Agile décrit un ensemble de principes qui utilisent une approche

itérative pour le développement de logiciels, tandis que Scrum est un
ensemble spécifique de règles à respecter lors de la pratique du
développement de logiciels Agile.
 Table de comparaison
Agile Scrum
Scrum est l’une des implémentations de la méthodologie agile.
Agile est une méthodologie de développement basée sur une
Dans lequel des versions incrémentielles sont livrées au client
approche itérative et incrémentale.
toutes les deux ou trois semaines.

Le développement logiciel agile a été largement considéré

Scrum est idéalement utilisé dans le projet où les exigences
comme hautement approprié aux environnements qui ont une
changent rapidement.
équipe de développement de projet petite mais experte

Dans le processus Agile, le leadership joue un rôle essentiel. Scrum crée une équipe multidisciplinaire auto-organisatrice.

Le principal avantage de l’agile est sa flexibilité, car il réagit Comparé à Agile, il s’agit d’une méthode plus rigide. Il n’ya
rapidement aux changements. donc pas beaucoup de place pour des changements fréquents.
Dans Scrum, la collaboration s’effectue quotidiennement, avec
Agile implique des collaborations et des interactions face à face
un rôle fixe attribué au scrum master, au product owner et aux
entre les membres de diverses équipes inter-fonctionnelles.
membres de l’équipe.
Agile peut nécessiter beaucoup de processus de développement
Pas trop de changements nécessaires lors de la mise en
et de changements organisationnels initiaux.
La méthode agile nécessite des livraisons fréquentes à Dans Scrum, après chaque sprint, un build est fourni au client
l’utilisateur final pour obtenir ses commentaires. pour lui permettre de commenter.

Dans cette méthode, chaque étape du développement, telle que Une démonstration de la fonctionnalité est fournie à la fin de
les exigences, l’analyse, la conception, fait l’objet d’une chaque sprint. Pour que les commentaires réguliers puissent
surveillance continue pendant le cycle de vie. être pris avant le prochain sprint.

Le chef de projet prend en charge toutes les tâches de la Il n’existe pas de chef d’équipe. L’ensemble de l’équipe résout
méthode agile. donc les problèmes.

La méthode Agile encourage l’utilisateur final à faire part de Une réunion quotidienne de sprint est organisée pour examiner
ses commentaires pendant le processus. De cette façon, le et faire un retour d’information afin de décider de l’évolution
produit final sera plus utile. future du projet.

Lorsque l’équipe a terminé ses activités de sprint actuelles, le

Livrer et mettre à jour le logiciel régulièrement.
prochain sprint peut être planifié.
La conception et l’exécution peuvent être novatrices et
La conception et l’exécution doivent rester simples.
expérimentales.

Dans la méthode Agile, la priorité est toujours de satisfaire le

Le contrôle de processus empirique est une philosophie de
client en fournissant une livraison continue de logiciels de
base du processus Scrum.
valeur.
Il est préférable d’avoir une communication en face à face et L’équipe Scrum se concentre sur la création d’une valeur
des techniques comme celles-ci devraient être utilisées pour se commerciale maximale, du début à la fin du projet, et tout au
rapprocher le plus possible de cet objectif. long de celui-ci.