Dans ce qui suit, sont détaillés un ensemble de rapports Agile permettant de :

• comprendre la vélocité de l’équipe,
• identifier les goulots d’étranglement
• prédire les performances futures

Burdown Chart

Le Burndown Chart montre la quantité réelle et estimée de travail à effectuer dans un sprint. L’axe X horizontal dans un graphique Burndown indique le temps et l’axe Y vertical indique les tickets.

Le Burndown Chart permet de suivre le travail total restant et d’estimer les chances d’atteindre l’objectif du sprint. En suivant le travail restant tout au long de l’itération, une équipe peut gérer sa progression et réagir aux tendances en conséquence. Dans le cas où le graphique de progression indique que l’équipe pourrait ne pas atteindre l’objectif du sprint, l’équipe peut mettre en place les actions requises pour maintenir le cap.

Le Burndown Chart s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Burndown Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

• Statistique d’estimation : l’axe vertical représente la statistique d’estimation sélectionnée.
• Valeurs restantes : la ligne rouge représente la quantité totale de travail restant dans le sprint, selon les estimations de votre équipe. Quand la quantité de travail augmente lors d’un sprint suite à l’ajout de nouvelles user stories ou la revue à la hausse de l’estimation de user stories, la ligne rouge évolue vers le haut.
• Guide : la ligne grise montre approximativement où votre équipe devrait se trouver (avec un avancement linéaire). Si la ligne rouge est en dessous de cette ligne, votre équipe est sur la bonne voie pour terminer tout son travail à la fin du sprint. Cette information n’est toutefois pas infaillible ; il s’agit simplement d’une information à utiliser tout en surveillant l’avancement de l’équipe.
• Les zones grisées représentent les jours non travaillés

Burnup Chart

Le burnup chart fournit une représentation visuelle du travail accompli lors d’un sprint par rapport à son périmètre. Il offre des informations sur la progression de votre projet, ainsi que des avertissements pour vous aider à maintenir la santé de votre projet ; vous pouvez instantanément repérer des problèmes tels que le dépassement du périmètre initialement prévue ou une déviation par rapport au chemin de projet planifié.

Alors que le Burndown Chart indique le reste de travail à accomplir dans le sprint, le Burnup chart montre le travail réalisé et le total du travail à faire.

Le Burnup Chart s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Burnup Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

• L’axe vertical représente la quantité de travail et peut être mesuré de différentes façons telles que les story points, le nombre de tâches ou les estimations. L’axe horizontal représente le temps en jours.
• Le périmètre du travail (la ligne rouge) montre le travail qui était prévu pour le sprint. Si cette ligne augmente au cours du sprint, c’est un signe de débordement du périmètre initial.
• Le travail achevé (la ligne verte) montre le travail qui a été réalisé.
• La ligne directrice (la ligne grise) est une ligne théorique montrant l’achèvement quotidien nécessaire pour respecter la date limite.
• La distance entre le périmètre du travail (la ligne rouge) et le travail achevé (la ligne verte) sur le graphique représente la quantité de travail restante. Lorsque tout le travail du sprint est achevé, les lignes se rejoignent.
• Les pics dans le périmètre du travail signifient qu’un élément a été ajouté à la tâche, tandis que les pics dans le travail achevé signifient qu’une story a été réalisée. Ces informations peuvent être cruciales lors de la rétrospective pour comprendre si, par exemple, trop de travail a été ajouté ou si le travail a été plus complexe que prévu.
• Examinez la ligne ‘Périmètre du travail’ pour identifier tout débordement du périmètre initial.
• Si l’estimation n’a pas été activée, votre rapport s’affichera en utilisant le nombre de tâches, ce qui signifie qu’elles seront traitées comme ayant le même poids.

Sprint Report

Le Sprint report affiche la liste des tâches pour chaque sprint. Il est utile pour les réunions de Rétrospective de Sprint, ainsi que pour lors des points relatifs à l’état d’avancements du sprint.

Si votre instance Jira Software est connectée à Confluence, il est possible de créer les pages de rétrospective confluence à l’aide du bouton “Associer une page Confluence”

Le Sprint report s’applique uniquement aux tableaux Scrum.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Sprint report Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

