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

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

Burdown Chart

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

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

Le Burndown Chart s’applique uniquement aux tableaux Scrum.

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

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

Burnup Chart

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

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

Le Burnup Chart s’applique uniquement aux tableaux Scrum.

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

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

Sprint Report

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

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

Le Sprint report s’applique uniquement aux tableaux Scrum.

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

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

Velocity Chart

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

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

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

Autres points à noter concernant le Velocity Chart :

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

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

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

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

Cumulative Flow Diagram

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

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

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

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

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

Par exemple:

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

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

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

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

Version Report

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

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

Epic Report

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

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

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

Control Chart

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

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

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

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

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

Comment est déterminé le temps de cycle ?

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

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

Comment est calculée la moyenne mobile ?

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

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

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

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

Que représentent les points sur le graphique ?

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

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

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

Exemples de control chart :

Sur ce premier exemple :

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

Sur ce deuxième exemple :

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

Epic Burndown

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

L’Epic Burndown permet de :

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

Le graphique affiche les informations suivantes :

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

Release Burndown

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

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

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

Le graphique affiche les informations suivantes :

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

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

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

Les nouveaux filtres vous montrent les cartes qui sont :

•Actives au cours de la dernière semaine

•Actives au cours des deux dernières semaines

•Actives au cours des quatre dernières semaines

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

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

Partager les pages de Confluence sur Slack

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

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

Changements dans la publication de Confluence

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

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

Amélioration de la recherche rapide dans Jira Software

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

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

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

4.La requête intelligente va devenir optionnelle

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

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

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

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

Créer des tickets Jira à partir de Confluence

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

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

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

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

Nouvelle navigation des espaces dans Confluence

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

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

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

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

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

Jira Work Management Premium

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

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

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

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

Le thème sombre arrive au Data Center !

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

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

Liens publics dans Confluence Cloud

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

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

Jira Service Management Agent virtuel AI

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

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

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

Amélioration de la recherche rapide

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

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

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

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

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

Nouvelles fonctionnalités pour Bitbucket Cloud

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

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

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

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

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

Nouveau modèle pour Jira Cloud Automation

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

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

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

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

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

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

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

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

2023 Gartner Magic Quadrant pour DevOps

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

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

Mise à jour du Jira Work Management

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

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

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

Jira & ChatGPT – Tri des tickets avec l’IA

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

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

2.Exigences pour le tri automatique des tickets

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

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

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

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

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

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

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

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.

QU’EST-CE QUE LA GESTION DES TESTS ?
La gestion des tests est une méthode de planification, d’organisation, de contrôle et d’assurance de la traçabilité du processus de test logiciel afin de fournir des applications logicielles de haute qualité.

Alors que de plus en plus de développeurs adoptent les démarches agiles, les méthodes de test des produits évoluent. Au lieu d’exécuter des tests après la phase de mise en œuvre, les développeurs doivent commencer les tests durant les étapes initiales du développement. Cela permet de détecter et de résoudre les anomalies en amont et de réduire, par conséquent, la charge de leurs résolutions.

Etant donné que la méthodologie agile suit une approche continue et itérative, la gestion des tests doit s’aligner sur ce processus.

Les solutions de gestion des tests permettent de s’aligner sur ce processus en couvrant l’ensemble des étapes depuis la conception, le chiffrage et la planification à la recette jusqu’au déploiement.

La gestion des tests transforme le rôle du manager dans un environnement agile

Dans les processus de développement de logiciels traditionnels, les managers sont en charge de tâches telles que la revue et l’approbation des estimations, la tenue de réunions pour évaluer l’état d’avancement et la répartition des tâches.

Mais en démarche agile, les équipes sont autonomes et s’approprient les tâches. Les membres des équipes évaluent leurs propres estimations et se répartissent les tâches.

