Start Small Principle – Best Practice Tipps für Workflows

[grossal]

Begriffe wie Scrum, KANBAN, Continuous Integration und DEVOPS begegnem einem als Entwickler dauernd, jedoch sind sie außerhalb der Entwickler-Bubble oft vollkommen unbekannt, obwohl der dahinterstehende Gedanke sich auf viele Bereiche übertragen lässt. Keine Sorge, sie müssen diese Begriffe, auch wenn sie als Links hinterlegt sind, nicht nachschauen. Ich werde alles zum Verständnis wichtige im Blog erklären, wenn sie sich genauer zu den einzelnen Verfahren informieren wollen, können Sie am Ende gerne zurückkehren und sich diese nochmal anschauen.

Typische Projekte

Vor allem als Deutscher ist es eigentlich typisch Projekte nach dem Wasserfall-Prinzip anzugehen. Zuerst werden Lasten- und Pflichtenheft erstellt, danach folgt Technik- und Design-Konzept – welche man idealerweise irgendwie miteinander vereinbaren kann und danach wird eine Timeline erstellt und dann geht das Programmieren los. Nach einigen Monaten ist das Produkt (Webseite, App, Software) dann laut Entwicklern fertig und wandert ins Qualitätsmanagement, welche dann via Jira und Co. all die Bugs und Fehler notieren. Nach einigen Iterationen und dem Beheben der größten Bugs geht das Produkt dann Richtung Kunden und alle hoffen, dass er damit zufrieden ist.

Vollkommen egal ob wir uns in der Softwarewelt oder in anderen Branchen bewegen, oft laufen Projekte mit diesem riesigen Planungsoverhead zu Beginn ab und bieten kaum Potential für Änderungen und Neu-Priorisierungen von Tasks im Projektverlauf. Es ist sicherlich nicht schlecht sich zu Beginn einmal Gedanken über alle Ziele des Projekts zu machen, aber dieses dann monatelang zu entwickeln bevor man erstmals Nicht-Entwickler darauf schauen lässt, ist oft ein Grund für viele Bugfixing-Iterationen. Der Gegenansatz lautet Agilität.

Agilität

Agile Methoden setzen sich zum Ziel nicht das ganze Produkt auf einmal zu entwickeln, sondern mit einem MVP – Minimal valuabe product – zu starten. Ziel ist es bereits nach 4-6 Wochen ein lauffähiges Produkt mit dem Kernelement der Anwendung zu haben – welches ebenfalls schon getestet ist. Eine typische Scrum-Iteration enthält eine kleine Planungsphase, Entwicklung, sowie Testing und Bugfixing, so dass am Ende der Iteration ein fertiges Produkt feststeht. Jede weitere Scrum-Iteration hat zum Ziel die vorherige, um die in dieser Iteration wichtigsten Features zu erweitern. Der Kunde hat dabei sowohl die Möglichkeit, das Produkt nach jeder Iteration zu sehen, als auch, für die nächste Iteration Einfluss auf die Priorisierung der Aufgaben zu haben. Dadurch wird nicht am Kunden vorbeientwickelt, sondern mit ihm zusammen. „Themaverfehlungen“ wie man sie früher aus Deutsch-Tests kannte, werden dadurch bereits nach wenigen Absätzen erkannt, so dass man sie frühzeitig korrigieren kann.

Zeit für ein Beispiel

Es ist typisch Deutsch, dieses Wasserfallprojektstruktur auf andere – moderne – Bereiche auszudehnen, auch wenn die Tools uns Agilität quasi direkt vor die Augen führen und hier kommen wir zurück zum Alteryx Designer und unserem Beispiel für diesen Blog.

Die Daten

Als ich den Designer das erste Mal geöffnet hatte, stand ich wie bei so vielen Programmen vorher vor einem Problem: Ich will es lernen, aber ich habe keinen konkreten Anwendungsfall. Auf der Suche nach freiverfügbaren Datensätzen bin ich dann über die World Development Indicators gestoßen und um diesen Datensatz soll sich auch das Beispiel drehen. Das folgende Beispiel war damals meine erste mir selbst gestellte Aufgabe mit dem Designer.

Ziel: Wir wollen die WDI-Daten automatisiert auswerten und den Nutzern dabei so viel Flexibilität wie nur möglich bieten.

Werfen wir doch erstmal einen Blick in die Daten. Wir haben 65 Spalten und hundertausende Zeilen.

 

(Quelle)

 

Vergleich Wasserfall und Agilität

Im Wasserfall und oft auch in der Praxis würden wir uns nun grob überlegen wie es ablaufen soll, einen riesigen Workflow zusammenbauen, ihn dann anwerfen und merken: Es funktioniert nicht. Zahlreiche Stunden und Verbesserungen später haben wir dann vielleicht den Workflow, den wir wollten, aber so wirklich glücklich sind wir oft trotzdem nicht.

Der Designer unterstützt uns proaktiv dabei agil zu arbeiten. Meine persönliche Empfehlung: Reduzieren sie die eingelesen Daten auf 5.000-10.000 und werfen Sie die den Workflow spätestens alle 2-3 Tools an. Dadurch stellen sie sicher, dass der Workflow auch genau das macht, was sie haben wollen.