• Le Sprint Report est spécifique au tableau – il ne comprendra que les tâches correspondant au filtre enregistré de votre tableau.
• Sous le rapport, les tâches du sprint sont répertoriées en fonction de leurs états d’avancement. Sous « Tâches Terminées », la colonne « Story Points » indique combien de Story Points votre équipe a réalisé pendant le sprint. Si elle est affichée avec deux valeurs et une flèche entre elles (par exemple 3 → 3.5), cela indique qu’une estimation de Story Points a été revue pendant le sprint.
• Les tâches ajoutées après le début du sprint sont indiquées par un astérisque.
• Une tâche est considérée comme « À Faire » lorsqu’elle est dans un statut qui est associé à la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminée » lorsqu’elle se trouve dans un statut qui est associé à la colonne la plus à droite de votre tableau. Voir la configuration des colonnes pour plus d’informations.
• La ligne grise représente une ligne directrice qui va du total estimé des tâches au début du sprint à 0 à la fin du sprint. La ligne grise reste horizontale pendant les jours non travaillés.
• La ligne rouge représente le travail réel effectué pendant le sprint – elle est tracée à partir de l’estimation totale des tâches au début du sprint, et elle monte ou descend à mesure que votre équipe travaille sur les tâches du sprint. Notez que la ligne rouge montre l’estimation totale actuelle pour les tâches non résolues à n’importe quel moment du sprint. Elle reflète également les tâches qui sont ajoutées ou retirées du sprint.
• Si votre tableau est configuré pour suivre les estimations restantes et le temps passé, une ligne verte s’affichera dans le Rapport de Sprint, indiquant le travail enregistré sur les tâches.

Velocity Chart

Le Velocity Chart est la quantité moyenne de travail qu’une équipe Scrum effectue au cours d’un sprint, mesurée en Story Points ou en heures, et est très utile pour les prévisions. Le product owner peut utiliser la vélocité pour prédire la rapidité avec laquelle une équipe peut traiter la backlog, car le rapport suit le travail prévu et terminé sur plusieurs itérations : plus il y a d’itérations, plus la prévision est précise.

Le Volocity Chart n’est applicable que dans le cadre d’un modèle projet Scrum.

• Statistique d’estimation : l’axe des Y affiche la statistique utilisée pour estimer les storys. En savoir plus sur la configuration de l’estimation et du suivi. Les estimations peuvent être basées sur :
  • Story points, comme le montre l’exemple ci-dessus
  • Temps estimé (minutes, heures, jours ou semaines)
  • le nombre de tâches
  • Tout champ numérique personnalisé dans Jira.
• Engagement : la barre grise de chaque sprint affiche l’estimation totale de toutes les tâches au début du sprint. Une fois le sprint lancé, les story ajoutées au sprint ou les modifications apportées aux estimations ne seront pas incluses dans ce total.
• Terminé : la barre verte de chaque sprint affiche le total des estimations terminées à la fin du sprint. Toutes les modifications du périmètre apportées après le démarrage du sprint sont incluses dans ce total.
• Sprints : L’axe des X affiche les 7 derniers sprints réalisés par l’équipe. Ces données sont utilisées pour calculer la vitesse.

Autres points à noter concernant le Velocity Chart :

• Il est spécifique au bord, ce qui signifie qu’il n’inclura que les tâches du filtre associé au bord.
• Il est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.

Calcul de la vélocité
La vélocité récente d’une équipe peut être utile pour aider à prédire la quantité de travail qui peut être accomplie par l’équipe lors d’un prochain sprint. La vélocité est calculée en prenant la moyenne des estimations totales réalisées au cours des derniers sprints.

Cette valeur devrait devenir plus précise et fiable au fil du temps, à mesure que davantage de données deviennent disponibles et que l’équipe s’améliore dans l’estimation des tâches.

Les Story Points sur les sous-tâches ne sont pas inclus dans le Velocity Chart. Le rapport n’utilisera que les données des types de tâches de niveau standard.

Cumulative Flow Diagram

