Les principales méthodes de gestion de projets

Les principales méthodes
de gestion de projet
appliquées au secteur informatique
Laurence Genty
Cercle Marketing Digital

Sommaire
Laurence Genty – Méthodes de Gestion de Projet 2
1. Vision globale et présentation de la méthode traditionnelle dit
Cascade
2. Présentation de la Méthode Agile
3. Exemples de Projet Agile
4. Présentation de la Méthode RAD
5. Présentation de la Méthode Cycle V
6. Présentation des Feature Teams
7. Conclusion
8. Références et Logiciels de gestion de projet

Vision Globale
& Présentation de la méthode Cascade
1

Le cycle de réalisation d’un projet
Laurence Genty – Méthodes de Gestion de Projet – Source : 4

Objectif du chef de projet
Laurence Genty – Méthodes de Gestion de Projet – Source : 5
Mener son projet à terme en respectant les délais et le budget alloué.
Pour atteindre cet objectif, il doit prendre en compte les 3C qui sont les
trois contraintes que constitue le projet.

Taux de réussite de projets
Laurence Genty – Méthodes de Gestion de Projet - Source : Standish Reports
6
Projets
annulés
28%
Projets
réussis
26%
Projets
ayant
échoués
46%
3 projets sur 4 = des échecs complets
ou partiels
▶ Les projets sont abandonnés en cours
de route ou aboutissent, mais au prix
de dépassements importants…
▶ ou offrent moins de fonctionnalités
que prévu

Cycle en cascade : approche prédictive
Laurence Genty – Méthodes de Gestion de Projet – Schéma : 7
• Prévoir des phases séquentielles : valider l’étape précédente pour passer à
la suivante.
• Le chef de projet doit alors s’engager sur un planning précis de réalisation
du projet en prévoyant des jalons de débuts et fins de phases ainsi que les
tâches à effectuer.

Résultats de l’approche « cascade »
• 80% des projets exécutés connaissent des retards, des dépassements
budgétaires, voire finissent en échec
• Le chef de projet doit anticiper les problèmes
• Les risques sont détectés tardivement : plus difficile et coûteux de revenir en
arrière
• Production des documents très détaillés en amont (Recueil des besoins, cahier
des charges, zoning, wireframe, etc.)
• Beaucoup de documentation au lieu de produire de la valeur
• Le client validera le contenu papier (conception, maquette, développement
fonctionnalités, etc.)
• Le client intervient au moment du lancement du projet, à quelques jalons
majeurs puis réception et recette
• Effet tunnel
• Standardisations des activités d’ingénierie : contrôle qualité sur base établie,
création de documentation mais pas de valeur
• Le passage en relai entre les phases successives n’encourage ni l’empathie ni
l’esprit d’équipe

Présentation Méthode Agile
Manifeste définissant quatre valeurs :
• Les individus et leurs interactions avant les processus et les
outils
• Des fonctionnalités opérationnelles avant la documentation
• Collaboration avec le client plutôt que contractualisation des
relations
• Acceptation du changement plutôt que conformité aux plans
Les méthodes agiles utilisent un principe de développement itératif qui
consiste à découper le projet en plusieurs étapes qu’on appelle
« itérations ».

La méthode Agile préconise
L’adoption d’un cycle
itératif et incrémental
 Adaptation
L’implication du client
 Client et utilisateur
donnent leurs
feedback
La définition d’objectif
à court terme
 Maintient une
pression constante (et
non juste à la livraison)
La collaboration
entre les personnes
et l’intégration
des équipes
La livraison d’un
produit opérationnel
1
2
3
45

Agile vs avant
Objectifs :
Mieux collaborer
Prendre du recul sur l’application
Donner plus de visibilité aux clients et utilisateurs
Éliminer l’effet tunnel
Priorité données aux personnes et
aux interactions, plutôt qu’au
processus et aux outils
Priorité donnée à la production
de fonctions, plutôt qu’à
la documentation
Priorité donnée à la collaboration
avec le client,
Plutôt qu’à la négociation
contractuelle
Priorité donnée à l’adaptabilité
et à l’accueil d’éventuels
changements,
Plutôt qu’au suivi d’un
plan original

