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.
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.
Da es wichtige Besprechungen (z.B. die Scrum-Meetings) statt finden, ist es unbedingt notwendig, dass alle Mitglieder regelmäßig da seinsind. 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.
Die Gruppen teilen sich intern in die folgenden Teilgruppen auf (Stichwort Model-View-Controller):
- Client/View: Diese Gruppe ist für den Spieleclient und die grafische Darstellung zuständig.
- Server/Modell: Die Gruppe kümmernt sich um das Model. Hier geht es um die eigentlich Logik des Spiels und den Dingen die damit zu tun haben (z.B. auch Nutzer und Chatnachrichten). Das Modell darf kein Wissen über die Ausprägung des Clients haben. Dies sorgt zum einen für eine einfachere Austauschbarkeit des Clients und zum anderen zu einer deutlich besseren Testbarkeit.
- Kommunikation: Diese Gruppe kümmert sich darum, dass der Client und der Server miteinander kommunizieren können. Die Schicht muss dabei so gekapselt werden, dass weder Client und Server wissen, wie sie miteinander kommunizieren (Stichwort: Facade)
In jeder Teilgruppe findet die Entwicklung mit Hilfe von Pair-Programming statt. Jede Teilgruppe trifft sich zusätzlich außerhalb der Gruppensitzung. In den Gruppensitzungen stellen die Teilgruppen wöchentlich ihre Konzepte, Ideen und ihren Stand vor. Jedes Mitglied der Gruppe muss mindestens einmal Dinge vorgestellt haben.
Die Einteilung der Gruppen sollte innerhalb eines Sprints nicht wechseln. Innerhalb des Gruppen sollte es eine ausgewogene Mischung von erfahrenen und weniger erfahrenen Mitgliedern geben. Die Gruppeneinteilung muss im Confluence dokumentiert werden. Die Ergebnisdokumente dort hochgeladen.
Große Gruppen
Wenn es zu große Gruppen gibt, findet eine Aufteilung in Untergruppen statt:
- Es gibt dann zunächst ein gemeinsames Treffen mit allen.
- Dabei die Einteilung in eine Gruppe Client und eine Gruppe Server, jeder Gruppe muss einen Scum-Master haben
- Die Gruppen einigen sich auf eine gemeinsame Sprint-Länge.
- Danach dann bitte volle Zeitstunden einplanen, 60 Minuten für die Client-Gruppe und 60 Minuten für die Server-Gruppe, d.h. Start und Ende ist dann auch immer um s.t.
- Es trifft sich immer erst die Server und dann die Client-Gruppe
- (Mindestens) Ein Mitglied der Client-Gruppe ist dann schon in der Server-Gruppe dabei
- (Mindestens) Ein Mitglied der Server-Gruppe bleibt in der Sitzung der Client-Gruppe dabei
- Zum Ende des Sprints
- gibt es wieder eine gemeinsame Sitzung und der Sprint wird abgeschlossen.
Die Retrospektiven finden wieder innerhalb der Teilgruppen statt.Neu: Die Retrospektiven sollten doch gemeinsam durchgeführt werden.- Danach können (müssen aber nicht) die Gruppen neu eingeteilt werden, es muss aber immer mindestens ein Scrum-Master in jeder Gruppe bleiben.
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!
Für den Einstieg ist es sinnvoll, Pairprogramming durchzuführen. Wichtig ist es dabei, dass die Commits die Informationen über das Pairprogramming enthalten.
Zusatztreffen
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 zu buchen. Dazu bitte an Olaf Wendt wenden.
Vorschlag für Ablauf
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-Aspekte, die auch in einem Scrum Workshop aufbereitet wurde. Wenn es die Mittel zulassen und es eine geeignete Person gibt, wird der Scrum Workshop angeboten.
