Gestion de Projets

CHAPITRE 2
Des approches prédictives aux approches
agiles

Dorra Guermazi Ammous

S1 . Les fondamentaux des
approches prédictives

2
Processus d’initialisation

3
les 5 Groupes de Processus, vision linéaire

Initialisation Planification Exécution et Maîtrise Clôture

Après le travail d’appréhension du
projet ainsi que la réception des
documents business et
Éventuellement des accords (contrats
avec partie externe),
Le démarrage du projet doit être
formalisé dans un document qui
s’appelle LA CHARTE du projet
En initialisation, dans la charte, il y a
un premier travail
d’identification et d’estimation de
l’ordre de grandeur
- du coût,
- des risques
- des contraintes
- des hypothèses
Qui sera affiné par la suite dans la
planification
 Définitions importantes
- Contrainte / Constraint. Facteur
existant qui limite les options de
réalisation du projet, ou d’un
processus.
- Hypothèse / Assumption. un
facteur qui est considéré comme
vrai, réel ou certain, afin de pouvoir
avancer dans la planification (en
général ayant une forte probabilité de se produire)
 Définitions importantes
- Risque: Événement ou condition
possible dont la concrétisation
aurait un impact positif ou négatif
sur un ou plusieurs objectifs du
projet.
- Risque global du projet / Overall
Project Risk. Effet de l’incertitude
sur l’ensemble du projet, provenant
de toutes les sources possibles
 Remarque importante
- Au niveau de l’estimation de l’ordre de
grandeur, on doit définir la marge de
précision de cette estimation
- Au début de l’élaboration de la charte,
la marge de précision préconisée est de
-25% à + 75%
- Cette marge de précision sera par la
suite affinée durant la planification
 Processus de planification

- Planification du périmètre
- Planification de l’échéancier
- Planification du budget

10
Processus de planification en lien avec le
périmètre (Scope)

1. Recueillir les exigences

2. Définir le périmètre (énoncé du
périmètre, peut être sous forme de
cahier des charges)
3. Créer la Structure de découpage
du projet SDP ou WBS
Recueillir les exigences

La réussite du projet est directement fonction de

l’implication active des parties prenantes dans la
découverte et la décomposition des besoins en
exigences:

- du produit (spécifiques au secteur)

- du service ou du résultat du projet.
Définir le périmètre
- processus qui consiste à élaborer une
description détaillée du projet et du produit:
du contenu
des livrables
des critères d’acceptation
des exclusions
- Peut être sous forme de cahier des
charges
Créer la SDP ou WBS
- processus qui consiste à subdiviser les livrables
et le travail du projet en composants plus petits
et plus faciles à maîtriser (estimer le temps et
le coût)

- Le WBS est une décomposition hiérarchique du

périmètre qui représente le travail spécifié
dans l’énoncé du périmètre du projet
actuellement approuvé.
WBS :Work Breakdown Structure WBS
ou SDP: structure de découpage du projet

Il s’agit du passage d’une logique

fonctionnelle de résultats vers une
logique de travaux à faire.

Le travail prévu se trouve au niveau le

plus bas des composants du WBS, qui
sont appelés lots de travaux.

15
Projet de construction d’une maison: quels sont les
travaux à faire pour mettre en œuvre le bâtiment ?
Exemple de WBS pour la construction d’une maison
Projet de réalisation d’un
logiciel informatique Centres de
consolidations

Projet :
Produit
logiciel

Etude
Conception Réalisation Déploiement
préalable

Cahier de
Rapport de spécification
Réunions avec Cahier de Installation Formation Assistance
l’étude fonctionnelles Codage Tests Manuels
utilisateurs recettes sur site Utilisateurs Utilisateurs
préalable et techniques
détaillées

Cahier de Cahier de
spécification spécification Manuel Manuel
fonctionnelle technique utilisateur d’exploitation
détaillée détaillée

Lots de 18
travaux
Processus de planif. en lien avec
l’échéancier

- 1 Définir les activités

- 2 Organiser les activités en
séquence
- 3 Estimer les ressources
- 4 Estimer la durée des activités
- 5 Elaborer l’échéancier
1 et 2 Définir les activités et les organiser
en séquences

On dispose grâce à la WBS d’ une

décomposition aussi fine en lots et sous-lots
de travaux gérables.
On doit les définir et les organiser en
séquence

19
3 Estimer les ressources
Il reste à les affecter aux différents membres
de l’équipe de projet (acteurs)

On passe alors d’une logique de travaux….

à une logique de responsabilités

20
Pour Organiser les activités en séquence
Mais aussi élaborer l’échéancier on utilise plusieurs
techniques

Par exemple la technique PERT

Program Evaluation and Review Technique

C’est une Technique d'ordonnancement et de contrôle

des programmes.
Planification liée à l’ échéancier
Elaborer l’échéancier: le diagramme de
Gantt
- A partir du réseau PERT, on peut dresser le
diagramme de Gantt
- Le diagramme de Gantt établit le planning des
opérations
T1 T2 … … … Tn

Tâche A

Tâche B

……

