Configuration Jira plusieurs équipes

[Valentin]

Bonjour à tous ! 

Je souhaiterais échanger sur la manière dont vous fonctionnez techniquement avec plusieurs équipes sur Jira et être conseillé par rapport à notre fonctionnement. 

Nous sommes une jeune startup éditrice de logiciels et aujourd'hui nous sommes organisés de la manière suivante : 

• Une équipe backEnd (4p)
• Une équipe frontEnd (3p)
• Une équipe Design (2p)
• Une équipe Q/A (2p)

Dans les grandes lignes, notre fonctionnement est le suivant : 

• L'équipe FrontEnd ne doit pas démarrer une feature tant que le backEnd et le Design ne sont pas terminés à 100% 
• L'équipe Design travaille sur l'UI/UX de nos applications mais également sur des supports de communication (ses tâches ne sont donc pas à 100% reliées aux équipes de dev)
• L'équipe Q/A s'occupe de tester le travail du BackEnd puis, la feature complète une fois le frontEnd terminé. 
• Nous développons de multiples applications pour nos clients mais tout le monde intervient sur toutes ces applications. 
• Nous utilisons Jira Service management pour le support client 

Auriez des conseils concernant ces questions ? 

• Cherchant à améliorer notre approche agile, je souhaite avoir une visualisation claire de l'avancée de chaque feature (US ou EPIC) . Nous recommanderiez vous de fonctionner sur un seul projet Jira avec plusieurs boards ou bien de séparer chaque équipe sur différents projets ? Est il possible de relier des tickets de projets différents à la même US / même EPIC ? 
• Selon vous, faudrait-il inclure le travail non relatif au dev de l'équipe design sur Jira, sachant que des tâches peuvent leur être attribuées "au dernier moment" ? 
• Comment l'équipe de Q/A pourrait avoir une vue d'ensemble du travail de test à effectuer ? (Tickets dans la colonne test aussi bien frontEnd que backEnd)
• Auriez vous des propositions de fonctionnement à mettre en place ? :) 
  
  

Merci pour votre aide ! Et je suis curieux de savoir quels sont vos fonctionnements / process si vous organisation est similaire. 

[Marie-Hélène PARISATO]

Bonjour, je ne vais pas forcément vous apporter beaucoup d'aide mais juste un retour d'expérience.

Vous pouvez lier des tickets de différents projets à un meme story ou epic à partir du moment où vous ouvrez vos projets les uns aux autres. De ce fait nous avons créer un projet 'REFERENTIEL' qui est ouvert à tous et qui contient les objets que chaque projet doit voir.  

[Régis Odoardi Wonner]

Bonjour,

je ne suis pas dans le cas d'une startup mais d'un service IT interne à un groupe industriel mais nous nous posons régulièrement cette même question.

Je n'ai pas de réponse parfaite mais voici ce que nous faisons.

Pour répondre à la question "un seul ou plusieurs projets", nous avons mis une frontière autour des équipes techniques afin qu'elles puissent travailler en toute tranquillité.

Dans notre cas, nous avons:

• 1 projet "analyses fonctionnelles" (ce groupe n'apparait pas dans votre description mais il doit exister d'une façon informelle). Il s'agit des personnes qui définissent les fonctionnalités du produit, son évolution et qui font la communication.
• 1 projet HELPDESK pour le support.
• 1 projet "développement" ("Software Development" pour reprendre les termes JIRA).

Les tickets du support sont soit traités directement par le support, soit clonés et liés à un ticket qui apparaitra dans le projet d'analyse fonctionnelle (demande d'évolutions) ou dans le projet de développement (bugs).

Les Story du projet "analyste fonctionnelle", une fois validées, sont clonées dans le projet développement.

Nous avons un PLAN qui permet de visualiser pour un logiciel le projet d'analyse fonctionnelle et de développement. Cela n'est pas toujours pertinent. Tenir informer les équipes techniques des fonctionnalités futurs est parfois utile mais souvent cela est perturbant et peut inutilement impacter le planning. Il est nécessaire d'avoir un bon "coordinateur" (Scrum Master) entre ces deux équipes.

Les versions sont gérées dans le projet développement.

Quand vous écrivez "Nous développons de multiples applications pour nos clients mais tout le monde intervient sur toutes ces applications", c'est là qu'est une partie de la complexité pour la gestion de la charge de travail prévisionnelle. L'utilisation des PLAN résout une partie de ce problème mais que partiellement. Nous avons régulièrement des goulots d'étranglement sur certains profils.

J'espère avoir pu vous aider.

Je suis également preneur de toute idée concernant ce sujet.

[Valentin]

Merci pour ces retours ! 

Je viens de prendre connaissance de ceci disponible uniquement en version premium : 

https://www.atlassian.com/software/jira/guides/advanced-roadmaps/overview#what-are-advanced-roadmaps

Aussi je me suis rendu compte que nos projets sont "gérés par l'équipe" alors que "géré par l'entreprise" semble apporter une plus grande flexibilité. 

Je pense que je vais tenter ceci comme fonctionnement : 

• Un projet JSM (déjà en place) pour que nos clients remontent un bug ou une demande d'amélioration - Bug géré par l'équipe Q/A et amélioration par l'équipe produit
• Un projet pour le PO KANBAN où seront créés les US et les EPIC 
• Un projet BACKEND SCRUM avec les tickets reliés aux US du projet PO
• Un projet DESIGN KANBAN  avec les tickets reliés aux US du projet PO et les tickets frontEnd en attente de validation par l'équipe design
• Un projet FRONTEND SCRUM avec les tickets reliés aux US du projet PO et avec des liens avec les tickets FRONTEND & BACKEND 
• Un projet Q/A KANBAN pour cloner les bug à investiguer de JSM et un BOARD qui référence les tickets FRONTEND & BACKEND qui sont dans la colonne "test"

