Management de projet agile vs classique pmi atlantic 20120322

Présentation préparée par Jean-Luc MAZE, CSM, CSPO
Pour la journée du 22 mars 2012 du PMI Atlantic

(c) C & MOI 2012 P.M. : Quelle Approche ? 1

Plan de la présentation
 Management de projet
 Concepts de base
 Etat des lieux
 Genèse de l’agilité
 Exemple d’approche Agile
 Le framework Scrum
 Les Rôles
 Les Times-Boxes
 Les Artefacts
 « Classicisme » ou « Modernité » ?
 Les points communs
 Les complémentarités
 Les antagonismes
 Synthèse
 Les limites des modèles
 La sagesse vient avec l’âge…


MANAGEMENT DE PROJET :
– SCÈNES DE LA VIE
« ORDINAIRE »


Management de projet
Le projet « idéal »

CdPilot. du 14/06 CdPilot. du 28/06 CdPilot. du 05/07
-Point sur les activités -Point sur les activités -Point sur les activités
réalisées réalisées réalisées
-Présentation du dossier de -Présentation des -Signature du PV de recette
spécification développements -Pot de clôture
-Planning de Réalisation -Planning de Réception
-Pot de lancement -Pot de fin d’étape


La vraie vie


Le cauchemar


MANAGEMENT DE PROJET
:
– LES FONDAMENTAUX


Quelques définitions
Projets

 Un projet est une entreprise temporaire
décidée dans le but de créer un produit,
un service ou un résultat unique.
 Il est caractérisé par des dates de début
et de fin formelles
 Il se termine lorsque ses objectifs sont
atteints et que les livrables satisfont les
commanditaires

Opérations

 A la différence des projets, les opérations
sont continues et répétitives.
 Si il existe une date de début pour une
opération, elle n’a pas de date de fin
prédéfinie
 Le but d’une opération est de soutenir
l’activité de l’entreprise



 Le management de projet est l’application :
 De connaissances,
 De compétences,
 D’outils,
 et de techniques
aux activités du projet afin d’en respecter les
exigences.



 Le management de projet est effectué en
appliquant et en intégrant les processus
des cinq groupes suivants:
Démarrage;
Planification;
Exécution;
Surveillance et maîtrise;
Clôture. Roue de Deming


Chef de projet
 Les spécificités du projet auront une influence sur
les contraintes. Le chef de projet doit porter une
attention particulière aux variables suivantes :
• Budget ;
• Echéancier ;
• Qualité ;
• Contenu ;
• Ressources.


MANAGEMENT DE
PROJET
FONDATION DU MOUVEMENT
(c) C & MOI 2012
AGILE
P.M. : Quelle Approche ? 13

La genèse du phénomène Agile

 En 2001, dix-sept figures du développement
logiciel se sont réunies pour débattre du thème
unificateur de leurs méthodes respectives.
 De cette réunion devait émerger le Manifeste
Agile, considéré comme la définition canonique
du développement Agile .
 Il se compose de 4 valeurs et de 12 principes.

+ de détail sur le document distribué à l’accueil

Les concepts de l’agilité
Les valeurs fondamentales
Valeur Traductions

On privilégie les relations humaines, la communauté des
développeurs et le rôle de “l’humain” dans le déroulement du
L’interaction avec les personnes plutôt que les
projet, à contrario des processus institutionnalisés et
processus et les outils. déshumanisant, et des outils de développements qui ne laisse pas
libre cours à la créativité.

L’objectif principal des développeurs est de produire, en
Un produit opérationnel plutôt qu’une permanence ou presque, une application opérationnelle. L'objectif
documentation pléthorique. de réaliser une documentation technique et utilisateur considérées
comme ayant peu de valeur ajouté pour le client est secondaire.

La collaboration Client/Développeurs prime sur le contrat : On
La collaboration avec le client plutôt que la peut ainsi répondre aux besoins du client, et non aux contraintes
négociation de contrat. d’un contrat. Cela implique une confiance certaine entre la MOA
et la MOE et une bonne maturité juridique.

