Issues

Qu’est-ce qu’une Issue ?

Une issue représente un élément de travail concret : un bug à corriger, une tâche à réaliser, une spécification à rédiger. Chaque livrable dans Sinra se trace jusqu’à une issue.

Contrairement aux formats traditionnels de “user story” avec une structure rigide, les issues Sinra utilisent des noms directs et descriptifs. “Export CSV des rapports” est plus utile que “En tant qu’utilisateur, je veux exporter des rapports afin de pouvoir analyser les données.”

Types d’Issues

Le type se choisit à la création de l’issue, depuis le menu New, et ne peut plus être changé ensuite. Le bouton New global crée un bug.

Spécifications, plans, tâches et bugs suivent les mêmes règles de planification : ils peuvent être dans une capability, une release et un cycle. Ce qui change, c’est le statut qu’ils portent, la façon dont ils comptent dans la capacité et les liens qu’ils acceptent. La page Traçabilité explique comment ils se relient.

Champs Principaux

• Nom : titre concis et descriptif
• Corps : texte riche avec images et @mentions
• Priorité : Basse, Moyenne, Haute
• Temps estimé : en jours, alimente les calculs de capacité
• Labels : étiquettes personnalisées par organisation
• Plateforme : Backend, Frontend, Mobile, etc.

Assignation

Les issues peuvent être assignées à un utilisateur spécifique ou à une équipe entière. Quand une issue est assignée à une équipe, n’importe quel membre de l’équipe peut la prendre en charge.

Un Statut par Type

Une issue porte exactement un statut, celui qui correspond à sa nature :

Le formulaire, la fiche de l’issue et les listes n’affichent que le statut qui s’applique. Une nouvelle issue démarre au statut initial de son type.

La Réalisation

Une spécification ou un plan n’a jamais de statut de développement propre. Sa réalisation (realization) est calculée à partir de ses tâches et affichée à côté de son statut de rédaction :

La réalisation s’accompagne du nombre de tâches terminées sur le total (par exemple 2/5). Une spécification compte toutes ses tâches, celles rattachées directement et celles sous ses plans. Vous ne saisissez jamais la réalisation : elle suit les tâches.

“Terminé” pour une spécification recouvre donc deux questions distinctes : est-elle rédigée (statut de rédaction) et est-elle réalisée (réalisation). Un cycle compte la première.

La Chaîne de Conception : le Lien Parent

Un plan ou une tâche peut dire quelle issue il réalise, grâce à son Parent issue :

• Un plan a pour parent une spécification.
• Une tâche a pour parent un plan ou une spécification.
• Une spécification et un bug n’ont pas de parent.

Le parent est toujours facultatif, et parent et enfant sont toujours dans la même capability. Choisir un parent rattache l’issue à la capability du parent. Si un parent change de capability, ses enfants le suivent.

La fiche d’une issue montre la chaîne sous forme d’arbre : les ancêtres, l’issue, puis ses plans et ses tâches, avec pour chacun le type, le nom, le statut et la réalisation. La fiche d’une spécification indique combien de tâches sont terminées sur le total, et une action Add a plan ou Add a task ouvre le formulaire de création avec le parent et la capability déjà renseignés.

Supprimer dans une Chaîne

Une suppression ne laisse jamais d’orpheline :

• Supprimer un plan qui a une spécification pour parent : ses tâches remontent et se rattachent à la spécification.
• Supprimer une issue dont les enfants n’ont nulle part où remonter (une spécification qui a des plans ou des tâches, un plan sans parent qui a des tâches) est refusé. Le message donne le nombre d’issues rattachées. Déplacez-les ou supprimez-les d’abord.

Release et Release Souhaitée

Une issue dans une capability a toujours la release, et la release souhaitée, de cette capability. Les deux champs sont en lecture seule sur le formulaire et indiquent d’où vient la valeur (“Inherited from” la capability). Une issue sans capability choisit sa release librement. Voir Releases pour la règle complète.

Concerns : un Lien pour les Issues Hors Capability

Un bug trouvé après la livraison ne peut pas entrer dans la capability d’origine : il prendrait une release déjà livrée. Une issue sans capability peut en revanche déclarer la capability qu’elle Concerns. Ce lien est purement informatif : il ne change ni la release de l’issue, ni aucun chiffre d’avancement, de charge ou de capacité. Il disparaît dès que l’issue est rattachée à une capability.

Suivi du Temps

Enregistrez le temps passé directement sur une issue. Sinra compare le temps passé à l’estimation, ce qui fait remonter les dépassements avant qu’ils ne deviennent des surprises. Ces chiffres alimentent le calcul de la charge du cycle. Le temps est enregistré dès que vous quittez le champ (Entrée, Tab ou un clic ailleurs) et une courte confirmation s’affiche. Une valeur négative est refusée avec un message, et ce que vous avez saisi reste dans le champ.

Votre rôle sur une issue

Une personne peut être liée à une issue de quatre façons : assignée à l’issue, assignée via son équipe, créatrice de l’issue, ou testeuse. « Mes issues » montre la première par défaut et permet d’en choisir une autre.

Choisir une capability d’une release passée

Le sélecteur de capability d’une issue propose toutes les capabilities, y compris celles d’une release passée, qui viennent en dernier et portent la mention « Release passée : v0.9 ». En choisir une fait suivre à l’issue cette release, comme pour toute capability.

Avertissement de doublon

À la création d’une issue, saisir un titre d’au moins 8 caractères cherche les issues ouvertes au titre proche, quel que soit l’ordre des mots (« Suivi badge entreprise » trouve « Badge entreprise : suivi »). Un avertissement renvoie vers trois d’entre elles au plus, chacune dans un nouvel onglet. Il ne bloque rien : vous pouvez toujours créer l’issue.

Commentaires et Mentions

Chaque issue dispose d’une section de commentaires avec texte riche et @mentions. Mentionner un utilisateur déclenche une notification par e-mail avec tout le contexte. La discussion reste attachée au travail, pas perdue dans Slack.

Les mentions arrivent dans votre centre de notifications : le compteur de la barre du haut, un lien qui ouvre le commentaire exact, et une case Attendre une réponse pour suivre les questions jusqu’à leur réponse.

Le bouton Publier envoie le commentaire ; un commentaire vide, ou fait uniquement d’espaces, est refusé avec un message (une @mention seule compte comme du contenu). Dans le menu @, Entrée ou Tab insère la personne sélectionnée sans effacer ce que vous avez saisi ; les membres désactivés ne sont pas proposés. Les commentaires longs passent à la ligne au lieu d’être rognés.

Le type d’une issue est fixé à la création. À l’édition, il est affiché en lecture seule.

Créée depuis une action

Une issue peut être créée depuis une action de rétrospective ou de post-mortem (Convertir en issue). Le formulaire arrive pré-rempli et entièrement modifiable : titre, lien vers l’origine, type (une tâche depuis une rétro, un bug depuis un post-mortem), assigné, release et cycle. La page de l’issue affiche alors « Créée depuis l’action … de … » avec un lien, ou « origine supprimée » si la rétro ou le post-mortem n’existe plus.

Dès lors, 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. Supprimer l’issue rend à l’action son statut précédent et retire le lien. Une action ne se convertit qu’en une seule issue : la convertir de nouveau crée l’issue sans lien et vous le signale.