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.

Les produits et les données cloud d’Atlassian sont hébergés sur Amazon Web Services (AWS), le principal fournisseur de services cloud du secteur. Les produits Atlassian fonctionnent sur une plateforme PaaS (Platform as a Service) qui est divisée en deux ensembles d’infrastructures principaux appelés « Micros » et « non Micros ».

Infrastructure cloud

Zones de disponibilité (ZD)

Pour Jira et Confluence, Atlassian utilise le mode de déploiement multi-ZD avec Amazon Relational Database Service (Amazon RDS). Cela garantit une réplication synchrone de secours dans une autre ZD de la même région pour assurer la redondance et la capacité de basculement. Le basculement de ZD est automatisé et prend généralement de 60 à 120 secondes, permettant ainsi aux opérations de la base de données impactée de reprendre aussi rapidement que possible sans intervention administrative. Opsgenie, Statuspage, Trello et Jira Align utilisent des stratégies de déploiement similaires, avec de légères variations dans la synchronisation des réplications et des basculements.

Emplacement des données

Les données Jira et Confluence sont hébergées, par défaut, dans la région la plus proche de celle où se trouve la majorité de vos utilisateurs lors de leur inscription. Toutefois, Atlassian propose la Data Residency si le client exige que ses données soient hébergées dans un endroit particulier. Actuellement, la Data Residency Atlassian couvre les États-Unis et dans l’Union Européenne ainsi qu’en Australie.

Sauvegardes de données

Atlassian utilise la fonctionnalité d’instantané Amazon RDS pour créer des sauvegardes quotidiennes automatisées de chaque instance RDS.

Les instantanés Amazon RDS sont conservés pendant 30 jours avec prise en charge de la reprise à un instant de référence et sont chiffrés avec l’algorithme AES-256. Les données de sauvegarde ne sont pas stockées hors site, mais sont répliquées dans plusieurs data centers au sein d’une région AWS spécifique. Des tests trimestriels des sauvegardes sont également réalisés.

Architecture de la plateforme cloud

Architecture de services distribuée

L’architecture basée sur AWS permet l’hébergement d’un ensemble de services produit et de plateforme utilisés dans l’ensemble des solutions Atlassian. Ces services englobent les fonctionnalités de la plateforme partagée et utilisée par plusieurs produits.

FIGURE 1 – Architecture de services distribuée

Atlassian offrent ces services via une Platform as a Service (PaaS) interne, nommée Micros, qui automatise le déploiement des services partagés, de l’infrastructure, des entrepôts de données, et de leurs fonctionnalités de gestion, incluant les exigences en matière de sécurité et de conformité (voir la Figure 1 ci-dessus). En général, un produit Atlassian se compose de plusieurs services conteneurisés déployés sur AWS à l’aide de Micros.

FIGURE 2 – Architecture de services

Architecture Multi-Tenant

L’architecture mise en place est une architecture de microservices multi-locataire avec une plateforme partagée qui prend en charge les produits Atlassian. Dans une architecture multi-locataire, un même service dessert plusieurs clients, y compris les bases de données et les instances de calcul nécessaires pour faire fonctionner les produits cloud. Chaque partition (essentiellement un conteneur, voir la Figure 3 ci-dessous) contient les données de plusieurs locataires, mais les données de chaque locataire sont isolées et inaccessibles aux autres locataires. Il est important de noter que Atlassian ne propose pas d’architecture dédiée à un seul locataire.

FIGURE 3 – Architecture Multi-Tenant

Les microservices sont conçus selon le principe du moindre privilège et sont configurés de manière à réduire la surface d’attaque pour tout exploit zero-day, ainsi que la probabilité de mouvements latéraux au sein de l’environnement cloud. Chaque microservice dispose de son propre stockage de données, uniquement accessible via le protocole d’authentification spécifique à ce service, garantissant ainsi qu’aucun autre service n’a accès en lecture ou en écriture à cette API.

Atlassian a opté pour l’isolation des microservices et des données, plutôt que sur la mise à disposition d’une infrastructure dédiée par locataire, car cela limiterait l’accès aux données pour de nombreux clients.

Provisionnement d’un locataire et cycle de vie

Lors de la mise en place d’un nouveau client, une série d’événements déclenche l’orchestration des services distribués et le provisionnement des entrepôts de données. Ces événements peuvent généralement être associés à l’une des sept phases du cycle de vie :

Les systèmes commerciaux sont immédiatement actualisés avec les dernières métadonnées et informations de contrôle d’accès pour ce client. Ensuite, un système d’orchestration du provisionnement aligne « l’état des ressources provisionnées » avec l’état de la licence au moyen d’une série d’événements liés au locataire et aux produits.

Événements associés au locataire

Ces événements impactent le locataire dans son ensemble et peuvent prendre deux formes :

• Création : un locataire est créé et utilisé pour de tout nouveaux sites
• Destruction : un locataire entier est supprimé

Événements associés aux produits

• Activation : après l’activation de produits sous licence ou d’apps tierces
• Désactivation : après la désactivation de certains produits ou de certaines apps
• Suspension : après la suspension d’un produit existant, désactivant ainsi l’accès à un site donné dont il est propriétaire
• Annulation de suspension : après l’annulation de la suspension d’un produit existant, permettant ainsi l’accès à un site dont il est propriétaire
• Mise à jour de licence : contient des informations concernant le nombre de postes de licence pour un produit donné ainsi que son état (actif/inactif)

Création du site client et activation de l’ensemble de produits approprié pour le client. Le concept d’un site est le conteneur de plusieurs produits concédés sous licence à un client spécifique. (p. ex. Confluence et Jira Software pour ＜nom-site＞.atlassian.net).

Figure 4 – Evénements associés aux produits

Lors du provisionnement d’un produit sur le site client dans la région spécifiée, le contenu du produit est principalement hébergé à proximité de l’emplacement où les utilisateurs y accèdent. Les données peuvent être déplacées entre les régions pour optimiser les performances. Certains produits offrent également la possibilité de choisir la résidence des données, permettant aux clients de décider si les données sont distribuées mondialement ou conservées dans des zones géographiques définies.

• Création et stockage de la configuration et des métadonnées de base du site client et des produits.
• Création et stockage des données d’identité du site et des produits, comme les utilisateurs, les groupes, les autorisations, et bien plus encore.
• Provisionnement de bases de données de produits sur un site, p. ex. gamme de produits Jira, Confluence, Compass ou Atlas.
• Provisionnement des apps sous licence des produits.

Figure 5 – Déploiement d’un site client au sein de l’infrastructure distribuée d’Atlassian

La représentation schématique dans la Figure 5 dépeint le déploiement d’un site client au sein de l’infrastructure distribuée d’Atlassian, englobant non seulement une seule base de données ou un unique entrepôt. Elle englobe divers emplacements physiques et virtuels qui abritent des métadonnées, des paramètres de configuration, des données propres au produit et à la plateforme, ainsi que d’autres informations associées au site.

Isolement des locataires

Bien que les clients d’Atlassian partagent une infrastructure commune lorsqu’ils utilisent les produits cloud, un isolement logique est mis en place afin que les actions d’un client ne puissent compromettre les données ou le service d’autres clients.

Pour Jira et Confluence Cloud, Atlassian utilise un concept appelé « Contexte de locataire » pour parvenir à cet isolement logique. Ce concept est intégré dans le code applicatif et est géré par un service dédié appelé (Tenant Context Service, TCS). Le TCS s’assure que :

• les données de chaque client sont logiquement isolées de celles des autres locataires au repos ;
• toutes les requêtes traitées par Jira ou Confluence offrent une vue propre à chaque locataire, évitant ainsi tout impact sur les autres locataires.

En résumé, le TCS conserve un contexte pour chaque locataire du client. Chaque contexte est associé à un identifiant unique stocké de manière centralisée par le TCS. Il contient diverses métadonnées relatives à ce locataire, telles que les bases de données associées, les licences, les fonctionnalités disponibles, et d’autres paramètres de configuration. Lorsqu’un client accède à Jira ou Confluence Cloud, le TCS utilise l’identifiant du locataire pour récupérer ces métadonnées, qui sont ensuite associées à toutes les opérations effectuées par le locataire dans l’application pendant sa session.

Limites Atlassian

Los données client bénéficient également d’une protection par le biais d’une « limite » : des barrières virtuelles érigées autour du logiciel. Lorsqu’une requête arrive, elle est dirigée vers la limite la plus proche. Après une série de vérifications, elle est soit autorisée, soit refusée.

Voici le processus :

• La requête atteint la limite Atlassian la plus proche de l’utilisateur. Cette limite vérifie la session et l’identité de l’utilisateur via votre système d’identité.
• La limite détermine où sont localisées les données de vos produits, en se basant sur les informations fournies par le TCS.
• La limite transfère la requête vers la région cible, où elle est traitée par un nœud de calcul.
• Le nœud utilise le système de configuration du locataire pour obtenir des détails, tels que l’emplacement de la licence et de la base de données. Il interagit ensuite avec d’autres magasins de données et services pour récupérer les informations nécessaires afin de répondre à la requête.

Contrôles de sécurité

Du fait que les produits cloud reposent sur une architecture multilocataire, il est possible d’incorporer des mesures de sécurité supplémentaires dans la logique de l’application qui est décorrélée. En comparaison, une application monolithique par locataire ne serait généralement pas en mesure d’ajouter des contrôles d’autorisation supplémentaires ou de gérer la limitation du débit, notamment en cas de volume élevé de requêtes ou d’exportations. De plus, l’impact d’une éventuelle faille de sécurité (« exploit zero-day ») est grandement réduit à mesure que la surface d’attaque des services diminue.

En complément, des mécanismes de contrôle préventifs supplémentaires ont été intégrés. Ils incluent :

• L’authentification et l’autorisation des services
• Le Service de Contexte de Locataire (TCS)
• La gestion des clés
• Le chiffrement des données

Authentification et autorisation de services

La plateforme Atlassian applique un modèle de moindre privilège en matière d’accès aux données. Cela signifie que chaque jeu de données est restreint au service spécifique responsable de son enregistrement, de son traitement ou de sa récupération. Par exemple, les services multimédias, qui assurent une expérience homogène de chargement et de téléchargement de fichiers sur tous les produits cloud, disposent d’un stockage exclusif auquel aucun autre service Atlassian n’a accès. Tout service nécessitant l’accès à ces contenus multimédias doit interagir avec l’API dédiée aux services multimédias. Ainsi, une authentification et une autorisation rigoureuses au niveau de la couche de service garantissent une séparation des tâches efficace et un accès aux données conforme au principe du moindre privilège.

