Gestion de projet

Méthodes agiles

Emmanuel CHAUVET
Planning
• lun. 02/10/23
• ven. 20/10/23
• mar. 31/10/23
• ven. 24/11/23
• lun. 27/11/23

Gestion de projet - Méthodes agiles 2

01
Les fondamentaux
de l’agilité

Gestion de projet - Méthodes agiles 3

 Réduire le cycle de vie du logiciel

Objectifs
et accélérer son développement

des
Développer une version minimale
via l’intégration de fonctionnalités

méthodes Processus itératif et adaptatif basé

sur une écoute client

agiles Tests tout au long du cycle de

développement

Gestion de projet - Méthodes agiles 4

Instabilité de l’environnement

Origines
technologique

des
Client incapable de définir les besoins de
manière exhaustive en début de projet

Adaptation aux changements durant le

projet : évolution des spécifications en méthodes
agiles
cours de projet

2001 : Manifeste agile constitué par 17

personnes, avec une volonté de rupture
avec la gestion de projet classique

Gestion de projet - Méthodes agiles 5

 Nous découvrons comment mieux développer des logiciels
par la pratique et en aidant les autres à le faire.
Ces expériences nous ont amenés à valoriser :

Le
Les individus et leurs interactions plus que les
processus et les outils

Des logiciels opérationnels plus qu’une

Manifeste
documentation exhaustive

La collaboration avec les clients plus que la

Agile
négociation contractuelle

L’adaptation au changement plus que le suivi d’un

plan

Nous reconnaissons la valeur des seconds éléments,

mais privilégions les premiers.
http://agilemanifesto.org/iso/fr/manifesto.html
Gestion de projet - Méthodes agiles 6
 Le client est Première mise

Bénéfices
pilote à part en production
entière de son très rapide du
projet produit

pour le
client
Association
des utilisateurs Disparition des
et des cloisons
communautés Avant-Projet /
au plus tôt Projet / Produit
dans le projet

Gestion de projet - Méthodes agiles 7

Cycle en V vs Agilité
Itération 1 Itération 2 Itération n
Tests du Analyse Analyse Analyse
Analyse
système

Développement Développement Développement

Conception Tests
générale d’intégration Ecrits en même temps que le code, ou avant

Tests unitaires Tests unitaires Tests unitaires

Automatisés dans le build quotidien

Conception
Tests unitaires Tests Tests Tests
détaillée
d’intégration d’intégration d’intégration

Menés par une équipe de qualification sur le périmètre de

l’itération précédente, et automatisés pour la non-régression
Tests du Tests du
Développement système système

Gestion de projet - Méthodes agiles 8

2
Inventaire (partiel) des méthodes agiles

Gestion de projet - Méthodes agiles 9

Un peu d’histoire

1991 1987-1999 1999

RAD UP XP

1994 1998-2003 2001

DSDM RUP Scrum

Gestion de projet - Méthodes agiles 10

RAD – Rapid Application Development
James Martin (1991)

Cadrage

Cycle de développement
court (90 à 120 jours
max)
Construction Design

Gestion de projet - Méthodes agiles 11

DSDM – Dynamic Software Development Method
Basé sur RAD (UK, 1994)

Implication des utilisateurs durant tout le cycle de développement

Autonomie L'équipe projet a un pouvoir de décision sur l'évolution des besoins

Visibilité du résultat Application livrée le plus souvent possible pour avoir un feed-back rapide

Adéquation Livrer une application en adéquation avec le besoin du client

Développement itératif et incrémental Evolution du développement basée sur le feed-back des utilisateurs

Réversibilité Toute modification effectuée durant le développement est réversible

Synthèse Schéma directeur défini au préalable pour fixer le périmètre du projet

Tests continus durant le développement pour garantir le fonctionnement de l'application

Coopération Acteurs du projet faisant preuve de souplesse sur les modifications demandées

Gestion de projet - Méthodes agiles 12

UP – Unified Process
Ivar Jacobson (initié dès les années 60, première formalisation en 1987)

Développement itératif et incrémental

Segmentation en phases courtes

