Découvrez le processus utilisé pour gérer les efforts de développement de produit dans Agile Development 2.0, tels que la création d'un produit, ou le suivi d'un sprint ou d'une mise en production.

Définir des produits

Un produit peut être un ensemble de caractéristiques ou de fonctionnalités offertes aux utilisateurs. Chaque produit peut avoir un propriétaire qui gère le pipeline de travail, comme les épopées et les stories, pour le produit. Ces éléments de travail peuvent être associés à un thème, lui-même associé à un objectif business.

Voir Créer un produit dans Agile Development 2.0.

Créer des épopées et des stories

Les épopées contiennent les besoins de haut niveau pour vos produits, que vous pouvez décomposer en stories gérables. Lors de la création d'épopées et de stories dans Agile Development 2.0, vous pouvez les associer à un produit.

Consultez Créer une épopée dans Agile Development 2.0 et Créer une story dans Agile Development 2.0.

Créer des mises en production

Certaines organisations disposent d'un délai fixe pour rendre leurs produits disponibles sur le marché ; ce délai est appelé une mise en production. Une mise en production possède une date de début et une date de fin, entre lesquelles sont effectuées plusieurs itérations de développement. Par exemple, vous pouvez avoir des calendriers trimestriels ou semestriels pour publier de nouvelles applications ou améliorations aux applications existantes.

Après avoir créé une mise en production dans Agile Development 2.0, vous pouvez y associer des produits, des épopées et des stories. Voir Créer une mise en production dans Agile Development 2.0.

Créer des backlogs personnalisés

Un backlog personnalisé peut être créé en définissant des critères de filtre. Par exemple, un backlog personnalisé peut être une combinaison de stories, de défauts et d'incidents, tandis qu'un autre peut être une combinaison de stories et d'incidents. Ainsi, vous pouvez créer autant de backlogs personnalisés que nécessaire.

Reportez-vous à la rubrique Créer un backlog personnalisé dans Agile Development 2.0.

Créer des groupes d'affectation

Créez un groupe d'affectation et ajoutez-y des membres. Pour chaque membre du groupe, définissez le nombre par défaut de points d'une story d'utilisateur qu'il peut terminer dans un sprint. Au niveau du groupe, la somme des points d'une story d'utilisateur de tous les membres du groupe détermine la capacité du groupe.

Reportez-vous à la rubrique Créer un groupe d'affectation dans Agile Development 2.0.

Créer des sprints

Un sprint désigne le délai dans lequel l'équipe de développement va livrer une ou plusieurs stories. Un sprint peut être plus ou moins long, mais prend généralement entre une et quatre semaines. Le Scrum Master crée le nombre de sprints requis pour le groupe, et ces sprints sont utilisés par les membres du groupe pour terminer le travail requis pour une mise en production à venir. Néanmoins, tous les sprints d'une mise en production doivent être compris entre les dates de début et de fin de la mise en production.

Planifier des activités de sprint

Avant le début d'un sprint, le groupe et le scrum master décident des stories du backlogs qu'ils peuvent s'engager à terminer dans les délais d'un sprint. Les stories d'un sprint peuvent être sélectionnées selon leur priorité. Le Scrum Master doit s'assurer que l'effort (nombre total de points d'une story de l'utilisateur) requis pour terminer les stories est conforme à la capacité du groupe.

Lors de la planification de vos sprints, vous pouvez utiliser les rapports de vélocité pour estimer la quantité de travail que le groupe peut effectuer dans le sprint suivant. Le tableau de bord Agile Teams 2.0 fournit un rapport d'historique de vélocité et une vélocité par rapport de type.

• Historique de vélocité : obtenez un aperçu de la vélocité globale de l'équipe pour les 10 derniers sprints. Déterminez si l'équipe atteint une vélocité stable et prévisible et si elle répond aux engagements.
• Vélocité par type : analysez la façon dont la vélocité de votre équipe change au fil du temps et comparez la charge de travail stratégique de l'équipe avec un type de charge de travail opérationnel ou autre.

Pour plus d'informations sur la façon de planifier vos sprints, consultez la rubrique Planifier vos activités de sprint dans Agile Development 2.0.

Suivre la progression du sprint

Le Scrum Master gère les efforts de l'équipe de sprint, fournit des rapports de progression et lève tous les bloqueurs que rencontre l'équipe. Les membres de l'équipe mettent à jour les enregistrements de stories et organisent des réunions informelles quotidiennes pour informer le Scrum Master et les propriétaires de produits de leurs inquiétudes.

L'équipe est censée terminer toutes les stories engagées pour un sprint. Le Scrum Master s'attend à ce que les stories soient entièrement testées et prêtes pour la mise en production, selon les critères d'acceptation.

Idéalement, les stories validées et le champ d'application d'un sprint spécifique ne doivent pas changer lorsque le sprint est en cours. Agile Development 2.0 offre la possibilité de les mettre à jour si nécessaire et de les adapter aux priorités changeantes. Toutefois, les stories ne doivent être ajoutées ou supprimées d'un sprint qu'après discussion avec le groupe, le Scrum Master et le propriétaire de produit.

Vous pouvez utiliser le tableau de bord du sprint Agile 2.0 avec des rapports tels que les graphiques d'avancement (burnup, burndown) pour suivre la progression de l'équipe pour un sprint.

Suivre la progression d'une mise en production

Le propriétaire de produit suit la progression de la mise en production et vérifie si l'équipe termine les stories au rythme nécessaires à la réalisation de l'objectif de mise en production.

Vous pouvez utiliser le tableau de bord de mise en production Agile 2.0 avec des rapports tels que les graphiques d'avancement (burnup, burndown) et de temps de cycle pour suivre la progression de l'équipe pour une mise en production.