Totalement d'accord avec toi. Dans mon passé de développeur électronique dans les Telecoms, j'ai jamais vu 1 client en amont du projet Par contre, on a passé des semaines en validation avec le client pour rectifier le code, soit pour de l UX soit pour des fonctionnalités mal comprises. C'était il y a 30 ans..... Toujours un plaisir de suivre des postes et tes videos
Je me demande toujours pourquoi on n'apprend pas cela dans nos études d'informatique, et pourquoi on est toujours obligés de tout cloisonner à chaque fois. Je comprends mieux maintenant ce qu'est le BDD, merci pour la vidéo. J'irais lire le blog que tu recommandes. Tu dis des choses vraiment sensées, mais je sais qu'en tant que développeur junior, je ne pourrais jamais arriver en entreprise et dire : 'Hey, j'ai trouvé une vidéo géniale sur internet, cela pourrait être intéressant de s'y intéresser, non ?'. Les sociétés et les personnes n'aiment pas changer leurs habitudes. Rien qu'évoquer et promouvoir du changement dans une société, c'est prendre un risque, et je le dis en conséquence. Aujourd'hui, je préfère écouter et me taire ^^ C'est là que l'on se rend compte qu'en tant que junior, débutant, on ne fait pas vraiment partie de l'équipe, car la participation consiste juste à effectuer les tâches que l'on nous a assignées. Sur les fiches de poste, on se rend compte de la standardisation des fiches de postes écrites par des personnes ne comprenant le sens même des mots inscrits. En l'occurrence, la phrase "force de proposition" n'a aucune valeur quand on s'attend à ce qu'un débutant ne puisse donner son avis et proposer car il manque trop d'expérience 😅. Un jour, j'ai dit à un RH que la transmission du savoir était importante dans une équipe de développement, surtout à la phase d'intégration pour se familiariser le plus rapidement possible au projet pour que les nouveaux entrants deviennent le plus rapidement autonome. Il m'a dit "Ah, vous avez besoin d'accompagnement".... Je n'ai rien dit, mais je me suis rendu compte que les meilleurs recruteurs ne peuvent pas être des RH, mais des personnes passionnées par le développement ayant balancé leur égo dans les oubliettes. J'ai eu envie de cracher ma haine 🥵
On devrait faire du BDD dans tous les métiers en vrai. Dans le sens où on rassemble tout le monde et on discute. Je l'ai vécu dans une école (j'étais prof des écoles), ça changeait TOUT sur la manière dont on bossait. On réunissait de temps en temps tous ceux qui bossaient dans l'école (pas que les profs) + les représentants des parents d'élèves, et on incluait même parfois des enfants, qui avaient été élus dans leur classe.. Résultat on connaissait les besoins de tout le monde et je suis certaine qu'on a évité des quiproquos catastrophiques. A côté j'ai aussi vu des écoles où les profs faisaient tout en mode défensive pour ne pas être em***és par les parents, "moins on les voit mieux on se porte" (et pourtant même type de public, c'étaient toutes des REP) : résultat ça se ressentait tellement sur le climat général, et l'état d'énervement des gamins... et il y avait tout le temps des soucis avec les parents, des plaintes à l'inspection et j'en passe. Et forcément ça ne donne pas envie de faire un pas les uns vers les autres quand on en est arrivés à ce degré d'hostilité. C'est le serpent qui se mord la queue. Bref, en conclusion, la communication est TOUJOURS la clé ! 🗝
Je suis curieux de savoir pourquoi Gherkin est dangereux ? J'adorerais une vidéo sur ce sujet. J'ai trouvé le couple Gherkin/Cucumber très utile pour avoir une single source of truth. Quel serait l'alternative ?
Pour ma part j’ai arrêté quand j’ai vu que l’ingénieur de test et même le PO (qui pourrait montrer aux clients) ne regardaient pas les rapports de tests cucumber. Si le support sert d’échange ça vaut le coup. Sinon un bon TDD orienté cas d’utilisation permet d’arriver au même résultat mais plus vite (pas de double boucle cucumber ATDD + TDD -> juste TDD)
c'est clairement pas dangereux, mais BDD n'est pas gherkin et l'inverse est vrai aussi Michael a raison, ce qui compte dans BDD c'est la conversation. D'ailleurs, l'Example Mapping est arrivé fin 2015 pour nous aider à être meilleurs dans BDD. ne pas se focaliser sur le gherkin mais sur l'exemple, la règle, pour mieux nous aider écrire un gherkin. le gherkin est le Compte Rendu de l'atelier 3 Amigos qui deviendra la doc vivante, mais on est pas là, en 3 Amigos pour écrire ensemble cette doc, il faut "juste" faire de l'Example Mapping pour illustrer les règles par des exemples pour être sûr que tout est claire et qu'il n'y a plus d'ambigüité possible
@@pierre-jeanmartin5621 j'ai une préférence pour faire du BDD first pour coder les critères d'acceptations, et après tu fais la phase de refactor en ajoutant des TU. ça ne peut pas être plus long que TDD et le gain est tellement supérieur. La réutilisation de steps, le gral : la documentation vivante autogénérée, collée au code et qui teste ce même code. le truc impossible depuis 30 ans avant le génie de Dan North
Hello, un top 5 des livres que tu recommandes pour un développeur ? J'ai un problème majeur : il y a énormément d'informations sur comment faire des choses, mais plus rarement sur comment le faire correctement. Comment réaliser un code qualitatif. Si tu as un top 5 (ou +) de "bonnes pratiques" de codage (architecture et tests du code, même en terme de gestion de projet) ça serait top ! Merci et bonne soirée :)
Au bout de 10 ans d'expériences, le constat est une chaine de mépris. Le PO méprise le client final, le dév a du mépris pour le PO, le testeur a du mépris pour le dév et au final le client méprise le produit fournit. J'espère que l'IA mettra fin à ce métier un jour.
Faut pas penser comme ça... Et essayer d'apporter des ondes positives aux projets. On est tous là pour avoir un projet qualitatif et qui marche en bout de course. Travailler ensemble et réussir y'a rien de plus gratifiant.
En effet ! Je suis totalement aligné, on prêche la même chose ici.
-- JP
Chapeau merci pour cette approche très pertinente
Excellent format, tu devrais en faire plus souvent.
Merci, j’en ferai d’autres !
Merci pour le shout-out ☺
From linkedin to RUclips :)
Totalement d'accord avec toi.
Dans mon passé de développeur électronique dans les Telecoms, j'ai jamais vu 1 client en amont du projet
Par contre, on a passé des semaines en validation avec le client pour rectifier le code, soit pour de l UX soit pour des fonctionnalités mal comprises. C'était il y a 30 ans.....
Toujours un plaisir de suivre des postes et tes videos
Master 🙌
Le développeur pense if-else toute sa vie 😂. Merci pour la vidéo et je la partage au max
merci :)
top, chapeau
Je me demande toujours pourquoi on n'apprend pas cela dans nos études d'informatique, et pourquoi on est toujours obligés de tout cloisonner à chaque fois. Je comprends mieux maintenant ce qu'est le BDD, merci pour la vidéo. J'irais lire le blog que tu recommandes. Tu dis des choses vraiment sensées, mais je sais qu'en tant que développeur junior, je ne pourrais jamais arriver en entreprise et dire : 'Hey, j'ai trouvé une vidéo géniale sur internet, cela pourrait être intéressant de s'y intéresser, non ?'. Les sociétés et les personnes n'aiment pas changer leurs habitudes. Rien qu'évoquer et promouvoir du changement dans une société, c'est prendre un risque, et je le dis en conséquence. Aujourd'hui, je préfère écouter et me taire ^^ C'est là que l'on se rend compte qu'en tant que junior, débutant, on ne fait pas vraiment partie de l'équipe, car la participation consiste juste à effectuer les tâches que l'on nous a assignées. Sur les fiches de poste, on se rend compte de la standardisation des fiches de postes écrites par des personnes ne comprenant le sens même des mots inscrits. En l'occurrence, la phrase "force de proposition" n'a aucune valeur quand on s'attend à ce qu'un débutant ne puisse donner son avis et proposer car il manque trop d'expérience 😅. Un jour, j'ai dit à un RH que la transmission du savoir était importante dans une équipe de développement, surtout à la phase d'intégration pour se familiariser le plus rapidement possible au projet pour que les nouveaux entrants deviennent le plus rapidement autonome. Il m'a dit "Ah, vous avez besoin d'accompagnement".... Je n'ai rien dit, mais je me suis rendu compte que les meilleurs recruteurs ne peuvent pas être des RH, mais des personnes passionnées par le développement ayant balancé leur égo dans les oubliettes. J'ai eu envie de cracher ma haine 🥵
Carré
Trop drôle cette vidéo, le développeur if else et le PO qui pense à rien !
On devrait faire du BDD dans tous les métiers en vrai. Dans le sens où on rassemble tout le monde et on discute. Je l'ai vécu dans une école (j'étais prof des écoles), ça changeait TOUT sur la manière dont on bossait. On réunissait de temps en temps tous ceux qui bossaient dans l'école (pas que les profs) + les représentants des parents d'élèves, et on incluait même parfois des enfants, qui avaient été élus dans leur classe.. Résultat on connaissait les besoins de tout le monde et je suis certaine qu'on a évité des quiproquos catastrophiques.
A côté j'ai aussi vu des écoles où les profs faisaient tout en mode défensive pour ne pas être em***és par les parents, "moins on les voit mieux on se porte" (et pourtant même type de public, c'étaient toutes des REP) : résultat ça se ressentait tellement sur le climat général, et l'état d'énervement des gamins... et il y avait tout le temps des soucis avec les parents, des plaintes à l'inspection et j'en passe. Et forcément ça ne donne pas envie de faire un pas les uns vers les autres quand on en est arrivés à ce degré d'hostilité. C'est le serpent qui se mord la queue. Bref, en conclusion, la communication est TOUJOURS la clé ! 🗝
Amen: c'est bien de le rappeler car c'est dommage de voir des cas où les US sont piloter sans agilité.
Tu dis ne plus utiliser Gherkin. Peux-tu développer STP ? Merci !
Excellent
Je suis curieux de savoir pourquoi Gherkin est dangereux ? J'adorerais une vidéo sur ce sujet.
J'ai trouvé le couple Gherkin/Cucumber très utile pour avoir une single source of truth. Quel serait l'alternative ?
Pour ma part j’ai arrêté quand j’ai vu que l’ingénieur de test et même le PO (qui pourrait montrer aux clients) ne regardaient pas les rapports de tests cucumber. Si le support sert d’échange ça vaut le coup. Sinon un bon TDD orienté cas d’utilisation permet d’arriver au même résultat mais plus vite (pas de double boucle cucumber ATDD + TDD -> juste TDD)
c'est clairement pas dangereux, mais BDD n'est pas gherkin et l'inverse est vrai aussi
Michael a raison, ce qui compte dans BDD c'est la conversation. D'ailleurs, l'Example Mapping est arrivé fin 2015 pour nous aider à être meilleurs dans BDD. ne pas se focaliser sur le gherkin mais sur l'exemple, la règle, pour mieux nous aider écrire un gherkin. le gherkin est le Compte Rendu de l'atelier 3 Amigos qui deviendra la doc vivante, mais on est pas là, en 3 Amigos pour écrire ensemble cette doc, il faut "juste" faire de l'Example Mapping pour illustrer les règles par des exemples pour être sûr que tout est claire et qu'il n'y a plus d'ambigüité possible
@@pierre-jeanmartin5621 j'ai une préférence pour faire du BDD first pour coder les critères d'acceptations, et après tu fais la phase de refactor en ajoutant des TU. ça ne peut pas être plus long que TDD et le gain est tellement supérieur. La réutilisation de steps, le gral : la documentation vivante autogénérée, collée au code et qui teste ce même code. le truc impossible depuis 30 ans avant le génie de Dan North
Hello, un top 5 des livres que tu recommandes pour un développeur ? J'ai un problème majeur : il y a énormément d'informations sur comment faire des choses, mais plus rarement sur comment le faire correctement. Comment réaliser un code qualitatif. Si tu as un top 5 (ou +) de "bonnes pratiques" de codage (architecture et tests du code, même en terme de gestion de projet) ça serait top ! Merci et bonne soirée :)
Clean Code d’Uncle Bob et Implementing Domain-Driven Design de Vaughn Vernon
Au bout de 10 ans d'expériences, le constat est une chaine de mépris. Le PO méprise le client final, le dév a du mépris pour le PO, le testeur a du mépris pour le dév et au final le client méprise le produit fournit. J'espère que l'IA mettra fin à ce métier un jour.
Faut pas penser comme ça... Et essayer d'apporter des ondes positives aux projets. On est tous là pour avoir un projet qualitatif et qui marche en bout de course. Travailler ensemble et réussir y'a rien de plus gratifiant.
Hello, possible qu'on se soit déjà croisé à Bruxelles ? (Je bossais pour la société Boxify avec Ilan)
Ah non malheureusement je n’ai jamais mis les pieds en Belgique
Nice talk
merci
Gherkin dangerous ?
It would deserve a separated video
From linkedin to RUclips :)