Livraison systématique en fin de phase d’une nouvelle version incrémentée

Modélisation UML pour l'architecture (fonctionnelle, logicielle et physique)

Cas d'utilisation (use case) pour les besoins et exigences des utilisateurs

Gestion de projet - Méthodes agiles 13

RUP – Rational Unified Process
Implémentation d’UP proposée par Rational Software (racheté depuis par IBM)

Gestion et Approche Modèles de

composition temporelle documents
en rupture par deadline
avec
l’approche
traditionnelle
des équipes

Gestion de projet - Méthodes agiles 14

XP – eXtreme Programming
Kent Beck, Ward Cunningham, Ron Jeffries & Palleja Xavier (1999) - Systématisation extrême de pratiques pré-existantes

Revue de code bonne pratique faite en permanence (par un binôme)

Tests utiles faits systématiquement avant chaque mise en œuvre

Conception importante faite tout au long du projet

Simplicité avancer plus vite solution la plus simple

Intégration des modifications cruciale plusieurs fois par jour

Besoins évoluent vite cycles de développement très rapides

Gestion de projet - Méthodes agiles 15

Scrum (= mêlée de rugby)
Présentation détaillée dans la prochaine partie

Stand up
Livraison en fin
Product Sprint d’itération
backlog backlog

Sprint

Gestion de projet - Méthodes agiles 16

Synthèse et recommandations

Ne pas choisir une méthode mais s’inspirer des existantes

• Le client est au centre du projet

Garder en tête les principes • Moins de documentation et plus de livraisons

• Deadline et découpage en phases courtes
agiles • Implication et autonomie des équipes
• Tests tout au long du projet

Une question à se poser « Le client est-il agile ? »

Corollaire : s’il ne l’est pas, comment faire de l’agilité ?

Gestion de projet - Méthodes agiles 17

03
Scrum
Une méthode agile adaptable à tous
types de projets

Gestion de projet - Méthodes agiles 18

 Un peu d’histoire

2001
1986
Ken Schwbaer & Mike
2011
Hirotaka Takeuchi & Beedle (Agile
Ikujiro Nonaka (The Software Jeff Sutherland et Ken
New New Product Development With Schwaber (The
Development Game) Scrum) Scrum Guide)

1991 2004
Ken Schwaber Ken Schwaber (Agile
(description des Software
fondements de la Management with
future méthode) Scrum)

Gestion de projet - Méthodes agiles 19

 Notions fondamentales & vocabulaire

Stand up
Product Sprint Planning meeting ou
Sprint Livraison User story
backlog backlog poker Morning
meeting

Découpage du à la fin de chaque Description d’une Liste de l’ensemble Liste des Estimation de Réunion
projet en itérations sprint fonctionnalité des fonctionnalités fonctionnalités à charge des tâches quotidienne de
de 2 à 4 semaines attendue attendues produire pendant avant chaque tous les acteurs du
selon le projet un sprint, non sprint projet
modifiable
pendant le sprint

Gestion de projet - Méthodes agiles 20

Déroulement d’un sprint

Stand up
Livraison en fin
Product Sprint d’itération
backlog backlog

Sprint

Gestion de projet - Méthodes agiles 21

3 piliers

Cérémonies Acteurs

Artefacts

Gestion de projet - Méthodes agiles 22

Les Stakeholders
Product

acteurs du
owner

Team Scrum

projet
member Master

Gestion de projet - Méthodes agiles 23

Représentant officiel du client, présent avec l’équipe

Interlocuteur principal du scrum master et des team

Product
members
Répond aux questions qui surviennent (stories, maquettes…)

owner
Formalise les besoins du produit et rédige les spécifications

Se fait aider de responsables fonctionnels pour la rédaction

des spécifications

Définit et priorise les users stories pour chaque sprint

Gestion de projet - Méthodes agiles 24

 Veille à la mise en application de la
méthode et au respect de ses
objectifs

Scrum Lève les obstacles éventuels qui

empêcherait l'avancement de

master
l'équipe et du projet pendant les
sprints

! Ce n’est pas un chef de projet !

