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 begleitet.

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 sein. 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 (>=14) 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.