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 !

Transcript

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 ?
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
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)
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