Jira

Jira pour cadrer le backlog quand le client y est déjà. Ce n’est pas la source de vérité : le dépôt (critères, CI, doc courte) l’est. Jira, c’est le tableau de bord — pas l’endroit où stocker le métier.

On s’y branche pour parler le même langage que le SI client. Sinon, on préfère GitHub Issues / Projects, Bitbucket, ou un board léger (Trello) — sans disperser le savoir hors du repo.

Jira est un outil de pilotage : issues, backlog, sprints, workflows. Utile pour rendre visible le travail et aligner métier / tech.

Chez iD, le dépôt reste la source de vérité. Jira ne remplace ni le Brief, ni les critères Gherkin, ni la CI, ni la doc dans le repo. Il sert à suivre ce qui est décidé — pas à stocker le métier dans des tickets.

On l’utilise quand le client y est déjà, ou quand plusieurs parties prenantes ont besoin d’un suivi partagé. On évite de forcer un autre outil « parce que nous on préfère ».

Sinon, on reste centralisé : GitHub Issues / Projects (ou Bitbucket), parfois Trello si l’équipe métier y vit déjà. L’outil de board suit l’existant ; le savoir utile reste versionné avec le code.

Bon choix pour des projets multi-équipes, des audits suivis, ou un client qui exige Jira pour la gouvernance. On le configure sobrement : colonnes claires, peu de champs obligatoires, liens vers les critères et le repo.

On passe si le projet est petit, si un board forge ou Trello suffit, ou si Jira est devenu un goulot (processus plus lourds que le code). Dans ce cas, on allège — et on recentre sur le dépôt.

Vous voyez l’avancement là où votre organisation travaille déjà, sans doubler la vérité du livrable. Méthode iD : périmètre tranché, critères exécutables, pipeline vert, doc dans le repo. Le Brief 45 min clarifie si Jira aide ou freine.