Agile Tour Bordeaux 2024 : on y était !

Laurent Verdier -

Cette année, l'Agile Tour Bordeaux s'est tenu dans les locaux du campus Ynov, place Ravezies à Bordeaux. Wanteeed y était présent : Christophe comme speaker, et Jérémie et Laurent qui ont fait le plein d'informations aux différentes présentations.

Nous n'avons hélas pas pu tout voir, mais voici des récap de quelques-unes des sessions auxquelles nous avons assisté :

Comment mettre l'utilisateur au coeur de la QA ?

par Camille Fournier

Constat : la connaissance des users permet réellement d'augmenter la qualité produit. Autrement on risque de se focaliser sur des points de qualité non pertinents

3 piliers pour mettre users au centre de la démarche

  • écouter les utilisateurs
    • interviews
    • constitution & analyse d'une base de données des retours exprimés au support (problèmes, besoins...). Que ce ne soit pas seulement les personnes en charge du support qui accèdent à ces données
    • utiliser les verbatims dans les persona, pour leur donner plus de véracité
  • faire un "shift left" sur la QA
    • faire intervenir la démarche qualité le plus en amont possible dans le cycle de vie du produit (de la phase exploratoire jusqu'à la phase de maintenance, en passant par le dev)
    • favoriser la transversalité QA/UX/Produit/dev...
    • tester sur la base des maquettes & user stories
  • adopter le bon état d'esprit pour tester
    • gare aux biais !
    • reproduire le contexte d'utilisation (par ex. on se rend vite compte en testant en conditions une app de méditation qu'il faut un dark mode...)
    • favoriser les tests exploratoires (= qui ne suivent pas un scénario précis). Permet de reproduire des vrais cas d'utilisation, favorise la sérendipité

En conclusion : faire que les testeurs soient les ambassadeurs des utilisateurs auprès des équipes produit

Les colibris connectés contre les dragons de l'inaction climatique

par Charlotte Baradat

Présentation d'une app développée par OnePoint pour sensibiliser les individus aux questions écologiques et les inciter positivement à agir à leur niveau.

  • démarche expérimentale de test d'une app auprès de quelques centaines de collaborateurs OnePoint.
  • features pensées à la lumière des neurosciences pour prendre le contrepied de certains biais cognitifs, désignés par un universitaire américain comme les "dragons de l'inaction", tels que :
    • cognitifs :
      • torpeur causée par la complexité et masse d'information

         => proposer des microcontenus dans un parcours d'apprentissage

    • comparaison avec les autres
      • ne pas faire par peur du jugement
      • ne pas faire car on pense qu'on en fait déjà plus que les autres

         => stimuler par le collectif et l'interaction sociale en partageant son expérience, proposant des défis...

    • comportements limités
      • tout miser sur des actions à l'effet symbolique
      • "effet rebond" : compenser négativement ses efforts du quotidien ("j'ai pris le vélo toute l'année, je peux me permettre de prendre l'avion")

         => mesure d'empreinte carbone avec système gamifié

Dites adieu aux sessions interminables de product backlog refinement avec l'Example Mapping

par Arnaud Langlade

Constat du caractère ennuyeux et inefficace des sessions de backlog refinement de deux heures, très descendants, sujets aux digressions... et qui aboutissent souvent à une séance d'estimations peu fiables, puis à des aller-retour supplémentaires avec le métier

Proposition de solution : l'atelier d'example mapping

  • Objectif = clarifier les critères d'acceptance d'une story
  • Modalités proposées :
    • nécessite les "tres amigos" : PM, dev, QA. Pas forcément des personnes, mais des "casquettes". Parfois aussi des experts métiers, s'ils ne sont pas déjà représentés parmi les 3 premiers rôles.
    • max 30 minutes
    • 1 session = 1 story
    • écrire le nom de la story sur une carte verte
    • écrire les règles métier sur des cartes bleues
    • illustrer ces règles avec des exemples sur des cartes vertes. Par ex. structure given/when/then, ou des schémas... tout ce qui marche
      • commencer par les cas passants
      • ajouter les cas d'erreur
    • noter sur des cartes roses les problèmes / questions à répondre hors atelier (pour ne pas bloquer l'échange).

Tant que les cartes roses n'ont pas eu de réponse, la story n'est pas prête ! ne pas chercher à la développer.

Tips :

  • difficile au début, persévérer !
  • si manque de clarté sur les règles métier, commencer par lister des exemples pour faire émerger les règles métier
  • si une règle a trop d'exemples, il y a peut-être en réalité plusieurs règles, à distinguer avec chacune ses exemples
  • permet de classer les règles en must have, nice to have... et donc de découper la story en plus petits incréments
  • prévoir un créneau quotidien, quitte à annuler les séances si pas besoin.
  • convier toute l'équipe, pas que les personnes qui travailleront spécifiquement dessus => meilleur partage de connaissance, alignement...
  • pour les PM : attention à laisser la main aux autres participants
  • en présentiel : privilégier une table et des cartes plutôt qu'un mur et des post-its
  • en remote : désigner un scribe qui est seul à écrire, pour éviter l'éparpillement
  • les exemples pourront servir de test cases pour les devs et de scénario pour les QA

Le No-Hype Driven Development

par Christophe Héral (notre VP chez Wanteeed !)

Disclaimer du speaker : pas mal de technos critiquées dans cette présentation, reflète les opinions personnelles. Ouvert à la discussion :)

Constat : en tant que tech, on est souvent tenté de se jeter sur les dernières techno. Mais cela peut nuire à la santé du projet !

