Spécifications en milieu agile - Agile Pays Basque 2016

Spécifications en milieu agile - Agile Pays Basque 2016

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

September 23, 2016
Tweet

Transcript

  1. Spécifications en milieu agile Arnaud LEMAIRE — @lilobase www.arpinum.fr

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

    a specification are easy 
 if both are frozen. »
  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. 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. »
  11. Ce que les Spécifications ne sont pas Description du problème

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

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

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

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

  25. « 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
  26. 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
  27. Impact mapping pourquoi Qui Qui Comment Comment Quoi Quoi Le

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

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

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

  33. « 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
  34. 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)
  35. Évènement métier Ne pas confondre avec un process Commande Origine

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

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

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

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

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

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

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

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

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

  48. Le fonctionnel Le temps

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

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

  51. 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
  52. 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
  53. 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é) !
  54. Contractualisation agile ?

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

  56. 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
  57. 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
  58. Merci @lilobase www.arpinum.fr