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 ­čśŐ

Schreibe einen Kommentar

Zur Werkzeugleiste springen