Un Cumulative Flow Diagram (CFD) est un graphique en aires qui montre les différents statuts des éléments de travail pour une application, une version ou un sprint. L’axe horizontal des X dans un CFD indique le temps et l’axe vertical des Y indique les tâches. Chaque zone colorée du graphique équivaut à un statut de flux de travail (c’est-à-dire une colonne sur votre tableau).

Le CFD peut être utile pour identifier les goulots d’étranglement. Si votre graphique contient une zone qui s’élargit verticalement au fil du temps, la colonne qui équivaut à la zone qui s’élargit constituera généralement un goulot d’étranglement.

Le CFD est spécifique au bord, c’est-à-dire qu’il inclura uniquement les tâches qui correspondent au filtre enregistré de votre bord.

Il est basé sur le mapping des colonnes de votre bord. Une tâche est considérée comme « À faire » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’elle se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.

Il garde une trace du nombre de tâches qui transitent par chaque colonne de votre bord, vous aidant ainsi à voir quelles colonnes accumulent plus de problèmes que d’autres.

Par exemple:

Si vous démarrez un sprint avec 5 tickets, tous les tickets commenceront dans la colonne To Do. Si vous consultez le CFD, il affichera 5 tâches à faire, 0 tâche en cours et 0 tâche terminé.

Si vous déplacez ensuite 2 tâches vers En cours, le CFD affichera 5 tâches À faire (car 5 sont passés par cette colonne), 2 tâches En cours et 0 tâcheTerminé.

Si vous déplacez ensuite 1 tâche de En cours à Terminé, le CFD affichera À faire = 5, En cours = 2 et Terminé = 1.

Si vous retirez ensuite cette tâche de Terminé et la remettez dans À faire, le CFD supprimera le 1 de Terminé et supprimera 1 de En cours, mais les chiffres dans À faire resteront les mêmes, car aucune nouvelle tâche n’est arrivée. . Par conséquent, le CFD affichera À faire = 5, En cours = 1, Terminé = 0.

Version Report

Le Version Report montre la progression de votre équipe vers l’achèvement d’une version. Le Version Report vous indique également la date de release prévue, en fonction du taux de progression (vélocité) moyen de votre équipe depuis le début de la version, et de la quantité estimée de travail restant.

• Le Version Report est spécifique au bord – c’est-à-dire qu’il inclura uniquement les tâches qui correspondent au filtre enregistré de votre bord.
• Le Version Report exclura les tâches d’un « type de sous-tâche ».
• Le Version Report affiche les versions « Released» mais pas les versions « Archivées ».
• Le Version Report est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.
• L’axe horizontal commence à la date de début de la version ; ou si aucune date de début n’est spécifiée, la date à laquelle une tâche a été ajoutée pour la première fois à la version. Le graphique montre l’état dans lequel se trouvait votre version à un moment donné, en termes de vos Story Points totaux et complétés (ou d’autres statistiques d’estimation de votre choix), afin que vous puissiez voir comment le périmètre a pu changer et comment vous progressez vers l’achèvement des travaux estimés.
• la ligne rouge représente le pourcentage des tâches non encore estimées
• Le graphique vous montre les prédictions suivantes :
  • la date de sortie prévue (ligne bleue) – c’est-à-dire la date à laquelle vous pouvez vous attendre à ce que toutes les tâches de votre version soient terminées, en fonction de votre vélocité quotidienne moyenne et de la quantité de travail restante estimée.
  • la date de sortie prévue (optimiste) (zone ombrée à gauche de la ligne bleue) – c’est-à-dire la date la plus proche à laquelle vous pouvez vous attendre à ce que la version soit complète. (La date « optimiste » est calculée en ajoutant 10 % à la vélocité quotidienne moyenne.)
  • la date de sortie prévue (pessimiste) (zone ombrée à droite de la ligne bleue) – c’est-à-dire la dernière date à laquelle vous pouvez vous attendre à ce que la version soit complète. (La date « pessimiste » est calculée en soustrayant 10 % de la vélocité quotidienne moyenne.)
• 10 % du travail estimé pour la version devra être terminé avant que les prédictions puissent être calculées.

Epic Report

Le Epic Report affiche une liste des tâches complètes, incomplètes et non estimées dans une Epic. Il est particulièrement utile pour planifier le travail d’une Epic pouvant s’étendre sur plusieurs sprints.

