Agile Tour Bordeaux 2022 : on y était !
Christophe et Jérémie étaient à l'Agile Tour Bordeaux dans les locaux de 3IS pour y représenter Wanteeed, partager avec la communauté et repartir avec plein d'idées et de tips à mettre à place dans notre contexte.
Voici un échantillon de quelques sessions auxquelles nous avons assisté :
Le test est une activité, pas une phase du cycle de développement
Retour d’expérience sur la mise en place d’une stratégie de test dans une entreprise de 15 ans avec 80 devs et 0 tests (AT Internet - Web Analytics).
- Comment tester une grosse brique legacy : partir petit et ajouter au fur et à mesure
- Mettre en place les bonnes pratiques de test sur les nouveaux projets
- Avoir des indicateurs pour suivre l'évolution et les bénéfices
- Savoir ralentir pour repartir plus sereinement
Développez des APIs que les développeurs adoreront utiliser, grâce au design thinking
Point de vue d'un PM qui pilote plusieurs équipes travaillant sur des APIs au sein d'une entreprise qui en produit des centaines (ADEO - Data Exchange Platform).
- Ecrire des APIs en pensant aux développeurs qui vont l'utiliser et pas la machine qui va l’appeler
- Mettre en place des guidelines pour uniformiser et respecter les standards définis
- Documenter
Le property based testing pour répondre aux questions métier
Présentation des bases du Property Based Testing par un dev/scrum (AT Internet - Web Analytics)
- S'applique principalement aux tests unitaires
- Exécute un grand nombre de fois un test avec des valeurs différentes en entrée pour chaque "property" (= argument)
- Permet de mettre dans les tests des règles métier
- Utiliser un framework qui permet de générer ces valeurs et se servir de leur puissance de shrinking.
Ci-dessous les slides d'autres sessions intéressantes :
Comme souvent, le format Forum Ouvert était également très enrichissant le 2e jour. Les vidéos des sessions enregistrées seront disponibles prochainement ici.
Pour finir, un certain nombre de leçons (re-)apprises :
- Le modèle Agile Fluency et l'agilité à plusieurs niveaux
- Accompagner à la fois tech et métier dans les transformations
- La MEP doit être un non-évènement
- "Si un œuf est brisé par une force extérieure, la vie prend fin. S'il est brisé par une force intérieure, la vie commence."
- "All models are wrong, but some are useful"
- Faire participer les dev le plus en amont possible du process
- Discuter entre dev et métier avec le vocabulaire de l'espace du problème
- Mettre les dev en contact avec le support
- Plutôt effectuer l'apprentissage du produit au niveau de l'epic plutôt qu'au niveau de l'US
- Utiliser les outils du management 3.0 (moving motivators, delegation poker...)