Le Behaviour-Driven Development alias BDD, ce n'est pas ce que vous croyez ! - Michaël AZERHAD

J'explique dans cette vidéo le quiproquo autour de BDD et illustre son essence à travers un exemple concret.

Пікірлер: 31

  • @ScrumLife
    @ScrumLife2 жыл бұрын

    En effet ! Je suis totalement aligné, on prêche la même chose ici. -- JP

  • 2 жыл бұрын

    From linkedin to KZread :)

  • @rastafadev
    @rastafadev Жыл бұрын

    Chapeau merci pour cette approche très pertinente

  • @lunivore-yt
    @lunivore-yt5 ай бұрын

    Merci pour le shout-out ☺

  • @louis_korczowski
    @louis_korczowski2 жыл бұрын

    Excellent format, tu devrais en faire plus souvent.

  • @wealcome_company

    @wealcome_company

    2 жыл бұрын

    Merci, j’en ferai d’autres !

  • @michellapalus5284
    @michellapalus52842 жыл бұрын

    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

  • @zaelyndra744
    @zaelyndra7447 ай бұрын

    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 🥵

  • @khalil5100
    @khalil5100 Жыл бұрын

    top, chapeau

  • @sebastienmace8470
    @sebastienmace84704 ай бұрын

    Tu dis ne plus utiliser Gherkin. Peux-tu développer STP ? Merci !

  • @laurelineparis5407
    @laurelineparis54072 жыл бұрын

    Amen: c'est bien de le rappeler car c'est dommage de voir des cas où les US sont piloter sans agilité.

  • @KiKofbeats
    @KiKofbeats Жыл бұрын

    Carré

  • @WhatTheGuiz
    @WhatTheGuiz Жыл бұрын

    Excellent

  • @josuembiyavanga2197
    @josuembiyavanga21972 жыл бұрын

    Le développeur pense if-else toute sa vie 😂. Merci pour la vidéo et je la partage au max

  • @wealcome_company

    @wealcome_company

    2 жыл бұрын

    merci :)

  • @sebgendt347
    @sebgendt3472 жыл бұрын

    Trop drôle cette vidéo, le développeur if else et le PO qui pense à rien !

  • @adelineiscoding
    @adelineiscoding10 ай бұрын

    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é ! 🗝

  • @apothicaris3770
    @apothicaris37702 жыл бұрын

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

  • @wealcome_company

    @wealcome_company

    Жыл бұрын

    Clean Code d’Uncle Bob et Implementing Domain-Driven Design de Vaughn Vernon

  • @Bakitto390
    @Bakitto3902 жыл бұрын

    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 ?

  • @pierre-jeanmartin5621

    @pierre-jeanmartin5621

    2 жыл бұрын

    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)

  • @TheLimande

    @TheLimande

    2 жыл бұрын

    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

  • @TheLimande

    @TheLimande

    2 жыл бұрын

    @@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

  • @walinkeio
    @walinkeio Жыл бұрын

    Hello, possible qu'on se soit déjà croisé à Bruxelles ? (Je bossais pour la société Boxify avec Ilan)

  • @wealcome_company

    @wealcome_company

    Жыл бұрын

    Ah non malheureusement je n’ai jamais mis les pieds en Belgique

  • @yannickg5788
    @yannickg57882 жыл бұрын

    Nice talk

  • @wealcome_company

    @wealcome_company

    2 жыл бұрын

    merci

  • @bikotchotcho8262
    @bikotchotcho8262 Жыл бұрын

    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.

  • @rastafadev

    @rastafadev

    Жыл бұрын

    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.

  • @makes5819
    @makes58192 жыл бұрын

    Gherkin dangerous ?

  • @wealcome_company

    @wealcome_company

    Жыл бұрын

    It would deserve a separated video