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