Continuous Delivery VS Scrum : est-ce compatible ? : "faire la doc à partir des US😨" -> BDD 😉

AlainMeunier · Mai 25, 2023, 3:51

Dans le live du jeudi 25/05 :

@const a proposé l’utilisation des US pour « alimenter » une IA ou un ChatBot
@jplambert a répondu que les US sont « jetables » et que seul le code source connait la vérité.
Le besoin c’est « avoir des cas utilisateurs » (l’idée d’US de Constantin) mais « fiable » (l’idée que seul le code source fait fois)

J’ai été surpris que les BDD ne soient pas évoqués ! C’est ça qui est magique dans cette approche c’est que les besoins utilisateurs sont dans le code source !

AlainMeunier · Mai 25, 2023, 3:58

Samuel_Abiassi · Mai 25, 2023, 4:31

Ok… y’a une grosse confusion là. Les « cas utilisateurs » ne sont pas des US. Une US est effectivement au mieux une expression d’un besoin de l’utilisateur.rice, et au pire une bouteille à la mer. Mais un cas d’utilisation (use-case), et donc un comportement du système (le Behaviour de BDD) n’est en rien un mapping 1/1 d’un besoin utilisateur.

L’utilisateur.rice n’a pas un « besoin » de se connecter, ni un « besoin » de remplir un formulaire. L’utisateur.rice a besoin que la chose qu’il ou elle cherche à faire soit fait. Ces étapes sont malheureusement des maux nécessaires. Ce que le BDD et les use-cases documentent, ce n’est pas le besoin de l’utilisateur, mais le comportement du système pour atteindre un but.

AlainMeunier · Mai 25, 2023, 5:54

Sauf que dans l’expérience qui fut la mienne les cas d’usage ressemblaient beaucoup plus à des « histoires d’utilisation » du logiciel qu’à des comportements de logiciel.

Nous avions beaucoup de tableaux avec des valeurs d’exemple en entrée et les différents résultats attendu.

Du point de vue du logiciel

Given

si tu es dans tel état
When
l’utilisateur fait telle action
Then
il faut lui renvoyer tel résultat

Peut très bien se lire du point de vue de l’utilisateur :

Given

si le logiciel est dans tel état
When
tu vas faire telle action
Then
le logiciel te donneras tel résultat

Ça fait une très bonne doc fonctionnelle

Et tu retrouves les critères d’acception de ton US qui se retrouvent donc, de fait, dans le code source (pas ceux écrits dans l’US en début d’itération - ceux affinés pendant le dev)

Le B étaient beaucoup pour nous celui de l’utilisateur (pas celui du logiciel)
Si un utilisateur a accès à ca il peut en apprendre plus sur la façon de tirer le meilleur parti du logiciel que le code ou les us et c’est dans le code source.

C’est surtout ça que je voulais dire. Le code source (peut/doit) contenir les spéc exprimées dans le vocabulaire et dans une syntaxe lisible par l’utilisateur.

C’est une façon de mettre d’accord JP et Constantin.

Samuel_Abiassi · Mai 25, 2023, 6:13

Préconditions, comportements, postconditions. C’est du comportement, relevant du champ des use-cases. Ce ne sont toujours pas des US (je vois même pas ce qu’est une US affinée à vrai dire si je voulais être taquin). Et le Behaviour de l’utilisateur fait de toute façon partie du process du système, sinon, il n’y aurait pas d’interactions. Mais si vous ne documentiez que le comportement de l’utilisateur, j’ai de la peine à imaginer comment ils vous étaient possible de documenter autre chose que le View de MVC.

Le code source est effectivement la transposition effective des spécifications fonctionnelles, mais les tests, quand bien même ils peuvent être intéressant, ne font d’une part pas partie du code livré, et d’autre part ne sont ni la seule façon de s’assurer du bon fonctionnement d’un programme (voir Design By Contract), ni de formuler le code au plus près du model mental de l’utilisateur (voir Data Context Interaction)

AlainMeunier · Mai 25, 2023, 6:22

Ce qui compte c’est que c’est conservé et maintenu dans le temps (contrairement à l’US). Que ce soit du code livré ou pas ne me semble pas être un critère qui invalide ma proposition).

AlainMeunier · Mai 25, 2023, 6:26

