En tant que membre de l’équipe delivery chez AZARA Consulting, votre rôle consistera à assister les consultants technico fonctionnels AZARA dans leurs projets de mise en place des solutions Atlassian.

Vos principales missions seront la configuration et l’intégration des applications Atlassian en fonction des modes opératoires élaborés par les consultants technico-fonctionnels.

Profil recherché

• Vous êtes parfaitement bilingue français et anglais.
• Vous avez étudié l’informatique.
• Vous êtes totalement autonome dans la réalisation de projets techniques.
• Vous souhaitez travailler dans le conseil, le support technique, le développement de logiciels.
• Vous avez de bonnes compétences en programmation (Java, Javascript, Groovy).
• Vous avez une bonne compréhension des méthodologies Agile et Devops
• Vous vivez pour la satisfaction du client et aimez l’autonomie

À propos de AZARA Consulting

Chez AZARA, nous accélérons la transformation digitale des entreprises en favorisant le travail d’équipe et l’état d’esprit collaboratif. Fondé par des consultants ayant acquis une forte expérience dans la conduite de projets d’envergures et guidé par une vision stratégique novatrice qui lui permet de se positionner de manière originale sur un marché du conseil en pleine mutation, AZARA réinvente les métiers du consulting en proposant à ses clients une approche efficiente dans la mise en œuvre de leurs projets, et à ses Consultants, un cadre professionnel qui repose sur l’établissement de rapports humains durables.

Si vous partagez nos valeurs, comme la qualité du service client, l’engagement envers les résultats et l’esprit d’équipe, ce poste pourrait représenter une opportunité exceptionnelle pour vous.

Poste basé à Oujda

Date limite de réponse

La date limite pour postuler est le 27/02/2026 avant 12h.

L’article Stage de pré-embauche Atlassian H/F [CONS-3624] est apparu en premier sur AZARA Consulting.

En tant que membre de l’équipe delivery chez AZARA Consulting, votre rôle consistera à assister les consultants technico fonctionnels AZARA dans leurs projets de mise en place des solutions Atlassian.

Vos principales missions seront la configuration et l’intégration des applications Atlassian en fonction des modes opératoires élaborés par les consultants technico-fonctionnels.

Profil recherché

• Vous êtes parfaitement bilingue français et anglais.
• Vous avez étudié l’informatique.
• Vous êtes totalement autonome dans la réalisation de projets techniques.
• Vous souhaitez travailler dans le conseil, le support technique, le développement de logiciels.
• Vous avez de bonnes compétences en programmation (Java, Javascript, Groovy).
• Vous avez une bonne compréhension des méthodologies Agile et Devops
• Vous vivez pour la satisfaction du client et aimez l’autonomie

À propos de AZARA Consulting

Chez AZARA, nous accélérons la transformation digitale des entreprises en favorisant le travail d’équipe et l’état d’esprit collaboratif. Fondé par des consultants ayant acquis une forte expérience dans la conduite de projets d’envergures et guidé par une vision stratégique novatrice qui lui permet de se positionner de manière originale sur un marché du conseil en pleine mutation, AZARA réinvente les métiers du consulting en proposant à ses clients une approche efficiente dans la mise en œuvre de leurs projets, et à ses Consultants, un cadre professionnel qui repose sur l’établissement de rapports humains durables.

Si vous partagez nos valeurs, comme la qualité du service client, l’engagement envers les résultats et l’esprit d’équipe, ce poste pourrait représenter une opportunité exceptionnelle pour vous.

Poste basé à Oujda

Date limite de réponse

La date limite pour postuler est le 15/08/2025 avant 12h.

L’article Consultant Technico-fonctionnel Atlassian H/F [CONS-3623] est apparu en premier sur AZARA Consulting.

Type de Contrat : Freelance

À Propos de Nous :

AZARA Consulting est un Partenaire Gold Atlassian reconnu pour son excellente expertise technique. Nous accompagnons nos clients à chaque étape de la mise en place des produits Atlassian (Jira Software, Jira Service Management, Confluence, Bitbucket, Trello, etc.). Notre mission est d’accélérer la création de valeur en optimisant l’efficacité et l’efficience des outils Atlassian au sein des organisations.

Description du Poste :