L’équipe projet (Développeurs et utilisateurs référents) doivent
La réactivité face au changement plutôt que le être préparés au changement; le planning doit être souple et
suivi d'un plan. chacun doit se remettre en question en permanence. Planifier est
important, mais adapter le contenu du planning l'est tout autant.


Les principes fondateurs (1/4)
Principes Traductions

Notre première priorité est de Toute la création de valeur doit être justifié par la vue client. La seule vraie justification de valeur
satisfaire le client en livrant tôt possible est démontrable uniquement lorsque le client se rend compte de l'utilisation réelle des
et régulièrement des logiciels produits livrés. La valeur identifiée lors de la livraison apporte naturellement au client la satisfaction
utiles. requise par le projet. Le cercle vertueux livraison/satisfaction est en place et le projet peut continuer.

La notion de cahier des charges évolutifs est ici annoncé. Il permettra au client de préciser au cours
Le changement est accepté, du projet ses idées pas toujours très claires au début du projet, dans le but de créer la juste valeur
même tardivement dans le attendue par les utilisateurs. Le changement du cahier des charges permet d'éviter la création de
fonctionnalité à faible valeur ajoutée. Pour autant, les développeurs doivent accepter ce changement
développement. Les processus
qui peut être déstabilisant par certains aspects. A l'inverse le client doit accepter lui aussi que les
agiles exploitent le changement développeurs refassent une partie du produit pour plus de qualité, et donc de satisfaction client. Il faut
comme un avantage compétitif donc : que le client gère en permanence ses priorités, que les développeurs acceptent les
pour le client. modifications des exigences et du code, que le chef de projet adapte la façon de travailler
continuellement.

Livrer fréquemment une
application fonctionnelle, toutes La livraison régulière et fréquente permet de se rendre compte du produit du point technique (les
les deux semaines à deux mois, développeurs) et fonctionnel (le client) et donc de se remettre en question. Des délais courts
avec une tendance pour la permettent également de réduire le risque d'erreurs sur ces deux aspects.
période la plus courte.


La collaboration quotidienne permet d'augmenter la productivité en abandonnant la création de
Les gens du métier et les documents intermédiaires qui n'ont pas de valeur pour le produit final. Il faut donc : être souple dans
développeurs doivent collaborer les relations contractuelles, être proche physiquement, s’assurer de la communauté et de la
quotidiennement au projet. compréhension des objectifs, prendre des décisions collégiales, se répartir les responsabilités, s’auto-
gérer, mettre en commun le travail (le code appartient à tous les développeurs).

Les membres de l'équipe (client et développeurs) doivent être motivé par leur métier, car cette
Bâtissez le projet autour de motivation pousse à l'excellence, et donc à l'augmentation de la productivité. Il s'agit d'un pré requis
personnes motivées. Donnez fort. Mais ce n'est pas suffisant : tout ce qui peut gêner les membres de l'équipe dans l'atteinte de
leur objectif doit être levé. Enfin les membres de l'équipe doivent bénéficier d'une délégation forte de
leur l'environnement et le
la part de leur hiérarchie organisationnelle et projet, pour décider rapidement sur des points
soutien dont elles ont besoin, et fonctionnels (le client) ou techniques (les développeurs). Cela passe par la confiance de cette
croyez en leur capacité à faire le hiérarchie. Le facteur humain est la clé du succès. Les individus sont professionnels : disciplinés,
travail. prompts à suivre les instructions. Les individus sont fort : communicants, curieux, en reproduction et
adaptation. Les individus sont fiers : de leur travail, de leur contribution, de leur réussite.

La méthode la plus efficace de
Donc augmenter l'efficacité consiste au mieux à aller discuter avec la personne, au pire à l'appeler au
transmettre l'information est
téléphone. Inutile d'essayer le mail, et encore moin la rédaction d'un document word.
une conversation en face à face.


