In unserem letzten Blogpost konntet ihr bereits die in unserem Projekt verwendete KI kennen lernen. In diesem Blogpost geht es nun um die Zusammenarbeit innerhalb des Projekts. Hierbei haben wir einige Produkte und Tools verwendet, um unsere Zusammenarbeit zu unterstützen. Im Folgenden werden die Tools und unsere Erkenntnisse innerhalb des Projekts genauer vorgestellt.

Quelltextverwaltung mit Git

Zur Verwaltung aller Quelltexte haben wir Git verwendet. Wir haben uns dabei für Gitlab als Hoster unseres Git-Repositories entschieden, da wir dort private Repos anlegen konnten. Nach dem initialen Set-Up konnten wir dann unseren Code teilen, verwalten und versionieren. Außerdem stellt Gitlab ein Tool zur Verwaltung von User Stories bereit. Dieses haben wir daher zur Verwaltung aller im Projekt angefallenen Aufgaben verwendet. Somit konnten jedem Gruppenmitglied Aufgaben zugeteilt werden und der Status dieser getrackt werden.

Gitlab stellt außerdem interessante Diagramme zur Analyse des Quellcodes bereit.

So sieht man auf der obigen Abbildung, dass der größte Teil unseres Projekts aus JavaScript Code bestand. Das passt auch dazu, dass wir unser Backend und Frontend mit JavaScript umgesetzt haben. Den restlichen Teil bildet die Bilderkennung und alle hardwarenahen Funktionen mit Python und Adruino. Die Summe der geschriebenen Codezeilen ist auf alle Bereiche gleichverteilt.

Außerdem können wir anhand der Verteilung der Commits sehen, dass wir in den Präsenzstunden am produktivsten waren.

Abstimmung innerhalb der Gruppe

Eigentlich wollten wir am Anfang keinen der Präsenztermine wahrnehmen. Daher haben wir beschlossen alle Arbeiten remote durchzuführen. Zu Abstimmung wollten wir (Video-)Konferenzen verwenden. Schnell war eine WhatsApp-Gruppe zur allgemeinen Diskussion und ein Discord-Channel zur Durchführung von Konferenzen erstellt. Aber nach den ersten paar Wochen merkten wir, dass die Zusammenarbeit so nicht ganz funktioniert.

Also beschlossen wir, dass wir uns jeden Montag zur gemeinsamen Abstimmung und zum gemeinsamen Vorantreiben des Projekts treffen. Gesagt, getan: Wir machten schnellere Fortschritte und konnten uns bis ins kleinste Detail abstimmen. Insbesondere die Kombination aller Komponenten in eine erste lauffähige Demo bereitete uns dabei viel Kopfzerbrechen.

Hardwarechaos

Innerhalb unserer Zusammenarbeit erkannten wir immer neue Fallstricke. Plötzlich funktionierte der MySQL-Server auf dem RaspberryPi nicht mehr. Ein anderes Mal mussten wir eine Möglichkeit suchen ein lokales Netzwerk aufzubauen, innerhalb dem wir per SSH kommunizieren konnten. Das DHBW Netzwerk konnten wir dazu nicht verwenden, da die Kommunikation zwischen den einzelnen Clients in diesem untersagt war. Zum Glück konnten uns schließlich die Mitarbeiter des WI-Labors einen HotSpot zur Verfügung stellen, mit dessen Hilfe wir unser Projekt weiterentwickeln und testen konnten.

Retrospektive

Entsprechend der in Scrum enthaltenen Sprint-Retrospektive können wir folgende Verbesserungsvorschläge und Leitsätze zur Arbeit in unserem Projekt festhalten:

  • Digitale Abstimmung ist praktisch. Sie kann bei komplexen Projekten aber nicht die realen Treffen ersetzen.
  • Diskussionen sind mindestens genauso wichtig wie die eigentliche Entwicklung der Anwendung. Gerade wenn viele Schnittstellen und Abhängigkeiten in einem Softwareprojekt existieren, macht eine gute Abstimmung den Unterschied zwischen Erfolg und Fehlschlag.
  • „Learn to fail“: Innerhalb der Gruppe müssen Fehler gemeinsam diskutiert und behoben werden. API-Definitionen müssen teilweise geändert werden. Geplante Vorgehensweisen müssen manchmal als unpassend verworfen und verbessert werden.
  • Overengineering ist ein Projektkiller. Softwareprojekte sind komplex, werden die verwendeten Technologien und Entwicklungsobjekte dann auch noch so komplex wie möglich gewählt und umgesetzt, kann ein Projekt nur fehlschlagen.
  • Abschließend darf niemals die Komplexität der Integration aller Komponenten innerhalb von IoT-Projekten vergessen werden. Wir haben diese Unterschätzt und daher viel Zeit für die eigentlich Erstellung unseres Prototyps aufwenden müssen.
SmartLock (8) – Der ganz normale Projekthorror 😊