--- sourceDocument: Gestion stratégique des portefeuilles Xanadu sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/xanadu/it-business-management Release : - xanadu ft:locale : - fr-FR ft:publication_title : - Gestion stratégique des portefeuilles Xanadu ft:clusterId : - itbm bundleId : - itbm workflow : - Technology --- # Flux de processus Agile Development # Flux de processus Agile Development {#ariaid-title1} * Rversion finale: Xanadu * * Mis à jour 1 août 2024 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes de lecture 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. Remarque : Le flux expliqué ici représente la pratique courante de gestion des efforts Agile Development à l'aide de la fonctionnalité disponible dans l'application Agile Development 2.0. Ce flux n'a pas vocation à représenter le seul processus possible. 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](https://servicenow-prod.fluidtopics.net/9nHn6xKhhPpZKyI4ZohvIg "Créez un produit pour représenter une fonctionnalité importante pour les clients. Un produit peut contenir des thèmes, des épopées et des stories qui décrivent ces améliorations du point de vue d'un utilisateur."). 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](https://servicenow-prod.fluidtopics.net/~1NvI3uIKfrNuJp7b4fySw "Définissez les exigences de haut niveau des fonctionnalités que vous souhaitez développer en créant des épopées dans Agile Development 2.0.") et [Créer une story dans Agile Development 2.0](https://servicenow-prod.fluidtopics.net/B1XR1UvGOu1wHZ5VyAQ8tA "Créez des définitions de haut niveau de vos exigences sous la forme de stories dans Agile Development 2.0. Gérez et suivez vos stories en les associant à un produit, un projet ou une mise en production et en les affectant à un groupe d'affectation."). 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](https://servicenow-prod.fluidtopics.net/Nhgy84bj4Bg~QuE~6DgX2A "Créez une mise en production pour commencer à associer les stories et les tâches Scrum de votre développement de produit à la 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](https://servicenow-prod.fluidtopics.net/BVtx9fyrUzeBQBD4W8tK2w "Créez des filtres pour définir les stories qui apparaissent dans vos backlogs 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](https://servicenow-prod.fluidtopics.net/t5d6GhdHSzU_75w2FOobCA#create-an-agile-group "Créez un groupe d'affectation de type Équipe Agile de sorte que vous puissiez affecter ces groupes à un produit ou à une version."). 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](https://servicenow-prod.fluidtopics.net/hZEgAaWz~zsYURahF6WLdg "Le tableau de bord d'équipe fournit une visualisation de la progression de l'équipe sur les stories sur une période donnée. Il propose des graphiques de prévisibilité de l'équipe et vous aide à planifier la capacité de l'équipe pour les sprints à venir. En outre, il fournit des détails sur tous les membres de l'équipe.") 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. {#agile-development-process-flow__ul_mkg_tcj_ntb} 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](https://servicenow-prod.fluidtopics.net/wFRmY_cpEOK~Nd~~pqB~KQ "Rationalisez vos activités de sprint, telles que la création, la modification et l'achèvement des sprints, ou l'ajout de stories aux sprints, à l'aide de l'onglet Planification de sprint du tableau Agile."). 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](https://servicenow-prod.fluidtopics.net/sjgwFlEcO5u~ZF_xCvKatg "Suivez la progression de vos stories dans le sprint actuel et prévoyez l'achèvement du sprint à l'aide du tableau de bord du sprint.") 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](https://servicenow-prod.fluidtopics.net/ygtqfZkG~Zm4Gp59grtaZg "Suivez la progression de vos stories et analysez les changements de champ d'application de la version actuelle à l'aide du tableau de bord de la version 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. Remarque : Tous les tableaux de bord Agile 2.0 sont disponibles avec [Pack de contenu Analyse des performances pour Agile 2.0](https://servicenow-prod.fluidtopics.net/EYdpWlhbG_2kbGmnMRcQWA "Améliorez vos processus et pratiques Agile à l'aide des tableaux de bord préconfigurés avec des visualisations de données du pack de contenu Platform Analytics pour Agile 2.0.").