Ce gain en autonomie permet de libérer les managers pour se concentrer sur d’autres prérogatives telles que le développement des compétences des membres de l’équipe et la mise à disposition de l’ensemble des équipes de spécialistes des tests. Cela peut se traduire par la création d’un centre d’excellence permettant de partager les ressources et les bonnes pratiques entre les équipes.

La gestion des tests améliore la recette dans une démarche agile

La gestion des tests offre de nombreux avantages aux organisations utilisant le développement agile, notamment en leur permettant d’intégrer plus facilement les tests dans leurs processus. L’impact se voit sur trois aspects importants :

1. La minimisation de la duplication des données. Lorsque des équipes cloisonnées exécutent des tests, cela peut entraîner une duplication des données. Mais les outils de gestion des tests donnent à ces équipes une vue de bout en bout de tous les tests effectués et des anomalies identifiées, ce qui réduit la duplication des données car toutes les équipes peuvent partager la même vue.
2. L’amélioration de la couverture des tests. La réalisation de tests manuels à travers différents jeux de données et plusieurs itérations est généralement difficile et prend du temps en raison du large éventail de tests à effectuer. Et parce qu’il y en a tellement, il peut être difficile pour tout le monde de garder une trace de ce qui a été réalisé. Les solutions de gestion des tests facilitent le suivi de votre backlog.
3. La priorisation les tests. Il existe de nombreuses combinaisons à prendre en compte dans un processus de développement agile, vous devrez donc vous concentrer sur les zones à risque. Les solutions de gestion des tests simplifient l’identification des zones à risque en vous permettant de classer les facteurs de risque dans des champs personnalisés, par exemple la probabilité et l’impact, et de les hiérarchiser dans l’outil.

La gestion des tests rend les équipes agiles plus efficaces

La gestion des tests aide vos équipes à fonctionner plus efficacement en facilitant la collaboration. Cela correspond à l’une des valeurs fondamentales du Manifeste Agile : « Les individus et leurs interactions plus que les processus et les outils ».

La gestion des tests aide également les équipes de développement et d’assurance qualité à rester alignées en offrant une visibilité totale sur les différents jeux de test. Chacun a facilement accès aux informations dont il a besoin, quand il en a besoin.

La gestion des tests pour une meilleure prise de décision

Le processus de gestion des tests aide les organisations à prendre des décisions en se basant sur des éléments factuels, en particulier en matière de conformité réglementaire, en leur permettant de documenter les informations de test. Le fait d’avoir ces données disponibles rend les rapports de conformité plus rapides et plus faciles.

Les outils de gestion des tests peuvent également vous aider à décider quand mettre en production la solution en suivant l’état d’avancement des développements.

Les bons outils de gestion de tests pour votre équipe agile

La bonne solution pour votre équipe dépend de vos besoins, de vos produits et de votre budget. Si votre processus de développement logiciel est géré dans Jira, des applications de gestion des tests sont disponibles pour simplifier le processus dans toute votre organisation. Nos équipes sont à votre disposition pour vous accompagner dans le choix de la solution qui répond le mieux à votre besoin.

L’article Les méthodes et les pratiques de testing dans une démarche agile est apparu en premier sur AZARA Consulting.

Avant le COVID-19, la pression imposée par les évolutions du marché et les avancées technologiques poussait les organisations à gérer le changement et à prendre les décisions rapidement. La pandémie du COVID-19 a considérablement intensifié cette pression. Les entreprises de toutes tailles sont contraintes d’adapter leurs Business Modèles à des exigences évolutives. Cette tendance n’est pas éphémère : la digitalisation, l’automatisation, l’intelligence artificielle et autres facteurs de changement ne vont que s’accentuer.

