Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- rise:handbuch:2.3_zusammenarbeit_reference [2026-10-15 17:36] – [Kommunikation, Wissens- und Datenmanagement] r6_karlson
+++ rise:handbuch:2.3_zusammenarbeit_reference [2026-10-16 11:31] (aktuell) – [Fachbereiche, Werkzeuge und Außenkommunikation] lukas
@@ Zeile 6: / Zeile 6: @@
   * **Teamleitung:** Koordiniert das Gesamtprojekt und organisatorische Fragen. Der leitende wissenschaftliche Mitarbeiter ist die erste Ansprechstelle für Prüfungs- und Anrechnungssonderfälle; formelle Entscheidungen treffen die zuständigen Stellen.
-  * **Tutor*innen und Gruppenleitungen:** Begleiten fachliche Entscheidungen, Gruppenarbeit und Abstimmung zwischen Gruppen. Regelmäßige Gespräche sind unter [[rise:handbuch:2.2_woechentliche_termine|Wöchentliche Termine]] beschrieben.
+  * **Gruppenleitung (Leadership):** Begleitet die zugeordneten Projektgruppen fachlich und organisatorisch. Übernimmt Leitungs- und Koordinationsaufgaben, gibt Feedback und unterstützt Onboarding, Schnittstellenarbeit und Wissenssicherung. Gruppenleitung und Leadership bezeichnen dieselbe Rolle. Im SCRUM-Team agieren sie als Product Owner.
-  * **Product Owner:** Hält Ziel und fachliche Prioritäten im Blick und stimmt die Aufgabe mit Beteiligten ab. Bei RISE können Betreuung oder Leadership-Personen diese Aufgaben übernehmen; konkrete Zuständigkeit vereinbaren.
+    * Die Gruppenleitung übernimmt in der Regel zugleich die **Product-Owner-Funktion**: Sie hält Ziel und fachliche Prioritäten im Blick und stimmt die Aufgabe mit den Beteiligten ab. Product Owner bezeichnet damit eine Funktion, nicht automatisch eine zusätzliche Person oder Leitungsebene. Übernimmt eine andere Person diese Funktion, hält die Gruppe die Zuordnung im Semesterprotokoll fest.
   * **Scrum Master:** Unterstützt Arbeitsprozess, Termine und das Sichtbarmachen beziehungsweise Bearbeiten organisatorischer Hindernisse. Jede Gruppe klärt, wer diese Funktion übernimmt.
   * **Developer*innen:** Bearbeiten fachliche und organisatorische Aufgaben. Im **Specialist Track** vertiefen fortgeschrittene Studierende fachliche Entwicklungsarbeit.
-  * **Leadership:** Übernimmt vereinbarte koordinierende Aufgaben, unterstützt Gruppen, Onboarding, Schnittstellen und Wissenssicherung. Die Rolle ist nicht automatisch gleichbedeutend mit Tutor*innenstatus, Prüfungsberechtigung oder alleiniger fachlicher Freigabe.
+Den regelmäßigen Austausch mit der Gruppenleitung beziehungsweise der benannten betreuenden Person beschreibt [[rise:handbuch:2.2_woechentliche_termine|Wöchentliche Termine]].
 ===== Leitungsaufgaben konkret =====
-^ Bereich ^ Aufgaben ^ Nachvollziehbare Belege ^
+^ Bereich ^ Aufgaben ^ Was wird festgehalten? ^
 | Teamführung | Neue Mitglieder einführen; Ziele, Verantwortlichkeiten und Fristen mit der Gruppe klären; regelmäßige Meetings unterstützen. | Vereinbarte Ziele, Zuständigkeiten, Einarbeitung und konkrete Unterstützungsbeiträge. |
 | Problemlösung | Hindernisse früh erkennen; Ursachen und Optionen klären; Unterstützung organisieren; nötigenfalls eskalieren. | Problembeschreibung, Entscheidung, Maßnahme und nachverfolgtes Ergebnis. |
