TDD & BDD

Le principe FIRST c'est un ensemble de critères permettant de garantir que les tests sont bien conçus, efficaces et maintenables. L'acronyme FIRST représente une caractéristique comme:

F pour Fast (Rapide) : Les tests unitaires doivent s'exécuter rapidement. Un test trop lent risque d'être ignoré, ce qui peut compromettre la qualité du code.

I pour Isolated/Independent (Isolé ou Indépendant) : Chaque test doit pouvoir être exécuté indépendamment des autres. Il ne doit y avoir aucune dépendance entre les tests, ni à des bases de données. Cela garantit que les échecs d'un test ne provoquent pas ceux d'autres tests.

R pour Repeatable (Répétable) : Un test unitaire doit toujours donner les mêmes résultats, quel que soit le moment ou l'environnement dans lequel il est exécuté.

S pour Self-Validating (Auto-validant) : Un test unitaire doit être en mesure de déterminer automatiquement s'il a réussi ou échoué. Cela signifie qu'il doit se terminer par une condition binaire (réussi/échoué) sans nécessiter d'intervention humaine ou d'inspection visuelle des résultats.

T pour Timely (Temporaire) : Les tests unitaires doivent être écrits au bon moment, idéalement avant ou en même temps que le code testé. Cela garantit que le code est bien conçu pour être testé et qu'il remplit les exigences dès le départ.

Les "Test Doubles" sont des objets utilisés pour remplacer des dépendances réelles dans les tests, afin d'isoler la logique qu'on souhaite tester. Ils permettent de simuler des comportements sans avoir à recourir aux véritables objets ou services externes, souvent complexes ou lents (comme les bases de données ou les API externes). Il existe plusieurs types de doubles de test: Dummy, Stub, Spy, Mock

Un Dummy est le double de test le plus simple. Il est utilisé lorsqu'un objet doit être passé en argument pour une méthode, mais n'est jamais utilisé. Son rôle est simplement de "remplir" une place, et il ne contient aucune logique ou comportement spécifique.

Exemple concret : Dans un système de gestion des utilisateurs, supposons qu' on ait une méthode envoyerEmail qui prend en paramètre un objet Utilisateur ainsi qu'un objet EmailService. Dans un test de la logique métier, on ne se soucie pas de l'objet EmailService, on peut donc le remplacer par un Dummy.

Un Stub est un double test qui remplace une dépendance et renvoie des réponses pré-définies à certaines méthodes. Il ne contient pas de logique complexe, mais il permet de contrôler le comportement des appels externes afin de tester le code dans un contexte donné.

Exemple concret : Imaginons que vous testez une méthode qui récupère des données d'une API externe. Pour éviter de faire des appels réseau pendant les tests, vous utilisez un Stub qui renvoie toujours les mêmes données simulées. Le Stub remplace le service API et renvoie des résultats fixes, facilitant ainsi le test du comportement de votre code sans dépendre de l'API réelle.

Un Spy est un double test qui enregistre les interactions faites avec lui. Il permet de vérifier si certaines méthodes ont été appelées, combien de fois, avec quels arguments, etc. Contrairement au Mock, le Spy conserve le comportement d'origine du code.

Exemple concret : Dans un système de suivi des commandes, vous souhaitez vous assurer qu'une méthode de notification est appelée une fois qu'une commande est validée. Le Spy permet de vérifier cela.

Dummy : Utilisé lorsque l'objet n'a aucune importance pour le test (juste un placeholder). Stub : Utilisé pour fournir des réponses préprogrammées, souvent pour simuler des API ou services externes. Spy : Utilisé pour vérifier que certaines méthodes ont été appelées et avec quels arguments, tout en conservant le comportement réel. Mock : Utilisé pour vérifier et définir des comportements spécifiques sur un objet ou une méthode, en remplaçant l'implémentation réelle. Fake : Utilisé pour remplacer une dépendance avec une version simplifiée mais fonctionnelle, comme une base de données en mémoire.

BDD (Behaviour Driven Development) est une approche agile pour le développement logiciel qui se concentre sur le comportement attendu du système du point de vue des utilisateurs. Contrairement au TDD qui met l'accent sur les tests techniques (unitaires), le BDD se concentre sur la collaboration entre les développeurs, les testeurs, et les parties prenantes non techniques pour définir les comportements attendus à travers des scénarios concrets écrits en langage naturel comme Gherkin ou fitness, robot framework.

BDD se concentre sur le "quoi" (comportement) et TDD se concentre sur le "comment" (implémentation).

Les scénarios Gherkin, décrivent le comportement attendu d'une fonctionnalité d'un point de vue utilisateur. Ils sont écrits sous la forme de phrases simples en utilisant Given-When-Then, ce qui permet de les comprendre facilement même par des non-développeurs. Par exemple :

• Given une condition initiale,
• When une action est effectuée,
• Then un résultat spécifique est attendu.

Une bonne pratique est de suivre la règle du single responsibility dans les scénarios, c'est-à-dire qu'un scénario doit tester un seul comportement ou fonctionnalité spécifique. Cela aide à maintenir des tests clairs, compréhensibles et faciles à maintenir. Par exemple :

