07/02/2024

Projet fédéré (Méthode Agile) Objectifs

 Appliquer les notions de conception orientée objet et du
langage UML avec une méthodologie Agile.
Proposé par : Dr Adel KACEM
E-mail: [email protected]
Code ECUET 413
Section : 2ème année LCS-IM

Année Universitaire : 2022/2023

1 2

1 2

Un logiciel de qualité

S B
Projet fédéré (Méthode Agile) Re-utilisabilité Portabilité

Q u a l ité Efficacité

Introduction
Lisibilité et
Processus Unifié et Approche Agile R
Vérifiabilité
Modularité T
SCRUM

3 4

3 4

1
 07/02/2024

Un logiciel de qualité Projet logiciel

 Re-utilisabilité : aptitude d’un logiciel à être  Un projet est un ensemble d’actions effectuées par
réutilisé, en tout ou en partie, pour d’autres des personnes morales ou physique pour atteindre
applications, un objectif, limité par une date, possédant un coût.
 Vérifiabilité : aptitude d’un logiciel à être testé  Conduite et direction du projet :
(optimisation de la préparation et de la  Organisation méthodologique,
vérification des jeux de tests),  Gestion des personnes impliquées,
 Portabilité : aptitude d’un logiciel à être transféré  Gestion technique,
dans des environnements logiciels et matériels  Gestion de moyens, etc.
différents,
 Lisibilité et Modularité

5 6

5 6

Projet logiciel Projet logiciel

 Capture des besoins: réalisation du cahier des

charges, spécifications fonctionnelles et non
fonctionnelles des besoins,
Capture des
Conception Réalisation Validation Maintenance  Conception: architecture du logiciel, modèles de
besoins
conception,
 Réalisation : implémentation du code
 Validation : intégration et déploiement et j’aurais
un logiciel livrable,
 Maintenance.
7 8

7 8

2
 07/02/2024

Projet logiciel Cycle de vie d’un logiciel

 Toutes les phases de développement du logiciel,

de l'établissement des besoins du client jusqu'à
l'achèvement du logiciel en tant que produit
commercial.
 Ces phases sont organisées selon des modèles qui
permettent de guider l’ingénieur dans ses
activités.
Comment piloter un projet de développement  Modèles linéaires (en cascade, …)
comportant ces étapes ?  Modèles non linéaires (spirale, itératif,…)

9 10

9 10

Cycle de vie d’un logiciel (modèle en Cycle de vie d’un logiciel (modèle en
cascade) cascade)
Analyse et spécification des Analyse et spécification des
besoins besoins

Conception Conception

Implémentation Implémentation
 Délais longs pour voir
 Linéaire, flot descendant. quelque chose qui tourne.
 Retour limité à une phase en Test  Test de l’application globale Test
amont. uniquement à la fin.
 Validation des phases par des  Difficulté de définir tous les
revues. Livraison et besoins au début du projet. Livraison et
maintenance maintenance
wikipedia.org wikipedia.org
11 12

11 12

3
 07/02/2024

Cycle de vie d’un logiciel (modèle en V) Cycle de vie d’un logiciel

(Problèmes et solutions - modèles linéaires)
 Une anomalie détectée dans une phase aval de la
cascade peut remettre en cause des travaux
validés.
 La levée tardive des facteurs à risques.
 Non prise en compte de l’évolution des besoins
pendant le cycle.
 Modèle théoriquement parfait, mais inadapté aux
humains.

wikipedia.org
13 14

13 14

Cycle de vie d’un logiciel Cycle de vie d’un logiciel (modèle en

(Problèmes et solutions - modèles linéaires) spirale)
 Utilisés seulement quand les exigences sont bien
connues et non sujettes à modification.

 Encore assez populaires et souvent utilisés par les

non spécialistes.

15 wikipedia.org 16

15 16

4
 07/02/2024

Méthode et Processus Méthode et Processus

 Une méthode est une démarche reproductible  Un processus définit qui fait quoi à quel moment