-| Schnittstellenarbeit | Abhängigkeiten, Übergabegegenstände und Prüfkriterien zwischen Gruppen vereinbaren; Änderungen rückmelden. | Verlinkte Schnittstellenabsprachen und Entscheidungen im Wiki. |
+| Schnittstellenarbeit | Abhängigkeiten, Übergabegegenstände und Prüfkriterien zwischen Gruppen vereinbaren; Änderungen rückmelden. | Schnittstellenabsprachen und Entscheidungen in der Fachdokumentation, verlinkt aus dem Semesterprotokoll. |
 | Reflexion und Qualität | Feedback auswerten; Reviews und Tests begleiten; Befunde, Korrekturen und verbleibende Grenzen verfolgen. | Prüf- und Testnachweise, Rückmeldungen, Korrekturschleifen und eigene Reflexion. |
-| Folgeaufgaben und Übergabe | Ab Sprint 2 mit den Gruppen Aufgaben für das nächste Semester entwickeln, priorisieren und abstimmen. | Wiki-Folgeaufgaben und konsistente PowerPoint-Übergabefolie. |
+| Folgeaufgaben und Übergabe | Arbeit mit den betreuten Gruppen koordinieren. | Der Ablauf und die Anforderungen stehen in der [[rise:handbuch:3.5_semesterabschluss-rise_how-to|Abschluss-Checkliste]]. |
-Zu Beginn werden betreute Gruppen, Befugnisse und erwartete Nachweise vereinbart. Leadership-Personen erstellen fachlich begründete Einschätzungen und Bewertungsvorlagen; die **endgültige Prüfungsbewertung bleibt bei den Prüfungsverantwortlichen**. Fachliche oder sicherheitsbezogene Fragen an zuständige Personen weitergeben.
+Betreute Gruppen und Zuständigkeiten werden zu Semesterbeginn mit der Teamleitung festgelegt. Die **endgültige Prüfungsbewertung bleibt bei den Prüfungsverantwortlichen**. Fachliche oder sicherheitsbezogene Freigaben dürfen Leadership-Personen nicht allein aus ihrer Rolle ableiten.
-Zwei Retrospektiven und ein Portfolio mit gruppenweisen Prüf-, Bewertungs- und Korrekturbelegen sind die im Auftakt vorgesehene Ausgestaltung der Leitungsarbeit. Wie dies den offiziellen Prüfungselementen zugeordnet wird und welche Kriterien gelten, steht unter [[rise:handbuch:3.2_bewertungsmodalitaeten|Bewertungsmodalitäten]]. Keine zusätzlichen Prüfungselemente oder Untergewichte aus dieser Aufgabenliste ableiten.
+Prüfungsleistungen und Bewertung für Leadership sind ausschließlich unter [[rise:handbuch:3.2_bewertungsmodalitaeten|Bewertungsmodalitäten]] beschrieben.
 ===== Gemeinsame Integration und frühe Tests =====
-Integration ist laufende Entwicklungsarbeit, nicht nur ein letzter Termin vor der Präsentation. Plant mit den beteiligten Gruppen Anforderungen, Schnittstellen, Testaufbau und Erfolgskriterien frühzeitig. Benennt Verantwortliche und dokumentiert verwendete Hardware, Softwarestände, Durchführung, Ergebnisse und offene Fehler. Simulation, Einzelkomponententest und Gesamtsystemtest erfüllen unterschiedliche Zwecke.
+Integration ist laufende Entwicklungsarbeit. Die beteiligten Gruppen legen Anforderungen, Schnittstellen, Testaufbau und Erfolgskriterien fest, bevor sie Teile zusammenführen. Sie benennen Verantwortliche und dokumentieren verwendete Hardware, Softwarestände, Durchführung, Ergebnisse und offene Fehler. Simulation, Einzelkomponententest und Gesamtsystemtest prüfen unterschiedliche Fragen.
 Tests an realer Hardware werden mit Betreuung und den für Sicherheit zuständigen Personen abgestimmt. Eine funktionierende Komponente oder Simulation allein ist kein Nachweis für sicheren Pilot*innenbetrieb. Freigaben und Sicherheitsunterweisung gemäß [[rise:handbuch:2.4_material_und_sicherheit_how-to|Material und Sicherheit]] beachten.