Un logiciel fonctionnel est la
Pour réaliser le reporting du projet, nul besoin de feuilles d'activité (timesheets). Le seul indicateur
meilleure unité de mesure de la
d'avancement du projet est le nombre des fonctionnalités réalisées et/ou utilisées.
progression du projet.

Les processus agiles
promeuvent un rythme de Les heures supplémentaires sont fortement déconseillées. L'équipe n'est plus performante au bout de
développement soutenable. huit heure de travail, qu'elle aille se reposer et se changer les idées : demain lui donnera son
Commanditaires, développeurs efficacité. Les pressions dues au deadline projet sont également limitées : si certaines fonctionnalités
et utilisateurs devraient pouvoir ne sont pas développés pour la deadline, elles le seront à la suivante, ou elles ne le seront pas, selon
le choix du client.
maintenir le rythme
indéfiniment.
L'excellence technique est également un prérequis fort. Au besoin, les ressources devront suivre des
Une attention continue à formations. Cette excellence permet à l'équipe de se focaliser sur la qualité (le travail bien fait) qui est
l'excellence technique et à la indispensable pour la satisfaction du client. Aucun compromis de ce coté-ci n'est possible. Le
qualité de la conception développement agile requiert : un code propre, un code robuste (Testé). Il faut donc : refactoriser
améliore l'agilité. régulièrement le code, effectuer des revues croisées de code, tester en permanence (Ce qui n’est pas
testé n’existe pas).


La simplicité - l'art de Inutile de développer des lignes de code pour faire plaisir à un développeur : elles coûteront en
maximiser la quantité de travail maintenance et c'est autant de raisons supplémentaires de défaut. Par ailleurs, plus un code est
à ne pas faire - est essentielle. simple, plus il est lisible

Les meilleures architectures,
Nul besoin d'experts dans un projet agile. La meilleure solution ne viendra pas d'une seule personne,
spécifications et conceptions
mais du collectif. Nul besoin non plus de dire comment les équipes doivent s'organiser, elles
sont issues d'équipes qui s'auto- trouveront elles-mêmes l'organisation qui leur convient le mieux..
organisent.

À intervalle régulier, l'équipe La vie n'est pas un long fleuve tranquille ; il faut donc en permanence s'adapter aux situations
réfléchit aux moyens de devenir nouvelles. Cette adaptation a pour objectif d'être plus efficace et de se concentrer sur son propre
plus efficace, puis accorde et métier qui est notre première source de motivation. Il est nécessaire de se questionner en permanence
ajuste son comportement dans sur : l’utilité d’une exigence, l’utilité de telle partie de code, la façon de travailler, via des réunions à
intervalles réguliers et un recul personnel quotidien
ce sens.


La déclaration d’interdépendance
 Des approches agiles et adaptatives pour lier les personnes, les projets et la
valeur.
 Nous sommes une communauté de chefs de projet qui ont fortement réussis à
fournir des résultats. Pour réaliser ces résultats :
 1. Nous faisons de l’augmentation du retour sur l'investissement en générant à flux
continu de la valeur notre objectif.
 2. Nous fournissons des résultats fiables en engageant les clients dans des
interactions fréquentes et le partage de la propriété.
 3. Nous envisageons l'incertitude et la gérons par itérations, anticipation et
adaptation.
 4. Nous libérons la créativité et l'innovation en reconnaissant que les individus sont la
source ultime de la valeur, et en créant un environnement où ils peuvent faire la
différence.
 5. Nous améliorons la performance par l’engagement du groupe sur les résultats et la
responsabilité partagée de l'effectivité de l’équipe.
 6. Nous améliorons l’effectivité et la fiabilité par des stratégies, des processus et des
pratiques adaptées aux situations spécifiques.

Les méthodes «Agile»
disponibles


Management de projet agile
Mise en situation


MANAGEMENT DE
PROJET
LE FRAMEWORK SCRUM

Le framework de Scrum

7 TimeBoxes 3 Rôles

4 Artefacts


Les trois rôles :



Les 6 time-boxes :



Les 4 artefacts :