• Un scénario ne doit pas tester plusieurs cas de bord ou inclure de la logique conditionnelle.
• Utiliser des termes abstraits dans les Given, When, et Then pour rendre les scénarios réutilisables et indépendants des changements techniques mineurs (comme le nom des boutons).

Le succès de BDD peut être mesuré en suivant plusieurs indicateurs :

• Qualité du produit : Réduction des bugs en production, car les comportements sont validés avant et pendant le développement.
• Collaboration accrue : Amélioration de la communication entre les équipes techniques et non techniques, avec une meilleure compréhension des besoins métiers.
• Cycle de développement : Un cycle de développement plus rapide grâce à des exigences clarifiées et des tests automatisés intégrés au processus CI/CD.
• Couverture des tests : Mesurer le pourcentage de fonctionnalités couvertes par des tests BDD automatisés et valider la non-régression.

Lorsqu'on utilise BDD en complément de TDD (Test-Driven Development), on cherche à résoudre plusieurs problèmes liés à la communication, la clarté des exigences, et l'alignement entre l'équipe technique et les parties prenantes.

Alignement sur les exigences métier

• Problème : Avec TDD, les tests sont souvent écrits en se concentrant sur l'implémentation technique du code, ce qui peut créer un fossé entre ce que le produit doit faire et la manière dont il est testé. Les tests peuvent être trop techniques et ne pas refléter clairement les attentes des utilisateurs finaux.

• Solution BDD : En utilisant un langage commun et accessible à tous les acteurs (comme le format Gherkin en BDD, avec des mots-clés comme "Given", "When", "Then"), BDD permet de définir les tests en termes de comportements attendus du système du point de vue métier. Cela facilite l'alignement entre les développeurs, les testeurs, et les parties prenantes non techniques.

Clarté et compréhension partagée

• Problème : En TDD, les tests unitaires peuvent parfois être difficiles à comprendre pour des personnes qui ne sont pas des développeurs. Cela peut poser problème lorsque des non-techniciens, comme des chefs de produit ou des clients, veulent s'assurer que le système est bien conforme à leurs besoins.
• Solution BDD : Les scénarios BDD sont écrits de manière simple et compréhensible pour tous, y compris les non-techniciens. Ils décrivent les fonctionnalités sous forme de comportements observables, ce qui améliore la communication et garantit que tout le monde a la même compréhension des fonctionnalités à développer.

Focus sur la valeur métier

• Problème : Avec TDD, il est possible que les développeurs se concentrent trop sur les détails d'implémentation et testent des parties du système qui n'apportent pas directement de valeur au client final.
• Solution BDD : BDD oblige à se concentrer sur les fonctionnalités qui ont un impact direct sur le comportement observable par les utilisateurs. En décrivant les tests en termes de "comportements attendus", on s'assure que l'effort de développement est orienté vers la création de valeur métier.

Tests plus robustes et orientés utilisateurs

• Problème : Les tests TDD peuvent parfois manquer de perspective sur l'expérience utilisateur, car ils sont centrés sur le bon fonctionnement du code, mais pas nécessairement sur le bon fonctionnement du système du point de vue utilisateur.
• Solution BDD : Avec BDD, les tests sont basés sur des comportements que l'utilisateur final s'attend à voir. Cela permet de couvrir plus facilement des cas d'utilisation réels et d'éviter des bugs ou des comportements inattendus dans des situations que les tests purement techniques auraient pu ignorer.

Documentation vivante

• Problème : Les tests unitaires en TDD sont souvent cryptiques pour les personnes extérieures à l'équipe technique et ne servent pas nécessairement de documentation explicite sur le comportement du système.
• Solution BDD : Les scénarios de BDD servent de documentation vivante, car ils décrivent de manière claire et compréhensible le comportement attendu du système. Ils peuvent être relus et validés par toutes les parties prenantes, servant à la fois de spécification, de test et de documentation.

Amélioration de la collaboration entre équipes

• Problème : Le TDD est souvent perçu comme une activité strictement réservée aux développeurs, ce qui peut limiter la collaboration entre les développeurs, les testeurs et les parties prenantes métier.
• Solution BDD : Le processus BDD invite à une meilleure collaboration dès le départ. En impliquant les développeurs, les testeurs et les représentants métier dans l'écriture des scénarios BDD, on favorise une approche collaborative où tout le monde contribue à la compréhension des fonctionnalités à développer.

Les avantages de BDD sont:

• Alignement avec les besoins métiers : Les tests BDD sont écrits en collaboration avec les parties prenantes, ce qui garantit que les fonctionnalités développées répondent aux besoins des utilisateurs.
• Documentation vivante : Les scénarios Gherkin servent de documentation claire et toujours à jour, facilitant la compréhension des fonctionnalités pour toute l'équipe.
• Réduction des erreurs de communication : En traduisant les exigences en scénarios clairs, on minimise le risque de malentendus entre développeurs et parties prenantes.
• Tests d'acceptation automatisés : BDD permet d'automatiser les tests d'acceptation, augmentant ainsi la couverture des tests et réduisant les efforts manuels lors des tests de régression.

Les tests flakies, ou tests instables, sont des tests automatisés qui échouent de manière intermittente, sans que cela soit dû à des erreurs dans le code ou des changements dans les spécifications. Ils posent un problème majeur pour les équipes de développement et de test, car ils peuvent rendre difficile la détermination de la qualité réelle du logiciel.

