Gestion de Projets

CHAPITRE 2
Les approches agiles
et Le framework SCRUM

Dorra Guermazi Ammous

 Gestion dirigée par les
plans
La gestion prédictive fonctionne à condition d’avoir:

- Une stabilité des besoins

- des choix parfaits dès le depart

Dans le cas contraire, si les besoins s’avèrent instables où on veut

changer des choix : la gestion devient diffcile, lente...

Sinon , il y a une alternative:

L’agilité
 AGILE = RAPIDE

S’adapte au changement
 L’approche prédictive

Gestion dirigée par les

plans
Une vision linéraire du projet

Découpage du projet en phases du cycle de vie

Le chef de projet dirige et organise le travail

Le contrat de réalisation est figé

Quasi-définitif sauf en cas de demande de changement
Formelle et redaction d’un avenant

Il existe des spécialistes par tâches:

Analyste, designer, développeur
 6

L’approche agile

Gestion dirigée par la

valeur
Une vision cadencée du projet

Découpage du projet en incréments

Responsabilité collective
Représentant Facilitateur
Du métier
ou du client

Pas de gèle des demandes en début de projet : changements et

eclairsissement des idées accepté
 7

DEFINITION DE SCRUM
Un Framework de
gestion de projets
Pour développer des

IMPLEMENTATION
produits complexes et

RETROSPECT
SPRINT
ou changeants
Par une approche
itérative et PLANNING

incrémentale
 8

Pour maitriser SCRUM

3 SCRUM TEAM ROLES 4 EVENTS 4 ARTIFACTS

3 rôles 4 évènements 4 Artefacts
outils
 9

Pour maitriser SCRUM

3 SCRUM TEAM ROLES 4 EVENTS 4 ARTIFACTS

3 rôles 4 évènements 4 Artefacts
outils

Product Owner Sprint planning Backlog Produit

Équipe de développement Daily Scrum Definition of done
SCRUM Master Sprint review Sprint Backlog
Sprint retrospective Product Increment
 10

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT SPRINT
RETRO PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

SPRINT DAILY
REVIEW SCRUM

PRODUCT INCREMENT DEFINITION OF SPRINT

“DONE” BACKLOG
 Backlog du produit donne planifiaction du sprint 11

SCRUM TEAM ROLES

ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER
 planification du sprint donne le sprint backlog 12

SCRUM TEAM ROLES

ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

SPRINT
BACKLOG
 13

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

DAILY
SCRUM

SPRINT
BACKLOG
 14

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

DAILY
SCRUM

DEFINITION OF SPRINT
“DONE” BACKLOG
 15

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

DAILY
SCRUM

PRODUCT INCREMENT DEFINITION OF SPRINT

“DONE” BACKLOG
 16

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

SPRINT DAILY
REVIEW SCRUM

PRODUCT INCREMENT DEFINITION OF SPRINT

“DONE” BACKLOG
 17

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT SPRINT
RETRO PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

SPRINT DAILY
REVIEW SCRUM

PRODUCT INCREMENT DEFINITION OF SPRINT

“DONE” BACKLOG
 18

Le backlog du produit : Product Backlog

C’est une liste dynamique et ordonnée des
exigences (du client, des utilisateurs, de la
fonction métier concernée par le produit, etc.)
et de tout ce qui va entraîner du travail au
projet, définie par le PO.
 19

Le Backlog du sprint : sprint Backlog :

contient des éléments sélectionnés du
Backlog du produit et les tâches de
l’équipe pour le sprint courant afin de les
réaliser.
Definiton of done : DOD : c’est une liste de critères 20

définie par l’équipe Scrum qui permettent d’affirmer

qu’un élément (item, par exemple une user story) peut
être considéré comme fini (done). Exemples de critères :
revue du code effectuée – documentation utilisateur mise à jour
 21

La planification du sprint : Sprint Planning : réunion de l’équipe

