Gestion des releases > Analyser une release

Analyser une release

Agile Manager met à votre disposition divers outils d'analyse pour contrôler l'avancement et la qualité d'une release.

Widgets de la page Backlog de release

Utilisez les widgets situés en haut de la page Backlog de release pour connaître les statuts des user stories et des anomalies. Les graphiques s'appliquent aux éléments dans le filtre actuel.

Tableau de bord du gestionnaire des releases

Sur le Tableau de bord, sélectionnez le favori Tableau de bord du gestionnaire des releases. Il contient les widgets suivants :

Widget Description

Burn down de la release

Ce widget affiche le nombre de story points restants pour réaliser le backlog de release, en comparaison avec la capacité disponible à différents stades de la release.

La ligne diagonale droite indique la capacité restante (en heures) jusqu'à la fin de la release.

La ligne courbe indique le nombre d'heures de tâches restantes dans la release.

  • Si la ligne courbe se trouve au-dessus de la ligne droite, l'équipe a pris du retard.
  • Si la ligne courbe se trouve en dessous de la ligne droite, l'équipe a pris de l'avance.

Vélocité du groupe

Ce widget affiche le nombre de story points réalisés par le groupe dans chaque sprint, en comparaison avec la sortie de sprint moyenne du groupe.

Il peut être intéressant d'analyser les sprints avec une vélocité sensiblement différente à la vélocité moyenne.

Diagramme de flux cumulé des anomalies de release

Ce widget affiche le nombre d'anomalies affectées au groupe, groupées par statut, à différents stades de la release. Chaque bande indique le nombre de user stories dans un statut.

Les tendances idéales de ces graphiques et de chacun de leurs statuts sont les suivantes :

Total

Dans une release idéale, la forme du graphique doit être quasi rectangulaire, bien qu'il puisse y avoir une augmentation des nouveaux éléments au début de la release.

Au début de la release, la hauteur du graphique dépend principalement du nombre de nouveaux éléments. À partir de ce point, les éléments planifiés passent par différents statuts jusqu'à ce qu'ils soient tous terminés.

Nouveau En règle générale, tout nouveau contenu doit être planifié au début de la release. Les augmentations dans la bande Nouveau représentent les user stories ayant été ajoutés pendant la release. Cette bande doit se rétrécir à mesure que les user stories passent au statut En cours.
En cours Le nombre de user stories En cours doit être plus ou moins constant. L'équipe doit progressivement fermer les user stories et les déplacer vers le statut En cours de test avant de commencer utiliser d'autres éléments.
En cours de test La progression de la bande En cours de test doit être similaire à celle de la bande En cours, avec un léger décalage. Pour assurer un flux d'éléments graduel entre le statut En cours et le statut En cours de test, l'équipe doit tenter de réaliser plusieurs petits user stories peu après le début de chaque sprint.
Terminé La bande Terminé doit croître régulièrement tout au long de la release, jusqu'à prédominer dans le graphique vers la fin de la release.
Diagramme de flux cumulé du backlog de release Ce widget affiche le nombre de user stories et anomalies affectés au groupe, groupés par statut, à différents stades de la release.

Pour une rétrospective de la planification de la release, ouvrez la galerie de widgets, puis sélectionnez des widgets dans la catégorie Rétrospective.

Analyses ALI

Pour une présentation de la qualité de la release basée sur le code source et les informations de build, ouvrez la page Gestion des releases > Récapitulatif ALI.

Pour plus d'informations, reportez-vous aux sections ALI Release Summary et ALI Applications Summary.