Les jetons web JSON (JWT) sont utilisés pour garantir l’intégrité des signatures en dehors de l’application, afin que les systèmes d’identité et le contexte du locataire soient la source de référence. Ces jetons ne peuvent être utilisés que dans les limites de leurs autorisations. Lorsqu’un utilisateur sollicite un microservice ou une partition, les jetons sont transmis au système d’identité et validés en conséquence. Cette procédure assure que le jeton est à jour et authentifié avant tout partage des données appropriées. Ainsi, en cas de compromission d’un service, son accès est circonscrit grâce à cette méthode, associée aux exigences d’authentification et d’autorisation nécessaires pour atteindre ces microservices.

Les systèmes d’identité peuvent parfois faire l’objet de compromissions. Pour atténuer ce risque, deux mécanismes ont été mis en place . Tout d’abord, le TCS et les proxys d’identité sont hautement redondants. Un TCS supplémentaire est mis en place pour presque tous les microservices et des proxys supplémentaires qui émanent de l’autorité d’identité sont utilisés, de sorte que des milliers de ces services sont en cours d’exécution à tout moment. Si un comportement anormal est détecté dans l’un d’entre eux, Atlassian est en mesure d’intervenir rapidement et de remédier à la situation.

De plus, Atlassian met en œuvre divers programmes de sécurité pour identifier et contrer les menaces de sécurité.

Service de contexte de locataire (TCS)

Atlassian s’assure que les requêtes adressées à tous les microservices contiennent des métadonnées concernant le client (ou le locataire) sollicitant l’accès. C’est le service de contexte de locataire (TCS). Il est alimenté directement à partir des systèmes de provisionnement. Lorsqu’une demande est initiée, le contexte est extrait et intégré ans le code de service en cours d’exécution, qui est utilisé pour autoriser l’utilisateur. Tous les accès au service (et donc aux données) dans Jira et Confluence nécessitent ce contexte de locataire, sans quoi la demande sera rejetée.

L’authentification et l’autorisation des services sont mises en œuvre à travers le protocole d’authentification Atlassian Service Authentication Protocol (ASAP). Une liste blanche explicite détermine quels services peuvent communiquer, tandis que des informations d’autorisation précisent les commandes et les chemins disponibles. Cette approche limite tout potentiel de déplacement latéral en cas de compromission d’un service.

L’authentification et l’autorisation des services, ainsi que le flux de sortie, sont surveillées par un ensemble de proxys dédiés. Ainsi, les vulnérabilités du code de l’application n’ont aucun impact sur ces contrôles. Pour qu’une exécution de code arbitraire (RCE) ait lieu, il faudrait compromettre l’hôte sous-jacent et contourner les limites du conteneur Docker, et non simplement être en mesure de modifier la logique de l’application. Le système de détection d’intrusions au niveau de l’hôte signale les incohérences à cet égard.

Ces proxys restreignent le comportement de sortie en fonction des activités prévues pour chaque service. Les services qui n’ont pas besoin d’émettre des webhooks ou de communiquer avec d’autres microservices n’ont pas l’autorisation de le faire.

Cryptage de données

Les données clients stockées dans les produits cloud d’Atlassian sont sécurisées lors de leur transit sur les réseaux publics. Cela est réalisé en utilisant le protocole TLS (Transport Layer Security) 1.2+ avec PFS (Perfect Forward Secrecy), garantissant ainsi leur protection contre toute divulgation ou altération non autorisée. La mise en œuvre du TLS exige l’utilisation de cryptages robustes et de longues clés lorsque le navigateur les prend en charge.

Par ailleurs, les disques de données sur les serveurs hébergeant les données client et les pièces jointes dans Jira Software Cloud, Jira Service Management Cloud, Jira Work Management, Bitbucket Cloud, Confluence Cloud, Statuspage, Opsgenie et Trello bénéficient d’un chiffrement complet au repos. Cette méthode repose sur l’algorithme de chiffrement AES avec une clé de 256 bits, une norme de l’industrie.

En ce qui concerne les informations d’identification personnelle (PII) transmises via un réseau de transmission de données, elles sont soumises à des contrôles appropriés visant à garantir qu’elles atteignent la destination prévue. La politique interne d’Atlassian en matière de cryptographie et de chiffrement énonce les principes généraux qui guident la mise en œuvre de ces mécanismes pour réduire les risques liés au stockage et à la transmission des PII sur les réseaux. Le choix de l’algorithme de chiffrement pour les PII doit être en accord avec la classification de ces données, conformément aux principes de sécurité des données et de gestion du cycle de vie de l’information chez Atlassian.

Pour rester informé des fonctionnalités additionnelles relatives au chiffrement des données, veuillez consulter la feuille de route Atlassian Cloud.

Gestion des clés

Chez Atlassian, la gestion des clés est faite l’aide du service AWS Key Management Service (KMS) pour . KMS agit en tant qu’initiateur et gardien secret de ces clés, renforçant ainsi la confidentialité des données. Le processus de chiffrement, déchiffrement et gestion des clés est régulièrement soumis à une inspection et à une vérification en interne par AWS, conformément à ses procédures de validation existantes. Chaque clé est assignée à un propriétaire, qui a pour responsabilité de veiller à ce qu’un niveau de contrôle de sécurité adéquat soit appliqué.

De plus, Atlassian a opté pour la mise en place du chiffrement des enveloppes. La clé principale est détenue par AWS et demeure invisible par Atlassian. Toute requête de chiffrement ou de déchiffrement de clé nécessite les autorisations et rôles AWS appropriés. Lorsque Atlassian utilise le chiffrement des enveloppes pour créer ou générer des clés pour des clients spécifiques, différentes clés de données sont utilisées pour différents types d’informations, stockées dans leurs entrepôts de données. En parallèle, Atlassian a instauré un chiffrement de couche applicative interne qui assure des clés de données de secours dans d’autres régions AWS. Ces clés sont automatiquement renouvelées chaque année, et une même clé de données n’est pas utilisée pour plus de 100 000 éléments de données.

Dans un avenir proche, Atlassian compte mettre en place le chiffrement BYOK, offrant ainsi la possibilité de chiffrer les données de produits cloud avec des clés gérées par les clients dans AWS KMS. Grâce à ce système, les clients auront un contrôle total sur la gestion de leurs clés et pourront accorder ou révoquer l’accès à tout moment, tant pour leurs utilisateurs finaux que pour les systèmes Atlassian.

AWS KMS peut être intégré à AWS CloudTrail dans le compte AWS, fournissant ainsi des journaux de toutes les utilisations des clés. Cette solution permet le chiffrement des données à différents niveaux applicatifs, comme les bases de données, le stockage de fichiers, ainsi que les caches internes et la mise en file d’attente des événements. Tout au long de ce processus, l’expérience utilisateur ne sera en aucun cas impactée.

L’article Atlassian Cloud : Résilience à grande échelle et une protection complète des données 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.

Scrum est un framework de gestion de projet Agile utilisé par les équipes de développement de logiciels pour collaborer. Il se base sur l’apprentissage par l’expérience, l’auto-organisation de l’équipe pour la résolution des problèmes, et la rétrospective périodique pour s’améliorer continuellement.

La méthodologie vient avec un ensemble de réunions, d’outils et de rôles qui interagissent de concert pour aider les équipes à structurer leur travail et à le gérer.

Dans cet article, nous verrons comment se compose le framework Scrum classique avec l’aide du Guide Scrum et comment ses concepts sont matérialisés sur Jira Software, l’outil Atlassian pour la gestion de projets.

Le framework

Scrum est un framework heuristique : il repose sur l’apprentissage continu et l’adaptation à des facteurs variables. Il se base sur le fait que l’équipe ne maîtrise pas tout au démarrage d’un projet et évoluera avec l’expérience. La méthodologie Scrum est structurée pour aider les équipes à s’adapter naturellement à l’évolution des conditions et des exigences des utilisateurs. La redéfinition des priorités et les cycles de livraison courts sont intégrés au processus pour permettre à votre équipe d’apprendre et de s’améliorer en permanence.

Même si Scrum est structuré, il n’est pas tout à fait rigide. Son exécution peut être adaptée aux besoins de n’importe quelle organisation. Cependant, afin de réussir sa mise en œuvre, la communication claire, la transparence et la volonté d’amélioration continue doivent rester les piliers de votre framework.

Artefacts Scrum

Les artefacts sont des outils créés pour résoudre un problème. Dans Scrum, ils sont au nombre de trois : le backlog produit, le backlog de sprint et l’incrément qui regroupe les tâches « terminées ».

• Le backlog produit est la liste principale des tâches à réaliser. Il est géré par le Product Owner ou le responsable produit. C’est une liste dynamique de fonctionnalités, d’exigences, d’améliorations et de correctifs qui fait office de point de départ pour le backlog de sprint. C’est la « to-do list » des équipes. Le backlog produit est constamment mis à jour, et ses priorités sont revues. Il est géré par le Product Owner qui le maintient en fonction de l’évolution du marché et du retour sur expérience de l’utilisateur.
• Le backlog de sprint est la liste d’éléments, d’user stories ou de correctifs de bug que l’équipe de développement a sélectionné en vue de leur implémentation dans le cycle de sprint actuel. Avant chaque sprint, une réunion de planification est organisée. Au cours de celle-ci, l’équipe choisit les éléments sur lesquels elle travaillera à partir du backlog produit. Un backlog de sprint peut être flexible et évoluer durant un sprint. Toutefois, l’objectif fondamental d’un sprint (ce que l’équipe souhaite atteindre à partir du sprint actuel) ne peut pas être remis en question.
• L’incrément (ou l’objectif de sprint) est le produit final exploitable qui a été obtenu pendant le sprint. L’« incrément » est présenté durant la démo de fin de sprint au cours de laquelle l’équipe montre ce qui a été effectué durant le sprint. Vous n’entendrez peut-être pas parler du terme « incrément », puisqu’il est souvent remplacé par la définition de « terminé » : une étape importante, l’objectif du sprint, voire une version complète de l’epic livré. Cela dépend de la façon dont les équipes définissent « terminé » et les objectifs de sprint. Par exemple, certaines équipes choisissent d’effectuer une livraison à leur client à la fin de chaque sprint. Pour elles, « terminé » signifie donc « livré ».Toutefois, cela peut ne pas être réalisable pour d’autres équipes. Par exemple, dans le cas où les livraisons client peuvent être opérées uniquement chaque trimestre. Les sprints sont de deux semaines, mais « terminé » est défini comme achever une portion d’une version plus large qui sera livrée par la suite. Il est utile de noter que plus vous avez besoin de temps pour livrer un logiciel, plus le risque qu’il puisse échoué est élevé.

