Tempo : pourquoi SmartView est devenu partenaire

Depuis Décembre 2020, SmartView est devenu partenaire d’un éditeur d’une suite de plugins Atlassian, Tempo.

La suite Tempo, c’est un ensemble de plugins : Tempo Timesheets, Tempo Planner, Tempo Budgets et Cost Tracker for Tempo.

Ils permettent de gérer les feuilles de temps, le planning des équipes et les budgets directement dans Jira. Edités depuis 2009, les produits Tempo équipent aujourd’hui plus de 20 000 entreprises à travers le monde.

Tempo Budget - plugin pour Jira - gestion des finances

Pourquoi nous préférons limiter l’utilisation de plugins sur des instances Jira ?

Comme nous l’avons vu précédemment, nous nous efforçons lors de chacune de nos interventions de proposer à nos clients des solutions simples et rapides à utiliser et à administrer. Cela nous permet de limiter autant que possible le nombre de plugins que nous déployons.

De plus, chez SmartView, nous avons à coeur de travailler avec les valeurs et méthodes agiles. Celles-ci guident l’ensemble de nos interventions et bien souvent les organisations de la plupart de nos clients.

Ainsi, il est vrai que les notions de planifications et de suivis des temps  d’une granularité très fine des plugins Tempo nous apparaissaient comme étant peu compatibles avec ces valeurs et méthodes agiles que nous prônions.

Pourtant, force est de constater que les promesses de la suite Tempo paraissent souvent attrayantes pour le Top management et les contrôleurs de gestion. À l’inverse, la mise en place de ce type de plugins de suivi des temps est souvent perçue par les équipes utilisatrices comme une « bureaucratisation » des outils Atlassian. Surtout que ceux-ci peuvent alourdir sensiblement l’utilisation quotidienne de Jira qui est initialement consacré à leurs « vrais métiers » (développement, tests, supports, release…)

La valeur produite par les équipes informatiques qui travaillent sur les outils Atlassian est visible et mesurable à travers les logiciels produits et les services apportés aux autres métiers d’une organisation. Il est cependant souvent très difficile d’en mesurer avec précisions les coûts, et surtout de les ventiler correctement et simplement entre les différent projets ou process d’une DSI.

Un outil comme Jira ne peut répondre de façon exhaustive, simple et automatique à ce besoin légitime.

Tempo Planner - Suite de plugins pour Jira- planification des ressources

Notre retour d’expérience client sur la suite de plugins Tempo

Nous avons travaillé de manière presque simultanée avec deux clients utilisateurs de la suite Atlassian. Leurs activités, tailles et organisations sont très différentes mais leurs problématiques ont été similaires :

  • Comment contrôler et valider rapidement les temps facturés par les prestataires ?
  •  Comment distinguer facilement les charges et les immobilisations d’une DSI ?

Pour répondre à ces deux problématiques, nous avons décidé de nous plonger – avec appréhension je dois l’admettre – dans l’univers de Tempo.

À l’issu d’une étude détaillée, nous avons été convaincus que la suite Tempo permettrait de répondre à ces questions.

Le défi de la réussite de mise en œuvre résidait selon nous dans deux facteurs clé de succès :

  • Maîtriser les outils Tempo pour être en mesure de proposer une solution simple et évolutive, et surtout éviter l’effet «usine à gaz ».
  • Réussir l’adoption de la solution par les utilisateurs, en évitant les craintes de contrôle de la part du management et de complexité inhérentes à ce type de projet.

C’est donc pour mieux comprendre les subtilités des concepts Tempo que nous nous sommes initialement rapprochés des équipes de Tempo. Elles ont pris le temps d’analyser avec nous nos cas d’usage. Et elles nous ont aidé à arbitrer au mieux les différents scénarios envisagés :

  • Comment garantir une solution ergonomique pour les utilisateurs finaux, simple et robuste à administrer ?
  • Comment structurer les demandes, comptes et équipe Tempo pour faciliter les saisies de temps ? Le tout, en permettant de produire rapidement des reporting aux niveaux projets, programmes, services et fournisseurs ?
  • Quelle option retenir pour la gestion des TJM des prestataires ? Les intégrer dans Jira et Tempo ou les déporter dans un référentiel externe Excel ou Power BI ?

À l’issue de cette phase de conception, nous avons abouti à deux solutions proches pour nos clients. Celles-ci n’ont évidemment pas été similaires compte tenu des besoins de reporting et des organisations différentes entre nos deux clients.

Tempo Timesheets - Plugins Jira pour suivre le temps automatiquement - feuilles de temps

Mise en oeuvre de la solution Tempo

L’option retenue la plus structurante était de ne pas demander aux utilisateurs de saisir leur temps sur les demandes « opérationnelles » comme les users stories ou les bugs. À la place, nous leur avons proposer de créer  des projets et demandes Jira spécifiques qui correspondent à des unités budgétaires ou types d’activités qu’ils souhaitaient monitorer.

Nous avons ensuite pu réaliser les mises en production. Afin de faciliter l’adoption de la solution, la communication projet a été axée sur deux axes :

  • Pourquoi saisir ses temps dans Tempo ? Nous avons rappelé les enjeux attendus pour l’organisation et les différentes équipes.
  • La simplicité de la saisie des temps dans Tempo. Nous nous sommes appuyés sur l’ergonomie des outils, leurs intégrations à Jira, ainsi que sur des équipes pilotes ambassadrices de la solution.

Enfin, la dernière étape a été  le transfert de compétences. le but était de permettre aux équipes de nos clients d’être autonomes dans l’administration et l’évolution de leurs solutions Tempo.

Nous avons impliqués nos clients dès la phase de cadrage du projet. De cette manière, nos interlocuteurs se sont naturellement appropriés les nouveaux concepts et fonctionnalités des plugins Tempo pendant la phase de mise en œuvre.

Nous avons également accordé une attention toute particulière à la documentation des solutions mises en oeuvre. Cette phase est importante car elle permet de garantir la stabilité de la solution. Pour cela, nous leur avons détaillé non seulement les paramétrages réalisés, mais également les raisons des choix d’architectures et leurs impacts.

Quelle conclusion tirer de ces deux expériences ?

Pour suivre les temps d’une DSI, l’intégration de la suite Tempo à Jira est une option intéressante. Cependant, elle doit découler d’un réel besoin et non d’une volonté de contrôle des équipes de la part du management.

De plus, il est nécessaire de favoriser la simplicité et l’ergonomie de la solution afin de ne pas complexifier une instance Jira. Celle-ci doit rester souple, évolutive et aider les équipes sans leur donner plus de travail.

Enfin, dès lors que les équipes sont impliquées et qu’elles comprennent l’intérêt d’un outil de suivi des temps comme Tempo, l’adoption de la solution peut se faire rapidement et facilement à l’échelle d’une DSI de plusieurs centaines de collaborateurs.

Merci à nos clients pour leur confiance, et merci aux équipe Tempo pour leur support !

N’hésitez pas à nous contacter si vous souhaitez savoir comment mettre en place les plugins Tempo dans votre entreprise.

Pourquoi nous avons choisi Jira Service Management

« Le court-terme et les enjeux de l’IT long-terme de mon entreprise : mon choix de Jira Service Management avec SmartView » 

(english version below)

Interview-smartview-jira

« Je vais parler en toute transparence ». Joli début pour une interview ! Notre invitée travaille pour un leader mondial, spécialisé dans la distribution de matériel électrique et la gestion de l’énergie. Des urgences du court terme à la stratégie à long terme, les conseils IT et l’ITIL, Atlassian Jira et Service Now… La consultante Olga Campeis a recueilli son témoignage sur des sujets brûlants. 30 minutes en compagnie d’une professionnelle de l’IT de haut vol.

