Umsetzung / Implementierung

Convo Entwicklungszyklus – Teil 4

Einleitung

In den vorangegangenen Blogbeiträgen haben wir gesehen, wie eine neue Story zunächst fachlich und anschließend aus User-Experience-Sicht spezifiziert wird. Damit können wir uns jetzt dem nächsten Schritt widmen und uns in diesem Blogartikel die technische Umsetzung eines neuen Features ansehen. Hierbei werden wir weiter die Optimierung der Vorschau im Produkt Convo als Beispiel verwenden und dabei darauf eingehen, welche Schritte entwicklungsseitig ablaufen, bis ein Feature vollständig umgesetzt und zum Test bereit ist.

Schritt 1: Vorbereitung

Wenn wir mit der Umsetzung eines neuen Features beginnen, liegen uns zunächst die Ergebnisartefakte aus den vorangegangenen Schritten vor, die spezifizieren, was umgesetzt werden soll.

Dabei handelt es sich zum einen um das Ticket, in dem die fachlichen Anforderungen u. a. mittels Akzeptanzkriterien beschrieben sind und zum anderen um das UX-MockUp, das Design und Benutzerführung darlegt. Als erstes sollten wir diese beiden Dokumente noch einmal gründlich durchgehen und schauen, ob noch Unklarheiten bestehen. Eigentlich sollte dies aufgrund des vorangegangenen Refinements zwar nicht mehr der Fall sein, allerdings kann es durchaus mal dazu kommen. Für diesen Fall ist es wichtig die offenen Punkte frühzeitig zu klären, um nicht in die falsche Richtung zu entwickeln. Generell bleibt der Kontakt zu PO und UX während der gesamten Entwicklung bestehen, um auftretende Fragestellungen direkt zu klären. Solche kurzen Abstimmungen, ganz im agilen Geist, sind deutlich effizienter als nach Abschluss der Entwicklung festzustellen, dass ein Großteil des Features noch einmal überarbeitet werden muss. Neben möglichen Unklarheiten muss zudem geprüft werden, ob alle benötigten Zulieferungen vorhanden sind. In unserem Anwendungsfall wären solche Zulieferungen zum Beispiel die Geräte-Icons im Header oder die Bezeichnungen der Farben.

Fortschritt im Blick durch kleine Arbeitspakete

Nachdem wir uns nun einen Überblick verschafft haben, was genau umgesetzt werden muss, und eventuelle Fragen bzw. fehlende Zulieferungen beseitigt haben, können wir uns überlegen, wie wir das Feature umsetzen. Gerade bei größeren Features ergibt es hier Sinn, noch einmal zu schauen, ob eine Aufteilung in kleinere Arbeitspakete möglich ist. Blicken wir wieder auf unser Beispiel, so lässt sich dieses in drei Pakete aufteilen: Die Umsetzung des Sidepanels mit den Farben auf der linken Seite, die Headerleiste mit der Geräteauswahl und den mittleren Bereich mit der eigentlichen Vorschau und dem umgebenden Geräterahmen. Der Vorteil der kleineren Arbeitspakete liegt insbesondere darin, dass wir diese deutlich besser überblicken und zudem auch unseren Gesamtfortschritt besser abschätzen können. Damit haben wir jetzt eine Struktur und einen groben Fahrplan, wie wir bei der Umsetzung vorgehen.

Hatten wir das schon einmal?

Bevor wir aber mit der tatsächlichen Umsetzung starten, lohnt sich noch ein Blick auf den technischen Plan für die Umsetzung. Für diesen sollten wir uns überlegen, welche Komponenten es bereits gibt, die nur angepasst werden müssen und welche wir komplett neu implementieren müssen. Darüber hinaus sollten wir uns die Frage stellen, ob wir an anderer Stelle in der Anwendung bereits mit ähnlichen Herausforderungen zu tun haben, sodass wir Code wiederverwenden können und keinen duplizierten Code erzeugen. Im Anwendungsfall fällt beispielsweise auf, dass das Dropdown bei der Geräteauswahl in ähnlicher Form bereits bei der Sprachauswahl existiert. Darüber hinaus können wir feststellen, dass die Farbauswahl im linken Sidepanel bereits vorhanden ist und wir sie nur an die neuen UX-Vorgaben anpassen müssen, die Geräteauswahl im Header hingegen gibt es noch nicht. Mit diesen Feststellungen können wir nun für die einzelnen Arbeitspakete besser abschätzen, was im Detail zu tun ist.

Damit haben wir nun eine Reihe von Überlegungen angestellt, bevor wir überhaupt mit der tatsächlichen Entwicklung angefangen haben. Diese Überlegungen und Feststellungen dienen vor allem dazu Struktur in die Umsetzung zu bringen und so nicht während der Umsetzung von Unklarheiten überrascht zu werden. Gleichzeitig helfen sie den eigenen Fortschritt im Blick zu behalten und möglichst effizient vorzugehen.

Schritt 2: Entwicklung

Zu Beginn der tatsächlichen Implementierung des Features müssen wir zunächst einen so genannten Feature-Branch anlegen. Dabei handelt es sich – vereinfacht gesagt – um eine Kopie des aktuellen Entwicklungsstandes. Diese Kopie können wir beliebig bearbeiten und so unser neues Feature hinzufügen. Sobald wir fertig sind, wird dann der Feature-Branch in den eigentlichen Entwicklungsstand übernommen. Durch dieses Vorgehen sind wir, während der Entwicklung unabhängig von Änderungen am Entwicklungsstand durch andere Entwickler und können ungestört an unserem Feature arbeiten. Außerdem gelangen so nur fertige Features und keine unvollständigen Zwischenstände auf den allgemeinen Entwicklungsstand.