Nous recherchons un Spécialiste de la Génération de Leads dynamique et orienté résultats pour renforcer nos efforts de développement commercial. En tant que spécialiste indépendant, vous jouerez un rôle clé dans l’identification et la création de nouvelles opportunités commerciales pour nos services Atlassian.

Responsabilités Clés :

• Rechercher et identifier des clients potentiels via divers canaux, y compris les plateformes en ligne, les événements sectoriels et les réseaux professionnels.
• Utiliser des outils et des techniques de génération de leads pour développer un pipeline solide de prospects qualifiés.
• Élaborer des séquences de prospection personnalisées (e-mails, appels, réseaux sociaux) en adoptant une approche « test & learn ».
• Qualifier les prospects et planifier des rendez-vous pour l’équipe de vente, en assurant un flux constant de clients potentiels.
• Surveiller et analyser les performances des campagnes de génération de leads, en apportant des ajustements pour optimiser les taux de conversion.
• Fournir des rapports réguliers sur les activités de génération de leads et leurs résultats.

Exigences :

• Expérience avérée en génération de leads ou prospection commerciale, avec un historique de réalisation ou de dépassement des objectifs.
• Solide connaissance des outils de génération de leads et des meilleures pratiques du secteur.
• Excellentes compétences en communication écrite et orale.
• Grande organisation, souci du détail et capacité à travailler de manière autonome.
• La familiarité avec les produits et services Atlassian est un atout.
• La maîtrise de l’anglais est un plus.

Important : Si vous ne répondez pas à l’un des critères ci-dessus, nous vous invitons à ne pas postuler.

Comment Postuler :

Les candidats intéressés sont invités à soumettre les informations suivantes :

• Votre méthodologie pour la génération de leads.
• Quelques exemples de vos réalisations passées.
• Toute autre information pertinente démontrant votre adéquation avec ce poste.

Date limite de réponse

La date limite pour postuler est le 16/09/2024 avant 12h.

L’article Spécialiste de la Génération de Leads en Freelance [CONS-3622] est apparu en premier sur AZARA Consulting.

En tant que membre de l’équipe delivery chez AZARA Consulting, votre rôle consistera à assister les consultants technico fonctionnels AZARA dans leurs projets de mise en place des solutions Atlassian.

Vos principales missions seront la configuration et l’intégration des applications Atlassian en fonction des modes opératoires élaborés par les consultants technico-fonctionnels.

Profil recherché

• Vous êtes parfaitement bilingue français et anglais.
• Vous avez étudié l’informatique.
• Vous êtes totalement autonome dans la réalisation de projets techniques.
• Vous souhaitez travailler dans le conseil, le support technique, le développement de logiciels.
• Vous avez de bonnes compétences en programmation (Java, Javascript, Groovy).
• Vous avez une bonne compréhension des méthodologies Agile et Devops
• Vous vivez pour la satisfaction du client et aimez l’autonomie

À propos de AZARA Consulting

Chez AZARA, nous accélérons la transformation digitale des entreprises en favorisant le travail d’équipe et l’état d’esprit collaboratif. Fondé par des consultants ayant acquis une forte expérience dans la conduite de projets d’envergures et guidé par une vision stratégique novatrice qui lui permet de se positionner de manière originale sur un marché du conseil en pleine mutation, AZARA réinvente les métiers du consulting en proposant à ses clients une approche efficiente dans la mise en œuvre de leurs projets, et à ses Consultants, un cadre professionnel qui repose sur l’établissement de rapports humains durables.

Nous sommes fiers d’avoir été les 1er au monde à avoir formé +1000 utilisateurs dans +70 pays sur les outils. 

Si vous partagez nos valeurs, comme la qualité du service client, l’engagement envers les résultats et l’esprit d’équipe, ce poste pourrait représenter une opportunité exceptionnelle pour vous.

Date limite de réponse

La date limite pour postuler est le 16/09/2024 avant 12h.

L’article Stage de pré-embauche Atlassian H/F [CONS-3621] est apparu en premier sur AZARA Consulting.

Sous la direction du responsable des services , vous aurez à monter en compétence sur un outil interne afin de participer au développement de modules (plugins)..

Profil recherché

1. Vous êtes parfaitement bilingue français et anglais.
2. Vous étudiez l’informatique (de Bac+3 à Bac+5)
3. Vous justifiez d’une première expérience réussie en développement/algorithmie et conception d’applications
4. La connaissance de Python et du développement web sont un plus.