En respect des règles de l’entreprise, le nom et la société de notre invitée sont restés anonymes. 

Olga : Nous parlons d’IT. En quoi « l’honnêteté » est-elle essentielle dans votre entreprise ?

Invitée : J’ai des années d’expérience dans la collaboration avec des cabinets de conseil. Un message pour toutes ces sociétés : vendez quelque chose dont le client a besoin ! En tant qu’entreprise, j’ai besoin d’une transparence totale. En tant que manager, j’ai besoin de comprendre ce que nous pouvons faire, ce que nous ne pouvons pas faire. Le plus étonnant ? Ce type de cabinet de conseil est si rare à trouver sur le marché.

La transparence est une grande plus-value de SmartView par rapport aux autres. Un vrai plaisir !

Olga : Parfois, les clients veulent entendre ce qu’ils aiment entendre. Avec votre entreprise, les choses sont différentes. C’est donc un plaisir partagé !

Invitée : Nous avons une approche ouverte. Voici un exemple récent. Un nouveau sujet est apparu. Un membre de l`équipe SmartView a dit « Je n`ai pas la réponse », a proposé de vérifier et est revenu avec la réponse. Je sais que je peux faire confiance à la réponse de ce consultant. Parfois, SmartView propose une option plus souple et plus rentable pour mon entreprise, même si elle gagne moins d’argent ! C’est un véritable changement !

Olga : SmartView fête son 10e anniversaire. Avez-vous un message à faire passer ?

Invitée : Je refuse habituellement les interviews parce que ce n’est pas la politique de l’entreprise. Je suis contente d’apporter également une valeur ajoutée à SmartView. Le nom de votre entreprise est le bon : vous fournissez une vue intelligente. Parce qu’elle apporte beaucoup de valeur. Parce que vous êtes intelligents, pragmatiques et vous apportez des avantages à long terme. 

Covid-19-objectif long-terme avec jira service management

Olga : Merci ! À cause de la Covid-19, est-il réaliste de travailler sur le « long terme » ?

Invitée : Attention, ne vous méprenez pas ! Parfois, nous avons besoin d’une solution rapide, qui donne lieu à des résultats immédiats mais peu convaincants. Cependant, offrir une perspective à long terme est vraiment ce que nous voulons faire… Au moins, nous avançons pas à pas, avec une approche agile. Notre but est de nous rapprocher de l’objectif à long terme que nous nous sommes fixé. 

Olga : Le Service Desk de Jira d’Atlassian fait partie de votre périmètre. Où voyez-vous cette solution dans votre « schéma directeur » IT ?

Invitée : Parfois, les gens pensent que le Ticketing n’est qu’un détail. Le Ticketing, avec la bonne structure, à travers le catalogue de service, les SLA, est la colonne vertébrale IT de l’entreprise. Ce n’est pas uniquement un bloc-notes. C’est la façon par laquelle l’efficacité est obtenue et les processus IT quotidiens sont organisés. 

Les gens mettent en œuvre ITIL et les référentiels de gestion. Mais vous avez vraiment besoin de l’ADN et de la structure appropriés, sinon cela restera uniquement sur le papier. 

Olga : Vous considérez donc les systèmes de ticketing comme un maillon essentiel ?

Invitée : Oui, le ticketing occupe une place importante. « La mise en œuvre à l’aveugle » par l’intermédiaire de processus : produire, produire, produire, produire… mais quelle est la stratégie ? Nous ne pouvons pas avancer sans réfléchir. Quoi que nous fassions, nous nous projetons dans l’avenir. Nous avons obtenu d’excellents résultats avec la mise en place de Jira Service Management* au siège. Et maintenant, de plus en plus de filiales dans le monde entier migrent également sur Jira. 

Olga : Des exemples ?

Invitée : Au siège, un Département nous avait affirmé : « Jira convient aux informaticiens uniquement ». Ils avaient comparé Jira à des services de ticketing externalisés. Puis ils ont été agréablement surpris par le résultat : « Vous êtes sûr que c’est vraiment Jira ? » ont-ils conclu !

Olga : Pourquoi Jira a-t-il fait la différence ?

Invitée : Vous pouvez faire vite et bien. Vous pouvez aussi passer des heures à planifier la solution idéale. Toutefois, la bonne approche consiste à travailler sur les actions correctives, à demander aux utilisateurs actuels et futurs leurs attentes, leurs exigences, leurs contraintes, etc. Pas seulement avec Jira, j’ai déjà utilisé Service Now.

Olga : … et vous n’aimiez pas Jira au début !

Invitée : C’est vrai, Olga, vous avez bonne mémoire ! Service Now était vraiment bien organisé. J’étais aveugle parce que j’essayais de voir Jira à travers le prisme d’autres outils. Merci à SmartView de m’avoir ouvert les yeux ! J’ai fini par devenir  » Madame Jira  » ! Mais mon vrai métier est de sensibiliser la société. J’apporte de nouvelles réponses à des besoins spécifiques ou à la suite d’un audit. J’apprécie l’aide de SmartView. On peut faire des erreurs un peu partout. C’est comme en cuisine, il y a de nombreuses possibilités pour se tromper.

Smartview Paris - Partenaire Jira Atlassian

Olga : La cuisine, belle métaphore. Et si un DSI ou un responsable IT vous posait des questions sur SmartView, que répondriez-vous ?

Invitée : SmartView écoute. Nous exprimons nos besoins aux consultants. Ils travaillent sur les besoins et nous présentent ensuite une solution. Ce que j’aime c’est que SmartView explique les avantages à long terme : maintenance, efficacité, standardisation…

Olga : Si Jira est la colonne vertébrale IT, vous avez un impact considérable… pour le meilleur ou pour le pire ?

Invitée : Le ticketing a un impact sur la façon dont les gens travaillent. Les utilisateurs pourraient devenir schizophrènes si nous ne faisions pas attention. Nous avons besoin de la collaboration des utilisateurs. Certaines entreprises offrent des choses que les clients souhaitent à court terme… mais à long terme, c’est une autre histoire !

Olga : Pourquoi faites-vous référence à SmartView comme un véritable partenaire ?

Invitée : Une partie importante est la communication avec SmartView. Quand vous pensez que les gens s’intéressent à vous, alors la collaboration fonctionne. Quoi que nous fassions, quoi que nous discutions, c’est un partenariat solide. L’une des valeurs de ma société est de prendre plaisir à faire la différence. J’aime travailler avec SmartView. C’est tellement important. Surtout dans le contexte Covid. Chaque fois que j’ai besoin d’une nouvelle proposition d’amélioration, d’une nouvelle fonctionnalité à analyser, je le fais avec joie ! Et je sais que ce sentiment est partagé avec mon partenaire…

Olga : J’apprécie vraiment d’avoir un seul point de contact. Vous vous êtes occupée de tous les besoins. Puis tous les interlocuteurs ont été ajoutés au projet. Nous avons fait les choses plus vite et mieux. Nous savons toutes les deux comment nous travaillons. J’aime beaucoup ça.

Invitée : Le partenariat et la confiance sont perpétuels. Il n’y a pas de bouton ON/OFF

Olga : Et vous avez aussi de formidables compétences en matière d’interview !

Invitée : C’est une question de contexte. Vous savez que je suis vraiment sincère. Je ne peux pas mentir. Je n’aime pas mentir. La transparence est le point fondamental.

