Mthodes Agiles Nassur MHOUMADI Scrum Master DREAM IT

Méthodes Agiles

Nassur M’HOUMADI Scrum Master – DREAM IT TECHNOLOGY Email : m. nassur@almteam-consulting. com Tél : +33 7 82 71 82 35

TOUR DE TABLE HORAIRES : 9 H – 12 H 30 / 13 H 30 – 17 H MODE PROJET

“L’Expert en Réunion”

1. Rappel méthodes prédictives

Management Traditionnel TRAMDITIONNEL Opportunité (note cadrage) Besoin FAISABILITE Actions correctives Changements validés Rapports d’avancement Contrôle Initialisation Planification Clôture Etat d’avancement Demande changement Problèmes Plan de projet périmètre Charte projet ( opportunité, organigramme des tâches objectifs et bénéfices attendus, étude préliminaire des coûts…) livrables attendus délais budget qualité RH communication gestion du changementt Réalisation Livrable 6

Un projet Selon le PMI, un projet est une entreprise temporaire décidée dans le but de créer un produit, ou un service ou un résultat unique Entreprise : dimension économique du projet, englobant les ressources, le budget Temporaire : tout projet a un début et une fin déterminés, la fin marquant l’atteinte des objectifs ou le constat qu’ils ne pourront être atteints Produit, service ou résultat unique : un projet crée des livrables uniques, un produit ou un service application logicielle, de la doc… Le résultat de chaque projet est unique .

Atelier 1 « Secret du succès » 8

Instructions Atelier 1 « Secrets du succès d’un projet » Pensez à un projet qui a réussi (garder la réponse pour soi) ? 9 Maintenant que vous avez êtes ce projet en tête. Dites moi en 1 seul mot, ce qui a rendu ce succès possible ? Collecte des mots Qu’est ce qui fédère l’ensemble de ces mots ? Quelle est la tendance

Débriefing Atelier 1 « Secrets du succès » Tout est possible avec une attitude positive 10

Un projet La gestion de projet est la mise en œuvre de connaissances, de compétences, d’outils et de techniques appliqués au projet afin de respecter les exigences visà-vis du client (estimation des charges, planning, gestion des risques, accompagnement au changement, réunion…) Pour atteindre l’objectif, le chef du projet doit toutefois prendre en compte les 3 Contraintes (3 C) : contenu du projet, calendrier et le coût

Un peu d’histoire Années 60 (informatique militaire et scientifique) : des méthodes de gestion de projets inspirées du BTP et de l’industrie (Waterfall ) Années 70 (milieux d’affaires et banques…) : quelques évolutions Cycles en V années 80 : on s’améliore grâce aux tests 1985: MERISE : méthode conceptuel de données. 2001: Manifeste Agile : soin porté aux individus, au logiciel, à la collaboration avec le client et au changement plutôt que le suivi d’un plan

Méthodes agiles Vs Méthodes traditionelles Depuis 50 ans, les projets sont gérés avec une approche classique (cascade ou en V) basées sur des activités séquentielles : on recueille besoins, définit le produit, développe puis, teste avant de livrer Obligation de tout planifier et de tout prévoir (méthodes prédictives) Dans ce type de management on s’oppose systématiquement à tout changement

Modèle cascade TRAMDITIONNEL 14

Modèle cascade TRAMDITIONNEL Modèle en Cascade AVANTAGES o. Facile à utiliser et à comprendre o. Structure simple pour une équipe inexpérimentée o. Fonctionne bien quand la qualité est plus importante que la durée et le coût INCOVENIENTS 15 o. Face aux nouveaux besoins, refaire tout le procédé o. Une phase ne peut démarrer que si l ’étape précédente est terminée o. Le produit n’est visible qu’à la fin o. Les risques se décalent vers la fin. o. Très faible implication du client

Modèle en V 16

Modèle V TRAMDITIONNEL AVANTAGES o. Mets l’accent sur les tests et la validation. Accroît la qualité o. Chaque livrable doit être testable o. Facile à utiliser et planifier INCOVENIENTS o. Ne gère pas les activités parallèles o. Ne gère pas les changements de spécification o. Ne contient pas d’activités d’analyse de risques 17

Analyse réussite et échec projets 18 Les études menés par la Standish Group démontrent que la proportion de projets qui sont considérés comme des succès (respectant les 3 C) reste faible, soit 14%/

Pourquoi y a-t-il des projets qui échouent ? 19

Analyse réussite et échec projets Facteurs d’échecs 13% exigences incomplètes 13% manque d’informations utilisateurs 10% instabilité des exigences et spécifications 9% manque de ressources 8% manque de soutien du management 20 Facteurs de réussite 16% implications utilisateurs 14% soutien du management 13% énoncé clair des exigences 10% planning adéquat 8% demandes réalistes

Atelier 1 « NON/ OUI, ET…. . » 21

Instructions Atelier 2 « Non/ Oui, mais 22 A est un client qui souhaite se rendre à la foire du trône ce matin B est l’accompagnateur, et il a pour mission de conduire A à Belleville

Process pour aller à la Foire du Trône Café M’habiller Descendre les escaliers Prendre mon vélo Acheter mon journal à l’angle de la rue M’arrêter au feu Saluer mon coiffeur 23

Débriefing 24 Bénéfices de la collaboration Client/Prestataire

25 2. Mouvement agile

26

27

Akshay Mehra VLS Step 1 : VLS, installe une machine à laver robuste à l’arrière d’une pickup Step 2 : Feedback et redéfinition de la stratégie (présence physique et multiplication des points de présence) Step 3 : Kiosques ambulantes devant des supérettes locales. Succès commercial. Le VLS a aujourd’hui plus de 15 emplacements à Bangalore, Mumbai et Mysore. 28

Premiers pas Scrum - cadre léger 1996 – Article Scrum Ken Schwaber (processus empirique produits complexes) Le processus Scrum définit un cadre léger de travail : Sprint et leurs événements Une équipe avec trois rôles Un backlog concernant le travail à faire 29

Premiers pas Scrum – scrum en bref « Scrum aide les gens à améliorer leur façon availler » Les gens travaillent en équipe Le développement est rythmé par des itérations courtes – sprint Les fonctions du produit sont collectés dans le backlog Pendant un sprint, des points de synchronisation sont effectués tous les jours (Daily Scrum) A la fin de chaque sprint, l’équipe présente l’incrément qu’elle a ajouté au produit pendant le sprint. 30

Premiers pas Scrum – origine Scrum n’est pas un acronyme. Le mot Scrum vient du rugby Au rugby, une mêlée est sifflée lorsque une règle n’est pas respectée La mêlée permet de repartir sur des bases solides, avec une poussée synchronisée de tout le pack. L’effort est collectif La référence au Rugby, vient d’un article de 1986 « The New Product Development game » rédigé par des japonais qui aimaient le rugby [Takeuchi et Nonaka]. Cet article montrait la performance des sociétés japonaises en adoptant une approche de co-construction pour le développement de leurs produits 31

En quoi Scrum est différent APPROCHE EMPIRIQUE RYTHME. PRIORITE AUTO GESTION TRANSPARENCE. 32

Le Mouvement agile – Le Manifeste agile En 2001, le manifeste Agile Rédigé par 17 experts qui se dressent contre l'échec des cycles en cascade, Il propose 4 valeurs fondamentales, et 12 principes : La Réactivité face au changement plutôt que le suivi d'un plan, tout change, l’environnement, la technologie et les besoins les diagrammes se dégradent car des tâches s’ajoutent et d’autres ne sont plus nécessaires L’Interaction avec les personnes plutôt que les processus et les outils, construire l’équipe est plus important que construire l’environnement Un produit opérationnel plutôt qu’une documentation pléthorique, La collaboration avec le client plutôt que la négociation de contrat Les projets réussis impliquent le client de manière fréquente et régulière Le client doit avoir un contact direct avec l’équipe de développement 33