Pratiques agiles principales
Product Owner : le client
Product Backlog : pour gérer dynamiquement les fonctions du produits à réaliser
Scrum Meeting : réunion quotidienne (15’) avec toute l’équipe
Restrospective Meeting : réunion de fin d’itération focalisée sur événement et analyse
des dysfonctionnements
Iteration planning : permet de découvrir le projet et les fonctions à implémenter,
identifier et estimer les tâches de réalisation
Vélocité : indicateur qui mesure le volume de logiciel produit
Burndown Chart : présentation graphique de l’avancement des travaux
Intégration continue : compiler, assembler, vérifier et tester l’ensemble du code source
dès qu’un nouvel élément est à disposition
Test Driven Development : spécifier le logiciel (TDR)
Pair Programming : programmation en binôme

« War room »
• La première chose à faire est de réunir les gens dans un même lieu,
dédié au projet
• Pour suivre le projet, on utilise les post-it sur les murs
• Un ensemble d’ordinateurs non affectés individuellement
Facilite le travail en binôme et la propriété collective du code
• Chaque ordinateur est dédié à un type de tâche : développement, bureautique, etc.
• Des postes de développement homogènes

« War room »
Laurence Genty – Méthodes de Gestion de Projet
Crédit photo : http://www.fastcodesign.com/3028471/google-ventures-your-design-team-needs-a-war-room-heres-how-to-set-one-up 15

Serveur d’intégration continue
Votre « war room » peut contenir une machine dédiée à l’intégration continue
Il est assez facile de libérer une machine pour la dédier à cette activité étant
donné que les développeurs travaillent chaque fois que nécessaire en binôme.
Les logiciels comme Hudson ou CruiseControl sont capable d’aller eux-
mêmes chercher le code source dans le dépôt de votre système de gestion de
version (par exemple Subversion ou ClearCase), de le compiler et d’exécuter
une série de tests et de mesures de qualité avec des outils tels que CheckStyle
ou Cobertura.
Il reste ensuite à astreindre plusieurs fois par jours les
développeurs à poster leur travail sur le dépôt central
(commit du code dans l’outil de gestion des sources).

Release Planning
Meeting
Sprint Planning
Meeting
Daily Status Meeting
(Daily Scrum)
Sprint Demo and
Review Meeting
Product
Backlog
Sprint
Backlog
Scrum Master
Scrum Team
Customer
Product Owner
Working Software
Other Deliverables
Sprint
14-30 days
Source : Livre blanc méthodes agile – Valtech
Présentation schématique de processus
de développement Agile
Workday
One day

L’essentiel à retenir
• Les méthodes Agiles préconisent l’adoption d’un cycle itératif et
incrémental
• L’Agilité prône la collaboration entre les personnes et l’intégration des
équipes
• Les méthodes Agiles mettent l’accent sur l’importance de développer le
bon produit
• L’agile et les méthodes itératives sont orientées « design to cost » : le
budget limite les fonctionnalités
4 principes fondamentaux :
Priorité aux personnes et aux interactions
Priorité au développement des fonctions
Priorité à la collaboration avec le client
Accueil et adaptation au changement

Exemples d’organisation
d’un projet «agile»
3

Organisation du projet
État des lieux des pratiques en cours
• Recueil du besoin
• Gestion de projet
• Transfert de connaissances
• Spécifications logicielles (dossier d’analyse)
• Conception et l’implémentation
• Test logiciel
• Qualité logicielle
• Déploiement et la mise en production
Entretiens et séances de travail pour établir la
cartographie des pratiques en cours (MOE, MOA,
Cellule qualité, formateurs…)

• Description des périmètres technique, fonctionnel et organisationnel du
projet ou du service, candidat à l’Agilité
• Description des rôles et responsabilités de chaque personne interviewée
au sein de l’organisation projet ou service
• Description de l’état des lieux de chacune des activités précédemment
citées
• Liste des accélérateurs éventuels à l’adoption de l’Agilité
• Identification des freins éventuels
• Incontournables manquants (pratiques indispensables et pourtant absentes)
Ce document sert de base à une nouvelle séance
de travail
Rédaction d’un document de synthèse sur l’existant

• Rappel des risques et incontournables manquants avec les pratiques Agiles
associées
• Identification des conditions d’entrée pour la mise en place de toutes les
pratiques
• Description et le mode opératoire de chaque pratique détaillés
• Identification des éventuels Artefacts produits par chaque pratique
Description des conséquences et impacts sur l’organisation et les processus
actuels, attendus opérationnels de la pratique
Ce document sert de base à une nouvelle séance
de travail
Adoption de nouvelles pratiques

Exemple de Burndown Chart
REMAININGWORKINGHOUS
Source Wikipédia - Burndown Chart