Pourquoi les tests flakies se reproduisent-ils ?

• Problèmes de synchronisation : Chargement asynchrone : Dans les applications modernes, notamment les applications front-end, des éléments peuvent se charger de manière asynchrone. Les tests peuvent tenter d'interagir avec des éléments qui ne sont pas encore disponibles, entraînant des échecs intermittents. Timing : Les tests peuvent dépendre de délais ou de temps d'attente qui ne sont pas correctement gérés, ce qui peut conduire à des résultats imprévisibles.
• État global partagé :Les tests peuvent partager des ressources ou des états globaux, ce qui peut provoquer des conflits. Par exemple, si un test modifie l'état d'une base de données ou d'un système de fichiers, cela peut affecter d'autres tests qui s'exécutent par la suite.
• Dépendances externes : L'utilisation de services externes, d'APIs ou de bases de données externes peut causer des instabilités. Les tests peuvent échouer si ces services sont temporairement non disponibles ou si leurs réponses sont imprévisibles.

Comment gérer les tests flakies ?

• Stabilisation des tests : Attentes explicites : Utilisez des attentes explicites pour attendre que les éléments soient présents et visibles avant d'interagir avec eux. Par exemple, avec des outils comme Selenium, cela pourrait impliquer l'utilisation de WebDriverWait pour attendre des conditions spécifiques. Retries automatiques : Implémentez une logique de réessai pour relancer un test échoué après un court délai. Cela peut aider à réduire le nombre d'échecs dus à des problèmes temporaires.
• Isolation des tests : Tests indépendants : Assurez-vous que chaque test est indépendant, en évitant les effets de bord. Utilisez des données de test isolées pour chaque test, plutôt que de partager des ressources ou des états. Nettoyage après les tests : Implémentez des mécanismes de nettoyage pour réinitialiser l'état après chaque test, assurant ainsi qu'aucun test n'affecte les autres.
• Utilisation de mocks et de stubs : Éviter les dépendances externes : Utilisez des mocks ou des stubs pour remplacer les dépendances externes lors des tests, afin de réduire la variabilité due à des services tiers.

Le TDD est une méthode où les tests sont écrits avant le code de production ou la logique. Quand on utilise le TDD, on suit le processus en trois étapes :

• Écrire un test qui échoue (red).
• Écrire le code minimal nécessaire pour faire passer le test (green).
• Refactoriser le code pour améliorer la qualité tout en s'assurant que les tests passent toujours (refactor).

Les avantages du TDD sont

• Qualité du code améliorée : Les tests aident à identifier les bogues dès le début du développement.
• Documentation vivante : Les tests servent de documentation pour le comportement du système.
• Confiance lors des changements : Les développeurs peuvent modifier le code en toute confiance, sachant que les tests détectent les régressions.

Les types de tests sont:

• Tests unitaires : Vérifient des unités de code isolées (par exemple, des fonctions ou des classes).
• Tests d'intégration : Vérifient l'interaction entre différentes unités de code.
• Tests fonctionnels : Évaluent des fonctionnalités entières du système selon les exigences spécifiées.
• Tests d'acceptation : Assurent que le système répond aux critères d'acceptation des utilisateurs.
• Tests de Smoke : c'est une série de tests préliminaires pour vérifier que les principales fonctionnalités d'une application fonctionnent après un déploiement ou une mise à jour. L'objectif est de s'assurer que le build est stable avant de procéder à des tests plus approfondis.

TDD s'intègre avec les méthodologies Agile en favorisant un développement itératif et incrémental. Les tests peuvent être écrits pendant les sprints, et les résultats des tests guident le développement et les ajustements. Cela renforce la collaboration entre les équipes, car les tests aident à clarifier les exigences et à garantir que le produit respecte les attentes des utilisateurs.

• Temps d'exécution des tests : Si les tests sont lents, cela peut ralentir le développement. Les tests unitaires doivent être rapides.
• Complexité de l'écriture des tests : Pour des fonctionnalités complexes, écrire des tests peut nécessiter un effort important.
• Pression pour livrer rapidement : Les équipes peuvent être tentées de négliger les tests pour respecter des délais serrés, ce qui peut compromettre la qualité du code.
• Résistance au changement : Certains développeurs peuvent être réticents à adopter TDD en raison d'habitudes bien ancrées.

Pour moi, les meilleures pratiques pour écrire des tests unitaires efficaces sont si :

• Isolation : on assure que les tests unitaires ne dépendent pas d'autres tests ou de l'état global.
• Noms clairs : on donne aux tests des noms descriptifs qui indiquent leur intention.
• Simplicité : on écrit des tests simples qui vérifient une seule fonctionnalité à la fois.
• Rapidité : Les tests doivent s'exécuter rapidement pour permettre un retour d'information rapide.
• Utilisation d'assertions claires : on utilise des assertions qui décrivent clairement ce qui est attendu.

L'adoption du TDD nécessite un changement de mentalité. De nombreux développeurs ont l'habitude d'écrire le code d'abord et de tester ensuite. Le TDD impose une inversion de cette logique, où l'écriture des tests précède le développement du code. Cela peut être difficile pour les équipes habituées à des pratiques plus traditionnelles.