permettant d’obtenir des solutions fiables à un et de quelle façon pour atteindre un certain
problème donné. objectif.
 En GL, on trouve des méthodes:  Un processus fournit les directives nécessaires
 de développement pour le développement d’un logiciel de qualité.
 de conduite de projet  Un processus implique la présence des clients,
 d’assurance et de contrôle qualité utilisateurs, développeurs et responsables.
 etc.  Un processus suit l’évolution (des technologies,
des outils, des ressources, etc)
17 18

17 18

Méthode et Processus Méthode et Processus

 Deux approches méthodologiques du développement

de logiciels sont en concurrence :
 L’approche fonctionnelle ou classique (1970)
 Analyse fonctionnelle hiérarchique,
 Liée à la programmation structurée.
 L’approche orientée objets (1990)
 Approche avec grande cohérence (données/traitements),
 Lier le monde des objets au monde de l’application ,
 Encapsulation, abstraction, réutilisation, modularité, extensibilité,
etc.
https://www.mindcrafts.ch/fr
19 20

19 20

5
 07/02/2024

UML (rappel) UML (rappel)

Structuration Cas d’utilisation, classe, composant, …
 UML (Unified Modeling Language ou langage
unifié de modélisation) est un langage graphique Groupement Package, modèle , sous-système…
destiné à la modélisation de systèmes et de
processus[1] . UML Comportement interaction, machine d ’états…

Relation Association, dépendance, génération…

 Méthode: comment utiliser le langage de
modélisation (recueil des besoins, analyse,
Diagramme De Cas d’utilisation, de séquence, de classes,
conception, mise en œuvre, validation, ...) d’activité, de déploiement, …

[1] Fien VAN DER HEYDE Laurent DEBRAUWER

21 22

21 22

UML (rappel) UML (rappel)

 Les cas d’utilisation servent de fil conducteur

pour l’ensemble du projet.

23 24

23 24

6
 07/02/2024

UML(rappel) UML (rappel)

25 26

25 26

UML (rappel) UML (rappel)

27 28

27 28

7
 07/02/2024

UML (rappel) UML (rappel)

29 30

29 30

UML (rappel) UML (rappel)

31 32

31 32

8
 07/02/2024

UML (rappel) UML (rappel)

33 34

33 34

UML (rappel) Conclusion

 UML n'est qu'un langage de modélisation et

non une méthodologie à part entière. RUP Scrum
XUP
2TUP ASD
EssUP
Extreme Programming
 UML définit des notations utiles dans toutes AUP
les étapes du développement d'un logiciel, de EUP Crystal
UP DSDM
l'analyse des besoins à la livraison de celui-ci,
mais il ne propose aucune démarche spécifique
pour mener ce développement à terme.

35 36

35 36

9
 07/02/2024

Travail à faire

 Choisir un projet dont sa réalisation demande

l’intervention d’au moins deux acteurs.
Projet fédéré (Méthode Agile)
 Déterminer le cahier des charges
 Donner une première vision de:
 Diagrammes statiques
 Maquettes IHM Introduction
 Présentation Processus Unifié et Approche Agile
SCRUM

37 38

37 38

Plan Introduction

1. Introduction  La création des logiciels de plus en plus

2. Les phases du Processus Unifié imposants et complexes.
3. Caractéristiques du Processus Unifié  On cherche des logiciels:
4. Les 4 « P » du développement logiciel  plus adoptés à nos besoins,
 répondent aux exigences du marché,
5. Les enchaînements d’activités principaux
 dans des délais fixes,
 avec des coûts réduits,
 mieux documentés,
 …

39 40

39 40

10
 07/02/2024

Introduction Introduction
 « Le processus unifié (Unified Process) est un
processus de développement logiciel, c’est-à-dire  Le PU utilise le langage UML pour la création des
qu’il regroupe les activités à mener pour transformer plans d’élaboration du logiciel.
les be soin s d’un u t i li s a t e u r en s ystè m e  Le PU ne fait pas partie intégrante du standard
logiciel » (Jacobson, Booch, Rumbaugh 1999).
UML.
 Utilisé pour le développement orienté objet de
 Le résultat de la fusion des méthodes Objectory d'Ivar logiciel.