Cérémonies Scrum

L’ensemble des cérémonies séquentielles que les équipes Scrum effectuent régulièrement constituent des composantes mieux connues du framework.

1. “Product Backlog refinement” : cet événement est sous la responsabilité du Product Owner. Ce dernier a deux tâches principales : faire de la vision du produit une réalité et rester constamment en ligne avec le marché et le client. Par conséquent, il tient à jour cette liste en s’appuyant sur le feedback des utilisateurs et de l’équipe de développement pour aider à définir des priorités et à maintenir un backlog propre et disponible à tout moment.
2. Planification du sprint : l’ensemble de l’équipe de développement planifie le travail à réaliser durant le sprint. Cette cérémonie est animée par le Scrum Master. À cette occasion, l’équipe détermine l’objectif du sprint. Les user stories sont ensuite ajoutées au sprint à partir du backlog produit. Ces stories correspondent toujours à l’objectif, et l’équipe Scrum s’accorde à dire qu’elles sont possibles à implémenter durant le sprint.À la fin de chaque réunion de planification, chaque membre de l’équipe Scrum doit savoir avec certitude ce qu’il est possible de livrer durant le sprint et comment réaliser l’incrément.
3. Sprint : un sprint désigne le délai défini par l’équipe Scrum pour terminer un incrément. Le délai classique d’un sprint est de deux semaines, mais il peut être d’une à quatre semaines. Ceci dit, plus le travail est complexe et plus les inconnues sont nombreuses, plus le sprint doit être court. Mais c’est à l’équipe de développement de voir. Le périmètre peut être renégocié entre le Product Owner et l’équipe de développement si nécessaire. C’est ce qui confère à la méthodologie Scrum sa nature empirique.Tous les événements, de la planification à la rétrospective, ont lieu durant le sprint. Dès lors que le délai du sprint est établi, il doit rester constant tout au long de la période de développement. L’équipe peut ainsi apprendre des expériences passées et appliquer ces enseignements aux sprints futurs.
4. Daily Scrum : mini-réunion quotidienne, rapide, de 15 minutes qui a lieu à la même heure le matin. L’objectif du « Daily Scrum » est de mettre tous les membres de l’équipe en phase avec l’objectif du sprint et de définir un plan pour les prochaines 24 heures.C’est l’occasion de faire part d’éventuelles préoccupations ou blocages concernant l’objectif du sprint.Le format de stand-up courant est de demander à chaque membre de l’équipe de répondre à trois questions sur la réalisation de l’objectif du sprint :• Qu’est-ce que j’ai fait hier ?
   • Qu’est-ce que je prévois de faire aujourd’hui ?
   • Y a-t-il des obstacles ?Le Daily Scrum a pour objectif de limiter les bavardages à une réunion quotidienne. L’équipe peut ensuite se concentrer sur son travail pendant le reste de la journée.
5. Revue de sprint : à la fin du sprint, l’équipe se rassemble afin d’effectuer une démo de l’incrément ou de l’inspecter. L’équipe de développement présente aux parties prenantes et à ses collègues les éléments du backlog terminés pour avoir leur avis. Le Product Owner peut décider de livrer ou non l’incrément.Cette revue est également l’occasion pour le Product Owner d’apporter des modifications au backlog produit sur la base du sprint actuel, lesquelles peuvent ensuite être intégrées à la session de planification du prochain sprint. Pour un sprint d’un mois, envisagez de « time-boxer » votre revue de sprint à un maximum de quatre heures.
6. Rétrospective de sprint : la rétrospective est l’occasion pour l’équipe de se rassembler afin de documenter ce qui a fonctionné ou non dans un sprint, un projet, des relations, des outils, chez des personnes, voire dans certaines cérémonies et d’en discuter. L’idée est de créer un espace dans lequel l’équipe peut se concentrer sur ce qui a bien fonctionné et sur les choses à améliorer.

Trois rôles essentiels pour la réussite de Scrum

Une équipe Scrum doit rassembler trois rôles : le Product Owner, le Scrum Master et l’équipe de développement. Et, comme les équipes Scrum sont pluridisciplinaires, l’équipe de développement comprend des testeurs, des concepteurs, des spécialistes de l’expérience utilisateur et des ingénieurs opérationnels, en plus des développeurs.

Le Product Owner Scrum

La priorité du Product Owner est de comprendre les exigences du business, des clients et du marché, puis de prioriser le travail de l’équipe d’ingénierie en conséquence. Le Product Owner efficace :

• crée et gère le backlog produit ;
• travaille en étroite collaboration avec le business et l’équipe pour s’assurer que tous savent en quoi consistent les tâches du backlog produit ;
• fournit à l’équipe des orientations claires sur les prochaines fonctionnalités à livrer ;
• décide du moment où le produit doit être livré, avec une prédisposition pour des livraisons plus fréquentes.

Le Product Owner fait en sorte que l’équipe de développement offre un maximum de valeur ajoutée au business. Il est également important que le Product Owner soit une seule personne. Aucune équipe de développement ne se réjouira de recevoir des directives différentes de plusieurs Product Owners.

Le Scrum Master

Les Scrum Masters sont les champions de Scrum au sein de leur équipe. Ils coachent l’équipe, les Product Owners et le business sur le processus Scrum et cherchent les façons d’affiner leur pratique en la matière.

Un Scrum Master efficace comprend parfaitement le travail que l’équipe doit réaliser et peut aider celle-ci à optimiser la transparence et le flux de livraison. En tant que chef d’orchestre, il prévoit les ressources nécessaires (humaines et logistiques) pour planifier le sprint, le stand-up, la revue et la rétrospective de sprint.

L’équipe de développement Scrum

Les équipes Scrum abattent le travail. Elles sont les championnes des pratiques de développement durables. Elles comptent généralement entre cinq et sept membres. Une façon de déterminer la taille de l’équipe consiste à suivre la règle des « deux pizzas » du PDG d’Amazon, Jeff Bezos : deux pizzas doivent suffire pour nourrir l’équipe.

Les membres de l’équipe présentent des compétences variées. Ils se forment les uns les autres afin qu’aucun ne devienne un goulot d’étranglement dans la livraison du travail. Les équipes Scrum efficaces s’organisent de façon autonome et adoptent une attitude du « nous » dans leur approche des projets. Les membres de l’équipe s’entraident tous afin de garantir la réussite du sprint.

L’équipe Scrum détermine le plan pour chaque sprint. Elle prévoit la quantité de travail qu’elle pense pouvoir assumer tout au long de l’itération en se servant de sa vélocité comme guide. En gardant une longueur d’itération fixe, l’équipe de développement bénéficie d’un feedback important sur son processus d’estimation et de livraison. Avec le temps, ses prévisions deviennent donc de plus en plus précises.

Scrum, Kanban et Agile

Scrum est un framework Agile si populaire que ces deux méthodologies sont souvent confondues l’une avec l’autre. Il existe toutefois d’autres frameworks, comme Kanban, qui est une alternative populaire. Certaines entreprises choisissent même de suivre un modèle hybride de Scrum et Kanban, appelé « Scrumban » ou Kanplan.

Scrum et Kanban utilisent tous deux des méthodes visuelles, comme le tableau Scrum ou Kanban, pour suivre l’avancement du travail. Tous deux donnent la priorité à l’efficacité et à la subdivision de tâches complexes en plus petits blocs gérables. Leur approche pour réaliser cet objectif diffère toutefois.

Scrum se concentre sur des itérations à durée limitée. Une fois la durée d’un sprint finalisée, les stories ou les entrées du backlog produit qui peuvent être implémentées durant ce cycle de sprint sont déterminées. Dans Kanban, le nombre de tâches ou la quantité de travail en cours (limite Work In Progress) à implémenter au cours du cycle actuel est fixé(e) au préalable. Le temps nécessaire pour implémenter ces fonctionnalités est ensuite calculé en remontant dans le temps.

Kanban n’est pas aussi structuré que Scrum. Hormis la limite Work In Progress, cette méthodologie est relativement ouverte à l’interprétation. Scrum intègre toutefois plusieurs concepts catégoriques dans le cadre de son implémentation, comme la revue de sprint, la rétrospective, la mêlée quotidienne (Daily Scrum), et bien d’autres. La méthodologie insiste également sur la transversalité, c’est-à-dire la capacité d’une équipe Scrum à ne pas dépendre de membres externes pour atteindre ses objectifs. Il n’est pas toujours simple de former une équipe transverse. En ce sens, Kanban est plus facile à adapter, alors que Scrum peut être considéré comme un virage fondamental dans le processus de réflexion et dans le fonctionnement d’une équipe de développement.

Mais, pourquoi Scrum ?

Le framework Scrum en lui-même est simple. Les règles, artefacts, événements et rôles sont faciles à comprendre. Son approche semi-normative aide véritablement à lever les ambiguïtés du processus de développement, tout en offrant aux entreprises la liberté suffisante pour ajouter leur propre touche.

L’organisation de tâches complexes en user stories gérables en fait la méthodologie idéale pour les projets complexes. Par ailleurs, la démarcation claire des rôles et les événements planifiés garantissent la transparence et la responsabilité collective tout au long du cycle de développement. Les livraisons rapides maintiennent la motivation de l’équipe et la satisfaction des utilisateurs à un niveau élevé, car il est possible de voir l’avancement dans un bref laps de temps.

Toutefois, la parfaite compréhension de Scrum peut prendre un certain temps, en particulier si l’équipe de développement est habituée à un modèle en cascade classique. Les concepts d’itérations plus restreintes, de mêlées quotidiennes (Daily Scrum), de revues de sprint et l’identification d’un Scrum Master pourraient s’avérer un virage culturel difficile à prendre pour une nouvelle équipe.

Toutefois, les avantages à long terme prévalent nettement sur la courbe d’apprentissage initiale. Le succès de Scrum dans le développement de produits logiciels complexes, quels que soient le secteur et le marché, en fait un framework attrayant à adopter pour votre organisation.

