Summer of Code 2021 – Unser Praktikum bei Zweitag

Der Start

Am 16. August ging es los: wir – 5 (Wirtschafts-)Informatik Studierende der Uni Münster – starteten beim diesjährigen Summer of Code bei Zweitag. Der Summer of Code (oder auch Winter of Code) ist ein achtwöchiges Praktikum, bei dem gemeinsam im Team und betreut durch professionelle Entwickler:innen eine Applikation entwickelt wird. Ziel ist es, praktische Erfahrungen in der Web-Entwicklung zu machen – etwas, das im Informatik-Studium neben der ganzen Theorie gern etwas zu kurz kommt.

Glücklicherweise kann der Summer of Code unter Einhaltung der Hygienerichtlinien bisher in Präsenz stattfinden. Das macht sowohl das Kennenlernen der Kolleg:innen, als auch die Zusammenarbeit persönlicher und es ist für uns alle interessant, den “echten” Alltag im Office samt gemeinsamer Mittagspause zu erleben – auch, wenn nicht so viele Mitglieder des Zweitag-Teams wie sonst üblich anwesend sind.

Der erste Block – die Grundlagen

Bei Zweitag wird im Front- und Backend mit zahlreichen Technologien wie JavaScript, HTML/CSS, Ruby und Elixir gearbeitet. Unser Einstieg fokussierte sich erst einmal darauf, Ruby on Rails kennenzulernen. Damit hatte noch keiner von uns zuvor Berührungspunkte.
Ein wichtiges Takeaway aus den ersten Wochen war der Grundsatz “standing on the shoulders of giants”. Frei nach Isaac Newton hieß das für uns, dass wir unsere Arbeit auf eine Menge bestehendes Wissen aufbauen können.
In der Softwareentwicklung ist das besonders essentiell: beim Aufsetzen unserer Rechner wurde schnell klar, dass wir uns so viel Aufwand und zahlreiche Probleme ersparen können, wie beispielsweise die Versionsverwaltung und das Vermeiden der “dependency hell” (Softwarepakete, die Abhängigkeiten von unterschiedlichen Versionen anderer Softwarepakete aufweisen und sich damit in die Quere kommen). Die gewonnene Zeit kann man dann direkt für die Entwicklung des eigentlichen Produkts nutzen.
Auch Rails hat uns beeindruckt – erstellt man ein Rails-Projekt, wird nach dem Grundsatz “convention over configuration” die passende Projektstruktur mit allen notwendigen Ordnern kreiert, die dann “nur” noch mit passenden Dateien/Code befüllt werden müssen, was erneut erheblich Zeit und Aufwand spart, sodass man direkt mit Coden loslegen kann.

Zusätzlich haben wir von Andrej Input zum Thema nutzerzentrierte Produktentwicklung erhalten. Er brachte uns unter anderem die Methoden Value Proposition Canvas, Personas und Product Vision Board näher. Die haben uns später dabei geholfen, ein geeignetes Projekt aus unseren Vorschlägen auszuwählen.
Zudem unterstützte uns Johannes dabei, noch einmal unsere HTML- und CSS-Kenntnisse aufzufrischen. Damit waren wir dann startklar für die Entwicklung der Frontend-Seite unseres Projektes.

Die Auswahl der Projektideen

Im Lauf der ersten Wochen entwickelten sich einige Projektideen aus denen sich am Ende drei Favoriten herauskristallisierten: der Spotify Matcher (SM), der Social Media Aggregator (SMA) und die Zweitag Knowledge Base (ZKB).
Der Spotify Matcher sollte eine Web-Applikation zur Erstellung gemeinsamer Playlisten sein. Die Anwendung sollte dabei die vorhandenen Spotify-Funktionen für solche Listen erweitern. Beispielsweise durch die automatische Erzeugung von Playlists durch mehr als zwei Nutzer oder  die Möglichkeit, bestimmte Genres, vorausgewählte Songs oder die meistgespielten Songs der User einfließen zu lassen.

Der Social Media Aggregator sollte dazu dienen, die Top Trending Posts auf diversen sozialen Medien übersichtlich und nach verschiedenen Kriterien filterbar auf einer Seite darzustellen. So würde ein kurzer Blick auf den SMA ausreichen um informiert zu bleiben, ohne dass man die zahlreichen Seiten einzeln besuchen muss.

Die Zweitag Knowledge Base sollte eine Seite sein, auf der jeder im Zweitag-Team Blogposts mit Hintergrundwissen oder schlauen Lösungen für gängige Probleme erstellen kann. Am Besten mit einer Anbindung an Slack, sodass neue Posts direkt im internen #knowledge Channel angekündigt und verlinkt werden.

Um unsere Ideen zu konkretisieren, haben wir zuerst ein Product Vision Board für die ZKB erstellt:

Nachträglich haben wir aber festgestellt, dass der Value Proposition Canvas für unsere Zwecke besser geeignet ist. Das Product Vision Board umfasst auch Business Goals, die für unser Projekt eher zweitrangig sind, während es beim Value Proposition Canvas fokussierter um den Kunden und damit die wichtigsten Features des Produkts geht.

Zudem haben wir zu den Projekten passende Personas gestaltet, also fiktionale mögliche Kund:innen, die typische Vertreter:innen unserer Zielgruppen darstellen.

Dadurch wurden uns mehr Features und mögliche Kundenbedürfnisse bewusst, die wir vorher noch nicht berücksichtigt hatten.

Nachdem wir nun also konkrete Vorstellungen zu den möglichen Projekten hatten, haben wir abgestimmt. Im Stechen zwischen dem Spotify Matcher und der Zweitag Knowledge Base konnte sich dann letztere mit 3:2 durchsetzen, auch, da sie sich unserer Ansicht nach besser zum agilen Arbeiten eignet.
Zuerst wollten wir ein Minimum Viable Product umsetzen, wobei es darum geht, die grundlegende Funktionalität anforderungsgerecht umzusetzen. Mit Hilfe von User Stories wird die Knowledge Base so iterativ-inkrementell weiterentwickelt.

Diese Entscheidung fiel am Ende der dritten Praktikumswoche. Danach winkte erst einmal eine anderthalb wöchige Praktikumspause. Unsere Semesterferien sind auch neben dem Praktikum ziemlich vollgepackt: sei es das Schreiben von Seminar- oder Bachelorarbeiten oder das Besuchen des Hochschulsport-Surfcamps, wir alle haben die Pause genutzt sodass nun die Umsetzung der ZKB mit frischem Wind in den Segeln starten kann.

Der zweite Block – die Umsetzung der Anwendung

Nun beginnt die Arbeit am eigentlichen Projekt:
Die ZKB soll neben den grundlegenden Features wie der Post-Erstellung und dem Suchen nach Posts via Tags (wie Ruby, Rails, Flutter, …) das Wissen, das bisher im Slack-Channel #knowledge nur sequentiell und unsortiert erscheint, kategorisiert und gezielt durchsuchbar machen.
Wenn ein Artikel auf der ZKB veröffentlicht wird, soll er automatisch durch eine entsprechende Slack-Integration in #knowledge gepostet werden.
Idealerweise kann in einer finalen Version den Thread, der dazu im Slack entsteht, ebenfalls in die ZKB synchronisiert werden.

Nachdem wir diese Woche schon die User Stories und Wireframes für die ZKB erstellt und das Projekt mit Rails aufgesetzt haben, folgt in den restlichen 4 Wochen des Praktikums die Umsetzung.

Wir freuen uns schon darauf, weiter daran zu arbeiten und am Ende das Ergebnis mit dem Zweitag-Team zu teilen :)

‍