Traditionnelle et/ou Agile ?

Traditionnelle et/ou Agile ?
Management de Projet quelle approche : Traditionnelle et/ou Agile ? 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 ?

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… Grand merci aux Sponsors ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de Projet : – Scènes de la vie « ordinaire »
(c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Le projet « idéal »
CdPilot. du 14/06 CdPilot. du 28/06 CdPilot. du 05/07 Point sur les activités réalisées Présentation du dossier de spécification Planning de Réalisation Pot de lancement Présentation des développements Planning de Réception -Pot de fin d’étape Signature du PV de recette Pot de clôture (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet La vraie vie
CdPilot. du 14 21/06 CdPilot. du 28/06 01/07 CdPilot. du 05/07 Point sur les activités réalisées Présentation du dossier de spécification Planning de Réalisation Pot de lancement Présentation des développements Planning de Réception Pot d’étape Signature du PV de recette Pot de clôture (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Le cauchemar
CdPilot. du 14 21/06 CdPilot. du 28/06 01/07 CdPilot. du 05/07 Pot de lancement Point sur les activités réalisées Présentation du dossier de spécification Présentation des développements Signature du PV de recette Pot de clôture Annulé Annulé (c) C & MOI 2012 P.M. : Quelle Approche ?

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 (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

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 ?

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 ?

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. . 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de Projet Fondation du mouvement Agile

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 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Les concepts de l’agilité Les valeurs fondamentales
Traductions L’interaction avec les personnes plutôt que les processus et les outils. On privilégie les relations humaines, la communauté des développeurs et le rôle de “l’humain” dans le déroulement du projet, à contrario des processus institutionnalisés et déshumanisant, et des outils de développements qui ne laisse pas libre cours à la créativité. Un produit opérationnel plutôt qu’une documentation pléthorique. L’objectif principal des développeurs est de produire, en permanence ou presque, une application opérationnelle. L'objectif de réaliser une documentation technique et utilisateur considérées comme ayant peu de valeur ajouté pour le client est secondaire. La collaboration avec le client plutôt que la négociation de contrat. La collaboration Client/Développeurs prime sur le contrat : On peut ainsi répondre aux besoins du client, et non aux contraintes d’un contrat. Cela implique une confiance certaine entre la MOA et la MOE et une bonne maturité juridique. La réactivité face au changement plutôt que le suivi d'un plan. L’équipe projet (Développeurs et utilisateurs référents) doivent être préparés au changement; le planning doit être souple et chacun doit se remettre en question en permanence. Planifier est important, mais adapter le contenu du planning l'est tout autant. 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Les concepts de l’agilité Les principes fondateurs (1/4)
Traductions Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. Toute la création de valeur doit être justifié par la vue client. La seule vraie justification de valeur possible est démontrable uniquement lorsque le client se rend compte de l'utilisation réelle des produits livrés. La valeur identifiée lors de la livraison apporte naturellement au client la satisfaction requise par le projet. Le cercle vertueux livraison/satisfaction est en place et le projet peut continuer. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme un avantage compétitif pour le client. La notion de cahier des charges évolutifs est ici annoncé. Il permettra au client de préciser au cours du projet ses idées pas toujours très claires au début du projet, dans le but de créer la juste valeur 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 qui peut être déstabilisant par certains aspects. A l'inverse le client doit accepter lui aussi que les développeurs refassent une partie du produit pour plus de qualité, et donc de satisfaction client. Il faut donc : que le client gère en permanence ses priorités, que les développeurs acceptent les 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 les deux semaines à deux mois, avec une tendance pour la période la plus courte. La livraison régulière et fréquente permet de se rendre compte du produit du point technique (les développeurs) et fonctionnel (le client) et donc de se remettre en question. Des délais courts permettent également de réduire le risque d'erreurs sur ces deux aspects. (c) C & MOI 2012 P.M. : Quelle Approche ?

Traductions Les gens du métier et les développeurs doivent collaborer quotidiennement au projet. La collaboration quotidienne permet d'augmenter la productivité en abandonnant la création de documents intermédiaires qui n'ont pas de valeur pour le produit final. Il faut donc : être souple dans les relations contractuelles, être proche physiquement, s’assurer de la communauté et de la 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). Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail. Les membres de l'équipe (client et développeurs) doivent être motivé par leur métier, car cette motivation pousse à l'excellence, et donc à l'augmentation de la productivité. Il s'agit d'un pré requis 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 la part de leur hiérarchie organisationnelle et projet, pour décider rapidement sur des points fonctionnels (le client) ou techniques (les développeurs). Cela passe par la confiance de cette hiérarchie. Le facteur humain est la clé du succès. Les individus sont professionnels : disciplinés, 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 transmettre l'information est une conversation en face à face. Donc augmenter l'efficacité consiste au mieux à aller discuter avec la personne, au pire à l'appeler au téléphone. Inutile d'essayer le mail, et encore moin la rédaction d'un document word. (c) C & MOI 2012 P.M. : Quelle Approche ?

Traductions Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet. Pour réaliser le reporting du projet, nul besoin de feuilles d'activité (timesheets). Le seul indicateur d'avancement du projet est le nombre des fonctionnalités réalisées et/ou utilisées. Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment. Les heures supplémentaires sont fortement déconseillées. L'équipe n'est plus performante au bout de huit heure de travail, qu'elle aille se reposer et se changer les idées : demain lui donnera son efficacité. Les pressions dues au deadline projet sont également limitées : si certaines fonctionnalités 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. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. L'excellence technique est également un prérequis fort. Au besoin, les ressources devront suivre des formations. Cette excellence permet à l'équipe de se focaliser sur la qualité (le travail bien fait) qui est indispensable pour la satisfaction du client. Aucun compromis de ce coté-ci n'est possible. Le développement agile requiert : un code propre, un code robuste (Testé). Il faut donc : refactoriser 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 ?

Traductions La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle. Inutile de développer des lignes de code pour faire plaisir à un développeur : elles coûteront en maintenance et c'est autant de raisons supplémentaires de défaut. Par ailleurs, plus un code est simple, plus il est lisible Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto- organisent. Nul besoin d'experts dans un projet agile. La meilleure solution ne viendra pas d'une seule personne, mais du collectif. Nul besoin non plus de dire comment les équipes doivent s'organiser, elles trouveront elles-mêmes l'organisation qui leur convient le mieux.. À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens. La vie n'est pas un long fleuve tranquille ; il faut donc en permanence s'adapter aux situations nouvelles. Cette adaptation a pour objectif d'être plus efficace et de se concentrer sur son propre métier qui est notre première source de motivation. Il est nécessaire de se questionner en permanence 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

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. 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Les méthodes «Agile» disponibles
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 ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Mise en situation
Qui connait Scrum ? (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de Projet Le framework Scrum

Management de projet agile Le framework de Scrum
3 Rôles 7 TimeBoxes 4 Artefacts 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Les trois rôles : (c) C & MOI 2012 P.M. : Quelle Approche ?

Les 6 time-boxes : (c) C & MOI 2012 P.M. : Quelle Approche ?

Les 4 artefacts : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Scrum : Acteurs, time-boxes, Artefacts
Le Product Owner est en charge de : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Scrum : Acteurs, time-boxes, Artefact
Le Scrum Master est en charge de : (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

Preparation for action Vision Sprint review Release Planning Sprint retrospective Daily Stand-UP 1-4 weeks Sprint Sprint Planning (c) C & MOI 2012 P.M. : Quelle Approche ?

L’objectif doit être défini ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Préparation de l’action : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet La plus grande difficulté
Comment se passe ton expérience Scrum à la maison ? Pas exactement comme je l’avais prévu. Aucune de mes propositions n’est inscrite au backlog. Dans le prochain sprint je dois Repeindre la cuisine, garder 5 enfants, payer un spa à mon épouse et à ses 3 amies Parfait, tu as clairement identifié le Product Owner Dans ta maison… (c) C & MOI 2012 P.M. : Quelle Approche ?

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

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é> Afin de <Bénéfice> Facultatif (c) C & MOI 2012 P.M. : Quelle Approche ?

Exemple de User Stories : En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker Afin de pouvoir jouer En tant qu’utilisateur Je souhaite pouvoir créditer mon compte en ligne Afin de pouvoir parier En tant que joueur adictif Je souhaite un lien pointant sur un site d’assistance comportementale Afin de pouvoir contrôler mes pulsions En tant que « High Roller » (Baleine) Je souhaite une table ouverte aux paris > à 10K€ Afin de pouvoir jouer gros (c) C & MOI 2012 P.M. : Quelle Approche ?

Toujours formaliser les conditions d’acceptation : Recto Verso En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker Afin de pouvoir jouer Vérifier qu’un même utilisateur ne peux pas réserver plus d’un siège par tournoi Vérifier que l’utilisateur peut annuler sa réservation jusqu’à l’ouverture du tournoi Vérifier que l’utilisateur reçoit un de confirmation (c) C & MOI 2012 P.M. : Quelle Approche ?

Privilégier des histoires sans zone d’ombre : En tant qu’utilisateur Je souhaite pouvoir réserver une place pour le prochain tournoi de poker jusqu’à la dernière minute Afin de pouvoir jouer En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker Afin de pouvoir jouer En tant qu’utilisateur Je souhaite recevoir un de confirmation Afin d’être sûr d’être inscrit (c) C & MOI 2012 P.M. : Quelle Approche ?

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 échanges En tant que programmeur 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 ?

Product Backlog Iceberg : Taillée pour un Sprint Curent Release Futur Releases Priorité Affinage continu Epic : Un « large » besoin fonctionnel Thème : Une collection d’items du Backlog liés fonctionnellement (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

Management de projet agile Les valeurs de Scrum
Il faut toujours demander l’avis de celui qui est concerné ! (c) C & MOI 2012 P.M. : Quelle Approche ?

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 : (Bill WAKE en 2003 ) Indépendante des autres Négociable initialement, plutôt qu’un engagement ferme Valorisante ou ayant de la valeur en soit pour le métier Evaluable donc suffisamment précise pour être chiffrée Suffisamment petite pour être aisément planifiable Testable donc dotée de critères d’acceptation GWT : (Dan North 2006) Given (Etant donné) un contexte When (Lorsque) l’utilisateur fait une action Then (Alors) on doit constater tels résultats (c) C & MOI 2012 P.M. : Quelle Approche ?

Product Backlog « hiérarchisé » : (c) C & MOI 2012 P.M. : Quelle Approche ?

Un bon Backlog est : DEEP : Détaillé à un niveau suffisant (Detailled sufficienty) Estimé (Estimated) Evolutif (Emergent / In evolution) Priorisé (Prioritized) Physique Partagé Visible Entretenu … Se rappeler la vison donne la destination, le backlog le chemin pour s’y rendre (c) C & MOI 2012 P.M. : Quelle Approche ?

Planification des releases : 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

Planification du sprint : 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Planification du sprint : (c) C & MOI 2012 P.M. : Quelle Approche ?

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,…) Risques de retours - (c) C & MOI 2012 P.M. : Quelle Approche ?

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 Accepte ou refuse les livrables présentés par l’équipe Le Scrum Master : S’assure que les fondamentaux de Scrum sont en place Œuvre à lever les empêchements Met à jour les tableaux de bord de suivi Et dire que je n’aime pas les carottes… (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

Daily StandUp : 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Le daily stand-up: (c) C & MOI 2012 P.M. : Quelle Approche ?

Le Dailly stand-up : Je pense que le Stand-Up dérive quelque peu… Qu’est-ce qui te fait dire ça ? Juste un pressentiment… Son Dolby et lunettes 3D… on est prêt ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Le bon moment pour mettre à jour le ScrumBoard ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Un petit dessin vaut mieux…
© Egilia 2011 Management de Projets : L'agilité

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 ?

Mettre à jour le Sprint Burndown Chart ! Vélocité sprint 6 (c) C & MOI 2012 P.M. : Quelle Approche ?

Mettre à jour les « Project’s BurnUp Charts » ! Effort en valeur métier Vue : Nb Users Stories Vue : Nb Points "Complexité" Vue : Nb Valeur Métier (c) C & MOI 2012 P.M. : Quelle Approche ?

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… 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  (c) C & MOI 2012 P.M. : Quelle Approche ?

Planification du sprint N+1 : + 20 Points : A la vélocité la plus haute + 15 Points : A la vélocité Moyenne + 11 Points : A la vélocité la plus basse (c) C & MOI 2012 P.M. : Quelle Approche ?

La rétrospective de sprint : 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) (c) C & MOI 2012 P.M. : Quelle Approche ?

La rétrospective de sprint : (c) C & MOI 2012 P.M. : Quelle Approche ?

La rétrospective de sprint : Avant… Pendant… Après… (c) C & MOI 2012 P.M. : Quelle Approche ?

Preparation for action Vision Sprint review Release Planning Sprint retrospective Daily Stand-UP 1-4 weeks Sprint Sprint Planning (c) C & MOI 2012 P.M. : Quelle Approche ?

Résultat du sprint : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Limite du modèle Agile (Scrum)
Combinaison normale : Combinaison envisageable : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Scrum : Acteurs, time-boxes, Artefacts
Combinaison envisageable : (c) C & MOI 2012 P.M. : Quelle Approche ?

Combinaison à éviter : (c) C & MOI 2012 P.M. : Quelle Approche ?

Combinaison à proscrire : (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Scrum en 100 mots

Management de projet agile Les valeurs de Scrum
Engagement Franchise Convergence Respect Courage (c) C & MOI 2012 P.M. : Quelle Approche ?

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

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

Management de projet Les points communs
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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Les complémentarités
Pas de Projet TRaditionnelle Projet Risqué Projet Risqué Projet OK Agile 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 (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Les antagonismes : Relation Clients/Fournisseurs

Management de projet Les antagonismes : Variables d’ajustement
« Traditionnelle » « Agile » On détermine Fonctionnalités Cout Echéancier Plan Ou Valeur ? On évalue Echéancier Cout Fonctionnalités (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Les antagonismes : Génération de valeur
Livrer de la valeur à la fin 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. (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Les antagonismes : La place des tests
Agile Traditionnelle (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Les antagonismes : Manager de Projet
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 « Traditionnelle » (c) C & MOI 2012 P.M. : Quelle Approche ?

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 » ; 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) (c) C & MOI 2012 P.M. : Quelle Approche ?

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 ?

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 ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet Pour aller plus loin…
Avancez pas à pas ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Prenez le métro en marche !
Management de projet Pour aller plus loin… Prenez le métro en marche ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Osez les mélanges ! Management de projet Pour aller plus loin…

Il utilise la version ptimisée de la roue de Deming !
Management de projet Pour aller plus loin… Copiez intelligemment sur les autres ! Regarde - Il utilise la version ptimisée de la roue de Deming ! (c) C & MOI 2012 P.M. : Quelle Approche ?

Management de projet agile Scrum = ma belle mère !

Pour aller plus loin : Manifeste Agile : http://agilemanifesto.org/
Agile Alliance : Scrum Alliance : Réference & Blog : PMI & Agilité : Livres : Gestion de projet Agile Ed Eyrolles de Véronique Messager Rota Succeeding with Agile Ed Alddison Wesley de Mike Cohn Vidéo : Project-Manager. Terminer US10T1 UST10T2 et US10 Tourner le Chevalet (c) C & MOI 2012 P.M. : Quelle Approche ?

Merci Pour aller plus loin : …. Jean-Luc MAZE +33 6 31 86 29 99
Générateur de Visibilité Merci (c) C & MOI 2012 P.M. : Quelle Approche ?

Traditionnelle et/ou Agile ?

Présentations similaires

Présentation au sujet: "Traditionnelle et/ou Agile ?"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Traditionnelle et/ou Agile ?

Présentations similaires

Présentation au sujet: "Traditionnelle et/ou Agile ?"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back