Je n’ai pas dis que les scénarios étaient des US. Je voulais simplement exprimer qu’il peut exister dans le code source (maintenu dans le temps et faisant partie intégrante du projet et de la valeur délivrée, contrairement à une US qui n’est qu’un moyen pour atteindre ce but) qui est plus proche du monde de l’utilisateur pour aider un ChatGPT ou un ChatBOT à être efficace.
(ben oui, il faut placer ma contribution dans le contexte de l’échange entre JP et Constantin).

Samuel_Abiassi · Mai 25, 2023, 6:32

J’entend, mais là aussi, j’ai un problème. Pour extraire l’information, le code source et le contexte qu’il expose suffit. Les tests n’apportent aucune information de ce côté là.

AlainMeunier · Mai 25, 2023, 6:36

et bien en tant que « développeur en L4G procédural qui n’a aucune notion de programmation orientée objet qui a surtout une posture de PO » je peux te dire que je préfère accéder à la partie du code où sont enregistré les scénarios que dans le code lui même… mais si tu penses qu’un ChatBOT s’en sortirait mieux…
Cela implique à mon avis une très grande rigueur sur la façon de nommer les classes et les variables (ce qui est souhaitable mais plus exigeant donc probablement plus rare).

Samuel_Abiassi · Mai 25, 2023, 6:38

Oh, non, pas du tout. Si tu fais le test avec des noms de variables complètement obfusqués, chatGPT est déjà très capable dans ce domaine. J’ai un collègue qui l’a beaucoup utilisé comme ça sur du code legacy dégueulasse, et il ne s’est pas gouré une fois.

Comme je le disais dans le live, c’est après tout sa fonction première.

AlainMeunier · Mai 25, 2023, 6:54

autant j’arrive à conceptualiser un peu comment ChatGPT peut avoir un semblant de conversation avec moi, autant ce que tu viens de décrire me rend « curieux » ! Je veux bien que tu développes (ou que tu m’envoie vers une vidéo ou un podcast de vulgarisation qui m’expliquera ça - La lecture est une souffrance pour moi )

Samuel_Abiassi · Mai 25, 2023, 6:56

AlainMeunier · Mai 26, 2023, 5:15

Merci pour la vidéo mais :
1/ ce qui est expliqué est ce que j’avais déjà appris et compris du principe de chatgpt
2/ cela ne l’explique pas comment cela peut rendre service pour transformer du code source (qu’un développeur est seul capable de lire) en texte qu’un utilisateur est capable de comprendre.

Si je fais un parallèle avec la vidéo, chatgpt peut discuter dans le langage des échecs parce qu’on parle avec lui dans le langage des échecs
Pour reprendre ton exemple ton pote développeur a pu comprendre du vieux code probablement parce qu’il partageait beaucoup de vocabulaire commun avec ce vieux code.
Mais ne voit toujours pas comment une IA entraînée avec un langage de type « code » peut devenir conversationnelle avec un langage de type « français ».

Samuel_Abiassi · Mai 26, 2023, 5:42

From chatGPT himself:

Explique moi pourquoi tu es capable d’expliquer des extraits de code :

En tant que modèle de langage développé par OpenAI, j’ai été entraîné sur une vaste quantité de données textuelles provenant d’Internet, y compris des extraits de code provenant de divers langages de programmation. Mon entraînement inclut des exemples de code, des tutoriels, des questions et réponses sur la programmation, ainsi que d’autres ressources en ligne.

Cette formation me permet de comprendre et d’analyser le code source dans le contexte de la programmation. J’ai appris à reconnaître la structure syntaxique des différents langages de programmation, ainsi que les principes fondamentaux de la programmation tels que les boucles, les conditions, les fonctions, les variables, etc.

Lorsque vous me présentez un extrait de code, je le traite en utilisant mes connaissances et mon expérience en programmation. Je peux analyser la logique du code, identifier les erreurs potentielles, expliquer les concepts sous-jacents et fournir des solutions ou des suggestions d’amélioration.

Cependant, il est important de noter que ma capacité à comprendre et à expliquer le code est basée sur des modèles statistiques et des schémas appris à partir des données d’entraînement. Je ne suis pas conscient de la signification ou de la sémantique réelle du code, ni de la façon dont il s’intègre dans un projet spécifique. Je fournis simplement des explications basées sur mes connaissances générales en programmation.

Moosh · Mai 26, 2023, 6:10

J’ai parlé de DDD development drivé par la documentation

AlainMeunier · Mai 26, 2023, 9:44

