CONF. 304 - L'intégration des approches agiles et traditionnelles au bénéfice de tous les...

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