jpantsjoha/ai-native-developer-experience

Sitrep

Les rapports de situation sont destinés à la personne qui n'était pas dans la salle. Écrivez pour elle.

Un sitrep n'est pas un journal d'activité. C'est une image compressée et actionnable de l'état actuel. Trois questions : ce qui est fait, ce qui est bloqué, ce qui est à venir. Tout ce qui ne répond pas à l'une de ces trois questions n'a pas sa place dans le sitrep.

Quand l'utiliser

• Synthèse quotidienne de standup à partir des journaux de travail, des commits ou de l'état des tickets
• Résumé de fin de sprint pour les parties prenantes
• Rapport de situation d'incident pendant ou après un incident actif
• Résumé de transfert lors d'un changement de contexte ou de la remise de travail à un autre agent ou personne
• Lorsqu'une partie prenante demande « où en sommes-nous ? » et que la réponse honnête est « c'est compliqué »

Procédure

1. Rassemblez l'état actuel du travail — lisez à partir des sources disponibles :

   • Problèmes / tickets ouverts et récemment fermés
   • Commits récents (24-48 dernières heures pour un standup ; dernier sprint pour un résumé de sprint)
   • Documents sur l'état du projet et la feuille de route (par ex. docs/operating-model/PROJECT-OPERATING-PROFILE.md, docs/ROADMAP.md, ou équivalent selon la structure du projet)
   • Tout indicateur de blocage, registre des risques ou notes d'escalade

2. Classez les éléments dans trois catégories :

   • Fait — terminé et vérifiablement clos (test passé, ticket fermé, déployé)
   • Bloqué — travail qui ne peut pas progresser sans une dépendance non résolue spécifique (nommez le blocage précisément)
   • À venir — les éléments les plus prioritaires qui seront travaillés ensuite (classés par priorité)

3. Rédigez le sitrep — structure :

   ## Sitrep — <date> [<périmètre : sprint / incident / transfert>]
   
   **Fait**
   - <élément> — <une phrase sur ce qui a été livré et sa preuve>
   
   **Bloqué**
   - <élément> — bloqué par <dépendance spécifique / propriétaire / ETA si connu>
   
   **À venir**
   - <élément> — <ordre de priorité, du plus important au moins>
   
   **Risques / indicateurs** (optionnel — seulement si pertinent)
   - <risque> — <impact si non résolu> — <propriétaire>
   

4. Appliquez le test de compression — pour chaque ligne : si la supprimer ne change rien que le lecteur doive traiter, supprimez-la.

5. Nommez les blocages précisément — « bloqué par le backend » n'est pas une entrée de blocage. « Bloqué par le contrat API pour /v2/orders — en attente de @owner, ETA inconnu » en est une.

6. N'éditorialisez pas le progrès — « de bons progrès ont été réalisés » est du bruit. « X a été livré, ce qui débloque Y » est un signal.

Livrables

• Un sitrep dans le format ci-dessus
• Optionnel : un résumé exécutif d'un paragraphe pour les parties prenantes qui en ont besoin d'encore moins

Garde-fous

• Pas de rapport d'activité. « J'ai travaillé sur le module d'authentification » n'est pas une entrée de sitrep. « Module d'authentification : validation JWT terminée, échec du rafraîchissement du token sous charge — en cours d'investigation » en est une.
• Bloqué signifie bloqué. Si quelque chose avance lentement mais n'est pas réellement bloqué, cela appartient à « À venir » avec une note, pas à « Bloqué ».
• Fait signifie fait. « Fait à 95 % » n'est pas fait. Si ce n'est pas vérifiablement complet, c'est « À venir ».
• La longueur n'est pas la qualité. Un sitrep de cinq lignes qui répond aux trois questions est meilleur qu'un sitrep de vingt lignes qui n'y répond pas.