Plusieurs (mauvaises) raisons pour aller vers une nouvelle techno :

  • pour faire bien sur le CV
  • car on est issu d'une formation (courte ou longue) qui lançait directement les étudiants sur des techs hyper récentes
  • pour imiter les acteurs phares du domaine (cf Cargo Cult)

On a tendance en tant que dev à aborder une problématique depuis l'espace de la solution (en pensant "technos") alors qu'on devrait rester dans l'espace du problème (en pensant "métier"). Les technos ne sont qu'un détail d'implémentation.

Parfois on choisit une techno inadaptée au cas d'usage :

  • BDD NoSQL répondent à des besoins précis : stockage de données peu structurées, besoin en scalabilité horizontale. Pour la plupart des apps, le modèle relationnel permis par les techno SQL est bien plus adapté !
  • GraphQL : utile lorsqu'on a une grande variété de consommateurs de la donnée, mais le surcoût technique à payer en contrepartie ne vaut pas la peine pour la plupart des apps
  • Architecture micro-services, kubernetes... répondent à des besoins de forte scalabilité de certaines parties de l'app, notamment. Même des géants comme Netflix sortent des microservices pour refaire du monolithe, alors ton app n'en a sûrement pas besoin non plus !
  • ORM : servent à faciliter la vie des dév en simplifiant la syntaxe rébarbative du SQL, mais peu efficaces pour les queries complexes. Résultat : on ne gagne pas grand chose à passer par l'ORM pour écrire des requêtes "simples", en revanche on doit quand même faire à la main les requêtes complexes.

Surabondance de technos notamment JavaScript dans les années 2010... dont pas mal finissent au cimetière.

Egalement des frameworks "agiles" tombent dans le travers de la hype : SAFe !

Back to basics : la plupart des pratiques d'ingénierie reconnues comme "bonnes" sont très anciennes. Notamment :

  • 1975 : introduction de qualité dès la conception, casser les silos...
  • 1985 : prémisses du Trunk bases development
  • 1988 : Inversion de contrôle (même si principes SOLID seront formalisés sous ce nom plus tard)
  • 1991 : LEAN
  • 1994 : tests automatisés
  • 1996 : Intégration Continue avec Cruise Control
  • 1999 : Software Craftsmanship
  • 2001 : manifeste Agile
  • 2002 : TDD & BDD

Toutes ces pratiques existaient déjà il y a 20 ans, mais encore aujourd'hui peinent à s'imposer pour certaines.

Propositions de solution :

  • Valoriser les pratiques + que les technos. Elles sont + stables et transversales.
  • Lors des choix de tech, partir sur des technos éprouvées : + fiables, meilleur support communautaire, moins de complexité accidentelle
  • Arrêter de survaloriser les technos lors du recrutement

MAIS : rester ouvert d'esprit : certaines tech de niche ont fini par s'imposer. Exemple : un certain TypeScript...

Donner le pouvoir aux équipes pour mieux gérer la complexité dans la tech

par Mathieu Lamiot

En réalité plutôt un retour d'expérience d'un dev engagé comme manager d'une équipe de devs qui rencontrait des problèmes.

Problèmes venaient de méthodologies de travail héritées du "management scientifique" à la Taylor, inadaptées au monde du software

  • problèmes rencontrés liés à deux principales méthodologie de travail de l'équipe
    • tableau kanban avec des acteurs successifs sur un même ticket : dev A développe, puis dev B review puis QA valide... = reproduction d'une chaîne de montage avec des rôles silotés
    • dev unique dédié au développement d'une release trimestrielle au contenu prédéfini suivant une roadmap fixe, avec test juste à la fin = cycle waterfall / en V. Exemple avec une release catastrophe qui prend 7 mois pour réparer les bugs qu'elle a introduits
  • solutions
    • favoriser focus et collaboration
      • faire émerger une équipe, pas des individus
      • prioriser l'efficacité du groupe avant l'efficience individuelle (au sens de maximiser le temps qu'un individu passe à produire)
    • établir les règles significatives les + simples possibles. Ex. d'une autre boîte : interdire strictement à 1 dev de commencer un ticket tant que le précédent n'est pas livré. En attendant, oblige le dev à aller solliciter / aider les autres => induit une communication dans l'équipe
    • approche "self-service" : constat que la prise de décision ne scale pas. Aboutit à des goulets d'étranglement.
      • si actions de validation uniquement faites par certains experts, ça va coincer
      • à la place, pousser ces experts à mettre en place des outils qui autonomisent les équipes

          => faire passer les devs d'exécutants à décideurs

  • sanctuariser du temps alloué aux tâches techniques. Par ex. "cooldown sprints", ou quota de tickets techniques dans les sprints...

Grande humilité du speaker sur ce qu'il a tenté de mettre en place. Précédé d'une phase d'observation et de travail avec les équipes (fait des tickets avec eux). Mise en place progressive des nouvelles pratiques, n'hésite pas à abandonner ce qui ne prend pas.

Quelques conseils / ressources / concepts supplémentaires évoqués au cours de cette journée

  • comment convaincre n'importe qui de faire n'importe quoi ?
    • faire preuve d'empathie
    • prémâcher le travail à la personne
    • faire en sorte qu'il soit difficile de dire non (= montrer que ça va coûter + cher de ne pas faire)
  • livre Turn the ship around! a true story of turning followers into leaders de David Marquet, ancien capitaine de navire dans l'US Navy
  • économie du donut
  • cadre conceptuel Cynefin d'aide à la prise de décision
  • acronyme VUCA, qui décrit les situations auxquelles doivent faire face les managers