Scrum : Acteurs, time-boxes, Artefacts

Le Product Owner est en charge de :


Scrum : Acteurs, time-boxes, Artefact
Le Scrum Master est en charge de :



L’équipe :
• ne comporte pas de rôles prédéfinis pour
ses membres
• Il n'y a pas non plus de notion de
hiérarchie interne :
• toutes les décisions sont prises ensemble
• personne ne donne d'ordre à l'équipe
sur sa façon de procéder.
• L'équipe s'adresse directement au
Product Owner
• La composition de l’équipe doit rester
stable durant le sprint (au minimum).


Preparation
Vision for action Sprint
review

Release
Sprint Da
Planning ily
retrospective Sta
nd-
UP

Sprint 1-4
Planning weeks
Sprint



L’objectif doit être défini !



Préparation de l’action :


La plus grande difficulté

Aucune de mes propositions
Comment se passe ton Parfait , tu as clairement
n ’ est inscrite au backlog .
identifié le Product
expérience Scrum Dans le prochain sprint je
à la maison ?
dois Owner
Repeindre la cuisine , garder maison…
Pas exactement comme Dans ta
je l ’ avais prévu . 5 enfants , payer un spa à
mon épouse et à ses 3
amies


Product Backlog :



 Syntaxe de construction des User Stories :
 User Stories :
• En tant que <Rôle> (As a <User role>)
• Je souhaite pouvoir <Fonctionnalité> (I want to <Functionality>)
• Afin de <Bénéfice> (so that <value>)

En tant que <Rôle>

Je souhaite <Fonctionnalité>
Facultatif
Afin de <Bénéfice>



Exemple de User Stories :
En tant qu’utilisateur En tant qu’utilisateur
Je souhaite réserver une place Je souhaite pouvoir créditer
pour le prochain tournoi de mon compte en ligne
poker Afin de pouvoir parier
Afin de pouvoir jouer

En tant que joueur adictif En tant que « High Roller »
Je souhaite un lien pointant (Baleine)
sur un site d’assistance Je souhaite une table ouverte
comportementale aux paris > à 10K€
Afin de pouvoir contrôler mes Afin de pouvoir jouer gros
pulsions



Toujours formaliser les conditions d’acceptation :

Vérifier qu’un même utilisateur
En tant qu’utilisateur ne peux pas réserver plus d’un
Je souhaite réserver une place siège par tournoi
pour le prochain tournoi de Vérifier que l’utilisateur peut
poker annuler sa réservation jusqu’à
Afin de pouvoir jouer l’ouverture du tournoi
Vérifier que l’utilisateur reçoit

un email de confirmation



Privilégier des histoires sans zone d’ombre :
En tant qu’utilisateur
Je souhaite pouvoir réserver
une place pour le prochain
Je souhaite réserver une place
tournoi de poker jusqu’à la
pour le prochain tournoi de
dernière minute
poker
Je souhaite recevoir un email
de confirmation
Afin d’être sûr d’être inscrit



Les « histoires » techniques sont à proscrire
du product backlog (mais à intégrer au sprint
backlog):
En tant que système de paiement
Je souhaite que les échanges
soient effectués en XML
Afin de normaliser les En tant que programmeur
échanges Je souhaite disposer d’une API
pour supprimer les doublons dans
la base de données
Afin de faciliter le développement


Product Backlog Iceberg :

Epic :

Affinage continu
Taillée pour un

Priorité
Un « large » Sprint
besoin
fonctionnel
Curent
Thème : Release
Une collection
d’items du Futur
Backlog liés Releases
fonctionnellement


Valorisation des Users Stories
Permet de classer les user stories selon la
criticité métier
Sont possibles les valeurs suivantes
(FISPE) Fonctionnalité :
-I : Indispensable (Must Have)
-S : Souhaitable (Should Have)
-P : Possible (Could Have)
-E : Eliminé (Want to Have but
Won’t Have »)

Permet de classer les User Stories par
niveau de « complexité » à les réaliser
Sont possibles les valeurs :
1, 2, 3, 5, 8, 13, 21, …