Le Mouvement agile – Le Manifeste agile Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles. Grâce au développement itératif, chaque livraison intermédiaire donne lieu à une validation par le client. Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client. Livrer fréquemment une application fonctionnelle, toutes les deux semaines à un mois, avec une préférence pour la période la plus courte Une version intermédiaire du produit final, visible et testable, satisfait 34 davantage le client qu’une documentation à valider. Il a, de ce fait, la preuve que le projet avance présenté.

Le Mouvement agile – Le Manifeste agile Le client et l’Equipe doivent collaborer quotidiennement au projet. 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 relations conflictuelles ne font pas partie de l’esprit agile ; on préférera des relations collaboratives et de partenariat basées sur la confiance et le consensus. Le client (ou son représentant) est accessible et disponible La méthode la plus efficace pour transmettre l'information est une conversation en face à face. 35

Le Mouvement agile – Le Manifeste agile Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet Les processus agiles promeuvent un rythme de développement soutenable. Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité. La simplicité garantit l’évolutivité du système. . 36

Le Mouvement agile – Pratiques agiles Des pratiques maintenant qualifiées d’agiles, existaient avant le Manifeste Agile et avant même les méthodes agiles : Cycles courts (itérations) – années 80 La mêlée quotidienne 37

Le Mouvement agile – L’agilité « L’agilité est la capacité d’une organisation à fournir tôt et souvent des services impactant ses utilisateurs, tout en s’adaptant à temps aux changements dans son environnement » Scrum est mise en pratique dans de très nombreuses organisations depuis 20 ans. Parti du développement, Scrum implique les gens de plusieurs métiers : Marketing et commerce • Numérique • Hardware 38

Qui utilise Scrum ?

Scrum en chiffres Scrum est de loin la plus populaire dans la famille des méthodes agiles. Presque ¾ des répondants disent utiliser Scrum ou des variantes dans leur projet Sur un panel d’agilistes : 28% travaillent dans une organisation agile datant plus de 3 ans 38% dans une organisation âgée de 1 à 3 ans 34% dans une organisation datant de moins 1 an. Une nette augmentation de la mise en place des méthodes agiles dans les organisation informatiques. • TYPES A titre expérimental : 15% Généralisé : 19% En cours de généralisation : 22% Sur un projet pilote stratégique avec mise en production : 25% Ces chiffres montrent une tendance à la généralisation de la mise en place des méthodes agiles. Ils démontrent également l’utilisation des méthodes agiles sur des projets stratégiques. • SPONSORS 55% des DSI 48% des Directions générales 42% du middle management 40

Scrum Bashing Compte tenu du succès de Scrum, on retrouve des articles critiques. Sur le terrain, on commence à voir des déçus qui ne retrouvent pas les belles promesses de Scrum : client enchanté, ROI, plus vite sur le marché, plaisir de travailler en équipe…. D’autres voient Scrum que de façon partielle : des utilisateurs brimés par leur DSI, pensent que Scrum peut accueillir et favoriser les changements. Ce qui les amène à penser qu’ils peuvent tout changer tout le temps et à n’importe quel moment des managers se disent qu’avec l’agilité, il leur sera plus facile de 41 demander à leur équipe de traiter une urgence par le biais d’heures supplémentaires…

Scrum n’est pas une méthode tout terrain Scrum n’est pas la solution pour tous les types de développement. Et ses échecs sont liés à la culture d’entreprise. Si vous développez des applications qui ne sont pas complexes. Scrum n’est pas le meilleur choix Si votre organisation est dans une culture du contrôle et que vous n’êtes pas en mesure de promouvoir le changement radical nécessaire, Scrum n’est pas pour vous Si vous travaillez dans l’urgence et que vous n’êtes pas en capacité de réduire les perturbations, vous n’arriverez pas à focaliser l’équipe sur un sprint sans qu’elle soit perturbée. Dans ce contexte d’urgence permanent, Scrum n’est pas recommandé 42

Scrum évolue Parfois les gens pensent « faire du scrum » , mais leur référence à Scrum n’est pas la bonne. Ce qui peut expliquer leur difficulté. Ils ont lu un manuel, ou suivi une formation, il y a quelques années…. SHU – HA - RI 43

BENEFICES PROPOSEES PAR L AGILITE 44

POURQUOI CELA MARCHE Priorité à ce qui a le plus de valeur, à ce qui est le plus important Démarche itérative, incrémentale et adaptative Des interactions et de la communication De la visibilité De la motivation et de la satisfaction dans les équipes Un produit opérationnel très tôt Une réactivité face au changement 45

MAIS CE N’EST PAS L’ABSENCE DE REGLE La discipline est indispensable Les processus sont indispensables L’ABSENCE DE DOCUMENTATION Il faut des spécifications MAGIQUE Cela ne fonctionne pas dans tous les contextes 46

LEAN, XP, KABAN, SCRUM Pratiques d’Ingénierie logicielle KANBAN Gestion des production des flux XP Framework de développement logiciel 47

TRADITIONELLES Vs AGILES 48

Atelier 3 : Agile Coin Game 49

Instructions Agile coin Games Livrer le maximum d ’argent au client : - Méthodes traditionnelles vs méthode agiles - Changement 50

TRADITIONELLES Vs AGILES 51

52

ATELIER 2 – Pire Projet Un Volontaire qui a vécu le pire projet informatique de sa vie ? 53

54 2. Framework Scrum