Olga : Comment voyez-vous l’avenir ?

Invitée : Je crois qu’après un an de développement continu, j’aimerais d’abord creuser la stratégie et la signification des processus IT au sein de l’entreprise. Je veux identifier les domaines dans lesquels l’outil de ticketing et les services de conseil peuvent apporter une meilleure valeur ajoutée. Nous avions une approche de pompier, maintenant nous devons prendre notre respiration, construire une approche ITSM** fédérée de Jira avec la bonne intégration. 

Au siège, on utilise Jira. D’autres filiales dans le monde possèdent également Jira ou d’autres outils de ticketing. Nous avons besoin d’une plateforme fédérée, connectée et partagée mais sans pour autant compromettre le résultat actuel obtenu par chaque filiale. Cela implique une approche IT à long terme, au niveau mondial, intégrée.

Olga : Merci pour votre temps précieux ! 

Invitée : (le téléphone se met à sonner) Mon prochain appel concerne le catalogue des services. Il va devenir l’épine dorsale de la société. J’agis maintenant dans une perspective à long terme…

Interview réalisée par notre consultante Olga Campeis.

Olga est consultante chez SmartView. Elle travaille principalement avec Jira et Confluence pour fédérer les processus et produire une amélioration continue.

*Jira Service Management : anciennement Jira Service Desk

**ITSM : IT Service Management / Gestion des services informatiques

(English version below)

Mixing short-term and long-term Enterprise IT: my choice for Jira Service Desk with SmartView 

“I will speak honestly.” Nice start for an interview! Our Guest works for a Worldwide Leading Service Provider in the Energy Business. Short-term emergency vs longer-term strategy, IT guidance vs ITIL, Atlassian Jira vs Service Now… Consultant Olga Campeis got insights over many hot topics. 30 minutes well spent with a world-class IT Professional.

To follow company rules, our Guest’s name and company remain anonymous. 

Olga: We are talking about IT. Why is “honesty” essential in your Business?

Guest: I’ve got years of experience in working with Consultancy Firms. One message to all of them: sell something that the customer needs! As a business, I need complete transparency. As a manager, I need to understand what we can do, what we cannot do. The amazing fact? This type of Consultancy Firm is so rare to find on the market.

Transparency is a big value-add for SmartView compared to others. A real pleasure!

Olga: Sometimes clients want to hear what they like to hear. With your Company, things are different. Therefore it is a shared pleasure!

Guest: We have an open approach. Here is a recent example. A new topic came up. Your SmartView team member said “I don’t have the answer”, offered to check and came back with the response. I know I can trust the answer from this Consultant. Sometimes SmartView will come up with a more flexible and cost-effective option for my Company, despite earning less money! It makes a refreshing change!

Olga: Our Company celebrates its 10th Anniversary. Anything to say?

Guest: I typically decline interviews because it is not company policy. I’m glad to bring added value to SmartView as well. Your Company name is the right name: you provide a Smart View. Because it brings a lot of value. Because you are: Smart, Pragmatic and bring long-term Benefits. 

Olga: Thank you! Because of Covid-19, is it realistic to think “Long-Term”?

Guest: Don’t get me wrong! Sometimes, we  do need a quick win, which results in   quick but dirty options. However providing a long-term perspective is really what we want to do… At least, we move forward by a small short step, with an agile approach. Our aim is to get positioned closer to the long-term designed goal. 

Olga: Jira Service Management* from Atlassian is part of your responsibilities. Where do you see this solution in your IT “Grand Plan”?

Guest: Sometimes people think Ticketing is not even interesting to mention. Ticketing, with the right structure, across Service Catalogue, SLA, is the backbone of the Company IT. It is not just a notebook. It is the way efficiency comes and day-to-day IT processes are organized

People implement ITIL and design standards. But you really need the right DNA and structure, otherwise it will only stay on paper. 

Olga: So you see Ticketing Systems as part of the big picture?

Guest: Yes, ticketing has a large footprint. “Blind execution” through processes: deliver deliver deliver… but what is the strategy? We cannot move like headless chickens. Whatever we do, we think about the future. We have great results with our implementation of Jira Service Desk at Headquarters. And now more and more subsidiaries worldwide are moving to Jira too. 

Olga: Any examples?

Guest: At Headquarters, one Department said “Jira is for IT people only”. They benchmarked Jira against externalized Ticketing Systems. They were pleasantly surprised with the result: “Are you sure this is really Jira?”!

Olga: Why did Jira make a difference?

Guest: You can make it quick & dirty. You can as well spend ages on planning the ideal solution. However the right approach is to work on the improvement actions, ask future and current users for their expectations, requirements, constraints, etc. Not just with Jira, I’ve used Service Now previously.

Olga : … and you didn’t like Jira at the start!

Guest: Good memory Olga! Service Now was so well organized. I was ignorant because I was trying to see Jira through the prism of other tools. Thank you SmartView for opening my eyes! I eventually became “Mrs Jira”! But my real job is to bring awareness to the Company. I provide better responses to specific needs or following an audit. I do appreciate SmartView’s help. You can do it wrong everywhere. It is like cooking, there are many ways to get it wrong.

Olga: Cooking, nice analogy. And if a CIO or IT Manager asked about SmartView, what would you respond?

Guest: SmartView do listen. We tell the Consultants our needs. They work on the requirements then they come with a proposal. What I like with the SmartView people, you explain the long-term benefits: maintenance, efficiency, standardization…

Olga: If Jira is the IT backbone, you do have a deep impact… for the better or for the worse?

Guest: Ticketing impacts the way people work. Users could become schizophrenic if we are not careful. We need collaboration with users! Some companies do offer things clients want short term… but long term is a different story!

Olga: Why do you refer to SmartView as a true partner?

Guest: One important part is interpersonal relationship with SmartView. When you think people care, then the chemistry works. Whatever we do, whatever we discuss, it is a solid partnership. One of my Company’s values is to enjoy making a difference. I do enjoy working with SmartView. It is so important. Especially in the Covid context. Whenever I need another improvement initiative, new functionality to analyze, , I do it with joy! And I know this feeling is shared with my business partner…

Olga: I really appreciate having one point of contact. You took all needs. Then all the relationships were added to this. We did things faster and better. We both know how we work. I really enjoy it.

Guest: Partnership and trust is continuous. There is no ON/OFF button

Olga: And you have fantastic interview skills too!

Guest: This is a question of context. You know I am really honest. I cannot lie. I don’t like to lie. Transparency is the main point.

Olga: How do you see the future?

Guest: I believe after one year of continuous development, I’d like to first drain the strategy and the meaning of the IT processes within the Company. I want to identify where both the Ticketing Tool and Consultancy Services may bring better value. We had a fireman’s approach, now we need to take a deep breath, build a federated Jira ITSM** approach with the right integration. At Headquarters, Jira is used but as well other subsidiaries worldwide own Jira or other ticketing tools. We need a federated platform, connected and shared but without ruining the current result achieved by each subsidiary. It means a long-term IT approach, worldwide, integrated.

Olga: Thank you for your precious time! 

Guest: (phone ringing) My next call is about the Service Catalog. It will become the backbone for the Company. I’m acting now with long-term in mind…

Olga Campeis

Olga is a Consultant at SmartView. She works mainly with Jira and Confluence to federate processes and produce continuous improvement.

*Jira Service Management : formerly known as Jira Service Desk

**ITSM : IT Service Management

Filtre Jira : Inclure un filtre dans un autre

Inclure un filtre Jira dans un autre-JQL

