$30 off During Our Annual Pro Sale. View Details »

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 !

Arnaud LEMAIRE
PRO

September 23, 2016
Tweet

More Decks by Arnaud LEMAIRE

Other Decks in Programming

Transcript

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

    www.arpinum.fr

    View Slide

  2. View Slide

  3. -Edward Berard
    « Walking on water and developing software
    from a specification are easy 

    if both are frozen. »

    View Slide

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

    View Slide

  5. View Slide

  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

    View Slide

  7. Mais aussi…
    « Du téléphone arabe Enterprise Edition™ »
    Utilisateur final DSI Client MOA
    AMOA
    MOE
    Développeurs

    View Slide

  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 »

    View Slide

  9. avalanche driven development

    View Slide

  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. »

    View Slide

  11. Ce que les Spécifications ne sont pas
    Description du problème métier du client
    Description de la solution (produit fini)

    View Slide

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

    View Slide

  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 »

    View Slide

  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 »

    View Slide

  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

    View Slide

  16. Spécifications
    Développement
    Just Enough Design Up Front
    Spécifications Développement
    Big Design Up Front

    View Slide

  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

    View Slide

  18. Quel est le problème du client ?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  24. Quelle est la meilleure solution au problème ?

    View Slide

  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

    View Slide

  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

    View Slide

  27. Impact mapping
    pourquoi
    Qui
    Qui
    Comment
    Comment
    Quoi
    Quoi
    Le problème
    Une solution

    View Slide

  28. exemple tiré du projet Eventrix (eventrix.co) par Mozaic Work (mozaicworks.com)

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  32. Quel est le contexte métier de l’application ?

    View Slide

  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

    View Slide

  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)

    View Slide

  35. Évènement
    métier
    Ne pas confondre
    avec un process
    Commande
    Origine de
    l’évènement
    L’utilisateur qui en
    est à l’origine

    View Slide

  36. Modèle de
    lecture

    (vue) Ce qui sera
    « rendu » au client
    Règle
    A chaque fois
    que…

    View Slide

  37. Un système externe
    Une action
    utilisateur
    Une règle
    Un évènement métier 

    a comme origine :
    Le temps…

    View Slide

  38. Organiser les éléments par contextes métiers

    View Slide

  39. View Slide

  40. Vision d’ensemble et temporalité du projet

    View Slide

  41. « Quoi développer dans quel ordre »
    « Conserver une vision d’ensemble du projet »
    4ère étape : Le temps

    View Slide

  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

    View Slide

  43. Activité : quelqu’un utilise le
    logiciel pour…
    Étapes pour mener à bien
    cette activité

    View Slide

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

    View Slide

  45. Tout ce qui n’est pas
    INDISPENSABLE
    Le « squelette marchant »
    (MVP)

    View Slide

  46. View Slide

  47. Voir si ça marche
    L’améliorer
    Version livrable

    View Slide

  48. Le fonctionnel
    Le temps

    View Slide

  49. Todo Doing
    Les cartes sont transférées
    dans le backlog de sprint
    Utilisation en association avec un Scrum/Kanban board

    View Slide

  50. Quand est ce qu’on mets à jour les
    spécifications ?

    View Slide

  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

    View Slide

  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

    View Slide

  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é) !

    View Slide

  54. Contractualisation agile ?

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  58. Merci @lilobase
    www.arpinum.fr

    View Slide