Les Business Analysts face à l'agilité

708 vues

Publié le

Les méthodes agiles apportent en amont du développement de nouvelles façons de penser et concevoir un projet dans lesquelles les business analysts endossent un rôle clé.

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

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

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

    1. 1. Les Business Analysts face à l’agilité Joseph Glorieux Romain Felden
    2. 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
    3. 3. Processus Scrum 3
    4. 4. Capturer les besoins 4
    5. 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. 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. 7
    8. 8. 8 Largeur (périmètre) Profondeur (précision) Exhaustivité
    9. 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. 10
    11. 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. 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. 13 Délai 2 à 6 semaines Vision & Enjeux Scope & Roadmap Equipe Architecture Orga. & Budget Risques Cadrage Agile
    14. 14. Ateliers 14
    15. 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. 16. Pour aller plus loin 16 Product Box Luke Hohmann http://www.innovationgames.com/product-box/
    17. 17. Scope & Roadmap 17 Largeur (périmètre) Profondeur (précision)
    18. 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. 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. 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. 21. Création des releases 21 priorité nécessaire plus prioritaire moins prioritaire première release seconde release troisième release temps
    22. 22. Création des releases 22
    23. 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. 24. L’heure du départ 24 Largeur (périmètre) Profondeur (précision)
    25. 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. 26. Le premier Sprint arrive… 1 2 26
    27. 27. 1. Story Map vers Product Backlog 27 Epic Product Backlog Priorisé par valeur métier User Story
    28. 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. 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. 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. 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. 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. 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. 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. 35. Nouveaux critères d’acceptation 35 Vérifiez uniquement avec des portefeuilles mono-devises
    36. 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. 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. 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. 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. 40. Disponibilité & proximité 40 Itération -1/-2
    41. 41. Une présence tout au long du processus de delivery 41 Itération -1/-2 Itération +1/+X
    42. 42. 42 Sans une gestion de produit appropriée, les équipes de développement agile construisent simplement de mauvais produits plus vite.
    43. 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. 44. Pour aller plus loin 44

    ×