Les business analystes face à l'agilité
•
0 recomendaciones•741 vistas
Du cadrage agile aux itérations, parcours du combattant du business analyste
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (12)
Destacado
Destacado (20)
Similar a Les business analystes face à l'agilité
Similar a Les business analystes face à l'agilité (20)
Más de Joseph Glorieux
Más de Joseph Glorieux (8)
Les business analystes face à l'agilité
- 1. 1 © OCTO 2015 Les Business Analystes face à l’agilité Joseph Glorieux @jglorieux
- 2. 2 Faisons connaissance avec … 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
- 5. 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 ? Accompagnons Jérôme dans son voyage vers l’Agile
- 6. 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 ? Accompagnons Jérôme dans son voyage vers l’Agile
- 8. 8 Taux d’utilisation des fonctionnalités 7% 13% 16% 45% 19% Toujours Souvent Parfois Jamais Rarement 64%de gaspillage Standish Group, XP 2012
- 9. 9
- 10. 10 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 Cadrage agile, n. m.
- 11. 11 ~1J Partager les fondamentaux Agiles et initialiser la dynamique d’équipe BOOTSTRAP AGILE ~2h Personnaliser les utilisateurs pour mieux les comprendre PERSONAS ~1J Qui sont les utilisateurs ? Quels sont leurs problèmes/besoins ? Quels enjeux pour l’entreprise ? Quelle proposition de valeur ? Quels critères de succès ? VISION Quels logiciels/technologies /frameworks ? Quels risques ? Quelles contre- mesures ? RISQUES ~4h JAN FEV MARS POINT D’ATTENTION FEATURE VICTOIRE Quelle trajectoire de réalisation ? ROADMAP ~1J ~4h Quel process ? ORGA AGILE Quelles métriques ? Quels rituels ? ? ? ? Quelle solution d’industrialisation du code ? ~3h Quels échanges de données ? Quels formats ? ARCHI TECHNIQUE Quel matériel ? Quels standards de qualité pour le code ? Quels tests ? ~2h ~1h ~2h TECH ARCHI APPLICATIVE PRATIQUES DE DEV FLUX ORGATECHPRODUIT Quelles sont les macro- fonctionnalités ? STORYMAP ~1J ++ + - EPIC (activité) FEATURE (Macro- fonctionnalité) ~3h Quel est le rôle de chacun ? Quelles sont les interactions ? RÔLES RESPONSABILITÉS Cadrage agile – entre 2 et 6 semaines pour obtenir une équipe alignée prête à démarrer 2~6 semaines
- 12. 12 Ateliers
- 13. 13 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 La vision produit de Jérôme
- 14. 14 Exemple – atelier vision produit Product Box Luke Hohmann http://www.innovationgames.com/product-box/
- 15. 15 Scope & Roadmap Largeur (périmètre) Profondeur(précision)
- 16. 16 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
- 17. 17 Tranche de vie… Ils s’adorent, mais il leur arrive de se taper sur les nerfs au boulot Le sport est un bon moyen pour reconnecter… et se défouler ! Aspirations Acheter un gros voilier, pour y vivre et voyer / plonger dans le monde entier Besoins S’amuser et se relaxer ensemble Leurs dernières vacances Ski & plongée sous glace en Alaska - Est-ce le meilleur moment pour y plonger ? - Quelles autres activités sont disponibles sur place ? - Doit-on / Peut on emmener notre propre équipement ? - Kate voudrait essayer la plongée profonde, y a-t’-il des stages spécialisés ? - “Tout compris” : plus de sports à pratiquer ! - Parmi les meilleurs sites au monde, les gens sont sympas, et l’ambiance très relax. Ils ont découvert par hasard, c’est maintenant leur référence - Plutôt spontané ! Quand c’est le moment pour eux, ils cherchent un endroit qui leur plairait - Comparent selon les activités sur place (plongée en particulier), et la beauté de l’endroit - La meilleure offre l’emporte En préparation – Les Personas « Les vacances sont l’occasion de plonger dans de nouveaux spots » OBJECTIFS Trouver un super endroit pour pratiquer leurs sports favoris, et prendre le soleil. Ou? : Peut-être l’Indonésie, mais ouverts à toutes les nouvelles destinations. Quand? : Peu importe. Le meilleur moment pour y aller. Budget? : Flexible. Thomas & Kate Binch 55 ans – mariés, sans enfants Importateur de vin Cheltenham, Angleterre EN QUELQUES MOTS… QUESTIONS PROCESS DE RÉSERVATION ATTITUDES
- 18. 18 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 temps
- 19. 19 temps Illustration de Jeff Patton – User Story Mapping – http://www.agileproductdesign.com « Quelles tâches l’utilisateur accomplit-il au sein de cette activité ? » Organiser les tâches verticalement dans l’ordre du workflow
- 20. 20 Création des releases priorité nécessaire plus prioritaire moins prioritaire première release seconde release troisième release temps
- 21. 21
- 22. 22 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 La storymap : un « must have »
- 23. 23 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 ? Accompagnons Jérôme dans son voyage vers l’Agile
- 24. 24 Le premier Sprint arrive… 1 2
- 25. 25 1. Story Map vers Product Backlog Epic ProductBacklog Prioriséparvaleurmétier User Story
- 26. 26 2. Être prêt pour le prochain Sprint Planning Epic ProductBacklog Prioriséparvaleurmétier User Story User Stories dans l’état READY
- 27. 27 Cycle de vie de la User Story New To be described To be estimated Committed Done Ready Described À retenir Le BA amène un ensemble cohérent de User Stories à l’état Described Coté développement agile
- 28. 28 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 » L’état Described
- 29. 29 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 User story - les critères INVEST
- 30. 30 Exemple issu de RTPM 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
- 31. 31 Critères d’acceptation 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 … … … … … … …
- 32. 32 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
- 33. 33 Nouveaux critères d’acceptation Vérifiez uniquement avec des portefeuilles mono-devises
- 34. 34 Sachant que le portefeuille contient 1 action en CHF Quand je demande la valeur de mon portefeuille Alors la valeur de mon portefeuille vaut 1 CHF de Et que l’action monte de 1,00 CHF le lendemain le lendemain plus Un exemple concret – Formalisme Gherkin Sachant que le portefeuille contient 1 action NESN Quand je demande la valeur de mon portefeuille Alors la valeur de mon portefeuille vaut 67,20 CHF le 3 janvier 2014 au cours de 66,20 Et que l’action monte de 1,00 CHF le 4 janvier 2014 le 4 janvier 2014
- 35. 35 Exemple 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 ScenarioFixture
- 36. 36 Processus des « Three Amigos » BA Développeur QA 30 min – 1h 1 ou 2 sprint(s) avant le développement Durée Quand 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)
- 38. 38 Disponibilité & proximité Itération -1/-2
- 39. 39 Une présence tout au long du processus de delivery Itération -1/-2 Itération +1/+X
- 40. 40 Sans une gestion de produit appropriée, les équipes de développement agile construisent simplement de mauvais produits plus vite.
- 41. 41 J’y vais demain ! 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 »
- 42. 42 Pour aller plus loin
- 43. 43
Notas del editor
- Pour incarner cette présentation, nous vous proposons de suivre les évolutions de jérome
- 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
- Le cadrage, d'habitude, c'est ça : exhaustif (cahier de specs) -> Trop de détails On est quasi certain que l’on aura pas tout, alors demandons en beaucoup, en espérant avoir quelque chose de « viable ».
- 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 d’1 an et demi
- Insérer de l’agile au niveau du cadrage -> accord puis démarrage ou pas
- En 2 à 6 semaines, on devrait pouvoir cadrer n’importe quel projet, sinon découpage
- Réunir tout le monde au départ -> difficile + réflexion entre ateliers Timeboxing Balayage du périmètre
- 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
- Personnaliser les utilisateurs du produit pour mieux les comprendre Aider l’équipe de réalisation à comprendre le point de vue de l’utilisateur et faciliter les discussions sur les usages et les fonctionnalités En réutilisant le travail fait dans l’atelier vision Liste des utilisateurs types du produit, leurs caractéristiques
- 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
- 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
- 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 apportant les précisions, les compléments nécessaire et en levant les ambiguité Ce n’est pas la seule participation de jérome sur le projet bien entendu
- 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 apportant les précisions, les compléments nécessaire et en levant les ambiguité On a vu iteration -1/ -2 sur user story à passer sur statut described, groom de backlog
- 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
- 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