Agiles Vorgehen im Forschungsprojekt

Das Projekt wird in insgesamt 5 Iterationen unterschiedlicher Dauer durchgeführt, die sich an der SPES Viewpoints orientieren. Es ist geplant, in den einzelnen Iterationen agil vorzugehen. Dabei sollen wesentliche Elemente des Vorgehensmodells SCRUM, die gegebenenfalls für den kon-kreten Projektkontext angepasst werden, verwendet werden. Die Tatsache, dass die meisten Projektpartner bereits in den Vorgängerprojekten gut zusammengearbeitet haben, und eine sehr ver-trauensvolle Basis besteht, ist ein wichtiger Faktor für das Gelingen des agilen Ansatzes.

Iterations

Die Iterationen werden in agilen Phasen (Sprints) realisiert, die jeweils eine Dauer von ca. 4 Wochen haben. In diesen Sprints werden die Aufgaben (Tasks) aus dem Backlog abgearbeitet. Resultate eines Sprints sind immer die methodische Umsetzung der SPES Modelle in SysML (meist in Form eines Meta-Modells), die Implementierung der methodischen Umsetzung in den Werkzeugen und die Evaluierung der Resultate anhand der Praxisbeispiele („Running Code“). Dadurch werden in jedem Sprint bereits verwertbare Resultate erzeugt. Durch das geplante Vorgehen wird zunächst weitest-gehend auf Dokumentation in Form von Textdokumenten verzichtet. Stattdessen werden die Arbeits-ergebnisse während der Abarbeitung der Tasks Wiki-artig dokumentiert (z.B. in Confluence) und mit den entsprechenden Tasks verlinkt. Auf dieser Grundlage wird in der abschließenden Epilog-Phase die Dokumentation zusammengestellt und konsolidiert (zum Vergrößern auf das Bild klicken).

Sprints

Die einzelnen Iterationen, die sich grob an den SPES Viewpoints orientieren, werden mit einer Reihe von Sprints realisiert. Die Anzahl der Sprints je Iteration variiert, je nach Anzahl und erwarteter Komplexität der Modelle. Es wird erwartet, dass in späteren Iterationen Synergien aus voran gegangenen Iterationen genutzt werden können.

Wir planen eine Sprintdauer von 4 Wochen. Ein Sprint beginnt immer mit einem Sprint-Planungsmeeting, in dem die Tasks aus dem Product Backlog priorisiert, bezüglich ihres Aufwands bewertet und in das Sprint Backlog übernommen werden. Die Tasks im aktuellen Sprint Backlog bilden die Aufgaben, die vom Entwicklungsteam während der Dauer des Sprints abgearbeitet wer-den. Wie oben beschrieben ist das Resultat eines Sprints stets „Running Code“, also ein Meta-Modell für die Implementierung der SPES Modelle in SysML, die Implementierung dieser Modelle im Werkzeug und deren Evaluierung im Praxisbeispiel.

Den Abschluss eines Sprints bildet jeweils ein Sprint Review mit Retro, in dem die erzielten Resulta-te inhaltlich überprüft werden (Review). Zudem werden etwaige Hindernisse bei der Entwicklung analysiert und der Prozess gegebenenfalls angepasst (Retro).


Copyright © 2023 TUM