skills/bmad-code-org__bmad-method
1
0
Fork 0
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git synced 2026-09-19 08:11:52 +08:00
Code Issues Packages Projects Releases Wiki Activity
Files
main
bmad-code-org__bmad-method/docs/fr/reference/workflow-map.md
T
Brian cf54f4d76d refactor(bmm): consolidate sprint skills — one owner for the sprint-status artifact (#2659) 
* refactor(bmm): move sprint-planning and sprint-status to plan/

They sit at the plan/ship boundary and their outputs are planning
artifacts of the dev cycle; next commit makes sprint-planning the
readiness gate, which is plan-side work.

* refactor(bmm): fold readiness gate into sprint-planning, retire check-implementation-readiness

The old skill was 1,154 lines of legacy numbered-step ceremony whose
document discovery hardcoded filename globs (*prd*, *ux*, *epic*) that
miss what current skills produce (SPEC.md, DESIGN.md) and still treated
retired sharded docs as first-class. Sprint-planning now opens with a
lean readiness gate: generic artifact discovery by content, forward/back
traceability, PASS/CONCERNS/FAIL, stop on FAIL with findings. The IR
trigger on John's and Winston's menus dispatches sprint-planning, so
'check implementation readiness' still works everywhere it used to.

* refactor(bmm): modernize sprint-planning with deterministic script core

SKILL.md drops the legacy XML step dialect for the product-brief style
(~100 lines, uv run, headless contract). New scripts/sprint_plan.py owns
the mechanical work — epic parsing, key derivation, ordering, preserve-
never-downgrade merge, story-file detection, action_items carry-over,
atomic writes, drift checks — with 11 tests wired in as
test:sprint-planning. Judgment stays with the LLM: epic discovery, the
readiness gate, and reconciling script-reported orphans and unparsed
headings. checklist.md retired (the script performs that checklist);
sprint-status-template.yaml is the single source for the status
vocabulary. Output stays byte-compatible with build's sprint sync and
retrospective's tooling.

* refactor(bmm): fold sprint-status into sprint-planning's status view

sprint_plan.py gains a status subcommand: counts (legacy values mapped),
risk flags, open action items, and a priority-ordered next-action
recommendation — the old skill's inference-driven summary, computed
deterministically and covered by 9 new tests. bmad-sprint-status becomes
a v6-shims husk that forwards with status-view intent and a deprecation
notice; its dead data/validate modes had zero callers and are gone. If
a hand-edited status file defeats the script, the skill falls back to
reading it directly and summarizing by best judgment. New explanation
page docs/explanation/sprint-planning.md covers the consolidated skill;
workflow maps and references updated across all languages.

* docs: changelog entries for skill reorg and sprint consolidation

* fix(bmm): harden sprint_plan.py per review; add validate/fix intents with full progressive disclosure

Review fixes (PR #2659 findings, bot + internal review):
- Normalize legacy v6 statuses (drafted/contexted) on every read — merged by
  meaning and reported, never treated as illegal or reset
- dropped_orphans carry their old status; transplant renames via --set
- project_key/tracking_system/story_location preserved from the existing file
  unless overridden; refresh round-trips custom keys and user comments
- Hardened write path: dump-to-bytes, fsync, permission-preserving atomic
  write inside the guarded block, explicit checks (no asserts), atomic restore
- JSON-only argparse (errors and -h emit JSON); unicode-aware slugs with hash
  fallback; fenced code blocks ignored when parsing epics
- Odd retro keys, date-typed stamps, and non-mapping YAML report cleanly
  instead of crashing; unparseable timestamps warn instead of silently
  disabling the staleness check; malformed action items flagged, not dropped
- Dead check subcommand removed; generate --dry-run reports drift/in_sync
- test:sprint-planning wired into quality and CI (was test-only)
- Retro tests use a vendored template fixture (PATH-05); repo-level
  test-template-sync.js keeps it byte-identical to the source; template
  example timestamps and story_location fixed; header block pinned to the
  template by test

New capability:
- validate subcommand + reference: structural validation, never writes
- fix flow: evidence-gathering subagents -> user-confirmed state table ->
  generate --fresh --set writes a pristine file (the one path allowed to
  downgrade); universal script-failure fallback to inference for every intent
- SKILL.md is now a lean router: gate, tracking, status, fix, and validate
  each load as progressive-disclosure references

Docs: explanation page gains Repair section; workflow-map and getting-started
across all five languages mention the status view; headless payload nests
under 'report' to avoid the status key collision; changelog updated.

Test suite grows 20 -> 37; retro suite 91/91; docs build and validators green.

* docs: mention repair in sprint-planning explanation description
2026-08-01 16:21:38 -05:00

121 lines
9.8 KiB
Markdown
Raw Permalink Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "Carte des Workflows"
description: Référence visuelle des phases et des livrables des workflows de la méthode BMad
sidebar:
order: 1
---
La méthode BMad (BMM) est un module de l’écosystème BMad, conçu pour appliquer les meilleures pratiques d’ingénierie du
contexte et de planification. Les agents IA sont plus performants lorsqu’ils disposent d’un contexte clair et structuré. Le
système BMM construit ce contexte de manière progressive, en 4 phases distinctes — chaque phase, ainsi que les workflows
optionnels qu’elle contient, produit des documents qui nourrissent la phase suivante. Ainsi, les agents savent toujours
ce qu’ils doivent construire et pourquoi.
La logique et les concepts sous-jacents s’appuient sur les méthodologies agiles, largement éprouvées dans l’industrie
comme cadre de référence.
Si vous ne savez plus où vous en êtes, le skill `bmad-help` vous remettra sur la bonne voie ou vous indiquera la prochaine
étape. Cette page reste une référence utile, mais `bmad-help` est interactif et bien plus rapide si vous avez déjà installé
la méthode BMad. Par ailleurs, si vous utilisez des modules ayant étendu la méthode BMad ou ajouté d’autres modules
complémentaires non extensibles, `bmad-help` s’adapte automatiquement pour couvrir tout ce qui est disponible et vous
fournir les meilleurs conseils en temps réel.
Note importante : chaque workflow ci-dessous peut être exécuté directement via un skill avec l’outil de votre choix, ou
en chargeant d’abord un agent depuis le menu des agents.
<iframe src="/workflow-map-diagram-fr.html" title="Diagramme de la carte des workflows de la méthode BMad" width="100%" height="100%" style="border-radius: 8px; border: 1px solid #334155; min-height: 900px;"></iframe>
<p style="font-size: 0.8rem; text-align: right; margin-top: -0.5rem; margin-bottom: 1rem;">
<a href="/workflow-map-diagram-fr.html" target="_blank" rel="noopener noreferrer">Ouvrir le diagramme dans un nouvel onglet ↗</a>
</p>
## Phase 1 : Analyse (Optionnelle)
Explorez l’espace problème et validez vos idées avant de vous lancer dans la planification. [**Découvrez ce que fait
chaque outil et quand l’utiliser**](../explanation/analysis-phase.md).
| Workflow | Objectif | Livrable |
|---------------------------------------------------------------------------|--------------------------------------------------------------------------------|---------------------------|
| `bmad-brainstorming` | Brainstormez des idées de projet, animé par un coach de brainstorming dédié | `brainstorming-report.md` |
| `bmad-deep-recon` | Validez vos hypothèses ou choisissez entre des options — rédigez un prompt pour votre outil de recherche approfondie, traitez son rapport, ou menez la recherche ici ; marché, domaine, technique, concurrentiel, voix des utilisateurs, académique ; vérifiée, citée, actualisable | Rapport ou synthèse de recherche + briefing HTML optionnel |
| `bmad-product-brief` | Formalisez la vision stratégique — idéal lorsque votre concept est bien défini | `product-brief.md` |
| `bmad-prfaq` | Working Backwards — mettez à l’épreuve et affinez votre concept produit | `prfaq-{project}.md` |
## Phase 2 : Planification
Définissez ce qu’il faut construire et pour qui.
| Workflow | Objectif | Livrable |
|------------|--------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
| `bmad-prd` | Créez, mettez à jour ou validez un PRD[^1] — découverte accompagnée, trois intentions en un seul skill | Création/Mise à jour : `prd.md`, `addendum.md`, `.memlog.md` ; Validation : `validation-report.html` + `.md` |
| `bmad-ux` | Concevez l’expérience utilisateur (lorsque l’UX compte) | `DESIGN.md`, `EXPERIENCE.md` |
| `bmad-spec` | Distillez toute intention (brief, PRD, transcription, notes) en un contrat `SPEC.md` succinct + fichiers compagnons — fige le QUOI avant le COMMENT | `SPEC.md` + compagnons sous `{output_folder}/specs/spec-{slug}/` |
:::tip[Trois intentions en un seul skill]
`bmad-prd` couvre l’intégralité du cycle de vie du PRD. Précisez votre intention lors de l’appel, sinon le skill vous la demandera :
- **Créer** — nouveau PRD à partir de zéro via une découverte accompagnée ; produit `prd.md`, `addendum.md` et `.memlog.md`
- **Mettre à jour** — réconcilie un PRD existant avec un signal de changement, en mettant en évidence les conflits avant d’appliquer les modifications
- **Valider** — évalue un PRD à l’aide d’une liste de contrôle configurable et produit un rapport de constats structuré au format HTML
:::
:::tip[En amont : `bmad-product-brief`]
`bmad-product-brief` (Phase 1) produit un `product-brief.md` que `bmad-prd` peut exploiter lors de la découverte, réduisant les redondances et gardant les deux documents alignés. Aucun des deux skills ne nécessite l’autre — commencez directement par `bmad-prd` si vous savez déjà ce que vous construisez.
:::
## Phase 3 : Conception de la Solution
Décidez comment le construire et décomposez le travail en stories.
| Workflow | Objectif | Livrable |
|---------------------------------------|---------------------------------------------------|---------------------------------|
| `bmad-architecture` | Rendez explicites les décisions techniques | `architecture.md` avec ADRs[^2] |
| `bmad-create-epics-and-stories` | Décomposez les exigences en tâches implémentables | Fichiers d’epic avec stories |
| `bmad-sprint-planning` | Jalon de préparation avant implémentation, puis suivi des stories et vue d’état du sprint | OK / RÉSERVES / ÉCHEC + `sprint-status.yaml` |
## Phase 4 : Implémentation
Tous les points d’entrée convergent vers `bmad-build`. Il accepte une intention directe, une issue, une spécification ou une story planifiée, puis choisit le niveau de clarification, de planification, d’implémentation et de revue nécessaire.
| Workflow | Objectif | Livrable |
|------------------------|--------------------------------------------------------------------------------------|----------------------------------|
| `bmad-build` | Transformez une intention directe ou une story planifiée en code implémenté et révisé | `spec-*.md` + code |
| `bmad-code-review` | Validez la qualité de l’implémentation | Approuvé ou changements demandés |
| `bmad-correct-course` | Gérez les changements significatifs en cours de sprint | Plan mis à jour ou réorientation |
| `bmad-retrospective` | Bilan après l’achèvement d’un epic | Leçons apprises |
### Entrée directe ou planifiée
Un travail clair peut entrer directement dans `bmad-build`. Une initiative plus vaste peut d’abord produire un PRD, une conception UX, une architecture, des epics, des stories, un contrôle de préparation et un plan de sprint. Ces artefacts ajoutent du contexte sans sélectionner un autre workflow d’implémentation.
## Gestion du Contexte
Chaque document nourrit le contexte de la phase suivante. Le PRD indique à l’architecte les contraintes à respecter.
L’architecture précise à l’agent de développement les modèles à suivre. Les fichiers de story fournissent un contexte
ciblé et exhaustif pour l’implémentation. Sans cette structure, les agents prennent des décisions incohérentes.
### Contexte du Projet
:::tip[Recommandé]
Créez `project-context.md` pour que les agents IA respectent les règles et préférences de votre projet. Ce fichier agit
comme une charte pour votre projet — il oriente les décisions d’implémentation à travers tous les workflows. Ce fichier
optionnel peut être généré à la fin de la création de l’architecture, ou, dans un projet existant, pour capturer les
éléments clés et les garder alignés avec les conventions en vigueur.
:::
**Comment le créer :**
- **Manuellement** — Créez `_bmad-output/project-context.md` avec votre stack technique et vos règles d’implémentation
- **Générez-le** — Exécutez `bmad-generate-project-context` pour l’auto-générer à partir de votre architecture ou de votre codebase
[**En savoir plus sur project-context.md**](../explanation/project-context.md)
## Glossaire
[^1]: 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.
[^2]: ADR (Architecture Decision Record) : document qui consigne une décision d’architecture, son contexte, les options
envisagées, le choix retenu et ses conséquences, afin d’assurer la traçabilité et la compréhension des décisions
techniques dans le temps.
Reference in New Issue View Git Blame Copy Permalink