En réponse à cette pression, les grandes structures adoptent l’agilité à l’échelle afin de survivre et prospérer dans ce monde volatil, incertain, complexe et ambigu. L’agilité à l’échelle réorganise l’entreprise en un ensemble d’équipes hautement performantes, chacune avec les profils et les compétences requis et un objectif clair à atteindre. Au début de l’agilité, ces équipes, souvent appelées squads, associant développeurs, testeurs, data analystes, experts du parcours client et concepteurs d’interfaces utilisateur, intervenaient exclusivement dans le périmètre restreint de la Digital Factory de l’entreprise. Des modèles similaires ont émergé depuis dans d’autres secteurs d’activités et domaines technologiques. Des squads sont constitués dans la grande distribution autour de catégories de produits spécifiques (par exemple, des aliments frais) pour augmenter le volume et la marge. Les opérateurs télécommunications mettent en place des squads pour simplifier les offres de service. De même, les sociétés minières travaillent sur l’amélioration de la sécurité et de l’efficacité en responsabilisant des squads constitués des différentes directions Opérations, Maintenance et Ingénierie. Les entreprises de tous secteurs recherchent à optimiser leurs performances en s’appuyant sur des squads constitués de membres appartenant à des fonctions cloisonnées.

Pour réussir une démarche d’agilité à l’échelle, les squads doivent tous converger vers la même direction. Cette cohésion se construit en partageant la même culture, la même vision et les mêmes priorités. Lorsque des entreprises comptent des centaines de squads, il devient important de partager avec eux les orientations à travers d’événements réguliers tel que les revues d’activités trimestriels (Quarterly Business Review). Cette réussite repose aussi sur la capacité des managers à développer de nouveaux états d’esprit, d’adopter la démarche et de faire adhérer leurs équipes.

Évaluation de l’efficacité de la démarche
Une étude a été réalisée par le cabinet McKinsey and Compagny sur un échantillon de 25 entreprises dans 7 secteurs différents qui ont adopté ou adoptent actuellement une transformation agile. Selon leurs auto-évaluations, toutes les Business Units agiles ont mieux réagi que celles non agiles aux chocs causés par la pandémie de COVID-19 sur le plan de la satisfaction client, l’engagement des employés ou la performance opérationnelle (Graph1).

Graph1 : Auto-évaluation des performances des Business Units Agiles par rapport à celles non agiles (25 entreprises)

Selon la même étude, il ressort que les équipes agiles ont poursuivi leur travail de manière presque transparente après le choc, sans recul substantiel de la productivité. En revanche, de nombreuses équipes non agiles ont eu du mal à effectuer la transition, à redéfinir les priorités de leur travail et à être productives dans la nouvelle configuration à distance. L’alignement entre les backlogs des équipes agiles et leurs priorités commerciales leur a permis de se réinventer rapidement.

Les éléments d’une réponse réussie
La plupart des organisations, agiles ou non, ont connu un rythme de prise de décision plus rapide à mesure que les réalités de la pandémie de COVID-19 évoluaient. Sous l’immense pression de mettre en place très rapidement une infrastructure d’exploitation pour permettre à des centaines voir des milliers d’employés de travailler à distance, de nombreuses organisations ont abandonné leurs procédures et la bureaucratie traditionnelles pour se focaliser sur des résultats plus rapides. Les priorités sont devenues claires et l’effort a été concentré sur ce qui devait être fait à très court terme, car de nombreuses organisations sont passées en mode survie.

Les outils de travail en équipe
Les outils de travail en équipe ont permis aux équipes de rester regroupé et concentré sur leurs sujets pour que le travail se déroule dans les délais. Même les organisations et unités non agiles ont fait appel à de telles pratiques en réaction à la crise. Ils comprenaient un ensemble de cérémonies qui permettaient aux équipes de maintenir leur rythme, même si les priorités changeaient rapidement et que les membres de l’équipe n’étaient plus colocalisés. Ces cérémonies ont donné aux équipes des instances pour une prise de décision efficace et rapide au fur et à mesure que les priorités évoluaient. Certaines entreprises ont augmenté la fréquence des cérémonies, en doublant la cadence des sessions de contrôle d’état d’avancement des tâches, par exemple, ou en réduisant de moitié la durée de leurs sprints pour mieux faire face à l’évolution des priorités. Cela a assuré une meilleure communication au sein de l’équipe et a permis des interactions sociales régulières. Les outils de collaboration à distance ont ensuite permis aux équipes de continuer à travailler ensemble et de suivre leurs progrès en toute transparence, même en travaillant à distance.

