Jira contre le chaos en développement: comment ne pas perdre de tâches

Dans un article précédent , je vous ai dit quels add-ons pour Jira nous avons faits pour que le flux de travail devienne aussi pratique que possible et que le ticket soit exhaustivement informatif. Dans l'article d'aujourd'hui, nous allons résoudre un autre problème.

Étant donné:

• Vous développez et prenez en charge un produit logiciel complexe qui s'exécute sur plusieurs clients.
  
• vous disposez de plusieurs équipes d'ingénierie (backend, IT Ops, iOS, Android, web, etc.) qui fonctionnent indépendamment les unes des autres avec des backlogs distincts;
  
• vous avez plusieurs gammes de produits, c'est-à-dire, grosso modo, un chef de produit mène plusieurs projets dans sa propre direction, un autre chef - à sa manière;
  
• vos équipes d'ingénierie sont fonctionnelles, c'est-à-dire qu'elles ne sont pas affectées à des domaines de produits distincts, mais résolvent les tâches de toutes les unités en même temps, desservant une certaine partie de la pile technologique;
  
• et bien sûr vous utilisez Jira!
  

Les problèmes:

• les participants au processus ne comprennent pas de quelles pièces d'ingénierie la caractéristique est constituée et de quoi d'autre doit être fait sur le projet en ce moment;
  
• les équipes d'ingénierie travaillent sur le même projet de manière asynchrone: une équipe peut terminer sa partie il y a un mois, et la seconde ne peut même pas démarrer la sienne, car elle a oublié sa pièce dans le flux de tâches plus importantes.
  

Il y a un problème évident avec la transparence du processus de développement. Lorsqu'il y a beaucoup de projets et de directions, le besoin d'une sorte d'instrument magique qui élimine le chaos et donne une image claire est particulièrement aigu. Malheureusement, notre expérience montre que les fonctionnalités standard de Jira ne répondent pas pleinement à cela.

Est-ce familier? Réfléchissons à ce que nous pouvons y faire.

Structure du projet

J'analyserai le problème en utilisant l'exemple de développement dans Badoo. Alors, comment fonctionne le projet? Quelles sont les étapes du projet? Quelles pièces une nouvelle fonctionnalité typique consiste-t-elle à nécessiter la participation de plusieurs équipes?

Idée et design

Le chef de produit (PM), ayant trouvé ce qui peut être amélioré dans le produit, crée un ticket PROD avec le type Project dans Jira. La description de ce ticket se compose d'un lien unique vers une page dans Confluence (un analogue du wiki Atlassian qui s'intègre à Jira). Cette page est appelée PRD (Product Requirements Document). C'est un élément clé du développement. Il s'agit en fait d'une description détaillée de ce qui reste à faire dans le cadre du projet.


Lors de la création de ce document, PM travaille en étroite collaboration avec le concepteur. Pour cela, un autre ticket PROD avec le type Design est créé. Dans ce document, le concepteur place des mises en page, des jeux d'icônes, etc. Ces éléments sont ensuite insérés dans le PRD pour plus de clarté, et sont également utilisés par les équipes d'ingénierie en développement.

Après avoir rédigé le document, le PM le soumet à un débat public. Habituellement, d'autres PM ainsi que des chefs d'équipe d'ingénieurs participent à la conversation. La discussion est directement dans les commentaires sur PRD. C'est pratique, car l'historique des correspondances reste et tous les participants intéressés reçoivent des notifications lorsque de nouveaux commentaires apparaissent. Sur la base de la discussion, les modifications convenues sont apportées au PRD d'origine.

Lorsque toutes les nuances sont clarifiées, le ticket PROD initial est traduit dans le backlog du développement en attente. Après cela, une fois par semaine, l'équipe produit trie ce carnet de commandes par priorité en fonction des objectifs de l'entreprise, de l'épuisement estimé et de la complexité de la mise en œuvre. Les projets reconnus comme les plus prometteurs passent à l'étape suivante - la décomposition. Pour cela, un ticket MAPI spécial (API mobile) est créé pour l'équipe d'architectes système.