Utilisez le Epic report pour comprendre la progression vers la réalisation d’une Epic au fil du temps et pour suivre la quantité de travail restant incomplet ou non estimé.

• Le Epic Report est basé sur le mapping des colonnes de votre tableau. Une tâche est considérée comme « À faire » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à gauche de votre tableau. De même, une tâche est considérée comme « Terminé » lorsqu’il se trouve dans un statut qui a été mappé dans la colonne la plus à droite de votre tableau.
• Le graphique sera différent si vous utilisez le nombre de tâches comme statistique d’estimation (plutôt que les Story Points, comme indiqué dans la capture d’écran ci-dessus).
• Le graphique indique :
  • le nombre total de story points
  • le nombre total de story points « Terminé »
  • le nombre total de tâches
  • le nombre total de tâches non estimées

Control Chart

Le Control Chart affiche le temps de cycle (ou délai de livraison) de votre produit, version ou sprint. Il prend le temps passé par chaque tâche dans un ou plusieurs statuts particuliers et le mappe sur une période de temps spécifiée. La moyenne, la moyenne mobile et l’écart type de ces données sont affichés.

Le Control Chart vous aide à identifier si les données du sprint en cours peuvent être utilisées pour déterminer les performances futures. Moins la durée de cycle d’une tâche varie, plus la confiance dans l’utilisation de la moyenne comme indication des performances futures est élevée.

Quel est le temps de cycle et le délai de livraison ?

Le temps de cycle est le temps passé à travailler sur une tâche – généralement le temps écoulé entre le début du travail sur une tâche et le moment où le travail est terminé, mais il inclut également tout autre temps passé à travailler sur la tâche. Par exemple, si une tâche est rouverte, traitée et terminée à nouveau, le temps nécessaire à ce travail supplémentaire est ajouté au temps de cycle.

Le délai de livraison est similaire au temps de cycle, mais il s’agit du temps écoulé entre le moment où une tâche est créée (et non le moment où le travail commence) jusqu’à ce que le travail soit terminé sur cette tâche.

Comment est déterminé le temps de cycle ?

Les statuts utilisés pour calculer le temps de cycle dépendent du workflow que vous utilisez pour votre projet. Vous devez configurer le Control Chart pour inclure les statuts qui représentent le temps passé à travailler sur une tâche. Notez que le Control Chart tentera de sélectionner ces statuts automatiquement.

Par exemple, si vous utilisez le workflow « Jira Software Development », vous pouvez considérer que le travail a commencé sur une tâche lorsqu’elle passe à « En cours », et que le travail est terminé lorsqu’elle passe de « En révision » à « Terminé ». ‘. Vous l’afficherez sur le Control Chart en sélectionnant « En cours » et « En révision » comme colonnes, car cela afficherait le temps passé par les tâches dans ces deux statuts.

Comment est calculée la moyenne mobile ?

La moyenne mobile (ligne bleue sur le graphique) est basée sur la tâche et non sur le temps. Pour chaque tâche affichée sur le graphique, la moyenne mobile (à ce moment-là) est calculée en prenant la tâche elle-même, X tâches avant la tâche et X tâches après la tâche, puis en faisant la moyenne de leurs temps de cycle. 20 % du total des tâches affichées (toujours un nombre impair et un minimum de 5 tâches) est utilisé dans le calcul.

Que représente la zone ombrée en bleu ?

La zone ombrée en bleu du Control Chart représente l’écart type, c’est-à-dire l’ampleur de la variation des données réelles par rapport à la moyenne mobile.

L’écart type vous donne une indication du niveau de confiance que vous pouvez avoir dans les données. Par exemple, s’il existe une bande bleue étroite (faible écart type), vous pouvez être sûr que le temps de cycle des émissions futures sera proche de la moyenne mobile.

Que représentent les points sur le graphique ?

Chaque point vert représente une tâche ou un groupe de tâches :

L’emplacement vertical du point représente le temps de cycle de la tâche, c’est-à-dire le « Temps écoulé ». Pour un groupe de tâches, le point est placé au niveau du temps de cycle moyen des tâches.

