le pmbok n'est pas agile ?, ben voyons donc !!!

Le PMBOK n’est pas agile?: bin voyons donc!!!

Carl M. Gilbert, ing. MGP PMP ACP RMP OPM3 Technologia

[email protected]

©2012, Solutions Gestion de projets CMG inc. Tous droits réservés. www.SolutionsGPcmg.com

©2009-13, Solutions Gestion de projets CMG inc. Tous droits réservés. www.SolutionsGPcmg.com

Page 2

Votre conférencier

Carl M. Gilbert •  Président de Solutions GP CMG inc. •  Titulaire d’encadrement & formateur chez Technologia •  Consultant & praticien - 19 années d’expérience en GP •  Ingénieur (Polytechnique) & Maîtrise en gestion de projets (UQAM) •  Certifié PMP, ACP, RMP & OPM3 du PMI, Adm. A, CSM et PQS •  Dir. prog. certif. & formation PMI-Montréal (1999-2004, 2007-auj.) •  Président PMI-Montréal (2005) •  Vice-président exécutif PMI-Montréal (2001-04 & 2011-12) •  Conseil d’administration PMI-Montréal (1996-2005, 2011-12) •  PMBOK 1996, 2004, 2008, & 2012 FTVC (French translation committee)



Page 3

Plan de la présentation

•  Manifeste agile •  SCRUM vs. PMBOK 4e édition:

•  Cycle de vie •  Terminologie •  Processus •  Outils et techniques

•  Conclusion •  Période de questions



Page 4

•  Selon le PMBOK: •  Quelles sont les quatre (4) techniques pour estimer les efforts/

durées/coûts? •  Quel est le nom du dernier processus de la Gestion de

l’Intégration? •  Est-ce qu’il est nécessaire de produire un diagramme de Gantt

avec un chemin critique fait dans Microsoft Project pour avoir une bonne planification?

Questions quizz



Page 5

Évolution du PMBOK

2012 2004 1996 1983

2008 2000 1987 2013

Software Extension



Page 6

Manifeste Agile

Basé sur le Manifeste Agile (4 valeurs et 12 principes) - 2001 u  17 experts, dont Kent (XP), Schwaber & Sutherland (SCRUM) u  Les quatre valeurs fondamentales agiles sont de valoriser:

u Les individus et leurs interactions plutôt que les processus et les outils

u Des logiciels opérationnels plutôt qu’une documentation exhaustive

u La collaboration avec les clients plutôt que la négociation contractuelle

u L’adaptation au changement plutôt que le suivi d’un plan

http://www.agilemanifesto.org/



Page 7

Manifeste Agile

Basé sur le Manifeste Agile (4 valeurs et 12 principes) u  Les douze principes sont:

1.  Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée

2.  Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client

3.  Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts

4.  Les utilisateurs (ou leurs représentants) et les développeurs doivent travailler ensemble quotidiennement tout au long du projet

5.  Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés

6.  La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face



Page 8

Manifeste Agile

Basé sur le Manifeste Agile (4 valeurs et 12 principes) u  Les douze principes sont:

7.  Un logiciel opérationnel est la principale mesure d’avancement 8.  Les processus agiles encouragent un rythme de développement

soutenu. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant

9.  Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité

10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle

11.  Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées

12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence



Page 9

•  Il y a quelqu’un ici contre la vertu?

Manifeste Agile



Page 10

Cycle de vie des projets

PRÉDICTIF

ADAPTATIF

FAST-TRACKING



Page 11

Les projets sont divisés en phases (PRÉDICTIF)


CONCEPTION DÉVELOPPEMENT IMPLANTATION

EXEMPLE D’UN PROJET INFORMATIQUE PAR SÉQUENCE

CHARTE DE PROJET + PLAN DE PROJET

PLAN DÉTAILLÉ PHASE 1 PLAN DÉTAILLÉ PHASE #2 MISE EN OPÉRATION



Page 12

Les livraisons sont divisés en sprints (ADAPTATIF)


SPRINT #1 SPRINT #2 SPRINT #3

EXEMPLE D’UN PROJET INFORMATIQUE PAR ITÉRATION

VISION DU PRODUIT + PLAN DE LIVRAISON (SPRINT ZÉRO)

PLAN DU SPRINT #1 PLAN DU SPRINT #2 MISE EN OPÉRATION



Page 13


CONTENU

ADAPTATIF PRÉDICTIF

COÛTS TEMPS

COÛTS TEMPS

CONTENU

FIXE

VARIABLE

QUALITÉ

QUALITÉ



Page 14

Terminologie

Release Plan 1 Release Plan 2 Release Plan 3 Release Plan n FEUILLE DE ROUTE (ROADMAP)

Sprint 1 Sprint 2 Sprint 3 Sprint n

Story 1 Story 2 Story 3 Story n