Dans cet article, je vais vous présenter pourquoi et comment inclure un filtre Jira dans un autre. 

Pour terminer cette série consacrée aux recherches dans Jira, je voudrais juste vous parler d’une fonctionnalité assez pratique et pas toujours très connue qui permet d’économiser du temps en simplifiant la maintenance des filtres. 

Imaginons que j’ai une équipe qui travaille sur 3 projets. Le projet « Teams in space », le projet « Team travel web » et le projet « Platform ». Je souhaite trouver l’ensemble des demandes ouvertes sur ces 3 projets. La première façon de faire est de créer une recherche :

Status = « To Do » and project in (« Teams in space », « Team travel web », « platform »)

Mais j’ai également besoin de trouver toutes les demandes non résolues qui concernent cette équipe.

À nouveau, je vais faire une recherche :

resolution is empty and project in (« Teams in space », « Team travel web », « platform »)

Cependant, on s’aperçoit que c’est assez fastidieux. À chaque fois que je dois faire une recherche qui concerne mon équipe, je suis obligé d’énumérer les projets. D’autre part, si l’équipe en question se voit affecter un 4ème projet, je devrais reprendre chacun des filtres pour les mettre à jour. Une première façon d’adresser le problème est d’utiliser la catégorie de projet. 

Utiliser les catégorie de projet dans une recherche Jira

Chaque projet peut être associé à une catégorie. Il s’avère que dans mon exemple, chaque projet appartient à la catégorie « Web Team ». Par conséquent, je vais pouvoir faire une recherche en m’appuyant sur le critère catégorie :

category = « web team » and status = « To Do »

Notez que le critère « category » est uniquement accessible en recherche avancée. Alors en utilisant cette fonctionnalité, si j’ajoute un nouveau projet à la catégorie « web team », la requête n’a pas besoin de maintenance particulière. 

Par exemple, si j’ajoute le projet « IOS » à la catégorie, mes requêtes continueront de fonctionner. Je retrouverais donc désormais les demandes de mes 4 projets.

Inclure un filtre Jira dans un autre : pourquoi ?

Cette méthode est pratique mais elle a deux limites. La première, c’est que le champ Catégorie ne s’applique qu’aux projets. Donc si je voulais regrouper mes demandes pour une équipe autrement qu’en me basant sur le critère du projet, ça ne fonctionnerait pas. Deuxième limite, un projet ne peut appartenir qu’à une seule catégorie. Donc imaginons maintenant qu’en plus du regroupement par équipe comme c’est le cas ici, j’ai besoin de consolider mes projets en les classant dans une catégorie de projet stratégique et non stratégique. Le tout, en faisant référence à cette liste de projet de la façon la plus simple possible. 

Ma suggestion est de créer une recherche « Demandes des projets stratégiques » avec comme critère la liste des projets concernés. Exemple : 

Project in (« IOS app », « Android app », « Web browser app »)

Je sauvegarde ce filtre Jira. Maintenant, si je veux obtenir la liste des demandes dans l’état « À faire » des projets stratégiques, je peux créer une recherche :

Recherche et filtre Jira - recherche avancée ou JQL

status = « To Do » and filter = « Demandes des projets stratégiques »

Je peux créer un filtre portant sur toutes les demande résolues des projets stratégiques de la même façon. Ainsi, si je dois modifier la liste de ces projets stratégiques, je n’aurais à le faire qu’une seule fois dans mon premier filtre. Attention, pour que les utilisateurs puissent utiliser ces différents filtres, ils doivent tous être partagés avec les personnes concernées, y compris le filtre inclus. 

J’espère que cet article vous aura été utile et que cela vous aidera à organiser correctement vos filtres Jira pour gagner du temps en maintenance. 

La recherche par dates dans Jira – recherche historique

Créer des rapports dans Jira avec les filtres et le JQL

Dans cet article, je vais vous présenter la recherche par dates ou historique dans Jira. Cela vous permettra de créer des rapports mensuel par exemple grâce aux tableaux de bord. Si vous avez lu tous les articles précédents, vous êtes maintenant un as de la recherche dans Jira.

Néanmoins, tout ce qu’on a vu ramène des données telles qu’elles sont à l’heure actuelle. On peut par exemple retrouver toutes les données qui sont dans état particulier, toutes celles qui sont assignées à un utilisateur ou toutes celles qui sont actuellement résolues.

Mais dans certains cas, on souhaite rechercher des demandes sur un critère historique, par rapport à une situation à un moment donné ou par rapport à un évènement qui a eu lieu pendant une période. 

Par exemple, on peut vouloir chercher toutes les demandes qui sont passées dans un statut particulier à une date précise.

On peut avoir besoin de trouver toutes les demandes qui étaient assignées à un utilisateur en particulier à une certaine date, par exemple, à la fin du mois précédent.

C’est particulièrement intéressant pour la production de rapport de début de mois où on analyse l’activité du mois précédent. 

Les opérateurs en JQL à utiliser dans une recherche historique Jira

Pour faire ces recherches, il existe des opérateurs spécifiques :

  • « was » : si je veux trouver les demandes pour lesquelles le champ avait une certaine valeur. 
  • « was in » : si je veux retrouver les demandes pour lesquelles le champ était dans une liste de valeur. 
  • « was not » et « was not in » qui sont les recherches associées. 
  • « changed » si je veux retrouver des demandes pour lesquelles la valeur d’un champ a changé.
Les opérateurs pour une recherche par dates dans Jira

Ces opérateurs ne sont cependant pas disponibles pour tous les champs. Par exemples, lorsque l’administrateur créé des champs personnalisés, il n’est pas possible de les utiliser avec ces opérateurs. Les champs qui les supportent sont : le responsable, la version de correction, la priorité, le demandeur, la résolution et l’état. 

Malgré tout, on peut déjà retrouver beaucoup d’informations. 

Recherche Jira selon des dates spécifiques

Recherchons par exemple la liste des demandes dont la responsable était Alana à la fin du mois précédent. La requête à utiliser est la suivante :

assignee was agrant on endOfMonth(-1)

De la même façon, on peut vouloir retrouver au début du mois la liste des demandes qui n’étaient pas résolues à la fin du mois précédent. Pour cela, on peut réaliser la requête suivante :

resolution was empty on endOfMonth(-1)

Maintenant, comment retrouver toutes les demandes qui ont changé d’état entre deux dates ?

Par exemple, je souhaite trouver des demandes qui ont changé d’état l’avant-dernière semaine. Le champ sur lequel faire porter la requête est « status »  et ce qu’on veut regarder ce sont les demandes qui ont changées. La requête est donc :

status changed during (startOfWeek(-2), startOfWeek(-1))

On aurait aussi pu mettre « endOfWeek(-2)« .

On cherche donc la liste des demandes dont l’état a changé sur une période. Je spécifie la valeur de la première date et la valeur de la deuxième date. Ce qui donne : début de la semaine N-2 et début de la semaine N-1.

Chercher des demandes qui étaient dans un état Jira en particulier et selon une date spécifique

On peut aller encore plus loin. Je peux par exemple rechercher la liste des demandes qui sont passées de l’état « Terminé » à l’état « À faire » dans l’avant-dernière semaine, donc les demandes qui ont été rouvertes. 

En reprenant la requête précédente je vais l’enrichir :

Chercher des demandes selon une date dans Jira

status changed from Done to « To Do » during (startOfWeek(-2), startOfWeek(-1))

Et on peut aller encore plus loin en recherchant par personne ayant fait l’action. Et dans ce cas, je peux ajouter :

