Techniques de
Gestion de Projets
TGPR
Benoît PENELLE bepenelle@epfc.eu
1
Séquencement du cours
6 séances de 4h :
1. Introduction + Git
2. Révisions UML + Processus Unifié 3. Méthodes traditionnelles <> agiles 4. Projet : itération 1
5. Projet : itération 2
6. Projet : défenses orales + bilan de projet individuel
Semaine 7/11 : Première session Semaine 14/11 : Correction
Semaine 21/11 : Seconde session
Projet
• par groupe de ~ 8
• participation active indispensable et évaluée :
• présence au cours
• implication active dans le projet
• répartition équitable du travail
• participation active à la défense orale
• bilan individuel du projet
• évalué :
• sur le résultat produit
• sur le processus de projet
Évaluation
• Projet :
• évaluation collective
• évaluation individuelle
• Examen :
• partie théorique à livre fermé
• partie pratique (basée sur le projet)
Bibliographie
• Gestion de projet
• Effective Project Management, Traditional, Agile, Extreme, Robert K.
Wysocki, 5th edition, 2009, Wiley.
• Gestion de projet, Vers les méthode agile, Véronique Messager-Rota, 2008, Eyrolles.
• Techniques de planification de projets, Gilles Vallet, 2ème édition, 1996, Dunod.
• SCRUM: Le guide pratique de la méthode agile la plus populaire, Claude Aubry, 2de édition, 2011, Dunod.
• UML
• Modélisation objet avec UML, Pierre-Alain Müller, Nathalie Gaertner, 2003, Eyrolles.
• The Unified Modeling Language Reference, James Rumbaugh, Ivar Jacobson, Grady Booch, 2004, Addison-Wesley.
• UML 2 par la pratique, Etudes de cas et exercices corrigés, Pascal Roques, 6ème édition, 2008, Eyrolles.
Plan du cours
1. Introduction 2. Git
3. Révisions UML + PlantUML 4. Processus Unifié + Balsamiq
5. Méthodes traditionnelles <> agiles + Trello
Complexité intrinsèque
1. Les différentes parties
prenantes d’un projet n’ont pas la même vision du
projet
Complexité intrinsèque
Les différentes parties
prenantes d’un projet n’ont pas
la même vision du projet
Complexité intrinsèque
2. Les différentes parties
prenantes d’un projet ne parlent pas le même
langage
https://youtu.be/BKorP55Aqvg
L’Expert
Qu’est-ce qu’un projet ?
Définition
• une séquence d’activités uniques, complexes, connectées entre elles,
• ayant un objectif unique,
• et qui doit être :
• réalisé dans une période de temps donnée,
• compatible avec un budget donné,
• conforme à une spécification donnée.
Séquence d’activités
• Une activité est un bloc de travail.
• Le projet est composé d’activités qui doivent être réalisées dans un ordre précis.
• Le séquencement des activités est guidé par leurs inputs et leurs outputs respectifs :
• Quels inputs sont nécessaires pour une activité ?
• Quelles autres activités produisent ces livrables ?
• Les outputs d’une ou de plusieurs activités deviennent les inputs d’une ou de plusieurs autres activités.
Activités uniques
• Les activités d’un projet sont uniques.
• Un projet ne se répète jamais.
• S’il doit se répéter (par exemple suite à un échec ou d’une transposition d’un projet réussi dans un autre lieu, contexte, etc), ce ne sera jamais dans les mêmes conditions :
• Délais
• Budget
• Personnes
• Conditions externes
• …
• Ne pas confondre avec des activités récurrentes de type
« opération » où le même processus est répété à l’identique.
Activités complexes
• Les activités d’un projet ne sont pas des tâches simples ou répétitives comme tondre la pelouse, laver la voiture ou charger une camionnette de livraison.
• Ce sont des tâches complexes comme concevoir une interface utilisateur ergonomique et intuitive pour une application.
Activités connectées
• Les activités sont connectées entre elles sur base de considérations logiques et/ou techniques.
• Elles sont connectées car l’output de l’une devient l’input d’une autre.
• Exemple : il faut développer un programme avant de pouvoir le tester.
Objectif unique
• Un projet doit avoir un seul objectif.
• Si cet objectif est trop large, on découpe le projet en sous-projets :
• Chaque sous-projet a son objectif propre
• Simplifie et rationnalise la gestion de chaque sous- projets
• Mais introduit la nécessité de coordonner les sous- projets
Période de temps imposée
• Le projet a une date de début et une date de fin imposées par :
• le management,
• le client,
• l’entrée en vigueur d’une réglementation,
• …
• Généralement ce dates sont inamovibles et hors de contrôle de l’équipe de projet.
• Elles doivent être respectées pour que le projet soit considéré comme un succès.
• Dans certains cas, leur non respect peut avoir des conséquences financières lourdes.
Budget imposé
• Le projet dispose de ressources limitées : humaines, matérielles, financières, …
• Une fois attribuées au projet, ces ressources sont considérées comme fixes par le chef de projet.
• Cela signifie qu’il ne pourra (en général) pas
disposer de ressources supplémentaires, mais aussi qu’il doit veiller à les utiliser puisqu’elles lui sont
attribuées.
Conforme à la spécification
• Le « client » d’un projet attend :
• un certain nombre de livrables avec :
• un niveau de fonctionnalités
• un niveau de qualité
• Théoriquement les spécifications sont fixes pendant la durée du projet.
• En réalité, il y a souvent des facteurs extérieurs qui provoquent des changements de la spécification.
• Ces changements et leurs impacts sur le budget, le planning, les ressources, les livrables, … doivent
être gérés par le chef de projet.
Les 5 contraintes
• Les projets sont soumis à 5 contraintes :
• Scope
• Qualité
• Coût
• Temps
• Ressources
• Ces 5 paramètres sont interdépendants et doivent être en équilibre pour que le projet le soit aussi.
• Un changement dans l’une des contraintes peut nécessiter un changement dans une ou plusieurs autres pour rétablir l’équilibre du projet.
Scope
• Le scope définit les frontières du projet : il précise ce qui va être fait, mais aussi, dans la mesure du possible, ce qui ne sera pas fait.
• Il est défini dans la « spécification fonctionnelle » du projet.
• Tout changement de scope doit être détecté, analysé en terme d’impact et confirmé par une décision du management sur base de ces impacts.
Qualité
• La qualité se gère à deux niveaux : la qualité du produit et la qualité du processus.
• Qualité du produit :
• Qualité des livrables
• Outils de vérification : revue, tests, …
• Qualité du processus :
• Ici on s’intéresse au processus de gestion du projet lui- même. Comment fonctionne-t-il ? Peut-il être amélioré ?
• Outils de vérification : indicateurs de performance
Coût
• « nerf de la guerre »
• Difficile à estimer en début de projet, et de plus en plus précis au fur-et-à-mesure de l’avancement.
• Souvent le client dispose d’un budget pour financer le projet qu’il a imaginé, mais il n’est pas à même de
vérifier la compatibilité de ces deux éléments.
• Processus (itératif) en amont du projet :
• Le client définit globalement le scope
• Le fournisseur remet une estimation (une offre)
• Le client décide : go/no-go
• Une fois que le projet démarre, le budget est fixe.
Ressources
• Les ressources :
• sont des assets tels que personnes, équipements, locaux, …
• sont disponibles en quantité limitées
• ont un coût associé
• peuvent être planifiées
• Affectées au projet :
• de manière fixe
• ou variable
• Elles sont primordiales pour la planification du projet
• Pour le développement de SI, les principales ressources sont :
• Les personnes
• Les systèmes (serveurs, outils de développement, librairies, …)
Temps
• Le client impose une date de début et une date de fin pour le projet.
• Le temps est une ressource particulière pour le chef de projet : il ne peut pas être cumulé ou mis en réserve pour plus tard. Il s’écoule, qu’il soit mis à profit ou pas.
• En cours de projet, on fait la distinction entre :
• Le temps déjà consommé
• Le temps restant [à consommer]
• Le but du chef de projet est d’utiliser le temps restant de la manière la plus efficace et productive possible.
Le triangle du scope
Scope et qualité
Coût Temps
Ressources
