Erweiterungen des Datenmodells von Agile Development 1.0 nach Agile Development 2.0

  • Freigeben Version: Yokohama
  • Aktualisiert 30. Januar 2025
  • 2 Minuten Lesedauer
  • Agile Development 2.0 bietet gegenüber Agile Development 1.0 einige Verbesserungen des Datenmodells.

    Verwendung des gemeinsamen Plattformkonstrukts − Zuweisungsgruppe

    Um ein agiles Team (Scrum-Team) zuzuordnen, verwendet Agile Development 1.0 eine separate Entität, die sogenannte Release-Team-Tabelle (scrum_pp_team). Diese Entität ist einer Release-Entität zugeordnet, wie im folgenden Screenshot dargestellt.

    Abbildung : 1. Scrum-Release
    Teams innerhalb eines Release

    Alle anderen Aufgaben auf der Plattform, z. B. Incidents, Probleme, Changes, Projekte, hängen von der Zuweisungsgruppenentität ab, um Zuweisungen an einer Gruppe vorzunehmen. Gruppenmanager können Berichte für eine Zuweisungsgruppe ausführen, um Einblick in die Arbeit zu erhalten, die ihren Gruppen zugewiesen ist.

    Um die Verwendung einer Gruppe plattformübergreifend auch für Scrum-Arbeiten wie Storys und Aufgaben zu standardisieren, wird die Zuweisungsgruppe als Standardkonstrukt verwendet, im Gegensatz zur eigenständigen Entität des Release-Teams. Um agile Teams zuzuordnen, nutzt Agile Development 2.0 Zuweisungsgruppen. Zum Definieren eines agilen Teams wird eine Zuweisungsgruppe vom Typ „Agiles Team“ verwendet.

    Abbildung : 2. Gruppen
    Verwendung von Zuweisungsgruppen in Agile Development 2.0

    Keine Notwendigkeit, agile Teams (Gruppen) für jeden Release zu erstellen

    Mit Agile Development 1.0 müssen Teams für jeden Release erstellt und die Teams jedem Release zugeordnet werden. Beispielsweise wenn ein Scrum-Team namens „Team − Alpha“ an mehreren Quartals-Releases arbeitet. Sie können das Team nicht einmal erstellen und das Team allen Releases bzw. Release für Release zuordnen. Jedes Mal, wenn ein neuer Release erstellt wird, müssen Sie ein Team mit demselben Namen erstellen und das Team dem Release zuordnen.

    Mit Agile Development 2.0 werden Gruppen unabhängig von Releases erstellt und Sie können Storys aus mehreren Releases bearbeiten, ohne die Gruppe für jeden Release neu erstellen zu müssen.
    Abbildung : 3. Scrum-Release
    Teams innerhalb eines Release Dasselbe Team wird viermal erstellt, eines für jedes Release

    Möglichkeit, Sprints ohne Release zu erstellen

    Das Erstellen von Sprints ist mit Agile Development 1.0 nur möglich, wenn Sie einen Release erstellen. Sprints können nicht unabhängig für ein Team erstellt werden. Agile Development 1.0 erfordert die Erstellung eines Release für die Story-Ausführung über Sprints. Ohne Release kann ein Sprint nicht in einen Story-Datensatz eingefügt werden.
    Abbildung : 4. Sprints
    Sprints, die im Kontext eines Release erstellt wurden
    In Agile Development 2.0 werden Sprints Zuweisungsgruppen zugeordnet. Sprints werden Zuweisungsgruppen zugeordnet

    Teamrückstand kann unabhängig vom Release verwaltet werden

    Normalerweise kann ein Team nach dem Release einen laufenden Teamrückstand-Release haben, es kann Storys aus seinem Rückstand abrufen und sie durch Sprints im Release ausführen.

    Mit Agile Development 1.0 kann ein Team nicht definiert werden, ohne einen Release zu definieren. Der Teamrückstand lässt sich daher nicht unabhängig vom Release verwalten.

    Mit Agile Development 2.0 wird innerhalb eines Release keine Zuweisungsgruppe erstellt. Sie kann dem Release zugeordnet, aber nicht in einem Release erstellt werden. Daher kann eine Zuweisungsgruppe ihren eigenen Rückstand verwalten.

    Abbildung : 5. Gruppenrückstand mit Agile Development 2.0
    Gruppen-Backlog mit Agile Development 2.0

    Zuordnung zwischen Release und Gruppe

    Da es in Agile Development 2.0 keine direkte Beziehung zwischen einem Release und einer Gruppe gibt (Gruppen sind unabhängig und müssen nicht für jeden Release erstellt werden), wurde die Tabelle m2m_release_group_list eingeführt. Diese Tabelle speichert die Zuordnung einer Gruppe zu einem Release. Diese Zuordnung dient nicht zur Generierung von Sprints, sondern wird verwendet, um die Kapazität eines Release abzuleiten.
    Geben Sie die Anzahl der Sprints an, für die die Gruppe in einem Release arbeitet. Aus der Kapazität des Teams wird die Kapazität des Release abgeleitet.
    Tabelle : 1. m2m_release_group
    Team Startsprint Endsprint Points (jeder Sprint) Gesamtgruppenkapazität für Release
    A A_Sprint 1 A_Sprint 3 30 90 (3*30)
    B B_Sprint 1 B_Sprint 4 40 160 (4*40)
    Gesamte Release-Kapazität = 90 + 160 = 250 Points
    Release – Gruppenzuordnung in Agile Development 2.0