Start Simple – MVP erstellen

 (Quelle)

Das Ziel für unserer MVP (Minimal valuable prudoct) ist es erstmal die Daten von zwei Ländern und einer KPI zu visualisieren.

Der Workflow dazu ist relativ simpel und benötigt nur wenige Schritte:

1. Unnötige Spalten wie Länder- und KPI-Kürzel entfernen (da wir damit nicht arbeiten).
2. Um besser mit den Werten arbeiten zu können werden wir sie transponieren.
3. Auswählen einer interessanten Statistik und auswählen von 2 Ländern / Gruppen.
4. Daten wieder zusammenführen und eine Grafik erstellen.

 

Ein erstes Ergebnis

Ich persönlich finde die Statistik „Death rate, crude (per 1.000 people)“ sehr interessant und habe mich schon immer gefragt, wie arm (Low income) und reich (high income) in dieser Abschneiden, da die Medien in dieser Hinsicht oft ein sehr eindeutiges und klischeehaftes Bild vermitteln.

 

Das Ergebnis hat mich dabei ziemlich überrascht. Ich hätte nicht damit gerechnet, dass sich dabei zwei so klare Trends ergeben. Während die Statistik bei hohem Einkommen mehr oder weniger konstant bleibt, sinkt der Wert bei schwachem Einkommen über die letzten Jahre und Jahrzehnte deutlich und unterbietet mittlerweile sogar den des höheren Einkommens.

Auch der Vergleich der obigen KPI mit zwei Ländern wie Deutschland und – in den Medien oft verschrienen – Drittewelt-Ländern bringt erstaunliches zu Tage, aber diese Erkenntnisse will ich Ihnen nicht vorwegnehmen. Probieren Sie es doch einfach aus

 

Eine erste Erweiterung

Nachdem wir unser MVP erstellt und damit die erste Iteration erfolgreich hinter uns gebracht haben, können wir uns Gedanken über die weiteren Schritte machen.

Unser Kunde schickt uns nahezu täglich eine Liste mit Länder-Kombinationen und KPIs, für welche wir den Workflow anpassen sollen. Um diesem vorzugreifen machen wir eine Kopie unseres Kernprodukts und werden im nächsten Schritt eine App daraus machen, bei welcher der Kunde selbst entscheiden kann, was genau er auswerten will.

Wir passen dazu unsere drei Filter Tools an und füttern diese mit Werten aus einem Dropdown-Menü, welche über ein Action-Tool die Filter aktualisieren. In einem ersten Schritt können wir dabei die Listen der Länder bzw. KPIs manuell hinterlegen, da diese sich bis zu einer Änderung der Quelldatei nicht ändern werden, langfristig ist es jedoch besser, diese ebenfalls dynamisch lesen zu lassen.

 

Recap

Damit wollen wir diesen Eintrag so langsam zum Ende führen und uns noch einmal erinnern was wir gelernt haben. Wenn wir moderne Tools nutzen und trotzdem nur versuchen unsere alten Denkweisen auf diese zu übertragen, dann gewinnen wir nichts. Wir müssen offen für die Möglichkeiten und Methodiken sein, welche diese uns bieten und nicht immer versuchen, unsere alten auf die neuen Tools abzuwälzen.

Call to Action

Natürlich muss der Prozess an dieser Stelle nicht zu Ende sein. Mögliche nächste Schritte sind:

1. Generierung aller möglichen Kombinationen von Ländern / KPIs und Speicherung aller Graphen.
2. Automatischer E-Mail-Versand auf Basis einer Lookup Table (kombiniert mit dem vorherigen Schritt).
3. Mit den Predictive Tools vorhersagen wie sich die Werte in Zukunft entwickeln werden.

Die verwendeten Daten finden Sie sowohl im obigen Link, als auch unter diesem Blogpost. Sollten beide Varianten zu einem späteren Zeitpunkt nicht mehr verfügbar sein, so finden Sie eine Kopie davon hier.

Hinweis:

Selbstverständlich kann der Beispiel-Workflow noch deutlich simpler sein und mehrere Schritte in einem machen. Ich habe den Workflow jedoch bewusst so gestaltet, damit Neulinge jeden logischen Schritt einzeln sehen können. Man könnte bspw. alle Filter-Tools in einem zusammenfassen, dadurch würde man ebenfalls kein Union-Tool danach benötigen, jedoch ist es zum Erklären in dieser Variante leichter zu verstehen.

Autor: Alexander Gross

Ein Kollege gab mir einmal den Namen "Data Magician" und das trifft es eigentlich ganz gut 😉

Meine Leidenschaft oblag schon immer der Verarbeitung, Auswertung und Visualisierung von Daten. Begonnen hat es wie so oft mit Excel, später auch in Kombination mit MS SQL. Daraufhin folgten Maps Anwendungen auf Geodaten und Python Applikationen mit NLP-Pipeline, Machine Learning / BERT und anderen Hype-Themen. 

Bei Fragen können Sie mich gerne hier oder auf LinkedIn kontaktieren.

WDI_csv.zip