Exemples
Laurence Genty – Méthodes de Gestion de Projet 24Source : Livre blanc méthodes agile – Valtech

Organisation d’un projet
Le Product Backlog contient la description des besoins et permet entre autres :
• Avoir une vision commune sur l’ensemble des fonctions ou cas d’utilisation
définissant le périmètre du logiciel à développer
• Comprendre l’intérêt et les enjeux des développements pour les
utilisateurs (appelés également acteurs)
• Estimer l’avancement du projet sur la base des fonctions ou cas
d’utilisation livrés au client
• Réaliser facilement des macro-estimations en utilisant, par exemple, la
méthode des « Use Case points »
• Préparer l’identification des tâches du projet en les organisant autour des
fonctions ou des cas d’utilisation
Recueil des besoins dans le Product Backlog

Exemples
Laurence Genty – Méthodes de Gestion de Projet 26Source : Livre blanc méthodes agile – Valtech

Avantages du développement itératif
• Meilleure qualité de la communication : l’utilisateur à la possibilité de
clarifier ses exigences au fur et à mesure
• Meilleure visibilité : le client a eu meilleure visibilité sur l’avancement des
travaux, il valide au fil de l’eau
• Meilleur contrôle de la qualité : les tests sont effectués en continu
• Meilleure détection des risques : les risques sont détectés plus tôt
• Motivation et confiance de l’équipe : satisfaction d’atteindre un objectif
fixé
• Contrôle des coûts : le projet peut être arrêté s’il n’y a plus de budget
Agile

Il existe plusieurs méthodes agiles
Je vous propose ci-après de découvrir les principes
fondamentaux de :
• ASD : Adaptative Software Development
• Crystal
• Scrum
• RAD
Et encore d’autres méthodes :
• DSDM (Dynamic Software Development Method)
Créée en Grande-Bretagne en 1995
• XP (eXtreme Programming)
Créée en 1999

Principale méthode agile
• Focaliser sur l’objectif (mission focused)
• Se baser sur des composants (component-based)
• Itérer
• Découper le temps et fixer des deadlines (timeboxing)
• Piloter le projet par les risques* (risk-driven development)
• Accepter le changement
*Product owner absent, des erreurs dans les flux codées, etc.
Fonctionner en mode beta en
permanence
ASD (Adaptive Software Development)

Principale méthode Agile
• Des livraisons fréquentes
• Des aménagements permanents
• Une bonne communication interpersonnelle
• Confiance, liberté d’expression et sécurité personnelle
• Focus sur l’objectif et disponibilité
• Un contact permanent avec les utilisateurs
• Un environnement de travail approprié pour l’automatisation des tests, la
gestion de configuration et les intégrations fréquentes
• Une collaboration étroite entre toutes les parties prenantes, y compris en
dehors de l’équipe
• Une réflexion constante sur ces propriétés
*Jean-Pierre Vickoff
Crystal*

Principale méthode Agile
• Itérations de quatre semaines qu’on appelle sprints
• Avant chaque sprint, on effectue une réunion de planification appelée le
sprint planning meeting : sélectionner les exigences prioritaires pour le
client dans le produit backlog qui seront développées, testées et livrées au
client : le backlog sprint (sous-ensemble du produit backlog)
Valeurs mises en avant par cette méthode :
• Visibilité : avoir une vision réelle sur le résultat
• Inspection : vérifier l’écart par rapport à l’objectif initial
• Adaptation : s’adapter en fonction des écarts constatés afin de les ajuster.
Scrum est favorable à des petits ajustements fréquents
Scrum

LaurenceGenty–MéthodesdeGestiondeProjet–Source:
32
Classique versus agile

Méthode RAD
Précurseur des méthodes Agile
4

RAD (Rapid Application Development)
• La méthode sera formalisée par James Martin en 1991, puis repris par
Jean-Pierre Vickof en 1994. Le Gartner Group publiera par la suite le
processus RAD2
• Cette méthode formalise techniquement le premier postulat « agile » :
pour qu’une planification de projet soit prédictive certains aspects du
pilotage doivent être fixes
• RAD intègre aussi les techniques JRP (Joint Requirements Planning)
et JAD (Joint Application Design / Development / Delivery)
Durée
CoûtPérimètre
Projet