Task 1 Task 2 Task 3 Task n

PROGRAMME

PROJET LIVRAISON (RELEASE)

SPRINT (ou ITÉRATION)

HISTOIRE (USER STORY)

LIVRABLE

ACTIVITÉ

ADAPTATIF PRÉDICTIF



Page 15

Terminologie

PRÉDICTIF ADAPTATIF Programme = Feuille de route (roadmap) Projet = Livraison Charte de projet = Vision du produit Plan de projet = Plan de livraison WBS = Backlog du produit (aka FBS) Livrable = User Story (scénario utilisateur) Activité = Tâche Estimation paramétrique = Planning poker (wideband Delphi) Efforts (h-pers) = Story points Capacité (h-pers./mois) = Vélocité (story points/sprint) Rapport d’avancement = Tableau des tâches (Kanban) Gestion des DDC = Raffinement du Backlog du produit Valeur acquise (Burnup) = Burndown chart Post-mortem = Rétrospective



Page 16

Processus

Démarrage

Planification

Exécution Contrôle

Clôture

CHARTE DE PROJET

PLAN DE PROJET

LIVRABLES RAPPORTS AVANCEMENT

+ GESTION DDC

POST-MORTEM

Il y a cinq groupes de processus : –  Démarrage –  Planification –  Exécution –  Contrôle –  Clôture



Page 17

Processus

Équipe Scrum Product Owner

Backlog du produit

ScrumMaster

Backlog du Sprint Planif.

du sprint (parties 1 & 2)

1 à 4 sem.

Revue

Rétrospective

Incrément de produit potentiellement

livrable

Raffinement du Backlog

du produit

Mêlée journalière et MAJ

des livrables

Pas de changements (durée ou objectif)

L’Équipe choisit et s’engage sur ce qui doit être livré

d’ici la fin du Sprint

Intrants des utilisateurs finaux, clients, équipe et autres parties prenantes

Adapté de « Disciplined Agile Delivery » de Scott W. Ambler



Page 18

Processus


Backlog du produit

ScrumMaster



1 à 4 sem.

Revue

Rétrospective


livrable


du produit


des livrables





DÉMARRAGE OU

« SPRINT ZÉRO »

VISION DU PRODUIT = CHARTE BACKLOG DU PRODUIT = WBS PLAN DE LIVRAISON = PLAN DE PROJET



Page 19

Processus


Backlog du produit

ScrumMaster



1 à 4 sem.

Revue

Rétrospective


livrable


du produit


des livrables





PLANIFICATION

BACKLOG DU SPRINT = PLAN DÉTAILLÉ



Page 20

Processus


Backlog du produit

ScrumMaster



1 à 4 sem.

Revue

Rétrospective


livrable


du produit


des livrables





EXÉCUTION / SUIVI&CONTRÔLE MÊLÉES JOURNALIÈRES BURNDOWN CHART TABLEAU DES TÂCHES LISTE DE PROBLÈMES



Page 21

Processus


Backlog du produit

ScrumMaster



1 à 4 sem.

Revue

Rétrospective


livrable


du produit


des livrables





CLÔTURE

DÉMO RÉTROSPECTIVE = POST-MORTEM



Page 22

Backlog du produit

Le Backlog du produit (FBS) équivaut au WBS

VÉLOCITÉ = CAPACITÉ 23 story points/sprint = 900 h-pers/mois



Page 23

Plan de livraison

Le plan de livraison équivaut au plan de projet Livraison #1 3 mois 68 story points



Page 24

Planning poker

Il y a quatre outils et techniques d’estimation –  Jugement d’expert –  Estimation analogue –  Estimation paramétrique:

–  Function Point Analysis –  Barèmes –  Planning Poker (Wideband Delphi)

–  Estimation à trois points: –  PERT



Page 25

Burndown Charts

Report Performance

WHAT’S BEEN DONE? WHAT’S REMAINING?

VALEUR ACQUISE BURNDOWN CHART



Page 26

Conclusion

•  La gestion de projet agile est très alignée avec le PMBOK, et elle l’est davantage dans le PMBOK 5e édition (glossaire)

•  Le nouveau standard « Software Extension to the PMBOK Guide », fait avec IEEE*, adressera mieux la gestion de projet agile qui a été développée initialement pour le développement logiciel

•  C’est davantage le vocabulaire qui diffère…

* Institute of Electrical and Electronics Engineers



Page 27

Conclusion

•  « Stop fighting, start working »…



Page 28

•  Période de questions

Merci!!!



Page 29

19-‐21 juin 2013

Curieux d’en savoir plus ?… Info : www.pmimontreal.org, 514.861-‐8788

Le monde devient de plus en plus Agile. L’êtes-vous ?

le pmbok n'est pas agile ?, ben voyons donc !!!

Documents