Jacobson, Booch de Grady Booch et OMT de James
 Le PU est :
Rumbaugh, enrichi de nombreux apports issus des  piloté par les cas d’utilisation,
travaux d'élaboration du standard UML et du produit  centré sur l'architecture,
commercial RUP (Rational Unified Process).  itératif et incrémental.

41 42

41 42

Les phases du PU Les phases du PU

 Le PU répète une série de cycles constituant la vie Cycle 1 Cycle 2 Cycle 3

du système.
 Un cycle conduit à la livraison d’une version du
Etude
Elaboration Construction Transition
produit. préliminaire

 Un cycle s’articule autour de 4 phases:

 Étude préliminaire Chaque cycle de développement du PU est géré comme un projet
 Élaboration ayant 4 phases.
 Construction
Chaque phase s’achève par un jalon définit par un ensemble
 Transition d’artefacts.

43 44

43 44

11
 07/02/2024

Les phases du PU - artefact Les phases du PU – phase 1

Etude
Elaboration Construction Transition
 Un élément d’information produit ou modifié préliminaire

dans le cadre du processus de développement

(document, diagramme, compte rendu de réunion, Vision
code source, modèle de base de données, etc.)
 Cette phase traduit l’idée en une vision du produit fini .
 Artefacts qui dépendent de l’activité de gestion de
 Elle répond aux questions suivantes :
projet.
 Que va faire le système pour ses utilisateurs ?
 Artefacts qui sont directement issus du travail de  A quoi peut rassembler l’architecture du système ?
fabrication du logiciel.  Quels sont l’organisation et les coûts de ce produit?

45 46

45 46

Les phases du PU – phase 2 Les phases du PU – phase 3

Etude Etude
Elaboration Construction Transition Elaboration Construction Transition
préliminaire préliminaire

Vision Architecture Vision Architecture Version bêta

 Concevoir une architecture de référence,

 Formuler les cas d’utilisation pour couvrir environ 80% des  Mettre en œuvre tous les cas d’utilisation en accord avec les
besoins fonctionnels, clients.
 La phase la plus coûteuse qui englobe le codage, la
 Faire une planification complète (temps, personnel, budget).
conception , test et intégration, etc.
 Le jalon est une architecture de base en justifiant les choix
 Le jalon est une version du produit.
architecturaux.

47 48

47 48

12
 07/02/2024

Les phases du PU – phase 4 Les phases du PU

Etude
Elaboration Construction Transition Activités Phases
préliminaire
principales Etude Pré Élaboration Construction Transition

Besoins
Vision Architecture Version bêta Produit
livré Analyse
Conception
 Cette phase couvre le test du produit en version bêta .
Implémentation
 Les anomalies et les défauts constatés par l’équipe de test sont
prises en considération. Tests
 La formation des utilisateurs, la préparation des manuels
d’utilisation, la mise en place d’une équipe de maintenance.
 Le produit est déployé chez le client.
https://www.mindcrafts.ch/fr
49 50

49 50

Caractéristiques de Processus Unifié Caractéristiques de Processus Unifié

(itératif et incrémental) (itératif et incrémental)
Activités Phases
 Découper le travail en plusieurs parties qui principales Création Élaboration Construction Transition
présentent des mini-projets.
Besoins
 Une itération contient toutes les activités, conduit au Analyse
développement d’un certain nombre de UC. Conception
 Les itérations donnent lieu à un incrément. Implémentation
 Un incrément correspond à une avancée dans les Tests
différents stades de développement. It. 1 It. 2 … … … … … It. n-1 It. n
Itérations
https://www.mindcrafts.ch/fr
51 52

51 52

13
 07/02/2024

Caractéristiques de Processus Unifié Caractéristiques de Processus Unifié

(itératif et incrémental) (piloté par les UC)
 Gestion de la complexité.  Un outil de spécification des besoins du système.
 Prise en compte des modifications de besoins.  Un outil pour guider le processus de développement.
 Apprentissage rapide de la méthode.  Les cas d’utilisation sont:
 Maîtrise précoce des risques.  détaillés par l’analyse
 …  réalisés par la conception
 concrètement implémentés par les développeurs
 vérifiés par les scénarios de test