Gestion de projet - Méthodes agiles 25

Chargé de la Développeur,
réalisation du sprint et Architecte,
Testeur,
d'un produit utilisable Infographiste,
Intégrateur…
en fin de sprint

Impliqué très en amont dans le

Team
member
projet

Participe à l’évaluation de charge,

à la conception, aux arbitrages
techniques…

Gestion de projet - Méthodes agiles 26

 Ensemble des autres
parties prenantes du
projet

Stakeholder
Principalement les
utilisateurs finaux ou
clients du projet

Expriment leurs
attentes/besoins au
Product owner

Gestion de projet - Méthodes agiles 27

 Les
Burndown Product
chart backlog

User story
Sprint
backlog artefacts

Gestion de projet - Méthodes agiles 28

 Le Product backlog
« Simple » inventaire des user stories

Valeur métier : priorisation selon

les critères métier (la valeur
accordée à la story)
User Stories Valeur métier Story points
Story points : estimation de l’effort Story A 1 5
nécessaire à la production de la
story Story B 2 8

Story C 3 1

Story D 4 8

Story E 5 2

Story F 6 2

Story G 7 2

Gestion de projet - Méthodes agiles 29

 Le Sprint backlog
Sélection de stories
• à produire pendant un sprint
• par le product owner
• en accord avec le scrum User Stories Valeur métier Story points
master et les team members User
Story A 1 5 Stories Priorité métier Story points
• construit au fur et à mesure de Story A 1 5
l’avancement (1 à 2 sprints à Story B 2 8
l’avance) Story C 3 Story
1 C 3 1

Story D 4 8

Story E 5 2

Story F 6 2

Story G 7 2

Gestion de projet - Méthodes agiles 30

Les User stories
Décrivent les fonctionnalités à produire

Fonctionnelles Utilisateur
Décrivent les attentes Rédigées du point de
vis-à-vis du produit vue de l’utilisateur
de la fonctionnalité

Simples & Synthétiques :

claires Le product owner
En les lisant, le (PO) est là pour
développeur sait ce répondre aux
qu’il a à faire questions qui
pourraient survenir

Gestion de projet - Méthodes agiles 31

 Titre Rédigé par le PO

Modèle de user story (format A5) Rattachement Défini par le PO et l’équipe

Titre Rattachement Valeur métier Définie par le PO

Valeur métier Propriétaire

Propriétaire Défini par le PO, sauf pour les US technical ou defect

Effort Affectation
Effort Estimé par l’équipe
Type de carte Statut
Affectation Définie par l’équipe
Objectif Critères d’acceptation
Défini par le PO (US fonctionnelle) ou par l’équipe (US
En tant que… Type de carte technical ou defect)
Je souhaite…
Afin de… BDD
Statut Défini par l’équipe
Given that (Etant donné
que)
When (Quand) Objectif Rédigé par le PO
Then (Alors)
Critères d’acceptation Définis par le PO, enrichis par l’équipe

BDD (Behaviour Driven

Définis par le PO, enrichis par l’équipe
Development)

Gestion de projet - Méthodes agiles 32

Les différents champs d’une user story
Titre identifie la US au sein du backlog, donc clair et concis description de l’action utilisateur, purement
fonctionnelle (pas de technique, pas d’IHM)
respecte la formulation rituelle
généralement à une feature (ensemble de Objectif « En tant que » (caractéristiques utilisateurs)
Rattachement fonctionnalités liées)
« Je veux » (exigence utilisateur)
« Afin de » (bénéfice utilisateur)
indicateur d’importance et de priorité (de 0 à 100 par
Valeur métier ex.)

désigne le responsable de la validation de la US

Propriétaire produite (généralement le product owner)
description des critères que le propriétaire de la US
va contrôler pour valider ou rejeter la livraison (ex :
Critères d’acceptation règles métiers à appliquer, textes à afficher…)
estimation de l’effort nécessaire pour la réalisation de peut contenir des informations/contraintes techniques
Effort la US (cf. planning poker, t-shirt sizing) (ex : regexp email, captcha, dédoublonnage…)

