Synchroniser des tickets Jira dans l'espace Exigences de Squash TM

Principe

Si une synchronisation Xsquash4Jira est configurée, les tickets Jira sont automatiquement synchronisés en tant qu'exigences dans Squash TM et sont maintenus à jour. À la première mise à jour, le répertoire de synchronisation ainsi que l'ensemble des exigences synchronisées contenues dans ce répertoire sont créés.

La synchronisation se fait uniquement dans le sens Jira vers Squash TM.

Cette partie détaille l'organisation de ce patrimoine dans l'espace Exigences.

Pour l'organisation dans l'espace Exécutions, consulter la page Synchroniser des sprints.

Les exigences synchronisées

Affichage

Les tickets Jira sont représentés dans Squash TM par des exigences synchronisées. Ces exigences apparaissent avec un nom en grisé dans l'arborescence des exigences et sont précédées d'une icône .

Cette icône indique non seulement qu'il s'agit d'une exigence synchronisée mais elle donne également des informations sur le statut de synchronisation du ticket Jira associé via le code couleur suivant :

• icône verte : l'exigence est toujours mise à jour par synchronisation ;
• icône jaune : l'exigence n'est plus mise à jour par synchronisation car le ticket Jira correspondant n'entre plus dans le périmètre de synchronisation défini au niveau de la configuration du plugin (par exemple, le ticket Jira a été passé dans un statut qui ne figure pas dans le filtre défini pour la synchronisation) ;
• icône rouge : l'exigence n'est plus mise à jour par synchronisation car le ticket Jira correspondant a été supprimé dans Jira ou a été déplacé dans un autre projet Jira (sa clé a été modifiée) ;
• icône noire : le statut de synchronisation du ticket est inconnu (par exemple, lorsque la synchronisation globale est en échec).

De plus, les exigences synchronisées disposent de trois informations supplémentaires par rapport aux exigences natives :

• Un lien hypertexte vers le ticket Jira d'origine ;
• Le statut de synchronisation du ticket Jira qui indique si l'exigence est toujours mise jour par synchronisation et si le ticket Jira correspondant est toujours présent dans Jira ;
• Le statut de la synchronisation à laquelle appartient le ticket Jira, qui permet d'alerter l'utilisateur si la communication entre Squash TM et Jira est rompue ou qu'une erreur est survenue lors du dernier processus de mise à jour.

Modification, déplacement et suppression

Les exigences synchronisées peuvent être modifiées dans Squash TM. Il y a deux cas de figure selon le champ modifié :

• il s'agit d'un champ synchronisé (par exemple : description, référence, ou tout autre champ pour lequel une équivalence est renseignée) : les modifications apportées seront écrasées lors d'une prochaine synchronisation dès que le ticket Jira sera mis à jour ;
• il s'agit d'un champ non synchronisé : les modifications seront conservées dans Squash TM.

Attention

Les statuts "Approuvé" et "Obsolète" bloquent toutes modifications sur une exigence. Ainsi, lorsqu'une exigence synchronisée passe à l'un de ces statuts, elle n'est plus mise à jour par synchronisation. Il faudra modifier le statut manuellement à "En cours de rédaction" ou "À approuver" pour réactiver la mise à jour de l'exigence.

Les exigences synchronisées peuvent être déplacées dans l'arborescence des exigences. À nouveau, il y a plusieurs cas de figure :

• les exigences sont déplacées au sein du même projet : elles seront toujours mises à jour et resteront ou non à leur nouvel emplacement selon le type de synchronisation (voir Organisation des exigences synchronisées) ;
• les exigences sont déplacées dans un autre projet : elles deviennent des exigences natives dans le projet de destination et seront recréées à la prochaine synchronisation dans le projet d'origine.

À la suppression d'exigences synchronisées dans Squash TM :

• si les exigences sont toujours dans le périmètre de synchronisation : elles seront recréées à la prochaine synchronisation ;
• si les exigences ne sont plus dans le périmètre de synchronisation : elles ne seront pas recréées dans Squash TM.

Pièces jointes

Les pièces jointes associées à un ticket Jira sont synchronisées dans Squash TM sous forme de liens dans la description. Ces liens mènent directement à la pièce jointe dans Jira.

Épopées

Attention

Cette fonctionnalité est disponible avec le plugin Squash TM Premium inclus dans la licence Squash Premium.
Sans ce plugin, les épopées Jira sont synchronisées en exigences classiques de Squash TM. Les liens avec les user stories ne sont pas synchronisés.

Les tickets Jira de type "épopée" sont synchronisés dans Squash TM en exigences de haut niveau.

Les liens épopée - user story (ou autre type de ticket) sont également synchronisés en liens exigence de haut niveau - exigence classique.

Pour récupérer ces liens dans Squash TM, les épopées et les user stories doivent être synchronisées avec le même serveur de synchronisation. Elles peuvent néanmoins appartenir à deux synchronisations différentes.

Plusieurs types d'organisation peuvent ainsi être envisagés :

1. Les épopées et les user stories se trouvent dans la même synchronisation :

   • pour les synchronisations de tableaux Kanban, filtres ou requêtes JQL, elles sont toutes synchronisées à la racine du répertoire cible ;
   • pour les synchronisations de tableaux Scrum, les épopées sont synchronisées à la racine du répertoire cible tandis que les user stories sont synchronisées dans les dossiers de sprint ou à la racine du répertoire cible si elles se trouvent dans le backlog.

   