status changed from Done to « To Do » by membersOf(« jira-administrators ») during (startOfWeek(-2), startOfWeek(-1))

Je vais donc retrouver toute la liste de mes demandes qui sont passées de l’état « Terminé » à l’état « À faire » dans l’avant-dernière semaine, lorsque cette action a été faite par un membre de l’équipe d’administration. 

La recherche par dates ou historique dans Jira ajoute beaucoup de puissance à la recherche. On peut l’utiliser pour effectuer une recherche ponctuelle pour identifier a posteriori une défaillance ou une erreur de process, ou pour réaliser des reporting fin de mois à transmettre au management en réutilisant toujours les mêmes filtres. À ce stade, vous avez toutes les clés pour devenir un maître de la recherche dans Jira. Je vous souhaite donc beaucoup d’amusement avec les requêtes JQL. 

Si vous trouvez des requêtes originales dont vous êtes particulièrement fier, n’hésitez pas à les partager en commentaire. Dans le prochain et dernier article de notre série sur la recherche Jira, nous verrons comment inclure un filtre dans un autre.

Exploration des fonctions de recherche de Jira (JQL)

Exploration des fonctions de recherche de Jira (JQL)

Dans cet article, nous irons plus loin dans les recherches en JQL en explorant les fonctions de recherche Jira qui permettent d’enrichir et de variabiliser vos requêtes. 

On peut déjà variabiliser les requêtes avec la recherche classique. Par exemple, « current user » ou en français, « utilisateur actuel », permet de faire référence à l’utilisateur connecté et donc avec une même requête, avoir des comportements différents en fonction de la personne qui l’exécute. De même, on peut faire des recherches glissantes. Par exemple, on peut chercher les demandes des 30 derniers jours. Mais on ne peut pas demander les demandes créées depuis le début de la semaine ou du mois. Alors, on pourrait chercher les demandes créées depuis le début du mois ou on pourrait mettre une date en dur, le 1er mai par exemple. Mais le mois suivant, cela ne fonctionnera plus et on récupérera toujours les demandes à partir du 1er mai. 

Les fonctions de recherche dans Jira

Jira propose donc un ensemble de fonctions qui permettent de répondre à ces besoins. Elles sont de plusieurs types. Certaines fonctions sont relatives à la date, comme le début de la semaine, le début de la journée, le début du mois, par rapport à l’heure courante, par rapport à ma dernière date de connexion.

D’autres fonctions font référence aux utilisateurs. On a déjà vu le currentUser() mais ça peut être également membersOf() pour les utilisateurs appartenant à un groupe. Cela peut-être également des fonctions qui sont relatives aux versions, donc les demandes qui sont demandées dans la prochaine version prévue. Cela peut encore être des fonctions associées aux liens entre les demandes. Par exemple, on peut chercher toutes les demandes liées à une autre demande en particulier. Il existe encore d’autres types de fonction, certaines étant spécifique à Jira Software ou Jira service desk.

Je ne vais pas toutes les parcourir ici car la documentation Atlassian est très complète et très exhaustive sur le sujet. Je vais plutôt prendre quelques exemples.

Premier exemple : comment retrouver toutes les demandes résolues le mois passé ? 

Pour cette recherche, nous allons nous baser sur le critère « date de création » et demander toutes les demandes créées dont la date de création est postérieure au début du mois précédent. 

Les fonctions de recherche de Jira : demandes résolues le mois passé

Le début du mois précédent s’écrit « StartOfMonth » avec entre parenthèse, moins 1 :

createdDate > = startOfMonth(-1)

Le début du mois courant serait startOfMonth() sans valeur entre les parenthèses, et le début du mois suivant, startOfMonth(1).

Si on veut faire la recherche deux mois en arrière, on mettra -2 entre les parenthèses : startOfMonth(-2).

Deuxième exemple : Comment retrouver toutes les demandes créées depuis ma dernière connexion ?

Si je veux trouver toutes les demandes créées depuis ma dernière connexion, la requête à saisir est la suivante :

createdDate > lastLogin()

Si je veux connaître les demandes créées depuis l’heure de ma connexion actuelle, je peux utiliser :

createdDate > currentLogin()

Troisième exemple : comment retrouver toute la liste des demandes affectées à des administrateurs de Jira ?

La requête appropriée sera :

assignee in membersOf(« jira-administrators »)

On pourrait également retrouver des demandes qui seraient assignées à des utilisateurs inactifs. Dans ce cas-là, la requête serait :

assignee in inactiveUsers()

Dans cet exemple, je n’en ai pas, ce qui est plutôt une bonne nouvelle.

Quatrième exemple : comment retrouver toute les demandes d’une prochaine version ?

Je pourrais également vouloir retrouver toutes les demandes dans la prochaine version à publier. Le critère que j’utiliserais pour faire porter la recherche est version corrigée ou fixVersion. Dans ce cas, la requête est :

fixVersion = earliestUnreleasedVersion()

Cinquième exemple : comment retrouver toute les demandes bloquées par une autre demande ?

Comment est-ce que je peux retrouver toutes les demandes qui sont bloquées par une autre ? Pour cela, il faut connaître la clé de la demande et utiliser la requête suivante :

Issue in linkedIssues, la référence de la demande et le lien sur lequel je veux faire porter le test.

Issue in linkedIssues(«PLAT-1», «Bloque»)

J’espère que maintenant, vous maîtrisez davantage l’utilisation des fonctions de recherche Jira en JQL. N’hésitez pas à tester, car une fois de plus, vous ne risquez pas de casser quoique ce soit. Dans le prochain article, nous verrons comment faire des recherches dans les historiques de Jira.

Premiers pas dans la recherche avancée de Jira (JQL)

Premiers pas dans la recherche avancée de Jira (JQL)

Dans cet article, je vous propose de commencer l’exploration des fonctions de recherche avancée offerte par Jira. La recherche avancée, ou JQL, signifie Jira Query Language. Cela ressemble un peu en termes de syntaxe au SQL.

Comment passer en recherche avancée dans Jira

Pour afficher la fenêtre de recherche avancée, cliquez sur le lien « Recherche avancée ». Il se trouve en haut à droite de la fenêtre de recherche si vous êtes en mode basique.

Lorsqu’on active ce mode, la recherche active est traduite en JQL. Bonne nouvelle, la recherche avancée bénéficie d’auto-complétion. Cela veut dire que lorsque vous êtes en train de rédiger, la recherche vous suggère les mots que vous pouvez utiliser. Chaque clause de la recherche se compose d’un critère qui est la plupart du temps un champ de Jira, d’un opérateur (=, >, !=, etc.) et d’une valeur de comparaison. 

Cependant, lorsque vous démarrez, la boîte de recherche est vide. Si cela vous intimide, je vous suggère de commencer la structure de votre recherche en mode basique.

Un exemple de recherche avancée dans Jira : rechercher des dates

Admettons que vous souhaitiez rechercher les demandes créées il y a plus de 30 jours. Ouvrez d’abord la recherche basique et choisissez le champ « Date de création ». Dans la boîte de sélection, cochez « Il y a plus de 30 jours ». Ensuite, passez en mode avancé pour voir l’écriture en JQL.

Recherche avancée Jira JQL

Vous voyez, la requête est :

created <= -30d

Ce qui signifie « toutes les demandes pour lesquelles la date de création est inférieure à l’instant T moins 30 jours ».

Si vous vouliez présenter la liste de toutes les demandes prévues dans les 7 prochains jours, la requête serait :

due < 7d