53 54

53 54

Caractéristiques de Processus Unifié Caractéristiques de Processus Unifié

(piloté par les UC) (piloté par les UC)
Cas d’utilisation
spécifié par réalisé par  Support de communication entre utilisateurs et
Modèle d’analyse
distribué par concepteurs.
Modèle de conception  Assurent la traçabilité de toute décision de
conception.
Modèle de déploiement
 Fournissent une vision commune aux participants du
implémenté par Modèle d’implémentation projet.
vérifié par Modèle de test  …

https://www.mindcrafts.ch/fr
55 56

55 56

14
 07/02/2024

Caractéristiques de Processus Unifié Caractéristiques de Processus Unifié

(centré sur l’architecture) (centré sur l’architecture)
 Une architecture décrit les différentes vues des  Dans un premier temps, choisir une architecture
modèles du système à construire. qui définit les parties générales de l’application.
 Une architecture représente les aspects dynamique  Ceci mène à la construction d’une ébauche.
et statique du système.  Dans un deuxième temps, stabiliser l’architecture
 Une architecture est un lien pour les membres du autour des fonctions essentielles.
projet:  Ceci mène à la construction d’une architecture
 Une architecture émerge des besoins exprimés à travers référence.
les cas d’utilisation.
 Dans un troisième temps, l’architecture continue à
 Elle complète les cas d’utilisation.
se stabiliser dans les itérations suivantes.
57 58

57 58

Caractéristiques de Processus Unifié Les 4 « P » du développement logiciel

(centré sur l’architecture)
Processus
Automatisation
 Comprendre le système,
Template
Participants

 Organiser le développement, Personnes Projet Outils

Résultat
 Favoriser la réutilisation,
Produit
 Faire évoluer le système.

59 60

59 60

15
 07/02/2024

Les 4 « P » du développement logiciel Les enchaînements d’activités principaux

 Personnes: les architectes, développeurs, testeurs, Activités Phases

la direction, les utilisateurs, les clients. principales Etude Pré Élaboration Construction Transition

 Projet: élément d’organisation à travers lequel est Besoins

géré le développement du logiciel. Analyse

 Produit: ensemble des artefacts créés au cours du Conception

cycle de vie du projet. Implémentation

 Processus: offre un cadre générique à la création Tests

de projet. It. préliminaire … … … … … It. n-1 It. n
Itérations
https://www.mindcrafts.ch/fr
61 62

61 62

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Expression des besoins- -Expression des besoins-
 Décrire les exigences que doit respecter le système  La modélisation du domaine
avec précision pour parvenir à un accord entre le  La saisie des objets les plus importants dans le contexte du
client et les développeurs. système.
 Le diagramme du domaine est décrit avec le langage
UML à travers le diagramme de classe contenant les
classes essentielles.
 La modélisation du métier consiste à décrire les
processus métier existants ou perçus afin de les
comprendre.

63 64

63 64

16
 07/02/2024

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Expression des besoins- -Expression des besoins-
 Modèle des cas
d’utilisation
 Représenter les cas
d’utilisation
 Classer les cas d’utilisation
par priorité
 Décrire en détail les cas
d’utilisation

65 66

65 66

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Expression des besoins- -Expression des besoins-
 CU : Réserver une chambre
 La gestion locale est un traitement classique alors le risque est
faible pour ce cas.  Portée : système de réservation
 Acteur principal : Gérant
 Les réservations en ligne nécessitent une architecture plus
 Intervenants et intérêts : Client, Chaîne hôtelière
complexe alors le risque est plus élevé.
 Préconditions : une chambre est libre pour la période désirée
 Le ménage des chambres entraîne des ressources alors le risque  Garanties minimales : rien ne se passe
est moyen.  Garanties en cas de succès : la chambre est réservée
1. Réserver une chambre sur le site,  Scénario nominal
2. Gérer la chambre à nettoyer, 1. Description du scénario……..
3. Réserver une chambre dans le local,
4. ….