A quoi ressemble une journée type de travail à distance ?

L’article Agilité à l’heure du COVID-19 : Faire évoluer le modèle opérationnel à l’ère des turbulences est apparu en premier sur AZARA Consulting.

Les deux ont des avantages et des inconvénients selon le contexte du projet :
Quand est ce que l’approche agile est plus adaptée ?
La méthode Agile (scrum ou kanban) a tendance à mieux fonctionner dans un projet où :

• Il existe un niveau d’incertitude relativement élevé et une approche flexible et adaptative est nécessaire pour résoudre l’incertitude au fur et à mesure que le projet avance.
• La créativité et l’innovation sont nécessaires pour maximiser la valeur pour le client.

Quand est ce que l’approche classique est plus adaptée?
Un modèle classique basé sur un plan a tendance à mieux fonctionner dans un projet où :

• Il existe un niveau d’incertitude relativement faible, la solution est bien définie et un certain niveau de planification et de contrôle sont nécessaires
• L’organisation n’est pas préparée à mettre en œuvre une approche Agile et/ou l’équipe projet n’est pas formée à l’Agile

Ci-dessous, quelques axes de réflexion pour vous permettre de choisir la méthodologie qui répond le mieux au contexte de votre projet :

Quel est le niveau d’incertitude?

Est-ce que les spécifications des fonctionnalités sont détaillées et connues?

Est-ce que le besoin risque de subir un changement durant la phase projet?

Il sera nécessaire de faire beaucoup d’hypothèses pour essayer de résoudre l’incertitude ; et ces hypothèses peuvent être erronées et nécessitent beaucoup de replanification et de Rework.
Un projet classique axé sur la planification et le contrôle n’est pas propice aux changements. Il n’est pas adapté à l’optimisation de valeur de la solution dans un environnement incertain.

Quel est le niveau de besoin en termes de créativité et d’innovation?

Est-ce que le projet nécessite de la créativité et de l’innovation?

Exemples :
Développement d’une nouvelle solution innovante
Evolution d’un ERP existant selon un moule prédéfini

Une approche fortement axée sur la planification et le contrôle peut étouffer la créativité et l’innovation.

Quel est le type de relation avec le client interne?

Quelle est la nature de la relation avec le client interne?

La nature de la relation client peut varier entre :

• Relation contractuelle
  Les attentes des clients sont précises et bien définies. Le client définit les exigences et attend de l’équipe de projet qu’elle fasse tout ce qui est nécessaire pour répondre à ces exigences. Dans ce style de relation, la participation du client au projet est limitée et le niveau d’incertitude est relativement faible. Il sera nécessaire de définir les exigences du client dans le détail avant le début du projet. « 
• Relation collaborative
  L’équipe projet et le client jouent un rôle actif dans la définition de l’orientation du projet au fur et à mesure de son avancement.

Aptitudes de l’équipe projet

Est-ce que l’équipe projet est en mesure de mener un projet Agile?

Une approche Agile nécessite une équipe formée aux principes, rituels et outils de la méthodologie.

L’article Choix de la méthodologie projet : Agile vs Cycle en V est apparu en premier sur AZARA Consulting.

1 – Pour la gestion des exigences et des scénarios de test

Un nombre croissant d’équipes se développent aujourd’hui de manière plus itérative et agile. Dans ce contexte, Jira Software est la pierre angulaire pour gérer toutes les phases de développement, de collaboration et de livraison. Pour la gestion des tests, Jira s’intègre avec une variété de fonctionnalités afin que les tests de l’Assurance Qualité (AQ) s’incorporent parfaitement dans le cycle de développement logiciel. 

