Création Automatique
Quand une release est marquée comme livrée, Sinra crée automatiquement sa rétrospective. Vous n’avez jamais besoin de créer une rétro manuellement ou de vous souvenir de configurer un tableau Miro à la fin d’une release.
Quatre Catégories de Retours
Chaque rétrospective collecte des retours dans quatre colonnes structurées :
| Catégorie | Ce qui y va |
|---|---|
| Bien | Ce qui a bien fonctionné cette release |
| Mal | Ce qui n’a pas fonctionné ou a causé des frictions |
| Améliorations | Changements de processus spécifiques à essayer la prochaine fois |
| Général | Tout ce qui vaut la peine d’être noté |
N’importe quel membre de l’équipe peut ajouter des entrées à n’importe quelle colonne. Chaque entrée est attribuée à son auteur.
Discussion sur les Éléments de Rétro
Chaque entrée de rétro supporte un fil de commentaires. Cela permet à l’équipe de discuter d’un point spécifique sans encombrer la vue principale de la rétrospective. Utilisez les commentaires pour approfondir les causes racines des éléments “Mal” ou affiner les propositions d’“Amélioration”.
Release ou cycle
Une rétrospective est rattachée à une release ou à un cycle (au moins l’un des deux). Une rétro créée à la livraison d’une release est rattachée à cette release. Vous pouvez aussi la lier à un cycle depuis son formulaire de modification : elle apparaît alors dans la liste des rétros de la page du cycle, et sur la page de la release quand elle en a une.
Parcourir les Rétros Passées
Toutes les rétrospectives sont disponibles dans la liste des Rétros, liées à leur release. Cela crée un historique consultable de ce que votre équipe a appris. Les nouveaux membres de l’équipe peuvent lire les rétros passées pour comprendre les schémas récurrents et les décisions antérieures.
Les retours à la ligne saisis dans un retour de rétro sont conservés à l’affichage.
Actions suivies
Les décisions d’une rétro sont des actions, pas du texte libre. Chaque action a un responsable, une échéance facultative et un statut (à faire, en cours, faite, abandonnée). Une action dont l’échéance est dépassée est signalée en retard ; une action sans échéance n’est jamais en retard.
- Le responsable fait avancer ses propres actions, tout comme la personne qui a créé l’action.
- Le responsable reçoit un e-mail quand une action lui est confiée, dans sa langue.
- Les actions des rétros et des postmortems sont listées ensemble dans Apprendre → Actions, filtrables par responsable, origine et échéance. Les product owners et les managers ont aussi un widget « Actions ouvertes » sur leur tableau de bord.
Une action a obligatoirement un responsable et une échéance. Les actions en retard sont comptées dans un bandeau sur la rétro et sur la page Actions, où chaque action convertie en issue affiche aussi cette issue et son statut actuel. À la conversion, la release ou le cycle de la rétro n’est proposé que s’il n’est pas terminé ; sinon on prend le cycle ou la release en cours.
Convertir une action en issue
Convertir en issue ouvre le formulaire d’issue déjà rempli : le titre, un lien vers la rétro, le type (une tâche pour une rétro), le responsable comme assigné, ainsi que la release et le cycle de la rétro. Tous les champs restent modifiables. Une fois enregistrées, l’action et l’issue se renvoient l’une à l’autre, et le statut de l’action suit l’issue : faite quand l’issue est terminée, abandonnée quand elle est désactivée, de nouveau en cours quand elle est rouverte. Si l’issue est supprimée, l’action retrouve son statut précédent. Une action ne se convertit qu’en une seule issue.
Participants
Ajoutez les personnes qui ont pris part à la rétro. Elles sont prévenues par e-mail et retrouvent la rétro dans Mes rétros, qui liste aussi les rétros où elles sont responsables d’une action.
Une nouvelle rétro démarre avec les personnes auxquelles sont assignées les issues de sa release ou de son cycle ; ajoutez ou retirez les autres au besoin.
Chaque ligne des notes de rétro peut devenir une action suivie en un clic (le formulaire d’action s’ouvre prérempli ; responsable et échéance restent obligatoires). Une rétro liste les incidents (postmortems) de la même release ou du même cycle, et un postmortem liste ces rétros. Une action ouverte écrite à la fois dans une rétro et dans un postmortem porte le badge Aussi ailleurs.