User Stories What Else ?

872 vues

Publié le

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.

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

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

Aucune remarque pour cette diapositive

User Stories What Else ?

  1. 1. User Stories, what else ? par Christophe Addinquy 15h30 - 14h Salle 1 #AgileFrance
  2. 2. Aujourd’hui : Accompagnement agile @ Zenika Christophe Addinquy, Avant : Directeur de projet, consultant, formateur, agiliste bon teint, développeur et d’autres choses encore...
  3. 3. Donc, des outils ?!?
  4. 4. ...ça va être un peu dense ! Et pourtant incomplet Désolé...
  5. 5. Décidator Du côté de chez Victor Mon pote Bernie
  6. 6. Décidator Vision Produit Positionnement produit / marché Stratégie
  7. 7. La «pyramide de Leffingwell»
  8. 8. ✤ Une proposition de valeur ✤ Un branding ✤ Un caractère différenciant La Product Box
  9. 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
  10. 10. Simon Sinek «start with the why»
  11. 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
  12. 12. Décidator Vision Produit Positionnement produit / marché Stratégie
  13. 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. 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
  15. 15. Décidator Vision Produit Positionnement produit / marché Stratégie
  16. 16. Ash Maurya Le Lean Canvas Problem / solution fit 1 2 3 4 5 Product / market fit 7 6 8 9
  17. 17. ... ou Business Model Canvas
  18. 18. Et pour les projets internes ?
  19. 19. 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
  20. 20. Du côté de chez Victor ✤ Structurer ✤ Exprimer ✤ Solidifier
  21. 21. Du côté de chez Victor ✤ Structurer ✤ Exprimer ✤ Solidifier
  22. 22. ✤ Acteurs externes ✤ Evénements déclencheurs ✤ Evénements en retour ✤ Système boite noire Le diagramme de contexte
  23. 23. http://freethinker.addinq.uy/post/66131430961/a-la-conquete-du-story-mapping Bottom up 1 - Collecter les fonctionnalités 2 - Ajouter des détails 3 - Disposer en séquence 4 - Regrouper par fréquence 5 - Indiquer les ruptures logiques dans le worflow 6 - Diviser en releases 7 - Indiquer les estimations 8 - Servir en tranches ! Story Mapping
  24. 24. Cas d’utilisation, 1ère étape Essentiellement Top-Down ✤ Acteurs ✤ Cas d’utilisation ✤ Packages ✤ (relations)
  25. 25. Du côté de chez Victor ✤ Structurer ✤ Exprimer ✤ Solidifier
  26. 26. 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)
  27. 27. Use Cases Entitésdudomaine Entrées/sorties Vision Use case User Story Cas d’utilisation, 2nd étape (2/2)
  28. 28. ✤ Hub d’information par exigence ✤ Permet le tri ✤ Remplissage incrémental Template d’exigences
  29. 29. Software Requirements Specifications
  30. 30. Exigences non-fonctionnelles
  31. 31. 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
  32. 32. Du côté de chez Victor ✤ Structurer ✤ Exprimer ✤ Solidifier
  33. 33. ✤ 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
  34. 34. ✤ « 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é
  35. 35. Mon pote Bernie
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. ✤ 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
  41. 41. Liespotting ✤ Pourquoi ? ✤ Récompense ✤ Avantage ✤ Impression positive ✤ Pouvoir ✤ Eviter la punition ✤ Protection ✤ Intimité ✤ Comment ? ✤ Langage non-verbal ✤ Expressions faciales ✤ Indications verbales
  42. 42. Conclusions
  43. 43. 45 Analyse causale Programmation neuro- linguistique BPMModèle de Kano Design Thinking Creativity workshop Biais cognitifs Pyramide de Leffingwell Brainstorming Personas Mind maps Analyse contextuelle Use Cases Story boards Archéologie documentaire Gap analysis Exigences non- fonctionnelles Contraintes Questionnement Liste d’attributs Mesures Vision Analyse de risques Liespotting Glossaire Prototypage Story maps Stakeholders assessment Elevator statement Analyse système Product features Cartes CRC Arbre de décision Modèle de traçabilité Business case Usability engineering Analyse quantitative Goal modeling Service-Oriented requirements Integrated requirements engineering Agent-oriented requirements Use Cases maps UML Collaborative reqt. gathering Screenwriting Card sort Spécifications formelles Analyse cognitive Analyse structurée EARS Social modeling Event-oriented reqt. Contextual inquiry Reqt. driven design Problem frames Domain Driven Design HCI analysis Stakeholders taxonomy
  44. 44. « Awareness » Ne pas se méprendre sur le facteur principal !
  45. 45. Merci ! @addinquy http://freethinker.addinq.uy christophe.addinquy@zenika.com addinquy addinquy addinquy addinquy addinquy
  46. 46. Questions #AgileFrance Si vous avez des passez me voir après

×