Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
RISE-Scrum: kurz erklärt
RISE arbeitet Scrum-inspiriert: Gruppen planen überschaubare Arbeit, zeigen Ergebnisse, holen Feedback ein und passen die nächsten Schritte an. Nicht jedes Element des formalen Scrum-Leitfadens wird unverändert umgesetzt. RISE hat einen Semesterrahmen mit drei Sprints, Betreuung und eigenen Prüfungsformaten. Ablauf und Termine stehen im Semesterablauf und in ISIS.
Begriffe
| Begriff | Bedeutung bei RISE |
|---|---|
| Backlog | Priorisierte Liste offener Aufgaben im vereinbarten Aufgabenwerkzeug. Keine zweite laufende Liste im Wiki. |
| Sprintziel und Sprint-Backlog | Ergebnis des nächsten Arbeitsabschnitts und dafür übernommene Aufgaben; verfügbare Zeit, Abhängigkeiten und Risiken berücksichtigen. |
| Definition of Done | Überprüfbare Kriterien, wann ein Paket wirklich abgeschlossen ist, etwa Testnachweis, dokumentierte Entscheidung oder nutzbare Datei. |
| Sprint Review | Ergebnisse zeigen, Abweichungen erklären und Feedback für die nächste Entscheidung aufnehmen. Prüfungszuordnung unter Bewertungsmodalitäten. |
| Retrospektive | Zusammenarbeit und Arbeitsweise reflektieren; konkrete Verbesserung vereinbaren und im nächsten Sprint nachverfolgen. |
Ein Review betrachtet vor allem das Ergebnis; die Retrospektive betrachtet den Arbeitsprozess. Die vorgesehenen Leadership-Retrospektiven als Prüfungsformat sind mit der Betreuung gesondert abzustimmen und nicht automatisch jede interne Sprint-Retrospektive.
Rollen und Anwendung
Product Owner hält Ziel und fachliche Prioritäten im Blick. Scrum Master unterstützt Prozess und Hindernisbehebung. Developer*innen bearbeiten die Aufgaben. RISE-spezifische Zuständigkeiten und Leadership stehen unter Zusammenarbeit und Rollen.
- Zu Sprintbeginn Ziel und Prioritäten vereinbaren; Arbeit in überschaubare Pakete mit Verantwortlichen und Abschlusskriterien zerlegen.
- Aufwand, Urlaubs- und Prüfungszeiten, Beschaffung und Abhängigkeiten berücksichtigen. Nicht mehr parallele Arbeit beginnen, als gemeinsam geprüft und abgeschlossen werden kann.
- Aufgabenstand beim Gruppentermin aktualisieren. Der gemeinsame Mittwochstermin ist nicht automatisch ein formales Daily Scrum.
- Integration und Tests innerhalb der Pakete planen. „Code geschrieben“ oder „CAD erstellt“ bedeutet nicht automatisch „am System nutzbar“.
- Ergebnisse, Entscheidungen und Grenzen laufend im Wiki dokumentieren.
- Nach dem Review Feedback in die nächsten Prioritäten übernehmen; nach der Retrospektive konkrete Maßnahmen nachverfolgen.
Die methodischen Bestandteile des Sprintplans werden zentral unter Vortragshinweise: Sprintplan geführt. Das bisherige Format der Aufgabenbeschreibung bleibt erhalten.
Folgeaufgaben ab Sprint 2
Gruppe und Leadership beginnen gemeinsam, die Aufgaben für das nächste Semester zu definieren. Der Wiki-Abschnitt beschreibt Ausgangslage, Ziele, Prioritäten und Schnittstellen. Konkrete ausführbare Pakete werden im Aufgabenwerkzeug angelegt und aus dem Wiki verlinkt. Vor Review II mit Tutor*innen abstimmen, nach Abschlussbefunden aktualisieren und in die Übergabefolie nach bestehendem Vorbild übernehmen. Siehe Übergabe.
Methodik zum Nachschlagen
Das ISIS-Video „Methodik zur Prototypentwicklung und Agiles Projektmanagement“ bereitet die Anwendung vor. Die zugrunde liegenden Methodikfolien SoSe 2024 enthalten folgende Hilfen:
| Frage | Abschnitt |
|---|---|
| Wie formulieren wir übergebbare Aufgabenpakete? | Klassische Zeitplanung, Folien 10–11: Ziele, Ergebnisse und Zuständigkeiten. |
| Ist der Sprint machbar? | Klassische Zeitplanung, Folie 12: verfügbare Zeit, Abhängigkeiten und Puffer. |
| Was klären wir vor der Lösung? | Anforderungs- und Funktionsanalyse, Folien 13–18. |
| Wie begründen wir eine Konzeptentscheidung? | Lösungsraum und bewertete Konzeptauswahl, Folien 19–27. |
Ältere Methodikfolien sind keine Quelle für aktuelle Termine oder Prüfungsregeln. Der offizielle Scrum Guide erklärt das vollständige Framework; diese Seite beschreibt die Anwendung bei RISE.