Si vous envisagez de mettre en place la méthode SCRUM, n’hésitez pas à nous contacter. Nos équipes constitués de consultants certifiés SCRUM et Atlassian ont à leurs actifs plusieurs projets mis en place avec succès et seront ravis de partager avec vous leurs retours d’expériences.

L’article Fonctionnent de la méthode Scrum est apparu en premier sur AZARA Consulting.

SAFe définit le cadre pour l’alignement, la collaboration et le delivery entre un grand nombre d’équipes agiles. Il s’articule autour de trois principaux blocs de connaissances : le développement logiciel agile, le développement de produits lean et la pensée systémique.

À mesure que les entreprises grandissent, SAFe apporte une approche structurée pour le scaling agile. Quatre configurations sont proposées en fonction du niveau de scale souhaité : Essential SAFe, Large Solution SAFe, Portfolio SAFe et Full SAFe.

Dean Leffingwell et Drew Jemilo ont lancé SAFe en 2011 pour aider les organisations à concevoir de meilleurs systèmes et logiciels qui répondent mieux aux besoins changeants des clients. À cette époque, les équipes utilisaient des processus de gestion de projet classiques pour livrer des logiciels. Mais à mesure que la nécessité de répondre rapidement aux conditions évolutives du marché augmentait, de nouvelles méthodologies ont émergé pour aider les entreprises à améliorer la livraison de solutions dans leurs entreprises : SAFe a vu le jour. Aujourd’hui, SAFe est l’une des méthodologies agile à l’échelle les plus utilisées, et la communauté mondiale de praticiens de SAFe continue de le faire évoluer.

Les principes et les valeurs fondamentaux

Valeurs fondamentales

Les valeurs fondamentales de SAFe décrivent la culture que le leadership doit favoriser pour réussir la mise en œuvre de la méthodologie.

Alignement

L’une des exigences de SAFe est la mise en place des cadences de planification et de réflexion à tous les niveaux de l’organisation. Une fois en place, tous les collaborateurs ont une idée claire sur l’état actuel de l’entreprise, les objectifs et le rôle de chacun pour atteindre ces objectifs. En synchronisant régulièrement les personnes et les activités, tous les niveaux du portefeuille restent alignés. Les informations circulent à la fois vers le haut et vers le bas en temps opportun, contrairement aux structures traditionnelles top down.

Qualité intégrée

Dans le cadre de la démarche SAFe, l’agilité ne doit jamais se faire au détriment de la qualité. SAFe exige des équipes à tous les niveaux qu’elles définissent ce que « done» signifie pour chaque tâche ou projet et qu’elles intègrent des pratiques de développement de qualité dans chaque contrat de travail. Selon SAFe, il existe cinq dimensions clés de la qualité intégrée : le flux, la qualité de l’architecture et de la conception, la qualité du code, la qualité du système et la qualité des livraisons.

Transparence

SAFe encourage la mise en place d’un climat de confiance et de transparence, notamment en planifiant le travail en petits lots afin que les problèmes puissent être identifiés plus tôt, offrant une visibilité en temps réel sur l’avancement de la backlog à tous les niveaux, ainsi que les rituels d’inspection et d’adaptation.

Exécution du programme

L’exécution du programme est au cœur de SAFe et soutient tous les autres aspects du framework. Les équipes et les programmes doivent pouvoir fournir régulièrement un service de qualité, des logiciels opérationnels et une valeur business.

Direction

SAFe requiert un comportement de leadership Lean/Agile, car seuls les leaders peuvent transformer le système et mettre en place l’environnement nécessaire pour inculquer toutes les valeurs fondamentales.

Principes SAFe

Les principes SAFe sont destinés à améliorer l’entreprise dans son ensemble en éclairant la prise de décision Lean/Agile au-delà des limites fonctionnelles et organisationnelles. Les principes visent à influencer non seulement les décisions des dirigeants et des responsables, mais aussi celles de tous les membres de l’organisation, et à les encourager à passer d’une pensée classique en waterfall à une pensée Lean/Agile, qui applique des pratiques telles que la gestion de portefeuilles Lean.

Principe n° 1 : Adopter une vision économique

D’après les théories sur le flux de développement produit tirées des best-sellers de Donald Reinertsen, chaque intervenant dans la chaîne de décision doit comprendre les implications économiques des retards pour obtenir le délai d’exécution le plus court possible. Il ne suffit pas toujours de livrer tôt et régulièrement. Selon SAFe, classer les tâches pour optimiser les bénéfices, comprendre les échanges économiques et travailler en respectant des budgets serrés sont autant de responsabilités qui doivent être communiquées à l’échelle de l’organisation. De nombreux concepts et outils sont tirés des théories de Donald Reinertsen sur le flux de développement produit.

Principe n° 2 : Appliquer une pensée systémique

SAFe encourage les personnes qui utilisent le framework à appliquer une pensée systémique sur trois axes clés : la solution elle-même, l’entreprise qui développe le système et les flux de valeur. Les solutions peuvent concerner des produits, des services ou des systèmes fournis au client, qu’ils soient internes ou externes à l’entreprise.

Les solutions d’envergure comportent de nombreux composants interconnectés. Les membres de l’équipe doivent avoir une vision d’ensemble pour savoir comment leur élément s’intègre dans la solution.

Les adeptes de SAFe doivent prendre en considération l’ensemble des acteurs de la chaine de réalisation de la solution, du système de management et des processus de réalisation. Ainsi, si une organisation cherche à optimiser les méthodes de travail, elle devra peut-être éliminer les silos, devenir transverse, et conclure de nouveaux accords de coopération avec les fournisseurs et les clients. Finalement, l’entreprise doit clairement expliquer comment la valeur passe du concept au financement dans les flux de valeur de développement de solutions. Les dirigeants et la direction doivent optimiser le flux de valeur au-delà des limites fonctionnelles et organisationnelles.

Principe n° 3 : Supposer la variabilité, conserver les options

Par défaut, la conception de systèmes et de logiciels est un exercice incertain. Ce principe répond à cette incertitude en introduisant le concept de « Set-Based Design » (design basé sur un ensemble), qui implique de garder plusieurs exigences et options de design pendant une période prolongée dans le cycle de développement. Le « Set-Based Design » s’appuie également sur des données empiriques afin de se focaliser sur la dernière option de design dans la suite du processus.

Le « Set-Based Design » aide à prendre des décisions éclairées en période d’incertitude en identifiant les options et les résultats escomptés, sur le même principe qu’un choix stratégique. Le concept visant à intégrer des « étapes importantes d’apprentissage » (qui font référence à la date limite pour prendre des décisions) joue un rôle clé dans le « Set-Based Design ». Plus les équipes apprennent au fil du temps, plus elles peuvent éliminer de choix. Plus elles éliminent de choix, plus il est facile d’identifier la meilleure voie à suivre et de produire le meilleur résultat possible pour les clients.

Principe n° 4 : Se développer de manière itérative à l’aide de cycles d’apprentissage rapides et intégrés

À l’instar du principe n° 3, ce principe aborde le risque et l’incertitude par le biais d’étapes importantes d’apprentissage. Il ne suffit pas que chaque composant du système soit fonctionnel, il faut tenir compte de l’ensemble du système pour évaluer la faisabilité des choix de design actuels. Les points d’intégration doivent être planifiés à intervalles réguliers, afin d’accélérer les cycles d’apprentissage. Ces points d’intégration constituent un parfait exemple du cycle PDCA (plan-do-check-adjust) de Walter A. Shewhart, un framework pour l’amélioration continue de la qualité et un mécanisme pour contrôler la variabilité du développement. Les travaux de Walter Shewart et ceux qu’il a inspirés se concentrent souvent sur SAFe.

Principe n° 5 : Baser les étapes importantes sur une évaluation objective des systèmes de travail

La démonstration d’un véritable système de travail constitue une meilleure base pour la prise de décision qu’un document d’exigences ou toute autre évaluation superficielle de la réussite. Inclure dès le départ les parties prenantes dans ces décisions de faisabilité permet de renforcer la confiance et encourage une pensée systémique.

Principe n° 6 : Visualiser et limiter le travail en cours (Work in Process, WIP), réduire la taille des lots et gérer la longueur des files d’attente

Limiter le travail en cours aide les parties prenantes à évaluer avec précision le déroulement des opérations.

Les trois éléments de ce principe représentent les principaux moyens d’optimiser le débit et d’accélérer la création de valeur ou, en d’autres termes, d’implémenter le « flux ». Comme le dit l’adage « Ne mettons pas la charrue avant les bœufs ».

En appliquant ce principe au développement logiciel, vous limitez le nombre de tâches se chevauchant, la complexité de chaque tâche et le volume total de travail à réaliser à un moment donné. La petite taille des lots permet de vérifier en permanence que le travail est sur la bonne voie. Et que la longueur des files d’attente est correctement gérée…

Ce principe vise à donner des conseils sur l’optimisation de ce processus en vue d’obtenir les meilleurs résultats.

Principe n° 7 : Appliquer la cadence, synchroniser avec la planification transverse

Les équipes Agile appliquent naturellement la cadence par le biais de sprints ou d’itérations. La création d’une cadence pour tous les sujets possibles réduit la complexité, répond à l’incertitude, développe la mémoire musculaire, renforce la qualité et incite à la collaboration. La synchronisation de ces cadences permet aux personnes et aux activités de fonctionner comme des rouages où les informations apprises éclairent les décisions et la planification incrémentielle.

Principe n° 8 : Susciter la motivation intrinsèque des travailleurs du savoir

Inspiré par le conseiller en gestion influent Peter Drucker et l’auteur Daniel Pink, ce principe est l’un de nos préférés ! Il permet de libérer le potentiel des équipes et aide la direction à adopter une approche de commandement et de contrôle pour coacher ses équipes et répondre à leurs besoins.

Principe n° 9 : Décentraliser la prise de décision

Réduire la longueur des files d’attente et adopter une approche économique en décentralisant la prise de décision confèrent aux équipes l’autonomie dont elles ont besoin pour accomplir leur travail. Les dirigeants doivent conserver leur pouvoir de décision pour les sujets stratégiques et permettre aux équipes d’opérer des choix éclairés sur tous les autres sujets.

Comment fonctionne SAFe ?

Les organisations prêtes à implémenter SAFe bénéficient généralement d’un parrainage au niveau de la direction, d’une forte volonté de changement et d’une base Scrum.

