Save 37% off PRO during our Black Friday Sale! »

Spécifications en milieu agile - BreizhCamp 2016

Spécifications en milieu agile - BreizhCamp 2016

La question de savoir quoi faire reste un élément central de notre industrie !
Mais comment associer spécifications fonctionnelles et techniques avec les méthodologies agiles ? Comment permettre au client de garder une vision d'ensemble sans être noyé sous le détail ?

En étudiant les pratiques du user story mapping, de l'impact mapping et de l'event storming, nous verrons comment concilier agilité et vision produit !

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

March 25, 2016
Tweet

Transcript

  1. None
  2. -Edward Berard « Walking on water and developing software from

    a specification are easy 
 if both are frozen. »
  3. Spécifications en milieu agile Arnaud LEMAIRE — @lilobase

  4. Qu’est ce que des spécifications agiles ?

  5. Problème métier du client Solution (produit fini) Spécifications

  6. Le cahier des charges « Du téléphone arabe Enterprise Edition™

    » Utilisateur final Chef de projet Cahier des charges fonctionnel Lead technique Cahier des charges technique Développeurs
  7. None
  8. Spécifications Utilisateur final Développeurs « Les spécifications doivent être coconstruites

    avec le client final » Si vous n’avez pas accès aux utilisateurs finaux, nommez quelqu’un en interne pour prendre ce rôle
  9. Les spécifications sont indispensables • Savoir quoi développer, permet vraiment

    se concentrer sur notre métier : faire du logiciel de qualité • Le manifeste agile n’a jamais indiqué qu’il ne fallait pas de spécifications (souvenez vous du contexte de l’époque) « Working software over comprehensive documentation »
  10. Les spécifications agiles • Le problème du client change rarement

    • Par contre la solution à ce besoin va évoluer pendant la durée de vie du logiciel • Les spécifications vont ainsi évoluer pendant le projet « Responding to change over following a plan »
  11. Spécifications Développement Just Enough Design Up Front Spécifications Développement Big

    Design Up Front
  12. Cette présentation n’est pas : • Une présentation des méthodes

    agiles • Une présentation détaillée de : • User Story Mapping • Impact Mapping • Event Storming
  13. Quel est le problème du client ?

  14. « Ce que le client veut n’est pas forcément ce

    dont il a besoin » « Le cahier des charges du client est rarement la meilleure solution à son problème » 1ère étape : découvrir le vrai problème du client
  15. Les 5 « pourquoi ? » • J’ai besoin d’un

    CRM pour le milieu médical • Pourquoi ? • Pour aider les médecins à faire des ordonnances • Pourquoi ? • Car il y a des erreurs dans les ordonnances que font les médecins • Pourquoi ? • Ils prescrivent des médicaments incompatibles • Pourquoi ? • Les interactions médicamenteuses sont très complexes et très nombreuses
  16. J’ai besoin d’un CRM pour le milieu médical Les interactions

    médicamenteuses sont très complexes Le client besoin d’un logiciel pour calculer les interactions entre médicaments
  17. La définition récursive • J’ai besoin d’un réseau social pour

    les voisins • Qu’est ce qu’un réseau social ? • Un site web où les utilisateurs peuvent poster des messages • C’est quoi des messages ? • Des petites annonces principalement • C’est quoi des voisins ? • Des personnes qui habitent dans la même rue
  18. J’ai besoin d’un réseau social pour les voisins J’ai besoin

    d’un site web où les personnes 
 qui vivent dans la même rue peuvent poster 
 des petites annonces
  19. Quelle est la meilleure solution au problème ?

  20. « Eviter de construire quelque chose qui ne correspond pas

    au besoin du client » « Chercher à obtenir le meilleur retour sur investissement pour le client » 2ère étape : découvrir la solution qui maximise l’impact pour le client
  21. Impact mapping • Adaptation de « InUse effect mapping »

    de Mijo Balic & Ingrid Domingues par Gojko Adzic • Permet d’éviter le « scope creep » et de faire de la « sur-ingénierie » • Aide à créer une vision commune de la solution à développer
  22. Impact mapping pourquoi Qui Qui Comment Comment Quoi Quoi Le

    problème Une solution
  23. Impact mapping Pourquoi Afin de faire baisser les erreurs de

    50% dans les ordonnances Les médecins Qui Ont accès au bon moment à l’information sur les interactions médicamenteuses Comment Grâce à une fiche récapitulative présente sur chaque médicament enregistré Quoi
  24. Traduction en user story En tant que médecin, j’ai accès

    à une fiche récapitulative sur chaque médicament afin de connaitre les interactions médicamenteuses de celui-ci
  25. Quel est le contexte métier de l’application ?

  26. « Permettre d’aligner métier et technique » « Partager et

    aligner la compréhension du métier de l’application » 3ère étape : connaitre le métier du client
  27. Event Storming • Mis au point par Alberto Brandolini •

    Permet de modéliser les évènements qui se déroulent dans une application • Aide à créer une vision commune du métier • Prépare le découpage de l’application en ensembles métiers cohérents • Est d’une grande aide dans le cadre du DDD, et d’application en event sourcing (sans que ça soit obligatoire)
  28. Évènement métier Ne pas confondre avec un process Commande Origine

    de l’évènement L’utilisateur qui en est à l’origine
  29. Modèle de lecture
 (vue) Ce qui sera « rendu »

    au client Règle A chaque fois que…
  30. Un système externe Une action utilisateur Une règle Un évènement

    métier 
 a comme origine : Le temps…
  31. Organiser les éléments par contextes métiers

  32. Vision d’ensemble et temporalité du projet

  33. « Quoi développer dans quel ordre » « Conserver une

    vision d’ensemble du projet » 4ère étape : Le temps
  34. User Story Mapping • Créé par Jeff Patton • Permet

    de créer une vision d’ensemble à plusieurs dimensions du projet • Aide au découpage en « lots » fonctionnels et l’extraction d’un vrai MVP • Evite les backlogs illisibles, permet à l’équipe de ne pas se perdre dans le détail de celui-ci
  35. Activité : quelqu’un utilise le logiciel pour… Étapes pour mener

    à bien cette activité
  36. Détails (fonctions) de l’étape Parcours de l’utilisateur dans l’application

  37. Tout ce qui n’est pas INDISPENSABLE Le « squelette marchant

    » (MVP)
  38. None
  39. Voir si ça marche L’améliorer Version livrable

  40. Le fonctionnel Le temps

  41. Todo Doing Les cartes sont transférées dans le backlog de

    sprint Utilisation en association avec un Scrum/Kanban board
  42. Le mot de la (presque) fin • Les spécifications évoluent

    avec le temps, n’hésitez pas à refaire des ateliers de USM, ES ou IM pendant le projet • N’oubliez pas l’UX et l’ergonomie dans les spécifications (si possible par un profil spécialisé) !
  43. Contractualisation agile ?

  44. Forfait Régie Quelque part entre les deux ?

  45. Du forfait au sprint • Un contrat cadre pour l’ensemble

    du projet : prix journaliers, engagement de moyens, … • Une facturation au sprint (15j - 1 mois) avec un engagement sur le fonctionnel du sprint • Souvent un « starter » de 2 jours à une semaine pour cadrer la mission et préparer les premières spécifications
  46. Aller plus loin… • « Introducing EventStorming » — Alberto

    Brandolini • « Impact Mapping » — Gojko Adzic • « User Story Mapping » — Jeff Patton • « Software Architecture for Developers »— Simon Brown • « Living Documentation by design »— Cyrille Martraire
  47. Merci @lilobase