Postulats de bases
• Certains aspects du pilotage sont fixes et d’autres variables
• Techniques de priorisation pour gérer les deux principales variantes possibles
de ces situations (délais fixe ou budget fixe)
Compléments introduit par la suite :
• Spécialisation des rôles
• Instrumentation des communications
• Organisation des divers types de réunions
• Groupe de facilitation et de rapport
• « Raccourcis méthodologiques » de modélisation
• Architecture de réalisation (imbrication des itérations)
• Formalisation de processus légers de mise en œuvre
Méthode RAD

Structure de la méthode
• Constitution d’une équipe : la SWAT
• SWAT : Special Weapons and Tactics, la célèbre force d’intervention américaine.
• Dans l'engagement d'un projet de développement, on retiendra plutôt l’acronyme de Skill
With Advanced Tools.
• SWAT : Idéalement de 4 à 6 personnes
• Afin de permettre à ses membres de nouer des relations fortes
• Equipe autonome, spécialement formée, : un profil unique de concepteurs-
développeurs
• Organisation pratique : l’équipe travaille avec les utilisateurs, un animateur,
dans une salle dédiée, isolée, spécialement équipée de style war room

Équipe et Leader
• Bien qu’il n’y ait pas officiellement de " chef " dans un SWAT*, lorsqu’un
leader non hiérarchique émerge par sa personnalité ou ses connaissances,
son charisme joue alors un rôle prépondérant dans la cohésion du groupe
face aux interventions externes.
• Initialement, dans les projets de développement, la qualification de SWAT se
limitait à l’équipe informatique.
La complexité des projets actuels impose une participation accrue et parfois permanente
d’utilisateurs ou de membres de la maîtrise d’ouvrage.
La notion de SWAT s’étend alors à toutes les personnes engagées en " mode projet ".
Réponses à appel d’offres dans les grandes organisations
Méthode RAD
Skill With Advanced Tools.

Méthode RAD :
Phases de formalisation
• L'expression des besoins (CADRAGE)
• La Définition globale de l'architecture technique (DESIGN), inclut dans sa
phase principale (CONSTRUCTION) la réalisation
• La validation immédiate et les tests d'une application en mode itératif-
incrémental-adaptatif
L'objectif de la méthode, qui implique activement
l'utilisateur final dans un principe de « validation
permanente », est d'obtenir un applicatif en adéquation
avec les réels besoins
Méthode RAD

Besoins d’un projet simple
Un niveau supérieur de planification stratégique sera ajouté plus tard par
Jean-Pierre Vickoff : processus RAD2
Source : Wikipedia – Méthode RAD
Méthode RAD
Le FOCUS est une présentation de l’itération de la livraison venant de
s’achever

EN BREF: un cycle adopté par l’ensemble des
méthodes agiles actuelles
• Le RAD préconise la formation d'une équipe de développement particulière :
le SWAT
• Les décisions concernant l'organisation du projet sont consensuelles
• L'équipe travaille avec les utilisateurs et, généralement avec un animateur,
dans une salle dédiée, isolée, spécialement équipée dans le style war
room, où les murs sont utilisés pour afficher un « radiateur d'information »
(une forme de cockpit de gestion de projet).
Méthode RAD
Construction et Validation

Évolution d’un projet avec
la méthode RAD
Laurence Genty – Méthodes de Gestion de Projet 41Source : Wikipedia – Méthode RAD
Méthode RAD

Description globale des phases
Parallélisation et sérialisation des phases de projet
Laurence Genty – Méthodes de Gestion de Projet
L’initialisation prépare l’organisation, puis détermine le périmètre et le plan de communication ;
• Le CADRAGE définit un espace d’objectifs, de solutions et de moyens
• Le DESIGN modélise la solution et valide sa cohérence systémique
• La CONSTRUCTION réalise en prototypage actif (validation permanente)
• La finalisation est réduite à un contrôle final de qualité en site pilote
Méthode RAD

Exemple d’un projet sur 120 jours
Initialisation du projet et
immersion animateurs
& coordinateurs dans le
domaine fonctionnel
Réunion de lancement et
d’individualisation
Entretien
propriétaire
Généralisation
Méthode RAD

Le Jalon ZD (Zero Defaut) est une intégration de l’itération journalière validée techniquement et fonctionnellement
Le FOCUS est une présentation de l’itération de la livraison venant de s’achever
Cette démonstration est effectué par le ou les utilisateurs impliqués dans le prototypage à destination de l’ensemble
des autres intervenants du projets. Pour pousser à l’extrême la qualité du code, ces étapes peuvent être remplacées
par les pratiques XP d'ingénierie du logiciel
Construction :
Le principe itératif, incrémental et adaptatif
Méthode RAD