Scaled Agile, Inc. fournit une feuille de route pour implémenter SAFA, qui contient des étapes détaillées pour vous lancer et configurer l’organisation en vue de l’adoption générale dans tous les portefeuilles. Voici les 12 étapes de l’implémentation de SAFe :

1. Atteindre le point de bascule
2. Former des agents du changement Lean/Agile
3. Former des directeurs, des responsables et des leaders
4. Créer un centre d’excellence Lean/Agile
5. Identifier des flux de valeur et des Agile Release Trains (ART)
6. Élaborer le plan d’implémentation
7. Préparer le lancement de l’ART
8. Former les équipes et lancer l’ART
9. Préparer le lancement de l’ART
10. Lancer d’autres ART et flux de valeur
11. Étendre au portefeuille
12. Maintenir et améliorer

Comment SAFe se situe-t-il par rapport aux autres frameworks Agile à grande échelle ?

Bien que SAFe® soit largement adopté par les entreprises disposant de grandes équipes de développement, d’autres frameworks Agile à grande échelle ont gagné en popularité au fil du temps. Tous ces frameworks partagent cinq composants principaux : l’inspiration des 12 principes du manifeste Agile, la cadence, la synchronisation, Scrum et les pratiques de développement de qualité. Comprendre les origines des autres frameworks, les différences fondamentales et les conditions pour une application réussie permet aux organisations de sélectionner le framework qui répond le mieux à leurs besoins.

Vous souhaitez en savoir plus sur certains des principaux frameworks Agile à grande échelle ? Consultez la page de présentation Agile à grande échelle sur le coach Agile.

SAFe et Scrum@Scale

Dans Scrum@Scale (S@S), tout le monde fait partie d’une équipe Scrum interchangeable. En fonction de leurs objectifs, les réseaux d’équipes Scrum se rassemblent pour former un écosystème. L’objectif de S@S est de créer un réseau d’équipes Scrum grâce à une architecture « scale-free », ce qui signifie que les rôles et les événements Scrum de base sont mis à l’échelle de façon linéaire, sans introduire de nouvelle dynamique de processus. Par exemple, un Scrum de Scrums (SoS) peut ne pas être suffisant pour un produit très complexe comptant 25 équipes Scrum, donc un Scrum de Scrum de Scrums (SoSoS) avec un Scrum de Scrums Master (SoSM) peut être nécessaire.

Bien que S@S soit généralement moins normatif, il propose une question directrice afin d’aider les organisations à déterminer si elles sont prêtes à évoluer : si vous ajoutez d’autres personnes au système, les performances augmentent-elles de manière exponentielle ou la productivité en souffre-t-elle ?

Tout comme SAFe, S@S propose un contenu de référence en ligne, notamment un guide Scrum@Scale complet dont la popularité ne cesse de croître.

Le framework S@S est le plus approprié dans les cas suivants :

• La stack technique est orientée objet (c’est-à-dire que les user stories verticales peuvent être livrées en deux semaines).
• Les « feature teams » de l’organisation possèdent des compétences en forme de T, adoptent des valeurs axées sur le produit et gèrent un minimum de paperasse.
• Aucun outil Agile ou de gestion du cycle de vie Agile (ALM) n’est requis tant que les pratiques ne sont pas devenues une seconde nature.
• L’équipe de direction est prête à se familiariser avec Scrum et à lever les obstacles pour l’organisation.

SAFe et Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) adopte une approche minimaliste des rôles, de la structure et des artefacts. Alors que SAFe propose quatre configurations pour satisfaire des équipes de plus en plus grandes et offrant des solutions de plus en plus complexes, LeSS en propose deux : LeSS pour deux à huit équipes et LeSS Huge pour plus de huit équipes. LeSS se distingue également par sa position selon laquelle les Product Owners devraient disposer d’un contrôle complet sur le contenu et d’une influence stratégique, alors que SAFe encourage une approche plus démocratique. Et si SAFe s’accompagne de nombreux facteurs qui influencent la stratégie, LeSS met l’accent sur une approche orientée client axée sur les clients payants.

À l’instar de S@S, LeSS évolue depuis les événements, les artefacts et les rôles Scrum. SAFe et LeSS mettent tous deux l’accent sur la pensée systémique, la pensée Lean et d’autres principes directeurs similaires. LeSS, en revanche, met fortement l’accent sur la réduction du gaspillage dans l’ensemble de l’organisation, avec pour objectif une amélioration continue.

Le framework LeSS est le plus approprié dans les cas suivants :

• Les équipes Scrum maîtrisent Scrum.
• La direction cherche à se restructurer et à expérimenter en permanence pour le bien commun.
• Un alignement sur la définition du produit existe.
• Un alignement sur la définition de l’état « Terminé » existe.
• Des coachs externes travaillent avec des groupes d’équipes, organisationnels et techniques.
• Des « feature teams » et des « component teams » possédant des compétences en T sont disponibles.
• L’organisation cherche à se débarrasser entièrement de la gestion de projets.

SAFe et DA

Contrairement aux autres frameworks décrits, Disciplined Agile (DA) est un kit d’outils qui permet aux organisations de décider de la méthode de travail la plus logique pour s’y adapter. Il propose une gouvernance Agile légère, qui s’appuie sur Scrum et Kanban, ainsi que des connaissances en matière de transformation dans des domaines, tels que les RH et les finances, la gouvernance, la méthodologie DevOps ou la gestion de portefeuilles. DA implique l’utilisation de différents niveaux d’évolutivité pour chaque projet et met l’accent sur la capacité de prise de décision pour aider à orienter la direction stratégique.

Le framework DA est le plus approprié dans les cas suivants :

• Les organisations veulent définir leurs propres parcours Agile à grande échelle.
• Les organisations souhaitent rester flexibles au sein de l’entreprise.
• Les organisations entendent préserver les choix de processus et/ou de framework.

SAFe et Spotify

Le « modèle » Spotify est un ensemble de pratiques autonome et axé sur les personnes qui peut être appliqué pour coordonner les équipes Agile. Il n’a jamais été conçu comme un modèle ou un framework, mais certaines entreprises l’ont adopté en tant que tel. Spotify met l’accent sur les équipes auto-organisées, transverses et colocalisées appelées « squads » (l’équivalent d’une équipe Scrum). En comparaison, SAFe n’a pas de disposition de ce type sur la colocation des équipes. Elle est encouragée pour la planification d’incrément de programme.

Les squads sont organisés en unités plus importantes appelées « tribus ». Les dépendances entre les squads sont peu nombreuses et sont traitées par le biais d’un Scrum de Scrums lorsqu’elles se produisent. Le partage des connaissances est possible grâce aux « chapitres » et aux « guildes », et des groupes informels sont organisés en fonction des compétences et des intérêts.

Par rapport à d’autres exemples, où des ressources en ligne, des cours de formation et des certifications sont disponibles, les ressources sur le modèle Spotify se limitent à un blog accessible au public et à d’autres éléments complémentaires développés par ses pionniers et ses fans. Le modèle est de plus en plus populaire, il est donc probable que nous en verrons d’autres à l’avenir.

Le modèle Spotify est le plus approprié dans les cas suivants :

• Application des idées dans votre propre contexte commercial.
• La culture organisationnelle est axée sur l’apprentissage, la tolérance aux erreurs et la prise de risques contrôlés.
• Les équipes et les produits sont « légèrement couplés, étroitement alignés » pour éviter tout conflit de dépendance.

SAFe 5.0

L’un des principes fondamentaux du framework SAFe est qu’il continue à évoluer en collaboration avec sa communauté d’experts dans le monde entier. Récemment, Scaled Agile, Inc. a lancé la version 5.0 de SAFe. Les principaux changements comprennent l’ajout d’un 10e principe, « Organiser autour de la valeur », et le remplacement de l’étape 12, « Maintenir et améliorer », par « Accélérer ». Mais les implications sont bien plus nombreuses.

Conclusion

Les frameworks comme SAFe et ceux qui ont été évoqués ci-dessus constituent une option viable pour aider les entreprises à se développer efficacement au sein de leur organisation et à atteindre leurs objectifs commerciaux. Mais les outils que vous choisissez pour vous aider à amplifier les pratiques existantes et à en tirer pleinement parti sont tout aussi importants. Nos équipes sont à votre disposition pour vous présenter la solution Jira Align d’Atlassian, une plateforme de planification Agile d’entreprise développée pour SAFe. Grâce à Jira Align, vous pouvez améliorer la visibilité, l’alignement stratégique et l’adaptabilité de l’entreprise afin d’accélérer votre transformation digitale.

L’article Le scaled agile framework Safe : ses principes, fonctionnement et comparaison avec les autres frameworks Agile à grand échelle est apparu en premier sur AZARA Consulting.

De nombreux signes indiquent que les équipes supports informatiques ont du mal à répondre aux besoins de votre organisation et de ses employés. Ceux-ci incluent la backlog des demandes non encore prises en charge, un taux de réponse faible, une productivité à la baisse, les niveaux élevés d’escalades avec des demandes urgentes et les mauvaises performances par rapport aux mesures des engagements de services convenues (SLAs).
De nombreuses organisations utilisent un système rudimentaire de ticketing ou IT Help Desk, mais il manque probablement la plupart des fonctionnalités disponibles dans les solutions modernes de gestion des services informatiques (ITSM). Cela affecte négativement l’efficacité du support informatique et offre une mauvaise expérience utilisateur aux collaborateurs.
Avec les exigences croissantes dans ce monde en constante évolution et sans un moyen efficace pour gérer les demandes des employés, la capacité de support informatique de l’entreprise aura du mal à suivre le rythme des objectifs business. Il est de plus en plus nécessaire que les services informatiques soient plus efficaces et offrent l’expérience utilisateur souhaitée. De plus, les attentes en matière de services informatiques de haute qualité continuent de croître, quel que soit l’endroit où les employés travaillent.

5 Bonnes pratiques ITSM clés pour de meilleure prestation de services IT

L’adoption des meilleures pratiques et outils ITSM modernes peut transformer la façon dont votre équipe de services informatiques fournit le support :

1. Séparer les incidents des demandes de service
2. Mieux utiliser les données relatives aux prestations de services
3. Offrir aux collaborateurs le libre-service 24 heures sur 24, 7 jours sur 7
4. Fournir le service informatique n’importe où, n’importe quand
5. Fournir de meilleurs services en utilisant les dernières technologies

Bonne pratique 1 : Séparer les incidents des demandes de service