-==== E1 im WiSe 2026/27: Softwareintegration ====
+Die Aufgabenstellung und die betreuten Projektseiten legen fest, welche Komponenten und Schnittstellen eine Gruppe bearbeitet. Den gültigen technischen Stand prüft die Gruppe außerdem am verwendeten Repository und an der vorhandenen Hardware.
-Die aktuelle Auftaktpräsentation zeigt für E1 mehrere Aufgabenblöcke mit eigener Personenspanne. Diese Blöcke bearbeiten denselben Softwarestack und müssen ihre Schnittstellen gemeinsam abstimmen. Ob sie als Teilgruppen eines E1-Teams oder organisatorisch getrennt arbeiten, legt die Betreuung bei der Gruppenbildung fest. Eine verbindliche Gesamtpersonenanzahl nennt die aktuelle Auftaktpräsentation nicht. Gemeinsames Ziel ist, den Softwarestack zu integrieren und **frühzeitig auf realer Hardware nachvollziehbar zu testen**.
+===== Kommunikation, Wissens- und Datenmanagement =====
-Der Integrationsentwurf nennt zusätzlich folgende Arbeitspakete. Vor der verbindlichen Vergabe sind Übernahmestand, Priorität und Zuständigkeit mit der Betreuung zu prüfen:
+^ Ort ^ Inhalt ^ Erster Schritt ^
+| [[https://isis.tu-berlin.de/|ISIS]] | Semesterzeitplan, Kursorganisation, Abgaben, Vorlagen, Videos und Sicherheitsunterweisung. | Den aktuellen RISE-Kurs nutzen. |
+| [[https://docs.chat.tu-berlin.de/|Matrix]] | Laufende Nachrichten in und zwischen Gruppen. | Client nach TU-Anleitung einrichten; Team- und Gruppenräume erfragen. |
+| [[https://cloud.rise-tub.de/|RISE-Nextcloud]] | CAD- und Simulationsdaten, Dokumente, Präsentationen, Medien, Inventar und Übergaben. | Konto, Rechte und richtigen Gruppenordner prüfen. |
+| DokuWiki | Handbuch, Semesterprotokolle aller Projektgruppen und Fachseiten außerhalb der Software- und Elektronikdokumentation. | [[rise:handbuch:3.4_wikidokumentation_how-to|Konventionen]] und [[rise:studi:rise-exo-2:vorlagen:semesterprotokoll|Semesterprotokollvorlage]] lesen. |
+| [[https://riseos-docs-e1325d.gitlab-pages.tu-berlin.de/|git-Dokumentation (git-Wiki)]] | Fachliche Dokumentation der Software und der elektrischen/elektronischen Systeme; im aktuellen Aufgabenzuschnitt E1/E2. | Die lesbare Dokumentation sichten und den Bearbeitungszugang zum [[https://github.com/riserobotics/rise-docs|Dokumentationsrepository]] prüfen. |
+| Nextcloud Deck oder vereinbarte Issues | Aufgaben, Prioritäten, Zuständigkeiten und Bearbeitungsstand. | Ein gemeinsames Aufgabenwerkzeug pro Arbeitskontext vereinbaren. |
+| GitHub und vorhandene GitLab-Bestände | Code, Konfiguration und Versionsverlauf. | Das für die Aufgabe verwendete Repository mit der Betreuung festlegen. |
-  * Homing und Offset Detection mit Control verbinden und den durchgängigen Ablauf prüfen.
+**Jede Projektgruppe führt ihr Semesterprotokoll im DokuWiki, auch im Bereich Software und Elektronik.** Es verlinkt die zugehörige Fachdokumentation und die verwendeten Dateien und Versionen. Die Zuordnung der Fachinhalte richtet sich nach dem Thema; die Teamnummer allein bestimmt keinen zusätzlichen Dokumentationsort.
-  * Launch, Motor-Konfiguration und Deployment integrieren.
-  * Trajektorienausführung und automatisches Error Handling prüfen.
-  * Hardware- und Regressionstests abschließen; Start, Neustart und Fehlerfälle nachvollziehbar testen.
-Weitere Themen priorisiert das Team gemeinsam nach Umfang und Abhängigkeiten: Navigation/Motion Planning, NixOS/System Services, EtherCAT-Treiber, Simulation mit Gazebo/RViz und Companion App. Die Aufzählung ist keine Zusage, alle Erweiterungen in einem Semester vollständig umzusetzen.
+Pflegt einen Fachinhalt an einem maßgeblichen Ort. Verlinkt ihn aus dem Semesterprotokoll und von betroffenen Schnittstellen; schreibt dieselbe Fachdokumentation nicht zusätzlich im anderen System ab. Dauerhaft wichtige Chatentscheidungen werden in der passenden Fachseite festgehalten und im Semesterprotokoll verlinkt. Große Dateien und Code bleiben am jeweiligen Ablageort.
-Die Systemstrukturfolie ist als **Referenz aus der Übergabe** zu lesen. Aktuelle Paketzuordnung und tatsächliche Schnittstellen im Repository und mit der Betreuung prüfen. Ein „Launch“- beziehungsweise „Messages“-Baustein aus unterschiedlichen Folien wird hier nicht ungeprüft als aktuelle Architektur festgeschrieben. Ergebnisse und offene Integrationspunkte gehören in die Fachseiten und das Semesterprotokoll.
+Der laufende Backlog bleibt im Aufgabenwerkzeug. Dokumentation erklärt Ausgangslage, Entscheidungen und Ergebnisse; sie führt keine zweite laufende Aufgabenliste.
-===== Kommunikation, Wissens- und Datenmanagement =====
-^ Ort                                                                        ^ Inhalt                                                                                               ^ Erster Schritt                                                                                                                                                                           ^
-| [[https://isis.tu-berlin.de/|ISIS]]                                        | Disposition, Kursorganisation, Vorlagen, Videos, Sicherheitsunterweisung, Originalraster.            | Aktuellen RISE-Kurs öffnen, nicht einen Kurslink aus einem alten Semester übernehmen.                                                                                                    |
-| [[https://docs.chat.tu-berlin.de/|Matrix]]                                 | Laufende Nachrichten in und zwischen Gruppen.                                                        | Client nach TU-Anleitung einrichten; Team- und Gruppenräume erfragen.                                                                                                                    |
-| [[https://cloud.rise-tub.de/|RISE-Nextcloud]]                              | CAD- und Simulationsdaten, Dokumente, Präsentationen, Medien, Inventar und Übergaben.                | Konto, Rechte und richtigen Gruppenordner prüfen.                                                                                                                                        |
-| DokuWiki                                                                   | Semesterprotokolle (alle), wiederverwendbares Wissen, Entscheidungen und Fachseiten (außer E1, E2).  | [[rise:handbuch:3.4_wikidokumentation_how-to|Konventionen]] und [[rise:studi:rise-exo-2:vorlagen:semesterprotokoll|Vorlage]] lesen.                                                      |
-| git-Wiki                                                                   | Dokumentation der elektrischen/elektronischen Systeme und Software.                                  | [[https://riseos-docs-e1325d.gitlab-pages.tu-berlin.de/|Gerenderte Version]] überfliegen und Zugang zu [[https://github.com/riserobotics/rise-docs|github-Repos]] zum Editieren prüfen. (E1, E2)  |
-| Nextcloud Deck oder vereinbarte Issues                                     | Aufgaben, Prioritäten, Zuständigkeiten und Bearbeitungsstand.                                        | Ein gemeinsames Aufgabenwerkzeug pro Arbeitskontext vereinbaren.                                                                                                                         |
-| [[https://github.com/riserobotics|GitHub]] und vorhandene GitLab-Bestände  | Code, Konfiguration und Versionsverlauf; ältere Repositories als Vorarbeit.                          | Zugriff und maßgebliches Repository mit der Gruppe klären.                                                                                                                               |
-Dauerhaft wichtige Chatentscheidungen ins Wiki übertragen. Große Dateien und Code am Ablageort verlinken. Der Backlog bleibt im Aufgabenwerkzeug; das Wiki beschreibt die begründete Aufgabenstellung und Ergebnisse, statt eine zweite laufende Aufgabenliste zu führen.
 ===== Fachbereiche, Werkzeuge und Außenkommunikation =====
-RISE umfasst Konstruktion, Software/Elektronik, Steuerung/Regelung, Human Machine Interaction, Ganganalyse/Simulation und Operations mit PR, Sponsoring und Eventmanagement. Aktuelle Untergruppen und Codes ändern sich mit Aufgaben und Semester; gültige Zuordnung mit Teamleitung und Aufgabenfolien klären.
+RISE umfasst die Fachbereiche **Human Machine Interaction**, **Mechanical Design**, **Electrical Engineering**, **Control Engineering**, **Biomechanics** und **Operations**. Zu Operations gehören unter anderem Event Management, Finance, PR und Sponsoring. Fachbereiche beschreiben Kompetenzen und Arbeitsfelder, keine festen Teams. Welche Gruppen im Semester gebildet werden und wer welche Aufgabe übernimmt, wird bei der Themenvergabe geklärt und auf den jeweiligen Projekt- und Semesterprotokollseiten festgehalten.
-Je nach Aufgabe kommen Siemens NX oder Onshape, KiCad, MATLAB, AnyBody, ROS 2, Gazebo, RViz, Isaac Sim/Isaac Lab oder Blender zum Einsatz. Nicht jede Gruppe benötigt jedes Werkzeug. Installation, Version und Zugang mit dem Fachteam klären. [[https://cloud.rise-tub.de/s/eypAPmfQQ22kgNt|Vorhandene Workshop-Materialien]] können den Einstieg unterstützen.
+Je nach Aufgabe kommen Siemens NX oder Onshape, KiCad, MATLAB, AnyBody, ROS 2, Gazebo, RViz, Isaac Sim/Isaac Lab oder Blender zum Einsatz. Nicht jede Gruppe benötigt jedes Werkzeug. Installation, Version und Zugang werden mit der fachlichen Betreuung geklärt.
-Website, Instagram, LinkedIn und YouTube dienen Außenkommunikation, Recruiting und Partnerkontakt. Sponsoring, Veröffentlichungen und zugehörige Materialien mit Teamleitung und Operations-Gruppe abstimmen; gültige Links im aktuellen Kurs verwenden.
+[[https://blogs.tu-berlin.de/mt_rise/de/home-deutsch/|Website]], [[https://www.instagram.com/rise_tub/|Instagram]], [[https://www.linkedin.com/company/rise-research-and-innovation-in-student-exoskeleton-development|LinkedIn]] und [[https://www.youtube.com/@RISE_TUB|YouTube]] dienen Außenkommunikation, Recruiting und Partnerkontakt. Sponsoring und Veröffentlichungen werden mit Teamleitung und dem zuständigen Operations-Bereich abgestimmt.
 ----
 [[rise:handbuch:2.5_rise_scrum_reference|RISE-Scrum]] | [[rise:handbuch:1_uebersicht|Handbuch]]
-{{tag>RISE Handbuch Zusammenarbeit Rollen Leadership Integration Reference}}
+{{tag>RISE Handbuch Zusammenarbeit Rollen Fachbereiche Leadership Integration Reference}}