Gestions de Projets
Méthode en cycle V
5

Méthode en cycle V
Modèle conceptuel de gestion de projet
imaginé suite au problème de réactivité
du modèle en cascade
Cycle V
Théorie
Pratique

Les étapes
• Analyse des besoins et faisabilité
• Spécifications fonctionnelles
• Conception architecturale
• Conception détaillée
• Codage
• Tests unitaires
• Tests d’intégration
• Tests de validation : recette usine, validation usine, VAU
• Tests d’acceptation : vérification d'aptitude au bon fonctionnement, VABF
Cycle V

Les rôles
Maîtrise d’ouvrage (MOA) qui regroupe les fonctions suivantes :
• le maître d’ouvrage stratégique (MOAS)
• Le maître d’ouvrage délégué (MOAD)
• Le maître d’ouvrage opérationnel (MOAO)
• L’assistant à maîtrise d’ouvrage (AMOA ou AMO)
• L’expert métier
• L’utilisateur, au service duquel se trouvent toutes les autres fonctions
• Une méthode respectant les impératifs de qualité, coût et délai : découpage du
projet en phases.
• Chaque phase est accompagnée d’une fin d’étape destinée à formaliser la
validation de la phase écoulée avant de passer à la phase suivante.
• Les phases de la partie montante doivent renvoyer de l'information sur les phases
en vis-à-vis lorsque des défauts sont détectés.
Cycle V

Les Rôles - suite
Maîtrise d’œuvre (MOE) Maîtrise d’œuvre déléguée (MOED)
• L’équipe architecturale
• L’équipe de développement
• Titulaire de marché
Répartition des rôles en fonction des étapes
Rôles
Besoins
et Faisabilité
Spécification
Conception
Architecturale
Conception
Détaillée
Codage
Test
unitaire
Test
d'intégration
Test
de Validation
Recette
FONCTIONNEL
MOA + AMOA X X
SYSTÈME
MOE + MOED X X
TECHNIQUE
ET MÉTIER
Équipe
Architecturale
X X
COMPOSANT
Équipe
de
Développement
X X X
Cycle V

Documents par phase
Besoins
et Faisabilité
Spécification
Conception
Architecturale
Conception
Détaillée
Codage
Test
unitaire
Test
d'intégration
Test
de Validation
Recette
Spécification des
Besoins Utilisateur
Cahier des
charges
Rapport de
Recette
Spécifications
Générales
Spécification
Technique des
Besoins
Procès Verbal de
Validation
Dossier de
Définition du
Logiciel Dossier
d'Architecture
Technique Plan de
Tests
Rapport de Tests
d'Intégration
Rapport de
Conception
Détaillée
Rapport de
Tests
Unitaires
Code source
Cycle V

Le cycle en V : en image
• Une méthode respectant les impératifs de qualité, coût et délai est le découpage du projet
en phases.
• Chaque phase est accompagnée d’une fin d’étape destinée à formaliser la validation de la
phase écoulée avant de passer à la phase suivante.
• Les phases de la partie montante doivent renvoyer de l'information sur les phases en vis-à-
vis lorsque des défauts sont détectés.
Source : Wikipedia – Cycle en V
Analyse des besoins
et faisabilité Recette
Tests de
validation
Spécifications
Conception
architecturale
Tests
d’intégration
Conception
détaillée
Tests unitaires
Codage
TempsDélais
Cycle V

Détails sur les étapes
• Expression de besoin : le client exprime son besoin, en décrivant les usages correspondant au produit fini tel qu’il
peut l’imaginer. Cela doit répondre aux questions « Que veut-on ? » et « À quel coût ? ».
• Spécifications fonctionnelles : cahier des charges exact du produit final, tel que le désire le client. Il doit couvrir
l’intégralité des cas d’utilisation du produit, en expliquant ce qu’il doit faire et non pas comment il va le faire.
• Spécifications techniques : traduction des spécifications fonctionnelles en termes techniques. C’est durant
l’élaboration des spécifications techniques que sont choisies les technologies à mettre en œuvre pour développer le
produit, et qu’est conçue l’architecture logicielle du produit.
• Codage : phase de réalisation à proprement parler, pendant laquelle sont développées des briques qui sont ensuite
assemblées pour créer le produit fini.
• Tests unitaires : interviennent à un niveau « atomique ». Chaque brique logicielle a été modélisée puis codée durant
les étapes précédentes. Les tests unitaires assurent que ces briques respectent de manière individuelle leur cahier
des charges.
• Tests d’intégration : premiers tests grandeur nature du produit fini. On s’assure qu’il suit les indications des
spécifications techniques.
• Validation : le produit est à ce moment testé en regard de la spécification fonctionnelle. Toutes les utilisations qui y
ont été définies doivent pouvoir se vérifier dans les faits.
• Mise en production et recette : le produit est vérifié une dernière fois en pré-production, avant d’être mis en
production. Le client procède à la recette, pour vérifier que son expression de besoin est respectée.
Cycle V