Framework Scrum Rôles Dev Team Product Owner (PO Scrum Master (SM) Cérémoniaux Sprint Planning Sprint Revue de Sprint Rétrospective de Sprint Artefact Product Backlog Sprint Backlog Burdown Chart 55

Atelier 3 : Les acteurs Chaque groupe doit discuter des qualités nécessaires pour assurer d’un des 3 rôles. 56

Acteurs de Scrum 57

Acteurs scrum – Importance des gens On privilégie la confiance au contrôle et on favorise l’auto gestion plutôt que le pouvoir du chef Scrum est associé à 5 valeurs : focus, ouverture, respect, courage et engagement. Le focus, c’est la volonté de se concentrer sur un sprint. Pendant le sprint, l’équipe a le focus sur l’objectif qu’elle a défini lors de la planification de sprint 58

Acteurs Scrum – Intérieur et extérieur Scrum présente une distinction nette entre ceux qui font et ceux pour qui c’est fait. Les gens qui font constituent l’équipe Scrum. Les autres sont appelés des parties prenantes (stakeholders) Parties prenantes (stakeholders). Le développement d’un produit est réalisé pour le développement d’une société. On y trouve des utilisateurs, des clients mais aussi des sponsors, des représentants des utilisateurs, des marketeurs, commerciaux, des managers…. Equipe. L’Equipe Scrum est composée des personnes qui contribuent à produire un résultat à chaque sprint. Il y a 3 rôles : Product Owner (PO), Scrum Master (SM) et le Developement Team (DT) 59

Development Team 60

Development Team – Equipe Taille. Pour que Scrum reste efficace, le nombre de personnes dans une équipe doit rester limité. Max 7 personnes. Auto – organisation. C’est l’équipe qui réalise le produit, en développant un nouvel incrément à chaque sprint. Elle est investie du pouvoir et de l’autorité pour le faire de la façon qu’elle estimera la plus efficace. Pluridisciplinarité. Scrum doit posséder en son sein toutes les compétences nécessaires pour finir le travail dans un sprint. Par exemple, pour le développement de logiciel, on regroupera des compétences de définition de produit, d’expérience utilisateur (UX), architecture de logiciel, de développement et de tests 61

Développement Team – Développeur Responsabilité. En tant que membre d’une équipe auto gérée, le dev est responsable de ce qu’il fait devant ses pairs. Ce qu’il fait est décidé en commun avec ses pairs. Sélection. Pour constituer l’équipe, on prend les personnes les plus qualifiés et qui acceptent le jeu collectif 62

Development Team – L’Expert Qui sont ils ? Un expert est une personne qui aide l’équipe à produire un résultat. Il dispose de compétences que l’équipe ne possède pas. Expert fonctionnel ou expert technique. 63

Product Owner 64

Product Owner – Responsabilités du PO Le PO agit à la fois sur la stratégie et la tactique. Il prend des décisions de niveau stratégique qui relève du comité de pilotage. Partager vision. Le PO doit avoir une bonne vision du produit. Il doit définir : la raison du produit, l’objectif de la prochaine release, les impacts attendus sur les acteurs, et liste des fonctionnalités. Affiner le produit. Le PO définit le contenu du produit. Il définit les fonctionnalités requises, collectées auprès des parties prenantes et mise dans une liste, product backlog Planifier. Le PO définit l’ordre dans lequel les parties du produit seront développées. Il alimente l’équipe avec les fonctionnalités à développer, en s’efforçant de maximiser la valeur. 65

Product Owner – Compétences souhaitées Bonne connaissance métier. Le business ou le cœur métier. Cela désigne un domaine de connaissances en relation avec les utilisateurs du produit. Une bonne connaissance du métier est fondamentale pour le PO. Maîtrise des techniques de définition du produit. Le PO doit maîtriser des techniques de collecte des besoins et de leur transformation en éléments du backlog Autorité. Aptitude à la négociation. Esprit ouvert au changement 66

Product Owner – Choisir le PO d’une équipe Une personne disponible Le travail nécessite une participation d’au moins 3 heures par jour à la disposition de son équipe. Plus la fin d’une release se rapproche, plus le temps que le PO devrait consacrer à son équipe augmente. Exemple : Pour un sprint de deux semaines, le PO : réunion de planification de sprint : environ deux heures Mêlées quotidiennes, 2 fois par semaine (minimum) Affinage : environ 3 heures Revue de sprint et rétrospective : 1 heure chacune En plus de participer aux réunions, le PO doit également : affiner seul le backlog, ajuster les priorités, répondre aux questions produit, conditions d’acceptation, 67 vérifier terminaison d’une user story

Product Owner – Choisir le PO d’une équipe Collaborer avec l’équipe. S’installer dans le même lieu que l’équipe pour répondre à ses questions. En collaborant avec l’équipe, le PO apprend à écouter. Il comprend mieux leurs préoccupations de délai et de qualité S’impliquer dans l’acceptation du fini. Le PO doit fournir les conditions qui permettent de s’assurer que ce qu’il demande est terminé. Lors des séances d’affinage, le PO formule à l’équipe le comportement qu’elle attend d’une fonctionnalité. Ensemble, ils identifient les conditions d’acceptation. 68

Scrum Master 69

Scrum master – Responsabilités du scrum master Le Scrum master (SM) est une personne dans l’équipe scrum qui se met à son service, pour faciliter la réalisation des travaux demandés par le PO, en appliquant Scrum Servir l’équipe. Une des missions du SM est de motiver l’équipe pour qu’elle s’auto organise. Il fait tout pour que l’équipe progresse. Il se produit toujours des événements imprévus pendant un développement. Certains sont susceptibles de ralentir ou de bloquer le travail de l’équipe. Ex : un développeur malade, un po injoignable, le serveur qui crash etc. . C’est au SM d’éliminer ces obstacles. Appliquer Scrum 70

Scrum master – Compétences souhaitées Bonne connaissance de Scrum. Aptitude à comprendre le fonctionnel et la technique. Une expérience dans le métier permet au SM de mieux communiquer avec le PO. Des bonnes compétences techniques lui permettent de mieux appréhender les problèmes rencontrés par son équipe. Facilité à communiquer. Des talents de communication sont nécessaires car le SM est amené à discuter fréquemment avec l’équipe et la direction. Capacité à guider. Il influence l’équipe. C’es un meneur, un guide qui sait créer les conditions pour que l’équipe soit motivée, pour qu’elle arrive au résultat. Mais il doit arriver à ses fins par la conviction sans imposer ses décisions. Talent de médiateur en cas de conflit entre les personnes Ténacité. Un SM n’abandonne pas à la première adversité. Il se montre opiniâtre, il poursuit sa quête jusqu’à l’élimination de ce qui freine l’équipe. 71 Etre au service de l’équipe. Le SM n’est pas un chef, ne commande pas. Il est au service de l’équipe. Il offre son support. Son humilité consiste à ne pas se mettre en avant.

72 Comment ces rôles travaillent-ils ensemble?

Rôles organisationnels Scrum Team Roles

Le Scrum. Master travaille avec le Product Owner 74

Le Scrum. Master travaille avec l’Equipe 75

Le Product Owner travaille avec le client 76

L’Equipe travaille avec l’utilisateur final 77

Le Scrum. Master travaille avec le Manager 78

Le Product Owner a besoin de connaître ce que le marché (l’utilisateur final) souhaite. 79

80 3. Cérémoniaux Scrum

Réunion de planification de Sprint 81

Réunion de planification de Sprint – Les activités C’est l’équipe qui planifie. Toute l’équipe participe à la planification Se mettre dans le contexte du sprint. Le PO rappel les objectifs du sprint. Il donne la liste des user stories 2 temps. La première partie permet de définir le périmètre et le but du sprint. Et, la seconde partie est consacrée à l’identification des tâches nécessaires et à leur estimation. Pour chaque user story, nous allons vérifier la capacité de l’équipe à la réaliser pendant le sprint Lancement du sprint. Ce sont les membres de l’équipe qui prennent eux-mêmes les tâches, en respectant l’ordre des stories. 82

Réunion de planification de Sprint – Le résultat de la planification de sprint Plan de sprint. Ce plan contient la liste des stories avec les leurs tâches, sous une forme visible et facilement accessible. Une tâche est décrite simplement : - Un nom et de la description du travail à effectuer. - La personne qui prend la tâche pour la réaliser 83 PBI : Product Backlog Item

Daily Scrum 84

Daily Scrum– Réunion quotidienne Daily scrum meeting en Angleterre ou Daily ou encore mêlée quotidienne en France. Pour réussir le sprint. La mêlée est un point de rencontre où tous les membres de l’équipe répondent à 3 questions simples. Elle sert à optimiser la probabilité que l’équipe atteigne l’objectif du sprint. La mêlée est de l’inspection et de l’adaptation au quotidien. La mêlée appartient à l’équipe. Toute l’équipe participe à la réunion, y compris le PO. Le SM s’assure que la réunion a lieu et que les règles sont respectées. Un cérémonial balisé : même lieu, même horaire, 15 min 85

Daily Scrum– La mêlée classique L’Equipe se réunit. Chacun s’exprime à tour de rôle sur les trois questions : ce qu’il a fait, ce qu’il va faire, et ce qu’il empêche d’avancer. Répondre à 3 questions : Qu’ai-je fait hier ? Il s’agit pour chaque membre de l’équipe, de parler des tâches sur lesquelles il a travaillé. Il indique si la tâche est encore en cours ou si elle est finie. Que vais-je faire aujourd’hui ? Il présente les tâches sur lesquelles, il prévoit de travailler. Pour chacune d’elles, il indique en quoi elle consiste et s’il pense la finir dans la journée. Quels sont les obstacles qui me freinent dans mon travail ? 86

Daily Scrum– La mêlée classique - Tableau 87

Revue de sprint 88

Revue Sprint – Les activités de la revue de sprint Voici un enchaînement des activités de la réunion : Avant la revue, l’équipe prépare tout ce qui est nécessaire pour que la démo se passe bien Au début de la réunion, le PO statue par rapport à l’objectif du sprint Ensuite, pour chaque story finie, l’équipe effectue une démo et collecte le feedback sollicité On profite de la présence des parties prenantes pour 89 évaluer l’impact obtenu avec le produit et prendre une décision sur son avenir

Rétrospective de sprint 90

Rétrospective de sprint Sprint –une pratique d’amélioration continue A partir des expériences tirées sur le sprint courant. L’équipe identifie ce qui marche bien pour elle, ce qui marche moins bien, et trouve collectivement ce qu’il faut modifier à sa façon de travailler. Inspection et adaptation. A la fin d’un sprint , la rétrospective est le moment où l’équipe se pose des questions sur la façon dont elle a travaillé. Cela constitue un des piliers de l’approche empirique. L’inspection conduisant à des adaptations, en fonction du ressenti sur le sprint qui se termine Un moment de réflexion collective. Une rétrospective permet de capitaliser sur les pratiques qui ont marché, d’éviter de refaire les mêmes erreurs, de partager les différents points de vue et de s’adapter aux nouvelles avancées 91

Revue Sprint – Les activités de la rétrospective de sprint Voici un enchaînement des activités de la réunion L’animateur, en général le SM, s’assure que l’environnement est propice à l’expression de tous. Il s’agit de s’assurer que tout le monde se sent en confiance et pourra s’exprimer librement pendant la rétro L ’équipe commence par collecter des informations sur le sprint passé. Avant de cher à améliorer les pratiques, il convient de collecter le ressenti des participants sur ce qui s’est passé pendant le sprint qui s’achève Identifier des ides d’amélioration. Une bonne pratique consiste à collecter les points d’amélioration individuellement, puis les 92 regrouper.

Rétrospective Sprint 93

94 4. Artefacts

Avant de penser à travailler en sprints, il faut que le Product Backlog soit “prêt”. C-à-d un juste niveau de granularité, Un Bon product 95 backlog est DEEP.

96

Atelier 4 - Schéma Scrum Les équipes vont représenter tous les éléments de SCRUM de manière visuelle 97

98

EXERCICE PROJET SCRUM – BALLES OBJECTIF : COMPRENDRE PRINCIPES DE SCRUM 99

REGLES SCRUM – BALLES Chacun est membre d’une équipe 1/2 Entre chaque participant, la balle doit voler ( « air-time » ) Chaque balle doit être touchée par chaque membre de l’équipe Vous ne pouvez passer la balle à votre voisin ou voisine de gauche ou de droite Chaque cycle de balle doit démarrer et se terminer par la même personne Une balle qui tombe par terre est perdue : elle doit recommencer Le cycle Il y aura 5 itérations Les seules règles sont celles écrites ci-dessus 100

PLANNING – BALLES 2/2 • Explication des règles • 2 min Création des équipes • 2 min Organisation de l’équipe • 1 min Estimation du temps • 2 min itération • 1 min debriefing de l’itération Après les 5 itérations : • 10 min de debriefing commun 101

DEBRIEF BALL POINT • PAS DE TEST • ON PEUT/ON NE PEUT PAS • ECOUTE < ======> ECOUTE • ON ESSAIE • 3 PILIERS : INSPECT/ADAPT/TRANSPARENCE • PDCA 102

LE BALL GAME 2/2 QUE NOUS APPREND CE JEU ? • Bâtir sur les idées de tous est plus motivant pour l’équipe. • Contraintes • Pour être le plus efficace : garder un rythme et éviter les interruptions. 103

“La difference entre cinema français et cinema belge”

105 5. Recueilir le besoin

Recueillir des besoins -Constat 2 chiffres illustrent les enjeux et la complexité des besoins : - le 1 er concerne le taux d’utilisation des fonctionnalités développées sur les projets. On constate que plus de 50% des fonctionnalités livrées sont jamais ou rarement utilisées - Le second indique, que plus de 56% des défauts constatés sont liés à la qualité des besoins recueillis en amont des projets (contre 27% liés à la conception et 7% seulement aux activités de développement) 106

Pourquoi est si difficile ? Une mauvaise communication. Dans un projet coexiste ceux qui achètent un produit et ceux qui le réalisent Ceux qui demandent le produit ne savent pas exactement ce qu’ils veulent Ils n’appréhendent pas nécessairement ce que les utilisateurs veulent précisément Ils ne parlent pas toujours le même langage. Les utilisateurs dialoguent difficilement avec ceux qui réalisent le produit. Ces derniers adoptent souvent un jargon technique 107

Pourquoi est si difficile ? Exemple : Dessiner une pizza avec parts 108

Pourquoi est si difficile ? L’illusoire exhaustivité. Dans une démarche traditionnelle on vise un recensement exhaustif des besoins, avant de commencer à élaborer et de construire la solution On demande au client de décrire la produit qu’il imagine, il doit conceptualiser et étayer avec beaucoup de détails le produit On arrive à une situation ou cette phase de recueil des besoins n’en finit jamais…. Et entame considérablement le crédit de jours disponible pour la réalisation Demander à un client de tout prévoir alors que des besoins sont diffus dans son esprit, entraînera inévitablement à des modifications en cours de projet. 109

Pourquoi est si difficile ? La défaillance du client. Dans certains projets, l’expression des besoins est réduite au stricte minimum. Le développeur doit exprimer lui-même les besoins des utilisateurs non disponible Quand ce n’est pas la disponibilité du client qui n’est en cause. C’est la capacité du client à rédiger un cahier charges qui fait défaut 110

Recueillir besoins - Constats Recueillir efficacement les besoins, c’est améliorer la qualité des échanges entre toutes les parties prenantes C’est également passer par la définition d’un langage commun et un partage des techniques et des outils facilitant cette coopération. Enfin, il faut adopter une démarche qui aide le client à faire émerger ses besoins progressivement et les hiérarchisés Comment le client, peut il être rassuré que ses besoins ont été compris ? Comment une équipe de réalisation peut elle certaine d’avoir compris le client ? Comment savoir si le produit développé correspond aux besoins réels. 111

Techniques de recueil des besoins L’analyse de l’existant. Il s’agit ici d’examiner les applications existantes pour en évaluer les forces et les faiblesses, et de mettre au point la stratégie d’évolution. L’observation du comportement de l’utilisateur en situation. Ce travail est efficace pour bien comprendre le comportement des utilisateurs sur leur poste de travail ou autour du poste de travail. En notant toutes les astuces qu’u utilisateur trouve pour compenser les manques d’une application. On prend les mesures de ces limites et des failles qu’il faudra combler. Le brainstorming (en amont). Idéal pour « défricher » les besoins encore flous et mal organisés des utilisateurs lors du démarrage d’un projet. Le benchmark. Ou l’analyse de la concurrence. C’est un des meilleurs moyens de découvrir ses propres besoins. Aussi, une analyse des outils du marché ouvre le champs des fonctionnalités possibles L’interview 112

Techniques de recueil des besoins Dans une approche agile, la scrum team privilégie le contact direct, en face à face avec le client ou les users qui expriment euxmêmes leurs besoins Le temps non consommé à la longue description des besoins est utilement consacré au dialogue, à la levée des ambiguïtés, à la rédaction des scénarios de tests, au développement et à ma validation client 113

Formaliser les besoins Une fois recueilli, il faut formaliser les besoins. Traditionnellement, Les besoins exprimés par les users sont formalisés dans un support documentaire (cdc ou autre) Le besoin est exprimé en langage métier , celui des utilisateurs, en terme d’usage ou de services attendus Ces besoins sont ensuite pris en charge par l’équipe de réalisation puis introduits dans un cycle de fabrication L’enjeu de la formalisation est double : - Eviter la déperdition d’information lors des franchissements d’étapes. - Comme dans le jeu du téléphone arabe, chaque passage de relais entre les différents intervenants risque de dénaturer le besoin exprimé. Pour des raisons d’interprétation possible, de subjectivité, 114 d’absence de clarification ou encore de non disponibilité du client, le résultat peut tout à fait être différent

Planifier avec la méthode agile Dans une approche agile, on distingue 4 niveaux de planification : établissement de la vision, planification d’une release, planification d’une itération, planification quotidienne 115

Travailler votre vision produit Construire le bon produit n’est pas facile. Il faut à a fois que le produit apporte de la valeur réelle à ses utilisateurs et qu’il soit d’une qualité irréprochable. La vision du produit est la réponse opérationnelle à la stratégie business de l’entreprise. Elle fait le pont entre cette stratégie et la roadmap du produit (release planning, story mapping, backlog). La vision produit est la réponse aux questions suivantes : quel problème essayons nous de résoudre ? Pour qui résolvons nous ce problème ? Quelle solution apportons nous ? Avoir une vision produit claire permet entre autres : - d’accorder les parties prenantes (marketing, finance, équipes techniques) - de garantir la motivation des équipes - d’anticiper les choix technologiques en fonction de cette vision Dans une équipe agile, la vision produit est encore plus importante que pour une équipe classique. Avant chaque sprint ou avant le développement de chaque fonctionnalité, les membres de l’équipe doivent se demander si leur travail répond bien au « Product statement » . Si ce n’est pas le cas, c’est que l’énergie est utilisée à bon escient 116

Travailler votre vision produit : Lean Canvas Qu’est-ce que c’est ? Trame de 9 cases Créé par Ash Maurya (adapté du Business Model Canvas) Objectifs pour une startup • • Synthétiser le Business Model en 1 slide Identifier les hypothèses les plus risquées à valider Pour l’entreprise • • Aligner les parties prenantes en début de projet Identifier les hypothèses pour créer une culture de l’expérimentation

Le Lean Canvas Problème Solution Indicateurs clés S tr u c tu r e d e c o û ts Risque produit client/marché Proposition Avantage de valeur déloyal unique Segment de clients Canaux S o u rce d e reven u s / g ai n s Risque

Atelier Lean Canvas – Projet Réseau Social Entreprise Préparez une affiche grand format du canvas ; Initialisez-le en collant vos propositions sur des notes repositionnables 119

Problème Pour qui ? Distinguer les types : utilisateur / payeur / influenceur Solution Indicateurs clés Affiner le ciblage Proposition de valeur unique Avantages concurrentiels Segments de clients • Canaux • • • Collaborateurs de l’entité Les experts Les managers (pas les autres filiales et les externes) 1 Early adopters : Collaborateurs de la DSI • S tr u c tu r e d e s c o û ts S o u rces d e reven u s / g ai n s (optionnel) Qui seraient les plus faciles à convaincre au début ? Segments client pour un Projet RSE (Réseau Social d’Entreprise). Les Early adopters sont les premières personnes intéressées par le projet. Et il faut les convaincre rapidement

Problème 2 1. 2. 3. 4. Obtenir de l’aide pertinente rapidement Etre au courant/ faire de la veille Trop de mails Experts : être reconnus Solution Indicateurs clés Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : aléatoire Proposition de valeur unique Avantage concurrentiels Pourquoi ? Les 3 principaux problèmes que vous comptez Segments de résoudre clients • Canaux Collaborateurs du groupe (incluant filiales) Distinguer les • Les experts problèmes d’une • (pas les cible spécifique externes) (optionnel) Early adopters : Alternatives • Collaborateurs actuelles et leurs de la DSI limites S o u rces d e reven u s / g ai n s S tr u c tu r e d e s c o û ts Dans cette case problème, identifiez les 3 principaux problèmes que vous voulez résoudre pour vos cibles. Identifiez ensuite les problèmes des alternatives actuelles. Des concurrents potentiels, ou des contournements manuels effectués par les utilisateurs. Ceci est une clé pour formuler des propositions de valeur

Proposition de valeur unique Problème 1. 2. 3. 4. 2 Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité Solution Proposition de valeur unique 3 Avantage cocurrentiel Des réponses à vos questions par vos collègues Indicateurs clés • Canaux Concept de haut niveau : « la machine à café virtuelle du groupe » S tr u c tu r e d e s c o û ts Segments de clients • • 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) La promesse de bénéfic du résultat final Pourrait être votre sloga accroche Early adopters : Collaborateurs de la DSI • S o u rces d e reven u s / g ai n s Se concentrer sur problème n° 1 La proposition de valeur est la promesse de bénéfices que vous faites à votre cible pour les intéresser. Faites abstraction des fonctionnalités. La proposition de valeur est la clé de voûte de votre projet. A partir de ce point, passez peu de temps sur les cases restantes, qui risquent d’être remises en cause au prochain changement de modèle.