À propos de AZARA Consulting

Chez AZARA, nous accélérons la transformation digitale des entreprises en favorisant le travail d’équipe et l’état d’esprit collaboratif. Fondé par des consultants ayant acquis une forte expérience dans la conduite de projets d’envergures et guidé par une vision stratégique novatrice qui lui permet de se positionner de manière originale sur un marché du conseil en pleine mutation, AZARA réinvente les métiers du consulting en proposant à ses clients une approche efficiente dans la mise en œuvre de leurs projets, et à ses Consultants, un cadre professionnel qui repose sur l’établissement de rapports humains durables.

Nous sommes fiers d’avoir été les 1er au monde à avoir formé +1000 utilisateurs dans +70 pays sur les outils. 

Désireux de travailler au sein d’une équipe jeune et traitant des problématiques complexes et à forte valeur ajoutée? ce poste est donc pour vous.

Date limite de réponse

La date limite pour postuler est le 30/05/2024 avant 12h.

L’article Stage De Développement En Java [CONS-3630] est apparu en premier sur AZARA Consulting.

• En tant que membre de l’équipe delivery chez AZARA Consulting, votre rôle consistera à accompagner nos clients à travers toutes les étapes de leurs projets, depuis le recueil des besoins jusqu’au déploiement des solutions. En tant que Consultant Atlassian, vous serez directement supervisé par notre responsable des services et vous serez chargé de gérer plusieurs projets pour divers clients de manière autonome.
• Vos principales responsabilités incluront :
  • Analyser les besoins de nos clients, réaliser des audits techniques et fonctionnels, et leur fournir des conseils avisés.
  • Configurer et intégrer les applications Atlassian en fonction des besoins spécifiques et des exigences de chaque client.

Profil recherché

• Vous êtes parfaitement bilingue français et anglais.
• Vous avez étudié l’informatique.
• Vous êtes totalement autonome dans la réalisation de projets techniques.
• Vous souhaitez travailler dans le conseil, le support technique, le développement de logiciels.
• Vous avez de bonnes compétences en programmation (Java, Javascript, Groovy).
• Vous avez une bonne compréhension des méthodologies Agile et Devops.
• Vous vivez pour la satisfaction du client et aimez l’autonomie.

À propos de AZARA Consulting

Chez AZARA, nous accélérons la transformation digitale des entreprises en favorisant le travail d’équipe et l’état d’esprit collaboratif. Fondé par des consultants ayant acquis une forte expérience dans la conduite de projets d’envergures et guidé par une vision stratégique novatrice qui lui permet de se positionner de manière originale sur un marché du conseil en pleine mutation, AZARA réinvente les métiers du consulting en proposant à ses clients une approche efficiente dans la mise en œuvre de leurs projets, et à ses Consultants, un cadre professionnel qui repose sur l’établissement de rapports humains durables.

Nous sommes fiers d’avoir été les 1er au monde à avoir formé +1000 utilisateurs dans +70 pays sur les outils. 

Si vous partagez nos valeurs, comme la qualité du service client, l’engagement envers les résultats et l’esprit d’équipe, ce poste pourrait représenter une opportunité exceptionnelle pour vous.

Date limite de réponse

La date limite pour postuler est le 15/05/2024 avant 12h.

L’article Consultant Technico-fonctionnel Atlassian H/F [CONS-3620] est apparu en premier sur AZARA Consulting.

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.

• Participation à l’analyse et la conception des solutions
• Développement des écrans, états et programmes de gestion
• Tests unitaires des développements effectués
• Intervention lors de la phase d’intégration
• Assurer le développement des IHM Mobile à partir des maquettes fournies
• Participation à la phase de recette
• Correction anomalies
• Déploiement de solutions développées
• Gestion des versions

Nombre d’années minimum d’expérience 

• Avoir une expérience de 5 ans minimum de développement Mobile, et ayant participé à 3 projets au minimum de digitalisation des services

Compétences requises

• Excellente Maîtrise de l’outil Flutter
• Excellente Maîtrise du développement Hybride (Android & IOS)
• Excellente Maîtrise du langage JAVA
• Excellente Maîtrise du langage Kolín

Date limite de réponse

La date limite pour postuler est le 20/01/2023 avant 12h

L’article Développeur mobile [CONS-3596] est apparu en premier sur AZARA Consulting.