conf. 304 - l'intégration des approches agiles et traditionnelles au bénéfice de tous les...
TRANSCRIPT
L'intégration des approches agiles et traditionnelles
au bénéfice de tous les types de projets
Conférencier : Claude Besner, Ph. D., MBA, B. Arch. , PMP
Symposium PMI-Montréal
2012
Ma carte de visite
• Claude Besner, Ph. D., PMP professeur‐chercheur titulaire au département de management et de technologie de l’École des sciences de la gestion (ESG) de l’UQAM.
• Responsable de l’axe de recherche « processus et nouveaux outils » au sein de la Chaire de gestion de projet de l’ESG‐UQAM. Ex‐directeur des programmes de 2e cycle en gestion de projet à l’UQAM.
2
Plan de la présentation
1. Mon parti pris et mes A priori2. Des résultats de recherche qui illustrent les
limites du paradigme actuel3. Un modèle intégrateur: incertitude; cycle de
vie du projet; groupe de processus; etc.4. Une métaphore: Agile comme un Gagaku5. Une période de questions
Mon parti pris et mes A priori
1. Les meilleures pratiques ne sont pas universelles, elles dépendent du contexte.
2. J’adore les méthodes agiles (système de pratiques mis au point pour les projets de développement de logiciel).
3. Les bonnes idées et meilleures pratiques agiles méritent d’être adaptées à d’autres contextes.
Cadre de la recherche
• Questionnaire Web• Support département du PMI
Types de projet• TI et télécommunication 54%• Services d’affaires et financier 18%• Ingénierie et construction 17%• Développement logiciel 11%
Contexte de projet• Buget (médian) 1 M$• Durée (médiane) 9 mois• Projet externe 58%• Projet international 41%• Projet privé 76%• Projet innovant 54%• Mature (CMMI 3, 4 et 5) 53%
2500 répondants; majorité PMP
Expérience moyenne 16 ans
Deux questions pour chaque pratique
1‐ “What is the extent of actual use”
“Not use” = 1“Very extensive use” = 5
2‐ “In your opinion, more extensive or better use of this tool or technique would improve project performance.”
“No improvement” = 1“Very extensive improvement” = 5
Liste des boîtes à outils ordonnées selon leur niveau d’utilisation et de potentiel
La boîte à outil de la gestion du risque
Le niveau d’utilisation et de potentielde la gestion de risque
Le niveau d’utilisation et de potentiel de la gestion de risque
Un test
Discussion• Plus le projet et ses objectifs sont bien définis,
plus on utilise les pratiques de gestion des risques, plus on a du succès.
• Les pratiques du modèle traditionnel de gestionde projet semblent mal adaptées aux contextesoù règne une grande incertitude.
• Que faut‐il faire?
1. Il faut réduire l’incertitude avant l’exécutionet
2. Il faut gérer l’incertitude pendant l’exécution
• Afin de gérer l’incertitude, il faut:
Être alerte et vigilant, flexible et Agile durant le projet
1. Être à l’écoute de l’équipe qui exécute le projet (gérer l’incertitude interne)
2. Être à l’écoute du client et de l’environnement (gérer l’incertitude externe)
La méthodologie « Scrum »
Nouveaux rôles1. Propriétaire du produit Un client compétent2. ScrumMaster Un coach facilitateur3. Équipe polyvalente Autodirigée et engagée
MilliardièmePage en construction
Des produits et contextes différents
De 1 à 999,999,999 pages fonctionnelles 99.999% terminé, mais non fonctionnel
Un pont en construction
Site WebIKIWISI vs DTRTRTFT
Pont
Soyons Agile! Cessons de planifier et passons à l’action! Il faut tester nos idées! On devra s’adapter, car on découvrira de ce qu’il faut faire en le faisant IKIWISI! Le site évoluera et répondra à de nouveaux besoins en cours de route.Construisons sans attendre!
Il faut très bien planifier tous les détails, la vie du public en dépend et le pont devra répondre au besoin pour les 50 prochaines années. On ne pourra pas le changer! Il faut encore planifier, car il ne faut pas se tromper DTRTRTFT.Prenons le temps de bien planifier le tout en détail.
Contradiction
Les processus vs le cycle de vie
Démarrage Planification Exécution Clôture
Processusde démarrage
Processus de planification Processus
d’exécutionProcessusde clôture
Processus de suivi et contrôle
Phase/étape
Processus
Cycle de vie
Phase‐gateWaterfall
Les processus vs le cycle de vie
Démarrage Planification Exécution ClôturePhase/ étape Identification Design Construction Terminaison
Démarrage Planification Exécution Clôture
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
Processus
Cycle de vie
Phase‐gateWaterfall
Les processus vs le cycle de vie
Phase/ étapeitération Identification D1 Construction Terminaison
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DPE
CS/C
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DémarragePlanification
Exécution
ClôtureSuivi/Contrôle
DPE
CS/C
DPE
CS/C
DPE
CS/C
D2 D3 D4
Design
Processus
Cycle de vie
Phase‐gateWaterfall
(PMBOK, 2008)
Les processus de gestion de projet
Identification Design ConstructionOpérations
Support
TerminaisonTemps
Res
sour
ces Cycle de vie
du projet
Cycle de vie vs groupe de processus
(PMBOK, 2008)
Les processus de gestion de projet
Revue et rétrospective
Planification d’une phase VS d’une itération
Identifier les objectifs d’une
phase VS d’une itération
Autoriser les travaux VS gestion très active; mêlée quotidienne; identification des
problèmes; coaching; facilitation /protection;
etc.
Valeur acquise VS burndown chart et calcul de la vélocité, etc.
Le cas d’un projet de construction
Identification Design Construction OpérationsSupport
Terminaison
Res
sour
ces Coût de
changer
Le cas du développement d’un logiciel
Identification Design Codage et Test OpérationsSupport
Terminaison
Res
sour
ces
Coût dechanger
Opérations SupportLivrable fonctionnel
plus tôt
Waterfall
Identification Design Construction OpérationsSupport
Terminaison
Res
sour
ces
Coût dechanger
Le cas d’un projet de construction
Universalité des approches agiles
1. Les valeurs et les principes agiles peuvent s’appliquer presque intégralement à certaines phases de plusieurs types de projet.
2. Les modèles agiles et traditionnels se confondent sur plusieurs points si on interprète une itération du modèle agile comme une sous‐phase à durée fixe du cycle de vie du projet.
3. Les modèles agiles et traditionnels se complètent, si on considère que les approches agiles proposent de nouvelles pratiques pour un groupe de processus auparavant négligé: le groupe de processus d’exécution.
4. On doit adapté le cycle de vie et les processus au type de produit.
Agile comme un Gagaku
Origine: 1,200 ansMusiciens: 8‐30 confrèresPartition: OuverteValeur: « WA »Direction: Autodirection
Origine: 1,200 ansMusiciens: 8‐30 confrèresPartition: OuverteValeur: « WA »Direction: Autodirection
Gagaku Orchestre
Origine: 400 ansMusiciens: 50‐100 virtuosesPartition: StricteValeur: PerformanceDirection: Chef
Origine: 400 ansMusiciens: 50‐100 virtuosesPartition: StricteValeur: PerformanceDirection: Chef
HIROKO NAGAYA, HISATO HAMA (2008)
.
Le chef de projet
Un système Agile
Questions ?• Est‐ce que le gestionnaire de projet a besoin de soin
palliatif?
• Est‐ce que le système Agile est fractal (scalable)?
• Est‐ce que le vrai travail en équipe multidisciplinaire et l’engagement de l’équipe nécessitent la polyvalence de ses membres?
• Serez‐vous à l’AGILE TOUR le 24 novembre à l’UQAM?• 500 partisans • 85$ avec lunch• 22 conférenciers; 5.5 PDUs