Liste des formations

Des difficultés à comprendre quels sont les comportements attendus du logiciel en relisant le code ? Des soucis d'alignement entre les attentes du métier et ce qui est livré en production ? À partir d'une User Story , il est compliqué de savoir par où commencer, quoi tester, quand s'arrêter et ce qu'on en attend ? Si tel est votre cas, le Behavior-Driven Development peut vous aider ! Le Behavior-Driven Development (BDD) est une façon de penser, concevoir et coder les fonctionnalités, pilotée par les comportements attendus. Sa double boucle ATDD/TDD permet d'outrepasser les limitations du bottom-up inhérentes au Test-Driven Development seul. Il permet une fluidification de la communication avec les expert·e·s métier, un meilleur alignement du code avec le besoin, l'écriture de tests fonctionnels solides et la documentation efficace du logiciel. La formation s'effectue sous forme d'ateliers pratiques et de séquences théoriques interactives. : Découverte à travers l'Exemple Mapping : Découvrir le besoin. Ancrer le langage commun, faire émerger les différents scénarios métiers d'un cas fonctionnel, faciliter la communication entre le métier et les développeurs et développeuses. Formulation : Décrire les scénarios fonctionnels, Quand et comment utiliser (ou non) le Given When Then Automatisation : Bien structurer ses tests, comment découpler ses tests des données de tests. Implémentation via la double boucle ATDD/TDD. Jour 1 matin – Introduction et découverte des besoins Introduction au BDD : historique, principes, place dans l'agilité. Le rôle des Three Amigos : Métier, Développeur, Testeur. La conversation avant la documentation : “Shared documents aren't shared understanding”. Atelier pratique : Jeu de découverte et Example Mapping Identifier les règles, exemples et questions. Faire émerger un langage commun et des cas limites. Structurer les échanges autour d'un besoin fonctionnel simple. Jour 1 après-midi – Structurer et formuler les scénarios fonctionnels Introduction à la formulation De la découverte à la documentation. Structure Gherkin : Given (contexte) / When (action) / Then (résultat) . L'acronyme BRIEF : B – Business language : langage métier partagé. R – Real data : données concrètes révélant les règles. I – Intention revealing : exprimer le “pourquoi”, pas le “comment”. E – Essential : aller à l'essentiel. F – Focused : un scénario = une règle métier. Atelier pratique : Scénarios cliniques Analyse de scénarios “pathologiques”. Réécriture collective selon BRIEF. Partage et validation en groupe. Jour 2 matin : Cas d'école – Pandemic Introduction du cas d'école : Pandemic Présentation du jeu et de ses règles principales. Identification des fonctionnalités à modéliser : propagation ( infection ) et éclosion . Discussion sur la notion de “comportement attendu”. Découpage des règles en features Reformulation des règles en comportements observables. Sélection des règles prioritaires pour l'atelier. Atelier pratique : Example Mapping Construction des cartes “règle / exemple / question”. Détection des ambiguïtés et clarifications collectives. Formulation des scénarios BDD Passage des exemples aux scénarios Given / When / Then . Application du cadre BRIEF (Business language, Real data, Intention revealing, Essential, Focused). Implémentation avec Cucumber (Java ou Kotlin) Création du projet et mise en place de la structure de test. Implémentation et exécution des scénarios. Discussion sur la valeur ajoutée du couplage Example Mapping → Formulation → Automation . Jour 2 après-midi : Cas pratique collectif Choix du sujet Exemple proposé : Shomulator (simulateur du modele social de Shodo). Ou cas concret apporté par les participants (besoin réel d'un projet). Atelier : Example Mapping complet Définition du périmètre et du vocabulaire métier partagé. Identification des règles, exemples et questions. Construction du langage commun. Rédaction et partage des scénarios Structuration des scénarios avec Given / When / Then . Vérification de leur cohérence et de leur lisibilité. Discussion sur la transposition potentielle vers l'automatisation. Débrief collectif et synthèse Retours d'expérience : aspects humains, techniques et méthodologiques. Discussion sur la mise en place concrète du BDD dans les projets des participants. Mise en perspective : apprentissages du cas Pandemic vs contexte réel.

Avez-vous déjà observé qu'il n'est pas toujours facile d'aligner le développement logiciel ou l'architecture du système d'information avec les besoins métier ? Les concepts fonctionnels discutés peuvent être confus et la technique pollue souvent les discussions avec les expert·e·s du métier si bien que l'on pousse souvent des solutions avant d'avoir une compréhension profonde du besoin. D'ailleurs, il n'est pas forcément très simple de se comprendre, car chaque personne peut avoir une compréhension différente du même concept fonctionnel. Comment s'y prendre pour avoir un découpage du système d'information et/ou du logiciel aligné sur le métier tout en prenant en compte les contraintes opérationnelles ? Le Domain-Driven Design est une philosophie qui vise à remettre le métier au centre du développement logiciel en s'intéressant tout particulièrement à l'art de la modélisation. Les patterns du Domain-Driven Design Stratégique visent à dissocier, cartographier et modéliser l'espace du problème de celui de la solution afin de faire émerger un langage commun partagé par toutes et tous. Ceci permet de construire une compréhension et une vision collective du besoin à adresser. Le Domain-Driven Design Stratégique permet de construire solutions d'architecture alignées sur le besoin métier qui prennent en compte les différents rapports de force opérationnels (priorisation, organisation…). La formation s'effectuera sous forme d'ateliers de mise en pratique ainsi que de cours théoriques: Demi-journée 1 : L'art de la modélisation : Comprendre pourquoi le Domain-Driven Design, ce qu'est la modélisation de l'espace du problème et de la solution. Demi-journée 2 : EventStorming : Modéliser son système en évènements métier afin de faire émerger les sous contextes métier (bounded-contexts), langage commun et omniprésent (ubiquitous language), les dynamiques de communication interpersonnelles et la compréhension collective du métier. Demi-journée 3 et 4: Context Map : Cartographie des domaines métiers avec leurs interdépendances, leur niveau de couplage et l'interaction des équipes en charge de ces domaines.

Le Domain Driven Design (DDD) permet de modéliser efficacement les besoins métier afin de mieux gérer la complexité des logiciels. Traditionnellement associé à la Programmation Orientée Objet, les patterns tactiques du DDD peuvent toutefois être adaptées pour utiliser cette approche avec la Programmation Fonctionnelle. La Programmation Fonctionnelle est un paradigme qui favorise des techniques comme l'immutabilité, les fonctions pures et la composition fonctionnelle pour créer un code plus prévisible et maintenable. Le langage TypeScript est à cheval entre les approches objets et fonctionnelles, et présente des particularités qui peuvent rendre difficile l'adoption du DDD selon l'un de ces deux paradigmes. Cette formation vous propose de découvrir des approches adaptées spécifiquement à TypeScript qui intègrent les avantages de la programmation fonctionnelle avec la structuration de données sous forme d'objets dans un cadre DDD. Vous apprendrez comment implémenter des modèles métier efficacement et en restant pragmatique sur l'utilisation du paradigme fonctionnel pour créer des logiciels robustes et maintenables.