Management de projet agile vs classique pmi atlantic 20120322
1. 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
2. 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…
(c) C & MOI 2012 P.M. : Quelle Approche ? 2
3. MANAGEMENT DE PROJET :
– SCÈNES DE LA VIE
« ORDINAIRE »
(c) C & MOI 2012 P.M. : Quelle Approche ? 3
4. 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
(c) C & MOI 2012 P.M. : Quelle Approche ? 4
7. MANAGEMENT DE PROJET
:
– LES FONDAMENTAUX
(c) C & MOI 2012 P.M. : Quelle Approche ? 7
8. 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
(c) C & MOI 2012 P.M. : Quelle Approche ? 8
9. Quelques définitions
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 9
10. Quelques définitions
Management de projet
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 10
11. Quelques définitions
Management de projet
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 11
12. Quelques définitions
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 12
13. MANAGEMENT DE
PROJET
FONDATION DU MOUVEMENT
(c) C & MOI 2012
AGILE
P.M. : Quelle Approche ? 13
14. Management de projet
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 14
15. 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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 15
16. Les concepts de l’agilité
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 16
17. Les concepts de l’agilité
Les principes fondateurs (2/4)
Principes Traductions
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 17
18. Les concepts de l’agilité
Les principes fondateurs (3/4)
Principes Traductions
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).
(c) C & MOI 2012 P.M. : Quelle Approche ? 18
19. Les concepts de l’agilité
Les principes fondateurs (4/4)
Principes Traductions
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 19
20. Les concepts de l’agilité
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.
(c) C & MOI 2012 P.M. : Quelle Approche ? 20
21. Management de projet
Les méthodes «Agile»
disponibles
(c) C & MOI 2012 P.M. : Quelle Approche ? 21
22. Management de projet agile
Mise en situation
(c) C & MOI 2012 P.M. : Quelle Approche ? 22
23. MANAGEMENT DE
PROJET
LE FRAMEWORK SCRUM
(c) C & MOI 2012 P.M. : Quelle Approche ? 23
24. Management de projet agile
Le framework de Scrum
7 TimeBoxes 3 Rôles
4 Artefacts
(c) C & MOI 2012 P.M. : Quelle Approche ? 24
25. Management de projet agile
Le framework de Scrum
Les trois rôles :
(c) C & MOI 2012 P.M. : Quelle Approche ? 25
26. Management de projet agile
Le framework de Scrum
Les 6 time-boxes :
(c) C & MOI 2012 P.M. : Quelle Approche ? 26
27. Management de projet agile
Le framework de Scrum
Les 4 artefacts :
(c) C & MOI 2012 P.M. : Quelle Approche ? 27
28. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Le Product Owner est en charge de :
(c) C & MOI 2012 P.M. : Quelle Approche ? 28
29. Management de projet agile
Scrum : Acteurs, time-boxes, Artefact
Le Scrum Master est en charge de :
(c) C & MOI 2012 P.M. : Quelle Approche ? 29
30. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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).
(c) C & MOI 2012 P.M. : Quelle Approche ? 30
31. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Preparation
Vision for action Sprint
review
Release
Sprint Da
Planning ily
retrospective Sta
nd-
UP
Sprint 1-4
Planning weeks
Sprint
(c) C & MOI 2012 P.M. : Quelle Approche ? 31
32. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
L’objectif doit être défini !
(c) C & MOI 2012 P.M. : Quelle Approche ? 32
33. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Préparation de l’action :
(c) C & MOI 2012 P.M. : Quelle Approche ? 33
34. Management de projet
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 34
35. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Product Backlog :
(c) C & MOI 2012 P.M. : Quelle Approche ? 35
36. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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>
(c) C & MOI 2012 P.M. : Quelle Approche ? 36
37. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 37
38. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 38
39. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Privilégier des histoires sans zone d’ombre :
En tant qu’utilisateur
Je souhaite pouvoir réserver
En tant qu’utilisateur
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
Afin de pouvoir jouer
Afin de pouvoir jouer
En tant qu’utilisateur
Je souhaite recevoir un email
de confirmation
Afin d’être sûr d’être inscrit
(c) C & MOI 2012 P.M. : Quelle Approche ? 39
40. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 40
41. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 41
42. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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 !
(c) C & MOI 2012 P.M. : Quelle Approche ? 42
43. Management de projet agile
Les valeurs de Scrum
(c) C & MOI 2012 P.M. : Quelle Approche ? 43
44. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 44
45. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Product Backlog « hiérarchisé » :
(c) C & MOI 2012 P.M. : Quelle Approche ? 45
46. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Un bon Backlog est :
DEEP :
• Détaillé à un niveau suffisant (Detailled sufficienty)
• Estimé (Estimated)
• Evolutif (Emergent / In evolution)
• Priorisé (Prioritized)
Physique
Partagé
Visible
Entretenu
…
(c) C & MOI 2012 P.M. : Quelle Approche ? 46
47. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Planification des releases :
(c) C & MOI 2012 P.M. : Quelle Approche ? 47
48. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 48
49. Management de projet agile
Scrum : Acteurs, time-boxes, Artefact
Planification du sprint :
(c) C & MOI 2012 P.M. : Quelle Approche ? 49
50. Management de projet agile
Scrum : Acteurs, time-boxes, Artefact
Planification du sprint :
(c) C & MOI 2012 P.M. : Quelle Approche ? 50
51. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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,…)
(c) C & MOI 2012 P.M. : Quelle Approche ? 51
52. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 52
53. Management de projet agile
Scrum : Acteurs, time-boxes, Artefact
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 …
(c) C & MOI 2012 P.M. : Quelle Approche ? 53
54. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Daily StandUp :
(c) C & MOI 2012 P.M. : Quelle Approche ? 54
55. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Le daily stand-up:
(c) C & MOI 2012 P.M. : Quelle Approche ? 55
56. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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 ?
(c) C & MOI 2012 P.M. : Quelle Approche ? 56
57. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Le bon moment pour mettre à jour le ScrumBoard !
(c) C & MOI 2012 P.M. : Quelle Approche ? 57
59. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 59
60. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 60
62. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
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…
(c) C & MOI 2012 P.M. : Quelle Approche ? 62
63. 200
Management de projet agile
190
1,67
Scrum : Acteurs, time-boxes, Artefact
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 63
50
64. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
La rétrospective de sprint :
(c) C & MOI 2012 P.M. : Quelle Approche ? 64
65. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
La rétrospective de sprint :
(c) C & MOI 2012 P.M. : Quelle Approche ? 65
66. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
La rétrospective de sprint :
Avant… Pendant… Après…
(c) C & MOI 2012 P.M. : Quelle Approche ? 66
67. Management de projet agile
Scrum : Acteurs, time-boxes, Artefact
Preparation
Vision for action Sprint
review
Release
Sprint Da
Planning ily
retrospective Sta
nd-
UP
Sprint 1-4
Planning weeks
Sprint
(c) C & MOI 2012 P.M. : Quelle Approche ? 67
68. Management de projet agile
Scrum : Acteurs, time-boxes, Artefacts
Résultat du sprint :
(c) C & MOI 2012 P.M. : Quelle Approche ? 68
69. Management de projet
Limite du modèle Agile (Scrum)
Combinaison normale :
Combinaison envisageable :
(c) C & MOI 2012 P.M. : Quelle Approche ? 69
70. Management de projet
Scrum : Acteurs, time-boxes, Artefacts
Combinaison envisageable :
(c) C & MOI 2012 P.M. : Quelle Approche ? 70
71. Management de projet
Limite du modèle Agile (Scrum)
Combinaison à éviter :
(c) C & MOI 2012 P.M. : Quelle Approche ? 71
72. Management de projet
Limite du modèle Agile (Scrum)
Combinaison à proscrire :
(c) C & MOI 2012 P.M. : Quelle Approche ? 72
73. Management de projet agile
Scrum en 100 mots
(c) C & MOI 2012 P.M. : Quelle Approche ? 73
74. Management de projet agile
Les valeurs de Scrum
(c) C & MOI 2012 P.M. : Quelle Approche ? 74
75. Management de projet
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
(c) C & MOI 2012 P.M. : Quelle Approche ? 75
76. Management de projet
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é
(c) C & MOI 2012 P.M. : Quelle Approche ? 76
78. Management de projet agile
Les complémentarités
(c) C & MOI 2012 P.M. : Quelle Approche ? 78
79. Management de projet
Les antagonismes : Relation Clients/Fournisseurs
(c) C & MOI 2012 P.M. : Quelle Approche ? 79
80. Management de projet
Les antagonismes : Variables d’ajustement
« Traditionnelle « Agile »
»
On détermine Fonctionnalités Cout Echéancier
On évalue Echéancier Cout Fonctionnalités
(c) C & MOI 2012 P.M. : Quelle Approche ? 80
81. Management de projet
Les antagonismes : Génération de valeur
Livrer de la
valeur à la
fin
(c) C & MOI 2012 P.M. : Quelle Approche ? 81
82. Management de projet
Les antagonismes : La place des tests
Agile
Traditionnelle
(c) C & MOI 2012 P.M. : Quelle Approche ? 82
83. Management de projet agile
Les antagonismes : Manager de Projet
« Agile »
« Traditionnelle »
(c) C & MOI 2012 P.M. : Quelle Approche ? 83
84. Management de projet
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 » ;
(c) C & MOI 2012 P.M. : Quelle Approche ? 84
85. Management de projet
La sagesse vient avec l’âge…
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 !
(c) C & MOI 2012 P.M. : Quelle Approche ? 85
86. Management de projet
La sagesse vient avec l’âge…
(c) C & MOI 2012 P.M. : Quelle Approche ? 86
90. Management de projet
Pour aller plus loin…
Regarde -
Il utilise la
version ptimisée
de la roue de
Deming !
(c) C & MOI 2012 P.M. : Quelle Approche ? 90
91. Management de projet agile
Scrum = ma belle mère !
(c) C & MOI 2012 P.M. : Quelle Approche ? 91
92. 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
.
(c) C & MOI 2012 P.M. : Quelle Approche ? 92
93. Pour aller plus loin :
….
Jean-Luc MAZE
+33 6 31 86 29 99
jlmaze@conseiletmoi.com
Générateur
de
Visibilité
(c) C & MOI 2012 P.M. : Quelle Approche ? 93
Hinweis der Redaktion
. La relation entre ces facteurs est telle que le changement de l’un d’eux entraînera vraisemblablement le changement d’au moins un autre facteur. Par exemple, une réduction de l’échéancier nécessite souvent une augmentation du budget afin d’obtenir des ressources supplémentaires permettant d’accomplir le même travail en moins de temps. L’impossibilité d’augmenter le budget peut entraîner une réduction du contenu ou de la qualité dans le but de livrer plus rapidement un produit. Un défi plus important se présente lorsque les parties prenantes du projet ont des idées différentes sur l’importance relative des facteurs Dans le but d’assurer le succès d’un projet, l’équipe de projet doit être capable d’évaluer la situation et d’équilibrer les demandes
Les plus connus d'entre eux étaient Ward Cunningham l'inventeur du WIKI, Kent Beck, père de l ‘ extreme programming et cofondateur de Junit, Ken Schawber et Jeff Sutherland, fondateurs de Scrum, Jim Highsmith, prônant l ‘ ASD, Alistair Cockburn pour la méthode Crystal Clear, Martin Fowler, et Dave Thomas ainsi que Arie van Bennekum pour DSDM (Dynamic System Development Method) la version anglaise du RAD
Le manifeste agile commence ainsi : nous avons trouvé une voie améliorant le développement logiciel en réalisant ce travail et en aidant les autres à le faire. De ce fait nous avons déduit des valeurs communes
Jim Highsmith et Alistair Cockburn ont regroupé en 2005 un groupe d'agilistes de renom tels que David Anderson, Mike Cohn, Todd Little pour établir six principes de management agile, promus sous le nom de Déclaration d'interdépendance . Les quinze auteurs de cette déclaration ont ensuite créé l'APLN (Agile Project Leadership Network) pour promouvoir la gestion agile de projet pour tout secteur
Crystal : ou plus proprement la famille crystal Selon table de criticité du projet (Niveau revenu (vital, essentiel, argent, confort) et taille équipe (1-6, 20, 40,…) donne une méthode plus ou moins « complexe » DSDM : reprise en + structurée du RAD (approche anglo-saxonne) Ajoute de nouveaux principes au manifeste (9 : ex – implication active des utilisateurs) ASD : (Adaptative Software Developpement) : 3 volets Spéculation : Initialise le projet, determiner la durée, le nb d’Iteration, les dates associées, affecté un objectif, Dresser la liste des taches Collaboration : livraison des composants, communication (forte et informelle) Apprentissage : contrôle qualite, suivi & bilan, communication RAD Pas « agile » a proprement parlé mais à la base du mouvement (au moins en partie) 1980 première approche semi-itérative et incrémentale préconisant un usage intensif de la communication facilitée 5 phases : Initialisation, Cadrage, Design, Construction, Finalisation UP & RUP Proche du cycle en cascade Assez impliqué (et impliquant) dans le choix de l’outillage (Rationnal puis IBM) Usage d’UML (use case,…) XP : « le must » La plus complète sans doute mais aussi la plus « elitiste » Donne toutes les réponses (mais sans les questions)… Cf doc papier !
3 Roles : Product Owner, Scrum Master, Equipe 6 Time-box : Réunion Release Planning, Réunion Sprint Planning, Sprint, Daily Stand Up, Réunion Sprint Review, Réunion Retrospective du Sprint 4 artefacts : Product backlog, Sprint Backlog, Release Burndown et BurnUp, Sprint Burndown Règle : usage de la formalisation des users stories
Il faut toujours demander l’avis de celui qui est concerné !
Se rappeler la vison donne la destination, le backlog le chemin pour s’y rendre
Planifier la durée du sprint pour permettre de différer la prise en compte d’un changement jusqu’au prochain sprint Velocité forcement estimé au depart c’est pour cela que l’on ne travaille que les 2 premiers sprints
L’équipe choisit à partir du backlog produit / release les user stories qu’elle s’engage à finir durant le sprint La liste des taches est créée : tache = découpage des users story en action « technique » de 1 à 16H La conception de haut niveau est abordée
Paramètre : Tous les jours 15 minutes Debout face au backlog du sprint Tout le monde est invité Seuls les membres de l’équipe peuvent parler
Effort en valeur métier
On utilisera ces valeurs pour la planification des sprints suivants ! Si présence d’un outils cela peut se faire en « temps réels » mais cela peut poser des PB Comme se peser tous les jours
Réfléchir régulièrement à ce qui marche et ce qui ne marche pas Dure en général de 15 à 30 minutes Fait à la fin de chaque sprint Toute l’équipe participe (ScrumMaster, Product Owener, Equipe, Eventuellement Clients et Stakholder)
Engagement Franchise Convergence Respect Courage
Partage les mêmes valeurs Obligation d’une vison On réfléchie avant de faire (SI SI même si on passe à l’action plus vite en Scrum) Chaque chose en son temps (timebox) Le feedback après l’action
Elaboration progressive : Se rapporte à un développement par étape et une progression par incrément dans la connaissance des informations En rouge pas de Projet ! En orange pourquoi pas avec Traditionnel mais il y a un risque En vert c’est « sans Probleme » L’agilité peut permettre de passer du Orange au Vert en sécurisant
Le développement Agile, appelé aussi développement adaptatif, se caractérise par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu.
Positionnement et role du Manager de projet Classique : un chef visible et « hierachique » Agile : un leader effacé (le scrum master), le PO est en fait assez proche du MP
Outillage technique : atelier type RAD ou mieux MDA (site BUSINESS FIRST de W4) Management de Projet : Web 2.0 type IceScrum ou PMA de TimePerformance (qui gère aussi tres bien le multi-projet et la valeur acquise)
Que l’on soit traditionnel ou agile Ce qui compte c’est de conduire des projets avec méthode Et de ne pas oublier que ce que l’on acquière « jeune » ne se perd jamais !
Terminer US10T1 UST10T2 et US10 Tourner le Chevalet