Spécifications en milieu agile - BreizhCamp 2016

La question de savoir quoi faire reste un élément central de notre industrie !
Mais comment associer spécifications fonctionnelles et techniques avec les méthodologies agiles ? Comment permettre au client de garder une vision d'ensemble sans être noyé sous le détail ?

En étudiant 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
4. Qu’est ce que des spécifications agiles ?
5. Problème métier du client Solution (produit fini) Spécifications
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
8. 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
9. 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 »
10. 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 »
11. Spécifications Développement Just Enough Design Up Front Spécifications Développement Big Design Up Front
12. 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
13. Quel est le problème du client ?
14. « 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
15. 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
16. 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
17. 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
18. 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
19. Quelle est la meilleure solution au problème ?
20. « Eviter de construire quelque chose qui ne correspond pas au besoin du client » « Chercher à obtenir le meilleur retour sur investissement pour le client » 2ère étape : découvrir la solution qui maximise l’impact pour le client
21. 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
22. Impact mapping pourquoi Qui Qui Comment Comment Quoi Quoi Le problème Une solution
23. 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
24. 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
25. Quel est le contexte métier de l’application ?
26. « Permettre d’aligner métier et technique » « Partager et aligner la compréhension du métier de l’application » 3ère étape : connaitre le métier du client
27. 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)
28. Évènement métier Ne pas confondre avec un process Commande Origine de l’évènement L’utilisateur qui en est à l’origine
29. Modèle de lecture
 (vue) Ce qui sera « rendu » au client Règle A chaque fois que…
30. Un système externe Une action utilisateur Une règle Un évènement métier 
 a comme origine : Le temps…
31. Organiser les éléments par contextes métiers
32. Vision d’ensemble et temporalité du projet
33. « Quoi développer dans quel ordre » « Conserver une vision d’ensemble du projet » 4ère étape : Le temps
34. 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
35. Activité : quelqu’un utilise le logiciel pour… Étapes pour mener à bien cette activité
36. Détails (fonctions) de l’étape Parcours de l’utilisateur dans l’application
37. Tout ce qui n’est pas INDISPENSABLE Le « squelette marchant » (MVP)
39. Voir si ça marche L’améliorer Version livrable
40. Le fonctionnel Le temps
41. Todo Doing Les cartes sont transférées dans le backlog de sprint Utilisation en association avec un Scrum/Kanban board
42. Le mot de la (presque) fin • 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é) !
43. Contractualisation agile ?
44. Forfait Régie Quelque part entre les deux ?
45. Du forfait au sprint • Un contrat cadre pour l’ensemble du projet : prix journaliers, engagement de moyens, … • Une facturation 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 premières spécifications
46. 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
47. Merci @lilobase