Ce qui signifie « toutes les demandes pour lesquelles la date d’échéance est inférieure à l’instant T plus 7 jours ».

Cette notation n’est pas très intuitive. Le fait de passer par la recherche basique pour créer l’ébauche de la requête simplifie l’opération. 

Maintenant que nous savons effectuer une recherche avancée, prenons les exemples de recherche qui ne peuvent pas être effectués en mode basique ou qui peuvent l’être difficilement. 

Comment exclure un projet dans une recherche ?

Pour ce premier exemple, je vais commencer par me mettre en recherche basique. Je fais d’abord une recherche sur le projet et je vais choisir celui que je veux exclure, par exemple, le projet IOS. Ensuite, je bascule dans la recherche avancée et je remplace mon opérateur « = »  par « != ». Ça, c’est le mode débutant. En mode avancé, on écrira directement la requête. Donc j’efface, je recommence, et vous allez voir directement l’autocomplétion.

La recherche avancée dans Jira : exploration du JQL

Project != IOS

Je sélectionne le critère « Project »,  l’opérateur « différent » dans la liste qui m’est proposée (« != » ) et la valeur attestée, « IOS ».

L’avantage d’utiliser différent (« != » ) plutôt qu’une énumération est double. D’abord, on évite une énumération fastidieuse des projets. Ensuite, si on ajoute de nouveaux projets, leurs demandes apparaîtront sans qu’on est besoin de maintenir le filtre. 

Chercher des demandes de type différent dans des projets différents

Je vais reprendre l’exemple qu’on avait dans l’article précédent (Pourquoi la recherche basique de Jira ne suffit pas). On voulait récupérer toutes les demandes de type « Récit » du projet Teams in space et toutes les épopées du projet Web Browser App. La difficulté qu’on peut avoir ici, c’est que « Récit » et « Épopée » sont des termes traduits. Or, dans la base, ils s’appellent en fait « Story » et « Epic » (en anglais) parce que j’ai installé mon instance en langue anglaise. 

Dans la recherche basique, on utilise les termes dans la langue traduite de l’utilisateur. Mais dans la recherche avancée, on utilise les noms de champs tels qu’ils sont traduits dans l’instance. Donc si vous avez du mal à trouver la bonne valeur, je vous conseille de passer d’abord par la recherche basique puis de traduire votre recherche en mode avancé. Pour réaliser ma recherche, je vais d’abord procéder à la sélection des récits du projet Teams in space :

project = « Teams in space » and issuetype = Story

Puis je vais adjoindre les épopées du projet Web Browser App. Je vais entourer chaque critère par des parenthèses et les associer par l’opérateur « Or » :

(Project = « Teams in Space » and issuetype = Story) OR (project = « Web Browser App » and issuetype = epic)

La recherche avancée dans Jira : savoir utiliser le JQL

Dès lors que j’ai saisi une requête avancée qui ne peut pas être créée en mode basique, le lien qui me permet de revenir dans ce dernier mode apparaît en gris. Dans les exemples que nous avons énuméré tout à l’heure, nous avons vu qu’il n’était pas non plus possible de faire des recherches sur des champs numérique autrement qu’en indiquant la valeur juste.

Chercher des demandes qui contiennent un champ numérique

En mode avancé, je peux demander à retrouver toutes les demandes pour la valeur métier supérieure à 40 en écrivant la requête :

« Business value » > 40 

Je peux également demander toutes les demandes comprises entre 40 et 80 :

« Business value » > 40 AND « Business value » < = 80 

Alors attention à une chose, si je recherche les demandes dont la business value est supérieure à 40, j’en trouve 65. 

« Business value » > 40 

Si je recherche les business value dont la valeur est supérieure ou égale à 40, j’en trouve 94.

« Business value » < =  40 

Si je cherche toutes les demandes, j’en trouve 741. Alors que je pourrais penser qu’il y en a 65 plus 94, donc 159.

C’est parce que les recherches ne ramènent que les demandes pour lesquelles la business value a une valeur. 

Si je veux toutes les demandes qui ont une business value inférieure à 40 ou qui n’ont pas de business value, je dois saisir « business value » inférieure ou égale à 40 OU business value est vide :

« Business value » < = 40 OR « Business value » is empty

Et là, on voit que cela fait bien 676 demandes. Ce qui permet également de confirmer à cette occasion qu’il n’est pas possible d’interroger Jira en mode basique pour retrouver des valeurs vides. 

J’insiste sur le fait que vous ne prenez aucun risque à tester différentes recherches. Intéressez-vous au mode avancé parce qu’au bout d’un moment, le mode basique ne vous permettra pas d’effectuer des recherches plus avancées. Donc maintenant vous savez aller au-delà de la recherche basique et utiliser la recherche avancée de Jira. Dans le prochain article, nous irons plus loin en explorant les fonctions de recherche avancée de Jira

Pourquoi la recherche basique de Jira ne suffit pas ?

Dans cet article, nous allons voir pourquoi nous avons souvent besoin d’aller au-delà de la recherche basique de Jira. Aujourd’hui vous savez utiliser la recherche simple. Elle permet de retrouver les demandes Jira de façon intuitive en utilisant une recherche multi-critères. 

Cependant, au bout d’un moment, vous allez vous apercevoir qu’il y a certaines choses que vous n’arriverez pas à faire. Et à ce stade, vous aurez deux options. La première, c’est d’abord de vous lamenter et de tout exporter dans Excel pour réaliser des recherches plus poussées, avec les limitations en termes de demandes exportées, etc. La seconde, c’est de mettre en pratique ce que vous allez lire dans cet article et dans quelques articles suivants. 

Vous allez voir que la recherche avancée, au début, peut effrayer. Mais ensuite, vous ne pourrez plus vous en passer. Voici un ensemble d’actions qui sont difficiles à réaliser ou carrément impossible à faire en utilisant la recherche basique de Jira. 

Rechercher toutes les demandes de tous les projets sauf un

Admettons que vous vouliez retrouver toutes les demandes qui concernent tous les projets sauf un. Dans ce cas, vous ouvrez la liste des projets puis cochez tous les projets sauf celui que vous ne voulez pas. Ça peut être assez vite fastidieux. 

L’autre souci, c’est que si vous rajouter un projet dans votre instance, il faudra très probablement revoir votre filtre. En effet, ce nouveau projet ne sera pas inclus dans les résultats de la recherche. 

Chercher des demandes de différents types dans différents projets

Un autre exemple est de chercher des demandes de différents types dans différents projets. Vous voulez les demandes de type « récit » du projet « Web Browser App » et les demandes de type « épopée » du projet Teams in Space. Vous pourriez être tenté de cocher les deux projets dans la liste des projets. Puis de cocher les deux types de demandes dans la liste « Type ». Le problème est que, dans ce cas, vous allez récupérer à la fois les récits et les épopées des deux projets. Et vous ne pourrez pas avoir les récits de l’un et les épopées de l’autre.

Chercher des champs avec une valeur numérique

Encore un exemple, si vous utilisez des champs numériques, vous allez rapidement tomber sur des grosses limitations. Ici, j’ai un champ numérique qui s’appelle « Valeur métier ».  Par convention, je lui donne une valeur de 0 à 100 pour indiquer l’importance relative des demandes du point de vue des métiers. Je peux avoir besoin de récupérer toutes les demandes dont la valeur métier est supérieure à 50. Et bien en mode basique, ce n’est pas possible comme vous pouvez le constater. 

Limitation de la recherche basique de Jira

Évidemment, énumérer la liste des valeurs possibles n’est pas une option. D’ailleurs, ce n’est même pas possible.