Les équipes peuvent effectuer des tests de façon efficace et itérative. Les équipes QA utilisent Jira à travers des visuels personnalisés comportant des champs et des flux adaptés pour gérer les tests manuels et automatisés.

 2 – Pourquoi utiliser Jira pour faciliter l’agilité des équipes

Pour les équipes agiles, Jira Software fournit clé en main des outils innovants pour supporter vos activités et rituels Scrum et Kanban. Les tableaux agiles qu’il offre sont des centres de gestion des tâches, où les tâches sont mappées à des flux de travail personnalisables. 

Les tableaux de bord de Jira assurent la transparence du travail d’équipe et la visibilité de l’état de chaque tâche et développement en cours . Les capacités de suivi du temps et les rapports de performance en temps réel permettent aux équipes de mesurer de très près leur productivité au fil du temps. 

Nous allons maintenant découvrir pourquoi utiliser Jira pour le suivi de projet

 3 – Pour la gestion de projet efficace

Jira Software Cloud peut être configuré pour s’adapter à n’importe quel type de projet. Les équipes peuvent commencer avec un modèle de projet ou créer leur propre flux de travail personnalisé. Les tâches de Jira permettent de suivre de chaque lot qui doit passer par les étapes du flux de travail jusqu’à l’achèvement.

Les accès personnalisables en fonction des rôles de chaque membre de l’équipe permettent aux administrateurs de déterminer qui peut voir et exécuter quelles actions. Une fois tous les renseignements sur le projet en place, des rapports périodiques peuvent être produits pour suivre les progrès, la productivité et le respect des délais de livraison.

4 – Pour le développement de produits logiciels innovants

Jira Software Cloud fournit des outils de planification et de gestions de roadmap afin que les équipes puissent gérer dès le premier jour et de manière autonome : 

• La collaboration entre les parties prenantes
• Les budgets
• Les besoins en fonctionnalités. 

Jira facilite la transparence tout au long du cycle de développement du logiciel. Lorsqu’un produit logiciel est prêt à être déployé, les informations sur l’état du code de production apparaissent en direct dans Jira. En outre, les outils intégrés de « versionning » et de « flagging » des fonctionnalités permettent aux équipes de déployer de nouvelles briques logicielles graduellement et en toute sécurité.

5 – Pourquoi utiliser Jira pour la gestion de produits logiciels

Dans les templates nouvelle génération de Jira Software Cloud, les équipes peuvent créer une roadmap personnalisée associée à chaque projet. Elle permet aux équipes :

• D’esquisser la vision à long terme de leur travail.
• De suivre et de partager les progrès de leur feuille de route. 

Il est important d’ajouter le maximum de détails dans les roadmap Jira afin d’identifier les dépendances et les prévisions quant au moment où vous pourriez terminer chaque lot de travail.

Finalement, pour avoir un résultat encore meilleur, créez une vue mettant en évidence les feuilles de route « en direct » de plusieurs équipes en intégrant la feuille de route du logiciel Jira dans Confluence.

6 – Pourquoi utiliser Jira pour la gestion des tâches

Jira vous permet de créer des tâches pour vous et les membres de votre équipe de la manière la plus optimale qu’il soit. Lors de la création de tâches, on peut tout spécifier avec les détails, les dates d’échéance et les rappels. Il est aussi possible d’utiliser des sous-tâches au sein de la tâche mère pour décortiquer les tâches les plus conséquente et donc pouvoir suivre son avancement de manière granulaire. De cette façon, on parviendra à décomposer l’unité de travail en morceaux digestibles pour divers membres de l’équipe.

7 – Pour le suivi des anomalies

Jira vous permet de créer des demandes de correction d’anomalies afin d’apporter des correctifs aux problèmes constatés au sein d’un produit logiciel en cours de développement. Il est important que les équipes voient toutes les tâches et toutes les demandes de corrections afin de pouvoir établir des priorités pour les objectifs généraux. 

Le système de workflow de Jira garantit que les anomalies soient automatiquement assignés et hiérarchisés une fois qu’ils sont saisies. Les équipes peuvent ensuite suivre une anomalie jusqu’à la fin.

