Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- rise:handbuch:2.5_rise_scrum_reference [2026-10-14 11:46] – lukas
+++ rise:handbuch:2.5_rise_scrum_reference [2026-10-16 13:14] (aktuell) – lukas
@@ Zeile 1: / Zeile 1: @@
-====== RISE-Scrum: kurz erklärt ======
+====== RISE-Scrum ======
-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 [[rise:handbuch:2.1_semesterablauf_reference|Semesterablauf]] und in ISIS.
+RISE arbeitet **Scrum-inspiriert**: Gruppen planen überschaubare Arbeit, setzen sie um, prüfen Ergebnisse und passen die nächsten Schritte anhand neuer Erkenntnisse an. Diese Seite erklärt die Anwendung in der Projektgruppe; sie setzt nicht alle Elemente des formalen Scrum-Frameworks unverändert voraus. Der Semesterrahmen umfasst drei Sprints. Termine und Abgaben stehen in ISIS, die inhaltlichen [[rise:handbuch:2.1_semesterablauf_reference|Meilensteine]] im Handbuch.
+===== Vorbereitung: Videovorlesung auf ISIS =====
+Bereitet die erste Sprintplanung mit der Videovorlesung **[[[[https://isis.tu-berlin.de/|Methodik zur Prototypentwicklung und Agiles Projektmanagement]]** vor. Sie wird im RISE-Kurs im Bereich **„Bewertungsrelevante Informationen“** geführt. Der Videozugang erfordert eine TU-Anmeldung. Die weiteren Einstiegsmaterialien stehen im [[rise:handbuch:1.1_onboarding_tutorial|Onboarding]].
+Übertragt die Inhalte auf eure Aufgabe. Diese Fragen helfen beim Ansehen und bei der anschließenden Planung:
+^ Leitfrage ^ Ergebnis für eure Gruppe ^
+| Welches Problem lösen wir, und welches Ergebnis wollen wir erreichen? | Aufgabe, Randbedingungen und ein überprüfbares Sprintziel. |
+| Wie zerlegen und priorisieren wir die Arbeit? | Kleine Arbeitspakete mit Ergebnis, Verantwortung, Aufwand und Abhängigkeiten. |
+| Was können wir im nächsten Sprint tatsächlich abschließen? | Eine Auswahl, die verfügbare Arbeitszeit, Beschaffung, Abstimmung und Tests berücksichtigt. |
+| Wie prüfen wir eine Lösung und begründen die nächste Entscheidung? | Vorab festgelegte Prüfkriterien sowie eingeplante Auswertung und Rückmeldung. |
+Die Videovorlesung vertieft die Methoden; die folgenden Abschnitte beschreiben ihre Anwendung bei RISE. Die Anforderungen an die Darstellung des Semester- und Sprintplans stehen unter [[rise:handbuch:3.3_hinweise_zu_vortraegen#methodische_bestandteile_des_sprintplans|Vortragshinweise: methodische Bestandteile des Sprintplans]].
 ===== Begriffe =====
 ^ Begriff ^ Bedeutung bei RISE ^
-| Backlog | Priorisierte Liste offener Aufgaben im vereinbarten Aufgabenwerkzeug. Keine zweite laufende Liste im Wiki. |
+| Backlog | Priorisierte Liste offener Aufgaben im vereinbarten Aufgabenwerkzeug. Das Wiki enthält keine zweite laufende Aufgabenliste. |
-| Sprintziel und Sprint-Backlog | Ergebnis des nächsten Arbeitsabschnitts und dafür übernommene Aufgaben; verfügbare Zeit, Abhängigkeiten und Risiken berücksichtigen. |
+| Sprintziel | Überprüfbares Ergebnis, das die Gruppe im Sprint erreichen will. |
-| Definition of Done | Überprüfbare Kriterien, wann ein Paket wirklich abgeschlossen ist, etwa Testnachweis, dokumentierte Entscheidung oder nutzbare Datei. |
+| Sprint-Backlog | Die für dieses Ziel übernommenen Arbeitspakete mit Verantwortlichen, Abhängigkeiten und Aufwand. |
-| Sprint Review | Ergebnisse zeigen, Abweichungen erklären und Feedback für die nächste Entscheidung aufnehmen. Prüfungszuordnung unter [[rise:handbuch:3.2_bewertungsmodalitaeten|Bewertungsmodalitäten]]. |
+| Abschlusskriterien einer Aufgabe | Konkrete Merkmale, anhand derer das vereinbarte Ergebnis geprüft wird: etwa ein dokumentierter Schnittstellentest oder eine anhand benannter Kriterien begründete Auswahl. |
-| Retrospektive | Zusammenarbeit und Arbeitsweise reflektieren; konkrete Verbesserung vereinbaren und im nächsten Sprint nachverfolgen. |
+| Definition of Done | Gemeinsam vereinbarte Qualitätsanforderungen an ein verwendbares Ergebnis, etwa nachvollziehbare Prüfung, dokumentierte Grenzen und zugängliche Dateien. |
+| Review | Ergebnisse, Abweichungen und offene Fragen zeigen; Feedback für den nächsten Sprint aufnehmen. Die Prüfungszuordnung steht unter [[rise:handbuch:3.2_bewertungsmodalitaeten|Bewertungsmodalitäten]]. |
+| Retrospektive | Zusammenarbeit und Arbeitsweise prüfen, eine konkrete Verbesserung vereinbaren und deren Umsetzung nachverfolgen. |
+Die Aufgaben der Gruppenleitung (Leadership) sowie die Product-Owner- und Scrum-Master-Funktionen sind unter [[rise:handbuch:2.3_zusammenarbeit_reference#wer_macht_was|Zusammenarbeit und Rollen]] beschrieben.
+===== Arbeit im Sprint =====
+==== Sprint planen ====
+Plant das Semester zunächst grob und den jeweils nächsten Sprint konkret. Überarbeitet die spätere Planung nach Reviews, Tests und neuen Erkenntnissen. Ein Sprintziel beschreibt den erreichten Zustand, nicht nur eine Tätigkeit: etwa „Die Schnittstelle ist unter den vereinbarten Bedingungen geprüft“ statt „An der Schnittstelle arbeiten“.
+  - **Kapazität klären:** Berücksichtigt die tatsächlich verfügbare Zeit der Gruppenmitglieder, Urlaubs- und Prüfungszeiten, Besprechungen, Einarbeitung, Integration und Dokumentation. Klärt benötigte Geräte und Unterstützung. Plant Puffer für unsichere Arbeit ein.
+  - **Abhängigkeiten prüfen:** Was benötigt ihr von anderen Gruppen, aus einer Bestellung oder aus einem vorherigen Versuch? Stimmt Übergaben und benötigte Ergebnisse früh ab; Lieferzeit ist keine eigene Bearbeitungszeit.
+  - **Arbeitspakete schneiden:** Haltet für jedes Paket das erwartete Ergebnis, eine verantwortliche Person, geschätzten Aufwand, Voraussetzungen und überprüfbare Abschlusskriterien fest. Teilt große oder unklare Pakete, bis ein innerhalb des Sprints prüfbarer Zwischenschritt möglich ist.
+  - **Priorisieren und auswählen:** Wählt die für das Sprintziel wichtigsten Pakete. Klärt unsichere Voraussetzungen früh. Beginnt nicht mehr Arbeit gleichzeitig, als ihr gemeinsam prüfen und abschließen könnt.
+  - **Prüfung mitplanen:** Umsetzung, Integration, Tests, Auswertung und die nötige Dokumentation gehören zur Aufwandsschätzung. „Code geschrieben“ oder „CAD erstellt“ bedeutet noch nicht, dass das Ergebnis verwendbar ist.
+==== Arbeitspakete konkret formulieren ====
+Die folgenden Beispiele zeigen die Formulierung, nicht zusätzliche Pflichtaufgaben:
+^ Zu unbestimmt ^ Überprüfbares Arbeitspaket ^
+| „Software integrieren“ | Zwei benannte Module verbinden, den vereinbarten Datenaustausch anhand festgelegter Testfälle prüfen und Versionen, Ergebnisse sowie offene Fehler dokumentieren. |
+| „Recherche machen“ | Die vereinbarten Lösungsoptionen anhand vorab benannter Kriterien vergleichen und eine begründete Empfehlung mit Quellen und offenen Annahmen festhalten. |
+| „Veranstaltung organisieren“ | Ziel, Ablauf, Zuständigkeiten und benötigte Ressourcen zu einem abgestimmten Veranstaltungskonzept zusammenführen; offene Entscheidungen benennen. |
-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.
+==== Während des Sprints nachsteuern ====
-===== Rollen und Anwendung =====
+Pflegt Aufgaben, Zuständigkeiten und Bearbeitungsstand im vereinbarten Aufgabenwerkzeug, etwa Nextcloud Deck oder Issues. Aktualisiert den Stand beim [[rise:handbuch:2.2_woechentliche_termine|Gruppentermin]]. Benennt Hindernisse, benötigte Entscheidungen und die nächsten Schritte. Der gemeinsame Arbeitstermin ist kein tägliches Scrum-Meeting.
-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 [[rise:handbuch:2.3_zusammenarbeit_reference|Zusammenarbeit und Rollen]].
+Wenn eine Voraussetzung fehlt oder ein Paket größer wird als erwartet, klärt mit der Gruppenleitung, welche Arbeit geteilt, zurückgestellt oder anders priorisiert wird. Kennzeichnet den tatsächlich erreichten Stand und passt den Plan an; unerledigte Arbeit nicht als abgeschlossen ausweisen.
-  - Zu Sprintbeginn Ziel und Prioritäten vereinbaren; Arbeit in überschaubare Pakete mit Verantwortlichen und Abschlusskriterien zerlegen.
+Fachliche Entscheidungen, Tests und Ergebnisse gehören in die zugeordnete Fachdokumentation und werden aus dem Semesterprotokoll verlinkt. Zuständigkeiten und Ablageorte stehen unter [[rise:handbuch:2.3_zusammenarbeit_reference|Zusammenarbeit]], die Schreib- und Nachweisregeln unter [[rise:handbuch:3.4_wikidokumentation_how-to|Dokumentationsregeln]]. Führt keine zweite laufende Aufgabenliste im Wiki.
-  - 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 [[rise:handbuch:2.2_woechentliche_termine|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 [[rise:handbuch:3.4_wikidokumentation_how-to|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 [[rise:handbuch:3.3_hinweise_zu_vortraegen#methodische_bestandteile_des_sprintplans|Vortragshinweise: Sprintplan]] geführt. Das bisherige Format der Aufgabenbeschreibung bleibt erhalten.
+===== Review und Retrospektive =====
-===== Folgeaufgaben ab Sprint 2 =====
+Im **Review** prüft ihr das Arbeitsergebnis: Was wurde erreicht, welche Nachweise liegen vor, was weicht vom Ziel ab und was folgt daraus? Zeigt Ergebnisse und Grenzen. Übernehmt Rückmeldungen und offene Befunde in die nächsten Prioritäten. Vorbereitung und Präsentationsanforderungen stehen unter [[rise:handbuch:3.3_hinweise_zu_vortraegen#sprint_reviews|Sprint Reviews]].
-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 [[rise:handbuch:3.5_semesterabschluss-rise_how-to|Übergabe]].
+In der **internen Sprint-Retrospektive** prüft ihr eure Arbeitsweise: Was hat geholfen, was hat gebremst und was ändert ihr konkret? Vereinbart eine umsetzbare Verbesserung mit Zuständigkeit und prüft im nächsten Sprint, ob sie wirksam war.
-===== Methodik zum Nachschlagen =====
+Die internen Retrospektiven der Projektgruppe sind von den **benoteten Leadership-Retrospektiven** zu unterscheiden. Eine interne Besprechung erfüllt nicht automatisch das Leadership-Prüfungselement. Dessen Zuordnung und Bewertung stehen unter [[rise:handbuch:3.2_bewertungsmodalitaeten#leadership_und_specialist|Leadership und Specialist]], die Vorbereitung unter [[rise:handbuch:3.3_hinweise_zu_vortraegen|Leadership-Präsentationen]].
-Das ISIS-Video „Methodik zur Prototypentwicklung und Agiles Projektmanagement“ bereitet die Anwendung vor. Die zugrunde liegenden Methodikfolien SoSe 2024 enthalten folgende Hilfen:
+===== Folgeaufgaben und weiterführende Inhalte =====
-^ Frage ^ Abschnitt ^
+Nutzt Befunde aus Reviews und Tests auch für die Aufgaben der Nachfolgegruppe. Beginnt damit ab Sprint 2; Ablauf, Aufgabenkarten und Übergabefolien sind zentral unter [[rise:handbuch:3.5_semesterabschluss-rise_how-to#folgeaufgaben_entwickeln|Folgeaufgaben entwickeln]] geregelt.
-| 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 [[https://scrumguides.org/scrum-guide.html|offizielle Scrum Guide]] erklärt das vollständige Framework; diese Seite beschreibt die Anwendung bei RISE.
+Zum Nachschlagen der allgemeinen Scrum-Begriffe dient der [[https://scrumguides.org/scrum-guide.html|offizielle Scrum Guide]]. Für die konkrete Anwendung bei RISE gelten die hier beschriebenen Abläufe; konkrete Termine und die Lernmaterialien stehen im aktuellen ISIS-Kurs.
 ----