67 68

67 68

17
 07/02/2024

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Expression des besoins- -Expression des besoins-
 Compléter la description en représentant les
diagrammes de séquence système, diagrammes
d’activité.
 Préparer des maquettes IHM (si nécessaire) pour
l’évaluer auprès du client.
 Recenser les besoins non fonctionnels dans une
liste.

69 70

69 70

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Expression des besoins- -Expression des besoins-

71 72

71 72

18
 07/02/2024

Rôle des besoins dans le cycle de vie Les enchaînements d’activités principaux
du logiciel
 L’expression des besoins s’étale sur plusieurs incréments de Activités Phases
développement. principales Etude Pré Élaboration Construction Transition
 Chaque itération apporte de nouveaux cas d’utilisation ou des Besoins
détailles des cas d’utilisation existants.
Analyse
 La capture des besoin s’effectue principalement au cours des
phases d’étude préliminaire et d’élaboration. Conception
 Identification de la plupart des cas d’utilisations durant la phase d’étude Implémentation
préliminaire.
 La mise à jour des cas d’utilisation durant la phase de l’élaboration. Tests
 Le reste de besoins est formulé et implémenté durant la phase de It. préliminaire … … … … … It. n-1 It. n
construction. Itérations
https://www.mindcrafts.ch/fr
73 74

73 74

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Analyse- -Analyse-
 L'analyse se consacre à l'analyse des besoins décrits
dans l'expression de ces derniers, en les affinant et
en les structurant.
 Réalisation des cas d’utilisation par des objets/
classes d’analyse pour préparer la conception.
 Un point de départ pour l’analyse architecturale en
décomposant le système.

75 76

75 76

19
 07/02/2024

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Analyse- -Analyse (modèle d’analyse)-
Modèle des cas d’utilisation Modèle d’analyse  Le modèle d’analyse est un modèle d’objet
Langage du client Langage du développeur conceptuel.
Vue externe du système Vue interne du système
Structuré par les cas Structuré par les classes et les paquetages
 Un modèle d’analyse structure les besoins et les
exigences dans le langage des développeurs pour
Sert à définir un contrat entre le client et les Sert à comprendre le système faciliter la compréhension, la modification.
développeurs

Informel Cohérent , non redondant

 Une première ébauche du modèle de conception
Capture les fonctions du système et ce qui Esquisse la manière de réaliser les fonctions constituant une entrée essentielle pour
conditionne l’architecture dans le système et leur répartition dans des
classes l’élaboration du système.

77 78

77 78

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Analyse (modèle d’analyse)- -Analyse (modèle d’analyse)-
 Une classe d’analyse représente une ou plusieurs  Une classe frontière modélise l’interaction entre le
classes et/ou sous systèmes. système et ses acteurs.
 Elles présentent des fenêtres, des formulaires, des
interfaces de communication, des terminaux et
des API.
 Elles n’ont pas besoin de décrire la réalisation
physique de l’interaction.
 Elle est liée à au moins un acteur.

79 80

79 80

20
 07/02/2024

Les enchaînements d’activités principaux Les enchaînements d’activités principaux

-Analyse (modèle d’analyse)- -Analyse (modèle d’analyse)-
 Une classe entité modélise les informations de
longue durée et souvent de nature persistante.  Une classe de contrôle représente la coordination, le
séquencement, les transactions et le contrôle
 Elles présentent des objets gérés par le système.
d'objets.
 Elles font apparaître une structure de données  Elles modélisent la dynamique du système .
logique .
 Elles servent souvent à encapsuler le contrôle
 Elles offrent une meilleure compréhension des
associé à un cas d’utilisation spécifique.
informations dont le système dépend.

81 82

81 82

Les enchaînements d’activités principaux

-Analyse (modèle d’analyse)-
Projet fédéré (Méthode Agile)

chaine de caractères

Introduction
Processus Unifié et Approche Agile
SCRUM

83 84

83 84

21
 07/02/2024

Plan Qu’est ce que SCRUM?

 Méthode Agile