Solution Problème 1. 2. 3. 4. 2 Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus Solution 4 1. Écrire un post 2. Lire 3. Être notifié Indicateurs clés Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité Proposition de valeur unique 3 Avantage concurrentiel Des réponses à vos questions par vos collègues. • Canaux Concept de haut niveau : « la machine à café à l’échelle du groupe » Segments de clients • • Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) 1 Early adopters : Collaborateurs de la DSI • Les 3 principales macrofonctionnalités ou services À remplir après les 3 autres cases S o u rces d e reven u s / g ai n s S tr u c tu r e d e s c o û ts Notez les 3 fonctionnalités ou services clés qui expliquent comment vous remplirez votre proposition de valeur

Sources de revenus / gains Problème 1. 2. 3. 4. 2 Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus Solution 4 1. Écrire un post 2. Lire 3. Être notifié Proposition de valeur unique 3 Des réponses à vos questions par vos collègues. Indicateurs clés Revenus quantitatifs si Bto. B Alternatives ou Bto. C (distinguer revenus par offre)actuelles : • Mailing lists : trop fermées Et/ou gains qualitatifs (image, • Mail 1 to 1 : satisfaction) limité Notamment pour Bto. E • Discussions de couloir : limité S tr u c tu r e d e s c o û ts Avantage concurrentiel • Canaux Concept de haut niveau : « la machine à café à l’échelle du groupe » Segments de clients • • 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • Sources de revenus / gains Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • • • 5