Affectation qui va développer la US

description des cas de test ; permettent au d’écrire les
scénarios des test en même temps (voire avant) qu’il
user story fonctionnelle (la base), technical story (ex : développe
Type de carte traitement auto), defect story (bug) BDD (Behaviour Driven respecte la formulation rituelle
Development) « Etant donné que » (contexte)
« Quand » (action utilisateur)
état à l’instant t (ex : à faire, en cours, en test, validé, à
Statut livrer…) « Alors » (comportement/résultat attendus)

Gestion de projet - Méthodes agiles 33

Des user stories « INVEST »

Aucune
I NV E S T
Indépendante Négociable

Discussion entre
Valeur

Apporte une valeur

Estimable

Suffisamment claire
Small

Suffisamment petite
Testable

Les tests doivent

dépendance avec PO et équipe… tant à l’utilisateur, donc pour que l’équipe pour être planifiée découler de la story
les autres stories que la story n’est exprime l’objectif puisse estimer simplement et sur de façon évidente
afin d’éviter des pas dans un sprint de l’utilisateur l’effort nécessaire un seul sprint
problèmes de tests
et de planification

Gestion de projet - Méthodes agiles 34

Le Burndown chart
• Graphique d’avancement basé sur le « reste à faire »
• Indique l’effort en fonction du temps restant (jours, sprints…)
• Souvent utilisé pour piloter les sprints ou les releases
• Mise à jour fréquentes : quotidienne pour les sprints, fin de sprints pour les releases

Burndown chart de sprint (sprint de 2 semaines) Burndown chart de release

120 250
100 200
80 150
60 100
40 50
20
0
0 Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint Sprint
Lu Ma Me Je Ve Lu Ma Me Je Ve 1 2 3 4 5 6 7 8 9 10

Idéal Réel Idéal Réel

Gestion de projet - Méthodes agiles 35

Les
Sprint
Sprint planning
retrospective

cérémonies Sprint review

Stand-up meeting
/ Dayly standup /
Dayly meeting /
Dayly scrum

Gestion de projet - Méthodes agiles 36

Le Sprint planning

Qui ? Team members, Scrum Master, Product Owner

Quand ? Début de sprint

Combien de Environ 1 h par semaine de sprint

temps ?

• Construction du sprint backlog (sprints longs) ou basée sur le sprint backlog (sprints courts)
Quoi ? • Définition, estimation (en heures) et attribution des tâches en fonction des user stories du sprint backlog

Respect du cycle agile : (tests unitaires)

• Spécifications détaillées des user stories (tests • Intégration et des composants (tests d’intégration)
Contraintes d’acceptation) • Package produit (livraison)
• Remaniement de l’architecture si nécessaire • Passage des tests d’acceptation
• Conception, implémentation et tests des composants

Gestion de projet - Méthodes agiles 37

 Le Planning poker

0 0,5 1 2 3 5 8 • Evaluations de complexités relatives de user story

• Choix d'1 ou 2 étalons (fonctionnalités connues)
• Attributions de valeurs (non extrêmes) aux étalons
• Cycles d'évaluation "secrète"/débat jusqu'à obtention de
13 20 40 100 ? ∞ l'unanimité
• Peut être fait en début de projet, puis affiné ensuite
Principe

Ludique (utilisation des cartes)• • Evaluation de complexités relatives, pas de

Communication en amont • charges
Implication de l'équipe • • Traduction en charge de travail à réaliser par
la suite en début de sprint

https://scrumpoker.online/ Avantages Inconvénients

https://www.pointingpoker.com/

Gestion de projet - Méthodes agiles 38

 Le TShirt Sizing
Variante simplifiée et plus « grossière » du Planning poker

• Evaluation de complexités relatives

• Choix d’un étalon de durée (ex : « M » = 2 semaines)
• Attributions de valeurs (non extrêmes) à l’étalon
• Évaluations « grossières » à affiner par la suite

Principe
XS S M L XL

• Evaluation de complexités relatives, pas de