Solution : Pour surmonter cela, j'ai investi du temps dans la formation et l'accompagnement des équipes pour les sensibiliser aux avantages à long terme du TDD (qualité de code améliorée, réduction de la dette technique, meilleure documentation). J'ai aussi montré des exemples concrets d'améliorations sur des projets où TDD a été adopté.

La Clean Architecture, c'est un modèle d'architecture logicielle basé sur des couches concentriques qui respectent le principe d'inversion des dépendances.

L'idée principale est de séparer clairement les préoccupations, en plaçant les règles métier (core business) au centre et en les isolant des dépendances externes comme les bases de données, frameworks, et interfaces utilisateur.

Structure

La Clean Architecture est généralement représentée sous forme de cercles concentriques avec les couches suivantes (du centre vers l'extérieur) :

• Entities (Entités) : — Contient les règles métier fondamentales, indépendantes de tout framework ou technologie. — Exemples : Calcul d'impôts, validation de règles métier.
• Use Cases (Cas d'utilisation) : — Définit les actions spécifiques de l'application (logique applicative). — Coordonne les entités pour accomplir des tâches métier. — Exemples : "Créer un utilisateur", "Passer une commande".
• Interface Adapters (Adaptateurs) : — Traduit les données pour qu'elles soient compréhensibles par les couches externes et internes. — Exemples : DTOs, contrôleurs API, mappers.
• Frameworks and Drivers (Frameworks et pilotes) : — Contient les détails techniques et les outils externes, comme les bases de données, les frameworks web, les bibliothèques, etc. — Exemples : Express.js, MongoDB, RabbitMQ.

Fonctionnement

• Les dépendances vont toujours de l'extérieur vers l'intérieur.
• Les couches internes ne doivent jamais dépendre des couches externes.
• Exemple : La logique métier n'a pas besoin de connaître le type de base de données utilisé, car elle passe par des interfaces définies dans les couches internes.

But

• Maintenir la logique métier indépendante des détails techniques.
• Faciliter les tests unitaires en isolant les règles métier.
• Rendre l'application résistante aux changements technologiques (exemple : remplacer une base de données avec un autre moteur).

---

Concept

L'architecture hexagonale, introduite par Alistair Cockburn, est un modèle qui met l'accent sur l'interaction entre le cœur métier et le monde extérieur. Elle utilise les concepts de ports (interfaces définies par le domaine) et adaptateurs (implémentations concrètes des interfaces).

L'objectif est de rendre le code indépendant des mécanismes d'entrée et de sortie (par exemple, les API, bases de données, etc.).

Structure

Elle est souvent représentée comme un hexagone avec les éléments suivants :

• Core Business Logic (Cœur métier) : — Contient les règles métier et les cas d'utilisation. — Est totalement indépendant des couches externes.
• Ports : — Interfaces qui définissent les points d'entrée et de sortie du cœur métier. — Exemples : — Ports d'entrée : Interfaces pour les contrôleurs ou les scripts CLI. — Ports de sortie : Interfaces pour la communication avec des bases de données, des services externes, etc.
• Adapters (Adaptateurs) : — Implémentations concrètes des ports, situées en périphérie. — Exemples : Un contrôleur REST est un adaptateur d'entrée ; un dépôt qui interagit avec une base de données est un adaptateur de sortie.
• Monde extérieur : — Les outils ou services externes qui interagissent avec les adaptateurs, comme des frameworks, des bases de données ou des services tiers.

Fonctionnement

• Les dépendances sont dirigées vers le cœur métier.
• Les ports définissent comment le cœur métier interagit avec les éléments externes, mais n'en connaissent pas les détails.
• Les adaptateurs fournissent des implémentations concrètes pour les interactions externes.

But

• Découpler le cœur métier des technologies externes.
• Faciliter les tests unitaires en simulant les adaptateurs avec des implémentations factices (mocks).
• Rendre l'application flexible pour intégrer de nouveaux moyens d'interaction (par exemple, ajouter une interface CLI à une application REST).

---

Clean Architecture VS Hexagonale Contribution à la mise en place d'architecture

Lors de la mise en place de l'architecture hexagonale, j'ai réalisé les tâches suivantes :

Analyse et Conception :

• J'ai participé activement aux ateliers techniques pour identifier les différents domaines fonctionnels et déterminer les frontières entre les couches métiers et techniques, pour découpler clairement le domaine métier des détails techniques (accès aux données, services externes, etc.). Implémentation du cœur métier :
• J'ai implémenté des services métiers indépendants de toute technologie spécifique, en respectant le principe de la règle métier isolée. en assurant la cohérence de la logique métier en développant des cas d'utilisation (use cases) clairement définis et testables de manière isolée.

Développement des adaptateurs (entrée/sortie) :

• J'ai créé des adaptateurs entrants (contrôleurs d'API, gestionnaires d'événements) et sortants (persistance en base de données, appels à des APIs externes), assurant ainsi que chaque adaptateur communique avec le cœur métier uniquement à travers les ports définis.
• J'ai veillé à la séparation nette entre ces adaptateurs et le code métier pour faciliter l'évolutivité et la testabilité. Tests et Validation :

• J'ai mis en place des tests unitaires et d'intégration pour valider chaque composant de manière indépendante, ainsi que des tests de bout en bout pour vérifier l'ensemble du fonctionnement.
• J'ai vérifié que l'architecture mise en place respectait les principes d'isolation du métier et de testabilité accrue, facilitant ainsi la maintenance. Documentation et partage :

• J'ai rédigé la documentation technique détaillant l'architecture choisie, les flux d'interaction, et les principes à respecter par les équipes techniques.
• J'ai animé ou participé à des revues de code et des sessions de partage pour m'assurer que l'équipe adhère à l'architecture choisie.

DOD et DOR

DOD – Definition of Done (Définition de Terminé)

C'est une checklist qui définit les critères minimaux qu'un élément (user story, tâche, bug) doit satisfaire pour être considéré comme "terminé" et potentiellement livrable.

Elle est utilisée à la fin du développement pour s'assurer que :

• Le code est écrit, compilé et fonctionne.

• Les tests unitaires sont passés.

• Le code est relu (code review effectuée).

• Le produit est testé fonctionnellement et validé.

• La documentation est mise à jour (si nécessaire).

• La story a été démontrée au Product Owner.

📌 Exemple de DOD :

• Code poussé sur la branche principale

• Tests automatisés écrits et passés à 100 %

• Aucun bug bloquant

• Fonctionnalité validée en démonstration

• Documentation utilisateur mise à jour

🟨 DOR – Definition of Ready (Définition de Prêt)

C'est une checklist qui définit quand une user story (ou un élément du backlog) est suffisamment claire, détaillée et estimable pour être prise en charge par l'équipe de développement.

Elle est utilisée AVANT d'entrer dans un sprint (au moment du raffinement).

📌 Exemple de DOR :

• La user story est rédigée selon le format "En tant que... Je veux... Afin de..."

• Les critères d'acceptation sont clairs

• Les dépendances sont identifiées

• L'estimation en points est faite

• Le design ou prototype est disponible si nécessaire

Le Three Amigos Meeting est une réunion qui implique trois rôles principaux : le développeur, le testeur et le représentant du métier (product owner ou analyste business). Ce meeting a pour objectif de :

• Clarifier les exigences et les comportements attendus.
• Discuter des scénarios possibles et éliminer toute ambiguïté.
• Assurer que tous les angles (métier, test, technique) sont couverts dans les scénarios Gherkin.

L'impact de ce processus est pour la qualité des scénarios, car il permet de détecter les éventuels malentendus avant que le développement ne commence. Cela favorise la création de scénarios plus réalistes et exécutables.

Dans la méthodologie Agile Scrum, le cycle de développement est divisé en plusieurs étapes, qui permettent à l'équipe de collaborer et d'itérer rapidement sur les fonctionnalités. Les étapes principales d'un cycle Scrum:

Sprint Planning (Planification du Sprint)

• Objectif : Définir les tâches à accomplir pendant le prochain sprint.
• Description : L'équipe Scrum (développeurs, Product Owner, Scrum Master) se réunit pour décider quelles user stories du backlog seront développées dans le sprint à venir, en fonction de leur priorité et de la capacité de l'équipe.
• Résultat : Un Sprint Backlog, qui est la liste des tâches ou user stories que l'équipe s'engage à réaliser pendant le sprint (généralement 1 à 4 semaines).

Sprint (Développement du Sprint)

• Objectif : Développer, tester et livrer les fonctionnalités définies dans le Sprint Backlog.
• Description : Le sprint représente la période durant laquelle l'équipe travaille pour développer les fonctionnalités prévues. Durant cette phase, l'équipe de développement s'efforce de compléter les tâches définies tout en respectant les critères d'acceptation.
• Durée : Un sprint dure généralement entre 1 et 4 semaines.

Daily Scrum (Scrum quotidien)

• Objectif : Coordonner l'équipe et résoudre les obstacles.
• Description : Chaque jour, l'équipe se réunit pour une courte réunion (15 minutes maximum) appelée stand-up. Chaque membre partage :Ce qu'il a fait depuis la dernière réunion.Ce qu'il compte faire aujourd'hui.Les obstacles ou blocages qu'il rencontre.
• Résultat : L'équipe est alignée sur les progrès et peut réagir rapidement aux obstacles.

Sprint Review (Revue de Sprint)

• Objectif : Présenter le travail accompli et recueillir des retours des parties prenantes.
• Description : À la fin de chaque sprint, l'équipe présente les fonctionnalités développées aux parties prenantes (Product Owner, clients, managers). C'est l'occasion de recueillir des retours sur les fonctionnalités et d'ajuster les priorités pour les futurs sprints.
• Résultat : Les fonctionnalités potentiellement livrables sont démontrées, et des ajustements peuvent être apportés au backlog en fonction des retours reçus.

Sprint Retrospective (Rétrospective du Sprint)

• Objectif : Améliorer les processus internes de l'équipe.
• Description : Après chaque sprint, l'équipe Scrum se réunit pour discuter de ce qui a bien fonctionné et des aspects à améliorer. Cette étape est cruciale pour l'amélioration continue. L'équipe peut identifier des actions concrètes à prendre pour rendre le prochain sprint plus productif ou plus fluide.
• Résultat : Un plan d'action pour améliorer le processus, la collaboration, ou l'efficacité de l'équipe dans le sprint suivant.

Backlog Refinement (Affinage du Backlog)

• Objectif : Préparer les user stories pour les futurs sprints.
• Description : Bien que ce ne soit pas une cérémonie formelle dans tous les frameworks Scrum, l'affinage du backlog est une étape cruciale. L'équipe et le Product Owner travaillent ensemble pour s'assurer que les user stories dans le backlog sont bien définies, priorisées, et prêtes à être prises en charge dans un sprint futur.
• Résultat : Un product backlog plus clair, avec des user stories bien définies et estimées, prêtes pour les prochains sprints.

J'ai constaté que les cérémonies Agile (daily stand-ups, sprint reviews, etc.) favorisent une meilleure collaboration au sein de l'équipe. Le fait de se rencontrer régulièrement permet de résoudre les problèmes rapidement, d'éviter des malentendus et de partager plus facilement des idées. Par exemple, lors d'un projet complexe avec plusieurs développeurs juniors, les stand-ups quotidiens ont permis d'éviter des retards en identifiant rapidement des blocages.

Cela renforce la transparence et la cohésion d'équipe, et on peut détecter plus tôt les problèmes potentiels.

Agile aussi permet de s'adapter rapidement aux changements de priorités. Par exemple, lors d'un projet, des besoins imprévus venant des utilisateurs finaux ont émergé en milieu de sprint. Grâce à l'approche Agile, nous avons pu ajuster le backlog et prioriser ces besoins sans perturber l'ensemble du projet.

Impact : J'apprécie particulièrement la capacité à livrer des incréments fonctionnels rapidement, ce qui permet d'obtenir des retours d'utilisateurs précoces et d'ajuster le produit en conséquence.

J'apprécie beaucoup Agile Scrum pour sa flexibilité et sa capacité à renforcer la communication dans l'équipe. Mais s'il y a un point que je trouve parfois moins efficace, c'est quand la méthode devient trop rigide ou appliquée mécaniquement, sans l'adapter au contexte.

Par exemple, j'ai vu des cas où les cérémonies (daily, retro, planning…) étaient faites "par obligation", sans réelle valeur ajoutée, juste pour "cocher une case". Résultat : perte de temps, ou même lassitude dans l'équipe.

Un autre point, c'est que dans certains environnements, le changement de priorités trop fréquent, même en cours de sprint, peut créer de la frustration : on a l'impression de ne jamais terminer ce qu'on a commencé.

Enfin, si le Product Owner n'est pas assez disponible ou clair sur les priorités, le backlog peut devenir flou, et l'équipe perd du temps à interpréter ou à deviner les besoins.

Donc pour moi, Scrum fonctionne très bien à condition qu'il soit bien compris, adapté au contexte et soutenu par une vraie collaboration entre les rôles.

La Definition of Done (DoD) est une liste de conditions minimales obligatoires qu'un ticket (user story, tâche, bug) doit remplir pour être considéré comme "terminé" dans un projet Agile (Scrum, Kanban, etc.).

Elle est définie collectivement par l'équipe (développeurs, QA, PO, Scrum Master) et doit être claire, mesurable et partagée.

Conditions typiques pour valider un ticket DoD

• Code
• Le code est développé et compilé sans erreur
• Il respecte les standards de l'équipe (linters, conventions, etc.)
• Il est pushé et commité dans le bon repo / branche

• Tests
• Les tests unitaires sont écrits et passent
• Les tests d'intégration sont couverts si pertinents
• Les tests E2E ou manuels ont été exécutés
• Aucune régression n'est détectée dans les tests

• Revue / validation
• Le code a été relu et approuvé en peer review (pull request)

• Les retours de revue ont été traités
• Le ticket est validé par le QA ou le Product Owner (PO)

• Documentation / traçabilité

• Les commentaires ou doc techniques sont mis à jour si besoin La documentation fonctionnelle ou utilisateur est à jour (si nécessaire)
• Le ticket est bien lié au bon commit ou merge request

• Déploiement / environnement
• La fonctionnalité est déployée en environnement de test ou staging Elle est intégrée dans la CI/CD
• Elle est prête à être livrée en production sans modifications

• Valeur métier
• Le comportement attendu est respecté
• Tous les critères d'acceptation sont vérifiés
• Le PO confirme que la valeur métier est livrée

C'est un ticket qui est compréhensible, estimable, priorisé, et sans dépendances bloquantes. Il peut être confié à un développeur sans besoin de clarifications majeures.

Conditions typiques pour qu'un ticket respecte la DoR

• Clarté: Le titre et la description sont clairs et compréhensibles
• Objectif métier Le besoin ou la valeur métier est bien exprimé
• Critères d'acceptation: Ils sont définis, concrets et testables (Given / When / Then si besoin)
• Compréhension partagée: Le ticket a été présenté ou expliqué à l'équipe en refinement ou grooming
• Pas de dépendances bloquantes: Aucun ticket ou composant externe ne bloque son démarrage
• Estimable: L'équipe peut lui attribuer une estimation (temps ou story points)
• Priorisation: Le Product Owner l'a validé comme prioritaire ou prêt à être pris
• Testabilité: Il est testable (techniquement ou fonctionnellement)
• Design ou maquette disponibles: Si requis (UI/UX), les specs sont jointes au ticket
• Données ou environnement prêts: Si le ticket implique des prérequis (ex : base de test), ils sont prêts

J'ai l'habitude de collaborer avec l'équipe UI/UX à travers des outils de design comme Figma ou Zeplin. Ces plateformes facilitent la collaboration en fournissant des spécifications claires pour les développeurs (mesures, couleurs, typographies, etc.). Lors d'un projet récent, j'ai utilisé Figma pour laisser des commentaires directement sur les maquettes, ce qui a accéléré la résolution de certaines incohérences entre les besoins UI/UX et les contraintes techniques.

Impact : L'utilisation de ces outils rend la collaboration plus fluide et permet d'assurer que l'implémentation du design correspond exactement à la vision de l'équipe UI/UX, tout en facilitant les ajustements en temps réel.

En tant que développeur senior, je comprends que l'expérience utilisateur (UX) est aussi importante que la qualité du code. Par exemple, dans un projet où la rapidité d'interaction était essentielle, nous avons optimisé certains composants front-end pour réduire les temps de chargement et améliorer la fluidité des transitions. J'ai travaillé avec l'équipe UI/UX pour ajuster les animations afin de trouver un bon équilibre entre performance et esthétique.

Je collabore étroitement avec le Product Owner tout au long du projet. En général, notre échange commence dès la phase de refinement, où je participe activement à la clarification des user stories. J'essaie de poser les bonnes questions pour bien comprendre les besoins métier, les cas limites, et anticiper les contraintes techniques.

Ensuite, pendant le sprint, je reste en contact régulier avec le PO — que ce soit via Slack, des points informels, ou lors des daily meetings — pour lever rapidement les ambiguïtés ou discuter des ajustements éventuels.

Je n'hésite pas à faire des démos intermédiaires si un sujet est sensible ou flou, pour valider l'orientation avant d'aller trop loin dans le développement.

En sprint review, je présente les fonctionnalités que j'ai développées et j'écoute les retours du PO et des parties prenantes. Ça permet de s'assurer que le produit reste aligné avec les attentes.

J'apprécie quand le PO est accessible, clair dans ses priorités et ouvert à l'échange. Et de mon côté, j'essaie toujours d'apporter une vision technique pragmatique pour aider à prendre de bonnes décisions produit.

Différence entre PO et dev Si le PO me demande une fonctionnalité urgente et que j'estime qu'elle prend 4 jours alors qu'il pense que ça peut être fait en 1 jour, je ne rentre pas dans un débat frontal. Mon réflexe, c'est de clarifier ensemble ce qu'il attend exactement. Très souvent, il peut y avoir une différence de perception sur la complexité ou les impacts techniques.

Donc je prends le temps de lui expliquer pourquoi ça prend 4 jours : par exemple, parce que ça touche plusieurs composants, ou qu'il faut gérer des cas particuliers, des tests, ou une intégration avec un service externe.

Ensuite, je propose une alternative si c'est vraiment urgent :

– Soit on découpe la fonctionnalité pour livrer une version plus simple en 1 jour (MVP), puis on complète dans un second temps. – Soit on dépriorise autre chose si cette demande est devenue plus importante.

Ce qui compte pour moi, c'est de trouver une solution ensemble, en étant transparent, tout en respectant la qualité du code et la maintenabilité du produit.

Je travaille avec l'équipe Produit comme un partenaire plutôt que comme un simple exécutant.

Lorsqu'un besoin est présenté, mon premier réflexe est de comprendre le problème utilisateur et l'objectif métier avant de parler de solution technique.

Je pose souvent des questions comme :

• Quel problème cherche-t-on à résoudre ?
• Qui sont les utilisateurs concernés ?
• Comment fait-on aujourd'hui ?
• Comment mesurera-t-on le succès de cette évolution ?
• Existe-t-il des contraintes réglementaires ou métier particulières ?

Une fois le besoin compris, je participe aux ateliers de conception avec le Product Manager, le Product Designer et parfois les équipes métier afin de trouver la solution la plus adaptée.

Mon rôle est aussi d'apporter une vision technique. J'explique les impacts, les risques, les dépendances, les coûts de maintenance ou les conséquences sur les parcours existants afin que les décisions soient prises avec tous les éléments en main.

J'essaie également de proposer des alternatives lorsqu'une solution me paraît trop complexe par rapport à la valeur apportée à l'utilisateur.

Si je propose une idée et qu'elle est déclinée au profit d'une autre solution, je l'accepte sans problème.

Mon but, ce n'est pas d'imposer mon idée, mais de trouver la meilleure solution pour l'équipe et le produit. Si une autre approche est choisie parce qu'elle est plus simple, plus rapide, ou plus adaptée au contexte, je joue collectif.

Évidemment, si je pense qu'il y a un risque technique ou fonctionnel, je le signale avec des faits. Mais si après discussion, on tranche autrement, je passe à autre chose — sans blocage ni ego.

Par expérience, il vaut mieux avancer ensemble sur une décision imparfaite que bloquer sur un désaccord. Et parfois, on revient plus tard sur mon idée si elle devient plus pertinente dans un autre contexte.

Je considère qu'un désaccord technique est normal dans une équipe. Si une personne n'est pas d'accord avec mon idée, j'écoute ses arguments et j'essaie de comprendre ce que je n'ai peut-être pas vu.

Il m'est arrivé plusieurs fois de changer d'avis après une discussion.

Mon objectif n'est pas que mon idée soit retenue, mais que l'équipe prenne la meilleure décision possible.

Exemple

Chez OUIGO, sur certains sujets d'anomalies ou d'évolutions complexes, il m'est arrivé de proposer une solution différente de celle initialement envisagée.

Je commençais par analyser l'impact métier, les risques techniques et la charge de développement.

Ensuite, je présentais plusieurs options avec leurs avantages et leurs limites.

Cela permettait au Product Owner, au Tech Lead et à l'équipe de prendre une décision éclairée plutôt que de suivre une intuition.

J'essaie d'influencer par l'argumentation et les faits plutôt que par l'autorité.

Quand j'ai une idée ou une proposition technique, je commence toujours par expliquer le problème que je cherche à résoudre et la valeur que cela apporte à l'équipe ou au produit.

Par exemple, si je propose une évolution d'architecture ou un changement de pratique, je présente les avantages, les inconvénients, les impacts sur la maintenance, les performances, la qualité ou la productivité de l'équipe.

J'évite les débats basés sur les préférences personnelles du type "j'aime cette technologie". Je préfère m'appuyer sur des éléments concrets : retour d'expérience, métriques, complexité de mise en œuvre ou coût de maintenance.

Exemple de proposition idée

Sur un projet, on avait beaucoup de logique de validation dispersée dans plusieurs composants.

J'ai proposé de centraliser ces règles avec une approche basée sur Zod afin d'éviter les incohérences entre le frontend et les règles métier.

Au lieu d'arriver avec une solution toute faite, j'ai préparé un petit exemple, montré les problèmes actuels et expliqué les bénéfices attendus.

Cela a permis à l'équipe de comparer objectivement les approches et la proposition a finalement été adoptée.

Oui, plusieurs fois. En tant que développeur, on fait souvent face à des environnements à forte pression : délais serrés, incidents en production, demandes métiers urgentes ou pivot de dernière minute.

L'une des situations les plus stressantes que j'ai vécues, c'était lors d'une mise en production critique juste avant le gel de production. Une régression avait été détectée dans un composant clé quelques heures avant le déploiement.

Ce que j'ai fait :

• J'ai proposé de couper le problème en petits morceaux et d'identifier le périmètre exact du bug.
• J'ai travaillé en binôme avec un QA pour tester rapidement les cas impactés.
• On a corrigé le bug, écrit un test unitaire pour s'assurer qu'il ne reviendra pas, et communiqué avec le product owner pour prioriser un patch rapide mais maîtrisé.

Résultat :

• La mise en production a été maintenue avec succès.
• L'équipe a apprécié la gestion de crise calme et collaborative.
• On a ensuite proposé un postmortem pour éviter que ça se reproduise (amélioration du coverage et intégration continue).

Je n'ai pas eu un poste officiel de manager avec des entretiens annuels, la gestion des congés ou le pilotage hiérarchique d'une équipe.

En revanche, j'ai régulièrement occupé un rôle de référent technique sur les sujets Frontend.

Par exemple, sur mes dernières missions, j'étais souvent sollicité pour les choix d'architecture, les revues de code, l'analyse des sujets complexes et l'accompagnement des développeurs moins expérimentés.

Je participais également aux refinements et aux ateliers de conception afin d'apporter une vision technique et d'identifier les risques en amont.

Sur certains sujets, lorsqu'une anomalie complexe arrivait en production, c'était souvent moi qui réalisais l'analyse technique, proposais la stratégie de correction et accompagnait les autres développeurs jusqu'à la mise en production.

J'ai aussi l'habitude de partager mes connaissances à travers les code reviews, les présentations techniques ou le pair programming.

Aujourd'hui, je me sens à l'aise dans un rôle de référent technique Frontend ou React Native. Le management hiérarchique n'a pas encore été une responsabilité officielle dans mon parcours, mais l'accompagnement technique et le leadership d'influence font déjà partie de mon quotidien.

Vous estimez trois semaines. Que faites-vous pendant ces trois semaines ?

Je ne développe pas trois semaines sans échanger.

Je commence par clarifier le besoin avec vous :

• quel problème utilisateur voulons-nous résoudre ?
• quel est le parcours cible ?
• quels sont les critères d'acceptation ?
• existe-t-il un MVP ?

Ensuite, je découpe la fonctionnalité en incréments plus petits.

Cela permet d'avoir des démonstrations régulières et d'obtenir rapidement des retours.J'évite autant que possible les développements très longs sans validation intermédiaire.

Et si je change d'avis au bout d'une semaine ?

C'est une situation classique. Si le travail est découpé en petites User Stories, l'impact reste limité.

On peut réévaluer la priorité, ajuster le backlog et adapter la suite du développement. C'est aussi pour cela que je préfère livrer progressivement plutôt qu'attendre trois semaines avant de montrer quelque chose.