Cette séparation est essentielle pour la hiérarchisation efficace des tâches et la meilleure utilisation du temps de l’équipe de support informatique. Et les tâches les plus importantes, basées sur l’urgence et l’impact de l’entreprise, peuvent être traitées en premier et avoir des engagements de services appropriés. D’autant plus que les tâches les plus prioritaires changeront probablement tout au long de la journée.
La séparation est un excellent moyen de réduire, voire d’éliminer, la difficulté de prendre en charge tous les incidents prioritaires.

Amélioration de l’efficacité de 20% *

Réduction des incidents de priorité haute 25% *

Réduction du temps de résolution de 50% *

Bonne pratique 2 : Mieux utiliser les données relatives aux prestations de services

La séparation des incidents des demandes de service, ainsi que la catégorisation des demandes, permettent à l’équipe support informatique de réduire de façon proactive sa charge de travail :

• Les données des incidents peuvent être analysées pour mettre en évidence les problèmes récurrents. Ainsi, la mise en place de la gestion des problèmes et la correction de la root cause va permettre de remédier aux futurs incidents potentiels.
• Les données de demande de service peuvent être analysées pour identifier les types de demandes récurrentes à volume élevé qui peuvent l’objet d’une automatisation.

En plus, l’accès aux données de prestation de services structurées offre également une meilleure compréhension des performances opérationnelles, permettant aux organisations d’aligner les services sur les objectifs business et d’identifier les opportunités d’amélioration.

37% Des employés disent que les employeurs automatisent toujours les processus pour améliorer l’expérience des collaborateurs *
75% Réduction des efforts liés à la génération de rapports et à la gestion des ressources *

Bonne pratique 3 : Offrir aux collaborateurs le libre-service 24/24, 7/7

Les collaborateurs préfèrent disposer d’un portail libre-service simple et intuitif leur permettant de saisir de façon très allégée leurs demandes.
La mise à disposition d’une base de connaissance couplée à de l’intelligence artificielle permet d’offrir une assistance virtuelle en temps réel, personnalisée et de haute qualité. Ce qui augmente la satisfaction des collaborateurs tout en réduisant la charge de travail de l’équipe support leur permettant ainsi de dédier plus de temps à la résolution des incidents et problèmes prioritaires.

77% des collaborateurs préfèrent disposer d’un portail leur permettant d’accéder à l’information de façon centralisée *

Bonne pratique 4 : Fournir le service informatique partout et à tout moment

En plus du libre-service, les collaborateurs de votre organisation s’attendent à avoir accès aux services informatiques à tout moment et de n’importe où.
L’accès au libre service à partir de n’importe quel device (mobile, PC, Tablette…) accélère la prise en charge des demandes, la productivité et augmente de ce fait la satisfaction des collaborateurs.

54% s’attendent à accéder au portail de l’ITSM à partir du mobile *

20% de réduction des demandes dues grâce à l’automatisation et l’intelligence artificielle *

Bonne pratique 5 : Automatisez à l’aide de l’Intelligence Artificielle et le machine learning

L’intelligence artificielle (IA) ou, plus précisément, les fonctionnalités du support informatique basées sur le machine learning sont déjà disponibles dans les principales solutions ITSM. De nombreuses organisations offrent du libre-service et de l’assistance automatique à l’aide des agents virtuels.

Les agents virtuels peuvent, par exemple, fournir les réponses requises et pertinentes à partir de la base de connaissance, ouvrir un nouveau ticket ou commander un service nouveau ou modifié via le chat.
Le machine learning peut aussi catégoriser automatiquement, hiérarchiser et affecter des tickets ou même fournir des solutions recommandées, basées sur des modèles appris. Le machine learning permet également ChatOps et l’analyse fournissant ainsi des services informatiques plus efficients.

Seuls 8% des organisations ont déployées des agents virtuels ou AI Chat Bots *

Adopter ces bonnes pratiques avec Jira Service Management

Atlassian offre une solution modulaire qui couvre l’ensemble des fonctionnalités d’un ITSM à la pointe de la technologie. En effet, Atlassian a été classé leader dans The Forrester Wave : Enterprise Service Management, Q4 2021.

Cette solution modulaire permet de s’intégrer dans le paysage informatique des organisations et de s’appuyer sur les outils déjà en place.

En tant qu’expert Atlassian, AZARA Consulting vous accompagne dans la mise en place d’un ITSM fiable et résilient tout en s’intégrant avec le paysage du parc applicatif de votre organisation.

* Forrester Research, “The Total Economic Impact Of ITSM Applications” (2019)

L’article 5 Bonnes pratiques pour un ITSM fiable et résilient est apparu en premier sur AZARA Consulting.

DevOps est un ensemble de pratiques, d’outils et d’une culture philosophique qui automatise et intègre les processus entre les équipes de développement (change) et les équipes en charge des opérations (Run). Il met l’accent sur la responsabilisation des équipes, la communication et la collaboration entre les équipes et les technologies de l’automatisation.

Le mouvement DevOps a commencé vers 2007 lorsque les communautés les équipes Développement (Change) et les équipes Opérations (Run) informatiques ont soulevé des inquiétudes concernant le modèle de développement logiciel traditionnel, où les développeurs qui codaient travaillaient indépendamment des opérations qui déployaient et prenaient en charge le support post-déploiement. Le terme DevOps, qui est la combinaison des mots “développement” et “opérations”, reflète le processus d’intégration de ces disciplines en un seul processus continu.

DevOps est devenu l’approche de facto dans toute Software Factory, introduisant les principes Lean & Agile afin d’optimiser le Time-to-market : la chaîne de valeur entre la conception de l’application, sa mise en en service et sas maintenance.

Chaque membre de l’équipe doit collaborer et commencer à agir comme s’il était sur le même bateau

Une équipe DevOps comprend les équipes de développement (change) et les équipes en charge des opérations (Run) travaillant en collaboration tout au long du cycle de vie du produit, afin d’augmenter la vitesse et la qualité du déploiement des solutions informatiques. C’est une nouvelle façon de travailler, un changement culturel, qui impacte fortement les équipes et les organisations.

Dans un modèle DevOps, les équipes de développement et d’exploitation ne sont plus « cloisonnées ». Parfois, ces deux équipes fusionnent en une seule équipe pour travailler sur l’ensemble du cycle de vie de l’application – du développement et des tests au déploiement et aux supports – et disposent d’un éventail de compétences multidisciplinaires.

Passer au DevOps n’est pas une question d’outils mais une question de technologies et d’interaction humaine : Personnes > Processus > Outils.

Les équipes DevOps utilisent des outils pour automatiser et accélérer les processus, ce qui contribue à accroître la fiabilité. Une chaîne d’outils DevOps aide les équipes à aborder les fondamentaux DevOps importants, notamment l’intégration continue (Continuous Integration), la livraison continue (Continuous Delivery), l’automatisation et la collaboration.

Les valeurs DevOps sont parfois appliquées à d’autres équipes que celles de développement. Lorsque les équipes de sécurité adoptent une approche DevOps, la sécurité est une partie active et intégrée du processus de développement. C’est ce qu’on appelle DevSecOps.

Les phases du cycle de vie DevOps

En raison de la nature continue de DevOps, les praticiens utilisent la boucle infinie pour montrer comment les phases du cycle de vie DevOps sont liées les unes aux autres. Bien qu’elle semble s’écouler de manière séquentielle, la boucle symbolise le besoin d’une collaboration constante et d’une amélioration itérative tout au long du cycle de vie.

Le cycle de vie DevOps se compose de six phases représentant les processus, les compétences et les outils nécessaires au développement (sur le côté gauche de la boucle) et les opérations (sur le côté droit de la boucle). Tout au long de chaque phase, les équipes collaborent et communiquent pour maintenir l’alignement, la vélocité et la qualité.

Planifier

Les équipes DevOps doivent adopter des pratiques agiles pour améliorer la vélocité et la qualité. Agile est une approche itérative de la gestion de projet et du développement des applications qui aide les équipes à découper le travail en plus petits éléments pour offrir une valeur ajoutée.

Développer

Développer en se basant sur les outils de contrôle de version qui offre les fonctionnalités de gestion des branches, les fussions, la réécriture de l’historique du dépôt et de puissants workflows.

Intégrer et livrer continuellement
CI/CD permet aux équipes de publier des produits de qualité régulièrement et de façon prévisible, à partir du dépôt du code source vers la production avec des workflow automatisés. Les équipes peuvent fusionner fréquemment les modifications de code, déployer de nouvelles fonctionnalités et intégrer des tests de bout en bout.

Monitorer et alerter
Identifiez et résolvez rapidement les incidents qui affectent la disponibilité, le temps de réponse et le fonctionnement de l’application. Informez automatiquement votre équipe des changements, des actions à haut risque, afin que vous puissiez continuer à utiliser les services.

Exploiter
Gérer la livraison de bout en bout des services informatiques aux clients. Cela inclut les pratiques impliquées dans la conception, la mise en œuvre, la configuration, le déploiement et la maintenance de toute l’infrastructure informatique de l’organisation.

Améliorer continuellement
Les équipes DevOps doivent évaluer chaque version et générer des rapports pour améliorer les futures versions. En recueillant les feedbacks en continu, les équipes peuvent améliorer leurs processus et intégrer les feedbacks clients pour améliorer la prochaine version.

DevOps By Atlassian

Les outils DevOps traitent les phases clés du cycle de vie DevOps. Ils renforcent les pratiques DevOps en aidant à améliorer la collaboration, à réduire le changement de contexte, à introduire l’automatisation et à permettre le contrôle et le monitoring.

Les solutions d’outils DevOps suivent généralement deux approches : une solution d’outils tout-en-un ou bien une solution ouverte. Une solution d’outils tout-en-un est une offre complète qui ne s’intègre généralement pas avec d’autres outils tiers, tandis qu’une solution d’outils ouverte permet une personnalisation avec différents outils. Il y a des avantages et des inconvénients aux deux approches.

Un exemple de solution d’outils DevOps ouverte est la solution Open DevOps d’Atlassian, qui inclut Jira comme base et s’intègre avec les principaux fournisseurs et applications du marché.

Quels sont les avantages du DevOps ?

Dans l’enquête DevOps Trends 2020 d’Atlassian, 99 % des personnes interrogées ont déclaré que DevOps avait un impact positif sur leur organisation. Les avantages de DevOps incluent des livraisons plus rapides et plus simples, l’efficacité de l’équipe, une sécurité accrue, des produits de meilleure qualité et, par conséquent, des équipes et des clients plus heureux.