L’article Pourquoi utiliser Jira : 7 bonnes raisons est apparu en premier sur AZARA Consulting.

Les origines de la méthode Agile

La méthode agile, ou “Lightweight méthodologie », est née dans le domaine IT au milieu des années 90, en opposition à la méthode dite Heavyweight. C’est une méthode innovante basée sur l’interaction continue avec les utilisateurs et clients. La satisfaction de ces derniers est en effet déterminante pour la réussite du projet et pour le développement de l’organisation.

Depuis, au printemps 2000, un groupe de 17 développeurs de logiciels se sont rencontrés en Oregon pour discuter de la façon dont ils pourraient accélérer les temps de développement afin de mettre de nouveaux logiciels sur le marché plus rapidement. 

Ils ont reconnu deux possibilités clés qui permettraient d’atteindre cet objectif :

• raccourcir le délai des bénéfices pour les utilisateurs afin de résoudre les problèmes d’ajustement et de développement du marché des produits
• obtenir rapidement la rétroaction des utilisateurs pour confirmer l’utilité des nouveaux logiciels et continuer de les améliorer en conséquence.

Comment fonctionne la méthode Agile ?

Au lieu de tout miser sur un lancement « big bang » dans le cadre d’une approche « en cascade » (waterfall), une équipe agile livre le travail en petits incréments représentant une fonctionnalité utilisable par le client. Les exigences, les plans et les résultats sont évalués continuellement afin que les équipes disposent d’un mécanisme naturel pour réagir rapidement au changement.

La méthode agile fait appel à des équipes multidisciplinaires collaboratives. Ses principales caractéristiques sont les suivantes : 

• La communication ouverte.
• La collaboration.
• L’adaptation.
• La confiance entre les membres de l’équipe.

Bien que le chef de projet ou le propriétaire de produit priorise habituellement les lots à livrer, l’équipe prend la tête pour décider des choix techniques pour développer les fonctionnalités. L’équipe « s’auto-organise » pour affecter les tâches d’une manière granulaire.

L’agilité n’est pas définie par un ensemble de cérémonies ou de techniques de développement spécifiques. Agile est plutôt un groupe de méthodologies qui démontrent l’engagement de l’équipe dans des cycles de rétroaction courts et de l’amélioration continue.

La clé pour bien faire preuve d’agilité est d’adopter un état d’esprit d’amélioration continue. Expérimentez différentes pratiques et ayez des discussions ouvertes et honnêtes à leur sujet avec votre équipe. Gardez ceux qui fonctionnent, et jetez ceux qui ne fonctionnent pas.

Pourquoi choisir cette méthode ?

Les équipes choisissent l’agilité pour pouvoir réagir rapidement :

• Aux changements du marché
• Aux feedbacks des clients sans faire dérailler les plans d’une année. 

La planification et la livraison du « juste assez » par petites étapes permet à votre équipe de recueillir des feedbacks de la par des utilisateurs sur chaque changement et de les intégrer aux plans futurs à un coût minimal.

Mais l’agilité n’est pas seulement un jeu de nombres, c’est lié encore plus à l’aspect humain des projets. Les interactions humaines authentiques sont plus importantes que les processus rigides. La collaboration avec les clients et les coéquipiers est plus importante que les arrangements prédéfinis. Et fournir une solution de travail au problème du client est plus important que la documentation hyper-détaillée.

Une équipe agile s’unit sous une vision commune, puis la concrétise de la manière la plus adéquate. Chaque équipe établit ses propres normes de :

• Qualité
• Convivialité
• Exhaustivité. 

Le critère du « definition of done » définit les critères établis par l’équipe et déterminant si une fonctionnalité peut être considérée comme réalisés. Bien que cela puisse être effrayant au début, les dirigeants d’entreprise trouvent que lorsque les équipes adoptent l’esprit agile, ils ont de plus en plus confiance en eux, car ils ressentent plus de responsabilité. Ce sentiment augmente la qualité des produits réalisés et les aide à dépasser les attentes de la direction.

