Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Les Business Analysts face à l'agilité
Similaire à Les Business Analysts face à l'agilité (20)
Les Business Analysts face à l'agilité
- 1. Les Business Analysts face à l’agilité Joseph Glorieux Romain Felden
- 2. Faisons connaissance avec … 2 Jérôme, 35 ans, Business Analyst au sein d’une banque privée Travaille sur les applicatifs des Responsables de Portefeuilles Souhaite mettre au point une plateforme leur offrant plus de réactivité et de souplesse
- 4. Capturer les besoins 4
- 5. Accompagnons Jérôme dans son voyage vers l’Agile 5 Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la définition du produit ? Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la réalisation du projet ?
- 6. Accompagnons Jérôme dans son voyage vers l’Agile 6 Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la définition du produit ? Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la réalisation du projet ?
- 7. 7
- 8. 8 Largeur (périmètre) Profondeur (précision) Exhaustivité
- 9. Taux d’utilisation des fonctionnalités 9 7% 13% 16% 19% 45% Toujours Souvent Parfois Jamais Rarement 64% de gaspillage Standish Group, XP 2012
- 10. 10
- 11. 11 Responding to change over following a plan* L’agilité, c’est accepter le changement. Le changement ne doit plus être un obstacle, il doit devenir un levier. * http://agilemanifesto.org/
- 12. Cadrage agile, n. m. 12 Préparation réalisée en temps contraint, au cours de laquelle se succèdent un certain nombre d’activités et d’ateliers permettant d’aligner tout le monde autour de thématiques structurantes, qui se termine par un livrable global et synthétique pour validation et démarrage effectif du projet
- 13. 13 Délai 2 à 6 semaines Vision & Enjeux Scope & Roadmap Equipe Architecture Orga. & Budget Risques Cadrage Agile
- 14. Ateliers 14
- 15. La vision produit de Jérôme 15 Real-Time Portfolio Management (RTPM) est une application qui permet de consulter les métriques performance et risque sur l’ensemble des portefeuilles gérés, en temps réel et à la demande
- 16. Pour aller plus loin 16 Product Box Luke Hohmann http://www.innovationgames.com/product-box/
- 17. Scope & Roadmap 17 Largeur (périmètre) Profondeur (précision)
- 18. 18 Quoi ? Durée Qui ? Story Mapping Découverte collaborative du produit Outil de priorisation 2h à 8h Séances de 2h maximum Product Owner et BA Stakeholders Equipe de développement Ergonomes
- 19. 19 temps Organiser les activités de gauche à droite, dans l’ordre dans lequel on répondrait à la question « Que font les utilisateurs de ce produit ? » Illustration de Jeff Patton – User Story Mapping – http://www.agileproductdesign.com
- 20. 20 temps « Quelles tâches l’utilisateur accomplit-il au sein de cette activité ? » Organiser les tâches verticalement dans l’ordre du workflow Illustration de Jeff Patton – User Story Mapping – http://www.agileproductdesign.com
- 21. Création des releases 21 priorité nécessaire plus prioritaire moins prioritaire première release seconde release troisième release temps
- 22. Création des releases 22
- 23. 23 Meilleure compréhension du produit • Liens entre les éléments matérialisés • Représentation des flux et séquences utilisateur • Priorisation facilitée par l’aspect visuel Initialisation et suivi du backlog • Création rapide des premiers éléments de backlog • Suivi de l’avancement des incréments Gestion du changement • Souvent mieux reçue que le backlog • Appropriation facilitée
- 24. L’heure du départ 24 Largeur (périmètre) Profondeur (précision)
- 25. Accompagnons Jérôme dans son voyage vers l’Agile 25 Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la définition du produit ? Quel rôle et quelle(s) responsabilité(s) pour Jérôme dans la réalisation du projet ?
- 26. Le premier Sprint arrive… 1 2 26
- 27. 1. Story Map vers Product Backlog 27 Epic Product Backlog Priorisé par valeur métier User Story
- 28. 2. Être prêt pour le prochain Sprint Planning 28 Epic Product Backlog Priorisé par valeur métier User Story User Stories dans l’état READY
- 29. Cycle de vie de la User Story 29 New To be described Described To be estimated Ready Committed Done À retenir Le BA amène un ensemble cohérent de User Stories à l’état Described Coté développement agile
- 30. L’état Described 30 Signifie que la User Story ne contient plus d’ambiguïté Peut être estimée puis réalisée sereinement par l’équipe Comment lever les ambiguïtés ? Dialoguer, Dialoguer, Dialoguer Utiliser les critères INVEST comme « guidelines » Processus « three amigos »
- 31. User story - les critères INVEST 31 Indépendante Elle dépend le moins possible d’autres User Stories Négociable Une User Story n’est pas un contrat. Elle est négociée et discutée Valorisable Elle apporte de la valeur à l’utilisateur final Estimable Elle peut être aisément estimée Sprintable Elle tient dans un sprint Testable Elle peut être testée et validée
- 32. Exemple issu de RTPM 32 Recalculer la valeur du portefeuille En tant que responsable de portefeuille Je veux recalculer la valeur d’un portefeuille à une date arbitraire Afin de pouvoir informer mon client des valeurs les plus pertinentes
- 33. Critères d’acceptation 33 Vérifier avec un portefeuille qui ne contient qu’une Action en USD Vérifier avec un portefeuille qui ne contient qu’une Option en USD Vérifier avec un portefeuille qui contient une action et une option en USD … … … … … … …
- 34. Comment réduire la granularité (et augmenter la précision) ? Recalculer la valeur du portefeuille contenant une action En tant que responsable de portefeuille Je veux recalculer la valeur d’un portefeuille contenant une seule action à une date arbitraire Afin de pouvoir informer mon client en ayant les valeurs les plus pertinentes à lui communiquer 34
- 35. Nouveaux critères d’acceptation 35 Vérifiez uniquement avec des portefeuilles mono-devises
- 36. Un exemple concret – Formalisme Gherkin 36 Sachant que le portefeuille contient 1 action en CHF Et que l’action monte de 1,00 CHF le lendemain le 3 janvier 2014 au cours de 66,20 Et que l’action monte de 1,00 CHF le 4 janvier 2014 Quand je demande la valeur de mon portefeuille le lendemain le 4 janvier 2014 Alors la valeur de mon portefeuille vaut 1 CHF de plus NESN Quand je demande la valeur de mon portefeuille Alors la valeur de mon portefeuille vaut 67,20 CHF
- 37. Exemple 37 Scenario: Recalculer la valeur du portefeuille le lendemain quand il ne possède qu’une action Nestlé Given le portefeuille contient 1 action NESN le 3 janvier 2014 au cours de 66,20 And l’action monte de 1,00 CHF le 4 janvier 2014 When je demande la valeur du portefeuille le lendemain Then la valeur de mon portefeuille vaut 67,20 CHF Fixture Scenario
- 38. L’état Described 38 Signifie que la User Story ne contient plus d’ambiguïté Peut être estimée puis réalisée sereinement par l’équipe Comment lever les ambiguïtés ? Dialoguer, Dialoguer, Dialoguer Utiliser les critères INVEST comme « guidelines » Processus « three amigos »
- 39. Processus des « Three Amigos » 39 BA Développeur QA Durée 30 min – 1h Quand 1 ou 2 sprint(s) avant le développement Il introduit la User Story aux autres Amigos Ressemblance avec une autre déjà développée ? Il présente les tests associés Qui ont été préparés à l’avance Il prend en compte les feedbacks immédiatement Il donne son feedback sur la User Story Granularité + tests Il communique les tâches à réaliser avant le développement Est-ce qu’il a besoin de plus de docs ? Est-ce qu’il a besoin d’accéder à un service particulier ? (Il donne son estimation) Bénéfices Connaissance partagée des besoins Connaissance partagée des tests Consensus à propos de la qualité de la spécification Il donne son feedback sur la User Story Granularité + tests Il communique les tâches à réaliser avant les tests Est-ce qu’il a besoin d’accéder à un système ? (Il donne son estimation)
- 40. Disponibilité & proximité 40 Itération -1/-2
- 41. Une présence tout au long du processus de delivery 41 Itération -1/-2 Itération +1/+X
- 42. 42 Sans une gestion de produit appropriée, les équipes de développement agile construisent simplement de mauvais produits plus vite.
- 43. J’y vais demain ! 43 Sur un nouveau projet • Mener un atelier de vision produit • Organiser des séances de Story Mapping • Essayer de démarrer le projet rapidement Sur un projet en cours • Introduire progressivement les spécifications exécutables • Organiser des ateliers « Three amigos »
- 44. Pour aller plus loin 44
Notes de l'éditeur
- 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
- 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
- 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
- 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
- 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
- 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
- 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
- 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.
- 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)
- Cadrage rapide, pas de tunnel
- 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.
- -> accord puis démarrage ou pas
- 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
- 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
- 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)
- 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
- Qu’avez-vous fait ce matin avant de venir ici ? - Manger - Doucher - Raser - Brosser les dents - Habiller - …
- 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
- 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
- François va vous présenter les outils pour affiner les besoins et préparer les sprints de l’équipe de développement
- ma partie 17 minutes : 10 slides Bien sur la responsailité de jérome se s’arrete pas là,
- 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
- 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!
- 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
- 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
- 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.
- Etat Ready est l’état acceptable Un petit peu abstrait, rentrons sur un cas concret de jérome
- Revenons à jérôme et essayons d’appliuer cela à une user story
- 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
- Aspect récursif -> Quand est-ce que l’on s’arrete? Afiiner une story et découper une story
- 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.
- 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
- 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
- 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
- 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
- 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…
- DANGER = proxy product owner