Vélocité

Les équipes qui pratiquent DevOps publient des livraisons de façon plus fréquente, de meilleure qualité et plus stable. En effet, le rapport DORA 2019 State of DevOps a révélé que les équipes d’élite se déploient 208 fois plus fréquemment et 106 fois plus rapidement que les équipes peu performantes. La livraison continue permet aux équipes de développer, tester et livrer des applications avec des outils automatisés.

Collaboration améliorée
La base du DevOps est une culture de collaboration entre les développeurs et les équipes opérationnelles, qui partagent les responsabilités et la charge de travail. Cela rend les équipes plus efficaces et permet de gagner du temps lié aux transferts de compétences

Déploiement rapide
En augmentant la fréquence et la vitesse des livraisons, les équipes DevOps améliorent rapidement les produits. Un avantage concurrentiel peut être obtenu en publiant rapidement de nouvelles fonctionnalités et en réparant les bugs.

Qualité et fiabilité
Des pratiques telles que l’intégration continue et la livraison continue garantissent que les modifications sont fonctionnelles et sûres, ce qui améliore la qualité d’une application. Le monitoring aide les équipes à rester informées des performances en temps réel.

Sécurité
En incorporant la sécurité dans le pipeline d’intégration continue, de livraison continue et de déploiement continu, DevSecOps est une partie active et indissociable du processus de développement. La sécurité est introduite lors du développement du produit à travers des audits de sécurité actifs et des tests de sécurité dans la démarche agile et les workflows DevOps.

Comment adopter le DevOps ?

L’adoption du Devops nécessite tout d’abord un engagement à revoir le dispositif existant : personnes, processus et outils. L’objectif est de mettre en place l’infrastructure requise pour permettre à l’équipe Devops d’être autonome dans la conception, le déploiement et la gestion des produits sans trop dépendre des équipes externes.

Nos équipes sont à votre disposition pour vous accompagner dans l’adoption de la démarche en fonction du niveau de maturité de votre organisation.

L’article DevOps : Briser le mur entre Dev et Ops, inculquer un nouveau mindset de collaboration et s’appuyer sur les technologies d’automatisation est apparu en premier sur AZARA Consulting.

Utiliser Trello et Confluence ensemble vous permet d’utiliser ces pièces pour illustrer une plus grande user story, d’organiser projet plus grand et de préparer un planning plus vaste. Mais comment les utiliser ensemble ? Utilisez Confluence pour créer et planifier votre vision, puis utilisez Trello pour travailler et agir sur les détails de l’éxécution de cette vision.

Pour en savoir plus sur la meilleure façon d’utiliser les deux applications, lisez la suite.

Ajouter des cartes ou des tableaux Trello aux pages Confluence

Confluence est l’endroit où vous construisez votre vision. Par contre, Trello vous permet de diviser cela en petites tâches est d’organiser leurs réalisations. Faites-les ensemble en intégrant vos cartes et tableaux de projets dans la documentation. 

En faisant ceci, vous obtiendrez :

• Une mise à jour en temps réel. Toutes les modifications apportées par vous, ou quelqu’un d’autre, à partir de l’un des outils de la suite Atlassian, seront immédiatement visibles. 

• Le respect des permissions. Avant de pouvoir voir une carte ou un tableau, on vous demandera de vous connecter à Trello. Tout contenu que vous n’avez pas la permission de voir affichera une note vous indiquant que vous n’avez pas encore l’accès nécessaire pour le voir.

Comment est-ce qu’on peut intégrer Trello à Confluence ?

Pour intégrer un tableau de projet Trello dans une page Confluence, c’est très simple. Copiez et collez l’URL de votre carte sur une page Confluence et regardez le rendu automatique dans une carte dès que la page est publiée.

Vous pouvez voir l’état de chacune de vos tâches, les commenter, vous abonner pour rester à jour sur les changements ou vous inscrire. Si vous avez besoin d’ajouter plus d’informations, il suffit de cliquer sur la carte. Cela vous mènera dans Trello, où vous pouvez modifier la carte comme d’habitude.

Cette possibilité d’intégration fonctionne également avec un tableau de projet. Les carreaux donnent un large aperçu de votre tableau, sans les détails approfondis. Utilisez-les pour garder le lien des documents ou des fichiers sur Confluence. Ensuite, lorsque votre équipe a besoin d’ajouter quelque chose à son tableau, elle peut cliquer sur le carreau pour l’ouvrir dans Trello.

Vous pouvez également ajouter des tableaux entièrement interactifs sur votre page Confluence. Choisissez le bouton “+” Trello Board, et après ajouter l’URL de la carte et la hauteur à laquelle vous voulez que votre carte soit embarquée. Cela affichera une carte de projet entièrement fonctionnelle sur votre page Confluence. De cette façon, vous pourriez déplacer les cartes d’une liste à une autre, ajouter ou modifier des détails et faire tout ce que vous feriez habituellement sur un tableau de projet, à partir de Confluence.

Ajouter des pages de Confluence aux cartes Trello

Évidemment, les intégrations vont dans les deux sens. En utilisant la puissance Confluence pour Trello, vous pouvez :

• Attacher les pages Confluence Cloud aux cartes des tâches et accéder à votre contenu depuis votre tableau en un seul clic
• Créer de nouvelles pages Confluence Cloud directement à partir des cartes.
• Voir toute l’activité sur votre page, qui a créé la page et quand elle a été créée, y compris un extrait et le nombre de commentaires sur la page, à partir de la carte Trello.

Quelques cas pratiques

Voici quelques exemples pratiques sur la façon d’utiliser Trello et Confluence ensemble de la manière la plus efficace :

• Gérer votre travail au sein de plusieurs équipes ou projets – Obtenez un aperçu du travail de vos équipes en intégrant chacune de leurs cartes de tâches sur une seule page Confluence. Idéal lorsque vous avez des équipes agiles et vous avez juste besoin de faire une vérification rapide sur les progrès de vos équipes.

• Faire un Brainstorming et partager des idées – Utilisez Confluence pour détailler un problème et des contraintes, puis utilisez Trello pour réfléchir aux solutions possibles.

• Planifier un projet avec Confluence – Ajoutez votre tableau de projet à la page de planification du projet afin que votre équipe et d’autres intervenants puissent suivre vos progrès.

• Créer de la documentation dans Confluence – Utilisez Trello pour planifier votre architecture d’information, afin de pouvoir déplacer des sous-sujets d’un sujet parent à un autre.

• Travailler sur des tâches – Conservez tous vos documents et fichiers connexes dans Confluence, et intégrez les cartes Trello correspondantes sur chaque page. Ensuite, lorsque vous faites des progrès, il suffit de commenter la carte Trello à partir de Confluence.

L’article Trello et Confluence : comment les utiliser ensemble ? est apparu en premier sur AZARA Consulting.

Qu’est-ce que Devops signifie ?

Les entreprises de logiciels deviennent de plus en plus importantes et omniprésentes dans la chaine de valeurs de toutes les entreprises. Dans ce contexte, les modèles traditionnels de développement ne résistent pas aux environnements à forte demande et à forte croissance.

Traditionnellement, les équipes Développement et Opérations ont l’habitude de travailler séparément dans des silos, ce qui entrave la capacité d’agir rapidement suite à des changements ou urgences opérationnelles. La réponse à cette relation litigieuse a été un mouvement appelé DevOps. C’est un terme fantaisiste pour une idée simple :

Une approche permettant de réunir deux fonctions clés de la DSI d’une entreprise chargée du développement d’applications. D’un côté, vous avez terme le “Dev” représentant les équipes de développeurs et de l’autre, vous avez le terme “Ops” représentant les équipes d’exploitation des systèmes d’information (Operations en anglais).

L’objectif de DevOps est que les équipes de développement et d’exploitation travaillent mieux ensemble.

Définition et objectif de DevOps

Voyons donc comment il est possible de créer une infrastructure devops avec Atlassian.

Outils pour la documentation

Si votre équipe travaille dans un environnement agile, il est important de fournir régulièrement des retours d’information et feedbacks aux équipes de développement. Pour ce faire, les interactions entre le Product Owner et les développeurs peuvent être facilitées de plusieurs façons.

Jira Software offre à l’entreprise plusieurs fonctionnalités intéressantes, notamment :

• Un Backlog Scrum où on est capable de peaufiner et de classer les Stories par ordre de priorité.
• La création et le lancement des Sprints en quelques clics.
• Des tableaux agiles qui s’adaptent à votre processus de développement.
• Des rapports détaillant le travail effectué (notamment les rapports de Sprint).

Dans tout cela, Confluence a un rôle très important. Il permet en effet de rendre le tout encore plus organisé. Vous n’aurez plus besoin de chercher parmi les piles de mails pour trouver les informations que vous recherchez, grâce à cette fonctionnalité. Tout les ressources sont centralisées sur Confluence et directement liées au projet de développement.

Outils pour lancer une release

Lorsque les développeurs, le Scrum Master et le Product Owner valident ensemble les fonctionnalités de la nouvelle version et acceptent de le livrer en production, c’est alors que nous parlons de « lancer une release ».

Dans cette phase l’équipe réalise simplement les manipulations suivantes :

• Créer une branche de diffusion de la branche de développement qui prend son nom à partir du numéro de version (par exemple : 2.5). Pour ce faire, il suffit de remplir des champs vides avec des informations utiles.

• Le même numéro de version dans la release du projet Jira relie toutes les Stories de ce sprint, et potentiellement le sprint précédent également s’il n’a pas été publié.

Les actions ci-dessus sont simples – il suffit de se faire guider par le processus de saisie des informations. Il est possible de définir la portée fonctionnelle de la version à la fois dans Jira et Bitbucket, facilitant ainsi le travail pour la documentation (où nous recommandons Confluence) et pour le Product Owner qui pourrait exécuter les tests. Si des anomalies sont détectées, elles peuvent facilement être inclus dans la même version.

Outils d’automatisation Devops pour le déploiement continu

Et voilà que l’outil Bamboo entre en jeu ! Grâce à l’intégration avec Bitbucket et Jira Software, nous pouvons automatiser plusieurs tâches rébarbatives qui prenaient beaucoup de temps pour les développeurs.

Construction du livrable (build) avec Bamboo