Nota : 13 vaut de 9 à 20 !

Les valeurs de Scrum


 Une bonne User Story est :
 Bâtie sur la matrice Rôle / Fonctionnalité / Bénéfice :
(Rachel Davies et Tim McKinnon en 2001)
• En tant que (Rôle)
• Je veux que (Fonctionnalité)
• Afin de (Bénéfice)
 CCC (3C) :
(Ron Jeffries en 2001)
• Card (Carton) doit tenir sur une fiche bristol / Post-It
• Conversation (Conversation) doit servir de support à un dialogue entre le métier et le développeur
• Confirmation (Confirmation) doit préciser dans les critères d’acceptation comment va être validé
l’atteinte des objectifs
 INVEST : ∗ GWT :
(Bill WAKE en 2003 )
(Dan North 2006)
• Indépendante des autres
∗ Given (Etant donné) un contexte
• Négociable initialement, plutôt qu’un engagement ferme
∗ When (Lorsque) l’utilisateur fait une action
• Valorisante ou ayant de la valeur en soit pour le métier
• Evaluable donc suffisamment précise pour être chiffrée ∗ Then (Alors) on doit constater tels résultats
• Suffisamment petite pour être aisément planifiable
• Testable donc dotée de critères d’acceptation


Product Backlog « hiérarchisé » :



 Un bon Backlog est :
 DEEP :
• Détaillé à un niveau suffisant (Detailled sufficienty)
• Estimé (Estimated)
• Evolutif (Emergent / In evolution)
• Priorisé (Prioritized)
 Physique
 Partagé
 Visible
 Entretenu
…

Planification des releases :


Durée des sprints :

La durée du sprint doit être déterminée en :
-Prenant en compte la capacité à reporter les changements sur
le prochain sprint
-Tenant compte de la granularité moyenne des Users Stories



Planification du sprint :


Définition du « done » :
• Code écrit (tous les «à faire» développés)
• Code documenté et inscrit dans le gestionnaire de
versions
• Revu par un tiers et respectant les standards de
développement
• Assemblé sans erreur (Build)
• Tests unitaires écrits et effectués
• Déployé sur l’environnement d’intégration et tests de
non-régression OK
• Accepté par les utilisateurs et présenté lors de la sprint
review
• Documentation produite ou mise à jour
• Testé dans l’environnement de pré-production et tests
de performance OK
• Mise à jour des tableaux de bord de suivi de projet
(tache clôturée, temps restant à zéro,…)

 Durant le sprint :
 L’équipe :
• Réalise les travaux inscrits au sprint backlog
• Participe au daily stand-up meeting
• Gère la maintenance du backlog
• Travaille avec le product owner
 Le Product Owner :
• Collabore avec l’équipe pour répondre aux questions
Et dire que je • Participe au daily stand-up meeting
n ’ aime
• Accepte ou refuse les livrables présentés par l’équipe
pas les carottes …
 Le Scrum Master :
• S’assure que les fondamentaux de Scrum sont en place
• Participe au daily stand-up meeting
• Œuvre à lever les empêchements
• Met à jour les tableaux de bord de suivi


Sprint : courir sur une faible distance à la vitesse
la plus rapide possible 
Itération : action de répéter un processus 

Et dire que je
n ’ aime
pas les carottes …



Daily StandUp :


Le daily stand-up:


Le Dailly stand-up :
Je pense que Qu ’ est - Juste un Son Dolby et
le Stand - Up ce qui te pressentiment lunettes 3 D… on est
dérive fait dire … prêt !
quelque peu… ça ?


Le bon moment pour mettre à jour le ScrumBoard !


Un petit dessin vaut mieux…

© Egilia 2011 Management de Projets : L'agilité 58

 La revue de Sprint :
 L’équipe présente ce qu’elle à fait
pendant le sprint
 Se fait avec démo des nouvelles
fonctionnalités ou de l’architecture
 On rend compte de la progression du