Je vais essayer de creuser avec ce fonctionnement. 

Qu'en pensez vous ? 

[Jean-Emmanuel BANQUEY]

Bonjour @Valentin,

Désolé, je vais faire mon Agiliste convaincu (je suis Scrum Master) et puisque tu veux des conseils, je mets mon grain de sel -> le modèle que tu décris ressemble à vue de nez à du bon vieux mode cascade dit "Waterfall" (ou "Cycle en V" pour les plus anciens professionnels de l'IT).

En mode produit, je te conseillerai de basculer sur un mode Agile avec ses personnes aux compétences diverses réparties équitablement dans plusieurs équipes (l'idéal est même de les laisser choisir leur équipe) soient 2 équipes avec 2 FE, 2 BE, 1 UX/UI et 1 QA par exemple.

Ensuite vous vous mettez d'accord soit avec les lead dév, les PO ou les managers (ou mieux, un board composé de tout ça) pour répartir les features rangées par priorité (le + d'apport de valeur pour les clients/utilisateurs) des phases design jusqu'à la mise en prod dans une équipe ciblée et idéalement motivée ;).

Tu auras sûrement des résultats plus fluides et tes clients auront les features unitairement et donc plus rapidement (vous ne développerez pas plus vite mais vous livrerez au compte-goutte et donc plus tôt celles qui sont importantes) 

Après si ta startup réalise des projets avec un budget de départ imposé et une date de livraison assez peu flexible (qui sera fausse dès le départ), là, en effet, un mode Waterfall se justifie. Ne tiens pas compte de mon message du coup ^^ A savoir qu'un mode hybride est faisable mais vachement casse-gueule aussi.

Prends mon message comme une déformation professionnelle et non comme un jugement : je suis bien loin de ton contexte pour affirmer que ce que tu décris ne va pas marcher :)

Si tu veux en savoir plus, je peux te filer des ressources pour approfondir :) 

Amicalement,

[Valentin]

Hello @Jean-Emmanuel BANQUEY , 

Merci pour ton retour !  Je vais songer à cela, c'est en effet intéressant sachant que nous cherchons à nous rapprocher de plus en plus d'un fonctionnement agile. 

Je pensais que notre approche l'était déjà dans une certaine mesure mais visiblement peut être pas :). Je ne pense pas que notre contexte et organisation en terme d'équipe soit peu fréquent et particulier. 

Je trouve cela intéressant mais je me demande comment cela pourrait fonctionner ainsi chez nous. 
Admettons que nous créons 2 équipes qui avancent ensemble sur les mêmes feature.

Techniquement, tout le monde de la même équipe travaillerait sur le même ticket Jira sur le même board ? 

Que font les personnes qui doivent attendre qu'une autre ai fini sa tâche pour commencer la sienne ? 

Comment le travail annexe de certains (design par exemple) qui ne sont pas à 100% sur la partie développement produit est géré dans tout cela ? 

Aujourd'hui nous avons bien un board avec les features/epics/support client qui sont remontés et ensuite priorisés en fonction de la plus value apportée et de l'urgence. 
Cependant nous fonctionnons avec une seule "grande" équipe (pas si grande vu que nous sommes à peine une dizaine) et chaque sujet est traité dans des sprints de 2 semaines. 

Il est vrai qu'il nous arrive régulièrement d'avoir des dates très peu flexibles sur des features à apporter, et qui arrivent parfois assez tardivement. 

Si tu as des ressources qui pourraient m'aider je suis toujours preneur ! 

Merci pour ton aide 

[Jean-Emmanuel BANQUEY]

Bonjour @Valentin 

Désolé, cela fait 2 fois que mon loooooong message saute et disparaît donc j'abandonne ce canal de $£#!%. J'espère que tu as eu les notifs de réponse au moins et le contenu ?

Si tu veux en discuter et approfondir, cherches moi sur LinkedIn ;)

A+

[Sylvain Populaire]

Bonjour @Valentin ,

+1 pour le mode "feature team"  décrit par @Jean-Emmanuel BANQUEY  !

Côté Jira, j'organiserais les choses de la manière suivante :

• 1 epic par feature (renommer epic en feature, c'est encore mieux). Le backlog des features est géré par un "Product Manager/Product Owner" en charge de les décrire, prioriser, ... 
• Des US pour découper le travail au sein des features. Si les différents composants de votre produit font l'objet de releases indépendantes alors j'aurais tendance à gérer chaque composant du produit dans un projet Jira distinct pour gérer proprement ces releases (et ne pas mélanger les releases back et front dans le même projet). Les US au sein d'une epic peuvent sans problème provenir de projets différents.

Pour le travail des équipes, il me parait indispensable d'avoir un board par équipe :

• Si vous ne passez pas en mode feature team, l'équipe back traitera les US du projet back, etc. Dans ce cas, 1 board = 1 projet
• Si vous adoptez le mode feature team, vous pouvez affecter les US à la bonne feature team via un champ dédié. Le board de chaque équipe sera alimenté via les US affectées à l'équipe

Pour la partie testing, j'utiliserais un plugin de type xray pour organiser le travail (définition des tests sur les features, création des campagnes, ...) et des boards dédiés.

En synthèse : 

• 1 projet de niveau "Produit" pour les features (+ 1 board associé)
• 1 projet par composant du produit faisant l'objet de releases indépendantes pour les US
• 1 board par équipe (avec ou sans orga en feature team)
• xray pour gérer la partie testing

Les dépendances entre les US peuvent être gérées via des liens (US front is blocked by US back). 

Bonne continuation !