Gestion de projets agiles avec SCRUM PDF

Gestion de projets agiles 1ère Partie avec SCRUM Thierry Condamines  Sommaire 2 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe...

Gestion de projets agiles 1ère Partie avec SCRUM Thierry Condamines  Sommaire 2 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe SCRUM Un projet ne s’improvise pas ! 3 Des siècles de conduite de projets ! 4  Qu’est-ce qu’un projet 5 ISO 10006 : Processus unique qui consiste en un ensemble d’activités coordonnées et maîtrisées comportant des dates de début et de fin, entrepris dans le but d’atteindre un objectif conforme à des exigences spécifiques telles que des contraintes de délais, de coûts et de ressources. ISO 21500 : un ensemble unique de processus, constitués d’activités coordonnées et maîtrisées, ayant des dates de début et de fin et entreprises pour atteindre les objectifs du projet. La réalisation des objectifs du projet requiert la fourniture de livrables conformes à des exigences spécifiques. AFNOR : Un projet est une action spécifique, nouvelle, qui structure méthodiquement et progressivement une réalité à venir, pour laquelle on n'a pas encore d'équivalent.  Qu’est-ce qu’un projet 6 Les définitions Opération parlent d’ensemble d’activités ouProjet d’actions MAIS : neTâche routinière One shot (unique) pas confondre avec un ensemble d’opérations Peu complexe Innovant Exemple : Réalisation automatique Réalisation réfléchie Un grand constructeur automobile produit 2000 véhicules par jour, il Forte capitalisation d’expérience Faible capitalisation d’expérience s'agit d'opérations Le Pas de début, pas de fin Délimité dans le temps même constructeur envisage de fabriquer une voiture de « FormuleTemps1 »court on parlera de projet Temps long Equipes affectées (organigramme entreprise) Equipe constituée pour la durée du projet Projet : caractère d’unicité, originalité, incertitudes sur le produit Budget récurrent Budget d’investissement final Risque faible Risque fort Opérations : actions répétitives Qu’est-ce qu’un projet 7 Exemple : un constructeur automobile décide de produire un nouveau modèle Projet de conception du modèle. Incertitude forte au début : formes, motorisation, versions non définies. Fabrication en série = phase d’opérations (incertitude moindre car toutes les caractéristiques du véhicules sont définies) = fin du projet  Qu’est-ce qu’un projet 8 PMBOK : Un projet est une initiative temporaire entreprise dans le but de créer un produit, un service ou un résultat unique. Un produit, un service ou un résultat unique : Un projet est entrepris afin d’atteindre un objectif grâce à la réalisation de livrables. Livrable : produit, service ou résultat unique, produit pour achever un processus, une phase ou un projet.  Qu’est-ce qu’un projet 9 PMBOK : Un projet est une initiative temporaire entreprise dans le but de créer un produit, un service ou un résultat unique. Une initiative temporaire = une date de début et de fin déterminées (pas forcément de courte durée). Le projet prend fin lorsque : Objectifs atteints Objectifs non réalisables Ressources financières épuisées ou plus disponibles pour le projet Le besoin à disparu (client, changement de stratégie, …) RH ou ressources matérielles plus disponibles Raisons juridiques Les livrables perdurent après la fin du projet Aqueduc de Maintenon Caractéristiques d’un projet 10 Unicité : un projet de construction est unique Durée limitée Objectifs clairement définis (satisfaction d’un besoin) : nouveau véhicule familial 5 places gamme moyenne, 7cv, 150 km/h max, bi-énergie, moins de 5 l aux 100 km. Novation : une autoroute n’est pas nouvelle en soi mais le projet est novateur par les particularités des terrains traversés Incertitude : dans la réalisation d’un tunnel il est difficile de prévoir la dureté des matériaux traversés = incertitude sur la vitesse d’avancement Caractéristiques d’un projet 11 Contraintes de délai, de qualité, de coût, de ressources : travail d’équipes multi-compétences Irréversibilité forte : Exercice : Quelles contraintes ? 12 Une entreprise a décidé de réaliser un nouveau produit et de le présenter au prochain grand salon professionnel dans un an. L'entreprise compte sur la nouveauté de ce produit qui va la démarquer de la concurrence en prenant de l'avance et lui permettre ainsi de dynamiser ses ventes. Une enveloppe budgétaire de 600.000 € a été prévue pour le projet. L'investissement consenti dans ce nouveau produit par l'entreprise représente pour l'entreprise une très forte charge et ne peut être dépassé. Toutefois afin de pouvoir rivaliser avec les produits concurrents déjà existants qui sont de qualité irréprochable, le nouveau produit devra être produit avec des normes qualité très strictes. classer par ordre d'importance les contraintes suivantes : contraintes de qualité, contrainte de coût, contrainte de délai.  Solution : Quelles contraintes ? 13 1. Contrainte de délai Se positionner sur le marché et présenter le nouveau produit au salon. Lancement commercial des produits au moment du salon. Si le nouveau produit n'est pas présenté au salon le projet est gravement en danger car le produit ne pourra être présenté que l'année d'après. Il sera peut être dépassé à ce moment là par un produit concurrent. 2. Contrainte de coût Compte tenu de la capacité financière de l'entreprise, il est important de respecter ce budget afin de pouvoir rentabiliser rapidement cet investissement. 3. Contrainte de qualité L'objectif de l'entreprise est de se différencier des concurrents par les performances du produit. Il faut donc concevoir et industrialiser une gamme de produits ayant au moins des performances identiques à celles obtenues pour le prototype. Parties prenantes un projet 14 Maître d’ouvrage – MOA (porteur du projet, commanditaire, donneur d’ordre) : Personne physique ou morale pour le compte de qui l'objet du projet est réalisé, responsable de la définition des objectifs du projet et de la décision d'investir dans le projet. Client externe Entreprise elle-même qui décide de réaliser le projet pour son compte Maître d’œuvre (Réalisateur, chef de projet) : Personne physique ou morale qui, pour sa compétence, est chargée par le maître d’ouvrage de la réalisation du projet. Le chef de projet choisit l'équipe projet et l'anime, organise le projet et le conduit; il est responsable du résultat du projet devant le maître d'ouvrage. Parties prenantes un projet 15 Remarque : En France : Maître d’ouvrage – MOA Maître d’œuvre – MOE En anglais pas de distinction entre ouvrage ou œuvre : Work MOA : Owner (propriétaire) MOE : Project Manager (Chef de projet) Parties prenantes un projet 16 Equipe projet : choisie par le chef de projet comprend les personnes prenant une part active dans la réalisation du projet, les responsables de lots de travaux ou de tâches Limitée en taille Responsables hiérarchiques : Lorsque les membres de l'équipe sont «mis à disposition» pour la durée du projet, ils dépendent de leurs responsables hiérarchiques. Parties prenantes un projet 17 Partenaires : Le chef de projet peut avoir besoin de partenaires en plus des membres de son équipe projet qui peuvent être des fournisseurs, des sous-traitants ou des laboratoires de recherches ou tout tout autre partenaire utile au projet. Le comité de pilotage : Il intervient pour des décisions «politiques» importantes que le chef de projet ne peut prendre seul. Il est choisi par le maître d'ouvrage. Exercice : Parties prenantes un projet 18 Dans un projet de conception d'un nouveau produit pharmaceutique : qui est le maître d'ouvrage , le maître d'œuvre, les partenaires. Service R&D Hôpitaux Sécurité Sociale produits nouveaux Entreprise productrice Médecins de médicaments Maître d’ouvrage Maître d’oeuvre Partenaires  Typologie des projets 19 Taille du projet Equipe projet Budget moyen Durée moyenne Exemple Grand projet > 100 G-euros années Tunnel sous la manche personnes Projet moyen De 10 à 100 M-euros mois Lancement d’un pers. nouveau modèle Petit projet De 1 à 10 pers. K-euros semaines Informatisation d’une procédure de gestion Réussites et échecs de projets 20 Taux d’échec élevé (entre 20 et 30%) Augmente avec la taille/complexité du projet Gros projet : 10 fois plus de chances d’échouer 2 fois plus d’être en retard, dépasser le budget, mal répondre à la demande The Standish Group (2013) Réussites et échecs de projets 21 Principales causes d’échec : Incompétence du chef de Objectifs de projet vagues projet Mauvaise estimation des coûts Changement de priorités au Mauvaise estimation du temps sein de l'organisation par tâche Dépendance aux ressources Changement dans les objectifs du projet Absence de méthode de conduite de projet Risques ou opportunités non Procrastination (tendance à définis toujours remettre au Mauvaise communication lendemain)  Sommaire 22 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe SCRUM Bien définir le projet 23 Pour coller aux attentes … 24 Je voudrais un portrait d’une jeune femme énigmatique aux cheveux longs devant un paysage Je vois parfaitement ce que vous voulez  Définir précisément 25 Des objectifs mesurables : que souhaite-t-on ? Je souhaite que d’ici Je souhaite réduire 3 mois, le déficit de le déficit de mon l’entreprise passe entreprise de 3% à 2% Le périmètre du projet Les contraintes de coût, de délais, de qualité Des outils pour vous aider 26 Le « Proof of Concept » : mini étude ou maquettage Le modèle de Kano : identifier ce qu’il faut réellement faire pour satisfaire le client, sans superflus Le modèle QQOQCPC (Quoi, Qui, Où, Quand, Comment, Pourquoi, Combien) ou en anglais 5Ws and 1H (Who, What, Where, When, Why and How) Précision et clarté 27  Sommaire 28 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe SCRUM Cycle de vie d’un projet et méthodes agiles 29 Cycle de vie d’un projet 30 Un objectif ambitieux ? Un produit final complexe CYCLE DE VIE DU PROJET Des objectifs Un ensemble de intermédiaires produits plus simples simples à atteindre à réaliser Cycle de vie = série de phases que le projet traverse depuis sont initialisation jusqu’à sa clôture Cycle de vie d’un projet 31 Ensemble de phases (séquentielles, itératives ou parallèles) Phase = ensemble d’activités du projet liées logiquement et qui aboutit à la réalisation d’un ou plusieurs livrables Chaque phase se termine par une évaluation (revue de phase, phase gate, passage de contrôle) : livrables et performance du projet La performance du projet est comparée au plan de conduite du projet : changements, arrêt ou poursuite. Suivi : comités de pilotage et de projet. Cycle de vie d’un projet 32 Plusieurs grand modèles : dépend des métiers Cycle en V (années 80) : Cycle de vie d’un projet 33 Modèle en spirale (Boehm 88) :  Cycle générique séquentiel (en cascade) 34 PHASE 3 PHASE 1 PLANIFICATIO PHASE 5 INITIALISATIO PHASE 2 PHASE 4 N CLOTUR N CADRAGE REALISATION Coûts/délais/ E DEFINITION risques GO / No GO Cycle générique séquentiel (en cascade) 35 EFFORT PHASE 1 PHASE 3 PHASE 5 INITIALISATIO PHASE 2 PHASE 4 PLANIFICATIO CLOTUR N CADRAGE N REALISATION E Cycle générique séquentiel (en cascade) 36 Risque Coût des changements PHASE 1 PHASE 3 PHASE 5 INITIALISATIO PHASE 2 PHASE 4 PLANIFICATIO CLOTUR N CADRAGE N REALISATION E Cycle générique séquentiel (en cascade) 37 Avantage : Permet de connaître dès le départ l’ensemble des fonctionnalités du produit : rassurant pour le chef de projet Simple à appréhender : rassurant pour le client/MOA et les décideurs Inconvénient : Pouvez-vous définir aujourd’hui et en détail la maison de vos rêves (nombre de pièces, carrelage exact, couleur des peintures, …. ) ? Incertitude = Produit mal pensé par rapport aux besoins réels Dépassement des délais et coûts Cycle générique itératif (agile) 38 Le manifeste Agile (2001) 39 Les 4 valeurs : Favoriser les individus et leurs interactions plutôt que la mise en place de processus et outils Favoriser la collaboration avec le client plutôt que la négociation contractuelle Faire en sorte d’obtenir un logiciel opérationnel plutôt que d’investir dans une documentation exhaustive Être réactif face au changement plutôt que de respecter un plan Le manifeste Agile (2001) 40 12 principes sous-jacents: Accorder une haute priorité à la satisfaction du client à travers des livraisons rapprochées et continues Accepter le changement de besoins même tard dans le développement Livrer fréquemment un logiciel qui marche à échéances régulières de 2 semaines à 2 mois avec une préférence pour les plus petites périodes Faire travailler ensemble quotidiennement les utilisateurs et les développeurs Construire les projets autour de personnes motivées. Leur donner l’environnement et le support dont elles ont besoin et leur faire confiance. Privilégier la communication face à face, moyen le plus efficace pour transmettre de l’information aux équipes de développement. … Le manifeste Agile (2001) 41 12 principes sous-jacents (suite): Un logiciel opérationnel est la principale mesure d’avancement. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. Méthode Agile : méthode idéale ? 42 Intérêts : Favorise la productivité (plutôt que le respect de règles rigides) Permet de mieux appréhender les besoins du client (échanges continus) Difficultés : Forte implication du client Conceptuellement plus complexe à appréhender (client, prestataires, décideurs) Besoin de collaborateurs très performants à la fois sur le plan fonctionnel que technique Besoins d’outils de contrôle de qualité et de non régression Méthode très difficile à mettre en oeuvre sur des gros projets Contractualisation difficile : Vous en avez pour votre argent … Cycle de vie d’un projet 43 Outil de productivité du chef de projet Décrit l’organisation générale, donne la logique de son déroulement Premier niveau de planification Capitaliser les meilleurs pratiques en gestion de projet Outil de mise sous contrôle Facilite la surveillance par la direction (alignement des projets sur un même schéma) Outil de structuration des relations avec le client Validation de productions intermédiaires, du produit final Validé par la direction, des chefs de projets seniors et le client Cycle de vie d’un projet : quel modèle ? 44 Nature et caractéristiques du projet ? Fort niveau d’incertitude, représentation finale du projet impossible au début Modèle itératif (agile) Forte répétabilité, besoin d’une vision d’ensemble et systémique de la solution ou de son intégration dans un ensemble plus vaste (peut-on concevoir une pièce d’une maison sans un plan d’ensemble ?) Modèle séquentiel (en cascade) Besoin d’un temps d’émergence de la solution par essais/erreurs jusqu’à une première maquette/prototype Modèle itératif (agile) puis séquentiel Principales méthodes agiles 45 Lean Management (« gestion fine »): La source des autres méthodes (Toyota puis formalisée aux USA en 1990) S’adapter à la mondialisation : produire juste, production à la demande SCRUM : la plus utilisée Kanban (« étiquette ») très proche de Scrum Issue de la production automobile (Toyota) Et beaucoup d’autres : eXtreme Programming, …  Sommaire 46 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe SCRUM La méthode SCRUM 47  Effet tunnel en gestion de projet classique 48 e besoin : une jeune femme énigmatique, aux cheveux longs, devant un paysage … Ce qu’attend le client … Ce qui est livré 6 mois plus tard SCRUM : une équipe 49 3 rôles : Le Product Owner : possède la vision du produit la retranscrit dans des « histoires » (User Stories). L’ensemble des User Stories donnent une liste de besoins formant le Product Backlog. La notion Le Scrum Master : de Chef de Projet n’existe plus « facilitateur » qui a pour mission ! les obstacles pour l’équipe de lever S’assure que la méthode est correctement appliquée Ce n’est pas un chef de projet !!! L’équipe de développement Fonctions hétérogènes Développe les User Stories contenues dans le Product Backlog afin de fournir un livrable de qualité Pas de différences entre les membres de l’équipe qui est auto-organisée SCRUM : 3 piliers 50 TRANSPARENCE: Toute personne concernée par le projet doit comprendre aisément et rapidement l’état du projet Mise en place d’un langage commun Importance capitale ! INSPECTION L’équipe doit fréquemment inspecter ce qu’elle produit et l’état d’avancement par rapport aux objectifs (sans altérer la productivité !) Eviter l’effet tunnel Inspections quotidiennes lors des Mêlées ADAPTATION Si des écarts sont constatés, un ajustement est effectué pour minimiser les impacts SCRUM : des évènements (cérémoniaux) 51 Dans un projet Scrum, tout a une durée limitée Plus de réunions interminables (gestion de projet traditionnelle) On définit une durée maximale de chaque événement … … ET ON LA RESPECTE !!! Meilleur gestion du temps et gain de productivité Evènements Scrum : Sprint Réunion de planification de Sprint Mêlée quotidienne Revue de Sprint Rétrospective de Sprint SCRUM : les évènements (cérémoniaux) 52 SPRINT Durée maximale d’un mois (souvent 1 ou 2 semaines) Période de temps donnant un incrément de produit à l’état terminé, utilisable et potentiellement livrable Réunion de planification d’un Sprint Préparation du contenu d’un Sprint Réunion qui ne dépasse pas 8 heures pour un Sprint d’un mois, 4 heures pour un Sprint de 2 semaines Ensemble de l’équipe Définition des objectifs du Sprint et des tâches à effectuer SCRUM : les évènements (cérémoniaux) 53 La Mêlée quotidienne Quotidien, durée 15 minutes Equipe de développement Point de synchronisation sur les tâches en cours Planification des prochaines 24 H Appelée aussi : Daily Scrum, « Point Debout », Stand Up Meeting, Scrum Meeting Revue de Sprint 4 heures maxi pour un Sprint d’un mois, 2 heures maxi pour un Sprint de 2 semaines Ensemble des membres de l’équipe Scrum Démonstration du livrable fourni en fin de Sprint Présenter le travail réalisé Point précis sur l’avancement du projet Préciser les éventuels ajustements (trajectoire ou contenu) à effectuer dans les Sprints suivants SCRUM : les évènements (cérémoniaux) 54 La rétrospective de SPRINT 3 heures maxi pour un Sprint d’un mois Analyser comment s’est passé le travail de l’équipe Scrum (introspection) Envisager un plan d’amélioration Moment où l’ensemble de l’équipe peut s’exprimer sur son ressenti, sur les points à améliorer ou à maintenir SCRUM : les artefacts 55 BACKLOG PRODUIT Expression des besoins du Product Owner (User Stories) Ordonné selon des critères définis par le PO On traite les Stories dans l’ordre défini BACKLOG de Sprint Liste des User Stories issues du Backlog Produit devant être traitées durant le Sprint Chaque User Story est découpée en tâches devant être réalisées par l’équipe de développement (suffisamment finement pour pouvoir suivre la progression de l’équipe lors des mêlées quotidiennes) Aspect visuel : souvent un tableau (Scrum Board) où sont ajoutées des cartes (post-it) correspondant aux User Stories et tâches associées. Une colonne par état des tâches (« à faire », « en cours », « terminée », … à adapter à vos usages) Objectif : à la fin du Sprint toutes les étiquettes sont dans la colonne de droite SCRUM : les artefacts 56 Suivi de la progression Transparence et communication de l’information aux membres de l’équipe Scrum Suivi synthétique de la progression de l’équipe vers l’objectif de Sprint en complément du Scrum Board Utilisation de graphiques (Burn Down Charts) Abscisse : durée du Sprint Ordonnée : Somme des évaluations de l’effort de chaque User Story contenue dans le Sprint Courbe linéaire permettant d’apprécier le reste à faire idéal jour par jour du début à la fin du Sprint. Après chaque Scrum Meeting, l’équipe reporte le reste à faire sur le graphique et le compare avec le reste à faire idéal pour en déduire les actions à entreprendre. SCRUM : Cycle L’équipe Scrum de lors se réunit viede la réunion de 57 planification de Sprint afin d’établir la liste des User Stories qui seront traitées pendant le sprint (Sprint Backlog). Elles sont découpées en tâches par l’équipe de développement. Le PO Le PO rédige prioriseles lesUser User Stories et ordonne les placele Product dans Le Sprint leBacklog peut Product en L’équipe se réunit commencer conséquence Backlog pour une Aquotidiennement l’issue du Sprint Le cycle on a un pour se termine la par itération de 2 à 4 produit lapotentiellement Mêlée quotidienne de rétrospective semaines livrable qui fait Sprint l’objet d’une démonstration lors de la Et le cycle se répète revue de Sprint … SCRUM : Cycle de vie 58 Approche itérative et incrémentale Incrémentale : A l’issue d’un sprint 1 incrément (morceau) du produit est réalisé Itérative : Le feedback obtenu sur cet incrément permet d’ajuster dans un prochain sprint En résumé : un sprint est une itération qui produit un nouvel incrément et/ou enrichit l’incrément du sprint précédent Release : série de sprint Si possible de durée fixe : 3 à 4 mois pour des sprint de 2 ou 3 semaines (4 à 6 sprints par release). Souvent (mais pas toujours !) livraison d’une « version » du produit SCRUM : Cycle de vie 59 Sprint Sprint Sprint Fin 0 … RELEASE Sprint 0 Mettre en place l’équipe et l’environnement de travail, préparer un backlog initial, première planification de release, si 1ère release définir le produit Différent des autres sprints (durée, tâches, on ne produit pas un incrément, …) Durée qui dépend du contexte Fin de release Si le produit est conforme aux attentes à la fin du dernier sprint : pas d’étape finale Si besoin de finaliser la livraison de la « version »  SCRUM : Coût, délai et périmètre 60 Modèle séquentiel Modèle agile Gestion de projet classique Fixé Périmètre Coût Délais Seul le périmètre est fixé (besoin du client). Le temps de réalisation et les coûts sont inconnus. Cela influe sur le coût global du projet car rien n’indique que les coûts et délais seront respectés (effet tunnel). SCRUM C’est le contraire ! Les couts et délais sont respectés mais le périmètre peut varier … Parfois difficile à faire comprendre au management (et au client) : « Il se peut que je n’aie pas tout ce que j’ai demandé ? » En faitCoût Variable les fonctionnalités à Délais forte valeur métier seront développées en premier mais il Périmètre se peut que celles ayant une faible valeur soient écartées. C’est au Product Owner de s’assurer que le Backlog Produit soit correctement priorisé (qualité non négociable !) Durée d’un Sprint constante + nb de personnes de l’équipe connu = couts et délais assurés  Sommaire 61 Un projet ne s’improvise pas ! Bien définir un projet Cycle de vie d’un projet et méthodes agiles La méthode SCRUM L’équipe SCRUM L’équipe SCRUM 62  Le Scrum Master 63 Il n’est pas : un manager, un leader technique, un chef de projet Il est : un leader au service des tous les membres de l’équipe. Il lève les points de blocage, Il est le garant du respect des principes agiles tout en étant à l’interface entre les acteurs extérieurs et l’équipe Scrum.  Le Scrum Master : ses responsabilités 64 Animer les réunions : Planification de Sprint (phase de préparation) Scrum Meeting ou Daily Meeting (réunion quotidienne) Revue de Sprint (en fin de Sprint) Rétrospective de Sprint (en fin de Sprint) Au service du Product Owner, il l’aide (conseille): Dans la phase d’écriture des User Stories (comment bien les écrire) Dans la constitution du Backlog Produit (pour maximiser la valeur du produit) Dans l’adoption de techniques efficaces pour gérer le Backlog Produit (priorisation, raffinement, …) Au service de l’équipe de développement, il l’aide à mettre en œuvre les principes de Scrum  Le Scrum Master : ses responsabilités 65 Il n’a aucune autorité pour prendre les décisions à la place de l’équipe Il a toute autorité pour prendre les décisions concernant l’application de la méthode Scrum.  Le Scrum Master : ses responsabilités 66 Lever les obstacles pour que l’équipe se concentre sur les objectifs Blocages identifiés lors des points quotidiens ou rétrospectives Coaching pour une équipe autonome et responsable Veiller à un environnement de travail de bonne qualité (matériel fonctionnel, pas d’open space bruyant, …) Optimiser les interactions Entre les acteurs du projet Veiller à ce que les interactions avec l’extérieur ne soient pas néfastes (rôle protecteur) : directeur demandant de mettre la pression sur l’équipe … Leader du changement : impulser le changement dans l’entreprise (passage aux méthodes agiles)  Le Scrum Master : Personnalité et compétences 67 Connaître Scrum Etre un leader Etre communicant Etre un médiateur (conflits) Jouer la transparence (pilier de Scrum) même si le projet ne va pas dans le droit chemin  Le Product Owner 68 Seule personne de l’équipe à qui est imputable le résultat du produit auprès des parties prenantes Responsable du résultat !  Le Product Owner : ses responsabilités 69 Agit à la fois sur la stratégie (date de livraison, fonctionnalité à réaliser en priorité, …) et la tactique (choix métiers) Mais ne décide pas tout seul : en accord avec l’équipe ! Ses activités : Créer et partager la vision du produit (se construit au début et se consolide ensuite) pendant des ateliers et jeux Pourquoi crée-t-on ce produit ? Objectif de la prochaine release Impacts attendus sur les acteurs Liste des fonctionnalités essentielles qui y contribuent Affiner le produit : définit le contenu du produit, les fonctionnalités requises collectées auprès des parties prenantes et mises dans une liste (Backlog). Passe une grande partie de son temps à affiner le Backlog.  Le Product Owner : ses responsabilités 70 Ses activités : Planifier Ordre dans lequel les parties du produit seront développées Alimente l’équipe avec les fonctionnalités à développer S’efforce de maximiser la valeur du produit et du travail de l’équipe (et non pas tirer un max de bénéfice du travail de l’équipe !) Prends en compte les retours et questions de l’équipe Définit le plan de Release : Décide des dates de livraison et du périmètre des Releases  Le Product Owner : ses responsabilités 71 Implication dans le processus Scrum Participe à l’ensemble des cérémoniaux auxquels sa présence est requise Fait partie de l’équipe, partage les mêmes objectifs : ne pas tomber dans un schéma client/fournisseur Disponible à chaque instant du projet (3/5 à 4/5 du temps tout au long du projet) Accepter ou non le résultat d’un Sprint Lors de la revue de Sprint, accepte ou non la livraison effectuée par l’équipe Se base sur des indicateurs qui lui sont propres mais partagés avec toute l’équipe : résultats de tests de validation sur les User Stories du Sprint, …  Le Product Owner : ses responsabilités 72 Pouvoirs Pouvoir de construire le Backlog Produit et ainsi de définir le contenu des Sprints et Releases Pouvoir de définir les priorités et fonctionnalités candidates à chaque Sprint Limites Lorsqu’un Sprint est commencé, la modification des priorités et fonctionnalités n’est plus possible Attention : il arrive que les membres de l’équipe de réalisation soient sollicités par des interlocuteurs externes pour réaliser des tâches non prévues dans le Sprint : Il faut résister même si cela vient du chef de service ! S’appuyer sur le Scrum Master qui expliquera comment intéragir avec l’équipe et mettre en relation avec le PO  Le Product Owner : Qui choisir ? 73 Bonne connaissance du métier et maîtrise des techniques de définition de produit Soit il est l’un des utilisateurs (projet interne) Soit membre d’une équipe marketing ou produit (projet pour client externe) Mais peut être épaulé par des experts métier Une personne disponible Au moins 3 h par jour à disposition d’une équipe de 5 personnes Plus la fin de la release approche plus le temps consacré augmente Pour un sprint de 2 semaines, environ 8h soit 10% des son temps : Réunion de planification de sprint : 2 h Mêlées quotidiennes : 1h pour 4 séances Affinage : 3 h Revue de sprint : 1h Rétrospective : 1h Implication au jour le jour : affine seul le backlog, ajuste les priorités, réponds aux questions sur le produit, définit les conditions d’acceptation, vérifie la terminaison d’une story Une seule personne pour parler d’une seule voix ! Pas de comité ni de « PO Proxy »  L’équipe de réalisation 74 Transformer les User Stories en fonctionnalités d’un produit Auto-organisée et multi-disciplinaire Pas de rôles autre que « membre de l’équipe » Taille de l’équipe : pas de règle générale mais : En dessous de 3 : peu d’intéractions et Scrum limitée Au dessus de 9 : communication et coordination complexes – créer plusieurs équipes Tout le monde sur le même site et, mieux, dans la même salle