projet
 Informel :
• Préparation > 2h
• Pas de slide,…
 Toute l’équipe participe
 On invite tout le monde


Mettre à jour le Sprint Burndown Chart !
Statut Valeur Estimation
Reference US Effort RAF actualisé en H
(A,E,S,T,R) Metier en H
USM09 T 25 5 10 10 10 10 10 10 10 8 7 6 0
Catalogue US type 3 3 3 3 3 3 3 1 0

USM25 T 50 3 6 6 6 5 5 2Vélocité0 sprint 6
0 0 0 0
Cloner une US 1 1 1 0 0
Volume d'effort produit 22
USM41 T 100 3 4 4 4 4 4 4 Nb J/H 0
1 0 0
consommés 0 9
Sortir une US d'un Sprint 1 1 1 1 1 1 0
Vélocité ==> 2,44
USM45 T 50 3 7 7 7 3 2 0 0 0 0 0 0
Bloquer une US 1 1 1 0 0

USM46 T 50 2 6 6 6 3 2 0 0 0 0 0 0
Reprendre une US 1 1 1 0 0

UST71 T 50 5 3 3 3 3 3 1 1 1 0 0 0
Intégrer un mécanisme de version 3 3 3 3 3 1 1 1 0

UST72 T 50 1 2 2 0 0 0 0 0 0 0 0 0
Mise en place du jeux de donnée pour le demarrage de la 2 2 0
release 2


Mettre à jour les « Project’s BurnUp Charts » !
120 240 6000
115 230 5750
110 220 5500
105 210 5250
100 200 5000
95 190 4750
90 180 4500
85 170 4250
80 160 4000
75 150 3750
70 140 3500
65 130 3250
60 120 3000
55 110 2750
50 100 2500
45 90 2250
40 80 2000
35 70 1750
30 60 1500
25 50 1250
20 40 1000
15 30 750
10 20 500
5 10 250
0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13 0 S1 S2 S3 S4 S5 S6 S7 S8 S9 S10 S11 S12 S13


C’est le moment pour calculer la vélocité !
•Vélocité estimé au départ :
•Capacité de l’équipe à prendre en charge N point de
complexité durant un sprint
•Calcul de la vélocité du sprint :
•On divise le volume de jours/homme ayant été disponibles
durant le sprint par le cumul des points de complexités liés
aux Users Stories livrées durant le sprint.
•Analyse comparative et tendancielle :
•Vélocité Estimée vs Vélocité Constatée
•Vélocité moyenne, point bas, point haut…


200
190
1,67
180
170
Planification du sprint N+1 :
160 + 20 Points :
150 A la vélocité
140 la plus haute
130
120 + 15 Points :
110 A la vélocité
100 Moyenne
90
+ 11 Points :
80 A la vélocité
70 la plus basse
S4 S5 S6 S7 S8 S9 S10 S11 S12 S13
60
50


La rétrospective de sprint :




Avant… Pendant… Après…


Preparation
Vision for action Sprint
review

Release
Sprint Da
Planning ily
retrospective Sta
nd-
UP

Sprint 1-4
Planning weeks
Sprint


Résultat du sprint :


Limite du modèle Agile (Scrum)

Combinaison normale :

Combinaison envisageable :



Combinaison envisageable :



Combinaison à éviter :



Combinaison à proscrire :


Scrum en 100 mots


Les valeurs de Scrum


Rapide Comparaison (1/2)
Thème « Traditionnelle » « Agile »
Cycle de vie En cascade, en V, sans Itératif et incrémental
rétroaction possible
Planification Predictive, basée sur des plans Adaptative avec plusieurs niveaux de
(+/- détaillés), sur la base d’un planification (macro,micro,..) et
périmètre et d’exigences définies ajustement au fil de l’eau (changement,
et stable (au début du projet…) performance,…)
Documentation En forte quantité pour support à Réduite au stricte nécessaire au profit
la communication, la validation, d’incréments fonctionnels opérationnels
la contractualisation (convenir au client)
Equipe Equipe avec ressources Equipe responsabilisée où l’initiative est
spécialisées dirigée par un chef la communication sont privilégiées
de projet soutenue par un chef de projet
Qualité Contrôle qualité en fin de cycle. Contrôle qualité précoce et permanant,
Le client découvre le produit fini. au niveau du produit et du processus.
Le client visualise le produit tôt et
fréquemment

