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.
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!
Die Einzelaufgaben sollten erst beim zweiten Treffen vergeben werden. Vorher sollte sich jeder darüber informieren, was die Einzelaufgabe beinhaltet.
Einzelaufgaben/Rollen (müssen vergeben sein)
- Scrum-Master:
- Sorgt dafür, dass der Scrum-Prozess am Laufen bleibt
- Kurze Zusammenfassung zu Scrum, ausführlicher in den Folien der VL.
- Es sollte auf jeden Fall einen Stellvertreter geben, der ggf. die Rolle übernehmen kann (z.B. bei Krankheit oder Beendigung des SWPs).
- 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.
- Der Scrum-Master kann zu Beginn des Softwareprojekts an einem Workshop teilnehmen (Einladung erfolgt zu Beginn) - die Teilnahme ist empfohlen.
- 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.
- Aufwand: Sehr hoch
- Jira, Projektplanung und Productowner:
- 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.
- Projektplan/Meilensteinplan erstellen, aktualisieren und überwachen. Dabei ist es nicht notwendig, sowas wie ein Gant-Chart über das komplette Semester zu erstellen.
- Projekttagebuch führen
- Stundenzettelpflege überwachen
- Ggf. kann das Jira-Plugin: Portfolie verwendet werden.
- 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.
- Product Owner
- 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.
- NEU: Die Rolle sorgt dafür, dass in allen Tickets im Sprint Dod (Definition of Done) definiert sind
- 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 sollten im Laufe der Zeit wechseln.
- Aufwand: Hoch
- Konfliktmanagement
- Es kommt ab und zu vor, dass im SWP gruppeninterne Konflikte auftreten.
- 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.
- 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.
- Aufwand: Hängt massiv von der Gruppe ab ... Kann sehr wenig, kann aber auch sehr komplex werden.
- Git/Bitbucket
- Der Inhaber kennt sich mit Git und Bitbucket aus.
- Er kann in nicht Standard-Fällen helfen (z.B. wenn ein Mergen zu Konflikten führt)
- 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.
- Im Laufe der Zeit sollte diese Rolle weniger wichtig werden, da alle den Workflow verinnerlicht haben.
- Aufwand: Initial höher, zum Ende hin weniger.
Codequalitätsbeauftragter
Reviewbeauftragter
- Die Gruppe muss mindestens ein gruppenweites Code-Review durchführen
- Der Review-Beauftragte ist dafür zuständig, dieses Review anzuleiten und rechtzeitig zu initiieren.
- Zusammen mit dem Git- und dem Codequalitätsbeauftragtem für die sinnvolle Durchführung der Abarbeitung der Pull-Requests zuständig.
- Aufwand: Geringer
- Testbeauftragter:
- Der Testbeauftragte ist nicht dafür da, Tests zu schreiben!
- Die Person stellt ggf. Mockito und JUnit vor
- Testbautragte hilft dabei, Test zu schreiben, d.h. bietet Unterstützung bei Fragen an
- 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.
- Die Person sorgt dafür, dass Tests, die nicht automatisiert erstellt werden (z.B. Test von Oberflächen) dokumentiert werden.
- Aufwand: Mittel
Dokumentations- und Backupbeauftragter, Confluence, LaTeX-Beauftragter
Patternbeauftragter (ggf. auch zwei)
Diese Rolle soll sich in die wichtigsten Pattern (wie MVP, Observer, Command-Pattern) einarbeiten
und die Gruppe bei der Anwendung der Pattern unterstützen
- den Code darauf hin untersuchen, ob an bestimmten Stellen Pattern besser gewesen wären
- Aufwand: Geringer
- Entwicklungsumgebung, Maven, Bamboo und Infrastruktur
- Kümmert sich um die Erweiterung der vorgegebenen Maven Infrastruktur
- Hilft und Unterstützt bei der Auswahl und Einrichtung der Entwicklungsumgebung
- Kümmert sich um die Builds in Bamboo (Anpassen von Plänen)
- Kümmert sich um die Bereitstellung des Servers in der Arbi
- Aufwand: Mittel
Einzelaufgaben/Rollen (je nach Bedarf)
- Progammierkonzepte
- z.B. Dependency Injection mit Guice
- JavaFX und ControlsFX
- Google Guava
- DB-Zugriff:
- Installation/Überwachung der DB
- JDBC
- Spezialisten für verschiedene Teilthemen:
- Netzwerkkommunikation
- Regeln
- Weitere Frameworks