Ludique (utilisation des tailles de t-shirts) •
charges
Communication en amont •
• Traduction en charge de travail à réaliser par
Implication de l'équipe •
la suite (souvent difficile)
• Ne remplace pas les autres méthodes
Avantages Inconvénients

Gestion de projet - Méthodes agiles 39

 Le TShirt Sizing
Variante simplifiée et plus « grossière » du Planning poker

XS S M L XL
•Très simple voire anodin •Simple et maîtrisé •Taille moyenne •Plus complexe et moins maîtrisé •Très complexe et potentiellement
•Ce n’est même pas la peine d’en •On a déjà fait ça souvent et on sait •La majorité des •Il va falloir y réfléchir avant de s’y très long
parler (ou presque) comment s’y prendre tâches/fonctionnalités devrait être attaquer •On n’a jamais fait… et on ne sait
M pas vraiment comment s’y attaquer
•Est-ce qu’on peut redécouper en
éléments plus petits et plus
facilement maîtrisables ?

Gestion de projet - Méthodes agiles 40

Le Stand-up meeting / Dayly standup / Dayly meeting / Dayly scrum

Qui ? Team members, Scrum Master, Product Owner

Quand ? Tous les jours, en début de journée

Combien de 15 mn maximum
temps ?

Quoi ? Tout le monde debout

Chaque team member expose en 1 mn : • Les éventuels freins pour lui ou pour l’équipe
Contraintes • Ce qu’il a fait la veille pour l’atteinte des objectifs du projet
• Ce qu’il va faire aujourd’hui pour l’atteinte de ces objectifs

Gestion de projet - Méthodes agiles 41

 Daily en vidéo
https://youtu.be/EpysjhYBEfg

Gestion de projet - Méthodes agiles 42

La Sprint review

Team members, Scrum Master, Product Owner

Qui ?
Eventuellement certains Stakeholders du projet

Quand ? Fin de sprint

Combien de 30 à 60 mn
temps ?

Présentation du produit du sprint (démo)

Le tout en 5 étapes
• Rappel des objectifs du sprint définis pendant le sprint planning
Quoi ? • Démonstration du produit (user stories terminées uniquement, et par ceux qui les ont réalisées)
• Bilan du sprint, intégrant les retours en temps réel du Product Owner (y compris modifications du product backlog)
• Calcul de la vélocité réelle (capacité de production de l’équipe)
• Mise à jour du planning de release et du burndown chart

Gestion de projet - Méthodes agiles 43

 La Sprint review
En détails

À la fin du sprint juste avant la

rétrospective

Adapter au fur et à mesure avec Revoir – Évaluer – Adapter

à partir du sprint écoulé
ce qui fonctionne l’équipe

Échanger
sur les
Présenter et Donner du Aborder les Ajuster le
solutions à
contrôler contexte sur éventuels Product
mettre en
l’incrément les résultats problèmes backlog, si
place pour
réalisé obtenus rencontrés nécessaire
les éviter à
l’avenir

Gestion de projet - Méthodes agiles 44

 La Sprint review
Conseils

Informelle… en Inclure les bonnes Noter toutes les Les feedbacks augmentent les
Préparer la réunion chances de succès
apparence ! personnes suggestions
• Lister les «Il s’agit d’une réunion • Celles qui • Noter tous les
fonctionnalités qui informelle, pas d’une s’intéressent au retours faits
vont être présentée réunion de mise en La Sprint review est conduite en
produit pendant la review
• Définir le scénario de état, et la présentation toute transparence
la démo de l’incrément vise à • Celles qui ont des • Ne pas prendre de
• Noter les éléments susciter des feedbacks avis tranchés et des décisions hâtives
nécessaires à la et à favoriser la suggestions qui • Echanger ensuite
collaboration.» aideront à faire
démonstration: avec l’équipe sur
Le Scrum guide avancer le produit
• emplacements des d’éventuels
fonctionnalités • Celles qui ne modification du
démos (URL…)
comprennent pas Product backlog
• identifiants et mots
le produit, pour le
de passe des cas de
tests pour accéder
challenge
•… • Celles qui vont
entendre parler du
produit sans
réellement travailler
dessus.