1. Principes de Scrum  Elle a été présentée en 1990 par Jeff McKenna et Ken Schwaber,
et est appliquée depuis. De nombreux contributeurs ont œuvre
2. Scrum : Les évènements pour son amélioration.
3. Scrum : Les artefacts  C’est un cadre de travail permettant de répondre aux problèmes
complexes et changeants.
4. Scrum : rôles/responsabilités  Elle favorise le développement productif et créatif de produits de
grande valeur
 Méthode itérative:
 Réalisation d’un ensemble de fonctionnalités par itération =>
Sprints
 Itération d’une durée fixe (d’1 à 4 semaines)
 Livraison d’un produit partiel fonctionnel par itération
85 86

85 86

Les fondements du modèle Scrum Scrum : Les éléments

Scrum est un cadre (ou framework) simple et efficace qui repose sur 3 piliers :  Scrum est constituée de plusieurs éléments :
 Transparence  l’Equipe Scrum et les rôles associes
 garantir que toutes les informations relatives a la bonne compréhension
du projet sont bien communiquées aux membres de l’équipe et aux
 Les évènements
différentes parties prenantes.  Les artefacts
• Un langage commun partage par tous les acteurs de la gestion de  Les règles
projet.  Les règles permettent de lier les rôles, les évènements et les
• Un management visuel qui propose des informations libres d’accès, artefacts entre eux.
pertinentes et utiles.
• Une communication bienveillante et conviviale entre tous les
acteurs du projet.
 Inspection
 vérifier à intervalles réguliers que le projet respecte des limites
acceptables et qu’il n’y a pas de déviation indésirable par rapport à la
demande du client.
 Adaptation
 encourager la correction des dérivés constatées et proposer des
changements appropries afin de mieux répondre aux objectifs de 87la 88
gestion de projet.

87 88

22
 07/02/2024

Les éléments de Scrum : Vue d’ensemble Le cycle de vie d’un projet Scrum
 Scrum est un cadre de développement dans lequel des équipes
plurifonctionnelles réalisent des produits de manière itérative et
incrémentale.
 Scrum structure le développement en cycles de travail appelés
Sprints.
 Les Sprints sont d’une durée limitée, ils se terminent à une date
spécifique, que le travail soit termine ou non, et ne sont jamais
prolonges.
 Au début de chaque Sprint, une Equipe plurifonctionnelle
(environ sept personnes) sélectionné des éléments (exigences du
client) dans une liste priorisée.

89 90

https://agiliste.fr

89 90

Le cycle de vie d’un projet Scrum Cycle de vie d’un projet Scrum : En résumé
 Aucun nouvel élément n’est ajouté durant le Sprint
 Scrum accepte le changement pour le Sprint suivant, mais
la durée fixe d’un Sprint en cours est faite pour se
focaliser sur un objectif relativement stable, clair et
limite.
 Chaque jour, l’Equipe se réunit brièvement afin de contrôler sa
progression et ajuster les prochaines étapes nécessaires à la
finalisation du travail restant.
 A la fin de chaque Sprint, une évaluation de ce qui est réalise est
faite.
 Le feedback obtenu peut être pris en compte sur le Sprint suivant.
Scrum insiste sur la nécessite de livrer un produit opérationnel à
la fin de chaque Sprint, et réellement « terminé »

91 92

https://agiliste.fr

91 92

23
 07/02/2024

Scrum : Les évènements Les évènements : Le sprint

 Un Sprint est défini pour réaliser un objectif de l’activité de
 La méthode Scrum comprend différents évènements: développement liée à la réalisation du produit attendu.
 Le Sprint  Il a une durée bien limitée (moins d’un mois)
 La réunion de planification de sprint ( Sprint Planning  Il contient et est constitue de la planification du Sprint
Meeting) (SprintPlanning), des mêlées quotidiennes ( Daily Scrums), des
 La mêlée quotidienne ( Daily Scrum) activités de développement, de la revue du Sprint ( Sprint
 La revue du sprint (Sprint Review Meeting) Review) et de la rétrospective du Sprint ( Sprint Rétrospective)
 La rétrospective du Sprint ( Sprint Rétrospective)  Il a un objectif fixe auquel est associée une liste d’ éléments du
 Les évènements sont limites dans le temps ( Boites de temps) Product backlog
 Chaque évènement est une occasion pour inspecter et adapter  Les Sprints amènent de la prévisibilité en forçant une inspection