Il est important de noter ici que pour créer plus rapidement des tickets liés au projet, ainsi que pour éliminer le facteur humain (ils ont oublié quelque chose, mal lié ou marqué), nous avons automatisé ce processus. Ainsi, par exemple, le ticket racine du projet dans l'en-tête a deux boutons supplémentaires.



Le premier crée un ticket pour les concepteurs, le second pour les architectes système. Dans ce cas, les nouveaux tickets sont automatiquement remplis avec les attributs nécessaires: les étiquettes correctes, un lien vers PRD, un modèle de description, et surtout - sont liés les uns aux autres.

Cette optimisation de flux est implémentée sur la base du plugin Jira ScriptRunner , dont j'ai parlé dans un article précédent .

Décomposition

Après avoir reçu un nouveau ticket MAPI avec un PRD attaché, les architectes système décident:

• quelle partie de la logique doit être implémentée côté serveur et quelle partie côté client;
  
• quelles commandes le client doit envoyer et quelles réponses il doit recevoir du serveur;
  
• quels jetons doivent être «câblés» au client et lesquels doivent provenir du côté serveur.
  

Très souvent, à ce stade, un changement de PRD se produit. Les architectes approfondissent les détails de la mise en œuvre par rapport à PRD. Par conséquent, il peut s'avérer que pour atteindre les objectifs commerciaux du projet, il est possible, en abandonnant une partie des exigences initiales, de simplifier considérablement le développement. Nous apprécions vraiment cette initiative.

Vous pouvez en savoir plus sur le fonctionnement de notre équipe d'architectes et voir la description de notre API dans le rapport .

Les résultats du travail des architectes système sont:

1. L'apparition d'une documentation technique complète pour le projet (une description du protocole d'interaction client-serveur en référence aux cas de logique métier décrits dans PRD).
   
   
   Capture d'écran d'une partie de la documentation de l'une de nos fonctionnalités actuellement inactives

   
   
   
   
2. Protocole modifié (fichier au format Google Protocol Buffers) dans les référentiels. Si de nouvelles fonctionnalités ou des modifications des anciennes sont nécessaires pour implémenter des fonctionnalités, elles seront disponibles pour les développeurs de toutes les équipes.
   
3. Billets pour les équipes de développement et de localisation. Pour cela, nous avons une interface spéciale qui vous permet de créer simultanément les tickets nécessaires pour toutes les équipes impliquées. Il s'ouvre par un lien depuis un ticket MAPI.
   
   
   
   En cliquant dessus, l'interface suivante créée par nos soins s'ouvre:
   
   
   
   En cliquant sur le bouton en bas du formulaire (il n'est pas visible sur la capture d'écran), les tickets nécessaires apparaîtront, qui seront automatiquement liés au ticket MAPI d'origine. Il est à noter que toutes les équipes de développement travaillent dans notre propre espace (projet) Jira: l'équipe backend est en SRV, l'équipe Android est en AND, l'équipe web est sur le Web, etc.
   
   L'interface est basée sur l'API Jira REST.
   

Ainsi, la structure du projet peut être représentée comme le diagramme suivant:

Développement et lancement

Dans le cas général, toutes les équipes peuvent travailler sur un projet en parallèle, en ne touchant qu'au stade final de l'intégration, c'est-à-dire que les équipes clientes n'ont pas à attendre qu'un serveur fini fasse leur part. Comme le protocole d'interaction est décrit en détail, pendant le développement, vous pouvez émuler en toute sécurité la réponse attendue du serveur et déboguer la logique client. De plus, le serveur n'a pas besoin d'un client pendant le développement - le programmeur du serveur implémente simplement le protocole et le couvre de tests, émulant les demandes des clients.

En règle générale, une fonctionnalité est lancée dans le scénario suivant:

1. Le serveur est le premier à présenter sa partie de la fonctionnalité, couverte par l'indicateur de fonctionnalité, en production. Ainsi, cette logique reste inactive jusqu'à ce que l'un des clients commence à envoyer cet indicateur de fonctionnalité.
   
2. Les équipes clientes avant la sortie en production testent leur part des fonctionnalités déjà présentes sur le serveur «battle».
   
3. Dès qu'ils sont prêts, différents clients sont libérés, commencent à envoyer l'indicateur de fonctionnalité souhaité et à recevoir une nouvelle réponse du serveur.
   

La possibilité d'un travail synchrone sur le projet est un énorme plus, ce qui peut augmenter considérablement l'efficacité du développement. Mais c'est là que réside le risque: certaines équipes peuvent «écrire sur la table», c'est-à-dire faire leur part du travail, qui ne sera jamais demandée par d'autres participants au projet. Il peut y avoir plusieurs raisons:

• différentes priorités pour les équipes de développement; les problèmes ne se posent généralement pas lorsque vous travaillez sur des projets qui sont super importants pour l'entreprise (ils sont tous bien connus et difficiles à oublier), mais les moins importants peuvent être placés dans l'arriéré local d'une équipe distincte en dernier lieu;
  
• erreur de gestion de projet: le gestionnaire peut tout simplement oublier de prioriser correctement les tâches de l'équipe de développement, c'est-à-dire que ses participants ne sauront même pas que le ticket doit être mis en développement dès que possible.
  

Comment niveler ces problèmes? Comment s'assurer que les pièces du projet ne sont pas perdues et que les équipes accordent l'attention voulue aux projets prioritaires?

Caractéristiques standard de Jira

Que peut offrir la fonctionnalité Jira standard au chef de projet pour résoudre ces problèmes? Pas tellement:

• Filtres
  
• tableaux kanban.
  

Filtres

Le filtre vous permet de voir une liste linéaire de tickets reçus pour une requête JQL arbitraire. Cet outil est très pratique pour gérer l'arriéré d'une équipe, mais je ne sais pas comment l'utiliser pour une gestion de projet de haute qualité, répartie entre différentes équipes. Le maximum qu'un gestionnaire puisse faire est d'afficher une liste prioritaire de tickets PROD racine, puis vous devez aller dans chacun d'eux, en regardant les tickets liés. Mais cela est extrêmement gênant et long, d'autant plus que la hiérarchie des liens peut être à plusieurs étages. De plus, l'équipe de développement peut créer plusieurs tickets supplémentaires pour résoudre la tâche initiale, et leur statut doit également être surveillé.

Tableaux Kanban

Pour ceux qui ne savent pas comment cela fonctionne à Jira, je vais vous expliquer. En général, il s'agit d'une liste de tâches basées sur un filtre spécifique, regroupées en trois colonnes: «Backlog», «Tâches en développement», «Tâches terminées». L'interface vous permet d'augmenter la priorité des tâches en faisant simplement glisser un ticket dans la liste avec la souris. Dans le même temps, la propriété Rank change, vous permettant ensuite de trier les tickets dans vos filtres.

Ici, nous avons déjà beaucoup plus de place pour utiliser l'outil dans le contexte de la tâche à accomplir. PM peut créer un filtre qui sélectionne toutes les tâches de tous les services dans la direction souhaitée. Cela peut être fait, par exemple, en plaçant automatiquement des tickets avec les étiquettes correspondantes. Je vous rappelle que tous les tickets de projet clés pour notre projet sont créés à l'aide des outils appropriés. Par conséquent, la copie automatique des étiquettes nécessaires du ticket PROD racine vers tous les tickets dérivés est une tâche technique triviale.

Nous utilisons des tableaux Kanban pour former et contrôler les arriérés des équipes d'ingénierie. À l'aide de l'outil Swimlanes, une carte peut être regroupée en projets qui correspondent aux équipes d'ingénierie. Ainsi, à l'aide de cet outil, PM peut suivre l'avancement de ses projets dans le cadre de différentes équipes, ainsi que prioriser les tickets d'équipe.


Schéma d'un tableau de kanban de produit sur lequel les tickets de projets PM sont regroupés par équipes

Le problème est que l'outil ne fournit pas un moyen simple de regrouper les tickets par tickets PROD source, c'est-à-dire par fonctionnalités: je souhaite suivre l'avancement de chaque projet individuellement dans toutes les équipes d'ingénierie.

Excel

La solution la plus évidente consiste à utiliser des feuilles de calcul. Après tout, vous pouvez tout faire comme vous le souhaitez: pratique, beau, informatif. Quelque chose comme ça:



Vous pouvez voir la portée générale du travail pour chaque projet en un seul endroit. Vous pouvez prendre diverses notes, barrer les tickets terminés, etc. Tout est bon ici, sauf un gras mais: maintenir la pertinence de ces tableaux est extrêmement difficile. Les statuts des tickets changent constamment, de nouveaux sont en cours de création. Effectuez manuellement toutes les modifications? Vous pouvez le passer toute la journée. Mais nous sommes pour l'efficacité, non?

"Et traversons!"

Pourquoi n'utilisons-nous pas la commodité et la clarté des feuilles de calcul en ajoutant une synchronisation automatique avec Jira? Nous avons toutes les possibilités pour cela! Nous avons donc décidé de créer un outil supplémentaire basé sur l'API Jira REST, qui maintient automatiquement l'état actuel des informations et dispose d'une interface pratique pour nous.

Les exigences en matière d'outils étaient les suivantes:

• la possibilité de créer des listes de projets et de leurs dérivés à partir de tickets selon des requêtes JQL arbitraires (cela est nécessaire pour que tout PM puisse créer son propre espace (unité) dans lequel il ne verra que ses projets et les gérera);
  
• les nouveaux projets dans Jira devraient apparaître automatiquement dans l'interface;
  
• de nouveaux tickets dans le projet devraient apparaître automatiquement dans l'interface (c'est-à-dire que si l'équipe de développement décide que plus de tickets sont nécessaires pour implémenter la fonctionnalité, le PM le verra immédiatement dans l'interface);
  
