Your SlideShare is downloading. ×
Les Business Analysts face à l'agilité : de nouveaux challenges à relever
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Les Business Analysts face à l'agilité : de nouveaux challenges à relever

533

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
533
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 1 © OCTO 2014© OCTO 2014 François HELG Olivier JACOB Les Business Analysts face à l’agilité
  • 2. 2 © OCTO 2014
  • 3. 3 © OCTO 2014 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
  • 4. 4 © OCTO 2014 Processus Scrum
  • 5. 5 © OCTO 2014 Vers l’itératif et l’incrémental Plus de « phases » dans le projet Place à l’itératif & l’incrémental
  • 6. 6 © OCTO 2014 Capturer les besoins Titre de la User Story En tant que <rôle> Je veux <désir> Afin de <bénéfice>
  • 7. 7 © OCTO 2014 Où sont les détails dans les User Stories Titre de la User Story En tant que <rôle> Je veux <désir> Afin de <bénéfice> Où sont les détails ?
  • 8. 8 © OCTO 2014 Une organisation différente Où est le Business Analyst ? Où est le Project Manager ?
  • 9. 9 © OCTO 2014 ! 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
  • 10. 10 © OCTO 2014 Gestion de produit
  • 11. 11 © OCTO 2014 Pour réaliser un logiciel, l’approche habituelle consiste à décrire exhaustivement ce que l’on veut, pour en déduire ensuite une solution cible.
  • 12. 12 © OCTO 2014 Largeur (périmètre) Profondeur(précision) Exhaustivité
  • 13. 13 © OCTO 2014 Taux d’utilisation des fonctionnalités 7% 45% 19% 16% 13% Toujours Jamais Rarement Parfois Souvent 64%de gaspillage Jim Johnson, chairman, Standish Group, XP 2002
  • 14. 14 © OCTO 2014 On est toujours plus intelligent après. Source anonyme
  • 15. 15 © OCTO 2014 Facteurs endogènes
  • 16. 16 © OCTO 2014 Facteurs exogènes
  • 17. 17 © OCTO 2014 Responding to change over following a plan* * http://agilemanifesto.org/
  • 18. 18 © OCTO 2014 L’agilité, c’est accepter le changement. Le changement ne doit plus être un obstacle, il doit devenir un levier. Responding to change over following a plan* * http://agilemanifesto.org/
  • 19. 19 © OCTO 2014 Une 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, n. m.
  • 20. 20 © OCTO 2014 ! Temps contraint !   Démarrer le projet rapidement !   Se concentrer sur l’essentiel ! Ce n’est probablement pas grave si on n’a pas eu le temps de tout cadrer ! La plus grande contrainte est la disponibilité des interlocuteurs !   Sponsors / Stakeholders ! Sachants métier / Utilisateurs
  • 21. 21 © OCTO 2014 Aligner tout le monde ! Métier / Utilisateurs ! Marketing ! Développement ! Exploitation / Production
  • 22. 22 © OCTO 2014 Délai 2 à 4 semaines Vision / Enjeux Scope & Roadmap Orga. & Budget Equipe Architecture Risques Cadrage
  • 23. 23 © OCTO 2014 ! Aligner l’équipe et ses clients en 1 phrase sur l’objectif du produit ! Fournir un fil rouge !   Trouver les principaux axes de développement du produit !   Les nouveaux besoins servent-ils la vision produit ? !   Entre 2 besoins, lequel sert le plus la vision produit ? Partager une Vision produit
  • 24. 24 © OCTO 2014 Real-Time Portfolio Management (RTPM) est une application de type dashboard 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
  • 25. 25 © OCTO 2014 Pour aller plus loin Elevator Statement Product Box Geoffrey Moore, Crossing the chasm Luke Hohmann http://www.innovationgames.com/product-box/ Pour les gestionnaires de portefeuille Qui ont besoin de métriques temps réel RTPM est un outil financier Qui offre de nouvelles perspectives pour l’analyse de portefeuille. Contrairement aux approches classiques Notre produit traite les événements de marché et les trades intraday en temps réel pour proposer les métriques performance et risque au plus près de la réalité.
  • 26. 26 © OCTO 2014 Scope & Roadmap Largeur (périmètre) Profondeur(précision) ! 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
  • 27. 27 © OCTO 2014 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
  • 28. 28 © OCTO 2014 time ! 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
  • 29. 29 © OCTO 2014 time 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
  • 30. 30 © OCTO 2014 Et Jérôme ?
  • 31. 31 © OCTO 2014 Maintenant il faut prioriser ©Scott Adams, Inc. - http://dilbert.com/strips/comic/2007-08-24/
  • 32. 32 © OCTO 2014 time necessity The backbone The walking skeleton Illustration de Jeff Patton – User Story Mapping – http://www.agileproductdesign.com
  • 33. 33 © OCTO 2014 Création des releases optionality necessary less optional more optional first release second release third release time
  • 34. 34 © OCTO 2014 Création des releases
  • 35. 35 © OCTO 2014 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
  • 36. 36 © OCTO 2014 ! Product Owner est un rôle délicat nécessitant une large palette de compétences !   Selon son profil, un BA peut endosser le rôle de Product Owner !   Les BA peuvent accompagner le Product Owner dans la définition du produit ! Lors de la définition du produit, les BA peuvent donc !   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 Quel rôle pour Jérôme ?
  • 37. 37 © OCTO 2014 L’heure du départ Largeur (périmètre) Profondeur(précision)
  • 38. 38 © OCTO 2014 ! 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
  • 39. 39 © OCTO 2014 Le premier Sprint arrive… 1 2
  • 40. 40 © OCTO 2014 Story Map vers Product Backlog Epic ProductBacklog Prioriséparvaleurmétier Thème User Story
  • 41. 41 © OCTO 2014 2. Être prêt pour le prochain Sprint Planning Epic ProductBacklog Prioriséparvaleurmétier Thème User Story User Stories dans l’état READY
  • 42. 42 © OCTO 2014 Cycle de vie de la User Story New To be described To be estimated Commited Done Ready Described À retenir Le BA amène un ensemble cohérent de User Stories à l’état Described
  • 43. 43 © OCTO 2014 Board de suivi de l’état des User Stories New To be described Described To be estimated Ready Commited Done
  • 44. 44 © OCTO 2014 Travail du BA New Described To be estimated Ready Commited Done Titre En tant que … Je veux … Afin de … To be described
  • 45. 45 © OCTO 2014 ! 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 ? !  Utiliser les critères INVEST comme « guidelines » !  Dialoguer, Dialoguer, Dialoguer L’état Described
  • 46. 46 © OCTO 2014 User Story – Les 3C ! Carte !   Les User Stories sont traditionnellement écrites sur des cartes ! Conversation !   Les détails de la Story se matérialisent durant les conversations (entre le Product Owner, BA et l’équipe) ! Confirmation !   Des tests d’acceptation confirment que la story a été réalisée correctement Favorise la communication orale
  • 47. 47 © OCTO 2014 ! Independent !   Elle dépend le moins possible d’autres User Stories ! Negotiable !   Une User Story n’est pas un contrat. Elle est négociée et discutée ! Valuable !   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
  • 48. 48 © OCTO 2014 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 en ayant les valeurs les plus pertinentes à lui communiquer
  • 49. 49 © OCTO 2014 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 Mauvais signe… … … … … … … …
  • 50. 50 © OCTO 2014 Comment réduire la granularité (et augmenter la précision) ? Recalculer la valeur du portefeuille contenant 1 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 Recalculer la valeur du portefeuille En tant que responsable de portefeuille Je veux recalculer la valeur d’un portefeuille contenant une action et une option à une date arbitraire Afin de pouvoir informer mon client en ayant les valeurs les plus pertinentes à lui communiquer
  • 51. 51 © OCTO 2014 Nouveaux critères d’acceptation Vérifiez uniquement avec des portefeuilles mono-devises
  • 52. 52 © OCTO 2014 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
  • 53. 53 © OCTO 2014 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)
  • 54. 54 © OCTO 2014 Automatisez les tests d’acceptation
  • 55. 55 © OCTO 2014 Un exemple concret – Formalisme Gherkin 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 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
  • 56. 56 © OCTO 2014 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
  • 57. 57 © OCTO 2014 D’autres outils ? ! « Gherkin »-based !   Cucumber (Ruby) ! jBehave / Cucumber-JVM (Java) ! Specflow (.NET) ! Behat (PHP) ! Wikis !   FitNesse ! GreenPepper ! Autres ! Concordion !   Robot Framework
  • 58. 58 © OCTO 2014 Tests d’acceptation Critères d’acceptation Exemples (données)+ Spécification par l’exemple + Automatisation Spécifications exécutables
  • 59. 59 © OCTO 2014 Intérêt d’automatiser les tests d’acceptation CONSOLIDER LA CONNAISSANCE •  Posséder la connaissance du système dans un unique référentiel •  Rendre les spécifications exécutables COMMUNIQUER CLAIREMENT •  Utiliser les tests pour spécifier de manière non- ambigüe •  Limiter les problèmes de coordination durant les UAT MAINTENIR UN HAUT NIVEAU DE QUALITÉ •  Construire un harnais de test •  Détecter les régressions et les bugs rapidement GAGNER DU TEMPS •  Eviter les tâches manuelles •  Lancer la suite de test régulièrement HARNAIS DE TESTS D’ACCEPTATION AUTOMATISÉS
  • 60. 60 © OCTO 2014 Proxy Product Owner
  • 61. 61 © OCTO 2014 ! 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 ?
  • 62. 62 © OCTO 2014 Sans une gestion de produit appropriée, les équipes de développement agile construisent simplement de mauvais produits plus vite.
  • 63. 63 © OCTO 2014 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 en moins de 4 semaines Sur un projet en cours •  Introduire progressivement les spécifications exécutables •  Organiser des ateliers « 3 amigos »
  • 64. 64 © OCTO 2014
  • 65. 65 © OCTO 2014 La pyramide d’automatisation des tests ! “building the thing right” ! ROI le plus important => Effort d’automatisation le plus important ! TDD => drive development ! “building the right thing” ! Moins couteux à maintenir que les tests sur la GUI ! ATDD => drive development ! ROI les plus faible => effort minimal d’automatisation ! Plus lent et plus fragile ! Ecrits après le développement ! Souvent toujours nécessaire ! Doit être réduit au minimum

×