et adaptation du progrès vers l’atteinte d’un objectif au moins
mensuellement.
 Les sprints se déroulent de façon séquentielle.

93 94

93 94

Le sprint Les évènements : La planification du Sprint

(Sprint planification Meeting)
 Le Sprint au cœur de la méthode Scrum
 Elle a pour but de planifier l’objectif du Sprint, en se basant sur
les items du Product Backlog priorises (exigences les plus
priorisées du client) par l’équipe et le product owner.
 Elle se déroulent en 2 temps:
 1ère partie : Qu’est-ce qui peut être terminé dans ce sprint?
 2ème partie : Comment l’équipe va s’organiser pour réaliser
ce travail?
 Lors de la 1ère partie, l’objectif du sprint est arrête, et dans
combien de temps il sera réalisé.
 Lors de la 2ème partie, le travail est décomposé
(développement, tests, livraison au client).
=> Le Sprint Blacklog est ainsi défini
 Les Sprints Backlogs constituent le Product Backlog.
95 96

https://agiliste.fr

95 96

24
 07/02/2024

Les évènements : La mêlée quotidienne Les évènements : La revue du Sprint (Sprint

(Daily meeting) Review Meeting)

 C’est une réunion quotidienne d’avancement qui ne dure pas plus  A la fin d’un Sprint on fait une réunion (d’une durée respectant
de 15mn.
 Elle réunit tous les membres de l’ équipe et permet d’examiner sa boite de temps) pour passer en revue l’Incrément du produit
les tâches en cours et les difficultés rencontrées (ce qui a été fait qui vient d’être « terminé » et ainsi le valider.
et ce qui va être fait).
 C’est ce qui permet de mettre au quotidien l’application des  C’est aussi l’occasion de faire un bilan, sur le fonctionnement de
principes inspection-adaptation de la méthode Scrum. l’équipe et de trouver des points d’amélioration.
 Le Scrum Master maintient un graphique (Sprint Burndown
Chart) pour la visualisation de la progression du travail.  Cela permet de décider du prochain Item du carnet du produit à
traiter dans le prochain Sprint.

97 98

97 98

Les évènements : La rétrospective du Sprint Scrum : Les artefacts

(Sprint Rétrospective Meeting)
 La méthode Scrum produits différents artefacts
 Elle fait suite a la réunion de revue du sprint.  Le carnet du produit (Product Backlog)
 Elle a pour but de mettre en place un plan d’amélioration du  Le carnet du sprint (Sprint Backlog)
processus de développement lors de la prochaine itération  L’incrément( Increment)
(Sprint).  Les fonctionnalités ( User Story)
 Elle doit aider a l’adaptation aux changements qui surviennent au  Le diagramme de progression (Sprint Burndown Chart)
cours du projet et à l’amélioration continue du processus de  Les artefacts de Scrum sont conçus pour maximiser la
réalisation. transparence d’informations essentielles
 Elle alimente l’axe inspection / adaptation.
99 10
0

99 100

25
 07/02/2024

Les artefacts : Le carnet du produit Les artefacts : Le carnet du Sprint (Sprint

(Product Backlog) Backlog)
 C’est une liste ordonnée des besoins et de tout ce qui peut être  Les items du produit sélectionnés pour être réalisés sont
requis.
 Le product owner est responsable de la gestion de son contenu. consignes dans un carnet du Sprint.
 Il est soumis a une évolution constante (besoins, marche,  Le plan de réalisation de la fonctionnalité ciblée est indique dans
technologie...). Il est dynamique.
 Il contient des items du produit à réaliser. ce carnet du produit, ainsi que le travail nécessaire (temps,
 Lorsque ces derniers sont alors réalises et valides, ils deviennent moyens...)
des incréments du produit.
 Un carnet du produit est maintenu tout au long de la vie d’un  Le carnet du sprint est mis a jour régulièrement, et est de la seule