Rapide Comparaison (2/2)

Thème « Traditionnelle » « Agile »
Changement Resistance (voir opposition) au Accueil favorable au changement
changement. inéluctable, intégré dans le processus
Processus lourds de gestion des
changements acceptés
Suivi Mesure le da conformité aux Un seul indicateur d’avancement, le
avancement plans initiaux (ou révisés). nombre de fonctionnalités
Analyse des écarts implémentées (en valeur business) et la
charge de travail restant à faire
Gestion des Processus « distinct », rigoureux Processus intégré basé sur la
risques de gestion des risques responsabilisation de chacun. Peut
rapidement avoir des limites
Mesure du Respect des engagements Satisfaction du client par livraison de
succès initiaux en termes de budget, de valeur ajoutée (ou souhaitée)
délais et de qualité


Les points communs


Les complémentarités


Les antagonismes : Relation Clients/Fournisseurs


Les antagonismes : Variables d’ajustement

« Traditionnelle « Agile »
»
On détermine Fonctionnalités Cout Echéancier

On évalue Echéancier Cout Fonctionnalités


Les antagonismes : Génération de valeur

Livrer de la
valeur à la
fin


Les antagonismes : La place des tests

Agile

Traditionnelle


Les antagonismes : Manager de Projet

« Agile »

« Traditionnelle »


La sagesse vient avec l’âge…

Je conseille l’Agilité :
Dans un contexte «d’inculture» en Management de
Projet ;
Comme thérapie de groupe après un échec ;
Lorsque les délais sont courts et/ou que la formalisation
du besoin est faible ;
Lorsque l’on ne veut pas nommer un chef de projet mais
le laisser se découvrir ;
Lorsque l’outillage mis à la disposition de l’équipe peut
lui aussi être « agile » ;



Je déconseille l’Agilité :
Si il n’y a pas de vision construite (ou à construire) ;
Dans le cas de projet à fort niveau de bruit (Anarchie) ;
Si l’outillage de développement n’est pas un minimum
orienté « Agile » (Incrémental et Itératif)
Dans des contextes d’appel d’offre « Public » ;
Au Scrum Master sans expérience du Management de Projet
Au Product Owner sans compétence du métier
Si l’on ne sait pas qui est le Product Owner !
Si le Product Owner est hostile !


Pour aller plus loin…



http://guide.agilealliance.org/subway.html


Regarde -
Il utilise la
version ptimisée
de la roue de
Deming !


Scrum = ma belle mère !


Pour aller plus loin :
Manifeste Agile : http://agilemanifesto.org/
Agile Alliance : http://www.agilealliance.org/
Scrum Alliance : http://www.scrumalliance.org/
Réference & Blog : http://referentiel.institut-agile.fr//
PMI & Agilité : http://agile.vc.pmi.org/default.aspx
Livres : Gestion de projet Agile Ed Eyrolles
de Véronique Messager Rota
Succeeding with Agile Ed Alddison Wesley
de Mike Cohn
Vidéo :
http://agile-pm.pbworks.com/Confessions-of-an-Agile-Project-Manage
.

Pour aller plus loin :
….
Jean-Luc MAZE
+33 6 31 86 29 99
jlmaze@conseiletmoi.com

Générateur
de
Visibilité

Management de projet agile vs classique pmi atlantic 20120322

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Management de projet agile vs classique pmi atlantic 20120322

Similar to Management de projet agile vs classique pmi atlantic 20120322 (20)

More from Jean-Luc MAZE

More from Jean-Luc MAZE (7)

Management de projet agile vs classique pmi atlantic 20120322

Editor's Notes