Améliorations des modèles de données de à Agile Development 1.0Agile Development 2.0
Agile Development 2.0 offre quelques améliorations de modèle de données par rapport à Agile Development la version 1.0.
Utilisation de la construction de plateforme commune — Groupe d’affectation
Pour mapper une équipe Agile (équipe Scrum), Agile Development la version 1.0 utilise une entité distincte appelée table Équipe de mise en production (scrum_pp_team). Cette entité est associée à une entité de mise en production, comme illustré dans la capture d’écran suivante.
Toutes les autres tâches sur la plateforme telles que les incidents, les problèmes, les changements et les projets s’appuient sur l’entité de groupe d’affectation pour effectuer des affectations à un groupe. Les gestionnaires de groupe peuvent exécuter des rapports sur un groupe d’affectation pour avoir un aperçu du travail affecté à leurs groupes.
Pour standardiser l’utilisation d’un groupe sur l’ensemble de la plateforme, même pour le travail Scrum tel que les stories et les tâches, le concept standard Groupe d’affectation est utilisé par opposition à l’entité autonome Équipe de mise en production. Agile Development 2.0 utilise des groupes d’affectation pour mapper des équipes agiles. Un groupe d’affectation de type Équipe agile est utilisé pour définir une équipe Agile.
Il n’est pas nécessaire de créer une équipe Agile (groupe) pour chaque mise en production
Avec Agile Development la version 1.0, des équipes doivent être créées pour chaque version et les équipes doivent être associées à chaque version. Par exemple, si une équipe Scrum appelée Team — Alpha travaille sur plusieurs versions trimestrielles. Vous ne pouvez pas créer l’équipe une seule fois et l’associer à une mise en production ou à une mise en production sur une mise en production. Chaque fois qu’une mise en production est créée, vous devez créer une équipe portant le même nom et associer une équipe à la mise en production.
Les sprints peuvent être créés sans mise en production
Le backlog d’équipe peut être maintenu indépendamment de la mise en production
En règle générale, une équipe peut avoir un backlog d’équipe continu publication après version, elle peut extraire des stories de son backlog et les exécuter via des sprints dans la mise en production.
Avec Agile Development la version 1.0, il est impossible de définir une équipe sans définir une mise en production. Par conséquent, le backlog d’équipe ne peut pas être maintenu 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 peut être associé à la mise en production, mais pas créé au sein d’une mise en production. Par conséquent, un groupe d’affectation peut gérer ses propres backlogs.
Association entre la mise en production et le groupe
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 n’ont pas à créer de groupes pour chaque mise en production), la table m2m_release_group_list a été introduite. Cette table stocke l’association d’un groupe avec une mise en production. Cette association n’est pas utilisée pour la génération de sprints, mais pour dériver la capacité d’une mise en production.| Équipe | Sprint de début | Sprint de fin | Points (chaque sprint) | Capacité totale de 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) |