produit. responsabilité de l’équipe de développement.
 Les items sont hiérarchisés dans un carnet du produits. Les plus
prioritaires sont finement décrits.  Les estimations des temps de travail sont mises a jour lors de
 Les items « Prêts » réputés seront sélectionnés dans la chaque Daily meeting.
10 10
planification du prochain Sprint. 1 2

101 102

Les artefacts : L’incrément (Increment) Les artefacts : Fonctionnalité (User story)

 L’incrément est constitue des éléments « terminés » lors de  Les user stories décrivent les fonctionnalités.
l’itération en cours (sprint actuel) et des autres sprints déjà  Chaque user story contient plusieurs informations ( ID, Nom,
accomplis. Importance, Estimation, Démo, Notes )
 L’incrément déclaré « terminés » doit être utilisable, même s’il
n’est pas encore publie.

10 10
3 4

103 104

26
 07/02/2024

Scrum : Rôles/responsabilités Scrum : Rôles/responsabilités

Le propriétaire du produit (product owner)
• C’est une personne qui joue le rôle du client et des utilisateurs.
• C’est un expert métier.
 L’équipe Scrum comprend différents membres remplissant des • Il définit les fonctionnalités du carnet du produit (Product Backlog), et les priorise.
• Il est le seul habilité à prendre les décisions sur l’orientation du projet.
rôles : • Il est charge de maximiser la valeur du produit et du travail de l’équipe de
développement.
 Le propriétaire du produit ( product owner)
Le maître Scrum (Scrum master)
 Le maître Scrum (Scrum master) • Il joue le rôle de facilitateur et gardien de la bonne application.
• Il est au service du product owner.
 L’équipe de développement (development team) • Il facilite les interactions entre les membres de l’équipe Scrum.
• Il veille à la mise en œuvre de l’agilité.
 Elle est auto-organisée et pluridisciplinaire. • Il agit sur le processus de développement (développement, définition de la durée des
Sprints, des modalités de tenues et de l’ordre du jour des réunions scrum...)
 L’équipe Scrum suit un modèle favorisant l’optimisation, la
L’équipe de développement (Development team)
flexibilité, la productivité et la créativité.
• Elle est composée de 3 à 9 membres (aucun membre n’a un rôle particulier).
• Elle est auto-organisée et pluridisciplinaire
10 10
5
• Elle est en charge de la réalisation du produit. 6

105 106

Rôles d’un scrum master Rôles d’un Product Owner

 La participation active du client dans la gestion du projet est un
principe incontournable de toutes les pratiques agiles.
 Anime l’équipe  Il faut définir avec lui les fonctionnalités à réaliser afin de
développer son produit ou son service.
 Protège l’équipe
 Cependant, un client peut rencontrer plusieurs difficultés avec le
 Elimine les obstacles Scrum :
 Manque de disponibilité pour le projet
 S’assure que l’équipe est fonctionnelle et productive
 Manque d’expérience en gestion de projet agile
 Résout les problèmes non techniques (administratifs)  Manque d’informations sur les utilisateurs
 Le product owner ne joue pas le rôle d’un supérieur hiérarchique.
 Vérifie le respect des valeurs de Scrum
 Il est recommande de l’installer dans la même pièce que l’équipe.
 Ce n’est pas un chef de projet!  Il est indispensable de l’inviter a rester très disponible pour qu’il
réponde aux questions et donne son avis.

10 10
7 8

107 108

27
 07/02/2024

Le rôle d’une équipe de développement

 Les membres de l’équipe de développement sont en charge des
opérations du projet.
 Ils livrent le client a intervalles réguliers des fonctionnalités
complètes.
 ils ont de multiples compétences
 ils sont pluridisciplinaires
 ils sont autonomes
 une équipe est formée de 3 à 9 personnes capables de réaliser le
projet sans l’aide de membres extérieurs.

”Bon” ou ”Mauvais”,
Encourager le
ne jamais attribuer
partage des
les résultats à un
responsabilites
seul individu
10
9

109

28