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