Tâche K
Calendrier de réalisation: le
diagramme de Gantt
- Il est possible de modéliser le temps estimé pour
une tâche par une barre horizontale
- les tâches peuvent s’enchaîner séquentiellement
ou en parallèle.
T1 T2 … … … T12

Tâche A
Analyste
Tâche B
Concepteur
……

Tâche K
Testeur
A partir du diagramme de Gantt, il est possible
de visualiser divers scénarios:

- d’affectation des ressources ( nombre de

personnes à affecter au projet, affectation des
tâches aux ressources humaines, équilibrage
de la charge de travail entre les équipes)

- d’organisation du travail (prise en compte

des temps morts, jours de congé, etc.)
A partir du diagramme de Gantt, il est possible
de visualiser divers scénarios:

- avoir une vue sur l’avancement du projet à

une date donnée, en traçant une ligne
verticale traversant les tâches au niveau de
cette date

- faire apparaître sur le calendrier de

réalisation des jalons.
Le jalon est un évènement associé à :

- Un point sur l’avancement du projet

- Un livrable intermédiaire
- Une approbation ou validation par les
décideurs

Un jalon est généralement associé à une

réunion élargie qui regroupe l’ensemble des
acteurs: comité de pilotage du projet COPIL,
chef et équipe du projet, client, etc.
Le jalonnement des étapes du projet permet
d’éviter ce qu’on appelle l’effet tunnel.

- L’effet tunnel est le fait de se retrouver dans

une période où on a peu de visibilité sur la
progression du projet (projets longs et
complexes).

- La complexité d’un projet n’est pas liée à la

difficulté technique mais plutôt à la difficulté
de coordination lorsque les intervenants
sont nombreux et pluridisciplinaires.
- Sans jalons, il est difficile de connaître l’état
d’avancement du projet.

- Dans certains projets, l’effet tunnel risque d’aboutir

à un désintérêt des décideurs ou dans des cas
extrêmes à un oubli des commanditaires.
Planification liée au Budget

- Estimer les coûts

- Déterminer le budget
La démarche est la suivante :

- Estimer les coûts des activités ( par exemple

pour les ressources humaines : il s’agit du
(nombre de jours de travail) multiplié
par (jour/homme), le taux journalier de
l’intervenant concerné ( designer, développeur,
junior, sénior, etc.)
- faire la somme des coûts des activités qui
composent les différentes lots de travaux
- ajouter des réserves pour aléas :une sorte de
provision associée à l’incertitude sur les coûts
En résumé, la Planification c’est :

Etablir le périmètre total de l’effort,

définir et affiner les objectifs,
développer la suite d’actions
nécessaires pour atteindre ces
objectifs.
Processus d’exécution et de
maitrise

33
 EXECUTION

L’équipe va réaliser le travail défini dans le plan de

management du projet pour satisfaire aux
exigences du projet grâce à :
- la coordination des ressources,
- la gestion de l’engagement des parties
prenantes,
- la conduite des activités du projet
conformément au Plan de Management du
Projet.
 LA MAITRISE

- La maîtrise consiste à collecter les données

de performance du projet, définir des
mesures de performance, générer des
rapports et diffuser les informations
correspondantes.
Ensuite à comparer les performances réelles
aux performances prévues, analyser les
écarts, évaluer les tendances dans le but
d’améliorer les processus, évaluer les
alternatives possibles et recommander les
actions correctives appropriées
La clôture du projet

37
 Les processus de clôture
Les informations, les retours d’expérience du
projet sont archivés, le travail prévu est achevé et
les ressources organisationnelles sont libérées afin
de mener d’autres projets.
S2 . Les fondamentaux des
approches agiles

39
 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
 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
Les 4 VALEURS DE L’AGILITE sont préférées aux 4 VALEURS DES APPROCHES
PREDICITIVES

05/12/2022 43
 44

AGILE CORE VALUES

Individual and Customer

team collaboration over
interactions over contract
processes and negotiation
tools.

Working software Responding to

over change over
comprehensive following a plan
documentation
 45

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é
46
 47

AGILE METHODOLOGIES

FEATURE DRIVEN
SCRUM
DEVELOPMENT (FDD)

CRYSTAL LEAN SOFTWARE

METHODOLOGIES DEVELOPMENT

DYNAMIC SOFTWARE DEVELOPMENT EXTREME

METHOD (DSDM) PROGRAMMING (XP)
 48

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
 49

Pour maitriser SCRUM

3 SCRUM TEAM ROLES 4 EVENTS 4 ARTIFACTS

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

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
 51

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 52

SCRUM TEAM ROLES

ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

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

SCRUM TEAM ROLES

ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

SPRINT
BACKLOG
 54

SCRUM TEAM ROLES

SCRUM FRAMEWORK
ARTIFACTS

EVENTS
PRODUCT
BACKLOG &
SPRINT
REFINEMENT
SPRINT
PLANNNING

SCRUM
MASTER

DEVELOPMENT
STAKEHOLDERS PRODUCT
TEAM
OWNER

DAILY
SCRUM

SPRINT
BACKLOG
 55

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
 56

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
 57

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
 58

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
 59

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.
 60

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 61

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
 62

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 63

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 !
 64

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).
 65

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.
 66

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
 67

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 68

- 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
 69
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 70

- 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