Confluence ou Jira : quelle est la meilleure solution pour documenter ses user stories ?

confluence-ou-jira-documenter-user-stories

Lorsque l’on travaille dans une équipe Agile en utilisant les outils de la suite Atlassian et notamment Jira Software et Confluence, l’une des questions qui revient le plus souvent est de savoir s’il vaut mieux documenter ses user stories sur l’un ou l’autre des deux outils.

Une chose est sûre : documenter les user stories dans les deux outils est contre-productif. Vous auriez à renseigner deux fois les mêmes informations. Et en cas de changement, vous devrez surtout ne pas oublier de mettre à jour les deux outils ou bien vous risqueriez la confusion pour votre équipe.

Alors lequel choisir ?

#Team Confluence pour documenter ses users stories

Si vous êtes un adepte de  l’organisation

Confluence est un wiki d’entreprise et un gestionnaire de contenu. Il permet de définir des pages structurées contenant du texte, des images, des vidéos, des mockups, …

Pour documenter vos fonctionnalités, Confluence propose un modèle de page nommé « Caractéristiques produit ».

Le fait de travailler au niveau de la fonctionnalité permet de donner un contexte commun aux user stories la composant.

Page Confluence-caractéristiques produit-contexte pour les user stories

On peut ainsi définir la version et les intervenants sur cette fonctionnalité mais aussi la lier à une epic coté Jira. L’état du document permet à l’équipe de savoir immédiatement si on peut travailler sur cette version du document ou si c’est encore un brouillon.

Renseignez ensuite les objectifs, le contexte et les hypothèses de manière simple et directe afin que votre équipe puisse les comprendre aisément.

Caractéristique user stories dans Confluence

On peut ensuite traduire les différentes exigences fonctionnelles en user stories Jira. Celles-ci sont d’abord décrites dans Confluence puis créées dans Jira via le mécanisme de création rapide en sélectionnant le titre de la user story (voir ci-dessous).

Lien user story Jira dans une page confluence

La user story est ainsi directement créée dans Jira et un lien est fait vers la page Confluence d’où elle a été créée. On a ainsi facilement accès au contexte de la user story depuis celle-ci. Celui-ci est structuré comme on veut en rajoutant par exemple des informations de design préliminaire (mockups, copies d’écran, …).

Toutes les user stories et leurs états sont donc ainsi visibles depuis la page Confluence.

#Team Jira pour documenter ses user stories

Si vous préférez un peu moins de structure

Jira est un outil de gestion du travail qui va stocker toutes les user stories, les epics, les tâches et sous-tâches de votre projet. Pour certaines équipes, il peut être pénible de devoir passer de Jira à Confluence sans cesse lorsqu’elles sont en train de travailler sur une user story particulière. Donc ces équipes ont tendance à ne travailler qu’avec Jira et pas du tout Confluence. La user story contient donc toutes les informations nécessaires et suffisantes à sa mise en œuvre. L’avantage, c’est qu’on sait à tout moment depuis le tableau (scrum ou kanban) dans quel état se trouve la user story. On peut aussi savoir qui travaille dessus en ce moment et toutes les autres informations propres à la demande Jira.

L’un des soucis de cette approche est que, même si toute l’information est centralisée directement dans la user story, la structuration de cette information est beaucoup moins développée que dans Confluence. On a tendance à tout remplir dans le champ Description. Et de ce fait, l’expérience utilisateur peut être amoindrie s’il doit parcourir une centaine de lignes d’exigences fonctionnelles. Jira ne permet pas de définir une valeur par défaut qui donnerait une structure pour la description avant la version 8.16 Data Center.

Atlassian permet aux administrateurs des versions 8.16 de Jira Data Center d’ajouter des contextes avec une valeur par défaut à différents types de demandes et projets (comme on peut déjà le faire avec les champs personnalisés).

On peut malgré ça créer des champs personnalisés ou utiliser des plugins pour contrer ce problème. Par exemple, on peut définir une liste de conditions d’acceptance ou créer un champ de priorités pour implémenter la méthode MoSCoW (Must have, Should have, Could have, Won’t have).

En conclusion

Confluence et Jira ont tous deux des avantages et des inconvénients pour la gestion des user stories. Le principal est de choisir une méthode qui convienne le mieux à votre équipe. Si votre équipe préfère avoir des exigences bien structurées avec des informations complètes, partez sur Confluence. Vous ferez donc le lien vers les user stories créées dans Jira. Si elle ne veut pas passer d’un outil à l’autre et qu’elle veut avoir toute l’information centralisée à un seul endroit, quitte à ce que celle-ci soit un peu moins bien structurée, partez sur Jira tout seul.

Recommended Posts

No comment yet, add your voice below!


Add a Comment

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.