Les Business Analysts face à l'agilité

Notes de l'éditeur

• #2: Comment introduire le sujet : présentation des 2 octo, difficile en fin de journée après ces 2 journée, on va essayer de vous accompagenr jusqu’à la birere: La session : le Business analyst face à l’agilité L’agilité passé l’effet de mode est de plus en plus présent dasn nos organisation Ne se limite plus à quelques developpeurs anarchistes dans un coin du sous-seul  sétend coté prod, coté business Indépendamment du changement de méthodologie ou de process, les méthodes agiles on bien entendu un impact sur certains rôles Parmi ces rôles, au cœur du changement figure le business analyste : Quid de cet acteur dans un process agile Ce que nous vous proposons aujourd’hui c’est de partager notre vision de ce rôle dans l’agile issus de nos convictions et de nos retours terrain
• #3: Pour incarner cette présentation, nous vous proposons de suivre les évolutions de jérome Toute ressemblance avec une personne de l’assemblée est totalement assumée
• #4: Le projet va se dérouler en agile, et du coup jérome se pose la question de son rôle au sein de ce processus, sachant que son titre n’est mentionné nulle part… Indépendamment de son titre, jérome n’identifie plus les phases de projet caractéristiques d’un cycle en V ou il devrait intervenir On lui parle d’itératif, d’incrémentale et de user story dans le processus de collecte des besoins utilisateurs
• #5: Et quand il voit le modele d’une user story, s’il percoit la simplicité du modèle, ils ne voient pas où sont les détails des spécifications Bref il a du mal à se projeter, comment cadrer la demande, comment alimenter ce fameux backlog, quel est mon role une fois que le backlog est alimenter
• #6: Et bien nous allons essayer de répondre à ces questions au travers des deux parties qui compose notre présentation. La premiere concernant la phase amont, la définition du produit qui va nous permettre d’alimenter ce fameux backlog et la deuxième concerne plus la phase projet et son implication dans celle –ci. 4 minutes
• #7: Et bien nous allons essayer de répondre à ces questions au travers des deux parties qui compose notre présentation. La premiere concernant la phase amont, la définition du produit qui va nous permettre d’alimenter ce fameux backlog et la deuxième concerne plus la phase projet et son implication dans celle –ci. 4 minutes
• #8: Dans les processus classiques comme cascade ou cycle en V : spécifications -> conception -> codage On spécifie, on donne à l’IT pour chiffrage, GO/NOGO, développement, … Décrire exhaustivement ce que l’on veut
• #9: Le cadrage, d'habitude, c'est ça : exhaustif (cahier de specs) -> Trop de détails En amont du projet, on pense que c’est la seule chance que l’on aura de faire part de nos besoins, nous demandons tout ce à quoi nous pouvons penser. On est quasi certain que l’on aura pas tout, alors demandons en beaucoup, en espérant avoir quelque chose de « viable ». C’est un peu extrême, mais c’est comme ça dans une majorité de projets.
• #10: Standish Group, environ 50000 projets étudiés. Une des métriques produites est le taux d’utilisation des fonctionnalités réalisées (projets internes). Cadrage standard caca 64% de fonctionnalités que l’on peut considérer comme du déchet (Jamais et rarement). Seulement 20% des fonctionnalités sont essentielles (Toujours et Souvent)
• #11: Cadrage rapide, pas de tunnel
• #12: On peut dériver cet élément en … Le changement est un levier => C’est précisément un des objectifs recherché par les méthodes agiles, comme Scrum Product Backlog en constante évolution (nvlles stories, reprio.) Itérations/Sprints de 2 semaines : on peut changer d’avis toutes les 2 semaines Il faut que les Responsables Produit et les Business Analysts intègrent cela dans leur quotidien. Mais il leur faut de nouveaux outils.
• #13: -> accord puis démarrage ou pas
• #14: En 2 à 6 semaines, on devrait pouvoir cadrer n’importe quel projet, sinon découpage La vision produit, le scope et la roadmap : définis différemment, au travers d’ateliers spécifiques Equipe fixe
• #15: Réunir tout le monde au départ -> difficile + réflexion entre ateliers Timeboxing Balayage du périmètre Les BA peuvent accompagner le Product Owner dans la définition du produit Participer à l’élaboration de la vision produit, pour se l’approprier et la porter durant le développement Animer les ateliers de Story Mapping et faire vivre la Story Map Alimenter et affiner le backlog
• #17: Elevator statement => vendre son produit lors d’un voyage en ascenseur Product Box => aller un cran plus loin que la vision produit, comment attirer le chaland avec un objet en tête de gondole Comment vendriez-vous votre produit s’il était packagé dans une boîte, présent dans les rayonnages d’un supermarché (atelier créatif et collaboratif)
• #18: Balayer le périmètre en largeur Disposer d’une vue globale mais simple Eviter les éléments trop détaillés Créer la roadmap prévisionnelle En définissant des incréments de produit Former des incréments cohérents, maximisant la valeur livrée aux utilisateurs du produit
• #20: Qu’avez-vous fait ce matin avant de venir ici ? - Manger - Doucher - Raser - Brosser les dents - Habiller - …
• #22: Il n’est pas obligatoire d’avoir des éléments de chaque activité. Par contre, chaque release doit contribuer à la vision produit et délivrer de la valeur aux utilisateurs. Introduire Incrément de Produit
• #23: Jerôme apporte de la cohérence fonctionnelle aux releases En tant que PMS, je veux fournir la structure et les données de portefeuille En tant que PMS, je veux fournir la liste des portefeuilles sous gestion En tant que PMS, je veux obtenir la liste des ratings
• #25: François va vous présenter les outils pour affiner les besoins et préparer les sprints de l’équipe de développement
• #26:  ma partie 17 minutes : 10 slides Bien sur la responsailité de jérome se s’arrete pas là,
• #27: Revenons sur le processus avec le premier Sprint arrive! Il faut choisir les élements des éléments du backlog à développer durant ce Sprint. Mais il est ou le backlog Est-ce que ce que l’on a en sortie de notre cadrage est suffisant pour démarrer sereinement le premier Sprint?  j’en doute Travail préparatoire au sprint : travailler sur le backlog
• #28: Durant la phase de cadrage, Jérôme a donc contribué à valider le périmètre du produit dans le cadre de la storymap La storymap a permis de faire ressortir des Epix, des thèmes voir des usesr story un peu macro avec une priorisation à la release > itération Prendre un plus petite morceau de la release pour l’iteration Apporter du détail, de la précision aux besoins exprimés durant le cadrage, Pour qu’il n’y ait plus d’ambiguité au moment où l’équipe va réaliser cette User Story Comment passer de la Storymap de sortie de cadrage -> à une représentation suffisamment détaillé pour que l’équipe puisse développer. Solution 1 : pas de backlog pour les petits produits, on garde la storymap Dans le Product Backlog, on va retrouver nos Epics Thèmes et User Stories priorisé (par le PO), sous un format excel ou autre On va retrouver nos Stories prévues pour la première Release en haut du backlog!
• #29: Les éléments en haut du backlog, les plus prioritaires seront les éléments considérés par l’équipe pour le prochain Sprint. Pour que l’équipe soit capable de réaliser cette User Story, il faut certainement plus d’élément que quelques phrases sur un bout de carton… L’équipe décide donc ensemble d’un ensemble de critères (matérialisé par la frontière orange) pour qu’une User Story soit dans un état Ready : definition of ready (US qui pourra être considérée durant le prochain Sprint Planning) definition of done
• #30: Toutes les US venant du la SM se retrouvent à l’état NEW . Scrum Master vérifie la forme et Scrum Master propose Described -> Avec Forme + Critères d’acceptance claire + Exemples + Eventuellement doc Bien sur fait en amont Pourquoi délais ? À faire avant le planing meeting Grooming -> Décomposer et estimer
• #31: Objectif du BA  l’état described Avant, Dialoguer, dialoguer, dialoguer -> Au cœur du processus agile Il ne faut pas oubiler qu’une User Story n’est pas qu’une carte. La carte n’incarne qu’une promesse de discussion à propos du besoin, On veut provoquer la conversation.
• #32: Etat Ready est l’état acceptable Un petit peu abstrait, rentrons sur un cas concret de jérome
• #33: Revenons à jérôme et essayons d’appliuer cela à une user story
• #34: Commençons par un cas simple et vérifions qu’il marche réellement (avant d’ajouter de la complexité) -> discours sur la voiture Simplifier, déscendre le niveau de granularité  diminuer la complexité et augmenter la précision
• #35: Aspect récursif -> Quand est-ce que l’on s’arrete? Afiiner une story et découper une story
• #36: Ok, on est content, on a une US sont on cerne bien mieux le scope On a notre critère d’acceptance Pour autant, est-ce que notre User Story est testable? Ben non, pour pouvoir tester, il faut des exemples.
• #38: Une fois que c’est préciser, pourquoi pas ne pas aller plus loin et aller au bout de la démarche Spécification par les tests et pouruqoi pas executable Ou ce type de test pourrait être automatisé ici avec le framewok jbehave Necessite de la maintenance, c’est pas figé, ça va évoluer et ça a un coup de maintenance Support de dialogue entre BA et dev
• #39: Uen autre façon pour jérome de travailler sur ces user strory easy et de le ver les ambiguités est ce qui s’appelle le processus des 3 amigos
• #40: Uen autre façon pour jérome de travailler sur ces user strory easy et de le ver les ambiguités est ce qui s’appelle le processus des 3 amigos Avec le dialogue, en utilisant des critères de type invest ou avec le processus des three amigos, jérome travaille donc en amont des itérations de développement pour alimenter les futures iteration en approtant les précisions, les compélments nécessaire et en levant les ambihuité Ce n’est pas la seule participation de jérome sur le projet bien entendu
• #41: Jérome est bien sur un acteur au sein de l’itération meme Communiquer, apporter les précisions nécessaires, participer au rituel mise en place Précision mais pas changements
• #42: On a vu iteration -1/ -2 sur user story à passer sur statut described, groom de backlog Il est bien entenu actif au cours du sprint Il a encore un role sur les tests complémentaires utilisateur réalisé en générale à iteration + 1, test de bout en bout, d’intégration, test GUI supplémentaire…
• #43: DANGER = proxy product owner