Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- rise:handbuch:2.5_rise_scrum_reference [2026-10-11 23:29] – angelegt 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 den nächsten Schritt an. Das ist kein Versprechen, jedes Element des formalen Scrum-Leitfadens eins zu eins umzusetzen. RISE hat einen Semesterrahmen mit drei Sprints, Betreuung und eigenen Prüfungsformaten. Den Ablauf und die Termine findest du im [[rise:handbuch:2.1_semesterablauf_reference|Semesterablauf]] und in der aktuellen ISIS-Disposition.((RISE: Auftaktveranstaltung SoSe 2026, Folien 23–35; [[https://scrumguides.org/scrum-guide.html|The Scrum Guide]], November 2020.))
+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.
-===== Die Begriffe, die du brauchst =====
+===== 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** | Geordnete Liste der noch zu bearbeitenden Aufgaben. Haltet sie im mit der Gruppe vereinbarten Aufgabenwerkzeug, nicht als zweite Liste im Wiki. |
+| Backlog | Priorisierte Liste offener Aufgaben im vereinbarten Aufgabenwerkzeug. Das Wiki enthält keine zweite laufende Aufgabenliste. |
-| **Sprintziel und Sprint-Backlog** | Was die Gruppe im nächsten Arbeitsabschnitt erreichen will und welche Aufgaben sie dafür übernimmt. Berücksichtigt verfügbare Zeit, Abhängigkeiten und Risiken. |
+| Sprintziel | Überprüfbares Ergebnis, das die Gruppe im Sprint erreichen will. |
-| **Definition of Done** | Woran ihr bei einer Aufgabe erkennt, dass sie wirklich abgeschlossen und überprüfbar ist – zum Beispiel Test, dokumentierte Entscheidung oder übergebbare Datei. |
+| Sprint-Backlog | Die für dieses Ziel übernommenen Arbeitspakete mit Verantwortlichen, Abhängigkeiten und Aufwand. |
-| **Sprint Review** | Ergebnisse zeigen und Rückmeldungen für die Weiterarbeit nutzen. Welche Reviews als Prüfungsleistung zählen, steht unter [[rise:handbuch:3.2_bewertungsmodalitaeten|Bewertungsmodalitäten]]; die praktische Vorbereitung unter [[rise:handbuch:3.3_hinweise_zu_vortraegen|Vortragshinweise]]. |
+| 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** | Kurz auf Zusammenarbeit und Arbeitsweise zurückblicken und eine konkrete Verbesserung für den nächsten Sprint vereinbaren. |
+| 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. |
-===== Rollen und Anwendung =====
+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.
-**Product Owner** hält Ziel und fachliche Prioritäten im Blick; **Scrum Master** unterstützt den Arbeitsprozess und hilft, Hindernisse sichtbar zu machen; die **Developer*innen** bearbeiten die Aufgaben. Wer diese Funktionen in eurer Gruppe übernimmt, klärt ihr mit der Betreuung. Die RISE-spezifischen Zuständigkeiten stehen unter [[rise:handbuch:2.3_zusammenarbeit_reference|Zusammenarbeit und Rollen]].
+===== Arbeit im Sprint =====
-Besprecht zu Beginn eines Sprints das Ziel, priorisiert Aufgaben und macht Verantwortlichkeiten, Aufwand und Schnittstellen sichtbar. Aktualisiert den Stand beim [[rise:handbuch:2.2_woechentliche_termine|wöchentlichen Gruppentermin]] und dokumentiert Ergebnisse und Entscheidungen gemäß [[rise:handbuch:3.4_wikidokumentation_how-to|Wiki-Dokumentation]]. Der gemeinsame Mittwochstermin ist dabei **nicht automatisch ein formales Daily Scrum**.
+==== Sprint planen ====
-Zum Einstieg seht euch im ISIS-Kurs unter **„Bewertungsrelevante Informationen“** das Video „Methodik zur Prototypentwicklung und Agiles Projektmanagement“ an. Der [[https://scrumguides.org/scrum-guide.html|offizielle Scrum Guide]] erklärt das vollständige Framework; diese Seite beschreibt nur, was ihr für die RISE-Arbeit zunächst braucht.
+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“.
-===== Zum Nachschlagen bei der Sprintplanung =====
+  - **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.
-Wenn ihr aus einer Aufgabe einen realistischen Sprintplan machen wollt, nutzt das Methodikvideo im aktuellen ISIS-Kurs gezielt als Nachschlagewerk. Die zugrunde liegende Präsentation „Methodik zur Prototypenentwicklung“ (SoSe 2024) enthält dazu folgende Abschnitte:
+==== Arbeitspakete konkret formulieren ====
-^ Frage aus eurer Gruppenarbeit ^ Passender Abschnitt der Präsentation ^
+Die folgenden Beispiele zeigen die Formulierung, nicht zusätzliche Pflichtaufgaben:
-| Wie schneiden wir übergebbare Aufgabenpakete zu? | **Klassische Zeitplanung**, Folien 10–11: Ziele und Ergebnisse herunterbrechen; für jedes Paket einen überprüfbaren Beitrag und eine klare Zuständigkeit festlegen. |
-| Ist unser Sprint zeitlich machbar? | **Klassische Zeitplanung**, Folie 12: verfügbare Arbeitszeit, Abhängigkeiten zu anderen Gruppen und Puffer berücksichtigen. |
-| Was müssen wir vor der Lösung klären? | **Anforderungs- und Funktionsanalyse**, Folien 13–18: Anforderungen prüfbar formulieren und das Problem in Teilfunktionen zerlegen. |
-| Wie begründen wir eine Konzeptentscheidung? | **Lösungsraum und bewertete Konzeptauswahl**, Folien 19–27: Alternativen sammeln, Kriterien gewichten und die Auswahl auf Plausibilität prüfen. |
-Auf Folie 28 steht im sichtbaren Folientext nur „Agiles Projektmanagement“; die eingebettete Aufnahme wurde für diese Übersicht nicht transkribiert. Für **Scrum selbst** nutzt daher die Begriffe auf dieser Seite und bei Bedarf den offiziellen Scrum Guide. Die älteren Folien sind methodische Hilfen; aktuelle RISE-Termine oder Prüfungsregeln entnehmt ihr daraus nicht.((RISE: „Methodik zur Prototypenentwicklung“, Foliensatz SoSe 2024, Folien 10–28; ISIS-Kurs WiSe 2026/27, Abschnitt „Bewertungsrelevante Informationen“.))
+^ 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. |
-----
+==== Während des Sprints nachsteuern ====
-[[rise:handbuch:1_uebersicht|Zur Handbuch-Startseite]] | [[rise:handbuch:1.1_onboarding_tutorial|Zum Onboarding]]
-== Tags: ==
+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.
+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.
+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.
+===== Review und Retrospektive =====
+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]].
+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.
+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]].
+===== Folgeaufgaben und weiterführende Inhalte =====
+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.
+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.
+----
+[[rise:handbuch:1_uebersicht|Handbuch]] | [[rise:handbuch:1.1_onboarding_tutorial|Onboarding]]
 {{tag>RISE Handbuch Scrum Methodik Zusammenarbeit}}