Gestion de projet - Méthodes agiles 45

 La Sprint review
Suggestion de présentation

Bienvenue (5 mn – PO) Introduction (5 mn – Présentation de chaque Échange sur chaque Conclusion (15 mn –
Scrum Master) fonctionnalité fonctionnalité présentée PO)

•Accueil des •Présentation de •5 mn par •10 mn par •Résumé des

participants l’agenda de la Sprint fonctionnalité fonctionnalité commentaires
•Rappelle des objectifs Review •Pitch par le dév •1 à 2 mn de réflexion pertinents recueillis
du sprint et de •Rappel de •Démo de la pour tout le monde •Partage de son avis
l’engagement pris l’importance fonctionnalité •Lancement des sur les retours
par l’équipe d’échanger, échanges par le PO •Explication de ses
•Partage des commenter et (choisir des choix
événements débattre participants au
pertinents qui ont eu hasard pour amorcer
lieu pendant le sprint si besoin)
•Focus sur le produit : •S’assurer qu’un
pas de décisions maximum de
managériales ou feedbacks est récolté
opérationnelles

Ce n’est qu’un exemple

Chaque projet/équipe/review est différent

Gestion de projet - Méthodes agiles 46

La Sprint retrospective

Qui ? Team members, Scrum Master, Product Owner

Quand ? Fin de sprint

Combien de 60 mn
temps ?

Bilan du sprint en mode « amélioration continue » :

Quoi ? • Ce qui a bien fonctionné et comment capitaliser dessus => communiquez vos best practices
• Ce qui n’a pas fonctionné et comment le corriger et s’améliorer => imaginez des solutions

Gestion de projet - Méthodes agiles 47

 La Sprint retrospective
En détails

À la fin du sprint juste après la

revue

Orientée process et non produit Améliorer le fonctionnement

de l’équipe et son quotidien
Sprint 5
Ce qui n’a
Sprint 4 C’est bien !!! Relations Efficacité des Problèmes pas
entre les processus ou intervenus fonctionné et
membres des outils dans le sprint ce qui a bien
Sprint 3 Pas mal !

Sprint 2 C’est mieux

fonctionné
Sprint 1 Mouais…

Gestion de projet - Méthodes agiles 48

 La Sprint retrospective
Conseils

Adapter la cérémonie aux besoins

de l’équipe

Organiser Communiquer Synthétiser Prioriser Proposer des solutions

• Ambiance : • Inciter les participants • Inciter l’équipe à • Prioriser les actions à

• Ouverture d’esprit à s’exprimer choisir les sujets à engager
• Collaboration • Ne pas laisser de non- traiter… surtout s’il y en • Forte valeur
dits ni de sous- a beaucoup ! • Rapide à mettre en
• Constructif
entendus œuvre
• Logistique :
• Nourriture & Comme pour une user
boissons story !
• De quoi écrire
• Post-it
•…

Gestion de projet - Méthodes agiles 49

 Sprint retrospective en vidéo
https://youtu.be/oJp8dQxMNeo

Gestion de projet - Méthodes agiles 50

 Synthèse
en vidéo
https://www.youtube.com/watch?v=3qMpB-UH9kA

Gestion de projet - Méthodes agiles 51

Gestion de projet - Méthodes agiles
04
Des outils et des techniques
Inventaire (très) partiel (encore !)

Gestion de projet - Méthodes agiles 53

Des outils et des techniques pour tous

Préparation, organisation, pilotage… quelques outils pour se simplifier la vie

Matrice de
QQOQCCP
compétences
Kanban
Mind Matrice
Préparation Organisation Pilotage
mapping d’Eisenhower
Burndown
chart
Matrice de
Kanban
compétences

Gestion de projet - Méthodes agiles 54

 QQOQCCP : les questions à se poser sans cesse
Analyse systématique d’un projet,
d’une problématique, d’une
situation
Quoi ? Description du projet De quoi s’agit-il ? Que produit-on ? ...

