Christophe Gesché vous invite à une réunion Zoom planifiée.
Sujet : Libre antenne 18/07
Heure : 18 juil. 2023 01:30 PM Bruxelles
Participer à la réunion Zoom
https://us04web.zoom.us/j/74904920636?pwd=YM4PgboLbfZPeZvxqEgatvFars9t01.1
ID de réunion : 749 0492 0636
Code secret : grandsfans
Ajouter à
Google Agenda - Calendrier Outlook (.ics) - Calendrier Yahoo
C’est le lendemain de mon anniv’ \o/
Joli ! Moi c’est le 21 
Et moi le 13 ! On est tous né en juillet ?!? 
Merci aux participants.
Pendant cette libre antenne, @Samuel_Abiassi a présenté les Uses Cases.
N’hésitez pas à poster vos questions, remonter votre feedback sur la présentation ou sur l’évènement
Voici le contenu du chat :
Question (pour après)
Selon vous, doit-on, et si oui comment , différencier Use Case et Test Case ? Est-ce que le Use-case est un Test Case d’un des différent niveaux de test
Question sur la présa: quel est là US de cette présa ?
En tant que Sam avec ma casquette de …
Je veux que mon audience comprenne que ….
Afin que ….
flux nominal = Golden path ?
Quels liens faire avec le Story mapping ?
ou example mapping
Je suis frustré x) J’aurais bien aimé avoir plus de temps.
Quelques points en plus :
C’est important que les flux soient exprimés en prose. Un schéma saura jamais faire transparaitre les subtilités que le langage peut avoir.
Le document, formellement, c’est un texte qui tiens généralement en une page ou deux pour les use-cases les plus simples. Pour les plus complexes, rien n’empêche de créer des sous use-cases si ils sont pertinents en termes de réutilisation (un peu comme du refacto en dev).
Je voulais rentrer un peu plus en détail dessus, mais pour faire écho à la vidéo sur Conway d’il y a peu, sa loi se vérifie pas uniquement au niveau de l’organisation mais surtout au niveau des moyens de communication de cette dernière. Un document comme un Use-Case va induire des comportements et des architectures de code mécaniquement, grâce à sa nature. A priori, une équipe qui utilisera des Use-Cases arrivera bien plus facilement à du Behaviour Driven Dev, parce que le document aide à cela. De même, des assertions essentiels pour le Use-Case vont être faites en amont grâce aux préconditions, chose qui est beaucoup moins induite quand la règle métier se trouve dans un fatras d’autres règles à implémenter.
Difficile à répondre à ça dans le sens où je ne sais pas ce qui est entendu en tant que Test-Case formellement. Mais comme je le disais, si quelque chose est à tester à la fin d’un Use-Case, ce sont les post-conditions (quasiment des critères d’acceptances au final) qui vont permettre de savoir à quoi doit absolument ressembler le système et les acteurs à la fin du Use-Case.
En tant que Sam avec ma casquette de contributeur à la communauté Scrum Life
Je veux que mon audience comprenne que les Use-Cases sont un outil utile aux équipes agiles dans leur exploration du domaine du problème et de la formalisation des specs fonctionnelles
Afin que leurs équipes se trouvent moins démunies arrivé au sprint planning 
Voir mon commentaire plus haut sur la nécessité d’exprimer les flux en prose et pas en diagramme.
On peut voir ça comme ça.
Tu vas potentiellement inférer tes Use-Cases des story mapping dans le sens où tu scénarises les intéractions entre les différents acteurs. C’est la moitié du boulot de fait.
Merci Sam pour cette présentation, je pense que tu n’as pas pu aller jusqu’au bout alors voici mes remarques et mes questions :
1- Est-ce que les use-cases ne sont écrits que par le PO ?
Si oui, je comprends ta réflexion dans un autre sujet où tu demandes à ce que le PO soit un expert du domaine. Il me semble que le PO doit vraiment explorer voire peut-être un peu trop s’il n’a pas de casquette technique.
Si non, utilises-tu les example mapping ‹ 3 amigos › pour cela ? Et avec qui ?
2- Penses-tu que des use-cases soient utiles pour chaque US ?
L’exemple que tu nous a présenté était orienté plutôt IT puisque l’on parlait d’interconnexion entre systèmes, mais quand on doit réaliser une interface de type ‹ vue ›, un formulaire, le format me semble très « lourd » et peu sujet à propositions de la part de l’équipe de réalisation.
3- T’arrêtes-tu parfois à des use-cases non rafinés ?
En effet, pour rejoindre le point précédent, trop écrire peut parfois être soit rébarbatif pour les développeurs (donc un peu inutile), soit trop prescriptif (j’ai fait ce que l’on m’a demandé)
Pour développé mon point de vue, j’avais au début de ma vie de PO un peu la même approche que toi, mais en revue de sprint on avait souvent les retours des devs : « Ah ben non, on n’a pas fait comme ça, effectivement ça semble logique, mais en fait c’était pas écrit dans la spec »
PS: si vous vous êtes senti lésé sur le « pourquoi » du document, c’est normal. J’avais fais la présentation en deux temps à l’époque, et cette prez était plus sur la partie pratique de la chose.
Non, comme je le disais, les Use-cases techniques seront bien plus souvent exprimés par un dev que par le PO. Mais là où je vais aller un peu plus loin dans mon explication, c’est que ce document est avant tout une méthode d’exploration du domaine du problème en équipe. Un use-case écrit seulement par le PO et qui n’a pas fait l’objet d’une discussion avec l’équipe de dev à autant de valeur qu’une US, à savoir un pense bête au mieux. Et pour l’exemple mapping, ma réponse du dessus devrait peut être éclairer le sujet.
Non. Par contre, tu te fais peut être une fausse idée sur la lourdeur du formalisme. Le flux nominal peut tenir en trois étape potentiellement. Ceci étant dis, je vois que tu parles de « vue », de « formulaire » et tout cela fait partie de l’espace de la solution et pas du problème, tu es déjà bien trop loin.
Non, puisqu’encore une fois, un use-case non raffiné est un use-case qui n’a pas fait l’objet d’une analyse claire avec l’équipe de dev. De là, dans ma DOR, ce genre de chose ne passe pas (huhuhu :p). Je veux que tout le monde soit aligné sur le problème et toutes ses implications. Du coup, pas de surprise de la part de l’équipe quand on bascule dans l’espace de la solution.
Il va falloir que tu nous parles de l’espace de la solution alors 
Pour aller plus loin sur ta question sur le ‹ formulaire ›, pour moi, pour le cas par exemple d’une inscription à un abonnement à une salle de sport, ça donnerait:
1 - Le futur abonné renseigne: nom, adresse, formule souhaitée au service d’inscription
2 - Le service d’inscription enregistre les informations et fait part au futur abonné de sa bonne prise en compte
3 - le futur abonné peut procéder au paiement de son abonnement (voir use-case Paiement d’abonnement)
Dans ce use-case, le fond des informations (leur nature) est clairement établi. Par contre la forme (formulaire, coup de fil, mail,…) ne l’est pas.
C’est un tout autre sujet, et pour ça, la « Living Documentation » de Cyril Martraire est plutôt alignée avec ma vision des choses.
Point de débat, parce que l’intérêt du schéma est de rendre moins subtil, moins ambigu, moins « sujet à interprétation » qu’une prose.
Le schéma est beaucoup plus binaire, carré que la prose.
Le Use Case donnant un cadre, on s’attend qu’il soit compris le plus uniformément de tous.
On a encore fait recement l’exercice.
Prendre un Schéma, demande à chacun de le transformer en prose.
Prendre une prose et demander d’en faire un schéma.
Résultat, à partir du même schéma, toutes les proses donnent le même résultat malgré des termes parfois différents
Alors que de la même prose, on se retrouvait avec des schémas bien différents.
J’ai envie de dire qu’on a donc 2 orientations.
Si on veut laisser de la marge de manœuvre, la prose est plus « descriptive » mais moins contraignante. Si on veut un cadre plus précis, le schéma est plus opportun, mais donnera le comment et non le « pourquoi/ pour quoi »
Petit point important sur ce sujet: Rien n’empêche de mettre un diagramme UML dans les infos complémentaires. MAIS : Les cas de récursions d’étapes, les conditions inter-étapes, les fluxs alternatifs rebouclant sur le principal… tout ça devient un enfer à matérialiser graphiquement mais très simple à faire en langage écrit. L’autre point aussi, c’est que les histoires, ça se retient mieux