Le Manifeste Agile

La publication du Manifeste Agile en 2001 marque la naissance de l’agile comme méthodologie. Depuis, de nombreux frameworks agiles sont apparus comme :

• Scrum.
• Kanban.
• Lean.
• Extreme Programming (XP). 

Chacun incarne à sa façon les principes fondamentaux d’agile : itérations fréquentes, apprentissage continu et la haute qualité. Scrum et XP sont favorisés par les équipes de développement de logiciels, tandis que Kanban est préféré par les équipes orientées services comme l’informatique ou les ressources humaines. 

Aujourd’hui, de nombreuses équipes agiles combinent des pratiques de frameworks différents, augmentées de pratiques propres à l’équipe. Par exemple, si vous faites partie d’une équipe axée sur les mécanismes de files d’attente comme le support informatique, Kanban fournit une base solide pour votre pratique agile. Mais rien ne devrait vous empêcher de piocher dans quelques pratiques de Scrum comme : 

• Des séances de démonstration avec les parties prenantes.
• Des rétrospectives régulières.

Les équipes agiles de demain valoriseront leur propre efficacité plutôt que l’adhésion à la doctrine. L’ouverture, la confiance et l’autonomie émergent comme les bases de la culture des entreprises qui veulent attirer les meilleures personnes et réaliser les meilleurs produits. Ces entreprises prouvent déjà que les pratiques peuvent varier d’une équipe à l’autre, à condition qu’elles soient guidées par les bonnes pratiques de l’agilité.

L’article Agile : un Must Have pour vos équipes est apparu en premier sur AZARA Consulting.

Méthode agile Scrum  : c’est quoi ?

La méthode agile, ou “Lightweight methodologie”, est née dans le domaine IT au milieu des années 90. Elle était en opposition à la méthode dite Heavyweight. C’est une méthode innovante basée sur l’interaction continue avec les partenaires. Leur satisfaction est en effet déterminante pour la réussite du projet et pour le développement de l’organisation.

Scrum est la méthode agile la plus répandue, particulièrement adaptée aux projets complexes et innovants. La méthode agile SCRUM est un cadre de travail ou framework largement utilisé dans les équipes de développement de solutions logiciels. Cette méthodologie permet en même temps d’apporter un cadre de management souple et d’assurer 3 valeurs piliers de la méthode : la transparence, la visibilité en permanence et l’adaptation aux changements. 

Ce qui permet à une équipe adoptant Scrum de lancer rapidement un produit digital sur le marché. En d’autres termes, cela permet d’avoir un ‘time to market‘ très court par rapport aux autres méthodologie de gestion de projet. Ce qui aide à obtenir rapidement des ‘feedbacks’ d’utilisateurs réels et de pouvoir apporter les corrections et améliorations en fonction des besoins. Le temps est l’élément clé et le plus important dans la méthode Scrum. La méthode agile Scrum se base sur des sprints pour maitriser l’élément du temps et les ‘deadlines’.

La signification de Scrum

« Scrum » est un mot anglais qui traduit « Mêlée. C’est un terme utilisé dans le rugby pour représenter l’objectif commun de l’équipe d’obtenir la possession de la balle et d’avancer ensemble dans une seule direction de manière cohérente et solidaire. Disons que c’est un peu ce qui se passe dans la méthode agile SCRUM. L’équipe de développement travaille ensemble pour atteindre un ou plusieurs objectifs à la fin du Sprint/Itération. C’est l’un des concepts importants de la méthode agile SCRUM.

Les objectifs fondamentaux de la méthode agile Scrum ?

Dans le cadre des méthodologies agiles, l’objectif de Scrum est d’assurer les aspects suivants pour favoriser la réussite des projets : 

• La flexibilité dans l’adoption de changements et de nouvelles exigences au cours d’un projet complexe.
• L’importance du facteur humain.
• La collaboration et l’interaction avec le client.
• Le développement itératif comme moyen d’assurer de bons résultats.

