---
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


---

# Améliorations du modèle de données entre Agile Development 1.0 et Agile Development 2.0

# Améliorations du modèle de données entre Agile Development 1.0 et Agile Development 2.0 {#ariaid-title1}

* Rversion finale: Xanadu
* 
* Mis à jour 1 août 2024
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes de lecture

Agile Development 2.0 offre quelques améliorations du modèle de données par rapport à Agile Development 1.0.

## Utilisation de la construction de plateforme commune --- Groupe d'affectation {#data-model-enhancements__section_uqp_4qr_3gb}

Pour mapper une équipe agile (équipe Scrum), Agile Development 1.0 utilise une entité distincte appelée table d'équipe de mise en production (scrum_pp_team). Cette entité est associée à une entité de mise en production comme affiché dans la capture d'écran suivante.  
Figure 1. Mise en production Scrum

Toutes les autres tâches sur la plateforme, telles que les incidents, les problèmes, les changements ou les projets, reposent sur l'entité du groupe d'affectation pour affecter des éléments à un groupe. Les gestionnaires de groupes peuvent exécuter des rapports sur les groupes d'affectation afin d'obtenir un aperçu du travail qui leur est affecté.

Pour standardiser l'utilisation d'un groupe sur l'ensemble de la plateforme, y compris pour les travaux Scrum tels que les stories et les tâches, le groupe d'affectation de construction standard est utilisé par opposition à l'équipe de mise en production de l'entité autonome. Agile Development 2.0 utilise les groupes d'affectation pour mapper les équipes agiles. Un groupe d'affectation de type Équipe agile est utilisé pour définir une équipe agile.  
Figure 2. Groupes

## Il n'est pas nécessaire de créer une équipe agile (groupe) pour chaque mise en production {#data-model-enhancements__section_x4p_hrr_3gb}

Avec Agile Development 1.0, des équipes doivent être créées pour et associées à chaque mise en production. Par exemple, si une équipe Scrum appelée Team --- Alpha travaille sur plusieurs mises en production trimestrielles, vous ne pouvez pas créer l'équipe une seule fois et l'associer à n'importe quelle mise en production, ou à chaque mise en production successive. Chaque fois qu'une nouvelle mise en production est créée, vous devez créer une équipe du même nom et l'associer à la mise en production.  
Avec Agile Development 2.0, les groupes sont créés indépendamment des mises en production, et vous pouvez travailler sur des stories à partir de plusieurs mises en production sans recréer le groupe à chaque mise en production.Figure 3. Version Scrum

## Les sprints peuvent être créés sans mise en production {#data-model-enhancements__section_pj4_rrr_3gb}

Avec Agile Development 1.0, la création d'une mise en production est obligatoire pour créer des sprints. Les sprints ne peuvent être créés indépendamment pour une équipe. Agile Development 1.0 nécessite la création d'une mise en production pour l'exécution d'une story via des sprints. S'il n'y a pas de mise en production, le sprint ne peut être renseigné sur un enregistrement de story.Figure 4. Sprints Dans Agile Development 2.0, les sprints sont associés aux groupes d'affectation.

## Le backlog d'équipe peut être tenu indépendamment de la mise en production {#data-model-enhancements__section_el1_1sr_3gb}

En règle générale, une équipe peut avoir une mise en production continue du backlog d'équipe après la mise en production, elle peut extraire des stories de son backlog et les exécuter via des sprints lors de la mise en production.

Avec Agile Development 1.0, il est impossible de définir une équipe sans définir une mise en production. C'est pourquoi le backlog d'équipe ne peut être tenu indépendamment d'une mise en production.

Avec Agile Development 2.0, aucun groupe d'affectation n'est créé dans une mise en production. Il est possible d'en associer un à la mise en production, mais pas de le créer au sein même. C'est pourquoi un groupe d'affectation peut tenir son propre backlog.  
Figure 5. Grouper des backlogs avec Agile Development 2.0

## Association entre la mise en production et le groupe {#data-model-enhancements__section_hnr_3sr_3gb}

Comme il n'y a pas de relation directe entre une mise en production et un groupe dans Agile Development 2.0 (les groupes sont indépendants et il n'y a pas besoin de créer des groupes pour chaque mise en production), la table m2m_release_group_list a été introduite. Cette table stocke l'association d'un groupe à une mise en production. Cette association n'est pas utilisée pour la génération de sprints, mais sert à dériver la capacité d'une mise en production.  
Spécifiez le nombre de sprints pour lesquels le groupe travaille dans une mise en production. La capacité de la mise en production est dérivée de la capacité de l'équipe.{#data-model-enhancements__table_ndx_lsr_3gb__entry__5}

| Équipe | Début du sprint | Fin du sprint | Points (chaque sprint) | Capacité totale du groupe pour la mise en production |
|-|-|-|-|-|
| A | A_Sprint 1 | A_Sprint 3 | 30 | 90 (3\*30) |
| B | B_Sprint 1 | B_Sprint 4 | 40 | 160 (4\*40) |
[Tableau 1. m2m_release_group]

{#data-model-enhancements__table_ndx_lsr_3gb}Capacité de mise en production totale = 90 + 160 = 250 points