PROJET FÉDERÉ Méthode Agile: Le Framework Scrum

Institut Supérieur
d’Informatique et de
Multimédia de Sfax
PROJET FÉDERÉ − Méthode Agile

Le Framework Scrum
Responsable TP: Mariam BEN HASSEN OUALI
Auditoire : 2ème année LSI-MM
A.U : 2021 - 2022 mariem.benhassen@isims.usf.tn

Objectif du TP
 Comprendre la nécessité de la conduite de projets informatiques (logiciels)
 Apprendre les différentes activités de la gestion de projets informatiques
 Comprendre les différents modèles de développement logiciel
 Comprendre la différence entre le développement traditionnel et agile
 Comprendre l’approche « Scrum » Agile et son utilité
 Préparation à la certification
2
© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ 08/02/2022
Pourquoi de la Conduite de Projets ?
 Les projets n’atteignent pas souvent leurs objectifs

─ Dépassement de délais
─ Surcoûts importants
─ Qualité technique du produit insuffisante
 Les projets se déroulent dans un milieu complexe

─ Participation de divers acteurs : étude, production, marketing, etc.
─ Environnement extérieur non maîtrisable : marché, social, politique, concurrence, etc.
3
Objectifs de la Conduite de Projets
 Planifier le projet dans le temps
 Budgétiser de projet
─ Étude préalable des coûts, des sources de financement, etc.
─ Étude des risques opérationnels et financiers
 Aider les différentes parties prenantes du projet à réaliser leurs travaux de projet
 Responsabiliser le chef du projet
─ Mettre en place une comité de pilotage
 Suivre les enjeux opérationnels et financiers importants

4

Définitions & Terminologies
Notion de projet: Définition
 Un projet est un processus unique, qui consiste en un ensemble d’activités coordonnées et
maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif
conforme à des exigences spécifiques, incluant des contraintes de délais, de coûts et de ressources
 Un projet est un effort complexe, non répétitif et unique, limité par des contraintes de temps, de
budget et de ressources (humaines et matérielles) ainsi que par des spécifications d’exécution
conçues pour satisfaire les besoins d’un client [PMBOK -IEEE 1490]
─ complexe: les entrées sont nombreux, interagissent entre elles et créent des situations (ou
problématiques) difficilement prévisibles
─ non répétitif et unique: il n'y a pas deux projets identiques: ils peuvent se ressembler, l'objectif à
atteindre peut-être le même. Mais, il y a toujours des différences plus ou moins importantes soit
dans les détails, soit dans l'environnement, soit dans le contexte de réalisation
─ spécifications d’exécution: le projet répond à un cahier des charges (spécifications des exigences) 5
Définition de Logiciel
 Un ensemble de programmes, de procédures et de documentation associée et les données qui

concernent le fonctionnement d’un système informatique [ISO 24765]
─ Cahiers de besoins et de spécifications
─ Documents de conception
─ Code Source
─ Plans de tests
─ Interface avec le matériel et l'environnement système
─ Documentation, interne et externe
6
Exemples de projets
 Développement de nouveau produit ou service
 Changement de modèle d’organisation
 Conception d’un nouveau moyen de transport
 Développement de système d’information
Campagne électorale
 Implémentation d’un nouveau processus
ERP ou progiciel
 Site Web et commerce électronique
 Câblage
 Etc. 7
Définition de Gestion de Projets
 Selon l’AFNOR « la Gestion de Projet (GP) est l’ensemble des méthodes, outils d’évaluation, de
planification et d’organisation permettant d’atteindre les objectifs du projet en respectant les
contraintes de performance, de délai et de coût »
Définition de conduite de projets informatiques (ou logiciels)
 Fait partie de gestion de projet (GP) qui inclut deux dimensions:
─ La première dimension concerne le côté technique de gestion:la structure organisationnelle, la
planification, l’ordonnancement et le contrôle des projets.
─ La deuxième dimension concerne l’aspect socio-culturelle du processus de GP (culture de projet,
résoudre les problèmes qui menacent la bonne marche du projet, esprit d’engagement, de
coopération et de négociations
 Une organisation méthodologique mise en œuvre pour faire en sorte que le logiciel réalisé par le
développeur répond aux attentes de l'utilisateur dans les contraintes de délai, coût et qualité. 8
Peliers d’un Projet : Le triangle d’OR
La réalisation du projet doit répondre à un niveau adéquat de qualité pour

répondre aux besoins ainsi qu’aux attentes du clients et des utilisateurs
Qualité
Objectif du
Projet
Coût Délai
Ce paramètre représente l’objectif économique du projet Il s’agit d’identifier, avant même le début du projet, le temps
(des recettes et des dépenses) nécessaire à sa réalisation
Caractérise la réussite ou l’échec économique du projet Utiliser des méthodes rigoureuses de planification (PERT, GANT)
9
Pourquoi de la Conduite de Projets Informatiques?
 la gestion de projets logiciels est

─ Nécessaire pour réaliser les projets logiciels
• à temps
• à l'intérieur des budgets
• selon les objectifs Qualité technique du produit insuffisante
 crucial pour réaliser un projet réussi, à cause de

─ La complexité des systèmes logiciels actuels
─ La haute fréquence du changement pendant le développement des logiciels
─ Les contraintes qui sont imposées sur l'horaire, le budget, les ressources
10
Plan –Partie I-
Les exigences Logicielles

01
Le Framework Agile « Scrum »
03
Les modèles de processus de

développement logiciel
02

1.1 Les exigences logicielles
Les modèles de processus de

1.2 développement logiciel
1.3 Les Frameworks Agiles
Cycle de vie d’un 1.4

Projet Informatique

- Les exigences logicielles
Cycle de vie d’un Projet Informatique - Les modèles de processus de développement logiciel
- Les Frameworks agiles
Les exigences logicielles

Souhaits, Attentes
et besoins
Types des exigences d’un logiciel
Exigences Exigences non

Contraintes
fonctionnelles fonctionnelles
Fonctions du système: Propriétés (qualités)

Les obligations désirées du système
ce qui doit être exécuté
Techniques d’élicitation des

exigences
• Lecture de documents externes
• S’immerger dans leur milieu
• Interviews
• Comparer aux autres systèmes
13
• Brainstorming
Les exigences logicielles

 Exigences fonctionnelles (le quoi ?)
─ Une déclaration qui indique ce qu’un produit ou un processus doit accomplir (en termes de tâches et
de services) pour produire le comportement et/ou les résultats requis.
 Exigences non fonctionnelles (« exigences de performance/de qualité de service») (le comment ?)
─ Une exigence logicielle qui ne décrit pas ce que le logiciel va faire, mais comment le logiciel va le faire.
─ Toute exigence qui spécifie quelque chose sur le système lui-même, et de quelle manière il exécute
ses fonctions, y compris la façon dont il devrait être développé et maintenu.
• Performance, robustesse, fiabilité, disponibilité, facilité de maintenance et d’amélioration, facilité de
(ré)utilisation, portabilité, …
 Contraintes
─ Décrivent les limites du développement en quelque sorte:
• Définir un système d'exploitation sur lequel le système doit fonctionner, définir quel langage de
programmation doit être utilisé pour mettre en œuvre le système, définir les ressources humaines 14
et matérielles imposées…
QUIZ TIME
Exercice d’application N°1

 Classer les exigences ci-après en des exigences fonctionnelles (FUR), des exigences non fonctionnelles (NFR) ou des
contraintes (PRC)
─ Le système doit gérer les prêts de la bibliothèque.
─ Le calcul de la distance est effectué dans au moins 5 secondes.
─ Un abonné doit payer 20 dinars par ans.
─ Le système doit utiliser des mots de passe.
─ Le système doit être facile à apprendre.
─ Le système doit se déconnecter automatiquement après 2 mn sans utilisation.
─ Le système doit afficher la liste des emprunts pour un abonné.
─ Le système doit être utilisable même par des non-français.
─ L'espace de stockage de données devrait être suffisant.
─ Le système doit avoir une belle IHM, ergonomique et pratique à utiliser.
─ Le système doit jouer une musique rapidement : elle doit démarrer dans les 2 secondes suivant un click.
─ Le système doit produire automatiquement un rapport de synthèse des ventes hebdomadaires.
─ Le chargement d’une page Web dans le navigateur ne devrait pas prendre plus de 15 secondes en condition normale.
Découpage d’un projet - Les modèles de processus de développement logiciel
Correction Exercice N°1

Exigences logicielles FUR NF PRC
R
Le calcul de la distance doit être réalisé dans au moins 3 secondes. ☻
Un abonné doit payer 20 dinars par ans. ☻
Le système doit utiliser des mots de passe. ☻
Le système doit être facile à apprendre. ☻
Le système doit se déconnecter automatiquement après 3 mn sans utilisation. ☻
Le système doit afficher la liste des emprunts pour un abonné. ☻
Le système doit être utilisable même par des non-français. ☻
L'espace de stockage de données devrait être suffisant. ☻
Le système doit avoir une belle IHM, ergonomique et pratique à utiliser. ☻
Le système doit jouer une musique rapidement : elle doit démarrer dans les 3 secondes ☻
suivant un click.
Le chargement d’une page Web dans le navigateur ne devrait pas prendre plus de 16 s en
Le système doit produire automatiquement un rapport de synthèse des ventes ☻ ☻
condition normale. 17
hebdomadaires.
Système simplifié de Guichet Automatique de Banque (GAB)

─ Le GAB doit permettre à un porteur de carte qui n'est pas client de la banque, de retirer de l'argent, si son crédit hebdomadaire
le permet.
─ Le GAB est accessible 7 jours sur 7, 24h sur 24. L’absence de papier pour imprimer les tickets ne doit pas empêcher les retraits.
─ Un lecteur de carte bancaire à la disposition du porter de carte.
─ Un clavier numérique (pour saisir son code), avec des touches « validation », « correction » et « annulation ».
─ Des touches autour de l’écran pour sélectionner un montant de retrait parmi ceux qui sont proposés .
─ Le porteur de carte doit saisir le montant désiré du retrait.
─ L’interface du GAB doit réagir en l’espace de 2 s au maximum. Une transaction nominale de retrait doit durer moins de 2mn.
─ Le GAB doit contrôler le montant demandé par rapport au solde hebdomadaire.
─ Le porteur de carte doit demander un ticket.
─ Un distributeur de billets à la disposition du porteur de carte.
─ Un distributeur de tickets à la disposition du porteur de carte.
─ Le GAB doit délivrer les billets et un ticket.
─ Le GAB doit enregistrer la transaction de retrait.
─ Les interfaces du GAB doivent être très robustes pour prévenir le vandalisme.
18
─ La comparaison du code d’identification saisi sur le clavier du GAB avec celui de la carte doit être très fiable.
Exigences logicielles FU NF PR
R R C
Le GAB doit permettre à un porteur de carte qui n'est pas client de la banque, de retirer de
☻
l'argent, si son crédit hebdomadaire le permet.
Le GAB est accessible 7 jours sur 7, 24h sur 24. L’absence de papier pour imprimer les tickets ne doit pas ☻
empêcher les retraits ;
Un lecteur de carte bancaire à la disposition du porter de carte ; ☻
Un clavier numérique (pour saisir son code), avec des touches « validation », « correction » et « annulation » ; ☻
Des touches autour de l’écran pour sélectionner un montant de retrait parmi ceux qui sont proposés ; ☻
Le porteur de carte doit saisir le montant désiré du retrait ; ☻
L’interface du GAB doit réagir en l’espace de 2 s au maximum. Une transaction nominale de retrait doit durer ☻
moins de 2mn.
Le GAB doit contrôler le montant demandé par rapport au solde hebdomadaire ; ☻
Le porteur de carte doit demander un ticket ; ☻
Un distributeur de billets à la disposition du porteur de carte ; ☻
Le GAB doit délivrer les billets et un ticket ; ☻
Le GAB
Les doit enregistrer
interfaces la transaction
du GAB doivent être trèsde retrait. pour prévenir le vandalisme.
robustes ☻ ☻ 19
Cycle de vie d’un projet informatique

Processus de Développement logiciel
 Le Processus de Développement
─ Est une collection des principales activités à entreprendre au cours du cycle de vie d’un logiciel
 Différents aspects du processus

─ Qui le fait (le qui) ?
─ Que faut-il faire (le quoi) ?
─ À quel moment le faire (le quand) ?
─ Dans quelles conditions il faut le faire (le comment) ?
─ Quelles sont les raisons, les décisions, le contexte et les objectifs de l'action (le pourquoi)?
20

Notion de cycle de vie
 C'est la description d'un processus couvrant les phases de:
─ Création d'un produit,
─ Distribution sur un marché,
─ Disparition.
 Le but de ce découpage est de

─ Maîtriser les risques,
─ Maîtriser au mieux les délais et les coûts,
─ Obtenir une qualité conforme aux exigences.
• « La qualité du processus de fabrication est garante de la qualité du produit ».
21

Notion de cycle de vie (suite)
 Pour obtenir un logiciel de qualité, il faut en maîtriser le processus d’élaboration
─ La vie d’un logiciel est composée de différentes étapes
─ La succession de ces étapes forme le cycle de vie du logiciel
─ Il faut contrôler la succession de ces différentes étapes
 Cycle de vie et assurance qualité sont fortement liés; il faudra donc en permanence assurer:
─ la validation: sommes nous en train de faire le bon produit?
─ la vérification: est ce que nous faisons le produit correctement?
22

Composants du cycle de vie d’un logiciel/Phases de développement
 Étude de faisabilité
─ Déterminer si le développement proposé vaut la peine d’être mis en œuvre, compte tenu des
objectifs/attentes et de la difficulté de développement
─ Identification de plusieurs solutions avec les bénéfices attendus et les ressources requises
─ Étude de marché : Déterminer s’il existe un marché potentiel pour le produit.
 Spécification
─ Déterminer les fonctionnalités que doit posséder le logiciel
─ Collecte des exigences : obtenir de l’utilisateur ses exigences pour le logiciel
─ Analyse du domaine : déterminer les tâches et les structures qui se répètent dans le problème
23

Composants du cycle de vie d’un logiciel/Phases de développement (Suite)
 Organisation du projet
─ Déterminer comment on va développer le logiciel
─ Analyse des coûts : établir une estimation du prix du projet
─ Planification : établir un calendrier de développement
─ Assurance qualité du logiciel : déterminer les actions qui permettront de s’assurer de la qualité
du produit fini
─ Répartition des tâches : hiérarchiser les tâches et sous-tâches nécessaires au développement du
logiciel
24

Composantes du cycle de vie d’un logiciel/Phases de développement (Suite)
 Conception
─ Déterminer la façon dont le logiciel fournit les différentes fonctionnalités recherchées
─ Conception générale
• Conception architecturale : déterminer la structure du système
• Conception des interfaces : déterminer la façon dont les différentes parties du système
agissent entre elles
─ Conception détaillée : déterminer les algorithmes pour les différentes parties du système
25

 Implémentation
─ Réalisation des programmes dans un(des) langage(s) de programmation
─ Tests du logiciel selon les plans définis lors de la conception
─ Essayer le logiciel sur des données d’exemple pour s’assurer qu’il fonctionne correctement
─ Tests unitaires : faire tester (séparément) les parties (modules) du logiciel par leurs développeurs
─ Tests d’intégration : tester pendant l’intégration des modules (test de tout le logiciel)
─ Tests de validation : pour acceptation par l’utilisateur final
─ Tests système : tester dans un environnement proche de l’environnement de production
─ Tests Alpha : faire tester par le client sur le site de développement
─ Tests Bêta : faire tester par le client sur le site de production
─ Tests de régression : enregistrer les résultats des tests et les comparer a ceux des anciennes
26
versions pour vérifier si la nouvelle n’en a pas dégradé d’autres

 Livraison
─ Fournir au client une solution logicielle qui fonctionne correctement
─ Installation : rendre le logiciel opérationnel sur le site du client
─ Formation : enseigner aux utilisateurs à se servir du logiciel
─ Assistance : répondre aux questions des utilisateurs
 Maintenance
─ Mettre à jour et améliorer le logiciel pour assurer sa pérennité
• Maintenance corrective, adaptive, perfective
─ Pour limiter le temps et les coûts de maintenance, il faut porter ses efforts sur les étapes
antérieures 27

Les modèles de processus de logiciel
 Un modèle de processus de logiciel
─ est une approche générale pour organiser un projet en activités
─ est une représentation abstraite d'un processus de logiciel
─ Modèle temporel générique, qui comprend des étapes et des phases
─ aide le chef de projet et son équipe à décider
• quel travail devrait être effectué
• dans quel ordre le travail devrait être effectué
 Les modèles sont des aides à la pensée, ils ne sont pas des prescriptions rigides de
comment faire les choses
 Différentes organisations ont différents processus
─ les différences résultent de la nature des entreprises, même au sein d’une même entreprise, 28
plusieurs processus peuvent être utilisés
Modèles de cycle de vie d’un logiciel
 Modèles linéaires et incrémentaux

─ Modèle en Cascade
─ Modèle en V
─ Modèle en W
─ …
 Modèles non linéaires

─ Prototypage
─ Modèles incrémentaux
─ Modèle en spirale
─ Développement Agile
29
Les modèles de développement: Modèle en cascade

 Waterfall model
Étude de faisabilité • Modèle séquentiel linéaire
 Pas de modification possible des
Validation besoins
Définition des besoins
• Après le démarrage du projet
• En particulier si elles sont découvertes
Validation tardivement
Conception générale
 Étapes différentes = personnes différentes
Vérification • Risques d'incohérences
Conception détaillée
Vérification
Codage/Implémentation (Solution)
Tests unitaires
Validation
Tests d’intégration 30
© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ Mise en Service 08/02/2022
Les modèles de développement: Modèle de la cascade
 Dans ce modèle le principe est très simple : chaque phase se termine à une date précise par la
production de certains documents ou logiciels.
 Une séparation stricte des phases/étapes
 Chaque étape est effectuée une seule fois
 Interaction entre les étapes successives
 Chaque étape est complétée par la documentation des accomplissements
 Documents associés:
─ Récapitulatif de l'architecture conceptuelle; Récapitulatif des besoins; Récapitulatif de
l'architecture préliminaire; Récapitulatif critique de l'architecture
─ À réaliser avant le codage
31
Les modèles de développement: Modèle de la cascade
– La séparation des étapes est trop stricte et inflexible: on doit

– Facile à gérer
compléter une étape avant de commencer l'étape suivante
– Le modèle est facile à comprendre et à utiliser
– La moindre erreur coûte cher
– Chaque phase donne lieu à une validation officielle – Le modèle est seulement approprié quand les exigences sont
– Les systèmes sont spécifiés avant leur conception bien définies
– Les composants du système sont conçus avant leur – Il est rare que le client peut fournir toutes les spécifications
implémentation dès le début du projet; les exigences changent constamment
– Identifient implicitement certains aspects de flux de – c'est difficile de changer les spécifications quand le
connaissances processus est en cours
– Les étapes clés sont bien-définis – Le client est intégré uniquement dans le processus de
production après la programmation
– Facile à maintenir
Problèmes non découverts avant les tests
– Dans chaque étape les accomplissements sont Pas de prise en compte de l'évolution
explicitement documentés Apparition de besoins fonctionnels lors du codage
– Les coûts et la charge du travail peuvent être estimés Pas de tests des performances avant la réalisation 32
dès le début du projet. Difficulté d'amélioration des performances
© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ Cause de l'échec de nombreux projets 08/02/2022
Les modèles de développement: Modèle en V
Tests fonctionnels (de

Analyse/Spécifications validation)
Test d’une
Conception (globale) du Tests d’Intégration fonctionnalité
système
Test de composition
entre modules
Conception (détaillée)
des composants Tests unitaires
Test de chaque fonction

Codage/Programme indépendamment
Cheminement
Si échec
Document produit 33
 Caractéristiques
─ Modèle en cascade amélioré
─ Comporte une phase descendante et qui correspond à la partie d’avant projet, de conception et de
réalisation et la phase dite ascendante qui correspond au test, l’implémentation des solutions
proposées et leur mise en service.
─ Les procédures de vérification de la conformité du logiciel aux spécifications doivent être élaborées
dès les phases de conception
─ Validation systématique de chaque étape
─ Décomposition du projet en parties

34
Limites
Fonctionne comme un « rouleau compresseur »: on doit aller jusqu’au bout sans modifier les
spécifications initiales, c'est-à-dire les objectifs et les fonctionnalités attendues du logiciel.
La mise en application de modèle en V reste fastidieuse: la méthode manque de souplesse par

rapport à la gestion de projet Agile.
• Le cycle en V est un modèle de gestion de projet standard qui ne permet pas la prise en compte des
risques.
Le logiciel ne soit livré qu'à la fin des développements complets. Le client ne voit le produit que
lorsque celui-ci est terminé, avec tous les risques que cela comporte.
35

Analyse des risques (exemples)
 Risques humains
─ Défaillance du personnel; surestimation des compétences
─ Travailler solitaire, héroïsme, manque de motivation
 Risques technologiques
─ Produit miracle, « plaqué or »
─ Changement de technologie en cours de route
─ Problème de performance
─ Exigences démesurées par rapport à la technologie
─ Incompréhension des fondements de la technologie
36

Analyse des risques (exemples)
 Risques processus
─ Pas de gestion de projet
─ Calendrier et budget irréalistes
─ Calendrier abandonné sous la pression des clients
─ Composants externes manquants
─ Tâches externes défaillantes
─ Insuffisance de données
─ Validité des besoins
─ Développement de fonctions inappropriées
─ Développement d'interfaces utilisateurs inappropriées 37
Problème d’Expression des Besoins/Problème de Livrable
38
Problème d’Expression des Besoins/Problème de Livrable
39
Les modèles de développement: Modèle itératif

Étape n:
Principe:
Expression des besoins
Portions toujours croissantes du logiciel
A chaque étape, on rajoute de nouvelles
Spécifications fonctionnelle
fonctionnalités
Caractéristiques
Conception et architecture
Chaque étape est relativement simple
On peut tester et essayer au fur et à mesure le
Codage
logiciel que l’on développe
Tests
Permet la correction des:
- erreurs de codage
Documentation - erreurs de conception
- erreurs de spécifications
Prototype 40
Maintenance
© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ n 08/02/2022
Modèle Prédictif VS Modèle Empirique/Adaptive

Modèle Prédictif Modèle Adaptive
41
Analyse et Spécification
Modèle Cascade
des Besoins
Conception
Implémentation
Vérification/Test
Itératif/Incrémental
Modèle
Sprint Sprint Sprint Sprint Sprint Sprint
42
Modèle Prédictif VS Modèle Empirique/Adaptive

Modèle en Cascade
Développement Orienté
Planning
(Coût élevé)
Modèle Agile
Développement Orienté
Valeur
43
Approche Classique VS Approche Adaptive

Approche Prédictive Approche Adaptive
Objectifs clairs par le biais du temps Itération de courte durée avec un
incrément de haut qualité
Processus qui parait simple et facile aboutira à la Forte implication du client
non satisfaction du client (80% des fonctions d'un
logiciel sont peu ou pas utilisées)
Gain du temps et d’argent par le biais d’un grand Moins de risques
risque
Axée sur la planification Axée sur la valeur
Cascade/modèle en V Agile
Solution : Agilité
44
Méthodologie/Modèle Agile
Définition de l’agilité
L’agilité est une valeur montante dans le secteur de la production de logiciel.
L’agilité exige de s’adapter au changement inhérent aux environnements turbulents. Ces

changements pouvant être au niveau des spécifications, des intervenants, des procédures et
surtout, dans le domaine logiciel, des technologies.
« L’agilité est l’habilité conjointe de créer et de répondre aux changements d’un

environnement turbulent au profit de l’entreprise » [Traduit et tiré de Highsmith 2002]
45
La méthodologie Agile favorise un environnement d’adaptation (i.e., qui

repose sur des cycles de développement itératifs et adaptatifs en fonction
des besoins évolutifs du client), de travail d’équipe, d’auto-organisation et de
livraison rapide qui permet un haut niveau de participation des clients au
début de la planification du projet.
46
Méthodologie/Modèle Agile: Caractéristiques

 Incrémental (modèle en V)
─ Il s’agit de produire toujours un peu plus à chaque fois
─ Construire le produit morceau par morceau jusqu’au rendu final
 Itératif
─ Implique la répétition d’un cycle d’opérations
─ Le projet est affiné au fur et à mesure de chaque opération
─ L’estimation de charge est difficile, mais les courtes itérations nous aident
• On est plus précis sur les petites tâches
• Feedback très rapide
• Plus facile à s’adapter face aux dérives, surprises 47

 Les méthodes Agiles nécessitent l’implication du modèle incrémental et du modèle itératif à la fois,
ainsi qu’une grande adaptabilité:
─ Modification graduelle des objectifs et des spécifications des logiciels

─ Livraison des logiciels qui fonctionnent immédiatement avec un jeu restreint de fonctionnalités, là où
les méthodes classiques imposent que le logiciel ne soit livré qu'à la fin des développements
complets
─ Ce jeu de fonctionnalités est ensuite enrichi régulièrement, en fonction des nouvelles demandes des
utilisateurs ou de la pression concurrentielle
48
 Libérer le génie humain pour l’auto-organisation dans un contexte qu’il peut maîtriser :
─ La taille de l’équipe est limitée
─ Le domaine du problème est limité
• Petites équipes autogérées

• Portée fonctionnelle restreinte à un moment donné
• Garder un rythme de travail soutenable
• Avancement par itération
49
Les Solutions Classiques Les Solutions Agiles
• . .
Expression de besoins
Expression des besoins
Conception
Conception
Développement
Développement
Tests, recette & debuggage
Tests, recette & debugage
i i i i
1 2 3 n
50

─ De nombreuses entreprises d’ingénierie et de service ainsi que de nombreux éditeurs de
logiciels ont lancé des projets en mode agile, lorsque le contexte technique ou contractuel y
était favorable
─ L’objectif ultime est la satisfaction des utilisateurs en termes de valeur perçue, de facilité
d’utilisation et de respect des délais.
─ Les premiers promoteurs des méthodes agiles ont également impulsé des valeurs nouvelles
pour penser le travail.
─ Ces valeurs ont été écrites sous la forme d’un « Manifeste Agile » au début de la décennie
2000, qui met en avant quatre valeurs fondamentales.
51
Le manifeste Agile: Les 4 valeurs de l’Agilité (1/3)
Personnes et interactions Plutôt que Processus et outils
Un produit opérationnel Plutôt que Documentation exhaustive
Collaboration avec le client Plutôt que Négociation d'un contrat
Adaptation au changement Plutôt que Suivi d'un plan
52
Le manifeste Agile
Toujours focalisées sur le

Personnes et interactions produit final
La cohésion d'une équipe est plus

importante que le suivi des L’objectif d’un développement
conventions. logiciel est de produire un logiciel, la
Ce principe insiste sur la qualité des documentation doit être considérée
individus impliqués et l’esprit de comme un support complémentaire
collaboration. aidant à sa compréhension.
Cet élément reflète la synergie et la Il est préférable d'investir ses efforts
motivation qui doit laisser au second sur le produit, plutôt que sur les
plan la rigidité du processus ou la éléments qui le décrivent.
complexité des outils. 53
Le manifeste Agile (3/3)
Adaptation au changement Collaboration avec le client

L’agilité reconnaît l’apprentissage fait au L’agilité vise la collaboration des
cours d’un projet. Que tout n’est pas deux parties pour atteindre un
connu d’avance et que des adaptations objectif commun.
sont inévitables. Le client doit s’impliquer et diriger
Le changement est intégré au modèle de l’équipe dans les étapes de
développement. La planification réalisation.
originale ne doit pas être trop détaillée, Il doit s'approprier l'évolution de
car certains aspects ne seront son produit. L’agilité évite le
probablement jamais réalisés. gaspillage des négociations et des
Ceci évite de détailler inutilement des demandes de changement.
éléments trop tôt dans le projet.
54
Le Manifeste Agile: Les 12 Principes de l’Agilité
1. Satisfaire le client 2. Accueillir les changements 3. Livrer fréquemment
Notre plus haute priorité est de Accueillons positivement les Livrons fréquemment un logiciel
satisfaire le client en livrant changements de besoins, même opérationnel avec des cycles de
rapidement et régulièrement des tard dans le projet. Les quelques semaines à quelques
fonctionnalités à grande valeur processus agiles exploitent le mois et une préférence pour les
ajoutée changement pour donner un plus courts
avantage compétitif au client
4. Travailler ensemble 5. Confiance et soutien 6. Dialogue en face à face
Les utilisateurs ou leurs Réalisons les projets avec des À intervalles réguliers, l'équipe
représentants et les développeurs personnes motivées, en leur réfléchit aux moyens de devenir
doivent travailler ensemble fournissant l’environnement et le plus efficace, puis règle et
quotidiennement tout au long du soutien dont ils ont besoin et modifie son comportement en
projet faisons-leur confiance pour conséquence
atteindre les objectifs fixés 55

Le Manifeste Agile: Les 12 Principes de l’Agilité
7. Logiciel opérationnel 8. Développement soutenable 9. Attention continue
Un logiciel opérationnel est la Les processus agiles encouragent Une attention continue à
principale mesure d’avancement un rythme de développement l'excellence technique et à une
soutenable. Les commanditaires, bonne conception renforce
les développeurs et les utilisateurs l’agilité
doivent être capables de maintenir
indéfiniment un rythme constant
10. Privilégier la simplicité 11. Équipes auto-organisées 12. Réfléchir et adapter
La simplicité (c’est-à-dire l’art de Les meilleures architectures, À intervalles réguliers, l'équipe

minimiser la quantité de travail spécifications et conceptions réfléchit aux moyens de devenir
inutile) est essentielle émergent d'équipes auto- plus efficace, puis règle et
organisées modifie son comportement en
conséquence
56

Les solutions Agiles

Avantages
Toujours focalisées sur le produit final
☺ Une vision commune pour l’équipe
• La satisfaction du client
☺ Découper le projet autrement
• par fonctionnalité
☺ Organiser en cycles de développement réduits
• itérations
Collaboration avec le client
̶ Pourquoi on veut des contrats ?
• Instaurer la confiance autrement
• Éviter les effets pervers d’un contrat 57
Les solutions Agiles
Avantages
Adaptables
☺ Réactives aux nouveaux besoins
☺ Réceptives aux nouvelles solutions
• Prendre les décisions définitives le plus tard possible
• De courtes itérations permettent de changer de direction sans laisser
des éléments à moitié fait
Le contrôle qualité est accru
̶ Une étape ne sera pas validée si un livrable ne convient pas au client
• Éviter l’accumulation des erreurs tout au long du projet
58
QUIZ TIME

 Compléter les tableaux ci-après en précisant le(s) modèle(s) de processus de développement logiciel utilisée(s).
Les exigences logicielles Incrémental Agile Cascade
Les exigences sont très bien connues ou faciles à définir au début du cycle de développement ☻ ☻ ☻
Les exigences peuvent être bien définies au début du cycle de développement ☻ ☻
Les exigences sont susceptibles de changer souvent au cours du cycle de développement ☻
Des démonstrations sont nécessaires pour le développement des exigences ☻
Les exigences indiquent que le système à développer est un système vaste et complexe ☻
La livraison rapide des fonctionnalités limitées est souhaitée ☻ ☻
L’équipe de développement Incrémental Agile Cascade
La plupart des membres de l'équipe de développement sont nouveaux dans le domaine du
☻
projet logiciel
La plupart des membres de l'équipe de développement ne sont pas familiers avec les outils
☻
utilisés pour le développement du logiciel
Certains membres de l'équipe seront probablement affectés au cours du cycle de
☻
développement du logiciel
Des membres de l'équipe doivent nécessairement interagir avec le client quotidiennement ☻
Les progrès de l'équipe seront étroitement suivis par les gestionnaires et les clients ☻ ☻
© Mariam Ben Hassen- TD Conduite de Projets Informatiques 08/10/2021

 Compléter les tableaux ci-après en précisant le(s) modèle(s) de processus de développement logiciel utilisée(s).
Utilisateur/ Client Incrémental Agile Cascade
La disponibilité du client sera limitée au cours du cycle de développement ☻ ☻
Les représentants des utilisateurs du logiciel à développer sont nouveaux pour la définition
☻
des besoins
Les utilisateurs sont des experts dans le domaine du projet logiciel ☻ ☻
Les représentants des utilisateurs du logiciel veulent être impliqués dans toutes les phases
☻ ☻
du cycle de développement
Si le client veut suivre de près les progrès de développement ☻ ☻
Type de projet logiciel Incrémental Agile Cascade
Le domaine du projet logiciel est nouveau pour l'organisation ☻
Le projet logiciel implique l'intégration du système ☻
Le projet logiciel implique l'amélioration d'un système existant ☻ ☻
Le financement est instable au cours du cycle de développement ☻
Le calendrier est limité ☻ ☻
Des composants réutilisables sont disponibles ☻
Les ressources
© Mariam (employé,
Ben Hassen- outil,
TD Conduite argent)
de Projets sont rares
Informatiques ☻ ☻ 08/10/2021
Les Frameworks Agiles
Rational Unified Process (RUP) Crystal family of methods/

RAD pour Rapid Application Crystal Clear (2004)
Development
XP pour eXtreme
Scrum (1996) Programming (1999) Kanban
Lean product development
Feature-Driven Development (FDD) Dynamic Systems Development

Method (DSDM)
[15th Annual State Of Agile Report, 2021] 62
2.1 Définition de Scrum
2.2 Théorie de Scrum
2.3 Valeurs de Scrum
2.4 Processus Scrum
2.5 Équipe Scrum

Le Framework
Scrum 2.6 Les Artefacts de Scrum
2.7 Événements Scrum 63

© Mariam Ben Hassen- TD Conduite de Projets Informatiques
- Caractéristiques de Scrum
- Équipe Scrum
Le Framework Scrum -
-
Théorie de Scrum
Valeur Scrum
- Les Artefacts de Scrum
- Événements Scrum
- Processus Scrum
L’approche AGILE SCRUM
 Le terme « Scrum » est emprunté au rugby et signifie mêlée
Le Framework Scrum est un cadre de travail léger/simple, au sein duquel les personnes,
les équipes et les organisations peuvent aborder des problèmes complexes et adaptifs,
tout en livrant de manière productive et créative des produits de la plus grande valeur
possible [Ken Chwaber & Jeff Sutherland, 1990]
64
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
L’approche AGILE SCRUM

Démarche itérative, incrémentale, empirique et pensée «Lean» pour optimiser la prédictibilité et
contrôler les risques (produire le maximum de valeur pour le minimum de coût)
 S’appuie sur:
− Des équipes auto-gérées et adaptables et sur l’intelligence collective
− Cycles de développement courts « Sprints » (1 à 4 semaines)
− Implication forte du client (revue de sprint)
 Un Product Owner ordonne les besoins (le travail à faire) pour résoudre un problème complexe dans
le backlog de produit (Product Backlog)
 La Scrum Team transforme une sélection de ce travail en un Increment de valeur lors d'un Sprint
 La Scrum Team et ses parties prenantes inspectent les résultats et s'adaptent pour le prochain Sprint
65
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Composants de Scrum
 Équipe Scrum
─ Product Owner − Scrum Master − Équipe de développement
 Événements
─ Quatre événements prescrits (à durée limitée) sont utilisés dans Scrum afin de créer de la
régularité et de minimiser le temps passé en réunions
• Planification de Sprint (Sprint Planning)
• Mêlée Quotidienne (Daily Scrum)
• Revue de Sprint (Sprint Review)
• Rétrospective de Sprint (Sprint Retrospective)
 Artéfacts (Product Backlog, Sprint Backlog, Increment)
─ Ils représentent du travail ou de la valeur de diverses manières, de telle sorte qu’ils
fournissent de la transparence et des opportunités pour l’inspection et l’adaptation 66
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le Dilemme SCRUM
Léger Simple à comprendre Difficile à maîtriser

67
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Empirisme du Scrum
Contrôle empirique de processus Réduction du gaspillage
L'empirisme soutient que les La pensée Lean réduit le gaspillage
connaissances proviennent de et se focalise sur l'essentiel
l'expérience et que la prise de
décision s’appuie sur l’observation de
faits connues
Empirisme Pensé Lean
Approche iterative et incrémentale Équipe de haute qualité

Scrum engage des groupes de personnes
Scrum utilise une approche itérative
qui ont collectivement toutes les
et incrémentale pour optimiser la
compétences et l'expertise requises pour
prédictibilité et le contrôle de
faire le travail et partager ou acquérir de
risque 68
telles compétences selon les besoins
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les trois piliers de Scrum
Scrum
Transparence
Adaptation
Inspection
69
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les trois piliers de Scrum
Scrum
Transparence Adaptation
- Le processus et le travail émergents
Inspection
Lors d’un contrôle, si un ou
doivent être visibles pour ceux qui
Les artefacts Scrum et les progrès plusieurs aspects d’un processus
effectuent et reçoivent le travail
vers les objectifs convenus doivent sortent des limites acceptables et
- Définition d’un standard commun que le produit résultant sera
être inspectés fréquemment et
pour ces aspects afin que les inacceptable, le processus ou le
avec diligence pour détecter des
observateurs partagent une développement en cours doit être
écarts ou des problèmes
compréhension commune de ce qui ajusté dès que possible afin de
potentiellement indésirables
est observé minimiser le risque d’autres dérives
70
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les cinq valeurs de Scrum
Tout le monde se concentre sur le travail à faire et sur les objectifs Focus
L’équipe Scrum et ses paries prenantes acceptent d’être ouverts
sut tout le travail et les défis impliqués Ouverture
Les membres de l’équipe gagnent le respect en
renforçant la confiance entre les équipes
Respect
Les membres de l’équipe ont le courage de faire
les bonnes choses et de résoudre les problèmes
Courage
Les membres de l’équipe s’engagent
personnellement à atteindre les
objectifs de l’équipe
Engagement
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le processus Scrum: un cycle adaptatif, itératif et incrémental
72
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le processus Scrum
73

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le processus Scrum
74

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le processus Scrum: un cycle adaptatif, itératif et incrémental
Mêlée
Estimation quotidienne
Sprint Burndown Chart
Visualisation de l'état du projet sous la
Planification
Créer
forme d'un tableau du Sprint
•15
un minutes,
Backlog tous
dules jours
produit
Mêlée
•Trois questions pour chacun
Revue
•Par•Les
analogie du
tâches sprint
de àpréférence
faire
quotidienne
•Qu’avez-vous fait hier
Rétrospective
•L'intuition
•Les
•Géré par est
tâches le acceptable
en
Productcours du sprint
!
Owner
de l’équipe : décisions
•Réunion•Qu’allez-vous collectives
faire aujourd’hui
•Planning
•les
•Définir Poker
•Listetâches
deun tout terminées
ce
objectif qui
pour va
le entrainer du
sprint
•Quels
•Présentation
•Eviter l'influence sont 24
des vos
heures
des du problèmes
nouveautés
leaders d'opinion
•Choisir
travail des
pour éléments
l’équipe Backlog de produit
•Uniquement l’équipe
pour mettre dans leest
•Tout le
•Collégialité monde invitédu sprint
backlog
•Appréciation
•Constat de ce qui de a la
bienvaleur
ou apportée
moins bien
•Chaque élément est découpé en tachesle
•Toute
•Mettre
•Recherche à l’équipe
jour
du le participe
Backlog
consensus, et –
depas
du
la juste
Sprint
propriété
qui
marché
par
Scrum
collective dans
l’élément
Master
des l’organisation
! total(max
estimations
sontreste
•Le estimées à faire
en heures pour2 jours)
le Sprint ->
•La •Informel
•Chiffré
conception de
de façon
2haut imprécise
niveau
– 4 semaines est abordée
burndown chart
tâchesStories
•Les•User ne sont pas nominatives
Backlog du Produit Backlog du sprint Produit 75

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Quelques règles
 Durée fixe des Sprints (timebox)

─ Si on n’a pas fini, on livre quand même une version composée de ce qui marche Releasable
Livrable
 Pas de changements qui remettent en cause le Sprint Goal Highly flexible

and adaptive
─ Mais on les accepte aménagements en toute connaissance de cause
 On ne définit les détails que au bon moment (plans et produit)

─ Les items de Backlog sont décomposés et détaillés quelques semaines avant leur implémentation
76
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les Rôles (Acteurs) dans Scrum Team

Scrum Team <=10
Product Owner (PO) Scrum Master (SM) Development Team (DT)

- Decides what to do and why - Focus on how to work better - Do the work development
77
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les Rôles (Acteurs) dans Scrum Team
─ N’a pas de hiérarchie dans l’équipe

─ N’a pas de sous équipe
─ Est pluridisciplinaire
─ Prend des décisions sur son périmètre
─ Suffisamment petite pour être réactive
─ Suffisamment grande pour produire de la valeur à chaque Sprint
─ Souvent 10 personnes ou moins
─ Toute la Scrum Team est responsable de la création d’un Incrément qui ait de la valeur
et qui soit utile, à chaque Sprint 78
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Le Product Owner
Responsable de la gestion, du contrôle et de la
visibilité du Backlog Produit Représentant des clients et des
utilisateurs
• Exprimer clairement les items du Une seule
Product Backlog personne • Il est chargé d’écouter et d’exprimer
les exigences du client: il représente
• Ordonner les items du Product
le voix du client
Backlog (définir les priorités) pour
mieux réaliser les objectifs et les • Porteur de la vision globale du
missions produit
• Optimiser la valeur du travail effectué Responsable de maximiser la valeur du
par le DT produit résultant du travail de DT
• S’assurer que le Product Backlog est • Le bon produit=crée de la valeur
visible, transparent et clair pour tous, Peut déléguer
mais reste • Interface avec les réalisateurs:
et qu’il montre ce sur quoi le DT responsable • Clarifie/s’assure de la compréhension
travaillera prochainement
• Suit et valide la réalisation
• S’assurer que le DT comprend les
Le « Quoi » et le « Pourquoi » • Prendre des décisions sur le produit79
items du Product Backlog
sont très clairs et très priorisé (accepte ou rejette les livrables)
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
L’Équipe de Développement
Il est responsable de créer un plan pour le
Le DT est pluridisciplinaire, qui contient
Sprint et un Sprint Backlog toutes les compétences nécessaires pour
mettre en œuvre un incrément du produit
(Analyste, Architecte, concepteur,
développeur, spécialiste IHM, testeur, etc.)
Il adapte leur plan chaque jours pour Il est auto-organisée et auto-gérée (les
viser le Sprint Goal décisions sont prises collectivement)
Le DT doit être assez petite pour rester réactive Il inculque la notion de qualité en adhérant
et assez grande pour accomplir un travail au «Definition Of Done»: il livre à chaque
significatif durant le Sprint: 6 personnes +/- 3 sprint un incrément « Fini »
(sans tenir compte du PO et SM) potentiellement publiable (Releasable) à la
fin de chaque Sprint
Ne change pas pendant un Sprint

80

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Qualités du Dev Team

Connaissance de Scrum
Collaborative/Auto-organisée
Motivée/Indépendante
Proactive/Polyvalente
Esprit d’équipe
Responsable/Intuitive
Concentrée sur les objectifs
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Scrum Master
Il est Il n’est
– Un facilitateur, un coach, un leader, un agent de changement, qui Il n’est pas le chef, il n’assigne pas les tâches
s’assure que l’équipe Scrum dispose d’un environnement
– Il ne doit pas servir de passe plats
favorable à la réussite de projet
– Il ne fait pas le reporting au management
– Le SM est responsable de la compréhension et de l’application de
la méthode Scrum: il guide, facilite et enseigne les pratiques – Il évite de s’impliquer dans le cycle de vie du projet
Scrum à tous les participants du projet
– Le SM n’est pas le PO. Le PO porte plus sur la vision
– Celui qui élimine les obstacles qui ralentissent l’équipe et garantit métier, alors que le SM s’assure que toute l’équipe
le respect des processus Scrum comprend Scrum et l’applique correctement
– Celui qui rend l’équipe autonome
– Celui qui vise à la résolution des problèmes
– Le garant de la transparence
– Celui qui aide l’environnement à devenir agile ( clients…)
– Le Scrum Master est responsable de l’efficacité de l’équipe Scrum
– Les Scrum Masters sont de véritables leaders qui servent la Scrum 82
Team et l'ensemble de l'organisation

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Scrum Master au service: de Product Owner

Il aide le PO à comprendre et mettre S'assurer que les objectifs, le périmètre et le
en œuvre l’Agilité domaine du produit sont compris par tous les
membres de l'équipe Scrum de la meilleure
façon possible
Comprendre la planification de produits

dans un contexte empirique Trouver des techniques pour une
gestion efficace du Backlog produit
Il forme le PO à prioriser et gérer

efficacement le Backlog Produit pour Aider l'équipe Scrum à comprendre le
maximiser la valeur métier besoin de clarté et concision des
éléments du Backlog produit
Faciliter les événements Scrum, en cas de demande ou nécessité

83
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Scrum Master au service: de l’Équipe de développement

Il coache le DT pour devenir une équipe
Il résout les éventuels empêchements/blocages
auto-organisée et pluridisciplinaire
qui pourraient apparaître pendant le Sprint
Il aide la Scrum Team à rester focaliser Il participe aux réunions et s’assure que
sur la production d’incréments de grand tout les évènements Scrum aient lieu,
valeur utilisable soient positifs, productifs et respectent
leur timebox et l’objectif fixé
Il aide à la pratique de Scrum: Coacher le
DT dans des environnements Il soutient le DT pour mettre en œuvre les
organisationnels où Scrum n'est pas encore éventuelles améliorations identifiées lors
complètement adopté et compris de la rétrospective du sprint
84
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Scrum Master au service: de l’organisation

Il planifie la mise en œuvre de Accompagner, former et encadrer l'organisation
Scrum avec l’organisation (employés, parties prenantes) dans son
adoption de Scrum
Il aide l’organisation à comprendre

lesquelles des interactions avec l’équipe Planifier et apporter conseils sur les
apportent ou non de la valeur implémentations de Scrum au sein de
l’organisation
Il aide l’organisation à comprendre et

adopter une approche empirique pour un Contribuer à lever les obstacles qui
travail/environnement complexe peuvent se dresser entre les parties
prenantes et les Scrum Teams
85

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
86
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
87
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Artefact Scrum: Le Backlog du Produit
88
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
 Le Backlog du Produit « Product Backlog » est l’artefact le plus important de Scrum, c’est l’ensemble
des éléments/exigences fonctionnelles ou techniques (non fonctionnelles) à implémenter, qui
constituent le produit souhaité
− Les exigences fonctionnelles regroupent des histoires utilisateur (User Story), Epic, Feature, Theme, etc.
− Les exigences techniques sont appelées des histoires techniques (Technical Story): Limites,
performances, etc.
 Ordonné par priorité

─ Valeur, Risque, Dépendance techniques, etc.
 Sous la responsabilité du Product Owner

─ 1produit/1 Backlog/1ProductOwner
89
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Élaboration du Backlog du Produit

Établir la Vision du projet/Product Goal (1/2)
 La vision sur un projet/produit correspond au niveau le plus
élevé de représentation sémantique.
 La vision est un élément structurant pour les projets/produits

car:
− Elle donne du sens aux choses
− Elle fixe une direction principale
− Elle résume les objectifs à atteindre et présente un état
désiré
− Elle introduit la notion de priorité
 Elle permet de représenter la valeur principale attendue par

le/les client(s) pour réussir le Projet/Produit.
 Le Product Backlog sert la vision (il est le plan) 90

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Établir la Vision du projet/Product Goal (2/2)
 Il est important que cette vision soit acceptée et comprise par tous, elle doit faire consensus puisque l’équipe
va devoir se rallier derrière le PO pour réaliser ce projet selon l’objectif que le projet devra atteindre
 Exemple1 de vision pour notre système de gestion des locations vidéos:
« Offrir une solution de gestion complète, incluant suivi, statistiques et facturation ainsi qu’un module de
prélocation en ligne et d’analyse statistique pour les vidéoclubs »
 Exemple 2 de vision pour la plateforme d’un Système de soutien éducatif :
« Nous proposons de concevoir et d’implémenter une plateforme web en ligne qui regroupe les fonctionnalités
essentielles d’e-learning qui englobe à la fois le sharing (document, webcam) et le partage d’idées, des
connaissances et des formations en ligne pour faciliter et renforcer les relations entre les tuteurs et les apprenants »
91
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Élaboration des User Story
Exprimer ses besoins Product Owner User Story
92
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Ce sont les spécifications du projet présentées sous forme d’histoires utilisateurs qui décrivent les
interactions de l’utilisateur avec le système de façon plus ou moins détaillées
Description des exigences pour toutes fonctionnalités ou « tâches » nécessaires au fonctionnement
du produit en développement
Écrites par le Product Owner de manière concise et ne concerne qu’une seule fonctionnalité à la fois
Une fois rédigée, une User story va s’ajouter aux autres récits du produit et ensemble pour
constituer le « Product Backlog »
 Chaque histoire utilisateur possède un effort (vélocité) qui est l’estimation initiale sur la quantité de
travail nécessaire pour implémenter cette exigence
─ Cet effort est calculé en point d’histoire qui correspond aux jours hommes idéaux
• Généralement, un point d’histoire vaut un jour/homme. 93
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Une user story s’écrit comme suit :
En tant que <rôle> Je veux <liste de tâches> Afin de <valeur ajoutée ou résultat>
94
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Exemples
 « En tant que Bob, Je peux créer un compte client, Afin de pouvoir leur louer des films »
 « En tant qu’acheteur en ligne, je veux pouvoir ajouter des items à mon panier supprimer les items
afin de pouvoir n’acheter que ce dont je suis vraiment certain »
 « En tant que client, je peux consulter la liste des factures émises »
 « En tant que client (du projet), je peux consulter la liste de mes clients »
 « En tant que client, je peux connaître le montant total des factures impayées »
95
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Critères de qualité de User Story
II ndépendante
N égociable
VV erticale
EE stimable
SS mall (Sized appropriately)
TT estable
96
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Scrum n’impose pas de pratique pour identifier et nommer les éléments du Backlog. L’usage le plus
courant est de définir un élément comme étant une story ou un cas d’utilisation
Dans un Backlog de Produit, les stories sont rangées (Classées) selon l’ordre envisagé pour leur
réalisation. Cette notion de priorité prend une grande importance dans le développement itératif.
Un Backlog Produit peut se présenter comme le tableau ci-après :
Scénario ou User Story Priorité Effort Risque

En tant que client, je veux que mon robot puisse trier les pièces selon leur M 1 1
forme
En tant que client, je dois pouvoir soumettre mon ordre de fabrication via M 2 3
internet
En tant que donneur ordre de fabrication, je dois être informé par une M 2 2
notification sur mon smartphone à chaque changement de l’état de l’OF
97
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Autre Exemple de Backlog Produit
98
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Priorité des items/US
MUST HAVE SHOULD HAVE COULD HAVE WON’T HAVE

DOIT être fait DEVRAIT être fait (Il Il s’agit d’une Il s’agit d’une exigence «Luxe»
s’agit d’une exigence exigence NE SERA PAS faite cette fois mais
essentielle, qu’il faut souhaitable plus tard, mais intéressante et à
faire dans la mesure garder pour la prochaine version
du possible) 99
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Estimation des User Story: Effort
Une estimation va définir l’effort nécessaire pour réaliser la tâche
Une US doit être réalisable par un membre de l’équipe dans le temps défini du sprint. Sinon, elle doit
être découpée plus finement
Permet de définir l’engagement et calculer la vélocité d’une équipe
Exemples:
− 5jours/homme : a une durée de 5 jours si le nombre de ressources qui travaillent en parallèle et à
temps plein est égal à 1.
− A une durée de 10 jours si le nombre de ressources qui travaillent en parallèle et à mi-temps est
égal à 1.
− A une durée de 1 jours si le nombre de ressources qui travaillent en parallèle et à temps plein est
égal à 5 100
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Planning Poker: outil d’estimation de User Story
 Eviter l'influence des leaders d'opinion
Recherche du consensus (de la propriété collective des estimations)
Les estimations collectives favorisent la transparence
1 Chacun prend un jeu de carte
 Permet l’échange et la clarification
2 Le PO lit l’élément à estimer
 Augmente la précision en incluant toutes les perspectives
 Créé de l’engagement 3 Les estimateurs visent une carte
4 Au signal les cartes sont retournées
5 On discute les différences

101
© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ 6 On réestime si besoin 08/02/2022
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Product Owner Development Team (DT)
Premier tour
Second tour
102
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Le planning poker pourquoi ça marche?
− Ceux qui estiment font le travail
− Les rounds forcent les discussions
− C’est marrant!
− Tout le monde progresse
 On estime d’abord les stories en points relatifs
− Abstraction de qui ou quand
− C’est un travail d’équipe (juniors et seniors ensemble)
 On regarde le passé pour savoir combien de points sont produits en moyenne par sprint
 On améliore empiriquement nos estimations 103
- Définition de Scrum - Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Critères d’acceptation de User Story
Les critères d’acceptation complètent la User Story en décrivant la manière dont la fonctionnalité sera
utilisée en rendant le récit testable et garantissent qu’elle peut être montrée aux utilisateurs et aux
autres parties prenantes
• Étant donnée que « Contexte » ● Lorsque/Quand je « Action » ● Alors « Conséquence»
Étant donnée que je suis sur la page de connexion, lorsque je clique sur « mot de passe oublié »,
alors, je suis rédigé vers la page de réinitialisation du mot de passe
Étant donnée que je suis sur la page « réinitialiser mon mot de passe », lorsque je rentre et que je
valide mon identifiant, alors, une vérification de mon identifiant m’informe si oui ou non il existe
Étant donnée que mon e-mail existe, Lorsque je valide mon identifiant, alors, je reçois par sms mon
nouveau mot de passe
104
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Critères d’acceptation de User Story
Autres Exemples
105
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Ce qu’on doit créer
106
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Ce qu’on doit créer: Exemple
Epic est « l’authentification de l’utilisateur »
User stories:
− Processus du Mot de passe oublié
− Verrouiller le compte après trop de tentatives infructueuses
− Écran de connexion utilisateur
o Tâches:
− Conception de la page de connexion
− Couper les icônes et les images SVG
− Implémenter la page de connexion HTML/CSS/JS
− Créer des scripts SQL pour créer des tables
− Créer une API de service Web pour les informations utilisateurs 107
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
108
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

109
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

110
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 Le Product Backlog est une liste ordonnée et émergente de fonctionnalités attendues (user stories)
sur le produit
 Les éléments du Product Backlog (tâches) qui sont susceptibles d’être réalisés dans une seule itération
(Sprint) par le Scrum Team sont classées dans un sprint backlog
 Processus contenu comprenant:
− Ajout, modification, suppression d ’éléments
− Priorisation (plus important en haut)
− Les éléments hautement prioritaires sont décomposés et raffinés en vue de la réunion du planning du sprint
 Processus collaboratif:
− Toute l’équipe Scrum y participe
− Communication en face-à face plutôt qu’au travers de documents
 Responsabilité du Product Owner 111
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
 Décrire les éléments
 Affiner les Epics et Macro user
 Prioriser le Product Backlog
 Préparation pour le Sprint Planning
 Estimation des éléments
Remis à jour à chaque Sprint, au fil de l’eau (Raffinement de Backlog (10%))
112
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Qualités du Product Backlog
D E E P
Détaillée Estimé Emergent Priorisé
113
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Ce qu’il faut faire
 Prioriser le Product Backlog
 Cultiver le Backlog : il évolue dans le temps, il faudra le mettre à jour à chaque Sprint, au fil de
l’eau (Raffinement de Backlog (10%))
 Partager le backlog avec toute l'équipe
 Surveiller la taille du backlog : ne pas avoir plus de 150 éléments à faire dans le backlog
 Affiner les Epics et Macro user
 Estimer les éléments
Éviter
 D’avoir plusieurs backlog pour le même de produit
 De ne pas avoir de backlog
114
 De confondre le backlog de produit avec le backlog de sprint
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Artefact Scrum: Le Backlog du Sprint (1/5)
115
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Artefact Scrum: Le Backlog du Sprint
User Story 6
User Story 8 User Story 6
User Story 3 Tâche 1 Tâche 2 Tâche 3
User Story 2
User Story 8
User Story 4
Tâche 1 Tâche 2 Tâche 3
User Story 7
User Story 5 Sprint Backlog
User Story 1
Product Backlog
116
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
 Sous la responsabilité des Développeurs
 Le Sprint Backlog est composé de:
Pourquoi Comment
? Quoi ? ?
Objectif du Sprint Eléments du Product Plan d’action/de réalisation

Backlog sélectionnés User stories sélectionnées,
tâches, architecture, etc.
117

- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 C’est l’ensemble des éléments sélectionnés pour le
Sprint plus un plan évolutif de tous les travaux jugés
nécessaires par les Développeurs pour réaliser l’Objectif
du Sprint et livrer l’incrément du produit
 Il contient au moins une fonctionnalité utilisateur
 C’est une image en temps réel du travail que les
Développeurs prévoient d’accomplir durant le Sprint afin
d’atteindre l’Objectif du Sprint
 Il est mis à jour tout au long du Sprint selon ce qu’on en
apprend (Ajout/Suppression au fil de l’eau)
 Il doit être détaillé pour que les Développeurs puissent
inspecter leur progression durant le Daily Scrum
Seule l’équipe peut modifier le Sprint Backlog pendant le
118
sprint (négociation avec le PO)
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Engagement: Objectif du Sprint
 L'Objectif de Sprint est l’unique but du Sprint
 Bien que l'Objectif de Sprint soit un engagement fait par les Developers, il offre une certaine
flexibilité en termes de travail nécessaire pour atteindre cet objectif
 L'Objectif de Sprint crée également de la cohérence et du focus, tout en encourageant la Scrum

Team à travailler ensemble plutôt que sur des initiatives séparées
 L'Objectif de Sprint est créé pendant l'événement de Sprint Planning, puis ajouté au Sprint Backlog
 Lorsque les Developers travaillent pendant le Sprint, ils gardent l'Objectif de Sprint à l'esprit
119
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Artefacts Scrum: Backlog du Sprint VS Backlog du Sprint
120
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Artefact Scrum: Incrément
121
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 Durant chaque Sprint, l’équipe de développement réalise un incrément
de produit
 Un Incrément est une première étape concrète vers l'Objectif de Produit
 Chaque Incrément s'ajoute à tous les Incréments précédents et fait
l'objet d'une vérification approfondie, ce qui garantit que tous les
Incréments fonctionnent ensemble (formant un produit)
 Plusieurs Incréments peuvent être créés durant un Sprint. La somme des
Incréments est présentée lors de la Sprint Review, ce qui permet de
démontrer l’utilité de l'empirisme
 Un travail ne peut être considéré comme faisant partie d’un Incrément
que s’il satisfait à la « Définition de Fini/Terminé » (Definition of Done
en anglais)
 Doit être publiable, si le Product Owner le décide 122
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Engagement: Definition of Done (Définition de Fini)
 La Definition of Done (DOD) est une description formelle de l'état de

l'Increment lorsqu’il satisfait les mesures de qualité requises pour le produit
 C’est une liste de vérifications des tâches que l’équipe doit réaliser avec
succès avant de déclarer que la fonctionnalité est potentiellement livrable
 Toute le Scrum Team participe à sa construction et les Développeurs

doivent s’y conformer
 Dès qu’un élément du Product Backlog satisfait à la DOD, il se transforme

en Increment
 Si un élément du Product Backlog n’est pas conforme à la DOD, il ne peut

pas être publié ni même présenté lors de la Sprint Review. Il est alors
renvoyé au Product Backlog pour être pris en compte ultérieurement 123
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Engagement: Définition de Fini
La DOD définit pour chaque activité:
− La liste des critères
− La liste des choses à faire

− Qui définissent un état FINI et de qualité Livrable
 Non négociable!
 A faire:
− Pour chaque élément de Backlog
− Pour chaque Incrément
− Tout au long du Sprint 124
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènements Scrum
125
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènements Scrum
126
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les cérémonies et leur Timebox Sprint de 1 mois
3h
15 min
8h 4h
1 mois
127
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Sprint
128
-
Théorie de Scrum
Valeur Scrum
- Les Artefacts Scrum
- Les évènements Scrum
- Processus Scrum

 Les Sprints sont au cœur de Scrum, où les idées sont transformées en valeur
 Les Sprints sont des événements d’une durée fixe, de deux à quatre semaines, durant laquelle
un Incrément Produit « Fini » fonctionnel et potentiellement publiable est créé
 Les Sprints contiennent et consistent en
− Une planification du Sprint (Sprint Planning)
− Des mêlées quotidiennes (Daily Scrums)
− Des activités de développement
− Une revue de sprint (Sprint Review)
− Une rétrospective de Sprint (Sprint Retrospective)
 Un nouveau Sprint commence immédiatement après la fin du précédent

129
− Il n’y a pas de délai entre 2 Sprints
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 Chaque Sprint produit 1 incrément potentiellement utilisable « usable »
− La qualité ne doit pas décroitre
− Au moins une fonctionnalité de valeur au client
 Pas de Sprint non productif ou dont la finalité est détournée
− L’objectif de Sprint est fixe ne change pas au cours de Sprint même si son périmètre peut être
renégocier entre le Product Owner et les Développeurs
 Les objectifs de qualité sont maintenus; ils ne sont jamais revus à la baisse
 Le Product Backlog est affiné si nécessaire
 Un Sprint peut être annulé si l’Objectif de Sprint (Sprint Goal) devient obsolète
− Seul le Product Owner peut annuler un Sprint 130
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Pendant le Sprint
 Le Product Owner
− Travaille avec les utilisateurs /Clients

• Analyse des besoins et de leurs scénarios d’acceptations
131
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Pendant le Sprint: Raffinement de Product Backlog
 De nouveaux éléments peuvent émerger, il

faut les prioriser et les intégrer au Backlog
 Chaque élément peut être repriorisé à

chaque moment
 Les éléments peuvent être supprimés à

chaque moment
 Les éléments peuvent découpés/détaillés

en éléments plus petits
Product Backlog 132

-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Pendant le Sprint
 Le Product Owner
− Discute avec les développeurs
− Feedback sur le travail en cours
− Réponse aux questions
− Présentation de nouveaux éléments de Backlog
− Validation des items terminés
133
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Le Sprint Planning
134
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Sprint Planning Meeting

 Chaque Sprint débute par une réunion de
planification de Sprint durant laquelle les user
stories prioritaires sont étudiées en vue d’être
incluses dans le Sprint
Le Product Owner et l’équipe de

développement se réunissent et examinent le
Backlog du Produit afin de déterminer quelles
fonctionnalités sont prioritaires et lesquelles
sont à intégrer dans le prochain cycle
135
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
 Réunion de l’équipe : décisions collectives : toute la Scrum Team collabore pour établir un plan
destiné à atteindre un Objectif de Sprint
 Le Product Owner veille à ce que les items choisis représente l’Objectif de Produit
 Choisir des éléments du Backlog de produit pour mettre dans le Backlog du sprint
 Chaque élément est découpé en taches qui sont estimées en heures (max 2 jours)
 La conception de haut niveau est abordée
Les tâches ne sont pas nominatives
136
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Les questions à se poser
 Pourquoi ce Sprint est important?
− Le Product Owner veille à ce que les items choisis représente l’Objectif de Produit
 Que peut on faire durant ce Sprint?
− Le Product Owner collabore avec les Développeurs qui sélectionnent les items à inclure dans
le Sprint en cours
 Comment le travail choisi sera t-il réalisé?
− Les Développeurs s’organisent pour planifier le travail à faire pour produire un incrément qui
réponde à la Definiton Of Done
137
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Le Daily Scrum
138
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Daily Meeting

 Mêlée/Réunion quotidienne courte, limitée à 15 min (Max),
pour les Developers de la Scrum Team
 Est focalisé sur l’avancée vers le Sprint Goal
 Même lieu, mêmes heures
Les membres de l’équipe se retrouvent pour rendre compte

des progrès du projet et répondre aux questions suivantes:
1. Qu’ai-je fais hier?
2. Qu’ai-je prévu de faire aujourd’hui?
3. A quels blocages fais-je face en ce moment?
139
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Objectif: Inspecter la progression vers l'Objectif de Sprint et d'adapter le Sprint Backlog si nécessaire, en
ajustant les futurs travaux planifiés
− Produire un plan d’action pour la prochaine journée de travail
Seule les Developers sont requis de manière active
Le Scrum Master doit s’assurer de son existence
Le PO peut être présent pour écouter (seulement)
 Améliore la communication
 Aide à identifier les obstacles et d’ajuster le plan
Favorise les prises de décisions rapides (et élimine la nécessité de faire d'autres réunions)
140
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

Management du Sprint Backlog
Le Burndown Chart
 Le Burndown chart (si utilisé):
− Un pratique pour évaluer la progression vers l’Objectif de Produit
− Est sous la responsabilité des Développeurs
− Dans tous les cas, les Développeurs suivent et mesurent leur reste à faire quotidiennement
141
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Sprint Review Meeting
142
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 La Sprint Review est l'avant‐dernier événement du Sprint et se limite dans le temps à un maximum
de quatre heures pour un Sprint d'un mois.
 Au cours de cette réunion, qui fait partie du processus de démonstration et validation du sprint, la
Scrum Team présente les résultats de son travail aux principales parties prenantes et les progressions
vers l'Objectif de Produit sont discutées
 La Scrum Team et les parties prenantes passent en revue ce qui a été accompli durant le Sprint et ce
qui a changé dans leur environnement
 Sur la base de ces informations, les participants collaborent sur les prochains travaux qui pourraient
être faits et sur les décisions à prendre pour optimiser la valeur
Le Product Owner compare le produit (ou incrément de produit) aux critères d’acceptation et
accepte ou rejette les user stories réalisées
143
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 A chaque fin de Sprint
− Inspection du résultat basé sur l’observation d’un incrément « potentiellement livrable »
• Respecte la « Definition of Done »
• Réalisée par l’équipe
− Participants:
• L’équipe Scrum et les principales parties prenantes
• Le Product Owner est l’organisateur
− Objectif
• Comment avance t’on vers l’objectif de produit
• Ce qui a été fait Démo/Feedback
• Possibilité de décider pour la suite
• Mise à jour potentielle du Product Backlog
144
• Discuter et déterminer les adaptations futures
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 Rôles
− Le PO:
• Invite (les parties prenantes), anime
• Indique quels éléments du Backlog Produit ont été « Finis » et ceux qui n'ont pas été « Finis »
− Les parties-prenantes
• Donnent du Feedback
• Font part de leurs évolutions de contexte
• Disent quoi faire après
− La Development Team
• Présente l’incrément manipulé (le travail « Fini ») et répond aux questions sur l’incrément
• Discute de ce qui s’est bien passé pendant le Sprint, quels problèmes ont été rencontrés, et
comment ces problèmes ont été résolus 145
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum

 Résultat :
• La revue des délais, budget, fonctionnalités potentielles et conditions de marché pour les
prochaines versions prévues de la fonctionnalité du produit
• Un Backlog Produit révisé qui définit les éléments probables pour le prochain Sprint
• Le Backlog Produit peut également être ajusté pour répondre aux nouvelles opportunités métiers
146
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Sprint Retropective Meeting

 Inspection de la Scrum Team
• Personnes/ stratégies d’interactions/ processus suivis/
Outils employés/Definition of Done/….
 A chaque fin de Sprint, la Scrum Team discute:
• Ce qui a bien et moins bien marché
• Des problèmes rencontrés
• La manière dont ces problèmes ont été (ou n'ont pas été) résolus
• Ce que l’ on pourra améliorer les sprints à venir
• Ce que l’ on arrête de faire
 Objectif: Réfléchir à des pistes pour améliorer/augmenter la qualité et l’efficacité
− Les améliorations les plus impactantes sont abordées aussi vite que possible
• Elles peuvent même être ajoutées au Sprint Backlog pour le prochain Sprint 147
− C’est le bon moment pour durcir le « Définition de fini »
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Evènement Scrum: Sprint Retropective Meeting

L’amélioration continue pour créer de la valeur
 Produire de la valeur c’est aussi arrêter de produire de la non valeur
 L’amélioration continue est source de création de valeur sur :
• Les personnes et les relations
• Les processus de production
• Les outils de production
• Les méthodes
 En amenant:
• De la simplification
• Moins de gaspillages
• De l’innovation
• Plus d’efficacité
• Plus d’efficience 148
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
The Difference Between Sprint Review & Sprint Retrospective

Sprint Review Sprint Retrospective
When does it take place? On the last day of the Sprint After the Sprint Review, and typically on the same day
Product owner
Product Owner
Scrum Master
Who particpates? Scrum Master
Development Team
Development Team
Stakeholders
Is about demoing the work that was just Is about identifying areas of improvement to make
completed the next sprint better
Review delivered Increment Identify what went right
What are the goals?
Update the Product Backlog Identify what can be improved
Prep for the next sprint planning Improve culture
Re-energize the team
149
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Modèle d’un Sprint Scrum
150
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les responsables
151
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Les événements
152
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Durée des événements
153
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Amélioration continue
154
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
155
- Équipe Scrum
-
Théorie de Scrum
Valeur Scrum
- Processus Scrum
Principe Agile : Simplicité

Management Visuel
156
QUIZ TIME

Parmi les contraintes d'un projet, il y a _____.
1. les fondations
2. les réunions
3. les ressources
4. les livrables
158
Une question de la gestion de projet est : _____ ?
1. comment préparer le projet suivant
2. comment reconnaître la fin d'un projet
3. comment définir le sens du projet
4. comment diminuer les coûts d'un projet
159
Quelle est la compétence la plus importante pour être
chef de projet ?
1. La capacité à diriger.
2. Avoir de bonnes notions de statistiques.
3. Connaître un langage de programmation.
4. Savoir écrire une documentation fonctionnelle.
160
La phase de mise en œuvre du projet comporte une
phase _____.
1. de mise en place
2. de cycle agile
3. de surveillance et de contrôle
4. de clôture
161
Lorsque les buts sont clairs et les technologies connues,
vous pouvez utiliser une gestion de projet _____.
1. en cascade
2. rétroactive
3. spiralaire
4. ascendante
162
Les buts sont plus précis que les objectifs.
1. TRUE
2. FALSE
163
La dernière phase de la mise en place est _____.
1. l'obtention de l'approbation
2. la réunion de kick-off
3. l'écriture d'une synthèse
4. l'embauche des ressources
164
L'énoncé du problème _____.
1. doit nommer les ressources
2. doit être formulé positivement
3. peut tenir en une phrase
4. doit faire environ une page
165
Pour définir les exigences, vous pouvez _____.
1. ajouter toutes les exigences possibles
2. vous baser sur un livre du marché
3. varier les objectifs
4. établir un prototype
166
Vos livrables doivent être _____.
1. décomposés en parties raisonnables
2. les plus complets possibles
3. réalisés seulement au début du projet
4. réalisés seulement à la fin du projet
167
Lequel de ces acteurs n'est pas une partie prenante du
projet ?
1. Les clients des clients du projet.
2. Les sponsors.
3. Les membres de l'équipe.
4. Les cadres fonctionnels.
168
Correct
•FAUX
C'est pendant la planification qu'on détermine le coût du

projet.
1. VRAI
2. FAUX
169
Comment peut-on définir la gestion de projet agile ?
1. Maîtriser le tryptique coût, qualité et délais.
2. Maîtriser l'équilibre énergie, règles, délais et périmètre.
3. Maîtriser l'équilibre coût, qualité, délais et périmètre.
4. Maîtriser le tryptique énergie, règles et délais.
170
Si vous souhaitez gérer un projet de façon agile, qu'est-il
important de faire ?
1. D'enlever tout contrôle sur le projet.
2. D'intégrer l'incertitude comme une contrainte du projet.
3. D'anticiper et contrôler les écarts.
4. De concevoir le projet en un enchaînement d'actions.
171
Si vous souhaitez organiser un team building pour vos
employés de manière agile, quelle approche suivante n'est
PAS conseillée ?
1. Cadrer en détails les composantes du team building.
2. Fixer les coûts et délais attendus.
3. Prendre les décisions de manière collégiale.
4. Demander à valider chaque étape.
172
Comment se décompose un cycle ?
1. En 3 phases : une phase d'amorçage, une phase de conduite et une d'adaptation
2. En 5 phases : phase de lancement, d'amorçage, de conduite, d'adaptation et de

clôture
3. En 2 phases : une phase de conduite et une phase d'adaptation
4. En 4 phases : une phase d'amorçage, une phase de conduite, une d'adaptation et

une de clôture
173
Comment peut-on résumer la phase de lancement
d'un projet ?
1. Quoi, Qui, Quand, Comment
2. Pourquoi, Qui, Quand, Comment
3. Pourquoi, Qui, Quand, Combien
4. Quoi, Qui, Quand, Combien
174
Qu'est-ce que définir l'objectif d'itération ?
1. Faire une liste des choses attendue, et en déduire un objectif.
2. Découper les étapes de réalisation une à une, et définir la première comme le

premier objectif.
3. Prendre du recul sur toutes les choses à faire avec un maximum d'informations
pour qu'il en découle un objectif.
4. Se demander quelle est la prochaine étape pour faire avancer le projet dans le
temps imparti d'un cycle, et la définir comme objectif.
175
Si votre équipe comprend 6 personnes et que vous
êtes dans la phase de conduite d'itération, combien
de temps doit durer vos réunions quotidiennes ?
1. Environ 30 minutes
2. Maximum 1 heure
3. Maximum 25 minutes
4. Environ 10 minutes
176
Quelle est la partie la plus importante de la phase
d'adaptation ?
1. Cadrer la réunion de rétrospection.
2. Avoir le feedback du client.
3. Montrer les avancées techniques au client.
4. La préparation des éléments à présenter.
177
Que doit permettre la phase de clôture d'un projet ?
1. Valoriser ce qui a été positif durant le projet.
2. Savoir si le projet est une réussite ou un échec.
3. Faire le point sur tout ce qui a été appris au cours du projet.
4. Toutes les réponses sont correctes.
178
La construction d'une maison peut être éligible à une
méthode agile du point de vue _____.
1. du constructeur
2. des propriétaires
3. de l'architecte
4. du maçon
179
Quand est-il préférable d'éviter la méthode agile
pour un projet ?
1. Lorsque la confiance fait défaut au sein de vos équipes.
2. Lorsque votre entreprise est en difficulté financière.
3. Lorsque vos clients sont procéduriers.
180
En règle générale, combien de temps dure une
itération ?
1. Entre 3 et 6 mois
2. Entre 1 et 2 semaines
3. Entre 1 et 2 mois
4. Entre 2 et 4 semaines
181
Comment bien cadrer un projet au démarrage ?
1. En définissant les éléments caractéristiques du projet et les règles de

fonctionnement de l'équipe y compris le planning des vacances et la température
des bureaux par exemple.
2. En établissant les règles de fonctionnement de l'équipe et les éléments

caractéristiques du projet sans rentrer dans les détails.
3. En définissant les objectifs et les règles sans donner de budget ou de date, ceux-
ci évoluant au cours du projet.
4. En établissant une fiche technique du projet figée qui servira de référence tout au
long du projet. 182
Dans quelle situation est-il préférable de ne PAS
s'occuper des tâches risquées en premier ?
1. Lorsque vous êtes habitués à travailler avec des itérations longues.
2. Lorsque l'équipe n'est pas habituée à la méthode agile.
3. Lorsque vous êtes habitués à travailler avec des itérations courtes.
4. Lorsque l'équipe est expérimentée.
183
Quels outils choisir pour bien démarrer son projet
agile ?
1. Des outils agiles recommandés par les leaders du marché.
2. Les outils déjà en place dans votre entreprise.
3. Des outils digitaux permettant d'être utilisés en télétravail.
4. Les outils les plus simples possibles.
184
Dans une approche agile, le besoin exprimé au
commencement _____.
1. est un prérequis du projet
2. diverge plus ou moins du besoin réel
3. est appelé besoin réel
4. est appelé besoin non fonctionnel
185
Comment réussir ses réunions debout ?
1. Changer d'horaire régulièrement pour trouver le plus efficace.
2. Il s'agit avant tout de partager sa progression avec l'équipe.
3. Il s'agit avant tout de trouver des solutions aux points bloquants.
4. Il s'agit de faire un compte-rendu des avancées au chef de projet.
186
Que ne peut-on PAS modifier dans un plan
d'itérations ?
1. Ajouter des fonctionnalités à une itération.
2. Supprimer des fonctionnalités à une itération.
3. Inverser des itérations.
4. Modifier l'itération en cours.
187
Qu'est-ce qu'on peut dire à sa direction afin de la
fédérer autour d'un projet agile ?
1. Qu'on peut très bien avoir une relation contractuelle souple et s'organiser en
interne de manière rigide.
2. Que l'autonomie et la confiance données à l'équipe sont enthousiasmantes et

donnent la plupart du temps envie de se dépasser.
3. Qu'il est possible d'avoir un contrôle total sur le projet même avec une méthode
agile.
4. Qu'en cas de dérapage, c'est seulement l'équipe qui sera jugée coupable et pas la
direction.
188
Que pouvez-vous faire pour perfectionner votre
démarche agile ?
1. Essayer de la mettre en place.
3. Discuter avec d'autres agilistes pour échanger les points de vue.
4. Continuer de se former en regardant d'autres formations sur le sujet.
189
Dans un projet, la contrainte technique _____ que le
souhait du client
1. peut être des fois plus importante
2. est toujours moins importante
3. est toujours plus importante
4. peut être des fois moins importante
190
Quel est le rôle qui se rapproche le plus d'un coach ?
1. Celui qui mène l'équipe vers le succès.
2. Celui qui est le chef de projet.
3. Celui qui accompagne l'équipe dans l'adoption de l'agilité.
4. Celui qui pilote l'équipe par la définition du travail à faire.
191
Quelle phase ne doit PAS être négligée pour que
l'équipe comprenne vraiment bien la valeur attendue
par le client ?
1. La phase de lancement
2. La phase d'amorçage
3. La phase de conduite
4. La phase d'adaptation
192
Quels sont les 3 piliers de l’empirisme
1. Inspection Adaptation Réaction
2. Inspection Transparence Acceptation
3. Transparence Inspection Adaptation
4. Transparence Itération Adaptation
193
La Scrum Team est composée de:
1. Scrum Master, Stakeholder, Product Owner, Development Team
2. Scrum Master, Product Owner, Development Team
3. Scrum Master, Product Owner, Chef de projet, Development Team
4. Scrum Master, Development Team, Product Owner, Stakeholder,

Chef de projet
194
Quels sont les évènements formels pour inspecter et adapter:
1. Sprint Planning Meeting, Sprint Review Meeting, Sprint Backlog

Review Meeting, Daily Scrum Meeting
2. Daily Scrum Meeting, Sprint Planning Meeting, Sprint Backlog

Review Meeting, Sprint Review Meeting
3. Sprint retrospective Meeting, Sprint Review Meeting, Sprint

Planning Meeting, Daily Scrum Meeting
4. Sprint Review Meeting, Sprint retrospective Meeting, Sprint Done

Meeting, Daily Planning Meeting
195
Quels « Timeboxes » proposés par Scrum pour chaque
événement formel?
1. Sprint Planning Meeting 4h pour un Sprint de 1 mois et

proportionnellement moins selon la durée du Sprint
2. Scrum Review 3h pour un Sprint de 1 mois et proprtionnellement moins

selon la durée du Sprint
3. Sprint de 3 à 4 semaines
4. Daily Scrum Meeting 15 minutes peu n’importe la durée du Sprint
196
Quel est l’objectif principal du Sprint Retrospective?
1. Pratiquer le refactoring du code
2. Trouver des ameliorations pour l’équipe Scrum et les planifier pour

le prochain Sprint
3. Intégrer les différents increments en prévision de la release
4. Mettre à jour les différents artéfacts pour le Sprint suivant
197
La durée des sprints va de 2 à _____ semaines.
1. 12
2. 4
3. 48
4. 8
198
Why is a backlog refinement event usually held around
midpoint of the Sprint?
1. to evaluate what new items have come up
2. to compare user stories to each other
3. to update the team's vision
4. to create team norms
199
The Scrum Team must always work their stories in priority
order
1. False
2. True
200
What do Scrum Teams use to visually represent their project?
1. information heaters
2. Status charts
3. Progress simulators
4. Information radiators
201
All of the following are TRUE about the Daily Scrum except _____.
1. everyone stands up
2. it lasts 30 minutes
3. everyone answers the same 3 questions
4. it lasts 15 minutes
202
In order for Scrum to work, what does the Daily Scrum meeting
rely on?
1. time, effort, and goals
2. collaboration and communication
3. questions, answers, and results
4. creativity, delivery, and expectations
203
Before verifying the team has the capacity to complete the work,
what do you need to know?
1. the information on the Scrum Board
2. the Chaotic Domain
3. hours for all the planned work in the Sprint
4. your Story Point
204
Which scenario is an example of an information radiator?
1. getting specific data from point A to point B
2. determining the velocity of the Sprint
3. hosting a Sprint Review
4. posting a burn-down chart on the wall
205
The PO can add a new story to a Sprint that the Team is
currently in
1. FALSE
2. TRUE
206
Which statement best describes a Product Owner's
responsibility?
1. Optimizing the value of the work the Scrum Team does.
2. Directing the Developers
3. Managing the project and ensuring that the work meets the
commitments to the stakeholders.
4. Keeping stakeholders from distracting the Developers.
207
The Product Owner determines how many Product Backlog
items the Developers select for a Sprint
1. True, accordingly to what was committed to the stakeholders.
2. True, but only after confi rmation by the resource manager that
the Team has enough capacity.
3. True.
4. False, the Scrum Master does that.
5. False.
6. False, capacity and commitment are the Project manager's

208
responsibility.
Some Developers select a set of Product Backlog items for a Sprint Backlog
with the intent to get the selected items "Done" by the end of the Sprint.
Which three phrases best describe the purpose of a definition of "Done"?
Choose 3 answers
1. It defines what it takes for an increment to be usable and valuable.
2. It guides the Developers in creating a forecast at the Sprint
Planning.
3. It creates transparency over the work inspected at the Sprint
Review.
4. It provides a template for elements that need to be included in the
technical documentation.
5. It tracks the percent completeness of a Product Backlog item.
209
6. It controls whether the Developers have performed their tasks.
When does the second Sprint start?
1. After the customer completes acceptance testing of the first

Sprint.
2. Immediately after the first Sprint.
3. After the Product Backlog for the second Sprint has been selected.
4. Once the architectural changes for the second Sprint have been
approved by the senior architect.
210
How much time is required after a Sprint to prepare for the
next Sprint?
1. None. A new Sprint starts immediately following the end of the

previous Sprint.
2. The break between Sprints is time-boxed to 1 week for 30 day

Sprints, and usually less for shorter sprints.
3. Enough time for the requirements for the next Sprint to be

determined and documented.
4. Enough time for the Development team to fi nish the testing from
the last Sprint.
5. All of the above are allowed depending on the situation. 211

Which approach is best for Scrum Teams in order to produce
valuable Increments?
(choose the best answer)
1. Each Scrum Team works on an independent set of components.
2. Each Scrum Member works only as an independent layer of the

system.
3. Each Developer works on the component where they feel that

they can contribute.
4. Each Scrum Team is accountable for developing functionality from

beginning to end.
212
You are the Scrum Master of a new, to be developed product. Developement
is going torequire 45 people. What is a good fi rst question for you to suggest
the group thinks about when forming into teams ?
1. Who are the subject matter experts on each teams?
2. What if the right mixture of senior and junior people on each

team?
3. Who are going to be the team leads?
4. How will we make sure all teams have the right amount of
expertise.
213
A Developer takes the Scrum Master aside to express his concerns
about data security issues. What should the Scrum Master Do ?
1. Add security to the definition of "Done".
2. Create a Product Backlog item for security.
3. Go check with the testers.
4. Tell the Product Owner to stop further development of features

until the issues are fixed
5. Ask the Developer to share the issue with the team as soon as
possible
214
A product Increment must be released to production at the
end of each Sprint.
1. TRUE
2. FALSE
215
Who is responsible for clearly expressing Product Backlog
Items?
1. The Product Owner.
2. The Scrum Master.
3. The Scrum Master, or the Scrum Master may have the Developers
do it.
4. The business analyst who represents the Product Owner in the

Development Team.
216
Which three purposes does the defi nition of "Done" serve?
Choose 3 answers.
1. Describe the purpose, objective, and time-box of each Scrum

event.
2. Increase transparency.
3. Guide the Developers on how many Product Backlog items to

select for the Sprint.
4. Describe the work that must be done before the Sprint is allowed
to end.
5. Create a shared understanding of when work is complete. 217

Which three purposes does the defi nition of "Done" serve?
Choose 3 answers.
1. Describe the purpose, objective, and time-box of each Scrum event.
2. Increase transparency.
3. Guide the Developers on how many Product Backlog items to select

for the Sprint.
4. Describe the work that must be done before the Sprint is allowed to
end.
5. Create a shared understanding of when work is complete.

218
Which are NOT appropriate topics for discussion in a Sprint
Retrospective?
Choose 2 answers.
1. How the team collaborates
2. The order of items in the Product Backlog.
3. Documenting acceptance criteria for items in the next Sprint
4. Identifying high priority process improvements for the next Sprint
219
A Scrum Team is required to deliver a done Increment by the end
of a Sprint. Select two statements that explain what done means.
Choose 2 answers.
1. No work left from the definition of Done
2. Ready for integration
3. All work the Development Team is willing to do
4. Whatever the Product Owner defines as quality
5. Ready to be released to end users
220
When must the Product Owner be present at the Daily Scrum?
(Choose the best answer)
1. When the Scrum Master asks them to attend.
2. When the Product Owner is actively working on items from the

Sprint Backlog.
3. When they need to represent the stakeholders' point of view.
4. When there are impediments to discuss.
221
Who has the final say on the order of the Product Backlog?
1. The Developers
2. The Stakeholders
3. The CEO
4. The Product Owner
5. The Scrum Master
222
Which Scrum Values are exhibited by not building Product
Backlog items that have low business value?
(Choose three answers.)
1. Respect
2. Focus
3. Earned value
4. Courage
223
As the Sprint Planning meeting progresses, the workload is getting to
be greater than the Developers' capacity. Which two actions make the
most sense to do?
1. Start the Sprint and recruit additional Developers.
2. Potentially remove or change selected Product Backlog items.
3. Cancel the Sprint.
4. Ask the Developers to work overtime for this Sprint and promise
that it won't happen again.
5. The Developers ensure that the Product Owner is aware, starts the
Sprint and monitors progress.
224
What are two effective ways for a Scrum Team to ensure
security concerns are satisfied?
Choose 2 answers.
1. Have the Scrum Team create Product Backlog items for each concern.
2. Delegate the work to the concerned department.
3. Postpone the work until a specialist can perform a security audit and
create a list of security-related Product Backlog items.
4. Add security concerns to the definition of "Done".
5. Add a Sprint to specifically resolve all security concerns.

225
What is the time-box for the Sprint Planning meeting?
1. Whenever it is done
2. Monthly
3. 4 Hours for a monthly Sprint
4. 8 Hours for a monthly Sprint
226
Who should make sure everyone on the Scrum Team does
his or her tasks for the Sprint?
1. The Scrum Master
2. The Scrum Team
3. The Project Manager
5. All the above
227
During a Sprint Retrospective, for what is the Product
Owner responsible?
1. The Product Owner should not take part in Sprint Retrospectives.
2. Capturing requirements for the Product Backlog.
3. Participating as a Scrum Team member.
4. Summarizing and reporting the discussions to the stakeholders that

he/she represents in the Scrum Team.
228
As the Developers start work during the Sprint, they realize they
have selected too much work to finish in the Sprint. What should
they do?
1. Reduce the definition of "Done" and get all of the Product Backlog
items "done" by the new definition.
2. Inform the Product Owner at the Sprint Review, but prior to the
demonstration.
3. As soon as possible in the Sprint, work with the Product Owner to

remove some work or Product Backlog items.
4. Find another Scrum Team to give the excess work to.

229
True or False:
The purpose of a Sprint is to
produce a valuable and useful Increment of working product.
1. TRUE
2. FALSE
230
The Sprint Review is mainly an inspect and adapt opportunity
for which group?
1. The Product Owner and management
2. The Developers and management
3. The Product Owner and Developers
4. The Product Owner and stakeholders
5. The Developers and stakeholders
6. The Scrum Team and stakeholders

231
Which statement best describes Scrum?
1. A framework to generate value through adaptative solutions for

complex problems.
2. A complete methodology that defines how to develop software.
3. A defined and predictive process that conforms to the principles of

Scientific Management
4. A cookbook that defines best practices for software development.
232
Which are appropriate topics for discussion in a Sprint
Retrospective?
(Choose the best three answers)
1. Arranging the Sprint Backlog for the next Sprint.
2. How the Scrum Team does its work.
3. Definition of Done.
4. The value of work currently represented in the Product Backlog
5. Team relations. <<<<
233
Sprint burndown charts are an efficient tracking tool
because they show:
1. How much eff ort has gone into a Sprint.
2. How many Product Backlog items remain.
3. Estimated work remaining for the Sprint.
4. How many hours have been worked by each Development Team

member.
234
The Product Owner is not collaborating with the Developers during the
Sprint. What are two valuable actions for a Scrum Master to take?
Choose 2 answers.
1. Inform the Product Owners functional manager.
2. Nominate a proxy Product Owner.
3. Stop the Sprint, send the Product Owner to a course and restart.
4. Bring up the problem in the Sprint Retrospective.
5. Coach the Product Owner in the values of Scrum and incremental delivery.
235
Who is responsible for managing the progress of work during
a Sprint?
1. The Developers
2. The Scrum Master
236
An organization has decided to adopt Scrum, but management wants to
change the terminology to fi t with terminology already used. What will
likely happen if this is done?
Choose the best answer.
1. Without a new vocabulary as a reminder of the change, very little change

may actually happen.
2. The organization may not understand what has changed within Scrum and
the benefits of Scrum may be lost.
3. Management may feel less anxious.
4. All answer apply.
237
What enhances the transparency of a increment?
1. Keeping track of and estimating all undone work to be completed in a

separate Sprint
2. Updating Sprint tasks properly in the electronic tracking tool
3. Doing all work needed to meet he definition of "done"
4. Reporting Sprint progress to the stakeholders daily
238
Which of the following might the Scrum Team discuss during
a Sprint Retrospective?
1. Methods of communication.
2. The way the Scrum Team does Sprint Planning.
3. Skills needed to improve the Developers ability to deliver.
4. The Definition of Done.
5. All of the above.
239
The Developers ask their product Owner to re-order the Product Backlog. The team is
waiting for an external supplier to deliver a specific software component. Without that
component there won't be enough work in the next sprint to occupy the full team. The
product Owner asks the ScrumMaster for help. What would be good advice to give the
Product Owner ?
1. Remind the Product Owner that their primary concern is the flow of value
reflected in the ordering of the Product Backlog
2. Tell the Product Owner to re-order the Product Backlog so the work
involving the external component can be planned in a separate sprint
3. Tell the Product Owner that the Product Backlog should be ordered to
maximize utilization of the Developers.
240
Why does a Scrum Team need a Sprint Goal?
1. A Sprint Goal only gives purpose to Sprint 0.
2. A Sprint Goal ensures that all of the Product Backlog items selected for the
Sprint are implemented.
3. Sprint Goals are not valuable. Everything is known from the Product
Backlog.
4. The Scrum Team is more focused with a common yet specific goal.
241
What is included in the Sprint Backlog?
1. Tests
2. User Stories
3. Use Cases
4. Tasks
5. Any of the above (or others) which are a decomposition of the selected
Product Backlog items
242
In accordance with Scrum theory, how should a group of
100 people be divided into multiple Scrum Teams?
1. Check with the allocation department to see who has worked together
before and make these the first teams.
2. Understanding the product, the product vision and the rules of the Scrum
framework, the group divides itself into teams.
3. It doesn't really matter because you can rotate the teams every Sprint to
spread knowledge.
4. Create a matrix of skills, seniority, and level of experience to assign people

to teams. 243
What are three benefits of self-management?
Choose 3 answers.
1. Increased accuracy of estimates
2. Increased commitment
3. Increased rule compliance
4. Increased self-accountability
5. Increased creativity
244
Who creates the definition of "Done"?
1. If it is not an organizational standard, the Scrum Team must create a Definition

of Done appropriate for the product.
2. The Scrum Team, in a collaborative eff ort where the result is the common
denominator of all members’ definitions
3. The Product Owner as he/she is responsible for the product's success
4. The Scrum Master as he/she is responsible for the productivity
245
Who determines how work is performed during the
Sprint?
1. The Developers
2. Subject matter experts
3. Developers managers
4. The Scrum Master
5. Architects
246
What is the best way to divide a group of 120 Developers
into teams?
Choose 3 answers
1. Let the HR department run personality tests and decide which groups are well
suited
2. The Product Owner explains the product, the features and the business context
3. The Scrum Master reminds the rules of multiple teams Scrum
4. The Management decide, bases on people skills
5. There is no need for several Scrum Teams
6. Developers decide 247

Who is accountable for creating the most valuable
increment each sprint?
1. The CEO
2. The Scrum Team
3. The Developers
5. The Scrum Master

248
The Product Owner's authority to change and update the
Product Backlog is unlimited, except for:
1. Decisions by the CFO, the CEO or the board of directors.
2. Nothing. The entire organization must respect a Product Owner's decisions.
3. Decisions by the chief program manager.
4. Technical and architectural work that needs to be done first, as indicated by the
chief enterprise architect.
5. High impact changes that have not been approved by the change request
board.
249
6. Work for which impediments exist that the Scrum Master still needs to resolve.
In order to make investment decisions, the Product Owner is likely
to look at the Total Cost of Ownership (TCO) of the product being
built. What costs will a Product Owner take into account?
1. The money spent on development of the product, often a fixed cost per Sprint
multiplied by the Sprints required
2. All investments required to conceive, develop, operate and maintain the

product
3. The accumulated cost over the earned value of the product
250
What does it mean for a Scrum Team to be cross-functional?
1. The Scrum Team includes cross-skilled individuals who are able to contribute to
do what is necessary to deliver an increment of software.
2. The Scrum Team includes not only developers but also business analysts,
architects, developers and testers.
3. The Scrum Team is a virtual team drawing from separate teams of business
analysts, architects, developers and testers.
251
True or False: Product Owners must create clear and unambiguous
acceptance criteria foreach Product Backlog item before it may be
selected in Sprint Planning
1. TRUE
2. FALSE
252
True or False: There are multiple teams working on one product.
Each team should have a separate Product Owner.
1. TRUE
2. FALSE
253
What variables should a Product Owner consider when
ordering the Product Backlog?
1. Effort first, then value
2. Development cohesion as indicated by the Scrum Team
3. Lowest development cost in order to maximize ROI
4. The availability of resources and skills for implementation
5. Whatever is most appropriate for the Product Owner to achieve the product's
goals and to optimize the value received
254
Which of the following are true about the length of the
Sprint? (Choose 2 answers.)
1. All Sprints must be 1 month or less.

2. It is best to have Sprints of consistent length throughout a development eff ort.
3. Sprint length is determined during Sprint Planning, and should be long enough
to make sure the Development Team can deliver what is to be accomplished in
the upcoming Sprint.
4. Sprint length is determined during Sprint Planning, and should hold the time it
will take to code the planned features in the upcoming Sprint, but does not
include time for any testing.
5. The length of the Sprint should be proportional to the work that is done in
255
between Sprints.
How does an organization know that a product built through
Scrum is successful?
1. By measuring that velocity has increased since the last release.
2. By the Product Owner and stakeholders accepting the Increment at the Sprint
Review.
3. By releasing frequently, and measuring the value customers/users experience.
4. By measuring the actual time spent on development versus the time estimated
for development.
256
True or False: To get started in terms of what to build, Scrum
requires no more than a Product Owner with enough solid ideas for
a first Sprint, Developers to implement those ideas and a Scrum
Master to help guide the process.
1. TRUE
2. FALSE
257
True or False: A Product Owner can measure success by an increase
in the team's velocity.
1. TRUE
2. FALSE
258
True or False: A first Sprint can start before the
Product Owner has a complete and exhaustive Product
Backlog in place.
1. TRUE
2. FALSE
259
Of the following choices, what is the most effective way a
Scrum Master can keep a Scrum Team working at its highest
level of productivity?
1. Facilitate Scrum Team decisions and remove impediments.
2. Ensure the meetings start and end at the proper time.
3. Prevent changes to the backlogs once the Sprint begins.
4. Keep high value features high in the Product Backlog.
260
Scrum is based on empiricism. All Scrum artifacts must be
transparent to ensure sufficient accuracy of inspection. Which two
measures ensure that the Product Backlog is transparent?
(choose the best two answers)
1. The Product Backlog is available to all stakeholders.
2. The Product Backlog only has work for the next 2 Sprints.
3. Each Product Backlog item has a MoSCoW priority.
4. The Product Backlog is managed using a web-based tool.
5. The Product Backlog is ordered.

261
In order to maximize the value of the product, a Product
Owner needs awareness of the following:
1. Competitive research
2. Customer feedback
3. Product vision
4. Forecasting & feasibility.
5. All of the above
6. None of the above 262

Multiple Scrum Teams creating the same product work from
the same Product Backlog.
1. TRUE
2. FALSE
263
Who should make sure everyone does his or her tasks for the
Sprint?
1. The Project Manager
3. The Scrum Master
4. The Developers
5. All of the above
264
Which three of the following are feedback loops in Scrum?
Choose 3 answers
1. Daily Scrum
2. Sprint Review
3. Release Planning
4. Sprint Retrospective
5. Refinement Meeting
265
How often should customer satisfaction be measured?
1. Quarterly
2. Annually
3. Daily
4. Frequently
266
The Product Backlog is ordered by:
1. Size, where small items are at the top and large items are at the bottom.
2. Risk, where safer items are at the top, and riskier items are at the bottom.
3. Items are randomly arranged.
4. Importance, where the most important items are at the top at all times.
267
True or False: The Product Owner should have a complete and
exhaustive Product Backlog before the first Sprint can start?
1. TRUE
2. FALSE
268
True or False: A Product Owner is essentially the
same thing as a traditional Project Manager?
1. TRUE
2. FALSE
269
What is the Product Owner accountable for in Scrum?
1. Describing an Increment at the Sprint Planning and make sure that the
Development Team delivers it by the end of the Sprint
2. Writing the User Stories so they are comprehensive enough for the
stakeholders.
3. Maximizing the value of the product resulting from the work of the Scrum
Team.
4. Refining the top level Product Backlog items until they are ready to be handed
over to the Scrum Team. 270
if Product Backlog refinement is needed, When should the
Product Backlog be refined and would should participate?
(Choose 2 answers)
1. Describing an Increment at the Sprint Planning and make sure that the
Development Team delivers it by the end of the Sprint
2. Writing the User Stories so they are comprehensive enough for the
stakeholders.
3. Maximizing the value of the product resulting from the work of the Scrum
Team.
4. Refining the top level Product Backlog items until they are ready to be handed
over to the Scrum Team. 271
How important is it for a Product Owner to order
Product Backlog items by value points?
1. Using value points is the ultimate way for a Product Owner to predict the value
that the product will provide.
2. It is a good practice, keeping in mind that market reception is the best measure
of value.
3. Calculating value points is an upfront approach that conflicts with the

empiricism of Scrum, and is therefore not acceptable.
272
True or False: A Product Owner with multiple teams working on one
product should maintain separate Product Backlogs for each team.
1. FALSE.
2. TRUE.
273
What phrases best describe the relationship of the Product
Owner and the Developers?
(choose the best two answers)
1. They collaborate often so the Developers build Increments keeping end-user and
stakeholder concerns in mind.
2. They should work apart as much as possible in order to keep the concerns of
business and technology separated.
3. The Product Owner should be with the Developers full-time to grow a deep
understanding of the technology being used.
4. They should share no more than the Sprint Planning and the Sprint Review meeting.
5. They collaborate often so the Product Owner can make informed decisions in
balancing eff ort and value of Product Backlog items. 274
What are three advantages of a Product Owner with a solid
Product Goal?
(choose the best three answers)
1. It is easier to inspect incremental progress at the Sprint Review.
2. It helps the Scrum Team keep focus and they can check any decision against it.
3. It is not mandatory in Scrum. There is no real advantage.
4. It gives a good overall direction so Sprints will feel less like isolated pieces of work.
5. It helps the Scrum Team maintain focus on when the complete Product Backlog
should be finished.
275
Which two things does the Scum Team NOT do during the
first Sprint? (Choose 2 answers. )
1. Deliver an Increment of potentially releasable functionality.
2. Nail down the complete architecture and infrastructure.
3. Develop and deliver at least one piece of functionality.
4. Develop a plan for the rest of the project.
276
When is it most appropriate for a Scrum Team to change the
definition of “Done”?
1. During the Sprint Retrospective
2. During Sprint Planning
3. Prior to starting a new Sprint
4. Prior to starting a new project
277
1. After the customer completes acceptance testing of the first Sprint.
4. Once the architectural changes for the second Sprint have been approved by the
senior architect.
278
1. After the customer completes acceptance testing of the first Sprint.
4. Once the architectural changes for the second Sprint have been approved by the
senior architect.
279
True or False: A Product Owner with multiple teams working on one
product should maintain separate Product Backlogs for each team.
1. FALSE.
2. TRUE.
280
True or False: The Scrum Team is accountable for releasing the most
valuable product.
1. FALSE.
2. TRUE.
281
A Product Backlog is: (Choose 3 answers)
1. An exhaustive list of upfront approved requirements to be implemented

for the system.
2. Managed by the Product Owner.
3. An inventory of things to be done for the Product.
4. Ordered based on priority, value, dependencies, and risk.
5. Only visible to the Product Owner and stakeholders.
282
True or False: A Scrum Team is only allowed to meet with
stakeholders during Sprint Review.
1. TRUE
2. FALSE
283
What percent of the time should a Product Owner dedicate to
the Scrum Team? (Choose two answers)
1. 100%.
2. 40%, or more if the stakeholders agree.
3. Just enough time to keep the developers from complaining.
4. Enough time to avoid the waste that is created by delaying functional

answers to the Developers.
5. Enough to maximize the value being delivered in the Increment
6. As much as the stakeholders want to budget. Business analysts take over

the role the rest of the time. 284
Adaptation requires regular inspection. In what ways does the Product
Owner contribute to the results achieved by inspection ?
(Choose two answers)
1. The Product Owner invites stakeholders to the Sprint Review to learn how the current
state of the market place influences what is the most valuable thing to do next.
2. The Product Owner inspects the Sprint burn-down at the Daily Scrum for progress
towards a complete Increment and re-planning the team's work.
3. The Product Owner verifies the Sprint Backlog for completeness at the end of Sprint
Planning in order to allow the Sprint to start.
4. The Product Owner shares the current state of Product Backlog at the Sprint Review,
which, combined with the inspection of the Increment, leads to an updated Product
Backlog. 285
What is the maximum length of a Sprint?
1. Not so long that the risk is unacceptable to the Product Owner.
2. Not so long that other business events can't be readily synchronized with
the development work.
3. No more than one calendar month.
4. All of these answers are correct.
286
What activities would a Product Owner typically undertake in the
phase between the current Sprint Retrospective meeting and the
next Sprint's Sprint Planning?
1. Refining the Product Backlog.
2. Updating the project plan with stakeholders
3. There are no such activities. The next Sprint starts immediately after the
current Sprint.
4. Working with the QA departments on the Increment of the current Sprint.
287
What typically happens if Product Backlog is not sufficiently
clear at Sprint Planning?
1. It is acceptable if the Product Owner can give the Scrum Team a clear
Sprint Goal.
2. The Developers have difficulties creating a forecast of work for the Sprint.
3. Nothing in particular.
4. The Scrum Master shouldn't allow this to happen. Look for a new Scrum
Master and re-start the Sprint.
5. The Sprint Planning is cancelled so refinement can be done fi rst.

288
As the Sprint Planning meeting progresses, the Developers
see that the workload is greater than they can handle. Which
two are valid actions?
(Choose two answers)
1. The Developers work overtime during this Sprint.
2. Recruit additional Developers before the work can begin.
3. Cancel the Sprint.
4. Remove or change selected Product Backlog items.
5. The Developers ensure that the Product Owner is aware, starts the Sprint,
and monitors progress.
289
-
Théorie de Scrum
Valeur Scrum
- La Démarche Scrum
- Processus Scrum
Sprint Backlog (Sprint 0)

Spécification des Besoins et Elaboration du Backlog du Produit
Établir la vision du projet

01
Le Backlog de produit
04
Identification des acteurs

02
Planification des Sprints
05
Regroupement des fonctionnalités/
Elaboration des User Story
03
290

-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum
 Le Backlog du Produit « Product Backlog » est l’artefact le plus important de Scrum, c’est l’ensemble
des caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité
− Les caractéristiques fonctionnelles sont appelées des histoires utilisateur (User Story)
− Les caractéristiques techniques sont appelées des histoires techniques (Technical Story)
 L’élaboration du Product Backlog permettra de répondre aux 3 questions suivantes:

─ Quelles seront les fonctionnalités à créer ?
─ Dans quel ordre devront-elles être livrées ?
─ À qui sont-elles destinées ?
291
-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum

Étape 1: Établir la Vision du projet/Product Goal (2/2)
 Il est important que cette vision soit acceptée et comprise par tous, elle doit faire consensus puisque l’équipe
va devoir se rallier derrière le PO pour réaliser ce projet selon l’objectif que le projet devra atteindre
 Exemple1 de vision pour notre système de gestion des locations vidéos:
« Offrir une solution de gestion complète, incluant suivi, statistiques et facturation ainsi qu’un module de
prélocation en ligne et d’analyse statistique pour les vidéoclubs »
 Exemple 2 de vision pour la plateforme d’un Système de soutien éducatif :
« Nous proposons de concevoir et d’implémenter une plateforme web en ligne qui regroupe les fonctionnalités
essentielles d’e-learning qui englobe à la fois le sharing (document, webcam) et le partage d’idées, des
connaissances et des formations en ligne pour faciliter et renforcer les relations entre les tuteurs et les apprenants »
292
-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum
Le Backlog du Produit
Étape 2: Identification des acteurs (1/2)
 Un acteur représente l’abstraction d’un rôle joue par des entités externes (utilisateur, dispositif matériel ou autre
système) qui interagissent directement avec le système étudie
 Il va falloir identifier puis détailler tous les intervenants, utilisateurs du système dans tous ses aspects. Pour chaque
intervenant on voudra préciser les informations suivantes :
─ Surnom : donner un Surnom aux acteurs rendra plus agréable leur utilisation et il sera plus simple de s’y identifier.
─ Icone / image : ajouter une représentation graphique de l’acteur rend l’identification encore plus facile.
─ Rôle : c’est en fait une description courte souvent juste un mot ou nom commun.
─ Description : on décrit pourquoi et/ou comment cet acteur utilisera le système.
─ Critères de satisfaction : ce qui rendra cet acteur satisfait de l’utilisation qu’il fait du système.
─ Valeur commerciale : élevée, moyenne, basse, bloquante (les autres acteurs ne pourront utiliser le système).
─ Fréquence d’utilisation : permanente, quotidienne, occasionnelle, rare.
─ Nombre d’instances : combien d’intervenants comme celui-ci utiliseront le système. 1, 10, 100+.
─ Niveau de connaissance technologique : élevée, moyenne, basse.
293
─ Niveau de connaissance métier : élevée, moyenne, basse.
-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum

Étape 2: Identification des acteurs (2/2)
Exemple pour le Projet de gestion de club de location des vidéos (Acteur Bob)
294
-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum

Étape 3: Regroupement de fonctionnalités (1/2)
Exemple1 de vision pour notre système de gestion des locations vidéos:
« Offrir une solution de gestion complète, incluant suivi, statistiques et facturation ainsi qu’un
module de prélocation en ligne et d’analyse statistique pour les vidéoclubs »
 On en tire donc facilement les thèmes suivants :

─ Location et suivi
─ Statistiques
─ Facturation
─ Pré-location en ligne
295
-
Théorie de Scrum
Valeur Scrum
- Démarche Scrum
- Processus Scrum

Étape 3: Regroupement de fonctionnalités (2/2)
Exemple 2 de vision pour la plateforme d’un Système de soutien éducatif :
« Nous proposons de concevoir et d’implémenter une plateforme web en ligne qui regroupe les
fonctionnalités essentielles d’e-learning qui englobe à la fois le sharing (document, webcam) et le
partage d’idées, des connaissances et des formations en ligne pour faciliter et renforcer les relations
entre les tuteurs et les apprenants »
 Les besoins fonctionnels identifiés pour ce projet sont regroupées en quatre espaces en fonction
des différents intervenants à savoir :
─ Gestion des activités d’administrateur,
─ Gestion des tuteurs,
─ Gestion des apprenants
─ Gestion des simples visiteurs 296
- Extreme Programming (XP) - Le Framework FDD
Les autres Frameworks Agiles - Lean Product Development - Le Framework DSDM
- Kanban - Famille des méthodes agiles~ Crystal
Extreme Programming (XP)
 XP values
─ Simplicity
─ Communication
─ Feedback
─ Courage
─ Respect
297
Extreme Programming (XP)
Sprint 0
Architecture f°

Le processus XP

KP: Modèle itératif et travail en pair

Les rôles en XP
Coach
 Le Coach agit comme un mentor pour l'équipe, en guidant le processus et en aidant les
membres de l'équipe à rester sur la bonne voie.
 Le Coach est un facilitateur, qui aide l'équipe à devenir plus efficace
 Le Coach est un intermédiaire, qui renforce la communication au sein de l'équipe et entre

les équipes
 Ce rôle de Coach partage de nombreuses responsabilités avec le Scrum Master.
 En plus du coach, il peut également y avoir un manager qui facilite les communications
externes et coordonne les activités de l'équipe, mais ce n'est pas un rôle formel de XP.
301
Les rôles en XP
Customer
 Le client est le représentant de l'entreprise qui fournit les exigences, les priorités et
l'orientation du projet
 Le client définit le produit qui sera construit, détermine la priorité de ses fonctionnalités et
confirme que le produit fonctionne réellement comme prévu
 Ce rôle de client est similaire à celui du « Product Owner » dans Scrum
Programmers
 Les programmeurs sont les développeurs qui construisent le produit en écrivant et en
implémentant le code pour les user stories demandées.
Testers
Les testeurs fournissent une assurance qualité et aident le client à définir et à rédiger des302
tests d'acceptation pour les US.
Lean Product Development
303
Les principes de Lean

Éliminer les
déchets
Eliminate waste
Habiliter
Amplifier l’équipe
l’apprentissage Empower the
Amplify Learning team
Livrer
Remettre au plus Lean rapidement
tard les décisions Deliver fast
Defer decisions
Optimiser
Construire sur l’ensemble
de la qualité Optimize the
Build Quality in whole
304
Éliminer les « Mudas » (Lean Management)

Les 7 gaspillages
Travail non terminé
Processus inutiles
Production inutile
Interruptions
Tempsd’attente
Déplacements inutiles
Défauts
305
Kanban
Kanban: les 5 principes
306
Kanban: le flux
 Modéliser Carte et Tableau Kanban
 Décomposer le Processus (étape et file)

 Constituer les cartes Kanban du projet
 Visualiser l’avancement actuel du projet
...
Management visuel
307
Kanban: limiter le WIP
 Work In Progress (WIP)
 Fixer les seuils par étape (Max et Mini)

 Rendre visible les limitations
Limiter le travail en  Respecter les limitations imposées
cours
...
308
Kanban: Tableau Kanban

Kanban Board with WIP Limits
309
Kanban: cumulative flow diagram
310
Le Framework Feature Driven Development (FDD)
311
Les 8 principes du Framework FDD

1. Modélisation Objet du domaine (Domain object modeling): Consiste à explorer et à
exprimer le domaine du problème à résoudre via un modèle d’objet de domaine qui fournit
un cadre global dans lequel d’ajouter des fonctionnalités
2. Développer par fonction (Developing by feature): Toute fonction qui est trop complexe à
mettre en œuvre dans les deux semaines est décomposée en fonctions plus petites jusqu’à
ce que chaque sous-problème est assez petit pour être appelé une fonction
3. Propriété individuelle du code (Individual class ownerships): Les classes des codes
(individuelles ou de regroupement) sont attribués à un seul propriétaire. Le propriétaire est
responsable de la cohérence, de la performance et l’intégrité conceptuelle de la classe
4. Équipe techniques (Feature teams): L’équipe technique est une petite équipe formée,
dynamique qui développe une petite activité. Ce faisant, plusieurs esprits sont toujours
appliqués à chaque décision de conception et aussi de multiples options de conception sont
toujours évalués avant que l’on est choisi 312
Les 8 principes du Framework FDD (suite)

5. Inspections (Inspections): Les inspections sont effectués pour assurer la bonne qualité de la
conception et du code, principalement par la détection de défauts
6. Gestion de la configuration (Configuration management): La gestion de configuration

permet d’identifier le code source de toutes les fonctionnalités qui ont été réalisés à ce jour
et de conserver un historique des changements apportés aux classes que les équipes
techniques les améliorent
7. Déploiement réguliers (Regular builds): A travers ces déploiements réguliers, l’équipe

s’assure que le nouveau code s’intègre avec le code existant, Cette pratique facilite la
création de démonstration
8. Visibilité des progrès et des résultats (Visibility of progress and results): Cette pratique suit
les progrès réalisés en se basant sur le travail accompli
313
Le Framework Dynamic Systems Development Method (DSDM)
314
Les 8 Principes de DSDM
Le framework DSDM s’appuie sur 8 principes de base:

1. Focus sur les besoins métiers (Focus on the business need): L’objectif est de livrer une
application en adéquation avec le besoin métier du client
2. Livraison dans les temps (Deliver on time): L’application doit être livrée le plus souvent possible
afin de permettre un feed-back rapide
3. Collaboration (Collaborate): Les acteurs du projet doivent faire preuves de souplesse

concernant les modifications des fonctionnalités demandées
4. Qualité non négociable (Never compromise quality): Les tests sont continus durant tout le
développement. Ils permettent de garantir le bon fonctionnement de l’application, à chaque
étape du développement
315
Les 8 Principes de DSDM (Suite)
5. Construire par incrément (Build incrementally from firm foundations): chaque incrément doit
être bâti sur des fondations solides liées au socle applicatif de l’entreprise
6. Développement itératif (Develop iteratively)
7. Communication continue et transparente (Communicate continously and cleary): la conduite

du projet doit se faire en toute transparence et clarté vis-à-vis des parties prenantes
8. Projet sous contrôle/Demonstrate control: L’équipe projet doit maîtriser le déroulement du

projet et le respect des contraintes (ressources, délais & qualité)
316
Famille des méthodes agiles~ Crystal~

 Les différentes méthodes agiles Crystal ont été conçues pour s’adapter à la taille de l’équipe de
développement. Un code de couleur est utilisé pour identifier le « poids » de la méthode agile à
utiliser en fonction du projet.
 Les différentes couleurs utilisées sont :
─ transparent (« Clear »),
─ jaune,
─ orange,
─ rouge,
─ marron,
─ diamant
─ et saphir.
 Ce qui avec une variante supplémentaire nous donne les méthodes Crystal Clear, Crystal Yellow,
Crystal Orange, Crystal Orange Web, Crystal Red, Crystal Maroon, Crystal Diamond et Crystal
Saphir. Plus le projet à gérer est important, plus la couleur de la méthode est foncée. 317
Famille Crystal
318
Les 7 principes de Crystal
Le framework Crystal s’appuie sur 7 principes de base:
1. Livraison fréquente (Frequent delivery): Crystal préconise la création du système via de

multiples Buid incrémentaux qui ensuite sont soumis à des tests d’acceptances
2. Amélioration réfléchissante (Reflective improvement): cette pratique fait écho à la recherche

régulière de piste d’amélioration et à leur mise en œuvre
3. Communication étroite (Close communication): ici l’on souhaite que l’équipe soit co-localisé
pour une communication osmotique puisse se créer aisément
4. Sécurité personnelle (Personal safety): Crystal préconise que soit mis en place un
environnement où les personnes puissent en toute « sécurité » affronter problèmes et conflits
319
Les 7 principes de Crystal (suite)
5. Focus: Les personnes impliquées dans le projet doivent savoir sur quoi elles doivent travailler
et avoir le temps nécessaire pour réaliser ce travail
6. Accès facile aux utilisateurs experts (Easy access to expert users): à travers cet accès aisé au
« métier », les développeurs peuvent lever rapidement les ambiguïtés et obtenir du feedback
sur leur travail
7. Bon environnement technique (Good Technical environment): Crystal s’appuie sur un

environnement technologique de type « Software Factory » comprenant par exemple: des
tests automatisés, de l’intégration continue, une gestion de configuration, . . .
320
Les Frameworks Agiles Étude comparative
Caractéristiques Scrum XP Comparatif
FDD DSDM Crystal
Approche de Itérative et Itérative et incrémentale Itérative Itérative incrémentale
développement incrémentale
Durée d’itération Deux à quatre Une à six semaines Deux jours à deux 80% de solutions en selon la méthode
recommandée semaines semaines 20%de temps total utilisée par la famille
Toutes les tailles Petits équipes (moins de Plusieurs membres/ Tous les tailles Tous les tailles/Selon la
Équipe de projet 20 membres) plus qu’une équipe Équipe méthode de la famille
indépendante
Informelle/Réunion Informelle/Réunion Basé sur la Basée sur la Informelle
Communication
quotidienne de quotidienne de synthèse documentation documentation Face à face
de l’équipe
synthèse
Tous types de Petits projets Projets plus complexes Tous types de Tous les types de
Taille de projet
projets projets projets
Client à travers le Client impliqué Client par le biais de Client grâce à des Client grâce à des
Implication du
rôle de « Product rapports (de passage) incréments versions incrémentales
client
Owner » fréquentes
Documentation Documentation de Documentation de base La documentation est La documentation Documentation de base
du projet base (seulement) (seulement) importante existe (seulement)
Sprint, Product and TDD, User stories, Diagrammes UML prototypage Famille de méthodes
Sprint backlog, Refactoring adaptables
Particularités Planning Poker, Tous les types de
Scrum master projets et tailles
d’équipes
Haut niveau de Espace de travail ouvert, Les rapports et la Approche prioritaire Méthodologies qui
© Mariam Ben Hassen- communication et Agile~
Projet Fédéré ~Méthode client faisant partie de documentation des exigences s’adaptent au08/02/2022
type et à

PROJET FÉDERÉ Méthode Agile: Le Framework Scrum

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

PROJET FÉDERÉ Méthode Agile: Le Framework Scrum

Transféré par

Droits d'auteur :

Formats disponibles

Institut Supérieur

PROJET FÉDERÉ − Méthode Agile

Responsable TP: Mariam BEN HASSEN OUALI

Auditoire : 2ème année LSI-MM

A.U : 2021 - 2022 mariem.benhassen@isims.usf.tn

 Comprendre la nécessité de la conduite de projets informatiques (logiciels)

 Apprendre les différentes activités de la gestion de projets informatiques

 Comprendre les différents modèles de développement logiciel

 Comprendre la différence entre le développement traditionnel et agile

 Comprendre l’approche « Scrum » Agile et son utilité

 Les projets n’atteignent pas souvent leurs objectifs

 Les projets se déroulent dans un milieu complexe

 Planifier le projet dans le temps

─ Étude préalable des coûts, des sources de financement, etc.

─ Étude des risques opérationnels et financiers

 Responsabiliser le chef du projet

─ Mettre en place une comité de pilotage

 Suivre les enjeux opérationnels et financiers importants

© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ 08/02/2022

 Un ensemble de programmes, de procédures et de documentation associée et les données qui

La réalisation du projet doit répondre à un niveau adéquat de qualité pour

 la gestion de projets logiciels est

 crucial pour réaliser un projet réussi, à cause de

Les exigences Logicielles

Les modèles de processus de

© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ 08/02/2022

Les modèles de processus de

1.3 Les Frameworks Agiles

Cycle de vie d’un 1.4

© Mariam Ben Hassen- Projet Fédéré ~Méthode Agile~ 08/02/2022

Les exigences logicielles

Exigences Exigences non

Fonctions du système: Propriétés (qualités)

Techniques d’élicitation des

Les exigences logicielles

Exercice d’application N°1

Correction Exercice N°1

Système simplifié de Guichet Automatique de Banque (GAB)

Cycle de vie d’un projet informatique

 Différents aspects du processus

─ Que faut-il faire (le quoi) ?

─ À quel moment le faire (le quand) ?

─ Dans quelles conditions il faut le faire (le comment) ?

Cycle de vie d’un projet informatique

 Le but de ce découpage est de

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Cycle de vie d’un projet informatique

Modèles de cycle de vie d’un logiciel

 Modèles linéaires et incrémentaux

 Modèles non linéaires

Les modèles de développement: Modèle en cascade

Les modèles de développement: Modèle de la cascade

Les modèles de développement: Modèle de la cascade

– La séparation des étapes est trop stricte et inflexible: on doit

Les modèles de développement: Modèle en V

Tests fonctionnels (de

Test de chaque fonction

Les modèles de développement: Modèle en V