Les piliers de la méthode agile Scrum

La méthode agile SCRUM se base sur 3 piliers importants :

• Transparence. Grâce à la méthode agile Scrum, toutes les personnes impliquées ont une vision claire de toutes les tâches et actions du projet. Il en résulte une compréhension « commune » du projet, une vision globale unifiée.

• Inspection. Les membres de l’équipe Scrum peuvent vérifier régulièrement et facilement les progrès accomplis pour détecter les problèmes éventuels. L’inspection n’est pas un examen quotidien. Par contre, elle est un moyen de s’assurer que le travail avance sereinement, que l’équipement fonctionne de manière autoorganisée et d’anticiper les problèmes de qualité et délai avant qu’ils se produisent.

• Adaptation. La capacité à s’adapter facilement aux changements dans les spécifications et la structure de l’équipe. C’est la clé du succès dans des projets complexes, où les exigences changent souvent et où l’adaptation, l’innovation, et la flexibilité sont essentielles.

L’utilisation de sprints dans la méthode agile SCRUM

Les sprints sont de brèves périodes temporelles dans lesquelles l’équipe de développement travaille pour la sortie d’une ou plusieurs fonctionnalités. On appelle ceci un lot de fonctionnalité ou un backlog. Généralement un sprint compte de 2 à 4 semaines. À l’adoption de la méthodologie, l’équipe se met d’accord sur la durée du sprint en fonction du rythme de livraison voulu et de la réactivité de l’équipe. Il est conseillé de commencer par des sprints de 4 semaines lorsqu’on débute dans la méthode Scrum, afin d’avoir le temps de s’y habituer et d’adopter les différents rituels et bonnes pratiques Scrum.

Pendant le sprint, l’équipe a pour objectif de créer un « incrément », un produit/fonctionnalité, même non fini, qui a une valeur ajoutée. L’évaluation des objectifs et des résultats a lieu au cours du sprint review, une réunion à laquelle participent tous les membres de l’équipe Scrum. L’équipe reçoit des « feedbacks », commentaires positifs ou négatifs des parties prenantes concernées. Ces retours sont notés et transformées en demandes de corrections/améliorations qui seront ajoutées aux sprints suivants.

Les avantages de la méthode agile SCRUM

Au cours des dernières années, cette méthodologie a été de plus en plus utilisée, devenant désormais l’une des plus répandues parmi les équipes de développement de produits digitaux ou même physiques. Les processus et les principes qui la régissent la rendent avantageuse pour tout système d’entreprise qui se retrouve confronté à la gestion de projets innovants et complexes. Cette méthode a été adoptée pour des projets allant du développement d’un simple logiciel à la migration vers le cloud de l’infrastructure complète d’une entreprise.

Les avantages de la méthode agile Scrum sont très nombreuses. Ils varient en fonction des rôles et des points de vue.

Les avantages pour le client sont en termes de facilité de gestion :

• Communication facile avec les différentes équipes.
• Une planification et un suivi plus efficace.
• Résolution plus rapide des anomalies.
• Une vue d’ensemble claire de l’état général du projet à tout moment.
• Possibilité d’adapter facilement les exigences des produits en fonction de la stratégie générale de l’entreprise.

Les avantages pour l’équipe sont surtout en terme d’autonomie et de mise en confiance :

• Responsabilisation de chaque membre de l’équipe.
• Visibilité de l’efficacité du travail accompli et des retours client.
• L’autonomisation qui en résulte.

Les avantages pour les équipes d’exploitation IT sont en termes de fluidité de déploiement des produits digitaux :

• Amélioration de la vitesse d’exécution.
• Moins de dispersion des ressources.
• Amélioration de la relation avec les utilisateurs des solutions.
• Meilleure satisfaction finale des clients.

L’article La méthode agile Scrum et son importance pour votre équipe est apparu en premier sur AZARA Consulting.