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 !

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