Le placement horizontal indique le moment où le ou les tâches sont sorties du dernier statut sélectionné sur le graphique (en colonnes).

Exemples de control chart :

Sur ce premier exemple :

• La productivité de l’équipe augmente : comme l’indique la tendance à la baisse de la moyenne mobile.
• La durée de cycle des tâches futures sera probablement proche de la moyenne mobile (2 jours ou moins) : indiquée par le faible écart type (zone étroite ombrée en bleu).

Sur ce deuxième exemple :

• La productivité de l’équipe est assez constante : indiquée par une moyenne mobile proche de la moyenne.
• Il existe des valeurs aberrantes évidentes les mardi 14 et mercredi 15 (respectivement 7 jours et 10 jours de temps écoulé, contre 2 jours en moyenne) qui devraient faire l’objet d’une analyse.
• Les données deviennent de plus en plus prévisibles au fil du temps.

Epic Burndown

Le rapport Epic Burndown vous montre comment votre équipe progresse par rapport au travail d’une Epic. Une Epic est un chantier regroupant plusieurs User story. Le rapport affichera des données basées sur la statistique d’estimation utilisée au niveau du bord.

L’Epic Burndown permet de :

• Voir à quelle vélocité votre équipe travaille sur l’Epic,
• Découvrir comment le travail ajouté et supprimé pendant le sprint a affecté la progression globale de l’équipe
• Prévoir le nombre de sprints nécessaires pour terminer le travail d’une Epic, en vous basant sur les sprints passés et les changements au cours des sprints.

Le graphique affiche les informations suivantes :

• Section vert clair = travail réalisé pendant le sprint. Si une barre est entièrement vert clair, vous ne pourrez pas dire quelle part du travail effectué était initialement estimée ou non. Pour connaître ces informations, cliquez sur la barre pour afficher les détails.
• Section bleu clair = travail restant dans l’Epic par rapport à l’ensemble du travail estimé pour l’Epic au début du sprint.
• Section bleu foncé = travail ajouté pendant le sprint, mais non inclus à l’origine (c’est-à-dire changement de périmètre).
• Section vert clair + section bleu clair = travail total dans l’Epic initialement estimé au début du sprint.
• Section bleu clair + section bleu foncé = travail total dans l’Epic restant à la fin du sprint.
• Barres avec sections grises = sprints prévus. Les sprints prédits sont calculés en fonction de la vélocité de votre équipe (quantité de travail effectué au cours des trois derniers sprints) et du travail total restant pour l’Epic. Le changement de périmètre n’est pas pris en compte lors du calcul de la vélocité, mais est inclus dans le travail total restant.

Release Burndown

Le Release Burndown report vous montre comment votre équipe progresse dans le travail d’une Release. Dans Jira Software, il n’y a pas d’élément appelé « Release » : une version équivaut à une release (par conséquent, le terme « version » sera utilisé à la place de « release»). Le rapport affichera des données basées sur la statistique d’estimation utilisée par votre bord.

A l’instar de l’Epic Burndown, le Release Burndown permet de :

• Voir à quelle vélocité votre équipe travaille sur la Release,
• Découvrir comment le travail ajouté et supprimé pendant le sprint a affecté la progression globale de l’équipe
• Prévoir le nombre de sprints nécessaires pour terminer le travail d’une Release, en vous basant sur les sprints passés et les changements au cours des sprints.

Le graphique affiche les informations suivantes :

• Section vert clair = travail réalisé pendant le sprint. Si une barre est entièrement vert clair, vous ne pourrez pas dire quelle part du travail effectué était initialement estimée ou non. Pour connaître ces informations, cliquez sur la barre pour afficher les détails.
• Section bleu clair = travail restant dans la Release par rapport à l’ensemble du travail estimé pour la Release au début du sprint.
• Section bleu foncé = travail ajouté pendant le sprint, mais non inclus à l’origine (c’est-à-dire changement de périmètre).
• Section vert clair + section bleu clair = travail total dans la Release initialement estimé au début du sprint.
• Section bleu clair + section bleu foncé = travail total dans la Release restant à la fin du sprint.
• Barres avec sections grises = sprints prévus. Les sprints prédits sont calculés en fonction de la vélocité de votre équipe (quantité de travail effectué au cours des trois derniers sprints) et du travail total restant pour la Release. Le changement de périmètre n’est pas pris en compte lors du calcul de la vélocité, mais est inclus dans le travail total restant.