2. Les épopées et les user stories se trouvent dans des synchronisations différentes mais dans le même projet Squash TM.
   Cette organisation permet de séparer les épopées des user stories dans deux répertoires différents. Cela peut notamment faciliter le pilotage en générant des tableaux de bords ou des rapports uniquement sur les épopées ou les user stories.

   

3. Les épopées et les user stories se trouvent dans des synchronisations et des projets Squash TM différents.
   Cette organisation permet d'avoir des configurations différentes entre les projets contenant les épopées et les user stories (paramétrage des synchronisations, des champs personnalisés, des habilitations). Cela présente un intérêt dans le cas où l'on souhaite habiliter des utilisateurs uniquement pour faire du suivi au niveau épopée ou si l'on souhaite récupérer des informations différentes entre les épopées et user stories.

   

En savoir plus

Lors de la génération de tableaux de bord dans l'espace Exigences, il est possible d'étendre le périmètre des exigences de haut niveau pour que les exigences classiques rattachées soient prises en compte, même si elles ne sont pas dans la sélection initiale. Ainsi, même si les épopées et les user stories se trouvent dans des répertoires différents, il est possible d'inclure les user stories dans le tableau de bord généré à partir des épopées.

Sous-tâches

Dans Squash TM, le lien entre une sous-tâche Jira et son ticket mère est représenté par un lien exigence mère-fille si les deux exigences sont présentes dans la même synchronisation.

Ce lien ayant une signification particulière dans Jira, il est déconseillé de rompre cette hiérarchie afin d'avoir des indicateurs de couverture corrects pour l'exigence mère.

Hiérarchies hybrides

Il est tout à fait possible d'ajouter une sous-hiérarchie d'exigences natives en tant que sous-hiérarchie d'une exigence synchronisée.
Par exemple, une User Story donnée dans Jira pourrait nécessiter plusieurs exigences de test dans Squash TM. Ces exigences de test sont à créer sous l'exigence synchronisée qui représente cette User Story dans Squash TM.

Ainsi, le reporting dans Jira prendra en compte toute la hiérarchie d'exigences et tous les cas de test qui lui sont liés.

Le répertoire cible

Le répertoire cible correspond au répertoire parent dans lequel sont synchronisés les tickets Jira. Selon le type de synchronisation, des répertoires peuvent être créés automatiquement sous le répertoire cible.

Statut de la synchronisation

Les répertoires et sous-répertoires cibles sont précédés d'une icône et adoptent un code couleur similaire aux exigences synchronisées :

• icône verte : la synchronisation correspondant au répertoire cible est en succès et toutes les exigences synchronisées qu'il contient sont mises à jour par synchronisation ;
• icône jaune : la synchronisation correspondant au répertoire cible est en succès mais il contient des exigences qui ne sont plus mises à jour par synchronisation parce qu'elles sont sorties du périmètre de synchronisation ou parce qu'elles n'existent plus dans Jira ;
• icône rouge : la synchronisation correspondant au répertoire cible est en échec (par exemple, lorsque la communication entre Squash TM et Jira est rompue ou qu'une erreur est survenue lors du dernier process de mise à jour).

Déplacement et suppression

Les répertoires cibles peuvent être déplacées dans l'arborescence des exigences :

• les répertoires cibles sont déplacés au sein du même projet : les exigences qu'ils contiennent sont toujours mises à jour ;
• les répertoires cibles sont déplacés dans un autre projet : les exigences qu'ils contiennent deviennent des exigences natives dans le projet de destination et les répertoires cibles sont recréés à la prochaine synchronisation dans le projet d'origine.

Si les répertoires cibles sont supprimés dans Squash TM, ils seront recréés à la prochaine synchronisation, à leur emplacement d'origine.

Organisation des exigences synchronisées

Synchronisation de tableaux scrum

Lors de la synchronisation de tableaux scrum, les sprints sont représentés sous forme de dossiers dans l'arborescence des exigences et contiennent les exigences synchronisées qui correspondent aux tickets de ce sprint dans Jira.
Les tickets présents dans le backlog se trouvent quant à eux à la racine du répertoire cible.

Si un ticket change de sprint dans Jira ou retourne dans le backlog, il est déplacé automatiquement dans Squash TM dans le dossier correspondant.

Focus

L'accumulation de sprints terminés dans Jira entraîne la création de nombreux répertoires de Sprints dans Squash TM. Pour améliorer la lisibilité, il est possible de créer un (ou plusieurs) répertoires d'archive à la racine du répertoire cible et d'y déplacer les sprints terminés. À l'intérieur de ce répertoire d'archive, il est possible de s'organiser en sous-répertoire par année, par thème ou toute autre forme d'organisation qui conviendra.

Si l'organisation en sprint n'a plus de sens, il est possible de déplacer les exigences synchronisées n'importe où dans le même projet Squash. La seule restriction est de ne pas supprimer les anciens répertoires de sprints, sinon ils seront recréés lors de la prochaine mise à jour.

Attention

Il est conseillé de ne pas déplacer les sprints non terminés, ni leur contenu. Une fois le sprint terminé et les tickets Jira fermés, l'archivage dans Squash est libre.

Autres types de synchronisation

Pour les autres types de synchronisation (tableaux Kanban, filtres, requêtes JQL), les exigences sont créées à la racine du répertoire cible. L'utilisateur est ensuite libre d'organiser les exigences synchronisées comme il le souhaite, tant qu'il ne les change pas de projet afin qu'elles soient toujours mises à jour.