Qui ? Client, parties prenantes Qui est concerné ? Qui intervient ? ...
Pousse à envisager les différents
aspects et à identifier des pistes Où ? Localisation, contexte
Où le produit sera-t-il utilisé ? Dans quel environnement ? Dans quel
contexte ? ...
de solutions
Quand doit-on livrer ? Quels jalons ? Quelles contraintes temporelles
Quand ? Planification, contraintes temporelles
? ...

De quelle manière va-t-on procéder ? Quels outils seront mis en

Adaptation des questions au Comment ? Méthodes, outils, solutions
œuvre ? ...
contexte (projet à réaliser, incident
à corriger, situation à améliorer…) Combien ? Moyens et ressources Quel coût ? Quels moyens ? Quelles ressources ?

Pourquoi ? But et objectifs du projets Dans quel but ? Quelle finalité ? A quoi cela servira-t-il ?

Gestion de projet - Méthodes agiles 55

 Mind mapping
Collecte d’idées ludique
Représentation par nœuds, flexible, permettant
d’associer, capitaliser, enrichir, développer des idées ou Laissez vos idées
Ne recherchez s’exprimer
des concepts (mind map, topogramme, schéma pas la perfection

heuristique…) Chaque nœud

peut être une mind
Aller plus Personne Ne restez pas
map
loin n’est parfait
Sujet ou thème au centre bloqué sur une
seule page
Idées ou rubriques principales réparties
autour comme des branches Créer une
Idées « secondaires » représentées sous forme de « rameaux » mind map
Ne choisissez
Utilisation de libellés les plus courts possibles pas un camp
Partagez Utilisez des
Partagez vos couleurs Abordez les choses
mind map avec avec les 2 hémisphères
les autres de votre cerveau

Freeplane : www.freeplane.org Regroupez vos idées, vos

Freemind : freemind.sourceforge.net Vous y pensées avec des couleurs Créatif
gagnerez un Analytique
XMind : www.xmind.net autre regard
Lucidchart : www.lucidchart.com

Gestion de projet - Méthodes agiles 56

Matrice de compétences
Utile pour les recrutements, la constitution d’équipe…
Tableau synthétisant le niveau des compétences techniques et fonctionnelles des personnes
Facilite la constitution d’équipes projets (matching compétences nécessaires vs compétences disponibles)
Permet d’identifier les manques

Compétences Gandalf Frodo Galadriel Arwen Aragorn Éowyn

Equitation 4 2 3 3 4 4
Magie (feu) 4 0 0 0 0 0
Magie (Eau) 0 0 4 0 0 0
Escrime 3 1 2 3 4 4

Niveaux : 0 = pas de compétences | 1 = connaissances théoriques (scolaires) | 2 = première expérience | 3 = bonne expérience | 4 = expert

Gestion de projet - Méthodes agiles 57

Matrice d’Eisenhower – aide à la priorisation

Aide visuelle à la priorisation de

tâches, projets…
Urgent Pas urgent
Faire le tri entre l’urgence et
DO DECIDE l’importance des items
Important

Faire immédiatement Planifier… et tenir les

délais
Arbitrer entre faire soi-même et
déléguer

DELEGAT DELETE
Pas important

E
Eliminer (si ce n’est ni
important ni urgent,
Déléguer, planifier… pourquoi y perdre de
et suivre ! temps ?)

Gestion de projet - Méthodes agiles 58

 Kanban (signe en japonais)

Outil de management visuel des

tâches d’une équipe
(représentation visuelle du
Product backlog et du Sprint
backlog)

Tableau des tâches : ce qu’il y’a à A faire En cours Fait

faire, qui le fait, où ça en est

Principe très adaptable en

fonction du contexte, des besoins

Utilisable « en physique » (tableau

Tableau Kanban « de base »
& post-it) aussi bien qu’en digital

Gestion de projet - Méthodes agiles 59

Kanban – exemples
Candidats A voir Tests techniques Acceptés
En Vus En Faits Oui Non
cours cours

Sous-projets A faire Analyse Réalisation Validation Validés

Lot 1
Lot 2

Gestion de projet - Méthodes agiles 60