Les principales méthodes de gestion de projets

Les principales méthodes de gestion de projetappliquées au secteur informatique

Laurence GentyCercle 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 Reports6

Projets annulés

28%

Projets réussis

26%

Projets ayant

échoués46%

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

Méthode Agile

2

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 plansLes 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 collaborerPrendre du recul sur l’applicationDonner 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 ProjetCré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 CheckStyleou 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

Sprint14-30 days

Source : Livre blanc méthodes agile – Valtech

Présentation schématique de processus de développement Agile

WorkdayOne 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 interactionsPriorité au développement des fonctionsPriorité à la collaboration avec le clientAccueil et adaptation au changement

Exemples d’organisationd’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

Organisation du projet 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

Organisation du projet Adoption de nouvelles pratiques

Exemple de Burndown Chart


REM

AIN

ING

WO

RK

ING

HO

US

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

Lau

renc

e G

ent

y –

Mét

hod

es d

e G

estio

n d

e P

roje

t –S

our

ce :

32

Classique versus agile

Méthode RADPré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 SkillWith 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 warroom, 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 phasesParallé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 fonctionnellementLe FOCUS est une présentation de l’itération de la livraison venant de s’acheverCette 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 ProjetsMé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ôlesBesoins

et FaisabilitéSpécification

ConceptionArchitecturale

ConceptionDétaillée

CodageTest

unitaireTest

d'intégrationTest

de ValidationRecette

FONCTIONNELMOA + AMOA X X

SYSTÈMEMOE + MOED X X

TECHNIQUEET MÉTIER

ÉquipeArchitecturale

X X

COMPOSANTÉquipe

de Développement

X X X

Cycle V

Documents par phase


Besoinset Faisabilité

SpécificationConception

ArchitecturaleConception

DétailléeCodage

Testunitaire

Testd'intégration

Testde 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 deTests

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

éla

is

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 webFeature 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éristiqueorienté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

Conclusion

7

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 ERPIso 9001

Application Mobile Spotify, telecom systems (Ericsson), compiler development (Microsoft)

Différence Fondamentale

Effet TunnelCost to Design

Délais et/ou Budget FixePas d'effet tunnel

Découpage par phaseCost 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ôles4 à 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)

Equipepluridisciplinaire 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 dansla 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érienceutilisateur (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é.

Pour aller plus loinLes 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

Pour aller plus loin 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 projetLogiciels 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 projetet 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 – Peuné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 individusDes datesDes livrables

À ces données seront adjointes des fonctionnalités comme : Établir des plannings et les dépendances entre tâchesDé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 GentyAccount Manager - Projets

[email protected]

9

Business

Les principales méthodes de gestion de projets