Skip to Content

Wiki source code of Anforderungen an die Gruppe

Version 5.1 by Pascal Meyer on 2025/07/29 02:03
Show last authors
1 {{toc/}}
2
3 = Anforderungen: Gruppensitzungen =
4
5 Die Gruppensitzungen (im Stud.IP zu erkennen an AG Softwareprojekt (X)) sind die Zeiten, in denen die Teams gemeinsam ihr Produkt entwickeln. Die Sitzungen werden von einem Tutor/einer Tutorin begleitet. Die Gruppentreffen finden i.d.R. in Präsenz statt. Im zweiten Semester braucht es ggf. nur alle zwei Wochen ein Präsenztreffen mit dem Tutor/der Tutorin, der Rest kann dann auch online stattfinden.
6
7 Die Gruppen werden zu Beginn des Semesters (i.d.R. ca. 14 Tage vorher mit Hilfe des Tutorientools) gebildet. Idealerweise haben die Gruppen eine Größe von 8 bis 12 Teilnehmern. Da die Anzahl der Tutoren und damit Tutorien beschränkt ist, kann es in Ausnahmefällen auch zu leicht größeren Gruppen kommen.
8
9 Da wichtige Besprechungen (z.B. die Scrum-Meetings) statt finden, ist es unbedingt notwendig, dass alle Mitglieder regelmäßig da sind. Wenn jemand **drei mal unentschuldigt** fehlt, gibt es ein Gespräch bei mir um zu klären, ob eine weitere Teilnahme möglich ist. Das gleiche gilt für **sechs mal entschuldigt**.
10
11 **Unterteilung in Untergruppen**: Es ist sinnvoll, wechselnde, kleinere Teilgruppen für Teilaufgaben zu bilden. Die Erfahrung zeigt jedoch, dass es **keine gute Idee ist, eine dauerhafte Trennung in Client und Server** vorzunehmen, da es bei Problemen in den einzelnen Bereichen sehr schwierig ist, gegenzusteuern!
12
13 Für den Einstieg ist es sinnvoll, **Pairprogramming** durchzuführen. Wichtig ist es dabei, dass die Commits die Informationen über das Pairprogramming enthalten.
14
15 == Zusatztreffen ==
16
17 Es ist sinnvoll, sich mindestens in Kleingruppen noch einmal außerhalb des Gruppentreffens zusammenzusetzen. Dafür ist es möglich, Räume in der [[Arbi >>url:https://uol.de/informatik/department/arbi]]zu buchen. Dazu bitte an [[Olaf Wendt>>url:https://uol.de/informatik/department/arbi/olaf-wendt]] wenden.
18
19 == Vorschlag für Ablauf ==
20
21 Es ist nicht immer leicht, zu Beginn die Organisation zu handhaben. Aus diesem Grund im Folgenden ein paar Hilfsdiagramme, die ein Student erstellt hat und freundlicherweise zur Verfügung gestellt hat. Wichtig sind dazu auch noch einmal die [[Scrum>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]]-Aspekte, die auch in einem [[Scrum Workshop>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/319456049/Scrum+Workshop]] aufbereitet wurde. Wenn es die Mittel zulassen und es eine geeignete Person gibt, wird der [[Scrum Workshop>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/319456049/Scrum+Workshop]] angeboten.
22
23 [[image:Arbeitsweise_Weiß.png]]
24
25 [[image:Aufgabenbearbeitung_Weiß.png]]
26
27
28 = Anforderungen: Spielregeln innerhalb der Gruppe =
29
30 * **Allgemeine Regeln innerhalb der Gruppe**
31 ** alle
32 *** sind vorbereitet und nehmen aktiv teil
33 *** erledigen ihre Aufgaben vollständig und pünktlich
34 *** übernehmen aktiv Aufgaben
35 *** beachten Gruppenstandards
36 *** sind bereit, ihre Arbeit auf Fehler untersuchen zu lassen
37 **** Grundsätzliche Kritik bitte zunächst unmittelbar an eine Person, dann Gruppe, dann Tutor, dann Dozent
38 **** Es gibt in jeder Gruppe einen [[Konfliktbeauftragten>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393423/Einzelleistungen+und%C2%A0Einzelaufgaben]]
39 *** [[Diskriminierung wird in keinster Form geduldet!>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/569606145/Keine+Tolerierung+von+Diskriminierung+jeglicher+Art]]
40 *** Konsequenzen bei Nichterfüllung von übertragenen Aufgaben festlegen?
41 ** Jeder übernimmt Teile bei
42 *** Dokumentation und
43 *** Implementierung
44 *** keine „Doku-Sklaven“!
45 * **Kommunikationsregeln innerhalb der Gruppe**
46 ** Es sollte stets ein respektvoller Umgangston herrschen.
47 ** Jedes Gruppenmitglied hat das Recht auf freie Meinungsäußerung und wird in Gesprächen,
48 Diskussionen oder Vorstellungen nicht unterbrochen.
49 ** Gespräche und Diskussionen jeglicher Art finden stets auf einer sachlichen Ebene statt. Beleidigungen
50 jeglicher Form werden nicht toleriert.
51 ** Zwischenmenschliche Probleme werden direkt offen und nicht hinter dem Rücken des betreffenden
52 Gruppenmitgliedes kommuniziert.
53 * **Verhaltensregeln innerhalb der Gruppe**
54 ** Alle Gruppenmitglieder werden stets mit Respekt behandelt.
55 ** Kritik wird stets konstruktiv auf einer sachlichen Ebene geäußert.
56 ** Im Sinne der Projektarbeit kann der Fall eintreten, dass persönliche Ansichten zurückgestellt
57 werden müssen. Es wird somit ein hohes Maß an Kompromissbereitschaft vorausgesetzt.
58 ** Meinungen, welche von den eigenen Ansichten abweichen, werden stets toleriert.
59 ** Bei verursachten Fehlern wird stets die volle Verantwortung für das eigene Handeln übernommen.
60
61 == Keine Tolerierung von Diskriminierung jeglicher Art ==
62
63 Leider sind wir im Rahmen des „Software Projektes“ auf eine Reihe von Vorfällen aufmerksam geworden, bei denen es um sexualisiertes Verhalten oder Herabwürdigung aufgrund des Geschlechtes geht. Diese Vorfälle reichen von vermeintlich harmlosen „dummen Sprüchen“ bis hin zu direktem unerwünschtem körperlichem Kontakt.
64
65 Ich möchte noch einmal ausdrücklich darauf hinweisen, dass wir als Department für Informatik und natürlich auch als Universität Oldenburg jede Art von Diskriminierung in keiner Weise tolerieren. Ein solches Vorkommnis kann bis zum Ausschluss von der Veranstaltung, in weitergehenden Fällen sogar bis zur Exmatrikulation führen!
66
67 Wir wissen, dass dies in der großen Masse lediglich Einzelfälle sind, und es geht auf keinen Fall darum, das gesamte „Software Projekt“ zu beschuldigen. Wir möchten jedoch jeden Einzelnen und jede Einzelne dafür sensibilisieren, auf solche Situationen zu achten und gegebenenfalls entschärfend einzuwirken.
68
69 Die Betroffenen bitte ich darum, das Thema nicht mit sich herumzutragen, sondern die möglichen Kontaktmöglichkeiten zu nutzen. Nur dann, wenn das Thema offensiv angegangen wird, besteht die Chance, dass die Sensibilität für das Thema steigt!
70
71 Nachfolgend werden einige Informationen über Diskriminierung & Gewalt, dessen "Alarmglocken", Präventionsmöglichkeiten, Handlungsempfehlungen und die Aufgaben der Erstberatung zur Verfügung gestellt.
72
73
74 [[Alarmglocken.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/77f8e3b871815948bb5180c5b8352c64/Alarmglocken.pdf]]
75
76 [[Aufgaben Erstberatung.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/200d5f87a9735bd80a33f4e6f7857156/Aufgaben_Erstberatung.pdf]]
77
78 [[Handlungsempfehlungen Bystander_14.04.23.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/e7087acff76030955fcd46acda65596e/Handlungsempfehlungen_Bystander_14.04.23.pdf]]
79
80 [[Prävention.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/cb6873a1ee8c216372356589dc8561b1/Pr%C3%A4vention.pdf]]
81
82 [[Sexualisierte Diskriminierung und Gewalt.pdf>>path:/SPB/softwareprojekt-wiki_all_v2/-/wikis/uploads/7d11cc3e96658ddfe2876a95b343a4b3/Sexualisierte_Diskriminierung_und_Gewalt.pdf]]
83
84 **Kontaktmöglichkeiten**
85
86 * Tutor/Tutorin der Gruppe
87 * Dozent der Veranstaltung
88 * Fachschaft Informatik: [[https:~~/~~/fachschaft-informatik.de/>>url:https://fachschaft-informatik.de/]]
89 * Dezentrale Gleichstellungbeauftragte der Informatik: [[https:~~/~~/uol.de/informatik/department/gremien-beauftragte/beauftragte>>url:https://uol.de/informatik/department/gremien-beauftragte/beauftragte]]
90 * Direktor/Direktorin des Departments: [[https:~~/~~/uol.de/informatik>>url:https://uol.de/informatik]]
91 * conTakt: [[https:~~/~~/uol.de/contakt-beratungsstelle>>url:https://uol.de/contakt-beratungsstelle]]
92
93 = Anforderungen: Einzelleistungen und Einzelaufgaben =
94
95 Neben der eigentlichen Softwareentwicklung gibt es spezielle Aufgaben, die von den Teammitglieder als Querschnittsaufgaben übernommen werden müssen. Diese Spezialisten und Verantwortlichen arbeiten sich in das Thema ein, beraten die Mitglieder der Gruppe und sorgen dafür, dass die Anforderungen an diese Aufgabe eingehalten werden. Die Aufgaben können dabei von einzelnen Personen oder auch zu zweit übernommen werden.
96
97 Die Vorträge für die Einzelaufgaben des ersten Blocks müssen auf jeden Fall im ersten Semester, am besten innerhalb der ersten 7 Wochen durchgeführt worden sein!
98
99 Die Einzelaufgaben sollten **erst beim zweiten Treffen** vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet.
100
101 == Einzelaufgaben/Rollen (müssen vergeben sein) ==
102
103 * Scrum-Master:
104 ** Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
105 ** Kurze Zusammenfassung zu [[Scrum>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/30515755/Scrum]], ausführlicher in den Folien der VL.
106 ** Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
107 ** Diese Rolle ist mit die wichtigste Rolle im SWP und verlangt durchgehend sehr viel Kapazität. Ein Scrum-Master ist aus diesem Grund typischerweise weniger (aber trotzdem noch) an der Implementierung beteiligt.
108 ** Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
109 ** Der Scrum-Master kann während des gesamten Projekts hinweg an einem monatlichen **Scrum-Master-Treffen** teilnehmen (nähere Informationen werden im Workshop mitgeteilt) - die Teilnahme ist empfohlen.
110 ** Aufwand: Sehr hoch
111 * Jira, Projektplanung und Productowner:
112 ** Scrum hat das Problem, dass man beliebig "herumiterieren" kann. Diese Rolle soll dafür sorgen, dass das "Große und Ganze" nicht aus den Augen verloren geht. Die grundlegend definierten Meilensteine sollten dabei um weitere Meilensteine ergänzt werden. Diese Meilensteine sollen dabei helfen, Sprintziele zu definieren.
113 ** Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen.
114 ** [[Projekttagebuch>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393398/Projekttagebuch]] führen
115 ** Stundenzettelpflege überwachen
116 ** Ggf. kann das Jira-Plugin: Portfolie verwendet werden.
117 ** Weiterhin soll diese Person als Ansprechpartner für Jira dienen, d.h. sie sollte sich besonders informieren und ggf. bei Fragen und Problemen beratend zur Seite stehen.
118 ** Product Owner
119 ** NEU: Diese Rolle sollte vorrangig mit dem Tutor die Scrum-Rolle des Productowners übernehmen, d.h. die Person kontrolliert, ob immer genug Tickets im Backlog vorliegen und macht ggf. eine Priorisierung der Tickets.
120 ** NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind
121 ** NEU: Die Rolle sorgt dafür, dass kleinere Teilgruppen (**Ticket-Task-Force**) dafür sorgen, dass neue Tickets formuliert und Ticketbeschreibungen verbessert werden (Backlogrefinement). Die Teilnehmer der Teilgruppen dürfen nicht über den ganzen Durchgang gleich bleiben sondern muss im Laufe der Zeit wechseln. Sollte die Gruppe sich gegen eine Ticket-Task-Force entscheiden, können die Tickets und Ticketbeschreibungen auch in der gesamten Gruppe gemeinsam erarbeitet werden.
122 ** Aufwand: Hoch
123 * Konfliktmanagement
124 ** Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
125 ** Diese Rolle soll sich im Vorfeld (also bevor etwas "schief" geht), damit befassen, welche Methoden und Ansätze es gibt, in Gruppen mit solchen Konflikten umzugehen.
126 ** Es macht Sinn, dass es jemanden zweiten gibt, der sich als Stellvertreter ebenfalls mit dieser Aufgabe befasst, falls die Person, die diese Rolle eigentlich inne hat, selber der Auslöser eines Konfliktes ist.
127 ** Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden.
128 * Git/Bitbucket
129 ** Der Inhaber kennt sich mit Git und Bitbucket aus.
130 ** Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
131 ** Der Inhaber dieser Rolle sollte sich auch darum kümmern, dass der Git-Workflow (Ticket → Branch → PR → Mergen) eingehalten, dass Pull-Requests sinnvoll abgearbeitet werden und nicht zu lange liegen bleiben.
132 ** Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben.
133 ** Aufwand: Initial höher, zum Ende hin weniger.
134 * Codequalitätsbeauftragter und Patternbeauftragter
135 ** Überwachung von Codierungsstandards
136 ** Kennt sich mit Refactorings aus
137 ** Kennt sich mit Code-Smells aus, also, was macht guten und was macht schlechten Code aus
138 ** Kennt sich mit Tools wie: FindBugs, Checkstyle und SonarLint/Sonarqube aus.
139 ** Soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten
140 ** Die Gruppe bei der Anwendung der Pattern unterstützen
141 ** Den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
142 ** Aufwand: Mittel
143 * Reviewbeauftragter
144 ** Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen
145 ** Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
146 ** Zusammen mit dem Git- und dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Pull-Requests zuständig.
147 ** Aufwand: Geringer
148 * Testbeauftragter:
149 ** Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
150 ** Die Person stellt ggf. Mockito und JUnit vor
151 ** Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an
152 ** Die Person muss dafür sorgen, dass Tests nicht vernachlässigt werden, hat also regelmäßig einen Blick auf die aktuelle Testabdeckung und weist ggf. Personen darauf hin, dass bestimmte Codeabschnitte noch (besser) durch Tests abgedeckt werden müssen.
153 ** Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
154 ** Aufwand: Mittel
155 * Dokumentations- und Backupbeauftragter, Confluence, LaTeX-Beauftragter
156 ** Sorgt dafür, dass die passenden Dokumente erstellt, mitgepflegt und gesichert werden (kein Doku Sklave!)
157 ** Erstellung/Anpassung von Vorlagen, Hilfe
158 ** Musterdokumente, Standards, Ablagestrategie, Qualitätssicherung, Bereitstellungsstrategie
159 ** Die Rolle achtet darauf, dass Dinge die fertig sind, auch bereits dann ausreichend dokumentiert werden.
160 ** Aufwand: Mittel
161 * Entwicklungsumgebung, Maven, Bamboo und Infrastruktur
162 * Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur
163 ** Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung
164 ** Kümmert sich um die Builds in Bamboo (Anpassen von Plänen)
165 ** Kümmert sich um die Bereitstellung des Servers in der Arbi
166 ** Aufwand: Mittel
167 * GUI-Beauftragter
168 ** Da i.d.R. noch nicht viel Erfahrung im Bereich der Entwicklung von Oberflächen besteht, soll sich diese Rolle intensiv mit JavaFX auseinandersetzen
169 ** Die Rolle soll Wissen grundsätzlich zu JavaFX aufbauen und als Ansprechpartner bei Fragen und Problemen dienen.
170 ** Ganz wichtig sind in diesem Kontext auch Do and Don'ts, d.h. man sollte sich auch über Best-Practices bei JavaFX informieren.
171 ** Aufwand: Mittel (je nach angestrebter GUI auch Hoch).
172
173 === Projekttagebuch ===
174
175 Im Projekttagebuch werden kurz und knapp die Ergebnisse der Sprints festgehalten und der Ablauf der Projekte als Ganzes dokumentiert.
176
177 Für jeden Sprint wird hier geschrieben,
178
179 * welche Stories umgesetzt wurden.
180 * wie das Review gelaufen ist.
181 * wie die Retrospektive gelaufen ist und welche Maßnahmen ergriffen worden sind, um Probleme im nächsten Sprint zu reduzieren.
182
183 Außerdem:
184
185 * Wann wurden Meilensteine erreicht
186 * Wann wurden Meilensteine verschoben und (ganz wichtig!) was waren die Gründe dafür
187 * Wann wurden andere wichtige Zwischenziele erreicht
188 * Welche besonderen Dinge hat es gegeben, die wesentlichen Einfluss auf das Projekt oder die Gruppe hatten
189
190 == Einzelaufgaben/Rollen (je nach Bedarf) ==
191
192 * Progammierkonzepte
193 ** z.B. Dependency Injection mit Guice
194 * Google Guava
195 * DB-Zugriff:
196 ** Installation/Überwachung der DB
197 ** JDBC
198 * Spezialisten für verschiedene Teilthemen:
199 ** Netzwerkkommunikation
200 ** Regeln des aktuellen Spiels
201 ** Weitere Frameworks
202
203 = Anforderungen: Wechselnde Aufgaben innerhalb der Gruppe =
204
205 Diese Aufgaben wechseln wöchentlich:
206
207 * Sitzungsleitung und Moderation
208 ** Leitung der Gruppensitzung (Wichtig!!), Support durch Scrum-Master
209 ** Tagesordnung definieren (vorher)!!
210 ** Ein Moderator ist dafür zuständig, dass die Sitzungen geregelt ablaufen, d.h. insbesondere muss ein Moderator darauf achten, dass die Teilnehmer sich an die Regeln (siehe: [[Spielregeln in der Gruppe>>url:https://confluence.swl.informatik.uni-oldenburg.de/spaces/SWP/pages/393414/Spielregeln+in+der+Gruppe]]) halten, jeder Sprechzeit bekommt und eine Kommunikation möglich ist, d.h. im Zweifelsfall auch Diskussionen zu unterbrechen. 
211 Hier gibt es weitere Hinweise zu der Aufgabe eines Moderators: [[https:~~/~~/www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html >>url:https://www.openpr.de/news/1231293/Was-sind-die-Aufgaben-eines-Moderators.html%C2%A0]]
212 * Protokollführung
213 ** Erstellung eines Protokolls der Gruppensitzung
214 ** Hier reicht i.d.R. ein Ergebnisprotokoll
215 ** Protokolle müssen im Confluence abgelegt sein
216 * Zu Beginn jeder Gruppensitzung („Daily Scrum“):
217 ** findet ein kurzes „Briefing“ („Blitzlicht“) statt, in der jede/r berichtet, was sie/er in der letzten Woche für das Projekt getan hat.
218 * Am Ende jeder Sitzung neue Aufgabenverteilung
219 ** Tickets (wer macht was)
220 ** Leitung/Protokoll (Liste!)
221 * Tutor ist nur Berater, leitet keine Sitzungen, kann aber um Rat gefragt werden (und greift (zu Beginn mehr und Ende weniger) ein, wenn es zu sehr „aus dem Ruder läuft“, erlaubt aber auch Fehler …)