Amen ! Je fais du TDD tous les jours sur un projet en architecture hexagonale. Ça a été dur au début, c'était une nouvelle manière de bosser et un nouveau pattern d'architecture, mais le gain derrière est énorme !!! C'est un investissement, clairement :). PS : il y a un coté satisfaisant à voir tous les tests passer au vert :D. Le gamer que je suis est content.
En phase. Dans notre projet on est allé plus loin avec le BDD et quasi que des test traversants (et quelques tests unitaires pour compléter les parties les plus technique). Après un an, 2900 scénarios de tests traversant, 280 tests unitaires, 100% de réussite à chaque build, avec un taux de couverture qui tend vers 93% depuis 8 mois. Pour les 7% restant, on se demande si les parties non couverte sont sujette à des risque de régression ou non. Pour la plupart de ces sujets, on se dit que faire de la couverture pour de la couverture nuirait à la lisibilité du projet. Pas de bugs en prod, aucune régression entre les versions. On commence même à arriver à un point où on se satisfait de retirer du code projet tout en ajoutant des features (merci aux refactos déjà couverte par les tests). Bref, l'investissement est énorme au départ, mais le gain à moyen/long terme est sans commune mesure. Si jamais un bug est détecté par les équipes de qualif (ça arrive aussi), identifier la source nous prend aussi très peu de temps car c'est soit une absence de specs en amont, soit un petit trou dans les scénarios de test, un cas à la marge auquel personne n'avait pensé.
Oui, cela fonctionne comme des investissements bancaires : au début, on a peu d'intérêts, puis ensuite on touche aussi des intérêts sur les intérêts gagnés, et progressivement ça s'accélère en boucle. J'en parlais lors de ma keynote à Agile Tour Montréal à propos de la notion de progrès : notre cerveau n'est pas câblé pour penser "exponentiel", résultat on a du mal à imaginer les investissements qui permettent d'accélérer en boucle l'efficacité. Or c'est ce que permettent ces pratiques de développement : on va plus vite, et en allant plus vite cela permet d'accélérer encore plus et ainsi de suite, c'est une boucle vertueuse. Allez-vous partager cette vidéo autour de vous ? À qui ? Dans quel but, pour provoquer quoi ? -- JP
Très bien ce format. J'aime beaucoup le fait de placer l'expérience personnel au cœur du discours. Je pense que beaucoup de développeurs sont passés par ce saut de la foi pour basculer dans le TDD. Je me demande d'ailleurs si on peut directement être vraiment conscient de l'apport de ces méthodes sans avoir eu un accident avant...
Je fais le même constat que toi ! D'où ce format de vidéo qui essaie de convaincre en racontant une histoire, et pas juste par des arguments rationnels. Tant qu'on n'a pas eu le "déclic" soi-même, on a du mal à comprendre pourquoi cela n'a aucun sens de travailler autrement. Cette vidéo espère aider à provoquer ce déclic chez plus de personnes ! Penses-tu que nous allons atteindre ce but ? -- JP
@@ScrumLife Le fait d'utiliser des exemples personnels donne plus de poids à l'argumentaire auprès de certaines personnes. C'est toujours plus convainquant de dire "j'ai vécu ceci" que de dire "j'ai vu ça dans l'équipe x". Ca permet de compenser le fait que l'on ne peut pas citer d'exemples réels d'entreprise
@@ScrumLife J'en suis convaincu . Et j'ajouterai que je la réutiliserai pour coacher des devs dans mes futures missions. On est dans le concret et dans les impacts. Et cela cerne bien les angoisses des devs et ça y répond. Par contre, je dirais que ça aura moins d'impact sur du management. Donc pour répondre à ta question oui, ça peut inspirer au-delà des fans.
J'ai tellement l'impression de vivre la même chose en ce moment et cette impression d'être nul ça me rassure de voir qu'avec ton expérience tu as vécu la même chose. j'ai également un projet dont j'ai créé l'architecture qui n'est peut être au final pas le mieux et une deadline qui approche avec des énormes journées sans vraiment avancer le problème est : comment faire quand la deadline approche, que tu doit avancer tout en sachant que ce que tu fais n'est pas le mieux mais qu'il faille se former au TDD ou autres design pattern ? Egalement, comment appliquer ce type de logique sur du graphisme, ce qui me prend le plus de temps à chaque fois c'est la logique graphique comme si je sélectionne tel item de ma combobox alors ce bouton est enabled mais sauf si c'est tel item et une case a cocher etc... ? Merci pour ce retour personnel
Salut @son1powa ! Je comprends parfaitement ta situation, c'est vraiment frustrant de se sentir coincé entre les enjeux business et la nécessité d'apprendre de nouvelles techniques. D'abord, respire un grand coup et rappelle-toi que tu n'es pas seul, beaucoup passent par là. Quelques idées : Tu peux envisager de décomposer ton apprentissage en petites sessions quotidiennes, même 15 minutes par jour sur le TDD ou les design patterns peuvent faire une grande différence sur le long terme. Courage, et n'oublie pas, chaque petit progrès est une victoire ! 💪 Si tu as d'autres questions, je suis là pour t'aider. 🚀 Merci pour ton retour et à bientôt ! Robin
Salut @son1powa, Merci pour ton commentaire sincère et introspectif. Tu n'es pas seul, et c'est justement l'une des forces de l'agilité : partager nos défis et apprendre ensemble. Quand des deadlines approchent et que tu ressens le besoin de te former pour améliorer ta pratique (comme le TDD ou les design patterns), c'est souvent un signe que l'amélioration continue est nécessaire. Voici quelques pistes : 1. **Timeboxing et Incremental Learning** : Peut-être peux-tu allouer un court créneau quotidien pour te former tout en avançant sur ton projet. Pas besoin de tout apprendre d'un coup ! Par exemple, 30 minutes de TDD chaque matin avant de commencer ta journée de code. 2. **Choisir ses batailles** : Il est parfois stratégique de "faire au mieux" plutôt que de "faire parfait". Respecter une deadline peut aussi nécessiter quelques compromis pragmatiques. On peut toujours itérer et améliorer dans un sprint futur. Pour ton problème de logique graphique, peut-être devrais-tu explorer ces options : - **Automatiser les tests UI** avec des outils comme Selenium pour valider rapidement les interactions. - **Design Systems** : Avoir un guide de design préétabli pourrait te faire gagner énormément de temps en standardisant les composants. Moins de réinvention, plus de réutilisation. Ton commentaire me donne à penser que nombreuses sont les personnes confrontées aux mêmes défis. Qu'en pensez-vous la communauté Scrum Life ? Des idées ou des conseils à partager ? Merci encore pour ton ouverture, et n'oublie pas, chaque pas compte ! Robin
Je suis totalement en ligne avec l'idée que le test sert avant tout à soit même. Ca ne doit pas être pris comme un KPI pour le management. Les tests permettent de mettre à jour une feature plus tard, sans risquer de la faire régresser, malgré le fait qu'on aura immanquablement oublié la raison de certains détails d'implémentation. Devoir modifier un bout de code non couvert, c'est toujours assez flippant en fait :) Ah et sinon, pour avoir bosser avec Jean-Pierre sur ce projet en particulier, je confirme qu'il en était l'Alpha et l'Oméga ahah Ce n'est absolument pas exagéré ^^
💗🤗🙌 Faut-il leur raconter notre première rencontre, où j'étais en chaussons ? Ca t'avait marqué, tu m'avais dit, ça avait posé le ton comme quoi j'étais le boss. -- JP
@@ScrumLife tu m'étonnes que ça m'avait marqué ^^ Du coup ma première mission après Ateji, j'ai repris cette habitude à déambuler en chausson chez le client... Mais sans ton swag :D
Ah ah, content que ça t'ait plu, Garance ! Penses-tu qu'on devrait faire plus de vidéos de ce genre ? Penses-tu que ce format aide à convaincre les gens ? -- JP
@@ScrumLife Le format ne me choque pas, la question que je pose d'un point de vue plus global est cette position du SM face à la technique. Certes il va s'agir de promouvoir les meilleures pratiques de développement, mais pour moi cela pose la question du dilemne de position... Entre lesj purs tech devenus SM qui ont du mal à lacher la pratique pour adopter la posture de SM et les non techs qui se sentent plus ou moins légitimes sur ce types de questions.
J'ai vraiment du bol. Je bosse sur un gros projet depuis 1an, mais j'arrive encore à visualiser les compartiments et les interactions. Pour le moment jamais aucune régression et aucun test. Par contre, niveau conception, je schématise et j'anticipe les évolutions pendant des heures (j'adore ca). Le code, c'est vraiment 10% du travail. Le code, c'est l'étape finale. (edit: je dois être un mauvais codeur)
Salut @alexmge9182 ! Bravo, c’est génial que tu arrives à garder une vision claire des compartiments et des interactions dans ton projet ! 🎉 C’est souvent un aspect sous-estimé mais tellement crucial pour la réussite. Le fait que tu prennes le temps de bien conceptualiser et anticiper les évolutions, c’est une qualité précieuse. En agilité, on parle beaucoup de l’importance de la planification anticipatoire pour minimiser les risques et les surprises. C’est totalement en ligne avec ce que tu fais. Pour ce qui est du code, ne te sous-estime pas ! Le codage est la partie visible de l'iceberg, mais tout le travail en amont (conception, schématisation) est ce qui assure la robustesse et la maintenabilité de ton projet. Dans les approches agiles, la collaboration et la compréhension sont tout aussi importantes que la pure production de code. As-tu déjà envisagé d’intégrer des tests automatiques pour renforcer encore plus la qualité de ton projet ? Ça pourrait te permettre de gagner en sérénité et de libérer du temps pour continuer à te concentrer sur la conception. Merci pour ton partage ! Hâte de lire ta réponse. Robin #Agilité #ScrumLife
C'est en sa que l'itération des méthodes Agiles, Scrum;... sont fondamentales: PAS D'ACCUMULATION DE DETTES TECHNIQUES, VISUALISATION EN TEMPS REEL DES LIVRABLES ...
@@ScrumLife Pas encore. Je viens de l'univers du tertiaire et donc très imprégné des méthodes transversales. Je m'imprègne encore de la programmation. Le problème auquel tu as fait face est le "syndrome du spécialiste" : voir et concevoir le produit sous le seul prisme des développeurs. Le produit était techniquement bon, mais inconfortable pour les users (voir les vidéos de présentations de Steve Job IPhone ...)
Je suis sur un gros projet et j’aimerais qu’on développe une suite des tests automatisée. En tant que product manager (job fonctionnel) comme puis-je mettre les bonnes conditions en place? Pour l’instant je pensais à bien récapituler la logique business, les intégrations et le dictionnaire de donnée + que le logique business soit écrite avec des tests d’acceptable. Ça serait des entrants dispo pour l’équipe technique… Je pousse à des décisions de type “on passe à la TDD” ou alors “on développe une suite de tests” mais c’est difficile de faire avancer les choses dans cette direction sans initiative claire et il y a un gros passif qualité. Aussi nous sommes sur une appli distribuée avec de nombreux presta et beaucoup d’intégrations… si vous avez des conseils d’approche de test et d’outil que je peux approfondir, ça serait très utile!
Je vois deux aspects : 1. En tant que Product Manager, tu peux dire que ce sont des sujets, importants, non ? Et initier la dynamique en les identifiant comme des chantiers pour lesquels on paie parce qu'on croit en la valeur que cela apportera. 2. En tant qu'agent du changement, il faut se mettre à la place des personnes, en l'occurrence les développeurs. Quelles sont leurs douleurs ? Qu'est-ce qu'il faudrait faire selon eux ? Qu'est-ce qui les empêche de s'y mettre ? Est-ce que cela t'aide ? -- JP
2 роки тому+1
Dans le cadre de la conclusion, qu'elle est la place d'une équipe sa/testing ? Spoiler Mon avis c'est qu'elle n'a pas de sens mais je vais en vexer plus d'un
Il faut regarder ma conférence : "Transformation Agile : comment votre organisation QA peut-elle y trouver sa place ?" -- JP
2 роки тому
Mettre les bouchées doubles à l'approche des deadlines c'est comme rouler à 150km/h pour rattraper du temps perdu. On roule dangereusement pour soi, pour les autres, finalement on croise toujours des ralentissements,on s'énerve et on ne ratrappe jamais le retard sur la promesse. On a souvent bâclé, fait pire que mieux
@@ScrumLife le design by contract c'est une formalisation du test first, tes interfaces contiennent des assertions qui definissent ce qui est valide pour le systeme, ensuite tu code l'implem. Le property based testing c'est deduire des tests automatiquement a partir des assertions logiques. Vois ca un peu comme du fuzzing. Ca explore les combinaisons pour toi et ca isole les sous ensembles problematiques. Si tu fais du python y'a la lib hypothesis. Historiquement une des plus anciennes libraires (en haskell) s'appelle quickcheck, du coup beaucoup de langages ont vu des variantes de quickcheck avec un nom similaire.
Une question, un doute, quelque chose à ajouter ? Ajoute-le en commentaire ! ⌨👇
Nous en échangerons lors du 🔴Live jeudi : sl.run/hYAu40
Amen ! Je fais du TDD tous les jours sur un projet en architecture hexagonale. Ça a été dur au début, c'était une nouvelle manière de bosser et un nouveau pattern d'architecture, mais le gain derrière est énorme !!! C'est un investissement, clairement :). PS : il y a un coté satisfaisant à voir tous les tests passer au vert :D. Le gamer que je suis est content.
En phase. Dans notre projet on est allé plus loin avec le BDD et quasi que des test traversants (et quelques tests unitaires pour compléter les parties les plus technique). Après un an, 2900 scénarios de tests traversant, 280 tests unitaires, 100% de réussite à chaque build, avec un taux de couverture qui tend vers 93% depuis 8 mois. Pour les 7% restant, on se demande si les parties non couverte sont sujette à des risque de régression ou non. Pour la plupart de ces sujets, on se dit que faire de la couverture pour de la couverture nuirait à la lisibilité du projet. Pas de bugs en prod, aucune régression entre les versions. On commence même à arriver à un point où on se satisfait de retirer du code projet tout en ajoutant des features (merci aux refactos déjà couverte par les tests). Bref, l'investissement est énorme au départ, mais le gain à moyen/long terme est sans commune mesure. Si jamais un bug est détecté par les équipes de qualif (ça arrive aussi), identifier la source nous prend aussi très peu de temps car c'est soit une absence de specs en amont, soit un petit trou dans les scénarios de test, un cas à la marge auquel personne n'avait pensé.
Oui, cela fonctionne comme des investissements bancaires : au début, on a peu d'intérêts, puis ensuite on touche aussi des intérêts sur les intérêts gagnés, et progressivement ça s'accélère en boucle.
J'en parlais lors de ma keynote à Agile Tour Montréal à propos de la notion de progrès : notre cerveau n'est pas câblé pour penser "exponentiel", résultat on a du mal à imaginer les investissements qui permettent d'accélérer en boucle l'efficacité. Or c'est ce que permettent ces pratiques de développement : on va plus vite, et en allant plus vite cela permet d'accélérer encore plus et ainsi de suite, c'est une boucle vertueuse.
Allez-vous partager cette vidéo autour de vous ? À qui ? Dans quel but, pour provoquer quoi ?
-- JP
Super ton retour d'expérience ! merci
Avec plaisir ! Que retiens-tu de cette vidéo, Zied ?
-- JP
Très bien ce format. J'aime beaucoup le fait de placer l'expérience personnel au cœur du discours. Je pense que beaucoup de développeurs sont passés par ce saut de la foi pour basculer dans le TDD. Je me demande d'ailleurs si on peut directement être vraiment conscient de l'apport de ces méthodes sans avoir eu un accident avant...
Je fais le même constat que toi ! D'où ce format de vidéo qui essaie de convaincre en racontant une histoire, et pas juste par des arguments rationnels.
Tant qu'on n'a pas eu le "déclic" soi-même, on a du mal à comprendre pourquoi cela n'a aucun sens de travailler autrement. Cette vidéo espère aider à provoquer ce déclic chez plus de personnes !
Penses-tu que nous allons atteindre ce but ?
-- JP
@@ScrumLife Le fait d'utiliser des exemples personnels donne plus de poids à l'argumentaire auprès de certaines personnes. C'est toujours plus convainquant de dire "j'ai vécu ceci" que de dire "j'ai vu ça dans l'équipe x". Ca permet de compenser le fait que l'on ne peut pas citer d'exemples réels d'entreprise
Super partage d'expérience. Bravo pour la sincérité et la narration, en plus d'être totalement inspirant.🤩
Merci !!!
Penses-tu que cette vidéo inspirera au-delà des personnes déjà fan de Scrum Life ?
-- JP
@@ScrumLife J'en suis convaincu . Et j'ajouterai que je la réutiliserai pour coacher des devs dans mes futures missions. On est dans le concret et dans les impacts. Et cela cerne bien les angoisses des devs et ça y répond. Par contre, je dirais que ça aura moins d'impact sur du management. Donc pour répondre à ta question oui, ça peut inspirer au-delà des fans.
Superbe vidéo !
Merci ! Quel élément retiens-tu particulièrement de cette vidéo ? Qu'est-ce qui te ferait la partager à d'autres personnes ?
-- JP
J'ai tellement l'impression de vivre la même chose en ce moment et cette impression d'être nul ça me rassure de voir qu'avec ton expérience tu as vécu la même chose.
j'ai également un projet dont j'ai créé l'architecture qui n'est peut être au final pas le mieux et une deadline qui approche avec des énormes journées sans vraiment avancer
le problème est : comment faire quand la deadline approche, que tu doit avancer tout en sachant que ce que tu fais n'est pas le mieux mais qu'il faille se former au TDD ou autres design pattern ?
Egalement, comment appliquer ce type de logique sur du graphisme, ce qui me prend le plus de temps à chaque fois c'est la logique graphique comme si je sélectionne tel item de ma combobox alors ce bouton est enabled mais sauf si c'est tel item et une case a cocher etc... ?
Merci pour ce retour personnel
Salut @son1powa !
Je comprends parfaitement ta situation, c'est vraiment frustrant de se sentir coincé entre les enjeux business et la nécessité d'apprendre de nouvelles techniques. D'abord, respire un grand coup et rappelle-toi que tu n'es pas seul, beaucoup passent par là.
Quelques idées : Tu peux envisager de décomposer ton apprentissage en petites sessions quotidiennes, même 15 minutes par jour sur le TDD ou les design patterns peuvent faire une grande différence sur le long terme.
Courage, et n'oublie pas, chaque petit progrès est une victoire ! 💪 Si tu as d'autres questions, je suis là pour t'aider. 🚀
Merci pour ton retour et à bientôt !
Robin
Salut @son1powa,
Merci pour ton commentaire sincère et introspectif. Tu n'es pas seul, et c'est justement l'une des forces de l'agilité : partager nos défis et apprendre ensemble.
Quand des deadlines approchent et que tu ressens le besoin de te former pour améliorer ta pratique (comme le TDD ou les design patterns), c'est souvent un signe que l'amélioration continue est nécessaire. Voici quelques pistes :
1. **Timeboxing et Incremental Learning** : Peut-être peux-tu allouer un court créneau quotidien pour te former tout en avançant sur ton projet. Pas besoin de tout apprendre d'un coup ! Par exemple, 30 minutes de TDD chaque matin avant de commencer ta journée de code.
2. **Choisir ses batailles** : Il est parfois stratégique de "faire au mieux" plutôt que de "faire parfait". Respecter une deadline peut aussi nécessiter quelques compromis pragmatiques. On peut toujours itérer et améliorer dans un sprint futur.
Pour ton problème de logique graphique, peut-être devrais-tu explorer ces options :
- **Automatiser les tests UI** avec des outils comme Selenium pour valider rapidement les interactions.
- **Design Systems** : Avoir un guide de design préétabli pourrait te faire gagner énormément de temps en standardisant les composants. Moins de réinvention, plus de réutilisation.
Ton commentaire me donne à penser que nombreuses sont les personnes confrontées aux mêmes défis. Qu'en pensez-vous la communauté Scrum Life ? Des idées ou des conseils à partager ?
Merci encore pour ton ouverture, et n'oublie pas, chaque pas compte !
Robin
Je suis totalement en ligne avec l'idée que le test sert avant tout à soit même. Ca ne doit pas être pris comme un KPI pour le management. Les tests permettent de mettre à jour une feature plus tard, sans risquer de la faire régresser, malgré le fait qu'on aura immanquablement oublié la raison de certains détails d'implémentation. Devoir modifier un bout de code non couvert, c'est toujours assez flippant en fait :)
Ah et sinon, pour avoir bosser avec Jean-Pierre sur ce projet en particulier, je confirme qu'il en était l'Alpha et l'Oméga ahah Ce n'est absolument pas exagéré ^^
💗🤗🙌
Faut-il leur raconter notre première rencontre, où j'étais en chaussons ? Ca t'avait marqué, tu m'avais dit, ça avait posé le ton comme quoi j'étais le boss.
-- JP
@@ScrumLife tu m'étonnes que ça m'avait marqué ^^ Du coup ma première mission après Ateji, j'ai repris cette habitude à déambuler en chausson chez le client... Mais sans ton swag :D
Père Jp raconte nous une histoire 😀
Ah ah, content que ça t'ait plu, Garance !
Penses-tu qu'on devrait faire plus de vidéos de ce genre ?
Penses-tu que ce format aide à convaincre les gens ?
-- JP
@@ScrumLife Le format ne me choque pas, la question que je pose d'un point de vue plus global est cette position du SM face à la technique. Certes il va s'agir de promouvoir les meilleures pratiques de développement, mais pour moi cela pose la question du dilemne de position...
Entre lesj purs tech devenus SM qui ont du mal à lacher la pratique pour adopter la posture de SM et les non techs qui se sentent plus ou moins légitimes sur ce types de questions.
J'ai vraiment du bol. Je bosse sur un gros projet depuis 1an, mais j'arrive encore à visualiser les compartiments et les interactions. Pour le moment jamais aucune régression et aucun test. Par contre, niveau conception, je schématise et j'anticipe les évolutions pendant des heures (j'adore ca). Le code, c'est vraiment 10% du travail. Le code, c'est l'étape finale. (edit: je dois être un mauvais codeur)
Salut @alexmge9182 !
Bravo, c’est génial que tu arrives à garder une vision claire des compartiments et des interactions dans ton projet ! 🎉 C’est souvent un aspect sous-estimé mais tellement crucial pour la réussite.
Le fait que tu prennes le temps de bien conceptualiser et anticiper les évolutions, c’est une qualité précieuse. En agilité, on parle beaucoup de l’importance de la planification anticipatoire pour minimiser les risques et les surprises. C’est totalement en ligne avec ce que tu fais.
Pour ce qui est du code, ne te sous-estime pas ! Le codage est la partie visible de l'iceberg, mais tout le travail en amont (conception, schématisation) est ce qui assure la robustesse et la maintenabilité de ton projet. Dans les approches agiles, la collaboration et la compréhension sont tout aussi importantes que la pure production de code.
As-tu déjà envisagé d’intégrer des tests automatiques pour renforcer encore plus la qualité de ton projet ? Ça pourrait te permettre de gagner en sérénité et de libérer du temps pour continuer à te concentrer sur la conception.
Merci pour ton partage ! Hâte de lire ta réponse.
Robin
#Agilité #ScrumLife
C'est en sa que l'itération des méthodes Agiles, Scrum;... sont fondamentales: PAS D'ACCUMULATION DE DETTES TECHNIQUES, VISUALISATION EN TEMPS REEL DES LIVRABLES ...
Carrément, et bien dit !
Utilises-tu toi-même ces pratiques de Test First ?
-- JP
@@ScrumLife Pas encore. Je viens de l'univers du tertiaire et donc très imprégné des méthodes transversales.
Je m'imprègne encore de la programmation. Le problème auquel tu as fait face est le "syndrome du spécialiste" : voir et concevoir le produit sous le seul prisme des développeurs. Le produit était techniquement bon, mais inconfortable pour les users (voir les vidéos de présentations de Steve Job IPhone ...)
Je suis sur un gros projet et j’aimerais qu’on développe une suite des tests automatisée. En tant que product manager (job fonctionnel) comme puis-je mettre les bonnes conditions en place? Pour l’instant je pensais à bien récapituler la logique business, les intégrations et le dictionnaire de donnée + que le logique business soit écrite avec des tests d’acceptable. Ça serait des entrants dispo pour l’équipe technique… Je pousse à des décisions de type “on passe à la TDD” ou alors “on développe une suite de tests” mais c’est difficile de faire avancer les choses dans cette direction sans initiative claire et il y a un gros passif qualité. Aussi nous sommes sur une appli distribuée avec de nombreux presta et beaucoup d’intégrations… si vous avez des conseils d’approche de test et d’outil que je peux approfondir, ça serait très utile!
Je vois deux aspects :
1. En tant que Product Manager, tu peux dire que ce sont des sujets, importants, non ? Et initier la dynamique en les identifiant comme des chantiers pour lesquels on paie parce qu'on croit en la valeur que cela apportera.
2. En tant qu'agent du changement, il faut se mettre à la place des personnes, en l'occurrence les développeurs. Quelles sont leurs douleurs ? Qu'est-ce qu'il faudrait faire selon eux ? Qu'est-ce qui les empêche de s'y mettre ?
Est-ce que cela t'aide ?
-- JP
Dans le cadre de la conclusion, qu'elle est la place d'une équipe sa/testing ?
Spoiler Mon avis c'est qu'elle n'a pas de sens mais je vais en vexer plus d'un
Il faut regarder ma conférence : "Transformation Agile : comment votre organisation QA peut-elle y trouver sa place ?"
-- JP
Mettre les bouchées doubles à l'approche des deadlines c'est comme rouler à 150km/h pour rattraper du temps perdu.
On roule dangereusement pour soi, pour les autres, finalement on croise toujours des ralentissements,on s'énerve et on ne ratrappe jamais le retard sur la promesse.
On a souvent bâclé, fait pire que mieux
Ouais, bah, va dire ça à celui qui est en retard, et stressé bien entendu.
-- JP
@@ScrumLife on n'est jamais en retard on a juste mal estimé ou fait trop de promesses
bienvenue en 1994, amuse toi bien avec le design by contract, sinon j'vends des formations sur le property based testing, pour ceux que ca interesse
Oh ! Ça a l'air intéressant. Tu peux nous en dire plus ? C'est quoi le property-based testing ?
-- JP
@@ScrumLife le design by contract c'est une formalisation du test first, tes interfaces contiennent des assertions qui definissent ce qui est valide pour le systeme, ensuite tu code l'implem. Le property based testing c'est deduire des tests automatiquement a partir des assertions logiques. Vois ca un peu comme du fuzzing. Ca explore les combinaisons pour toi et ca isole les sous ensembles problematiques. Si tu fais du python y'a la lib hypothesis. Historiquement une des plus anciennes libraires (en haskell) s'appelle quickcheck, du coup beaucoup de langages ont vu des variantes de quickcheck avec un nom similaire.