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

Spécifications en milieu agile - MIXIT 2017

Spécifications en milieu agile - MIXIT 2017

Les spécifications ont parfois mauvaise presse : trop rigides, peu adaptées, elles sont vécues comme un fardeau par les développeurs.

En face, les méthodologies agiles sont parfois accusées d'être trop dans le détail et d'empêcher la vision à long terme du projet.

Et s’il était possible d'associer spécifications fonctionnelles et techniques avec les méthodologies agiles pour associer vision à long terme et flexibilité ? En associant 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

April 21, 2017
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 www.arpinum.fr

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

  5. None
  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. Mais aussi… « Du téléphone arabe Enterprise Edition™ » Utilisateur

    final DSI Client MOA AMOA MOE Développeurs
  8. Heureusement l’agilité est arrivée • Individuals and interactions over processes

    and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan « plus besoin de spécifications »
  9. avalanche driven development

  10. Le meilleurs moyen « d’over-ingénierier » la solution Vous venez

    de complexifier le logiciel pour aucune valeur ajoutée ! Personne ne sait quoi faire On fait des choses « au cas où » Ça n’est pas la bonne solution En restant « générique »
  11. N’oubliez pas de lire le manifeste jusqu’au bout « That

    is, while there is value in the items on the right, we value the items on the left more. »
  12. Ce que les Spécifications ne sont pas Description du problème

    métier du client Description de la solution (produit fini)
  13. Finalement c’est quoi des Spécifications ? Problème métier du client

    Solution (produit fini) Spécifications
  14. 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 »
  15. 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 »
  16. 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
  17. Spécifications Développement Just Enough Design Up Front Spécifications Développement Big

    Design Up Front
  18. 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
  19. Quel est le problème du client ?

  20. « 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
  21. 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
  22. 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
  23. 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
  24. 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
  25. Quelle est la meilleure solution au problème ?

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

    au besoin du client » « Chercher à obtenir le meilleur retour sur investissement pour le client » 2ème étape : découvrir la solution qui maximise l’impact pour le client
  27. 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
  28. Impact mapping pourquoi Qui Qui Comment Comment Quoi Quoi Le

    problème Une solution
  29. exemple tiré du projet Eventrix (eventrix.co) par Mozaic Work (mozaicworks.com)

  30. exemple venant de Mozaic Work (mozaicworks.com)

  31. 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
  32. 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
  33. Quel est le contexte métier de l’application ?

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

    aligner la compréhension du métier de l’application » 3ème étape : connaitre le métier du client
  35. 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)
  36. Évènement métier Ne pas confondre avec un process Commande Origine

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

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

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

  40. None
  41. Vision d’ensemble et temporalité du projet

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

    vision d’ensemble du projet » 4ère étape : Le temps
  43. 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
  44. Activité : quelqu’un utilise le logiciel pour… Étapes pour mener

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

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

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

  49. Le fonctionnel Le temps

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

    sprint Utilisation en association avec un Scrum/Kanban board
  51. Quand est ce qu’on mets à jour les spécifications ?

  52. Des symptômes • Quand les rétrospectives / le planning game

    prennent trop de temps • Quand les termes métiers divergent • Quand un nouveau développeur arrive dans l’équipe
  53. Si on récapitule ? • Quelle est la meilleure solution

    au problème à un moment donné : Impact Mapping • Quel est le context métier de l’application : Event Storming • Vision d’ensemble et temporalité : User Story Mapping
  54. Le mot de la (presque) fin • Dès qu’il y

    a une divergence de compréhension / vision : refaite un atelier • Il est normal que 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é) !
  55. Contractualisation agile ?

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

  57. Un exemple • Un contrat cadre pour l’ensemble du projet

    : prix journaliers, engagement de moyens, … • Une facturation par bon de commande, 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 premiers ateliers
  58. 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
  59. Merci @lilobase www.arpinum.fr