Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- rise:handbuch:2.1_semesterablauf_reference [2026-10-14 17:09] – r7_thao
+++ rise:handbuch:2.1_semesterablauf_reference [2026-10-16 01:35] (aktuell) – lukas
@@ Zeile 1: / Zeile 1: @@
 ====== Semesterablauf und Meilensteine ======
-RISE verbindet projektbezogene Lehre mit drei Arbeitszyklen. Diese Seite erklärt Reihenfolge und Ergebnisse. Konkrete Termine, Räume, Zeitslots und Änderungen stehen in der **aktuellen Disposition und den Ankündigungen im ISIS-Kurs**. Prüfungsleistungen richten sich zusätzlich nach dem belegten Modul.
+RISE arbeitet in drei Sprints. Jede Projektgruppe plant ihre Arbeit, zeigt Ergebnisse in den Reviews und passt die folgenden Arbeitsschritte an. Diese Seite legt fest, was die Meilensteine **inhaltlich** bedeuten. **Kalenderdaten, Räume, Präsentationsslots und konkrete Abgabetermine stehen ausschließlich im aktuellen [[https://isis.tu-berlin.de/|ISIS-Kurs]].** Die Reihenfolge der ersten Schritte steht im [[rise:handbuch:1.1_onboarding_tutorial|Onboarding]]; Prüfungsleistungen sind unter [[rise:handbuch:3.1_pruefung_und_dokumentation_reference|Prüfung und Dokumentation]] beschrieben.
-===== Vom Auftakt bis zur Übergabe =====
+===== Planung und Meilensteine =====
-^ Phase ^ Tätigkeit ^ Ergebnis ^
+^ Meilenstein ^ Zeitpunkt im Arbeitsablauf ^ Erwartetes Ergebnis ^ Geltung ^
-| Auftakt und Themenfindung | Projekt kennenlernen, Selbsteinschätzung bearbeiten, Themen und Gruppen finden; Anrechnung klären. | Thema, betreuende Personen und Belegungsweg. |
+| Sprintplanung | Zu Semesterbeginn und zu Beginn jedes weiteren Sprints | Sprintziel, priorisierte Arbeitspakete, Zuständigkeiten, Aufwand, Schnittstellen und überprüfbare Abschlusskriterien. | Jede Projektgruppe. |
-| Übernahme und Planung | Vorarbeiten lesen; Problem, Ziele, Methoden, Schnittstellen und Zuständigkeiten bestimmen. | Semesterplan für drei Sprints; genauer Plan für Sprint 1; angelegtes Semesterprotokoll. |
+| Semesterprotokoll | Spätestens zur Zeitplanpräsentation im DokuWiki angelegt; danach fortlaufend gepflegt | Aufgabe, Ausgangslage, Ziele, Zuständigkeiten und erste Verweise auf Vorarbeiten sind eingetragen. | Jede Projektgruppe. Die [[rise:handbuch:3.4_wikidokumentation_how-to|Dokumentationsregeln]] erklären die weitere Dokumentation. |
-| Zeitplanpräsentation | Plan vorstellen, Feedback und Schnittstellen aufnehmen. | Angepasster Arbeitsplan; Prüfungsanmeldung vorher fristgerecht erledigt. |
+| Inventur | Einmal im ersten Sprint | Vorhandenes und genutztes RISE-Material ist erfasst; der Anfangsstand der Inventurliste ist ausgedruckt und an jedem genutzten Schrank angebracht. | Jede Projektgruppe. Die Liste wird danach während des Semesters gepflegt und zum Abschluss erneut ausgedruckt. Das Verfahren steht unter [[rise:handbuch:2.4_material_und_sicherheit_how-to|Material und Sicherheit]]. |
-| Sprint 1 | Konzept entwickeln, erste Umsetzung und Tests beginnen, Dokumentation aufbauen. | Überprüfbare Ergebnisse, Konzeptentscheidung, erster Wiki-Entwurf. |
+| Konzeptentscheidung (Conceptfreeze) | Orientierung an Review I | Gewählte Lösung und Gründe für die Auswahl sind festgehalten; offene Annahmen, Risiken und Schnittstellen sind benannt. | Deutliche Empfehlung für Gruppen mit Konzeptarbeit. |
-| Sprint 2 | Realisieren, integrieren und testen; Wiki-Struktur abstimmen; Folgeaufgaben mit Leadership beginnen. | Zwischenintegration, vorläufige Fachseiten, abgestimmte Folgeaufgaben. |
+| Bestellentscheidung (Bestellfreeze) | Orientierung an Review I | Benötigte Kaufteile und Materialien sind mit Spezifikation, Kosten, Lieferzeit und Bestellweg so weit geklärt, dass die Beschaffung im Semester wirksam werden kann. | Deutliche Empfehlung für Gruppen mit Beschaffungsbedarf. Ohne Beschaffung entfällt dieser Punkt. |
-| Sprint 3 und Abschluss | Ergebnisse prüfen, Grenzen einordnen, Dokumentation und Folgeaufgaben aktualisieren. | Finale Wiki-Dokumentation, zugängliche Dateien, editierbare Übergabefolie und weitere vereinbarte Übergabemedien. |
+| Dokumentationskonzept | Erster Entwurf zu Review I; ausgearbeitete Struktur zu Review II | Die Struktur enthält Beispielinhalte, Fachseiten und ihre Verknüpfung mit dem Semesterprotokoll. Sie berücksichtigt DokuWiki und die git-Dokumentation entsprechend der festgelegten [[rise:handbuch:2.3_zusammenarbeit_reference|Zuordnung der Ablageorte]]. Ergebnisse und Entscheidungen werden laufend am jeweiligen Ablageort dokumentiert. | Jede Projektgruppe. Inhaltliche Anforderungen stehen unter [[rise:handbuch:3.4_wikidokumentation_how-to|Dokumentationsregeln]]. |
+| Entwurfsstand (Designfreeze) | Orientierung an Review II | Der Stand, der geprüft oder gefertigt werden soll, ist festgelegt; Versionen, Schnittstellen und Prüfkriterien sind dokumentiert. | Deutliche Empfehlung, sobald spätere Änderungen Tests, Fertigung oder Integration gefährden würden. Dies gilt auch außerhalb der mechanischen Konstruktion. |
+| Integration und Prüfung | Während aller Sprints | Schnittstellen und Ergebnisse werden anhand vorher festgelegter Kriterien geprüft; Aufbau, Versionen, Befunde, Fehler und Grenzen sind dokumentiert. | Entsprechend der fachlichen Aufgabe jeder Gruppe. |
+| Übergabe | Ab Sprint 2 vorbereitet; zum Semesterabschluss abgeschlossen | Dokumentation, Dateien und Folgeaufgaben sind für die nächste Gruppe nutzbar. | Verbindliche Punkte und Zuständigkeiten stehen ausschließlich in der [[rise:handbuch:3.5_semesterabschluss-rise_how-to|Abschluss-Checkliste]]. |
-Die [[rise:handbuch:2.2_woechentliche_termine|wöchentlichen Termine]] unterstützen Arbeit und Abstimmung. [[rise:handbuch:2.5_rise_scrum_reference|RISE-Scrum]] erklärt Planung, Review und Retrospektive; [[rise:handbuch:3.3_hinweise_zu_vortraegen|Vortragshinweise]] beschreiben die Präsentationen.
+Concept-, Bestell- und Designfreeze sind **Orientierungspunkte für rechtzeitige Entscheidungen**, keine Änderungsverbote und keine starren Prüfungsfristen. Sie schaffen Zeit für Bestellung, Fertigung, Integration und Tests im selben Semester. Wer einen einschlägigen Richtpunkt nicht einhalten kann, bespricht Grund, Folgen und Ersatzplan mit der Betreuung und hält die Entscheidung im Semesterprotokoll fest. Ist ein Punkt fachlich nicht anwendbar, etwa der Bestellfreeze bei einer Gruppe ohne Beschaffung, ist keine Ausnahme nötig.
-===== Ergebnisse an den Meilensteinen =====
+Spätere Änderungen bleiben möglich. Betroffene Schnittstellen, Prüfungen, Sicherheitsfragen und Lieferzeiten werden vor der Änderung mit den beteiligten Gruppen und der Betreuung geklärt.
-^ Meilenstein ^ Erwartetes Ergebnis, soweit für die Aufgabe relevant ^
-| Sprintplanung | Aufgabe und Methodik; priorisierte Arbeitspakete, Zuständigkeiten, Aufwand, Meilensteine und Schnittstellen; überprüfbare Abschlusskriterien. |
-| Conceptfreeze | Gewähltes Konzept und begründete Auswahl; verbleibende Annahmen und Risiken. |
-| Beschaffung | Kaufteil- und Materialbestelllisten; Kosten, Lieferzeiten und Abhängigkeiten berücksichtigt. |
-| Inventur | Bestände geprüft und Listen aktualisiert; angekündigte Inventuraufgaben abgeschlossen. |
-| Wiki-Konzept | Frühzeitig erster Entwurf mit Beispielinhalt und Vernetzungsplan; bis Review II ausgearbeitete und abgestimmte Struktur. |
-| Laufende Dokumentation | Erreichte Inhalte im Semesterprotokoll und auf Fachseiten; Dateien und Code auffindbar. |
-| Designfreeze | Abgestimmter Fertigungsstand für Werkstatt beziehungsweise 3D-Druck; Schnittstellen und Änderungen nachvollziehbar, Fertigung mit zuständigen Personen geklärt. |
-| Integration und Tests | Schnittstellen geprüft; Testaufbau, Versionen, Ergebnisse, Fehler und verbleibende Grenzen dokumentiert. |
-| Folgeaufgaben | Ab Sprint 2 gemeinsam mit Leadership im Wiki entwickelt, vor Review II mit Tutor*innen abgestimmt und bis Abschluss aktualisiert. |
-| Endabgabe und Übergabe | Finale Dokumentation und Ablage; PowerPoint-Aufgabenfolie nach bestehendem Vorbild; weitere vereinbarte Medien und Nachweise. |
-Conceptfreeze oder Designfreeze bedeutet nicht, dass spätere Änderungen unmöglich sind. Änderungen müssen mit den Betroffenen abgestimmt und in ihren Folgen für Sicherheit, Termine, Beschaffung und Fertigung nachvollzogen werden.
-===== Folgeaufgaben und Wiki =====
-Beginnt **im zweiten Sprint**, nicht erst kurz vor der Endabgabe. Jede Gruppe entwickelt die Aufgaben für ihre Nachfolge **gemeinsam mit den zuständigen Leadership-Personen**. Tutor*innen und Teamleitung stimmen fachliche Prioritäten, Machbarkeit und Umfang ab.
-Im Semesterprotokoll entsteht ein verlinkter Abschnitt mit Ausgangslage, verwendbaren Ergebnissen, offenen Problemen, Ziel, konkreten Folgeaufgaben, Prioritäten und Schnittstellen. Spätestens vor Review II wird der Vorschlag abgestimmt und vorgestellt. Nach Integration und Abschlussprüfung aktualisiert ihr ihn; die PowerPoint-Übergabefolie fasst denselben Stand zusammen. Die genaue Struktur und Abschlusskontrolle stehen unter [[rise:handbuch:3.5_semesterabschluss-rise_how-to|Semesterabschluss und Übergabe]].
-Die Dokumentation wächst in jedem Sprint. Das Wiki-Konzept beginnt früh; die ausgearbeitete Struktur einschließlich Vernetzungsplan ist bis Review II vorgesehen. Die finale Vernetzungsstruktur ist gemäß [[rise:handbuch:3.4_wikidokumentation_how-to|Wiki-Konventionen]] mindestens zwei Wochen vor der Endabgabe mit der Betreuung abzusprechen.
 ----
 [[rise:handbuch:1_uebersicht|Handbuch]] | [[rise:handbuch:1.1_onboarding_tutorial|Onboarding]]
+{{tag>RISE Handbuch Semester Ablauf Meilensteine}}
-{{tag>RISE Handbuch Semester Ablauf Reference}}