Les users stories sont rapidement devenus la formulation convenue du besoin. Mais est-ce la seule ? Est-ce toujours la meilleure ? On dit que quand on a un marteau, tout ressemble à un clou. Notre communauté agile tend à ignorer ce qui vient d'ailleurs. Pourtant ce qu'on appelle l'ingénierie des exigences est un domaine riche de plusieurs décennies de connaissances et de techniques. Certaines peuvent être utilisées directement, d'autres doivent être adaptées ou peuvent servir d'inspiration.
Dans cette présentation, nous allons passer en revue plusieurs techniques et concepts du recueil des besoins et les regarder par le prisme de nos pratiques agiles, afin d'évaluer comment elles peuvent renforcer nos pratiques actuelles.
8. ✤ Une proposition de valeur
✤ Un branding
✤ Un caractère différenciant
La Product Box
9. 30 secondes pour attirer l’attention
de votre boss dans l’ascenseur...
1 minute pour vendre
votre business model
!
De l’elevator statement au pitch
✤ Traction
✤ Produit
✤ Equipe
✤ Social proof
11. Faire rencontrer
l’ingénierie des exigences
à la communauté agile
L’assistance
d’agile Grenoble
Lecteurs de mon
blog
Donner envie d’en
savoir plus
Ce talk
Recommandation
s de lecture
ciblées
Notes de lecture
Impact Mapping
13. Veut de la
technologie
Veut une solution opérationnelle
La segmentation de marché
C’est nouveau,
imparfait, c’est une
avancée techno
C’est
nouveau et
prometteur
C’est une solution
à mon besoin
C’est un produit
bien établi qui a fait
ses preuves
J’y vais car je ne
peux plus faire
autrement
14. Se battre sur les marchés
existant
Vaincre la concurrence
Exploiter la demande existante
Ajuster la valeur par rapport au
coût
Se battre sur le prix ou
chercher le facteur
différenciateur
Créer un marché incontesté
Rendre la compétition sans
objet
Créer et capturer une nouvelle
demande
Casser l’équation coût / valeur
Rechercher le différenciateur
avec un coût ajusté
Blue ocean strategy
20. Purpose alignment model
Je fais pour moi quelque chose
de spécifique
Je fais ou j’achète une solution
standard
Envisager de ne pas
faire !
Je m’appuie sur des
spécialistes du sujet
27. 1 - Le client se présente pour régler sa nuit d’hôtel
2 - Le système affiche le montant à régler
2.1 - Le système imprime le voucher pré-payé
2.2 - Le client signe le voucher
2.2.1 - Le voucher ne correspond pas au client
2.3 - Le système enregistre le voucher acquitté
3 - Le client règle sa facture en cash
3.1 - Le client règle sa facture par C.B.
3.2 - Le système imprime une facturette (suite en 5)
4 - La système affiche le montant à rendre
4 - Le système imprime la facture
4.1 - Impression de la facture impossible
5 - Le système clos la transaction
Cas d’utilisation, 2nd étape (1/2)
32. Le modèle QUPER
✤ Définir les indicateurs qualité
✤ Pour chaque fonctionnalité : estimer
les breakpoints et barrières
✤ Estimer la qualité actuelle du produit
/ des concurrents
✤ Estimer la qualité cible souhaitée
✤ Communiquer / itérer
34. ✤ Exigences déclinées en
exemples
✤ Basé (si possible) sur des cas
réels
✤ Construits en collaboration
✤ Avec les combinatoires
✤ Avec les cas aux limites
Spécifications exécutables
35. ✤ « Quality gateway »
✤ Alignement sur l’objectif
✤ Viabilité des contraintes
✤ Besoin ou solution ?
✤ Levée des ambiguïtés
✤ PLanguage ?
✤ Quantification des attributs
✤ Levée des implicites
✤ Etc...
Améliorer la qualité
37. Go & See (aller sur le terrain)
✤ Voir ce que le système ne
prends pas en compte
(environnement de travail)
✤ Observer la logique de travail
✤ Mesurer les temps productifs /
improductifs
✤ Comprendre les problèmes /
souffrances des utilisateurs
✤ S’immerger dans le métier
✤ Empathie avec les utilisateurs
38. Analyse Causale
✤ L’utilisateur n’exprime généralement
pas un besoin mais ce qu’il pense être
la solution
✤ Factualiser, s’extraire du ressenti
✤ Remonter au besoin initial
✤ Les 5 pourquoi : une recette pour
l’analyse causale
39. Workshops
✤ Requirements workshop
✤ Définir, Identifier
✤ Acceptance tests workshop
✤ Cadrer, préciser et lever les ambiguïtés
✤ Brainstorm
✤ Générer des options, rechercher des solutions non
triviales
✤ Discussions informelles
✤ Comprendre
40. Questions hors
contexte
• Pour quelles raisons désirons-
nous cette fonctionnalité ?
• De quoi pouvons-nous nous
inspirer ?
Focus questions
• Qui ? Où ?
• Comment ? Quand ?
• Pourquoi ?
• Quoi ?
Questions Ouvertes
• Que voulez-vous traiter ?
• Que souhaitez-vous y voir
figurer ?
• Comment voyez-vous ça ?
Questions Fermées
• Cette information est-elle
obligatoire ?
Questions Provocatrices
• Immédiatement : c’est
nécessairement moins d’1 sec.
ou 1 min. convient encore ?
✤ Questions hors contexte : En amont pour connaitre des propriétés générales
✤ Focus questions : Pour détailler et lever des ambiguïtés
✤ Questions ouvertes : Pour générer des informations
✤ Questions fermées : pour lever des options
✤ Questions provocatrices : Pour affiner une information
Questionner
41. ✤ Biais rétrospectif ou l'effet « je le savais
depuis le début »
✤ Effet de récence : mieux se souvenir
des dernières informations auxquelles
on a été confronté
✤ Effet de simple exposition : avoir
préalablement été exposé à quelqu'un
ou à une situation le/la rend plus positive
✤ Effet d'ambiguïté : tendance à éviter les
options dont on manque d'information
✤ Ancrage mental : La répétabilité d’un
phénomène crée une illusion de
causalité
✤ Biais de statu quo : la nouveauté est
vue comme apportant plus de risques
que d'avantages possibles et amène une
résistance au changement
✤ Effet de halo : une perception sélective
d'informations allant dans le sens d'une
première impression que l'on cherche à
confirmer
✤ Biais de confirmation d'hypothèse :
préférer les éléments qui confirment
plutôt que ceux qui infirment une
hypothèse
✤ Perception sélective : interpréter de
manière sélective des informations en
fonction de sa propre expérience
Les biais cognitifs