Découpage par couches
Le découpage par couche « technologique »
• Dédier chaque équipe sur un type de technologie : typiquement, la couche
présentation, la couche métier, les socles transverses, la base de données…
• Le découpage traditionnel dans les DSI : regroupement par spécialités
Montre des limites au moment de la mise sur le marché (Time to Market) :
de la spécification, du développement, de la mise en production le plus
possible selon des cycles courts, voire au fil de l’eau
Le découpage par « pan fonctionnel »
• Livrer de bout en bout des fonctionnalités autonomes, qui rendent un service
à l’utilisateur final
Cycle V

Exemple organisation d’un projet
• Flèche rouge : sur sollicitation
• Autres équipes : production de choses marginales pour ces fonctionnalités
• On ne peut rien livrer tant que l’équipe 1 n’a pas fini
• La fonctionnalité 4 nécessite de faire collaborer les 4 équipes
• Il faut faire l’analyse détaillée des
impacts sur les 4 équipes :
analyse, synchronisation du travail
pour pouvoir tester, attendre l’équipe
la plus lente…
On se retrouve à faire de la cascade en amont à la fois pour l’analyse et la
planification et de la cascade en aval pour du test et de la mise en
production
Cycle V
Fonctionnalité 1
Fonctionnalité 2
Fonctionnalité 3
Equipe 1
- Front
Equipe 1
- Back
Equipe 1
- Echanges
Equipe 1
- Socle
Fonctionnalité 4

Les patterns
des grands du web
Feature Teams
6

Les Feature Teams
Si le succès advient, arrive un moment où la dizaine de personnes ne
suffit plus et où il faut pouvoir monter en charge
Augmenter les équipes
• Chaque équipe travaille sur un sous-ensemble fonctionnel cohérent, est
capable à tout moment de livrer de la valeur au client final en dépendant
faiblement des autres équipes
• Cela implique que dans une même équipe se retrouvent toutes les
compétences nécessaires à la production de fonctionnalités :
un architecte, un ergonome, un développeur Web, un développeur
Java, un expert base de données, et, oui, même
un exploitant : « you build it, you run it »
<
f

Les Feature Teams
• Les pairs de chaque type d’expertise se réunissent à intervalles
réguliers pour échanger sur leurs pratiques et s’accorder sur des
stratégies technologiques par rapport à la fabrication du produit en
cours.
• Les équipes progressent très vite sur le métier et cela favorise
l’implication des développeurs dans la vision produit et dans la
qualité du résultat final.
• Il existe d’autres axes possibles, notamment par release, par zone
géographique, par segment d’utilisateurs ou par famille de produits.

Les Feature Teams
Configuration idéale de l’équipe
• L’équipe est une entité à part entière (vs individu), inclus toutes les
compétences requises pour l’implémentation complète d’une caractéristique
orientée utilisateur : test, interaction, programmation
• Unie sur une longue période (meilleure performance), et l’équipe prend en
charge les nouvelles caractéristiques au fil de l’eau
Au sein de l’équipe :
• Compétences cross-fonctionnelles et cross-composants
• Idéalement, colocalisées afin de favoriser une communication optimale
• Travaillent sur une caractéristique orientée utilisateur, à travers les
composants et disciplines (analyse, programmation, tests, .)
• En général composée de spécialistes
• En Scrum, typiquement 5 à 9 personnes

Composition d’une Feature Team
Feature Team :
-Stable
-Fonctionnel
-Trans composant
PO
Caractéristique
orientée
utilisateur
Produit
potentiellement
livrable pour
implémentation
L’équipe a nécessairement les compétences pour générer et livrer une
caractéristique complète orientée utilisateur. Si ce n’est pas le cas, elle
va devoir acquérir les connaissances demandées.
Product
Backlog