L’article Les Reportings Agile de Jira Software est apparu en premier sur AZARA Consulting.

Essayez les nouveaux filtres d’activité des cartes pour Trello web !

Les nouveaux filtres vous montrent les cartes qui sont :

•Actives au cours de la dernière semaine

•Actives au cours des deux dernières semaines

•Actives au cours des quatre dernières semaines

•Aucune activité au cours des quatre dernières semaines

Source  : https://community.atlassian.com/t5/Trello-articles/A-new-way-to-filter-Trello-cards-saying-goodbye-to-the-Card/ba-p/2374997

Partager les pages de Confluence sur Slack

Vous avez peut-être interagi avec la fonctionnalité Confluence Share qui vous permet de partager du contenu avec d’autres via des notifications intégrées au produit. Vous avez peut-être également utilisé l’option Copier le lien pour générer une URL courte permettant de partager une page avec d’autres utilisateurs. La fonctionnalité Partager est désormais plus flexible que jamais, avec l’introduction de la fonctionnalité Partager dans Slack, qui vous permet de partager directement une page Confluence avec un utilisateur ou une chaîne dans Slack !

Source  : https://community.atlassian.com/t5/Confluence-articles/A-more-mindful-way-to-publish-is-coming-soon/ba-p/2384411

Changements dans la publication de Confluence

Pour que la publication se fasse de manière plus réfléchie, nous ajoutons une nouvelle boîte de dialogue de publication pour publier des projets pour la première fois et mettre à jour des pages existantes.

Source  : https://community.atlassian.com/t5/Confluence-articles/A-more-mindful-way-to-publish-is-coming-soon/ba-p/2384411

Amélioration de la recherche rapide dans Jira Software

1.Trouver rapidement les tickets grâce au filtre « reported by me ».

2.Voir les projets sur lesquels vous travaillez actuellement en haut des résultats de votre recherche

3.Trouvez ce que vous cherchez à l’aide d’une expression exacte

4.La requête intelligente va devenir optionnelle

5.Filtrer les résultats de la recherche en fonction de vos étiquettes

6.Lorsque vous survolez les résultats de recherche, une info-bulle apparaîtra avec plus d’informations sur le ticket.

7.À partir de bientôt, lorsque vous utiliserez la recherche rapide, un message « Vouliez-vous dire ? » s’affichera pour vous guider dans la recherche des termes et de l’orthographe corrects.

Source  : https://community.atlassian.com/t5/Jira-articles/Try-3-new-quick-search-improvements-in-Jira-Software-and-preview/ba-p/2387998

Créer des tickets Jira à partir de Confluence

Fini le temps où il fallait créer manuellement un ticket Jira Software à chaque fois que vous publiez une page dans Confluence !

Créer un nouveau ticket Jira Software directement à partir de Confluence Automation !

Créer un nouveau ticket Jira Software directement à partir de d’une Tâche Confluence à l’aide d’Automation !

Source  : https://community.atlassian.com/t5/Confluence-articles/Create-Jira-issues-directly-from-Confluence-with-the-latest/ba-p/2404119

Nouvelle navigation des espaces dans Confluence

1.Un tout nouvel onglet « Tout le contenu » : vous pouvez désormais rechercher et découvrir tout le contenu d’un espace en un seul endroit.

2.Mise à jour des sections (raccourcis, contenu, applications) – nous avons modifié l’ordre et rendu chaque section extensible afin que vous puissiez accéder rapidement au contenu et aux fonctionnalités qui vous intéressent.

3.Amélioration de l’accessibilité – nous avons ajouté des infobulles au survol pour tous les éléments de la barre de navigation latérale et mis à jour leurs états de sélection afin de mieux les distinguer.

4.Modernisation de l’apparence et de la convivialité – nous avons resserré la densité et l’espacement et mis à jour l’iconographie pour rendre l’expérience plus moderne.

Source  : https://community.atlassian.com/t5/Confluence-Cloud-Admins-articles/A-brand-new-space-navigation-experience-is-coming-to-Confluence/ba-p/2423193