Canaux Problème 2 1. Obtenir de l’aide pertinente rapidement Canaux par lesquels 2. être au • on vend courant/ faire • on fait connaître le de la veille produit 3. Trop de mails • on récupère le feed-back 4. Experts : être reconnus Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité Solution 4 1. Écrire un post 2. Lire 3. Être notifié Proposition de valeur unique 3 Segments de clients Avantage concurrentiel Des réponses à vos questions par vos collègues. • • • Canaux Indicateurs clés Concept de haut niveau : « la machine à café à l’échelle du groupe » • • • Intranet Communautés de Pratiques Responsables d’équipes 6 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • Sources de revenus / gains S tr u c tu r e d e s c o û ts Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • • • 5 Listez les canaux de communication dans les 2 sens avec vos cibles : Pour acquérir des prospects (on et offline) ; Pour obtenir du feedback de vos utilisateurs (fonctionnalités du site, réseau de distribution, support client, sondages, …).

Indicateurs clés Problème 1. 2. 3. 4. 2 Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité Solution 4 1. Écrire un post 2. Lire 3. Être notifié Proposition de valeur unique 3 Des réponses à vos questions par vos collègues. Indicateurs clés Structure des coûts • • • Canaux À 12 mois : 2. 000 lecteurs actifs (dans la semaine) • 200 contributeurs actifs (dans le mois) • Enquête satisfaction > 3, 5/5 • Segments de clients Avantage concurrentiel 7 Concept de haut niveau : « la machine à café à l’échelle du groupe » • • • Intranet Communautés de Pratiques Responsables d’équipes 6 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • • Sur les activités utilisateurs ( « métri pirates » ) Sur le succès (résol du problème) • Sources de revenus/ gains Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • • • 5 Max 5 indicateurs: ceux q signalent l’adoption utilis