scrum (y compris PO) qui répond aux questions :
- Quoi ? pour avoir une bonne idée du périmètre + but du sprint
(quelles sont les fonctionnalités qui seront réalisés pendant ce sprint ?
Quels sont les éléments du backlog du produit sélectionnés et qui
vont constituer le sprint backlog ,
- Comment ? Ensuite identifier les tâches nécessaires pour l’atteindre
et les estimer, dans une séance de travail collectif.
Daily Scrum : réunion de l’équipe de développement pour 22

présenter ce qui a été fait, ce qui va être fait d’ici le prochain

daily scrum et pour identifier les obstacles (qu’est ce j’ai fait
hier, ce que je prévoie de faire aujourd’hui, qu’est ce qui freine
mon travail ?).
Le but est de maintenir l’équipe concentrée sur l’objectif du
sprint et optimiser la probabilité de l’atteindre.
Le scrum master peut y être mais ce n’est pas obligatoire. S’il
y assiste, c’est dans le but de ne pas y être la prochaine fois,
c’est-à-dire aider l’équipe de développement à bien mener
seule cette réunion, à être autonome !
 23

La revue du sprint : sprint review : une réunion.

Son but est de montrer ce qui a été réalisé pendant
le sprint, elle accueille l’équipe scrum et les parties
prenantes (stakeholders). La revue montre le
produit (ou l’incrément de produit).
 24

La rétrospective du sprint : Sprint retrospective :

permet à l’équipe de faire ressortir les éléments qui
ont bien fonctionné et ceux qui restent à améliorer.
Des actions concrètes sont alors proposées pour le
sprint suivant. Elle est généralement animée par le
scrum master. La rétrospective améliore les
processus.
 25

1. SCRUM ROLES

PRODUCT DEVELOPMENT SCRUM

OWNER TEAM MASTER

Définit le produit Réalise le meilleur Facilite les échanges et

répondant aux attentes produit l’amélioration
des Utilisateurs
 26

1. SCRUM ROLES
Toute l’équipe SCRUM cherche
à satisfaire les Utilisateurs et fabriquer le meilleur produit possible

PRODUCT DEVELOPMENT SCRUM

OWNER TEAM MASTER

Définit le produit Réalise le meilleur Facilite les échanges et

répondant aux attentes produit l’amélioration
des Utilisateurs
 1. Product Owner: PO 27

- Disponibilité continue
PRODUCT
OWNER - Participe aux cérémonies évènements SCRUM

- Création et MAJ du Backlog du produit

- ajuster les priorités de façon à avoir un produit avec le

maximum de valeur, priroriser et reprioriser le Backlog
du produit

- définir les tests d’acceptation

- aider aux tests d’acceptation

- Collabore avec l’équipe et grâce aux synergies

maximise la valeur ajoutée du produit
 28
2. SCRUM MASTER

- Veille à l’application de Scrum et son adaptation

au contexte par l’équipe
SCRUM
MASTER - Encourage l’équipe à apprendre et progresser

- Fait en sorte d’éliminer les obstacles

- incite l’équipe à devenir autonome

- protège l’équipe des interférences extérieures

pendant le sprint

- a une influence sur la façon de travailler, par

equivalence au PO, c’est un process owner

- aptitude à comprendre les aspects techniques

 3. L’équipe de développement 29

- Pas de titre ni de sous-équipe

- Multifoncionnelle et Interfonctionnelle (cross-

DEVELOPMENT
TEAM functional)

- De préférence à plein temps sur le projet

- Auto-organisée: définit elle-même la façon dont elle

organise ses travaux

- s’approprie le travail et détermine comment livrer

régulièrment sous forme de blocs successifs

- Sa composition ne doit pas changer au cours d’un sprint

 En plus des : 30

3 SCRUM TEAM ROLES 4 EVENTS 4 ARTIFACTS

3 rôles 4 évènements 4 Artefacts
outils

Il est important pour pratiquer scrum de

connaître les notions de

User story Estimation des Vélocité de la Team

User Stories
 31

Rappelons que

Le product Backlog est une liste dynamique et ordonnée

des exigences des utilisateurs pour différentes fonctinnalités
= les Users Stories

La user story correspond au format:

“En tant que”….je souhaite”….“afin de”….
permet de poser les variables les plus importantes de la
fonctionnalité : le Qui ? le Quoi ? et le Pourquoi ?
 32

Comment estimer une User Story ?

En méthodologie prédictive, on est habitué à une

estimation horaire qui :
- ne tient pas compte explicitement de la complexité
- dépend de l’estimation personnelle de chaque membre
selon son expérience et son degré de spécialisation dans
un domaine précis

Qu’en est-il pour l’estimation en méthodologies agiles ?

 33

Comment estimer une User Story ?

En méthodologie agiles on a recours à la notion de points de

complexité ou plus généralement aux Story Points

Il s’agit de choisir une échelle pour estimer les User Stories

Plusieurs échelles sont possibles:

- La séquence de Fibonacci (0,5 ; 1 ; 2 ; 3 ; 5 ; 8 ; 13 ; 20 ;
30 ; 50 ; 100 ; 200) elle a l’avantage d’être non-linéaire,
l’intervalle entre deux échelons est croissant

- les tailles de T-shirts : XS, S, M, L, XL et XXL

 34

Comment attribuer les points à une User Story ?

Il s’agit d’estimer la complexité via des critères :

- l’effort à faire pour accomplir la tâche

- la complexité de la tâche
- les risques identifiés
- les dépendances extérieures à la Scrum team (besoin
d’information, prérequis sur l’environnement de
développement, etc)

Ces points sont donc effectivement liés au temps, mais

ils ne sont pas traduits en unité de temps.
 C’est quoi alors la vélocité d’une équipe agile ? 35

Rappelons que:
L’estimation est généralement réalisé en Sprint planning:
Afin de se décider sur les items ou les user stories à intégrer
dans un sprint, il faudra déterminer le nombre de story
points réalisables par sprint = la vélocité

La somme des Story points des User Stories intégrées dans

un Sprint représente l’engagement que se donne l’équipe.

La somme des Story points des User Stories qui seront

effectivement terminées à la fin de l’itération définit la
vélocité de l’équipe.
 Conclusion 36

User story Estimation des Vélocité

User Stories

En agilité, l’idée d’abandonner le traditionnel jour-homme,

a le mérite de construire un référentiel propre à l’équipe,
et lui permet de:

- Progresser et de mesurer ses progrès, surtout en début

de projet: Quand le nombre de points réalisés par sprint
augmente il s’agit d’un gain de vélocité

- De stabiliser ensuite la vélocité et de maintenir un

rythme soutenable sur la durée du projet