Auf dem neuen Feature-Branch können wir nun unsere einzelnen Arbeitspakete Schritt für Schritt umsetzen. Das wichtigste Tool, das uns hierbei unterstützt, ist unsere Entwicklungsumgebung, in unserem Fall IntelliJ.

IntelliJ bietet uns eine Vielzahl von unterstützenden Funktionen, die uns bei der Entwicklung helfen. So gibt es beispielweise ein Syntax Highlighting, das Schlüsselwörter im Code in verschiedenen Farben hervorhebt und diesen so leichter zu lesen macht. Darüber hinaus wird eine Code Completion angeboten, die sobald man anfängt zu tippen auswählbare Eingabevorschläge anzeigt und so die Anzahl der Tastaturanschläge maßgeblich verringert. Stellvertretend sei zudem noch die Einbindung der Versionsverwaltung, in unserem Fall Git, genannt, mit der wir u. a. Feature-Branches erstellen und Änderungen an diesen hochladen können.

Bin ich der erste mit dem Problem?

Während der Entwicklung des Features werden wir unter Umständen an einen Punkt kommen, an dem wir nicht genau wissen, wie wir die Anforderungen technisch umsetzen können. Im Anwendungsfall kann es beispielsweise sein, dass wir nicht sicher sind, wie wir die Geräterahmen am besten einbinden. Diese als SVGs von UX gelieferten Dateien, sollen ja so angezeigt werden, dass in ihnen die eigentliche Vorschau dargestellt wird. Hier gilt, dass in den meisten Fällen bereits jemand ein ähnliches Problem gehabt haben wird und eine einfache Internet-Recherche bereits helfen kann. Insbesondere Foren wie StackOverflow, auf denen Entwickler sich gegenseitig helfen können, sind hier besonders hilfreich . Darüber hinaus kann alternativ auch eine Frage im Kollegenkreis, beispielweise bei Entwicklern aus anderen Projekten, zur Lösung führen.

Neben der Implementierung des eigentlichen Features gehört auch das Ermitteln und Erstellen von notwendigen Tests. Da hierauf allerdings im nächsten Blogbeitrag gesondert eingegangen wird, sei es an dieser Stelle einmal ausgeklammert. Entsprechend können wir, nachdem das Feature vollständig implementiert ist, unseren Feature-Branch zurück auf den allgemeinen Entwicklungsstand überführen. Hierfür stellen wir einen so genannten Merge-Request. Das erfolgt mit Gitlab in einem Tool, das wir bereits aus den vorherigen Blogbeiträgen kennen, da wir es u. a. auch für unsere Ticket-Verwaltung benutzen. Es bietet jedoch noch eine Vielzahl mehr Funktionen und hält so zum Beispiel auch unseren aktuellen Entwicklungsstand.

Schritt 3: Review

Nach der Fertigstellung der Implementierung unseres Features folgt eine Überprüfung des neuen Codes durch einen zweiten Entwickler. Hierfür wird diesem der Merge-Requests zugewiesen und er stimmt der Überführung unserer Änderungen auf den allgemeinen Entwicklungsstand erst zu, wenn er mit der Qualität einverstanden ist. Durch dieses Vier-Augen-Prinzip wird eine zusätzliche Qualitätssicherung geschaffen.

Der Reviewer schaut sich nun alle Änderungen am Code an und überprüft, ob er Verbesserungsvorschläge hat, wie zum Beispiel eine simplere Lösung für einen Teil unserer Implementierung. Des Weiteren prüft er, ob die Definition of Done eingehalten wurde. Dabei handelt sich um eine Reihe von Richtlinien, die einen sauberen und wartbaren Code garantieren. Im letzten Schritt schaut er sich das Ergebnis selbst an. Hierfür wird zusammen mit dem Merge-Request eine Review-Umgebung erstellt, die es möglich macht, sich die geänderte Anwendung anzusehen. Konkret prüft der Reviewer die Funktionalität des neuen Features sowie die Akzeptanzkriterien.

Findet der Reviewer Anmerkungen weist er uns den Merge-Request wieder zu und wir müssen diese zunächst anpassen, bevor wir erneut ein Review erbitten können. Sobald der Reviewer keine Anmerkungen mehr hat, approved er die technische Umsetzung des Features und weist den Merge-Request dem Product Owner zu. Dieser nimmt das Feature dann noch aus fachlicher Sicht ab und merged anschließend den Feature-Branch, wodurch er unsere Änderungen in den aktuellen Entwicklungsstand überführt. Das Feature ist technisch fertig implementiert.

Fazit

Das Feature mag nun technisch fertig umgesetzt sein, der komplette Softwareentwicklungsprozess ist jedoch noch nicht beschrieben. Hierzu fehlen noch Details zur Abnahme durch den PO sowie insbesondere zum Testvorgehen, das wir in diesem Artikel noch ausgeklammert haben. Diese Informationen werden in den kommenden Blogbeiträgen zu finden sein. Für die technische Umsetzung eines neuen Feature lässt sich abschließend aber festhalten, dass insbesondere ein strukturiertes Vorgehen und die Abstimmung mit den anderen Beteiligten zum Erfolg führt.