Chercher une valeur métier

Enfin, un dernier exemple, il n’est pas possible de retrouver les demandes dont la valeur métier n’est pas renseignée. Vous pouvez chercher celles pour lesquelles la valeur métier est à zéro, en l’occurence ici, il n’y en a pas. Mais vous ne pouvez pas chercher celles pour lesquelles la valeur n’est pas indiquée. 

Pour toutes ces raisons et pour beaucoup d’autres, je suis sûr que vous en avez déjà en tête, vous devrez passer un jour ou l’autre à la recherche avancée.

Vous savez désormais pourquoi la recherche basique de Jira ne vous suffira pas. Je vous propose d’explorer ensemble la recherche avancée dans nos prochains articles : Premier pas dans la recherche avancée de Jira – Introduction au JQL.

Changement en lot dans Jira : modifier un ensemble de demandes en une seule fois

Changement en lot dans Jira - modifier un ensemble de demandes en une seule fois

Dans cet article, je vais vous montrer comment exécuter une même action sur l’ensemble des demandes rapportées par un filtre en une seule fois. C’est ce qu’on appelle le changement en lot dans Jira.

Pourquoi effectuer un changement en lot dans Jira ?

Alors, pourquoi rechercher des demandes ? La question peut sembler un peu simpliste et les réponses très évidentes. Je vais quand même prendre quelques exemples. 

Mitch, qui est mon lead dev, vient de m’apprendre qu’il est en arrêt maladie pendant 3 semaines. J’ai besoin de trouver toutes les demandes sur lesquelles ils travaillent pour pouvoir les réaffecter à Emma. 

Autre cas : j’ai trop de demandes en attente. Je veux retrouver toutes celles qui ont été ouvertes il y a plus de 6 mois et qui ont une priorité mineure dans le but de les abandonner. 

Autre possibilité : j’ai réalisé l’importation d’un fichier CSV et je me suis trompé. Je veux reprendre toutes les demandes importées et les supprimer. 

Un dernier exemple : je veux fusionner 2 projets, récupérer les demandes du premier projet, les déplacer vers un autre, avant de supprimer le premier projet.

Dans tous ces exemples, la recherche est juste une étape préalable avant la réalisation d’une action globale sur toutes les demandes concernées. 

Alors on va voir justement comment réaliser cette action en masse sur le résultat de la recherche. 

Étape préalable : la recherche de mes demandes dans Jira

Tout d’abord, on recherche les demandes concernées. Dans mon premier exemple, je vais rechercher toutes les demandes qui sont affectées à Mitch. Je cherche toutes les demandes dans lequel le responsable est Mitch Davis et qui ont une priorité bloquante ou critique parce que je ne vais pas tout réaffecter à Emma. 

Rechercher des demandes dans Jira

Dans la fenêtre qui apparaît, je clique sur « Outils », puis « Tous les 16 tickets ». Ici, je peux venir préciser la liste des demandes concernées. Si je clique sur la première case, je sélectionne toutes les demandes résultants du filtre. Je peux également limiter la recherche en sélectionnant ou désélectionnant de façon unitaire certaines demandes. Après avoir réalisé cette sélection, je clique sur « Suivant » pour choisir l’opération à effectuer. Si certains choix sont grisés, cela signifie que je n’ai pas le droit d’effectuer l’opération sur tout ou partie des demandes. Par exemple, je n’ai pas la permission de supprimer ou de modifier tous les tickets de la sélections certains appartiennent à des projets sur lesquels je suis simple utilisateur. 

Effectuer un changement en lot sur plusieurs demandes en même temps

Dans ce cas, il va falloir que je change mon filtre ou que je limite la liste des demandes concernées par l’action que je vais effectuer. 

Modifier plusieurs tickets Jira en même temps

La première possibilité offerte est la modification des tickets. Si je choisis cette option et que je clique sur « Suivant », je peux maintenant choisir les champs à modifier.

Les différentes options du changement en lot

Dans mon exemple, je veux changer le responsable et affecter toutes les demandes à Emma. J’en profite pour ajouter un commentaire sur toutes les demandes en même temps. Je peux décider si je veux envoyer une notification pour chaque demande en fonction des règles de notification en place. Je ne suis pas un grand fan des mails donc je décoche. Puis je clique sur « Suivant ». 

Opération en lot dans Jira : mettre à jour un champ

Une page récapitulative de l’action à réaliser et des demandes concernées s’affiche. Je n’ai plus qu’à confirmer. Voilà donc comment réaliser une action sur un ensemble de demandes en une seule fois. 

Rapidement, regardons quelles sont les autres possibilités offertes. 

Les différentes options de changement en lot des tickets Jira

Les différentes options d'un changement en lot dans Jira

« Déplacer les tickets » me permet de déplacer des tickets d’un projet à un autre ou de changer leur type. 

« Tickets de transition » est une mauvaise traduction, cela devrait être « transitionner les tickets ». Cela permet donc de changer en une seule fois l’état de tous les tickets concernés. 

Par exemple, abandonner les tickets qui sont ouverts depuis plus de 6 mois qui sont toujours dans l’état ouvert. 

« Supprimer les tickets » permet donc de supprimer les tickets, par exemple, suite à une importation infructueuse. 

« Observer les tickets » et « Arrêter la surveillance des tickets » permet de vous rajouter en tant qu’observateur à l’ensemble de tous ces tickets ou à vous retirer de la liste des observateurs. 

Les autres choix ici sont liés à la présence d’un plugin et ne sont donc pas couverts dans cet article.

Attention, comme pour les exports de demandes, les actions en lot (ou en masse) ne sont possibles que par groupes de 1000. Il va falloir trouver des astuces si votre sélection dépasse 1000 demandes. La plupart du temps, c’est assez simple. Si je fais une recherche sur les demandes attribuées à Mitch pour les réattribuer à Emma, après l’exécution de la modification sur les 1000 premières demandes, les demandes réattribuées ne répondront plus au filtre. Donc on pourra continuer de réaliser la mer recherche et la même action jusqu’à avoir traité toutes les demandes. 

C’est la même chose quand on déplace des projets d’un projet à l’autre ou quand on les change d’état. 

Vous savez maintenant effectuer en une seule fois une même action sur un ensemble de demandes ramenées par un filtre. À ce stade, nous pouvons considérer que nous sommes capable de rechercher des demandes, manipuler les résultats de recherche, partager les filtres, etc. Mais ce n’est pas terminé. Dans le prochain article, nous verrons pourquoi la recherche basique ne va pas vous suffire et comment aller plus loin grâce à la recherche avancée. 

Recherche Jira : recevoir par mail les résultats d’un filtre

Recherche Jira - recevoir par mail les résultats d’un filtre

Dans cet article, je vais vous montrer comment recevoir périodiquement par mail les résultats d’une recherche Jira.  

Exporter une recherche Jira : l’abonnement au filtre

Il existe dans Jira un mode d’exportation original très utile : l’abonnement au filtre. Celui-ci permet de recevoir périodiquement la liste des demandes qui répondent à un filtre sous forme de mail récapitulatif. On peut l’envoyer à soi-même ou à un ensemble d’utilisateurs. 

Recherche dans Jira : Abonnement à un filtre