Jira Work Management Premium

Débloquez la productivité à grande échelle sur Jira Work Management Premium.

Planifiez, livrez et rendez compte de votre travail à grande échelle avec des fonctionnalités Premium pour soutenir votre croissance.

Introduction d’un nouveau niveau de gestion du travail Jira : Premium, qui a été lancé le 17 juillet 2023.

Source  : https://www.atlassian.com/blog/jira-work-management/introducing-premium

Le thème sombre arrive au Data Center !

L’ajout d’un thème sombre vous permet de contrôler votre interface, de travailler dans la palette de couleurs de votre choix et d’aider un grand nombre de vos utilisateurs à mieux se concentrer sur leur écran. Ces mises à jour de l’expérience utilisateur permettent à chacun de travailler plus efficacement tout en réduisant les distractions visuelles.

Source  : https://community.atlassian.com/t5/Data-Center-articles/Dark-theme-is-coming-to-Data-Center/ba-p/2431400

Liens publics dans Confluence Cloud

Les liens publics vous permettent de partager une version d’une page en affichage limité avec toute personne sur Internet qui possède le lien public. (Remarque : les liens publics ne sont actuellement disponibles que pour un petit pourcentage de clients, mais nous espérons étendre cette fonctionnalité à tous nos clients payants dans le courant de l’année).

Source  : https://www.atlassian.com/blog/jira-work-management/introducing-premium

Jira Service Management Agent virtuel AI

Soutenu par Atlassian Intelligence, avec de puissantes capacités d’IA générative et un moteur de traitement du langage naturel de premier ordre, l’agent virtuel aide à fournir un support conversationnel rapide et automatisé via Slack (Microsoft Teams bientôt). Il analyse et comprend l’intention, le sentiment, le contexte et les informations de profil pour personnaliser l’assistance, et apprend de chaque interaction.

Qui y a accès ? L’agent virtuel (bêta) est actuellement disponible dans Slack pour tous les clients Jira Service Management Cloud Premium et Enterprise.

Source  : https://community.atlassian.com/t5/Jira-Service-Management-articles/Now-in-beta-Jira-Service-Management-AI-virtual-agent/ba-p/2462062

Amélioration de la recherche rapide

Vous pouvez accéder plus rapidement aux tickets récemment mise à jour. La dernière mise à jour signifie qu’une modification a été apportée au ticket. Voici quelques exemples :

•Le statut est passé de « à faire » à « en cours ».

•Un commentaire a été laissé sur la question

•La mise à jour d’un champ, par exemple l’ajout ou la suppression d’une étiquette.

Source  : https://community.atlassian.com/t5/Jira-articles/You-can-now-filter-by-last-updated-in-quick-search/ba-p/2466260

Nouvelles fonctionnalités pour Bitbucket Cloud

•Mise à l’échelle des flux de travail CI/CD : Importez les fichiers yml de Bitbucket Pipelines à travers les dépôts afin que tous les développeurs d’une équipe puissent utiliser le même flux de travail cohérent, en effectuant les mêmes étapes et les mêmes tests à travers le projet.

•Trouvez plus rapidement les commentaires non résolus : Lorsque vous avez plusieurs fichiers à examiner et de nombreux commentaires, il peut être difficile de trouver les commentaires qui nécessitent encore de l’attention. Nous avons ajouté une nouvelle liste déroulante dans la page de demande de retrait qui vous permet d’accéder aux commentaires non résolus ou de trouver des commentaires résolus spécifiques.

•Prise en charge des runners Linux ARM auto-hébergés : Si vous avez des builds qui nécessitent des runners ARM, vous pouvez maintenant faire pointer vos builds cloud utilisant Bitbucket Pipelines vers vos runners derrière le pare-feu.

•Vérifications de fusion au niveau du projet : Si vous avez un projet complexe avec de nombreux dépôts, vous pouvez maintenant appliquer un ensemble standard de vérifications à tous les dépôts d’un projet, ce qui facilite la gestion et le maintien d’un flux de travail cohérent.

