Aller au contenu

Première session

Ce parcours prend environ une heure et couvre le cycle minimal : créer un Business Epic, charger une Expression Originelle, instruire le dossier de Vision arrêtée et franchir la porte G1.

Prérequis

  • Installation terminée (voir Installation)
  • Un dossier .product/ créable à la racine du projet
  • Une Expression Originelle (EO) prête : email, transcription d'atelier, note de cadrage, idée exprimée par un sponsor.

Étape 1 — Créer le premier Business Epic

Depuis la racine du projet :

node .sdeg/sdlc/sdlc.js init be BE-I "Titre provisoire de l'hypothèse"

Effet :

  • .product/sdlc-registry.json est créé, avec BE-I en statut NOT_STARTED.
  • Heat : non défini (le BE est une ambition, pas encore un chantier).
  • L'identifiant BE-I est une convention : utiliser BE-II, BE-III… pour les suivants.

Vérification :

node .sdeg/sdlc/sdlc.js status

Étape 2 — Ouvrir la phase de Vision

Faire passer la BE en VISION_EN_COURS (LIVING). À partir de cet état, vous instruisez le dossier G1.

Charger l'EO dans .product/.epics/BE-I/eo.md. Si l'EO est un enregistrement audio, utiliser le skill #eo-transcription :

#eo-transcription

[coller le texte d'une transcription brute ou demander à l'agent de procéder]

Le skill produit un fichier structuré (contexte, demande, contraintes, non-dits) dans .product/.epics/BE-I/eo.md.

Étape 3 — Instruire le dossier G1 (Vision arrêtée)

La porte G1 demande un dossier complet. Produire, dans .product/.epics/BE-I/ :

Fichier Skill Contenu
asis.md #agent-vision Situation actuelle, problème factuel
tobe.md #agent-vision Cible visée, jobs to be done, valeur attendue
ehs.md #be-hypothesis-statement Epic Hypothesis Statement (1 cible valeur, ≤ 3 outcomes)
lbc.md #lean-business-case Lean Business Case + palier MVP
okrs.md #okr-coach Objectifs et résultats clés mesurables
decision.md — (humaine) Frontmatter decision: go \| conditional-go, decision_date, governance_body, sponsor

Règle SRP : un EHS = une seule cible valeur principale. Si plusieurs : découper en plusieurs BE.

Étape 4 — Inspecter la porte G1

node .sdeg/sdlc/sdlc.js check BE-I

Affichage attendu (extrait) :

→ ENGAGE  [LIVING → COLD]
  Porte : G1 — Vision arrêtée
  Évaluation automatisée :
    Checks :
      ✓ asis-exists         asis.md présent
      ✓ tobe-exists         tobe.md présent
      ✓ ehs-exists          ehs.md présent
      ✓ lbc-exists          lbc.md présent
      ✓ okrs-exists         okrs.md présent
      ✓ decision-frontmatter decision ∈ [go, conditional-go]
    Synthèse : 6 pass · 0 fail · 0 warn
    Verdict : GO

Étape 5 — Franchir G1

node .sdeg/sdlc/sdlc.js move BE-I ENGAGE

Le CLI :

  1. Ré-affiche la porte et la checklist.
  2. Demande oui/non.
  3. Si oui, met à jour le registre, gèle les artefacts G1 (asis, tobe, ehs, lbc, okrs, decision deviennent COLD), écrit un événement .product/.events/YYYY-MM-DD-sdlc-be-i-engage.md, et crée un commit git.

Vérification :

node .sdeg/sdlc/sdlc.js log BE-I

Étape 6 — Créer / mettre à jour spiral-state.md

C'est la mémoire entre sessions. À créer manuellement dans .product/spiral-state.md :

# État de la spirale — <date>

## Porte active
G2 — Plan de dév BE-I (découpage en Features)

## Objets vivants
- **BE-I** : ENGAGE, COLD sur la Vision → prochaine étape : ouvrir DEV_PLAN_EN_COURS et découper en Features (skill #be-to-features)

## Ce que nous savons
- [synthèse en 3 lignes]

## Ce que nous ne savons pas encore
- [incertitudes assumées]

## Prochaine action
- Appeler #be-to-features pour produire plan-dev.md + au moins une FE

À chaque fin de session, mettre à jour ce fichier. Le hook Stop vous rappelle si vous l'oubliez.

Étape 7 — Préparer la porte suivante (G2)

Ouvrir la phase G2 (LIVING) avant de produire les artefacts :

node .sdeg/sdlc/sdlc.js move BE-I DEV_PLAN_EN_COURS

Puis invoquer le skill :

#be-to-features

Contexte : voir .product/.epics/BE-I/{ehs.md, lbc.md, okrs.md}

Le skill produit plan-dev.md et au moins une Feature attachée à BE-I. Itération, puis franchissement de G2 :

node .sdeg/sdlc/sdlc.js check BE-I
# vérifier que plan-dev.md et ≥ 1 FE rattachée passent les checks
node .sdeg/sdlc/sdlc.js move BE-I DEV_PLAN_ARRETE

Ce qu'il faut retenir

  1. L'ordre est toujours : skill produit → revue humaine → check → move. Jamais sauter la revue.
  2. Un commit par transition. Si vous voyez un move sans commit, quelque chose cloche (option --no-git ? repo non initialisé ?).
  3. spiral-state.md n'est pas optionnel. C'est la seule chose qui empêche la session suivante de tout recommencer.
  4. Les événements .product/.events/*.md sont la mémoire longue. Les garder en clair, les commiter, ne pas les écraser.
  5. Boucle MVP→G1 : à la fin du MVP, la revue (REVUE_MVP) peut renvoyer la BE en VISION_EN_COURS (verdict PERSEVERE). Un nouveau cycle G1 alimente alors une vision enrichie.

Voir aussi : Usage quotidien · Catalogue des skills · Porte G1.