Facteurs clés de succès du chef de projet
• Identifier dès le démarrage les bons acteurs
• Aller au contact des utilisateurs pour mieux les comprendre
• Associer ses collaborateurs pour analyser les causes des problèmes
• Déléguer une partie de ses travaux
• Partager avec d’autres chefs de projet
• Dialoguer, avec objectivité et intégrité
• Pratique le management par écoute et rencontrer, en communiquant de
façon informelle avec ses collaborateurs
• Accepter l’incertitude, s’adapter, anticiper

Synthèse
Cascade RAD Cycle en V Agile Feature Team
Exemple de
projet
Projets BTP, Logiciels
etc.
Projets Logiciels Intégration d'un logiciel
modulaire de type
ERP
Iso 9001
Application Mobile Spotify, telecom
systems (Ericsson),
compiler development
(Microsoft)
Différence
Fondamentale
Effet Tunnel
Cost to Design
Délais et/ou Budget
Fixe
Pas d'effet tunnel
Découpage par phase
Cost to Design
Réactivité, Design to
Cost : le budget limite
les fonctionnalités
 Projet au forfait
impossible
Réactivité
Centré sur le client
final
Cycle de vie Effet Tunnel -
Retroaction difficile
120 jours
maximum, 90 jours
optimum
Effet Tunnel -
Rétroaction difficile
Itératif, incrémental Itératif, incrémental
Planification Prédictive : plan plus
ou moins détaillés au
début du projet
Par phase - Semi
itératif
Prédictive : plan plus
ou moins détaillé au
début du projet
Adaptative, ajustements
au fil de l'eau
Adaptative,
ajustements au fil de
l'eau
Documentation En quantité
importante
Entre Cascade et
Agile
En quantité importante Réduite au strict
nécessaire
Réduite au strict
nécessaire
Equipe Avec ressources
spécialisées et dirigée
un chef de projet
Spécialisation de
rôles
4 à 6 personnes, un
animateur
Avec ressources
spécialisées et dirigée
un chef de projet
Equipe responsabilisée,
soutenue par le chef de
projet (=Product
Owner)
Equipe
pluridisciplinaire
considérée comme
une entité – 5 à 9 pers

Synthèse - Suite
Cascade RAD Cycle en V Agile Feature Team
Qualité Contrôle à la fin du
cycle
Contrôles réguliers :
spécification >
Validation >
Réalisation
Contrôle par phases Contrôle précoce et
permanent, le client
(PO) visualise les
résultats
Les développeurs
sont impliqués dans la
vision produit et dans
la qualité du résultat
final
Changement Résistance voire
opposition, processus
lourds de gestion
Semi itératif donc
ouvert au
changement
Utilisateur finale en
validation permanente
Orienté expérience
utilisateur (UX), Fluide
Accueil favorable,
intégré au processus
Suivi avancement Mesure de conformité
/ plans initiaux
En fonction des
livrables
Mesure par rapport au
CADRAGE =
expression des
besoins
Au fur et à mesure Un seul indicateur: le
nombre de
fonctionnalités
implémentées et ce
qu'il reste à faire
Gestion des risques Processus distinct Au fur et à mesure
par la SWAT
Intégrée au processus
global,
responsabilisation de
chacun
Au fur et à mesure Intégrée au processus
global,
responsabilisation de
chacun
Mesure Respect des
engagements
Publication régulière Satisfaction client par
livraison de valeur
A chaque version
Un logiciel
opérationnel est la
principale mesure
d’avancement
Satisfaction client par
livraison de valeur

Pour aller plus loin
Il existe d’autres méthodes de gestion de projet :
Par exemple DevOps : proche de la méthode Agile, DevOps se définit
comme un mouvement visant à aligner le système d'information sur les
besoins de l'entreprise, afin minimiser les délais de commercialisation, dès
la livraison par l'équipe de développement. Cela permet de livrer
rapidement le client, avec plus de flexibilité.

Les techniques de gestion de projet
Management de l’intégration du
projet
Management du contenu du projet Management des délais du projet
• Élaboration de la charte du projet
• Élaboration de l’énoncé préliminaire
du contenu du projet
• Élaboration du plan de management
du projet
• Direction et pilotage de l’exécution
du projet
• Surveillance et maitre du travail du
projet
• Maitrise intégrée des modification
• Clôture du projet
• Planification du contenu
• Définition du contenu
• Création de la structure de
découpage du projet
• Vérification du contenu
• Maitrise du contenu
• Identification des activités
• Séquencement des activités
• Estimation des ressources
nécessaires aux activités
• Estimation de la durée des activités
• Élaboration de l’échéancier
• Maitrise de l’échéancier
Délais

