Un parcours unique et efficace
Ce cycle est le même quelle que soit la nature du travail : une fonctionnalité client, un outil interne ou une page de documentation. Seules les modalités de validation changent d’un sujet à l’autre.
Ce découpage sert trois objectifs :
- une qualité finale qui peut être vérifiée
- une productivité réelle en limitant les incompréhensions et en supprimant les allers-retours inutiles
- une visibilité claire des actions à suivre et des personnes devant intervenir
Nous nous efforçons de faire au plus simple. Quand nous sommes tentés de faire évoluer ce workflow vers quelque chose de plus riche, la bonne réponse est presque toujours de mieux découper la demande, avec des checklists ou des sous-tâches, plutôt que d’ajouter une colonne.
Un workflow en six étapes
| Étape | Ce qu’elle signifie | Condition pour en sortir |
|---|---|---|
| Backlog | Nouvelle demande : en cours de qualification ou déjà qualifiée par l’auteur mais qui n’a pas encore été priorisée | Le ticket est complet et nous avons le budget et la bande passante |
| À faire | Demande planifiée : la demande est complètement spécifiée et peut être prise en charge | La personne assignée a relu le ticket et confirme qu’elle peut travailler |
| En cours | Quelqu’un travaille réellement dessus | Tous les points sont traités et la validation peut commencer tel que défini dans le ticket |
| À valider | La demande est en attente de validation, ou la validation est en cours | Toutes les étapes de la checklist de validation sont validées |
| Terminé | La demande a été testée et validée | L’information a été partagée à l’équipe en point projet |
| Clôturé | La demande est traitée et l’information est partagée | Fin du parcours |
flowchart TD Backlog[Backlog]:::backlog Todo[À faire]:::todo Progress[En cours]:::inprogress Validation[À valider]:::validation Done[Terminé]:::finished Closed[Clôturé]:::closed Backlog -->|Ticket complet, budget et bande passante| Todo Todo -->|Ticket relu par la personne assignée + début du travail| Progress Progress -->|Tous les points traités| Validation Validation -->|Checklist de validation complète| Done Done -->|Information partagée en point projet| Closed Validation -.->|Retour recette| Todo Progress -.->|Dépriorisation entre deux étapes| Todo Progress -.->|Événement bloquant non anticipable| Backlog Closed -.->|Le problème réapparaît| Todo Closed -.->|Le problème réapparaît avec conception à retravailler| Backlog classDef backlog fill:#f1f5f9,stroke:#64748b,color:#334155 classDef todo fill:#bae6fd,stroke:#0284c7,color:#1d4ed8 classDef inprogress fill:#2563eb,stroke:#1d4ed8,color:#ffffff classDef validation fill:#86efac,stroke:#16a34a,color:#166534 classDef finished fill:#16a34a,stroke:#15803d,color:#ffffff classDef closed fill:#1e293b,stroke:#0f172a,color:#ffffff
Les flèches pleines sont le parcours nominal. Les pointillés sont des retours en arrière : ils restent l’exception et chacun répond à un motif précis.
- À valider vers À faire : un retour de recette. Le ticket repart avec le label Retour recette et passe avant les nouveaux développements.
- En cours vers À faire : le ticket comporte plusieurs étapes et il a été dépriorisé entre deux d’entre elles. Ce qui est fait est terminé et livrable, la suite attend d’être repriorisée.
- En cours vers Backlog : un événement extérieur remet en cause le travail lui-même. Ce retour est réservé à ce qui est indépendant de notre volonté et non anticipable : la fermeture d’une API, un changement de réglementation. Une demande mal comprise ou un besoin qui évolue en cours de route ne relèvent pas de ce cas, ils se traitent dans le ticket.
- Clôturé vers À faire ou Backlog : le problème réapparaît après la clôture (exemple une erreur de production).
Backlog
Le Backlog est l’étape d’entrée de toute demande. C’est ici que se fait la qualification de la demande : le ticket y reste tant que son auteur n’a pas terminé de le remplir.
Le passage à l’étape suivante se fait de deux manières, selon le type de demande et les compétences de l’auteur :
- par l’auteur lui-même pour une demande simple
- par une personne compétente pour la réalisation, par exemple un développeur pour une tâche de développement ou en atelier de travail entre l’auteur et une personne compétente si besoin d’ajuster la demande
Deux conditions doivent être réunies, et elles ne sont pas de même nature :
- le ticket est défini au point de mettre la personne qui le prendra dans les meilleures conditions
- nous avons le budget et la bande passante pour qu’il soit réalisé
La seconde est aussi bloquante que la première. Un ticket parfaitement rédigé mais sans budget reste au backlog.
À faire
Un ticket À faire peut être pris en charge par ordre de priorité. La priorisation se lit directement sur le board : le ticket le plus haut dans la colonne est le plus prioritaire.
L’assignation peut venir de l’équipe ou de la personne elle-même. Dans les deux cas, sa première action est de relire le ticket, pas de le commencer. Elle vérifie qu’elle a compris la demande et qu’elle dispose de tout ce qu’il lui faut pour travailler.
Tant que cette relecture du ticket n’a pas été faite, le ticket ne passe pas En cours . Se lancer sans avoir compris la globalité de la demande est notre première source de temps perdu et c’est la plus simple à éviter.
En cours
Un ticket En cours signifie qu’une personne travaille dessus ou sur l’une de ses sous-tâches.
Il y reste tant que la ou les étapes de validation ne peuvent pas commencer. Deux situations sont souvent prises à tort pour de la validation et restent dans cette étape :
- les tests faits sur le poste de la personne qui réalise le ticket, qui font partie de la mise au point
- une première merge request ou un premier écran poussés pour recueillir un avis -> le travail n’est pas terminé
La personne assignée est responsable de suivre son travail jusqu’à la clôture du ticket. Si la revue de code tarde ou si la validation bloque, c’est à elle de relancer.
À valider
La phase de validation ne s’improvise pas à ce moment-là : elle se prépare à la conception du ticket, où l’on définit qui valide et comment.
Se poser la question ici reviendrait à admettre que le principal intéressé n’a pas été consulté à la conception, ou qu’il n’a pas réfléchi aux cas de tests. Préparer la validation en amont apporte trois bénéfices :
- définir le niveau de détail attendu, pour ne faire ni de la sur-qualité ni de la sous-qualité
- savoir immédiatement qui contacter en cas de question
- prévoir les cas possibles dès la conception, ce qui limite les oublis et les incompréhensions
La validation se déroule toujours ailleurs que sur le poste du développeur : sur l’environnement d’intégration pour la validation interne, en recette pour la validation client. La personne qui valide la dernière étape de la checklist passe le ticket en Terminé .
Terminé
Le ticket a passé la validation. Le moment exact où il bascule dépend du stade du projet :
- projet déjà en production, déploiement continu : il passe Terminé une fois la mise en production effectuée
- projet en cours de développement : il passe Terminé une fois validé en recette
Il reste dans cette étape tant que l’information n’a pas été partagée avec l’équipe. C’est ce statut qui donne la liste des sujets terminés à parcourir au prochain point projet.
Clôturé
La clôture a lieu en point projet, une fois l’information partagée et une fois que nous actons que la demande est complètement traitée. À partir de là, le ticket compte comme une charge acquise dans le suivi d’avancement du projet.
Si le problème réapparaît plus tard, nous ne rouvrons pas le ticket au hasard :
- le problème est clair, nous repartons de À faire
- la conception est à retravailler, ou le sujet n’est pas pour tout de suite, il retourne au Backlog
Et si nous avons bien fait notre travail, les informations utiles du ticket ont été mises au propre dans une documentation avant sa clôture.