Les business analystes face à l'agilité

361 vues

Publié le

Du cadrage agile aux itérations, parcours du combattant du business analyste

Publié dans : Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
361
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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
  • Les business analystes face à l'agilité

    1. 1. 1 © OCTO 2015 Les Business Analystes face à l’agilité Joseph Glorieux @jglorieux
    2. 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
    3. 3. 3 Processus Scrum
    4. 4. 4 Capturer les besoins
    5. 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. 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
    7. 7. 7 Largeur (périmètre) Profondeur(précision) Exhaustivité
    8. 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. 9
    10. 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. 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. 12 Ateliers
    13. 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. 14 Exemple – atelier vision produit Product Box Luke Hohmann http://www.innovationgames.com/product-box/
    15. 15. 15 Scope & Roadmap Largeur (périmètre) Profondeur(précision)
    16. 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. 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. 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. 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. 20 Création des releases priorité nécessaire plus prioritaire moins prioritaire première release seconde release troisième release temps
    21. 21. 21
    22. 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. 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. 24 Le premier Sprint arrive… 1 2
    25. 25. 25 1. Story Map vers Product Backlog Epic ProductBacklog Prioriséparvaleurmétier User Story
    26. 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. 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. 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. 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. 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. 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. 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. 33 Nouveaux critères d’acceptation Vérifiez uniquement avec des portefeuilles mono-devises
    34. 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. 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. 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)
    37. 37. 37 Backlog grooming Itération -1/-2
    38. 38. 38 Disponibilité & proximité Itération -1/-2
    39. 39. 39 Une présence tout au long du processus de delivery Itération -1/-2 Itération +1/+X
    40. 40. 40 Sans une gestion de produit appropriée, les équipes de développement agile construisent simplement de mauvais produits plus vite.
    41. 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. 42 Pour aller plus loin
    43. 43. 43

    ×