Les techniques de gestion de projet
Management des coûts du projet Management de la qualité du projet Management des ressources
humaines du projet
• Estimation des coûts
• Budgétisation
• Maîtrise des coûts
• Planification de la qualité
• Mise en œuvre de l’assurance
qualité
• Mise en œuvre du contrôle qualité
• Planification des ressources
humaines
• Formation de l’équipe de projet
• Développement de l’équipe de projet
• Diriger l’équipe de projet
Management des communications
du projet
Management des risques du projet Management des
approvisionnements du projet
• Planification des communications
• Diffusion de l’information
• Etablissement du rapport
d’avancement
• Management des parties prenantes
•Planification du management des
risques
•Identification des risques
•Analyse qualitative des risques
•Analyse quantitative des risques
•Planification des réponses aux
risques
•Surveillance et maitrise des risques
• Planification des approvisionnements
• Planification des contrats
• Sollicitation des offres ou des
propositions des fournisseurs
• Administration du contrat
• Clôture du contrat
Qualité
Coûts

Références et Logiciels de
gestion de projet
Logiciels de gestion de projets
8

Références
• Crédits photos couverture et chapitres : http://littlevisuals.co - http://www.lifeofpix.co
• Crédit photo : http://fromstoneagetoagile.com/wp-content/uploads/2013/08/kanban-in-hr.jpg
• Livre blanc méthodes agile – Valtech
• http://www.rad.fr/glossair.htm
• http://blog.octo.com/feature-team - Ludovic Cinquin
• Gestion de projet vers les méthodes agiles – Véronique Messager Rota
• Wikipédia – Méthode Agile
• Wikipédia – Cycle en V
• Wikipédia – Méthode RAD
• Principes fondamentaux de mise en œuvre de projets - Bibliothèque Digitale de Qualité des Programmes de CARE
(http://pdql.care.org ).
• https://www.open-dsi.fr/11-logiciels-de-gestion-de-projets-web-et-open-source/
• http://www.geek-directeur-technique.com/2009/02/04/le-cycle-en-v
• Méthode RAD – Éléments fondamentaux – Le Développement Rapide d’Applications © 2000, Jean-Pierre Vickoff,
RAD.fr
• http://blog.octo.com/feature-team-au-dela-du-buzzword/
• http://featureteams.org/

Principaux logiciels de gestion de projet
Il existe de nombreux logiciels adaptés au différents projets de l’entreprise 
Wikipédia
LISTE DES 4 PRINCIPAUX
Logiciels Niveau de difficulté Possibilités Adaptés à quels types de
projet?
Microsoft Project Logiciel courant – 1er logiciel
dans le monde la planification et
de pilotage de projet
Moteur de planification
puissant – modèles de projet
et tutorial
Adapté à tous types de projet
Gantt Project Open source Possibilités moindres mais
apprentissage plus simple
Parfait pour des petits projets
Primavera Enterprise
Project
Logiciels spécialisés – Peu
nécessité un niveau de
compétence élevé
Besoin de formation en
fonction des compétences
Gestion des organisations
fonctionnant en mode projet
Planisware Solutions logicielles d’entreprise
pour la gestion de portefeuille
projets et produits
Comment choisir votre logiciel de gestion de projets :
http://methodo-projet.fr/comment-choisir-un-logiciel-de-gestion-de-projet/

Mise en œuvre du logiciel
Une gestion de projet s’articule autour de la mise en relation de tout ou partie
des éléments suivants :
Des projets divisés en tâches
Des individus
Des dates
Des livrables
À ces données seront adjointes des fonctionnalités comme :
Établir des plannings et les dépendances entre tâches
Définir les “workflow” ou flux de travail entre les individus
Optimiser l’utilisation des ressources humaines ou matérielles allouées au
projet
Des alertes paramétrables pour signaler ou rappeler les tâches arrivées à
échéance
Des rapports pour avoir un suivi des projets en cours
Des passerelles vers des outils de gestion d’agenda; etc…

Merci
Laurence Genty
Account Manager - Projets
laurence.genty@gmail.com
9

Les principales méthodes de gestion de projets

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Les principales méthodes de gestion de projets

Similaire à Les principales méthodes de gestion de projets (20)

Les principales méthodes de gestion de projets