Pour y accéder, lorsque mon filtre est affiché,  je clique sur le bouton « Informations » puis « Nouvel abonnement ». Je vais d’abord choisir les destinataires du mail récapitulatif. Je peux choisir l’abonnement personnel, et dans ce cas, le mail ne sera reçu que par moi-même. Ou je peux choisir de l’adresser à un groupe d’utilisateurs. Attention, je ne vois ici que la liste des groupes auxquels j’appartiens. Ensuite, je vais choisir à quelle fréquence je vais envoyer le mail. Cela peut-être tous les jours, certains jours de la semaine ou du mois. Je peux également spécifier le format d’émission dans un mode avancé que je ne couvrirais pas ici. 

Comment s'abonner aux résultats d'une recherche ?

Enfin, la dernière case me permet de recevoir un mail même s’il n’y a pas de demandes qui répondent au filtre. Cela permet de me rassurer en me disant que la souscription au filtre fonctionne correctement. Cela veut juste dire qu’il n’y a pas de demandes concernées. 

Notifier les utilisateurs Jira de leurs demandes

Vous pouvez notifier par exemple chaque utilisateur de leurs demandes :

  • Si vous souhaitez envoyer tous les matins la liste des demandes qui leurs sont attribuées et qui ne sont pas résolues
  • Si vous souhaitez prévenir des utilisateurs qu’ils ont des demandes à valider

vous pouvez créer un filtre dans lequel vous mettez comme critère :

Reporter = currentuser() AND status = « A tester »

Normalement, vous deviez pouvoir créer ce filtre (Vous ne savez pas comment faire ? Voici le lien vers l’article qui en parle). Ensuite vous faites en sorte que tous les matins à 8h, tous les utilisateurs de Jira reçoivent le mail. Ne recevrons le mail que ceux qui ont des demandes à traiter. Essayez de programmer cela à une heure durant laquelle Jira n’est pas trop sollicité (par exemple à 8h du matin). De cette manière, quand les gens arriveront au travail, ils verront ce mail en tête des mails qu’ils auront à lire. 

Donc dans cet exemple, le fait d’utiliser currentuser() fait que, même si c’est un filtre unique pour tous le monde, les gens ne verront que les demandes qu’ils ont eux-mêmes rapportées. Cette fonctionnalité est très intéressante car elle permet de réduire le flux de mails.

Gérer les notifications avec les abonnements

Il est très fréquent de constater que beaucoup d’utilisateurs de Jira demandent au départ de recevoir des notifications. Mais comme c’est difficile de bien calibrer ces notifications, les mails sont souvent trop nombreux. Finalement, au bout d’un moment, ils arrêtent de les regarder ou ils créent une règle dans leurs messageries pour les mettre directement à la corbeille. Ce que je conseille à mes clients, c’est de limiter les envois de mails immédiats et de les réserver aux notifications vraiment urgentes.

Enfin, pour toutes les notifications qui ne sont pas urgentes, il vaut mieux travailler avec les abonnements aux filtres. De cette façon, les utilisateurs reçoivent régulièrement un récapitulatif des actions à faire. 

Vous savez maintenant comment recevoir périodiquement les résultats d’une recherche grâce à l’abonnement à un filtre dans Jira. Dans le prochain article, nous verrons comment réaliser une même action sur toutes les demandes d’un filtre en même temps

Exporter les résultats de recherche de Jira

jira-jql-exporter les résultats de recherche-smartview

Dans cette article, nous allons voir comment exporter les résultats obtenus lors d’une recherche dans Jira. Si vous préférez, vous pouvez voir notre vidéo sur ce sujet et vous abonner à notre chaîne Youtube pour recevoir nos astuces sur l’outil Jira.

Exporter les résultats de la recherche par mail

Pour exporter les résultats d’une recherche, la première option dont nous disposons est d’envoyer par mail un lien sur la recherche pour permettre à d’autres utilisateurs d’exécuter le filtre actif. 

Exporter sa recherche Jira : envoyer les résultats de la recherche par mail

Le bouton « Partage » ouvre une boîte dans la quelle on peut spécifier une liste d’utilisateurs ainsi qu’une petite note pour personnaliser le message. Les destinataires du mail pourront cliquer simplement sur le lien et accèderont aux résultats du  filtre.

Exporter les résultats dans différents formats

 Le bouton « Exporter », comme son nom l’indique, permet d’exporter les résultats de la recherche dans différents formats. Je ne vais pas détailler la liste des possibilités mais me concentrer sur l’export csv qui est le plus utilisé.

Exporter sa recherche Jira en CSV

C’est en tout cas l’exportation que je vois la plus souvent réalisée. Vous pouvez choisir d’exporter toutes les colonnes ou uniquement les colonnes présentes à l’écran. En général, c’est cette option qui est utilisée. Je lance l’exportation et le fichier est récupéré. Vous pouvez ensuite l’ouvrir avec Excel ou un autre outil comme Numbers si vous êtes sur Mac. 

Comment exporter plus de 1000 demandes Jira ?

Alors attention, on ne peut pas exporter plus de 1000 demandes Jira à la fois dans la configuration standard. Si vous avez besoin d’exporter plus de 1000 demandes, il faudra le faire en plusieurs fois. Il n’y a pas vraiment de façon simple de le faire.  Ce que je suggère, c’est d’ajouter un critère supplémentaire. Par exemple, si la recherche sur le projet comporte 1200 demandes et que je veux les exporter. Je peux essayer de faire une première recherche en ajoutant un critère sur les priorités (ex : critique, bloquante et majeure) et réaliser mon exportation. Puis, je fais une nouvelle recherche en changeant les priorités  (ex: mineure et triviale) que j’exporte. L’astuce consiste ensuite à fusionner les 2 fichiers produits.

Je vous l’accorde, ce n’est pas très pratique. Si vous avez des besoins récurrents d’exportation de beaucoup de données Jira, ce n’est peut-être pas la meilleure façon de faire. Dans ce cas, il faudra peut-être envisager d’accéder aux demandes via l’API.

Exporter les résultats d’une recherche au format Excel ?

Dans les anciennes versions de Jira, vous disposez d’une option d’exportation au format Excel. Sachez que cette fonctionnalité existe toujours mais qu’elle est désactivée par défaut. Si vous souhaitez l’utiliser, tournez-vous vers votre administrateur. Cependant, attention, Atlassian l’a supprimée pour deux bonnes raisons. Tout d’abord, le format du fichier Excel généré n’était pas dans un format optimal. Ce n’est pas grave en soi mais cela peut générer des remarques de la part des utilisateurs. D’autre part, l’opération d’export Excel est très consommatrice en ressources. Par conséquent, je vous conseille de vous contenter de l’export CSV qui permet tout aussi bien de réutiliser les résultats de la recherche pour les retravailler ensuite dans Excel. 

Autres types d’export Jira

 Il y a d’autres types d’export qui sont moins utilisés. Par exemple le bouton « Imprimable » permet de mettre en forme la liste de manière à pouvoir l’imprimer directement à partir de votre navigateur. Le bouton graphique de tableau de demandes permet de créer directement un gadget de type « Résultat de la recherche » qui va s’insérer dans un tableau de bord existant. Le format Word ressemble au format imprimable et permet d’avoir une liste de toutes les demandes les unes à la suite des autres dans un document au format Microsoft Word. 

Je vous recommande de ne pas trop abuser de cette fonctionnalité. Dès lors que des demandes ont été exportées dans un fichier Excel en particulier, la tentation est grande pour les utilisateurs de modifier directement ce fichier. Donc restez au maximum dans Jira et chercher des alternatives à l’exportation dans des fichiers externes. 

Vous savez maintenant comment exporter les résultats de votre recherche Jira. Dans le prochain article, nous verrons comment recevoir périodiquement les résultats d’une recherche Jira.