Vorgehensmodell - derElias/udvide-Organisation GitHub Wiki
Scrum
In einem zu Beginn durchgeführten Kick Off Meeting einigten sich die Projektgruppe auf das Vorgehensmodell des Projektmanagements Scrum.
Dabei wurde folgende Rollenverteilung festgelegt:
- Product Owner: M.Sc. Toni Fetzer vertritt den Kunden des Projekts, nimmt an Sprint Reviews teil, stimmt dem Product Backlog und jeweiligen Sprint Backlogs zu.
- Scrum Master: Lukas Ziegler führt Scrum-Regeln ein und wacht über deren Einhaltung, behebt Störungen des organisatorischen Projektablaufs und achtet auf eine gelungene Kommunikation sowohl innerhalb des Teams als auch mit dem Product Owner
- Entwicklerteam: Nicolae Ababei und Siegfried Sehne sowie Elias Riedel, Simon Janssen und Lukas Ziegler setzen die Produktfunktionalitäten in zwei separaten Entwicklergruppen für die mobile Anwendung und den Webserver um. Dabei entscheiden sie selbstständig wie einzelne Eigenschaften zu implementieren sind. Sie schätzen den Arbeitsaufwand der Einträge im Product Backlog und ordnen sie in Tasks, die wiederrum den einzelnen Sprints zugewiesen werden.
Die einzelnen Sprints dauern zwei Wochen. Ein tägliches Daily Sprint Meeting findet nicht statt. Das Projektteam trifft sich innerhalb des Semesters jeden Montag und Mittwoch, um aktiv am Projet zu arbeiten. Zu Beginn jedes Treffens informiert jedes Mitglied des Entwicklerteams die anderen über seinen Fortschritt, die aufkommende Probleme, die ihm an der weiteren Umsetzung hindern könnten und was er sich in diesem Arbeitsabschnitt vorgenommen hat. Dabei wird auch geklärt ob eine bearbeitete Teilaufgabe wie vorgesehen durch das Teammitglied erreicht werden kann oder ob diese aufgeteilt oder evtl. von anderen Teammitgliedern mit übernommen werden sollte.
Jeden zweiten Mittwoch trifft sich das Team zu einem Sprint Review. Bei diesem präsentiert das Entwicklerteam das Ergebnis der aktuellen Sprintiteration dem Product Owner. Dieser gibt dem Entwicklerteam eine Rückmeldung über die implementierten Produkteigenschaften und nimmt diese im Fall der Fertigstellung ab. Sollte eine Aufgabe nicht zur Zurfriedenheit fertig gestellt worden sein, wird diese mit hoher Priorität in einen folgenden Sprint übernommen. Während dieses Treffens wird das Product Backlog überarbeitet und verfeinert sowie Aufgaben für das nächste Sprint Backlog definiert. Zudem werden Termine festgelegt.
Direkt im Anschluss findet innerhalb der Projektteams eine Sprint Retrospektive statt. Dabei wird die Arbeitsweise des Teams hinterfragt und ehrliche Kritik an der Art der Zielerreichung geübt. Es werden neue Praktiken und Methoden besprochen und gegebenenfalls eingeführt. Nicht genutzte Arbeitsweisen, oder solche die sich als nicht effektiv herausstellten werden ausdrücklich im Team abgelehnt. Eine Verbesserung, die innerhalb einer Retrospektive erarbeitet wurde ist beispielsweise der Einsatz von Pair Programming, das Veranstalten von Projekttagen, dieses Repository, dessen Wiki, und das regelmäßige Einpflegen der Aufgaben.
In unregelmäßigen Abständen veranstaltet das Team Projekttage an denen nur an einer einzigen größeren Teilaufgabe gearbeitet und diese im gesamten Team abgeschlossen wird. Dabei werden auch Entscheidungen von großer Tragweite getroffen, an denen jedes Teammitglied beteiligt werden muss. Beispielhaft dafür ist das Entwickeln verschiedener Prototypen für die unterschiedliche Augmented Reality Frameworks vuforia und ARToolkit sowie die Entscheidung für ein 3-Tier-Architekturmodel unter Einbeziehungt des Vuforia Cloud Services. Beim nächsten Sprint Review wird der Product Owner über die getroffenen Entscheidungen informiert.
Pair Programming
Um Verständigungsproblemen durch unterschiedliche Vorkenntnisse aus dem Weg zu gehen setzt das Entwicklerteam die agile Methode der Paarprogrammierung ein. Dabei einigt sich das Team auf ein Vorgehen anhand von UML-Diagrammen, die zusammen am Whiteboard entwickelt werden. Anschließend beginnt ein Teammitglied mit der Codierung während es von einem anderen unterstützt und kontrolliert wird. Auftretende Schwierigkeiten werden im Gespräch gelöst. Die Rollenverteilung wird je nach Aufgabe neu gewählt, da die Mitglieder unterschiedlich spezialisiert sind. So kann das Risiko von Implementierungsfehlern verringert werden und es findet ein Wissenstransfer innerhalb der Gruppe statt.