Pour gérer les builds des nouvelles version, Atlassian a opté pour une seule version avec un seul déploiement. Cela simplifie la configuration et rend ainsi l’utilisation et la gestion des versions plus gérable.

Dans ce plan de build, un script vérifie le type de branche sur lequel le commit a été réalisé et effectue certaines actions:

• La branche de développement agit comme la branche de base. À chaque commit, le plan de construction est lancé pour chaque commit afin de créer le livrable.
• Un plan est créé manuellement pour la branche master. Lorsqu’un commit est détecté sur cette branche, le livrable est créé et publié.
• Un plan est créé automatiquement pour chaque branche.  Une compilation du projet et un examen du code sont effectués après chaque commit sur une de ces branches.
• Un plan est créé automatiquement pour chaque branche de version et hotfix. Ces plans sont lancés manuellement par les développeurs pour créer le livrable.

Trouver les meilleurs outils Devops pour vos besoins

Il est crucial de disposer des bons outils Devops lors de la transition vers l’approche Agile, telles que : la livraison continue, le déploiement continu ou bien l’intégration continue. Et c’est sur ce point que la suite Atlassian excelle vraiment. Les intégrations entre les applications simplifient le processus tout entier. Indépendamment de l’évolution de vos besoins et de votre équipe, la documentation est toujours hébergée dans Confluence et liée à Jira. 

Tout au long du cycle de développement, le travail effectué sur l’ensemble des activités réalisé pour chaque User Story (code, build et déploiement) est enregistré en temps réel et de manière consistante et organisée. Tout peut donc être suivi et retrouvé sans effort, ce qui permet à chaque membre d’équipe d’orienter et de concentrer ses efforts sur son expertise métier et son rôle à jouer pour la réussite des projets.

Cependant, il n’y a pas de garantie qu’une méthodologie Devops sera adoptée, même lorsque les bons outils seront installés. Il est impératif de définir les processus appropriés que les outils et les gens mettront en œuvre. Cela repose sur une communication solide au sein de l’équipe, qui peuvent être facilitées par des ateliers Agiles et des rencontres périodiques avec tous les interlocuteurs concernés. Cela permet de résoudre rapidement les obstacles techniques et fonctionnels.

Concevoir et bâtir correctement votre infrastructure DevOps n’est en aucun cas une mission facile. C’est pourquoi AZARA Consulting est là pour vous aider. N’hésitez pas à nous contacter, nous serons ravis de vous rencontrer et de connaitre vos besoins pour vous accompagner dans votre aventure de transformation DevOps et Agile.

L’article DevOps : votre infrastructure grâce à Atlassian est apparu en premier sur AZARA Consulting.

Un monde de services

Commençons par un exemple que nous pouvons tous comprendre : pensez à votre smartphone dont vous ne vous séparez jamais. Bon nombre de vos applications et services sont très utiles voir indispensables en cette ère numérique actuelle. 

Nous sommes en train de passer de la création de produits à la création de services ! Il suffit de considérer la transition la transition qui s’est oppéré dans le monde de la mobilité : on est passé d’un monde où les gens étaient propriétaires de leurs voitures à un monde où plusieurs services comme Uber ou Heetch rendait possible la mobilité à la demande.

Les nouvelles générations ne voient pas la possession d’une voiture comme un symbole de statut. Au lieu de cela, ils sont à la recherche d’un moyen pratique pour se rendre d’un point A à un point B, et cela a des conséquences de grande portée pour chaque organisation et chaque équipe.

Réfléchissez à ce que ce paysage numérique en rapide évolution signifie pour les entreprises et les équipes informatiques chargées de fournir ces services. Pour réussir, chaque équipe informatique se concentre aujourd’hui sur les applications et les services numériques qu’elle fournit à ses clients.

Nous connaissons tous les histoires de la transformation incroyable des services numériques qui a eu lieu avec des entreprises comme Amazon, Google ou Airbnb.

Mais nous assistons également à une transition majeure pour les entreprises traditionnelles comme Macy’s, Marriott et ING, pour n’en nommer que quelques-unes. Les services numériques sont un aspect essentiel des produits et services historiques qu’ils offrent à leurs clients. Et ils ont dû évoluer très rapidement dans la façon dont ils sont commercialisés au risque de devenir obsolètes. 

Prenons un exemple : Marriott a 600 000 chambres et existe depuis 97 ans, tandis qu’Airbnb a 900 000 chambres et a été lancé il y a 8 ans. Ces changements ont une incidence sur la façon dont les équipes opérationnelles, logicielles et informatiques travaillent ensemble.

Les défis des outils ITSM pour les équipes IT

L’ITSM est l’optimisation de la prestation de services pour fournir de la valeur aux clients sous la forme de services. Les outils traditionnels de ITSM ont tendance à être lourds et rigides, sans possibilité de personnalisation, ce qui les rend difficiles à s’adapter aux besoins de plus en plus spécifiques des équipes IT. 

Il existe également des outils différents pour les divers processus informatiques qui créent des obstacles et un manque général de visibilité entre les équipes, ce qui finit par étouffer l’agilité, la collaboration et l’innovation. 

En outre, nous constatons souvent que le libre-service est déficient ou inexistant parce que les solutions ITSM traditionnelles rendent difficiles le déploiement et la gestion. Sans oublier que les utilisateurs finaux n’aiment pas les utiliser parce qu’elles ne sont pas intuitives.

Enfin, les outils ITSM traditionnels ne sont généralement pas intégrés aux outils de développement de logiciels. Ce qui rend le travail des équipes IT encore plus difficultés à cause d’au moins trois contraintes : 

• Incapacité de coordonner avec les équipes de développement.
• Difficulté de faire le lien entre les anomalies en production et l’avancement des corrections par l’équipe de développement.
• Absence de visibilité après avoir remonté des anomalies.

L’approche d’Atlassian dans l’ITSM

Comme chacun le sait, le processus est important pour les équipes informatiques. C’est pour cela que plusieurs frameworks et bonnes pratiques ont pour objectif d’apporter une « guideline » à l’ensemble des activités des équipes IT. Par exemple, ITIL (Information Technology Infrastructure Library) est considéré comme en est le pionnier.

Cependant, et malgré le fait que les équipes informatiques ont réalisé la valeur significative d’ITIL, ceux-ci trouvent que les outils classiques ITSM sont difficiles à adapter à leurs processus ITIL. Selon Doug Tire de la HDI Industry Insider, les clients qui se sont «sérieusement engagés à améliorer leur maturité en tirant parti de la librairie ITIL pendant une période de deux à trois ans ont vu une réduction de 50 à 75% du travail non planifié pour les services critiques, 10 à 25% de gains de productivité du travail et une amélioration de 20% dans les enquêtes de satisfaction client ». Cependant, le manque de compatibilité de l’ITIL et des outils hérités laisse aux équipes informatiques le sentiment de devoir modifier leur processus de support plutôt que d’avoir une solution informatique qui s’adapte à leurs besoins.

Les clients qui se sont «sérieusement engagés à améliorer leur maturité en tirant parti de la librairie ITIL pendant une période de deux à trois ans ont vu une réduction de 50 à 75% du travail non planifié pour les services critiques, 10 à 25% de gains de productivité du travail et une amélioration de 20% dans les enquêtes de satisfaction client »

Doug Tire de la HDI Industry Insider

L’approche d’Atlassian dans l’ITSM

Lorsque la plupart des organisations pensent à un « outil de centre d’assistance », elles ne font que « capturer » les incidents et les demandes de service de la part des clients. La gestion des problèmes et des changements nécessite généralement des modules distincts (et même des outils distincts), et les intégrations entre ces modules sont généralement loin d’être simples à réaliser. 

Au lieu de cela, Atlassian aborde l’ITSM en partant des besoins du projet et facilite la collaboration des équipes IT en temps réel. Grâce à cette approche axée sur les projets, les organisations disposent d’une solution unique où les équipes se concentrent sur leur cœur de métier tout en gardant leurs propres flux de travail, schémas de données, écrans et rapports, et tout en donnant une visibilité de bout en bout à la gestion des systèmes d’information. 

En plus de cela, Il n’y a pas de courbe d’apprentissage supplémentaire ni d’intégrations supplémentaires entre les modules. Vous pouvez créer des projets qui relient les tickets aux incidents qui y correspondent, et également aux demandes de changement. Un projet dans l’approche Atlassian représente donc une division logique des données et des processus pour aider les équipes IT à acquérir une organisation sans précédent.

Présentation de Jira Service Management

Jira Service Management est au cœur même de l’approche Atlassian de l’ITSM. Propulsé par la plateforme Jira, Jira Service Management est spécialement conçu pour les équipes IT et constitue le service desk le plus collaboratif du marché. Et pour appliquer les bonnes pratiques DevOps, Jira Service Management accorde une grande valeur à la transparence afin que les équipes puissent abandonner l’état d’esprit «silo» et adopter une communication ouverte et effiace entre ses membres. Grâce à cette approche, les équipes IT et celles du développement logiciel collaborent mieux et communique plus souvent pour résoudrre les problèmes plus rapidement. La raison est qu’ils disposent des bonnes pratiques et outils pour relier, suivre et automatiser la gestion des incidents plus facilement. Tout le monde a une visibilité complète sur la file d’attente et les meilleurs experts de chaque domaine peuvent collaborer à chaque fois pour résoudre les problèmes plus rapidement. En conséquence, les développeurs et les équipes d’infrastructure IT ont plus de temps pour se concentrer sur la conception et création de meilleurs logiciels et services.

Pourquoi les clients modernes utilisent Jira Service Management ?

Jira Service Management est également reconnu comme un leader des logiciels de centre de services par G2Crowd, devant les fournisseurs traditionnels tels que BMC et ServiceNow.

Voici les qualités qui expliquent pourquoi les entreprises adorent utiliser Jira Service Management ?

1. Facile à utiliser et à configurer : portail intuitif en libre-service, qui facilite la demande de support, la recherche dans les bases de connaissances et le suivi des progrès sur les anomalies et incidents.
2. S’intègre à Jira Software : associez les tickets Jira Service Management aux problèmes Jira Software et gardez le développement et le service informatique connectés pour une résolution rapide des problèmes.
3. S’adapte à vos besoins : un logiciel flexible qui en charge tous les types de résolutions, de remontées de niveau ou de processus de changement dont vos équipes informatiques pourraient imaginer.

L’article ITSM : Les meilleures pratiques d’Atlassian est apparu en premier sur AZARA Consulting.