• Save
Management de projet agile vs classique pmi atlantic 20120322
Upcoming SlideShare
Loading in...5
×
 

Management de projet agile vs classique pmi atlantic 20120322

on

  • 2,402 views

Conseil et MOI : Présentation effectuée lors de la journée Agilité du Chapitre Atlantic du PMI France à Caen en mars 2012

Conseil et MOI : Présentation effectuée lors de la journée Agilité du Chapitre Atlantic du PMI France à Caen en mars 2012

Statistics

Views

Total Views
2,402
Views on SlideShare
2,291
Embed Views
111

Actions

Likes
2
Downloads
0
Comments
0

1 Embed 111

http://www.scoop.it 111

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • . 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

Management de projet agile vs classique pmi atlantic 20120322 Management de projet agile vs classique pmi atlantic 20120322 Presentation Transcript

  • 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…(c) C & MOI 2012 P.M. : Quelle Approche ? 2
  • MANAGEMENT DE PROJET : – SCÈNES DE LA VIE« ORDINAIRE »(c) C & MOI 2012 P.M. : Quelle Approche ? 3
  • 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ésréalisées réalisées réalisées-Présentation du dossier de -Présentation des -Signature du PV de recettespé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
  • Management de projetLa vraie vie(c) C & MOI 2012 P.M. : Quelle Approche ? 5
  • Management de projetLe cauchemar(c) C & MOI 2012 P.M. : Quelle Approche ? 6
  • MANAGEMENT DE PROJET : – LES FONDAMENTAUX(c) C & MOI 2012 P.M. : Quelle Approche ? 7
  • Quelques définitionsProjets 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
  • Quelques définitionsOpé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
  • Quelques définitionsManagement de projet Le management de projet est l’application :  De connaissances,  De compétences,  D’outils,  et de techniquesaux activités du projet afin d’en respecter les exigences.(c) C & MOI 2012 P.M. : Quelle Approche ? 10
  • Quelques définitionsManagement 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
  • 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
  • MANAGEMENT DE PROJET FONDATION DU MOUVEMENT(c) C & MOI 2012 AGILE P.M. : Quelle Approche ? 13
  • Management de projetLa 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
  • 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 duL’interaction avec les personnes plutôt que les projet, à contrario des processus institutionnalisés etprocessus 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, enUn produit opérationnel plutôt qu’une permanence ou presque, une application opérationnelle. Lobjectifdocumentation 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 : OnLa collaboration avec le client plutôt que la peut ainsi répondre aux besoins du client, et non aux contraintesné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) doiventLa réactivité face au changement plutôt que le être préparés au changement; le planning doit être souple etsuivi dun plan. chacun doit se remettre en question en permanence. Planifier est important, mais adapter le contenu du planning lest tout autant. (c) C & MOI 2012 P.M. : Quelle Approche ? 15
  • Les concepts de l’agilité Les principes fondateurs (1/4) Principes TraductionsNotre première priorité est de Toute la création de valeur doit être justifié par la vue client. La seule vraie justification de valeursatisfaire le client en livrant tôt possible est démontrable uniquement lorsque le client se rend compte de lutilisation réelle deset régulièrement des logiciels produits livrés. La valeur identifiée lors de la livraison apporte naturellement au client la satisfactionutiles. 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 coursLe 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 valeurmê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 changementdéveloppement. Les processus qui peut être déstabilisant par certains aspects. A linverse le client doit accepter lui aussi que lesagiles exploitent le changement développeurs refassent une partie du produit pour plus de qualité, et donc de satisfaction client. Il fautcomme un avantage compétitif donc : que le client gère en permanence ses priorités, que les développeurs acceptent lespour le client. modifications des exigences et du code, que le chef de projet adapte la façon de travailler continuellement.Livrer fréquemment uneapplication fonctionnelle, toutes La livraison régulière et fréquente permet de se rendre compte du produit du point technique (lesles deux semaines à deux mois, développeurs) et fonctionnel (le client) et donc de se remettre en question. Des délais courtsavec une tendance pour la permettent également de réduire le risque derreurs sur ces deux aspects.période la plus courte. (c) C & MOI 2012 P.M. : Quelle Approche ? 16
  • Les concepts de l’agilité Les principes fondateurs (2/4) Principes Traductions La collaboration quotidienne permet daugmenter la productivité en abandonnant la création deLes gens du métier et les documents intermédiaires qui nont pas de valeur pour le produit final. Il faut donc : être souple dansdéveloppeurs doivent collaborer les relations contractuelles, être proche physiquement, s’assurer de la communauté et de laquotidiennement 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 cetteBâtissez le projet autour de motivation pousse à lexcellence, et donc à laugmentation de la productivité. Il sagit dun pré requispersonnes motivées. Donnez fort. Mais ce nest pas suffisant : tout ce qui peut gêner les membres de léquipe dans latteinte de leur objectif doit être levé. Enfin les membres de léquipe doivent bénéficier dune délégation forte deleur lenvironnement et le la part de leur hiérarchie organisationnelle et projet, pour décider rapidement sur des pointssoutien dont elles ont besoin, et fonctionnels (le client) ou techniques (les développeurs). Cela passe par la confiance de cettecroyez 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 lefficacité consiste au mieux à aller discuter avec la personne, au pire à lappeler autransmettre linformation est téléphone. Inutile dessayer le mail, et encore moin la rédaction dun document word.une conversation en face à face. (c) C & MOI 2012 P.M. : Quelle Approche ? 17
  • Les concepts de l’agilité Les principes fondateurs (3/4) Principes TraductionsUn logiciel fonctionnel est la Pour réaliser le reporting du projet, nul besoin de feuilles dactivité (timesheets). Le seul indicateurmeilleure unité de mesure de la davancement du projet est le nombre des fonctionnalités réalisées et/ou utilisées.progression du projet.Les processus agilespromeuvent un rythme de Les heures supplémentaires sont fortement déconseillées. Léquipe nest plus performante au bout dedéveloppement soutenable. huit heure de travail, quelle aille se reposer et se changer les idées : demain lui donnera sonCommanditaires, développeurs efficacité. Les pressions dues au deadline projet sont également limitées : si certaines fonctionnalitéset 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 rythmeindéfiniment. Lexcellence technique est également un prérequis fort. Au besoin, les ressources devront suivre desUne attention continue à formations. Cette excellence permet à léquipe de se focaliser sur la qualité (le travail bien fait) qui estlexcellence technique et à la indispensable pour la satisfaction du client. Aucun compromis de ce coté-ci nest possible. Lequalité de la conception développement agile requiert : un code propre, un code robuste (Testé). Il faut donc : refactoriseraméliore lagilité. 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
  • Les concepts de l’agilité Les principes fondateurs (4/4) Principes TraductionsLa simplicité - lart de Inutile de développer des lignes de code pour faire plaisir à un développeur : elles coûteront enmaximiser la quantité de travail maintenance et cest autant de raisons supplémentaires de défaut. Par ailleurs, plus un code està ne pas faire - est essentielle. simple, plus il est lisibleLes meilleures architectures, Nul besoin dexperts dans un projet agile. La meilleure solution ne viendra pas dune seule personne,spécifications et conceptions mais du collectif. Nul besoin non plus de dire comment les équipes doivent sorganiser, ellessont issues déquipes qui sauto- trouveront elles-mêmes lorganisation qui leur convient le mieux..organisent.À intervalle régulier, léquipe La vie nest pas un long fleuve tranquille ; il faut donc en permanence sadapter aux situationsréfléchit aux moyens de devenir nouvelles. Cette adaptation a pour objectif dêtre plus efficace et de se concentrer sur son propreplus efficace, puis accorde et métier qui est notre première source de motivation. Il est nécessaire de se questionner en permanenceajuste 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 quotidience sens. (c) C & MOI 2012 P.M. : Quelle Approche ? 19
  • 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 linvestissement 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 lincertitude et la gérons par itérations, anticipation et adaptation.  4. Nous libérons la créativité et linnovation 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 leffectivité 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
  • Management de projetLes méthodes «Agile»disponibles(c) C & MOI 2012 P.M. : Quelle Approche ? 21
  • Management de projet agileMise en situation(c) C & MOI 2012 P.M. : Quelle Approche ? 22
  • MANAGEMENT DE PROJET LE FRAMEWORK SCRUM(c) C & MOI 2012 P.M. : Quelle Approche ? 23
  • Management de projet agileLe framework de Scrum 7 TimeBoxes 3 Rôles 4 Artefacts(c) C & MOI 2012 P.M. : Quelle Approche ? 24
  • Management de projet agileLe framework de Scrum Les trois rôles :(c) C & MOI 2012 P.M. : Quelle Approche ? 25
  • Management de projet agileLe framework de Scrum Les 6 time-boxes :(c) C & MOI 2012 P.M. : Quelle Approche ? 26
  • Management de projet agileLe framework de Scrum Les 4 artefacts :(c) C & MOI 2012 P.M. : Quelle Approche ? 27
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsLe Product Owner est en charge de : (c) C & MOI 2012 P.M. : Quelle Approche ? 28
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactLe Scrum Master est en charge de : (c) C & MOI 2012 P.M. : Quelle Approche ? 29
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsL’équipe : • ne comporte pas de rôles prédéfinis pour ses membres • Il ny a pas non plus de notion de hiérarchie interne : • toutes les décisions sont prises ensemble • personne ne donne dordre à léquipe sur sa façon de procéder. • Léquipe sadresse 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts L’objectif doit être défini ! (c) C & MOI 2012 P.M. : Quelle Approche ? 32
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Préparation de l’action : (c) C & MOI 2012 P.M. : Quelle Approche ? 33
  • Management de projet La plus grande difficulté Aucune de mes propositionsComment se passe ton Parfait , tu as clairement n ’ est inscrite au backlog . identifié le Productexpé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
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsProduct Backlog : (c) C & MOI 2012 P.M. : Quelle Approche ? 35
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsToujours 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Product Backlog Iceberg :Epic : Affinage continu Taillée pour un Priorité Un « large » Sprint besoin fonctionnel CurentThème : Release Une collection d’items du Futur Backlog liés Releases fonctionnellement (c) C & MOI 2012 P.M. : Quelle Approche ? 41
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsValorisation 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
  • Management de projet agileLes valeurs de Scrum(c) C & MOI 2012 P.M. : Quelle Approche ? 43
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Product Backlog « hiérarchisé » : (c) C & MOI 2012 P.M. : Quelle Approche ? 45
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Planification des releases : (c) C & MOI 2012 P.M. : Quelle Approche ? 47
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefact Planification du sprint : (c) C & MOI 2012 P.M. : Quelle Approche ? 49
  • Management de projet agileScrum : Acteurs, time-boxes, Artefact Planification du sprint : (c) C & MOI 2012 P.M. : Quelle Approche ? 50
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Définition du « done » :• Code écrit (tous les «à faire» développés)• Code documenté et inscrit dans le gestionnaire deversions• Revu par un tiers et respectant les standards dedéveloppement• Assemblé sans erreur (Build)• Tests unitaires écrits et effectués• Déployé sur l’environnement d’intégration et tests denon-régression OK• Accepté par les utilisateurs et présenté lors de la sprintreview• Documentation produite ou mise à jour• Testé dans l’environnement de pré-production et testsde 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Daily StandUp : (c) C & MOI 2012 P.M. : Quelle Approche ? 54
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Le daily stand-up: (c) C & MOI 2012 P.M. : Quelle Approche ? 55
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsLe Dailly stand-up :Je pense que Qu ’ est - Juste un Son Dolby etle Stand - Up ce qui te pressentiment lunettes 3 D… on estdérive fait dire … prêt !quelque peu… ça ? (c) C & MOI 2012 P.M. : Quelle Approche ? 56
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsLe bon moment pour mettre à jour le ScrumBoard ! (c) C & MOI 2012 P.M. : Quelle Approche ? 57
  • Management de projet agileUn petit dessin vaut mieux…© Egilia 2011 Management de Projets : Lagilité 58
  • Management de projet agileScrum : 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
  • Management de projet agile Scrum : Acteurs, time-boxes, Artefacts Mettre à jour le Sprint Burndown Chart ! Statut Valeur EstimationReference US Effort RAF actualisé en H (A,E,S,T,R) Metier en HUSM09 T 25 5 10 10 10 10 10 10 10 8 7 6 0Catalogue US type 3 3 3 3 3 3 3 1 0USM25 T 50 3 6 6 6 5 5 2Vélocité0 sprint 6 0 0 0 0Cloner une US 1 1 1 0 0 Volume deffort produit 22USM41 T 100 3 4 4 4 4 4 4 Nb J/H 0 1 0 0 consommés 0 9Sortir une US dun Sprint 1 1 1 1 1 1 0 Vélocité ==> 2,44USM45 T 50 3 7 7 7 3 2 0 0 0 0 0 0Bloquer une US 1 1 1 0 0USM46 T 50 2 6 6 6 3 2 0 0 0 0 0 0Reprendre une US 1 1 1 0 0UST71 T 50 5 3 3 3 3 3 1 1 1 0 0 0Intégrer un mécanisme de version 3 3 3 3 3 1 1 1 0UST72 T 50 1 2 2 0 0 0 0 0 0 0 0 0Mise en place du jeux de donnée pour le demarrage de la 2 2 0release 2 (c) C & MOI 2012 P.M. : Quelle Approche ? 60
  • Management de projet agile Scrum : Acteurs, time-boxes, Artefacts Mettre à jour les « Project’s BurnUp Charts » !120 240 6000115 230 5750110 220 5500105 210 5250100 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) C & MOI 2012 P.M. : Quelle Approche ? 61
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsC’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
  • 200Management de projet agile190 1,67Scrum : Acteurs, time-boxes, Artefact180170 Planification du sprint N+1 :160 + 20 Points :150 A la vélocité140 la plus haute130120 + 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts La rétrospective de sprint : (c) C & MOI 2012 P.M. : Quelle Approche ? 64
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts La rétrospective de sprint : (c) C & MOI 2012 P.M. : Quelle Approche ? 65
  • Management de projet agileScrum : Acteurs, time-boxes, ArtefactsLa rétrospective de sprint :Avant… Pendant… Après… (c) C & MOI 2012 P.M. : Quelle Approche ? 66
  • Management de projet agileScrum : 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
  • Management de projet agileScrum : Acteurs, time-boxes, Artefacts Résultat du sprint : (c) C & MOI 2012 P.M. : Quelle Approche ? 68
  • Management de projetLimite du modèle Agile (Scrum) Combinaison normale : Combinaison envisageable :(c) C & MOI 2012 P.M. : Quelle Approche ? 69
  • Management de projetScrum : Acteurs, time-boxes, ArtefactsCombinaison envisageable :(c) C & MOI 2012 P.M. : Quelle Approche ? 70
  • Management de projetLimite du modèle Agile (Scrum)Combinaison à éviter :(c) C & MOI 2012 P.M. : Quelle Approche ? 71
  • Management de projetLimite du modèle Agile (Scrum)Combinaison à proscrire :(c) C & MOI 2012 P.M. : Quelle Approche ? 72
  • Management de projet agileScrum en 100 mots(c) C & MOI 2012 P.M. : Quelle Approche ? 73
  • Management de projet agileLes valeurs de Scrum(c) C & MOI 2012 P.M. : Quelle Approche ? 74
  • Management de projetRapide Comparaison (1/2) Thème « Traditionnelle » « Agile »Cycle de vie En cascade, en V, sans Itératif et incrémental rétroaction possiblePlanification 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 projetQualité 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
  • 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ésSuivi Mesure le da conformité aux Un seul indicateur d’avancement, leavancement 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 à faireGestion des Processus « distinct », rigoureux Processus intégré basé sur larisques de gestion des risques responsabilisation de chacun. Peut rapidement avoir des limitesMesure du Respect des engagements Satisfaction du client par livraison desuccè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
  • Management de projetLes points communs(c) C & MOI 2012 P.M. : Quelle Approche ? 77
  • Management de projet agileLes complémentarités(c) C & MOI 2012 P.M. : Quelle Approche ? 78
  • Management de projetLes antagonismes : Relation Clients/Fournisseurs (c) C & MOI 2012 P.M. : Quelle Approche ? 79
  • Management de projetLes 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
  • Management de projetLes antagonismes : Génération de valeur Livrer de la valeur à la fin (c) C & MOI 2012 P.M. : Quelle Approche ? 81
  • Management de projetLes antagonismes : La place des tests Agile Traditionnelle (c) C & MOI 2012 P.M. : Quelle Approche ? 82
  • Management de projet agileLes antagonismes : Manager de Projet « Agile » « Traditionnelle »(c) C & MOI 2012 P.M. : Quelle Approche ? 83
  • Management de projetLa 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
  • 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
  • Management de projetLa sagesse vient avec l’âge…(c) C & MOI 2012 P.M. : Quelle Approche ? 86
  • Management de projetPour aller plus loin…(c) C & MOI 2012 P.M. : Quelle Approche ? 87
  • Management de projetPour aller plus loin… http://guide.agilealliance.org/subway.html(c) C & MOI 2012 P.M. : Quelle Approche ? 88
  • Management de projetPour aller plus loin…(c) C & MOI 2012 P.M. : Quelle Approche ? 89
  • Management de projetPour aller plus loin… Regarde - Il utilise la version ptimisée de la roue de Deming !(c) C & MOI 2012 P.M. : Quelle Approche ? 90
  • Management de projet agileScrum = ma belle mère !(c) C & MOI 2012 P.M. : Quelle Approche ? 91
  • 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
  • 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