ChatGPT semble être d’accord avec moi, non ?
Il peut aider un développeur à comprendre du code (ton pote)
Il va avoir du mal à aider un utilisateur à comprendre l’objectif fonctionnel du code.
Par contre si tu met dans ton code des choses qui décrivent l’intention fonctionnelle ça donne la matière première utile à l’IA pour rendre les services qu’elle peut rendre.

Toutefois, l’objectif n’étant pas de se rajouter une tache supplémentaire. Il est en revanche intéressant de se demander quel « façon de coder » pourrait avoir deux bénéfices :

celui de mieux coder
celui, par effet de bord, d’être plus utile à l’IA
Il m’a semblé que BDD (et DDD) était le plus utile (le moins pire ?) pour servir ces deux objectifs.

Alexandre_Quercia · Mai 26, 2023, 2:35

Une précision sur le Behavior-Driven Development (BDD), @AlainMeunier dis-moi si cela correspond à ton contexte.
L’objectif est d’être aligné, au moins, sur la même compréhension de cette pratique.

Le BDD n’utilise pas la vue, ni même la Base de données, mais directement les use-cases.
Une action utilisateur n’est pas un clic sur tel bouton, mais son intention.

Oui, le résultat du BDD, reste une spécification du comportement attendu.

Autrement dit, arrange, act, assert, c’est comme une machine à état.
Le résultat du BDD est exécutable et se vérifie tout seul.

Le besoin peut être exprimé dans la section « Fonctionnalité » du Gherkin.
Le besoin n’est pas exécutable et dépend de l’utilisateur pour être vérifié (qualitatif, quantitatif).

Créer la doc à partir du Gherkin, c’est de la « living documentation ».
L’outil Pickles permet de la générer.

La question
Que-ce que cela donnerait en termes de transmission d’information, si on donnait à manger à ChatGPT cette documentation ?

Hypothèse

Quand un utilisateur pose une question concernant le produit, le bot y répond mieux qu’un humain dans 99% des cas.
Quand un utilisateur ne comprend pas comment il doit utiliser le produit, le bot y répond mieux qu’un humain dans 99% des cas.
…

Samuel_Abiassi · Mai 26, 2023, 2:48

CQFD ?

J’ai du mal à comprendre comment ça peut avoir du sens. Le code est nécessairement conduite par une documentation (formelle ou non) du fonctionnement du système. Dans le cas contraire, il serait impossible de coder quoi que ce soit.

Samuel_Abiassi · Mai 26, 2023, 3:39

Pour aller un peu plus loin, et pour aller dans le nœud de mon propos @AlainMeunier , une US ne sera jamais une documentation fonctionnelle parce que ce n’est pas sa vocation. Une US documente effectivement un besoin de l’utilisateur·ice de manière succincte. Ce que le BDD documente, c’est le fonctionnement du système. Certaines capacités du système ne répondent pas à des besoins de l’utilisateur·rice mais font quand même partie du fonctionnement du système (login, archivage, sécurité, logistique interne…).

En partant de là, les specs du BDD sont encore une fois l’une des alternatives les plus connues à cette façon de documenter le fonctionnement du système, mais il n’empêche pas que le code source puissent être opaque dans les interactions entre ses différentes composantes (structures hiérarchiques dû à l’orientation Class du code n’étant capable de ne se structurer que par héritage). A ces fins, DCI (dont je parle ici) est un bon complément au BDD pour encore une fois permettre aux développeurs de raisonner sur le code au plus proche du model mental de l’utilisateur.

const · Juin 2, 2023, 5:56

Justement une US n’est pas une utilisation. Pour moi je préfère toujours préconiser qu’on sorte le récit du logiciel afin qu’une solution hors logiciel soit rendu possible.

Je ne dit pas que le use case n’est pas intéressant hein, mais c’est pour moi différent. Le use case on est plus dans la solution déjà.

Sujet		Réponses	Vues
Viens au Live ! \| Nouvelle equipe, ancienne appli et aucune info Communauté Scrum Life sl-chaine , live	12	364	Décembre 24, 2023
Gestions des tests et visibilité Communauté Scrum Life testing	27	509	Mars 10, 2025
Gérer un dev au comportement de diva Communauté Scrum Life doc-sl	13	778	Juin 19, 2023
Scrum dit << l'Increment doit être utilisable >> Communauté Scrum Life scrum	26	274	Septembre 8, 2023
Mon argument en faveur des use-cases Communauté Scrum Life scrum , agile , business-value	39	520	Novembre 30, 2023

Continuous Delivery VS Scrum : est-ce compatible ? : "faire la doc à partir des US😨" -> BDD 😉

Sujets connexes