ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/docs/fr/explanation/why-solutioning-matters.md

4.7 KiB
Raw Permalink Blame History

title description sidebar
Pourquoi le Solutioning est Important Comprendre pourquoi la phase de solutioning est critique pour les projets multi-epics
order
3

La Phase 3 (Solutioning) traduit le quoi construire (issu de la Planification) en comment le construire (conception technique). Cette phase évite les conflits entre agents dans les projets multi-epics en documentant les décisions architecturales avant le début de l'implémentation.

Le Problème Sans Solutioning

Agent 1 implémente l'Epic 1 avec une API REST
Agent 2 implémente l'Epic 2 avec GraphQL
Résultat : Conception d'API incohérente, cauchemar d'intégration

Lorsque plusieurs agents implémentent différentes parties d'un système sans orientation architecturale partagée, ils prennent des décisions techniques indépendantes qui peuvent entrer en conflit.

La Solution Avec le Solutioning

le workflow architecture décide : "Utiliser GraphQL pour toutes les API"
Tous les agents suivent les décisions d'architecture
Résultat : Implémentation cohérente, pas de conflits

En documentant les décisions techniques de manière explicite, tous les agents implémentent de façon cohérente et l'intégration devient simple.

Solutioning vs Planification

Aspect Planification (Phase 2) Solutioning (Phase 3)
Question Quoi et Pourquoi ? Comment ? Puis Quelles unités de travail ?
Sortie FRs/NFRs (Exigences)1 Architecture + Epics2/Stories3
Agent PM Architect → PM
Audience Parties prenantes Développeurs
Document PRD4 (FRs/NFRs) Architecture + Fichiers Epics
Niveau Logique métier Conception technique + Décomposition du travail

Principe Clé

Rendre les décisions techniques explicites et documentées pour que tous les agents implémentent de manière cohérente.

Cela évite :

  • Les conflits de style d'API (REST vs GraphQL)
  • Les incohérences de conception de base de données
  • Les désaccords sur la gestion du state
  • Les inadéquations de conventions de nommage
  • Les variations d'approche de sécurité

Quand le Solutioning est Requis

Parcours Solutioning Requis ?
Quick Dev Non - l’ignore complètement
Méthode BMad Simple Optionnel
Méthode BMad Complexe Oui
Enterprise Oui

:::tip[Règle Générale] Si vous avez plusieurs epics qui pourraient être implémentés par différents agents, vous avez besoin de solutioning. :::

Conséquences de sauter la phase de Solutioning

Sauter le solutioning sur des projets complexes entraîne :

  • Des problèmes d'intégration découverts en milieu de sprint5
  • Du travail répété dû à des implémentations conflictuelles
  • Un temps de développement plus long globalement
  • De la dette technique6 due à des patterns incohérents

:::caution[Coût Multiplié] Détecter les problèmes d'alignement lors du solutioning est 10× plus rapide que de les découvrir pendant l'implémentation. :::

Glossaire

  1. FR / NFR (Functional / Non-Functional Requirement) : exigences décrivant respectivement ce que le système doit faire (fonctionnalités, comportements attendus) et comment il doit le faire (contraintes de performance, sécurité, fiabilité, ergonomie, etc.). ↩︎

  2. Epic : dans les méthodologies agiles, une unité de travail importante qui peut être décomposée en plusieurs stories plus petites. Un epic représente généralement une fonctionnalité majeure ou un objectif métier. ↩︎

  3. Story (User Story) : description courte et simple d'une fonctionnalité du point de vue de l'utilisateur, utilisée dans les méthodologies agiles pour planifier et prioriser le travail. ↩︎

  4. PRD (Product Requirements Document) : document de référence qui décrit les objectifs du produit, les besoins utilisateurs, les fonctionnalités attendues, les contraintes et les critères de succès, afin d'aligner les équipes sur ce qui doit être construit et pourquoi. ↩︎

  5. Sprint : période de temps fixe (généralement 1 à 4 semaines) dans les méthodologies agiles durant laquelle l'équipe complète un ensemble prédéfini de tâches. ↩︎

  6. Dette technique : coût futur supplémentaire de travail résultant de choix de facilité ou de raccourcis pris lors du développement initial, nécessitant souvent une refonte ultérieure. ↩︎