Source  : https://community.atlassian.com/t5/Bitbucket-articles/Five-exciting-new-features-coming-to-Bitbucket-Cloud/ba-p/2475385

Nouveau modèle pour Jira Cloud Automation

Aujourd’hui, l’utilisation de l’automation est mesurée différemment selon les types de règles et les produits Atlassian. Actuellement, il n’y a qu’une seule limite commune pour tous les produits Jira Cloud.

Chaque fois qu’une règle d’automation s’exécute, elle est prise en compte dans cette limite, qu’elle ait réussi ou non. Le nouveau modèle d’emballage apporte une manière plus simple et plus cohérente de mesurer l’utilisation de l’automation. Chaque produit aura désormais un nombre fixe d’exécutions de règles mensuelles basé sur le plan.

Source  : https://community.atlassian.com/t5/Automation-articles/Introducing-our-new-packaging-model-for-Jira-Cloud-Automation/ba-p/2446099

Changements à venir dans le processus de sécurité des applications Data Center

Chez Atlassian, l’un de nos objectifs est de faire en sorte que nos clients puissent avoir confiance en la sécurité de nos logiciels. C’est pourquoi chaque produit DC d’Atlassian fait l’objet d’une analyse de sécurité des dépendances tierces pour détecter les vulnérabilités connues. Il est essentiel de remédier aux vulnérabilités dès que possible afin que nos clients puissent continuer à faire confiance à l’écosystème Atlassian. De cette manière, nous serons en mesure de détecter les problèmes potentiels suffisamment tôt pour réduire les risques pour nos clients.

Au fil des ans, nous avons vu évoluer les mécanismes utilisés par l’ingénierie d’Atlassian pour découvrir les failles de sécurité. Il existe des scanners de sécurité, le programme Bug Bounty 5, etc. Les clients s’appuient sur les logiciels d’Atlassian et nous confient leurs données tous les jours.

Les produits Atlassian Data Center font partie d’un écosystème florissant et la grande majorité des déploiements hébergent plusieurs applications Data Center. La sécurité d’une installation aussi complexe dépend de la sécurité de chacun de ses composants.

Source  : https://community.developer.atlassian.com/t/upcoming-changes-to-data-center-app-security-process/70096

2023 Gartner Magic Quadrant pour DevOps

Atlassian propose une plateforme DevOps unique et extensible qui connecte les équipes d’ingénierie, d’ITOps et d’entreprise pour accélérer la vélocité de l’ingénierie, améliorer la santé des applications, augmenter le temps de fonctionnement et la fiabilité, et livrer de la valeur plus rapidement.

Source  : https://www.atlassian.com/blog/devops/2023-gartner-mq-devops-atlassian

Mise à jour du Jira Work Management

1.Formulaires ouverts: Les formulaires ouverts sont en cours de déploiement ! Désormais, vous pourrez collecter les demandes d’admission de toute personne pouvant accéder à votre instance de gestion du travail Jira, et non plus seulement des utilisateurs ayant la permission de créer des tickets.

2.Intégration de Confluence dans la vue du tableau: Les pages Confluence en vue tableau sont également déployées dès maintenant et apportent le contexte dont vous avez besoin à une autre de vos vues préférées. Nous sommes impatients de voir comment vous allez tirer le meilleur parti de cette dernière intégration.

Source  : https://community.atlassian.com/t5/Jira-Work-Management-Articles/Let-the-July-updates-fly-New-University-course-open-forms/ba-p/2413981

Jira & ChatGPT – Tri des tickets avec l’IA

Dans cet article, même si vous n’êtes pas un développeur, vous apprendrez :

1.Pourquoi déléguer le tri à une IA ?

2.Exigences pour le tri automatique des tickets

3.Invitation à trier et à analyser le sentiment dans Jira

4.Comment intégrer Jira Service avec ChatGPT (étape par étape)

5.Coûts et économies générés

6.L’avenir du tri des tickets par l’IA

Accédez à l’article complet via ce lien !

Source  : https://medium.com/@feliperlucena/jira-chatgpt-triage-tickets-and-analyze-sentiments-with-ai-492ce7ead69d

L’article Newsletter Atlassian 3ième Trimestre 2023 est apparu en premier sur AZARA Consulting.