• en fonction du statut des tickets, les couleurs des cellules du tableau doivent changer (pour une compréhension rapide par les participants du statut du projet);
  
• la capacité de trier les projets (pour les prioriser correctement);
  
• masquage automatique des projets terminés deux semaines après leur achèvement.
  

PM commence à travailler avec l'outil, créant son propre espace (unité), indiquant son nom et sa requête JQL:



Ensuite, une demande est faite à Jira pour obtenir une liste de projets pour la requête JQL spécifiée. Tous les tickets dérivés des équipes d'ingénieurs utilisent également des liens dans Jira. Le résultat est quelque chose comme ce tableau:



Ci-dessus, des liens pour basculer entre les unités.

Les lignes du tableau sont les tickets PROD racine de l'unité. Dans les cellules, nous voyons les tâches du projet pour des départements d'ingénierie spécifiques. Le remplissage a lieu automatiquement sous réserve des règles de liaison entre les tickets de projet. Les étapes terminées sont marquées en vert, non commencées en rouge et en cours en jaune.

Les liens mènent à des billets pour Jira. Vous pouvez également obtenir de brèves informations sur le billet en survolant le lien:



Avec une fréquence d'une fois toutes les quelques minutes, une demande est faite à l'API Jira pour obtenir une liste à jour des projets pour toutes les unités, pour synchroniser la liste des dérivés de tickets, ainsi que leurs statuts actuels.

Le tri se fait par simple glisser-déposer du projet souhaité à l'emplacement souhaité dans la liste:



Il est important de noter qu'avec cet outil dans Badoo, non seulement les chefs de produit travaillent, mais aussi les chefs d'équipes d'ingénierie. Après tout, il est important que chacun comprenne ce qui se passe dans les domaines de produits, quelles équipes ont avancé dans la mise en œuvre de projets importants pour l'entreprise plus que d'autres, et qui sont en retard.

Conclusions

Jira "out of the box" fournit des fonctionnalités puissantes pour gérer la structure du projet et la relation entre les tickets. Il existe également des plugins qui étendent considérablement les capacités de JQL (par exemple, ils vous permettent d'utiliser des liens entre les tickets et leurs types pour filtrer les tickets). Dans notre cas, nous ne manquions que de la capacité de tout visualiser selon nos besoins.

Heureusement, Jira permet de créer des outils pratiques supplémentaires basés sur son API, adaptés aux processus métier de l'entreprise. Ainsi, par exemple, nous avons pu résoudre le problème qui se posait avec la transparence de la conduite de projets dans une douzaine de produits, avec un peu d'effort et en utilisant les fonctionnalités supplémentaires de ce tracker de tâches. Il serait intéressant de lire dans les commentaires si vous avez essayé de faire de tels modules complémentaires chez vous ou avez trouvé d'autres solutions pour vos tâches.

Merci à tous pour votre attention!