Avantage déloyal 1. • Proposition de valeur unique Solution Problème Obtenir de l’aide Atouts pertinente alternativesdifficilement rapidement copiables que les n’ont 2. être au pas courant/ faire de la veille 3. Trop de mails 4. Experts : être reconnus 2 Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité 1. Écrire un post 2. Lire 3. Être notifié 4 Avantages 3 Des réponses à vos questions par vos collègues. Indicateurs clés • • 8 Intégration avec Share. Point Application installée sur tous les postes Canaux À 12 mois : 2. 000 lecteurs actifs (dans la semaine) • 200 contributeurs actifs (dans le mois) • Enquête satisfaction > 3, 5/5 • 7 Concept de haut niveau : « la machine à café à l’échelle du groupe » • • • Intranet Communautés de Pratiques Responsables d’équipes 6 Segments de clients • • • 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • Sources de revenus / gains Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • • • 5 Structure des coûts Pensez aux atouts uniques de votre entreprise qui vous permettent de proposer une meilleure proposition de valeur que vos concurrents Pour une application interne, la « concurrence » sont en fait les outils actuels. L’avantage « concurrentiel » peut être le réseau des managers, le helpdesk, ou l’intégration dans des outils existants

Structure des coûts Problème 1. 2. 3. 4. 2 Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus Alternatives actuelles : Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité • Solution 4 1. Écrire un post 2. Lire 3. Être notifié 3 Proposition de valeur unique • Des réponses à vos questions par vos collègues. Indicateurs clés 7 À 12 mois : 2. 000 lecteurs actifs (dans la semaine) • 200 contributeurs actifs (dans le mois) • Enquête satisfaction > 3, 5/5 • 8 Avantage déloyal Intégration avec Share. Point Application installée sur tous les postes • Canaux Concept de haut niveau : « la machine à café à l’échelle du groupe » • • • 6 Intranet Communautés de Pratiques Responsables d’équipes • 1 Segments de clients Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • • • 5 Sources de revenus / gains Structure des coûts Build : x k€ (cadrage, conception, • développement, validation, déploiement) Run : x k€ / an (hébergement, maintenance, évolutions, support) Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • 9 • Assurez vous de la pertinence éco en évaluan un budget global sous la forme TCO (Total Cost of Ownership. • • Coûts fixes Coûts variables

Lean Canvas 129

Lean canvas 1. Écrire un post 2. Lire 3. Être notifié ? ? ? Alternatives actuelles : • Mailing lists : trop fermées • Mail 1 to 1 : limité • Discussions de couloir : limité À 12 mois : 2. 000 lecteurs actifs (dans la semaine) • 200 contributeurs actifs (dans le mois) • Enquête satisfaction > 3, 5/5 7 Concept de haut niveau : « la machine à café à l’échelle du groupe » ? ? Build : x k€ (cadrage, conception, • développement, validation, déploiement) Run : x k€ / an (hébergement, maintenance, évolutions, support) • ? ? ? Indicateurs clés • 3 Des réponses à vos questions par vos collègues. Structure des coûts 3. 4. ? ? Proposition de valeur unique 9 Avantage déloyal • Intégration avec Share. Point Application installée sur tous les postes • ? ? Canaux • • 8 Intranet Communautés de Pratiques Responsables d’équipes 6 • Segments de clients • • • 1 Collaborateurs du groupe (incluant filiales) Les experts (pas les externes) Early adopters : Collaborateurs de la DSI • ? ? ? Sources de revenus/ gains 2. Obtenir de l’aide pertinente rapidement être au courant/ faire de la veille Trop de mails Experts : être reconnus 4 • • 1. Solution 2 Capitaliser sur les bonnes pratiques Casser les silos entre départements Retenir les experts • Problème ? ? Ce ne sont que des hypothèses à valider ! 5

Construisez votre roadmap La roadmap est l’itinéraire entre la ou se trouve votre produit aujourd’hui et la destination définie dans votre vision Il propose une suite d’étapes intermédiaires et les dates prévisionnelles correspondant au franchissement de ces étapes La roadmap comporte principalement des objectifs chiffrés associés aux moyens à mettre e œuvre pour les atteindre 131

Construisez votre roadmap Pour construire votre roadmap, vous pouvez vous appuyez sur le story mapping. Le story mapping permet d’identifier et de structurer les fonctionnalités suivant 2 axes : un axe horizental découpant le parcours utilisateur et un axe vertical détaillant ces étapes en fonctionnalités 132

Construisez votre roadmap : story mapping Lors de l’atelier de story mapping, il est nécessaire que toutes les parties prenantes soient présentes : marketing, design, technique Il s’agit de bien prendre en compte les attentes et les contraintes de chacun. Et d’obtenir un consensus et un engagement sur votre roadmap 133

Construisez votre roadmap : story mapping Commencez par réintroduire la vision, les objectifs et les personas Puis, initiez la story map en inscrivant ce derniers sur le mur (sous forme de post it) Par exemple : pour développer les ventes d’un site en ligne, nous identifions 3 personas : l’acheteur économe, le fan de la marque, et l’employé. Chacun de ces acteurs utilise le produit d’une façon différente. L’enjeu consiste à dégager les étapes clés de leurs parcours utilisateur et dé réfléchir comment les optimiser pour influencer positivement l’usage du produit Enfin s’ensuite, une phase de discussion sur les fonctionnalités à mettre en place. A cet instant de l’éxercice, il ne s’agit pas de reteindre les idées, mais d’envisager toutes les possibilités 134

Construisez votre roadmap : story mapping Dans un deuxième temps, vous pouvez regrouper les fonctionnalités en MMFs (Minimum Marketable Features). Puis, ordonner ces dernières pour définir des releases. Ce sont des itérations du produit, apportant chacune nouvelle valeur supplémentaire à l’utilisateur et ayant une cohérence fonctionnelle 135

Construisez votre roadmap : story mapping 136

Construisez votre roadmap : story mapping Nous arrivons à la dernière étape, la création de la roadmap proprement dite à partir de la story map. En pratique, vous allez extraire cette roadmap de la story map, chaque MMF correspondant à une ou plusieurs releases. 137

Construisez votre roadmap : story mapping 138

Artistes et Spécificateurs 139

Artistes et spécificateurs – Régles du jeu 1. 5 personnes par équipe (2 spécifieurs et 3 artistes) 2. Les Spécifieurs et les Artistes sont séparés 3. Les Spécifieurs ECRIVENT les instructions aux Artistes (pas de dessin). Les spécifieurs NE PEUVENT PAS parler aux artistes 4. Les Artistes peuvent écrire des messages en retour. Les artistes NE PEUVENT PAS parler aux spécifieurs. 5. Les spécifieurs peuvent se parler entre eux (hors présence des artistes). 140

Structurer le Product Backlog – Outil pour l’équipe Une liste unique. Un backlog est simplement une liste ordonnée des choses à faire par l ’équipe. Cette dernière trouve dans le backlog ce qui est d’ordinaire dispersé dans plusieurs documents ou outils. C’est un outil de pilotage de projet. Une liste publique. Le PB est un outil élaboré par le PO, mais c’est l’outil de toute l’équipe. Ce dernier doit être visible des parties prenantes. Tout le monde y a accès pour favoriser la transparence, faciliter le feedback qui se concrétise par l’ajout de nouvelles idées Une liste ordonnée Changements permanents. Dans un dev agile, le chgt est possible, même encouragé. Le backlog n’est pas figé, il n’est jamais complet tant que le produit vit. Il est élaboré dans une forme initiale pendant le sprint 0, puis il évolue constamment (ajout, modif, suppression d’éléments). 141

Structurer le Product Backlog – Hiérarchie des éléments backlog 142

Structurer le Product Backlog – La User Story EN TANT QUE < ROLE> JE VEUX < FONCTIONNALITE> AFIN DE < RAISON/ Objectif Business> 143

Structurer le Product Backlog – La User Stry En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker Afin de pouvoir jouer 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 qu’utilisateur Je souhaite pouvoir créditer mon compte en ligne Afin de pouvoir parier En tant que « High Roller » (Baleine) Je souhaite une table ouverte aux paris > à 10 K€ Afin de pouvoir jouer gros 144

Structurer le Product Backlog – La User Story – conditions acceptations RECTO En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker Afin de pouvoir jouer VERSO En 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 145

EVITER LES ZONES D’OMBRE En tant qu’utilisateur Je souhaite réserver une place pour le prochain tournoi de poker 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 recevoir un email de confirmation Afin d’être sûr d’être inscrit 146

PROSCRIRE LA TECHNIQUE En tant que système de paiement Je souhaite que les échanges soient effectués en XML 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 Ce type d’informations est à réserver pour le Sprint Backlog 147

148 6. Affiner le Backlog

Affiner le Backlog Dans la pratique, de nombreuses équipes ne tiennent pas leur engagement à la fin du sprint L’origine du problème est lié à la méconnaissance de certaines stories embarquées dans le sprint La raison est que ces stories n’avaient pas été affinées L’affinage consiste à maintenir le backlog prêt pour augmenter les chances de succès des futurs sprints L’activité est une activité continue, dont le résultat est le reflet de l’émergence des stories tout au long du développement du produit 149

Définition de prêt L’objectif principal de l’affinage est d’avoir suffisamment de stories prêtes pour le prochain sprint Pour savoir si le backlog est prêt, nous regarderons si la liste des stories prêts est longue et bien ordonnée. Exemple : pour Almteam, la moyenne des stories finies dans un sprint est de 10. En fin de sprint, je dois livrer 10 stories prêtes et ordonnées pour le prochain sprint. Définition de prêt pour une story. C’est l’équipe qui décide si une story est prête. Pour prendre sa décision, elle s’appuiera sur une liste de vérifications qu’on appelle la définition de prêt. Il fau vérifier : - Décomposée : ce n’est pus une story épique - Débattue : elle a été discutée en équipe lors des séances - Définition de fini : pour qu’elle soit prête, c’est bien de savoir ce 150 qui permettra de savoir qu’elle est finie - Désirable : être sur que la story apportera de la valeur

L’affinage, une pratique d’équipe L’affinage du backlog est une activité faite par l’équipe pendant un sprint, dans le but de préparer les stories pour les sprints suivants. Avec qui ? Avec le PO qui est le principal affineur. Il affine souvent seul, mais il doit également solliciter l’équipe. Il est souhaitable que participe à cette activité. Dans quel cadre est il pratiqué? Une grande partie de ce travail est constituée de conversations entre le PO et l’équipe. Il faut donner un caractère permanent et officiel à l’affinage en le plaçant dans le cadre d’une réunion d’équipe : la réunion d’affinage du backlog (une fois par semaine par exemple) Avec quoi ? Un backlog structuré avec des bacs facilite le travail d’affinage : le bac de départ permet de bien visualiser la réussite de cet objectif. C’est facile de savoir s’il en contient assez. Les autres stories ont naturellement leur place dans le bac d’affinage. Les 151 idées et les demandes pour lesquels le PO n’a pas encore statué vont dans le bac à sable.

L’affinage, une pratique d’équipe Cette façon de structurer le backlog permet de mieux visualiser le Cyle de vie d’une story avant le sprint. Pratique inspirée de Kanban 152

Atelier Ecriture Backlog Alternative au taxi, Raid doit être une application qui donne un accès instantané à un large réseau de voitures avec chauffeurs (VTC) sur Paris et sa banlieue. Cible : Voyageurs d’affaires et citadins des grandes villes. Raid doit permettre la réservation des courses en quelques clics. Le passager et le chauffeur doivent pouvoir être géo localisés au moment d’une demande de course par le client. Le système de paiement doit être sécurisé (PCI DSS) afin de garantir des transactions sûres. Le client doit connaître à l’avance le prix et l’itinéraire de sa course. Possibilité de recevoir les factures par mail. Raid doit proposer un large éventail de fonctionnalités pour un usage personnel ou professionnel. . 153

154 7. Planifier

ATELIER PLANNING POKER 155

Exercice Valeur Métier Sanitaire Pièce Salon Cuisine Salon Sanitaire Cuisin e Chambre 2 Entrée FISPE Hall Véranda Chambre 1 Chambre 2 156

Exercice Valeur Effort Sanitaire Pièce Salon Cuisine Salon Sanitaire Cuisin e Chambre 2 Entrée FISPE Hall Véranda Chambre 1 Chambre 2 157

PRODUCT BACKLOG HIERARCHISE 158

7. Suivre et piloter le projet avec des indicateurs 159

Améliorer la visibilité avec des indicateurs Un indicateur permet de renforcer, ou pas la confiance dans la tenue d’un objectif de sprint ou release Pour produire des indicateurs, il faut collecter des mesures brutes. Avec Scrum les mesures les plus importantes portent sur des résultats concrets, collectés durant les daily scrum, le sprint, les releases. Elles permettent de construire des indicateurs utiles pour prendre des décisions, et pour analyser les effets au cours des mêlées, des revues et des rétrospectives 160

Burndown Chart 161

162

Suivi de l’humeur Un nouveau type de mesure encouragé par les méthodes agiles concerne la satisfaction des gens (Teammood. com : indicateur d’humour ) 163

Suivi de l’humeur Usage Uniquement destiné à l’équipe dans le suivi de son sprint. Peut être analysé lors de la rétrospective Quand l’utiliser ? Quand l’équipe se forme. On arrête quand l’équipe considère que ce n’est plus utile Collecte Tous les soirs en quittant le travail Unité A définir par l’équipe. Par ex, choix entre 5 valeurs : excellente journée, bonne journée, journée moyenne, journée difficile, mauvaise journée 164

Suivre la qualité - Tests Les moyens de prévenir la non qualité sont les tests, les revues ou les outils. Les différents types de tests 165

Suivre la qualité - Tests Les tests sont effectués à différentes niveaux de la chaîne de production Les tests unitaires sont effectués par chaque développeur sur la partir du code qu’il développe Les tests d’intégration sont réalisés par l’équipe sur l’ensemble du code pour valider que toutes les parties développées indépendamment fonctionnent bien ensemble Dans la démarche agile, tests unitaires et tests d’intégration sont mutualisés et l’on vérifie, à chaque modification de code source, que le résultat des modifications ne produit pas de régression dans l’application en cours de développement. On parle d’intégration continue Les tests de validation permettent de vérifier si toutes les exigences fonctionnelles ou non fonctionnelles sont satisfaites 166 Les tests de recette sont effectués par le client pour vérifier la conformité du produit livré

Quelle stratégie de test en mode agile L’approche traditionnelle en matière de stratégie de test la suivante : pour tester, il faut coder , afin de ne pas perdre du temps en tests inutiles, cette activité est planifiée en fin de projet Le pbm est que si l’on prend du retard dès le début du projet, la phase de test sera sacrifiée. Faute de temps et de budget, les tests son bâclés et le produit final mise en production est dans un état de qualité médiocre Dans la démarche agile, on intègre les tests dès le démarrage du projet. La détection et la correction tardives défauts coûtent beaucoup plus cher que lorsqu’ils sont détectés à leur source La recherche de défauts est initialisée dès les premiers développements et est permanente tout au long du projet. La correction des défauts est une activité parallèle aux développements qui s’effectue dans chaque itération. L’enjeu est de disposer d’une application opérationnelle, même en cours de réalisation 167

Scrum Quizz 168

169 Organisations

Management de projet Limite du modèle Agile (Scrum) 170 Combinaison normale : Combinaison envisageable : 170

Management de projet Limite du modèle Agile (Scrum) 171 Combinaison envisageable : 171

Management de projet Limite du modèle Agile (Scrum) 172 Combinaison à proscrire : 172

Brainstorming COMMENT ORGANISER L’AFFINAGE DU BACKLOG ? AVANTAGES ET INCONVENIENTS DES OUTILS SOFTWARE ET MANAGEMENT VISUEL ? LEQUEL CHOISR ? COMMENT FAIRE COHABITER SCRUM ET OFFSHORE? COMMENT GERER LES BUGS EN SCRUM ? 173

Les activités d’affinage On regarde le bac de départ. S’il ne contient pas assez d’éléments, l’approvisionnement en stories prêtes est primordial On observe ensuite le bac d’affinage pour identifier les stories épiques qu’il faut décomposer On examine le bac à sable en vue d’approvisionner en stories à affiner On estime les éléments approvisionnés ou décomposés qu’il contient 174

Les activités d’affinage q Approvisionner en stories prêtes La première chose à faire est d’évaluer le besoin en nouvelles stories prêtes Ensuite, l’équipe examine les stories les plus prioritaires du bac d'affinage. Un échange se fait avec le PO a pour objet de compléter la connaissance de l’équipe. La confirmation qu’une story est prête est obtenue quand l’équipe estime qu’elle peut entrer dans le sprint On continue ainsi de story en story jusqu’en avoir d’assez prêtes 175

Les activités d’affinage q Décomposer Une fois le bac d’affinage, débarrassé de stories prêtes, les stories épiques qu’il faut décomposer en priorité apparaissent. Ce sont elles qui sont susceptibles d’alimenter le prochain sprint ou les suivants. Les épiques sont décomposées en stories plus petites q Approvisionner en nouvelles stories Le bac d’affinage est alimenté à partir du bac à sable. Depuis le bac à sable, le PO et l’équipe discutent pour décider quoi faire des propositions. Les choix qui s’offrent : - passer la story dans le bac d’affinage dans le but de l’inclure dans la release courante - la supprimer si elle n’apporte pas de valeur q Estimer 176 Cette activité porte sur les stories ajoutées. Elles se pratiquent souvent avec le planning Poker

Scrum et Offshore Partager des ressources entre équipes par de fréquentes visites sur les autres sites. S’assurer que tout est en place pour bien accueillir les membres en visite. Utiliser la vidéoconférence pour les réunions de telle façon que tous les membres de l’équipe puissent se voir et mettre un visage sur un nom S’assurer que chaque site a un « évangéliste » agile, quelqu’un qui se consacre à la réussite de l’adoption des méthodes agiles sur le site S’assurer que les équipes ont des contacts quotidiens ; cela signifie que les membres d’une équipe communiquent entre eux, pas seulement avec le coach agile et pas uniquement par mail. Maintenir un wiki où tous les membres de l’équipe peuvent partager de l’information, pas seulement sur le projet mais aussi sur eux-mêmes 177

Scrum et Offshore Organiser des rétrospectives en interrogeant chaque membre de l’équipe par mail afin qu’il puisse apporter son feedback de façon asynchrone S’assurer que toutes les réponses sont recueillies avant la rétrospective afin que le coach agile puisse animer la réunion en présentant les résultats de l’enquête. 178

179 Outils Agiles

Outils agiles – Les Post it Quand on dispose d’un espace de travail avec un mur ou un tableau, le post it est l’outil le plus efficace pour communiquer Le Post it est recommandé pour le suivi d’un sprint Les Pos ti permettent également à faciliter le travail collectif et créatif lors des différents ateliers du backlog 180

Outils agiles – Les outils informatiques Les tableurs. Selon plusieurs sondages, l’outil informatique le plus utilisé dans les projets agiles, reste Excel. (Voir exemple) Les bugtrackers. Redmine. Les outils agiles. Jira 181

182 Transformer les Organisations

Transformer les organisations – Pourquoi se transformer ? Transformation agile. On parle de transformation agile, quand l’organisation prend conscience que, pour obtenir des bénéfices attendus, elle doit changer de structure, voire changer de culture. L’agilité est la capacité d’une organisation à fournir tôt et souvent des services ayant un véritable impact sur ses utilisateurs. La transformation agile correspond à la démarche que met en œuvre une organisation pour acquérir cette capacité. Origines de la transformation. C’est l’apparition d’obstacles d’organisation qui va déclencher la transformation. Obstacles d’organisation. Les obstacles identifiés par une équipe, qui la freinent ou le bloquent dans le développement du produit, sont variés, ils proviennent : pratiques de scrum, pratiques complémentaires à Scrum, résistance à l’organisation au changement, type de gouvernance. Pour les 2 premiers, l’équipe peut trouver des solutions. Et, pour le reste, voir le management. Voir SHU- HA - RI 183

Transformer les organisations – Pourquoi se transformer ? Un problème de culture. La culture d’entreprise est souvent négligée par le management. Privilégiant les objectifs financiers à court terme, les entreprises ne cherchent pas à devenir des collectifs organiques, cad des regroupements de personnes complémentaires, organisés autour d’un sentiment d’appartenance. La culture d’entreprise est un paramètre essentiel de la transformation de l’agilité. La transformation risque s’être longue et délicate pour une organisation plus dans la culture du contrôle, que une davantage focalisée sur la culture de de la compétence individuelle. 184

Transformer les organisations – Comment se transformer ? Avec qui ? Dans une transformation agile, il est préférable d’entraîner toutes les personnes qui sont sur le terrain, et de procéder par invitation pour les actions concrètes Définir l’objectif de la transformation. Qu’est ce qui pousse l’organisation à adopter à Scrum ? Quel est son objectif en introduisant l’agilité ? 185

FORCE ET FAIBLESSES DE Forces : SCRUM Scrum est axé sur la qualité du livrable. L’avancement est facilement mesurable et clairement visible. L’équipe est auto organisée, favorisant la motivation et éliminant la surcharge de travail car elle réalise en fonction de ses capacités. Le risque est détecté très rapidement. L’équipe peut prendre des décisions. Suppression de de la notion de hiérarchie pouvant être un frein à certaines personnes. • Faiblesses : Elle nécessite une forte implication du PO. Elle nécessite un coût de formation négligeable. Des relations difficiles peuvent apparaître lors de la présence de bugs. Le PO peut ne pas comprendre pourquoi vous l’ajouter au PB. Le télétravail n’est pas évident. • Opportunités : Scrum permet un gain de productivité par la notion de livraison fréquente. Ce gain permet notamment de fidéliser les clients et génère beaucoup de satisfaction. Scrum favorise la compétitivité. 186

187 QCM & TP