Conventions de gestion de projet¶
Guide de gestion de projet Scrum pour l'organisation, adapte au travail remote et asynchrone avec communication via Discord et tracking via GitHub. Ce standard s'applique a tous les repositories de l'organisation.
Langue obligatoire — Anglais
Tous les contenus visibles dans GitHub — issues, pull requests, epics, stories, tasks, commentaires, titres de branches et commits — doivent etre rediges exclusivement en anglais.
Portee¶
Ce standard s'applique a toutes les equipes de l'organisation, sur tous les repositories. Les conventions couvrent les roles Scrum, la hierarchie du travail, l'estimation, les sprints, les labels, les champs projet et les metriques.
Roles Scrum¶
Trois roles distincts qui ne se chevauchent jamais.
Product Owner (PO)¶
La voix du client. Decide quoi construire et dans quel ordre.
- Gere et priorise le backlog produit
- Redige ou valide les user stories et leurs criteres d'acceptance
- Decide ce qui entre dans un sprint et ce qui en sort
- Ne dit jamais comment faire, seulement quoi et pourquoi
- Seul habilite a fermer un milestone
Scrum Master¶
Facilitateur. Ne donne pas d'ordres, ne gere pas les gens.
- Protege l'equipe des distractions et interruptions mid-sprint
- S'assure que le processus Scrum est respecte
- Leve les obstacles (impediments)
- Anime les ceremonies (planning, review, retro)
- Rend les problemes visibles (metriques, board, enablers bloques)
- Gere le graphe d'enablers : s'assure que les dependances bloquantes sont identifiees et priorisees
- Ne resout pas les problemes techniques a la place de l'equipe
Equipe de developpement¶
Auto-organisee. Les devs decident eux-memes comment realiser le travail.
- Le Scrum Master ne leur assigne pas de taches — l'equipe se les repartit
- Chaque membre est responsable de ses engagements de sprint
- Autonomie forte : chacun gere son rythme librement
- Chaque dev signale ses blocages sur Discord
Hierarchie du travail¶
Trois niveaux. La relation Epic -> Story utilise les sub-issues natives de GitHub. La relation Story -> Task utilise de simples checkboxes Markdown dans le corps de la story (pas de sub-issues).
Epic (sub-issue GitHub)
+-- User Story A (sub-issue GitHub)
| +-- - [ ] Task 1 (checkbox Markdown)
| +-- - [ ] Task 2 (checkbox Markdown)
+-- User Story B (sub-issue GitHub)
+-- - [ ] Task 3 (checkbox Markdown)
+-- - [ ] Task 4 (checkbox Markdown)
Definitions¶
| Niveau | Description | Duree | Estimation | Mecanisme GitHub |
|---|---|---|---|---|
| Epic | Grand objectif metier ou technique. Plusieurs sprints. | Semaines a mois | Pas estime (somme des stories) | Sub-issue native |
| User Story | Besoin utilisateur ou technique, livrable en 1 sprint max. | 1-10 jours | Story points (Fibonacci) | Sub-issue native (sous un epic) |
| Task | Decoupage technique d'une story. Travail concret du dev. | < 2 jours | Pas estime separement | Checkbox Markdown dans le body de la story |
Regles¶
- Un epic n'est jamais assigne a une personne. C'est un conteneur.
- Un epic n'apparait pas dans le Sprint Board. Il vit dans la vue Roadmap et la vue Epics uniquement.
- Une story est assignable a 1 personne. Si elle necessite 2+ personnes en parallele, c'est un epic — spliter.
- Pas de story estimee au-dela de 13 points. Au-dela, spliter en 2-3 stories.
- Une task est toujours sous une story. Pas de task orpheline.
- Les tasks ne sont jamais des issues GitHub. Elles vivent comme checkboxes dans le body de la story.
- Pas de sous-epic. Si un epic est trop gros, le spliter en 2 epics.
Quand creer quoi¶
"Je veux un systeme d'authentification complet"
-> Epic
"En tant qu'utilisateur, je veux pouvoir me connecter avec mon email,
afin d'acceder a mon compte"
-> User Story (sous l'epic)
"Creer le composant de formulaire de connexion"
-> Task (sous la story)
Enablers et dependances¶
Qu'est-ce qu'un enabler ?¶
Un enabler est une issue qui bloque une ou plusieurs autres issues. Tant que l'enabler n'est pas Done, les issues dependantes ne peuvent pas etre commencees.
Un enabler est une issue normale (story ou task) avec le label enabler. Ce qui en fait
un enabler, c'est que d'autres issues en dependent.
Formalisation des dependances¶
Dans l'issue bloquee, ajouter une section ## Enablers avec des checkboxes
(- [ ] #12 -- Description (bloquant)). Sur l'issue enabler, ajouter le label
enabler et lister les issues qu'elle debloque dans une section ## Debloque.
Regles de gestion¶
| Regle | Explication |
|---|---|
| Enabler non-Done = issue bloquee en Backlog | Jamais en Ready, jamais assignee a un sprint |
| Enablers priorises en Critical | S'ils bloquent du monde, ils passent en premier |
| Le Scrum Master surveille le graphe | Il identifie les chaines critiques |
| Au sprint planning, verifier les enablers | Avant de prendre une story, verifier que ses enablers sont Done ou planifies |
| Pas de dependances circulaires | Si A bloque B et B bloque A, re-decouper |
User Stories et estimation¶
Format d'une User Story¶
Features produit¶
En tant que [role],
je veux [action],
afin de [benefice].
Stories techniques¶
En tant que developpeur,
je veux [capacite technique],
afin de [benefice pour le projet/l'equipe].
Criteres INVEST¶
| Critere | Signification |
|---|---|
| Independante | Pas de dependance forte avec une autre story du meme sprint |
| Negociable | Le scope peut etre ajuste avec le PO |
| Valuable | Apporte de la valeur (meme technique) |
| Estimable | L'equipe peut estimer la complexite |
| Small | Faisable en 1 sprint max |
| Testable | On peut verifier objectivement que c'est fait |
Estimation en Story Points¶
Echelle de Fibonacci : 1 (trivial) / 2 (simple) / 3 (modere) / 5 (significatif) / 8 (complexe) / 13 (tres complexe, maximum). 21+ est interdit — spliter la story.
Les story points mesurent la complexite relative, pas le temps. Bugs et Spikes ne sont jamais estimes (un bug restaure de la valeur existante, un spike est timebox).
Planning Poker async : le PO poste dans #estimation, chaque dev repond en spoiler
(||5||). Si convergence (ecart de 1 niveau max), on prend la mediane. Si divergence,
discussion puis revote.
Sprints et ceremonies¶
Sprint¶
- Duree : 2 semaines
- Regle d'or : ne planifier qu'a 80-90% de la velocite moyenne. Le buffer absorbe les imprevus.
Rythme du sprint¶
SEMAINE 1
Lundi : Sprint Planning (sync, 1h) -- choisir les stories du sprint
SEMAINE 2
Vendredi : Sprint Review (sync, 1h) + Sprint Retro (sync, 45 min)
Fin du sprint
Ceremonies¶
| Ceremonie | Quand | Duree | Contenu |
|---|---|---|---|
| Sprint Planning | 1er lundi | ~1h | PO presente les stories, equipe verifie enablers, estime, selectionne |
| Sprint Review | Dernier vendredi | ~1h | Demo de logiciel fonctionnel (pas de slides). Partage d'ecran en remote |
| Sprint Retro | Apres la review | ~45 min | Qu'est-ce qui a marche ? Qu'est-ce qui n'a pas marche ? Actions concretes (max 2-3) |
Checklist du planning : stories avec enablers Done, estimees en points, somme sous la
velocite moyenne, chaque story a un responsable, champ Iteration mis a jour.
Retro : pas de blame. On parle de processus, pas de personnes.
Protection du sprint¶
Jamais d'ajout sans retrait. Si le PO veut ajouter une story mid-sprint, il faut retirer une story d'effort equivalent. Pas de consensus -> ca attend le prochain sprint.
Communication¶
Discord pour la communication async : #general (annonces), #standup (updates
optionnels), #blocages (signaler un blocage immediatement), #estimation (planning
poker), #code-review (demandes de review).
GitHub est la source de verite. Tout ce qui est durable est dans GitHub : issues, PRs, Projects. Si une decision Discord impacte une issue, la mettre a jour dans l'issue.
Labels¶
Pas de prefixes — les couleurs distinguent les categories. Chaque issue a 1 label type (bleu) et 1+ label domaine (vert).
Type de travail (bleu — 1 obligatoire)¶
| Label | Usage |
|---|---|
epic |
Conteneur de stories, plusieurs sprints |
story |
User story estimee en points, livrable en 1 sprint |
task |
Decoupage technique d'une story |
bug |
Quelque chose ne marche pas |
spike |
Investigation timebox (resultat = savoir, pas du code) |
Domaine technique (vert — 1+ obligatoire)¶
Chaque projet definit ses propres labels de domaine en fonction de son architecture.
Exemples courants : build, ci, devex, api, auth, config, security, docs.
Labels speciaux¶
| Label | Usage |
|---|---|
enabler |
Cette issue debloque d'autres issues. Prioriser. |
blocked |
Cette issue a des enablers non-Done. Ne peut pas etre commencee. |
needs-refinement |
Story pas assez claire pour etre estimee |
good-first-issue |
Accessible pour un nouveau contributeur |
Ce qu'on NE met PAS en labels¶
| Ne pas faire | Alternative |
|---|---|
Labels de priorite (priority:high) |
Champ Priority dans le projet |
Labels de taille/points (3-points) |
Champ Story Points dans le projet |
Labels de sprint (sprint-3) |
Champ Iteration dans le projet |
Labels par defaut GitHub (enhancement) |
Supprimer, utiliser la taxonomie ci-dessus |
Champs projet (GitHub Projects v2)¶
Status (Single Select)¶
Stories¶
Backlog -> Ready -> In Progress -> In Review -> Done
| Status | Signification | Qui deplace |
|---|---|---|
| Backlog | Identifie mais pas pret | Auto a la creation |
| Ready | Enablers Done, estime, priorise, template rempli | PO / Scrum Master |
| In Progress | Un dev travaille dessus. Assignee obligatoire. | Le dev qui claim |
| In Review | PR ouverte, en attente de review | Auto quand PR liee |
| Done | PR mergee, criteres d'acceptance valides | Auto quand issue fermee |
Transitions :
| Transition | Condition |
|---|---|
| Backlog -> Ready | Tous les enablers Done + story estimee + titre conforme + template rempli |
| Ready -> In Progress | Un dev s'assigne |
| Branche existante | Le status doit etre au minimum In Progress |
| In Progress > 1 semaine (story 1-3 pts) | Signal d'alerte, le Scrum Master organise un point |
Epics¶
Les Epics ne suivent pas le workflow Backlog → Ready → ... → Done.
| Status | Signification |
|---|---|
| No Status | Epic en cours (stories en progression) |
| Finish | Toutes les stories Done + Completion Criteria coches |
Les Epics ne passent jamais par Backlog, Ready, In Progress ou In Review. Elles servent uniquement de conteneur pour regrouper les stories liees.
Priority (Single Select)¶
| Valeur | Signification |
|---|---|
| Critical | Bloque d'autres personnes ou enabler du chemin critique |
| High | Prevu pour ce sprint |
| Medium | Important, prochain sprint |
| Low | Nice-to-have, backlog long terme |
Story Points (Number)¶
Valeurs autorisees : 1, 2, 3, 5, 8, 13. Seules les stories sont estimees.
Iteration (Sprint)¶
Cycles de 2 semaines. Configure dans les settings du projet avec dates de debut/fin.
Issue Type (champ natif GitHub)¶
| Issue Type | Usage | Correspondance label |
|---|---|---|
| Feature | Story ou epic | story, epic |
| Task | Travail technique sous une story | task |
| Bug | Quelque chose ne marche pas | bug |
Le champ Issue Type et les labels sont complementaires. Les deux doivent etre remplis.
Milestones et roadmap¶
Milestones = Releases¶
Les milestones GitHub representent des versions livrables du projet.
- Chaque issue est dans 1 milestone
- Un milestone a une date cible (meme approximative)
- Plusieurs sprints composent un milestone
- Le milestone se ferme quand toutes ses issues sont Done
Milestone vs Sprint¶
| Milestone | Sprint | |
|---|---|---|
| Duree | Variable (1-3 mois) | Fixe (2 semaines) |
| Scope | Fixe au debut, ajustable | Planifie au sprint planning |
| But | Livrer une version | Avancer sur le backlog |
Modeles d'issue¶
Sections obligatoires par type¶
| Section | Story | Epic | Bug | Spike |
|---|---|---|---|---|
| User Story / Description | Oui | Oui | Oui | Oui |
| Tasks (checkboxes) | Oui | Non (sub-issues) | Non | Non |
| Affected Files | Oui | Non | Optionnel | Non |
| Enablers | Si applicable | Chaine critique | Non | Non |
| Unblocks | Optionnel | Non | Non | Non |
| Acceptance / Completion Criteria | Oui | Oui | Oui | Oui |
| Timebox | Non | Non | Non | Oui |
| Reproduction | Non | Non | Oui | Non |
| Environnement | Non | Non | Oui | Non |
La User Story suit le format (en anglais) :
As a [role], I want [action], so that [benefit].
Un Spike est une investigation timeboxee dont le livrable est du savoir (document, recommandation, stories creees), pas du code.
Template Epic¶
Les sections marquees * sont obligatoires.
## Description *
[Grand objectif, contexte, livrable cible.]
## Cross-Cutting Conventions
[Conventions communes a TOUTES les stories de l'Epic.]
## Structure *
[Vue d'ensemble des enablers et stories avec estimation relative (S/M/L).]
## Enabler N — Nom *
[Checklist de stories : - [ ] #NNN — **N.N** Titre `[S]`]
## Dependency Chain *
[Graphe visuel : chemin critique et branches parallelisables.]
## Module Mapping
[Optionnel. Correspondance story → fichiers.]
## Completion Criteria *
[Checklist des criteres de cloture de l'Epic.]
## Out of Scope
[Optionnel. Ce qui est reporte a une phase future.]
Template Story¶
Les sections marquees * sont obligatoires.
## User Story *
As a [role], I want [action], so that [benefit].
**Epic**: #NNN — Titre
**Enabler**: N — Nom
**Story ID**: N.N
**Size**: S/M/L
## Description *
[Specification technique detaillee : design, principes, choix d'architecture.]
## Tasks *
[Checklist des taches concretes. Cocher au fur et a mesure.]
- [ ] Implementer X
- [ ] Ecrire les tests pour X
## Affected Files *
[Fichiers crees ou modifies.]
- `Path/To/File.hpp` (create)
- `Path/To/Existing.cpp` (modify)
## Enablers
[Si applicable. Checkboxes des issues bloquantes.]
## Unblocks
[Optionnel. Issues que cette story debloque.]
## Acceptance Criteria *
[Checklists detaillees par categorie. Cocher au fur et a mesure.]
L'issue est un document vivant¶
Au debut, le template peut etre partiellement rempli. Cela ne doit pas empecher la creation de l'issue. L'important est de reflechir a la fonctionnalite, d'etudier comment la realiser, d'ecrire ses specs — avant de commencer a coder.
L'issue doit evoluer tout au long du developpement :
- Creation : au minimum
## User Story,## Description(meme partielle), et## Tasks. - Avant developpement :
## Affected Files,## Enablers,## Acceptance Criteriacompletes. L'issue est prete pour passer en Ready. - Pendant le developpement : les checkboxes de
## Taskset## Acceptance Criteriasont cochees au fur et a mesure. - Fin : toutes les checkboxes cochees, template complet, issue prete a etre fermee par la PR.
Vues recommandees du projet¶
| Vue | Layout | Filtre | Usage |
|---|---|---|---|
| Sprint Board | Board (Status) | iteration:@current |
Suivi quotidien du sprint |
| Backlog | Table (Priority) | status:Backlog,Ready |
Refinement et sprint planning |
| Enablers | Table | label:enabler |
Surveillance des blocages |
| Roadmap | Roadmap (Milestone) | — | Vision strategique trimestrielle |
| Mon travail | Table | assignee:@me |
Vue individuelle |
Signaux d'alerte sur le Sprint Board :
- Issue In Progress depuis > 1 semaine sur une story 1-3 points -> blocage probable
- Trop d'issues In Progress et rien en Review -> l'equipe code mais ne review pas
- Rien en Done a mi-sprint -> sprint en danger
Collaboration cross-repo¶
Validation par le proprietaire du repo¶
Quand un developpeur veut travailler sur le repo de quelqu'un d'autre :
- Creer l'issue complete avec le template rempli (architecture, choix techniques, fichiers concernes, criteres d'acceptance).
- Laisser l'issue en Ready — ne pas commencer le developpement.
- Ping le proprietaire du repo pour signaler que l'issue est prete et qu'on attend sa validation.
- Le proprietaire valide, demande des modifications, ou refuse la proposition.
- Si des modifications sont demandees, corriger l'issue puis re-ping le proprietaire.
- Le developpement ne commence qu'apres validation.
L'objectif : le proprietaire du repo peut juger si la proposition est alignee avec ses attentes avant que du code soit ecrit. Cela evite le travail perdu.
Choix des reviewers¶
| Situation | Reviewers |
|---|---|
| Code sur le repo de quelqu'un d'autre | Le proprietaire du repo (obligatoire) + une autre personne si pertinent |
| Code sur son propre repo | Obligatoirement une autre personne, la plus pertinente possible |
Metriques¶
| Metrique | Definition | Seuils |
|---|---|---|
| Velocite | Story points termines par sprint | Outil de prediction, jamais de pression. Ne jamais comparer entre equipes. |
| Cycle Time | Temps entre In Progress et Done | < 3j excellent, 3-7j normal (3-5 pts), 7-14j acceptable (8-13 pts), > 14j alerte |
| Sprint Completion Rate | % stories planifiees qui sont Done | > 85% bien planifie, 70-85% acceptable, < 70% sur-engagement |
L'objectif n'est pas 100% — c'est d'etre previsible et de s'ameliorer.