Einfache Lösungen – Das Zwiebelprinzip

Ich werde erklären, wie man Lösungen elegant, sauber und einfach gestaltet, im Kurs bleibt und gleichzeitig Gewinn und Qualität maximiert.

Heut zu tage gibt es tausende Software-Tools und -Lösungen, wie auch Frameworks und andere Plattformen, welche einen zum Mond und zurück transportieren können. Das grosse Problem ist den entsprechenden Knopf zu finden.

Als Beispiel werde ich eine einfache Wirtschafts-Simulation verwenden, wo man Häuser mit verschiedenen Funktionen bauen kann und so das Volk mit entsprechenden Gütern versorgen kann.
Dieses Spiel existiert wirklich. Es heisst Banished. Ich bin stark beeindruckt, wie eine einzige Person eine Anwendung bauen konnte, die so einfach und sauber und trotzdem sehr beliebt ist.

Welt-Herrschaft

Es startet meistens mit einer Idee im Kopf z.B. eines Software-Entwicklers.
Das ist das erste Problem: Oft findet es nie den Weg aufs Papier. Damit ist man später nicht in der Lage, Reviews durch zu führen und das Konzept zu überarbeiten.
In unserem Beispiel wäre dies die einfache Idee, ein solches Spiel zu bauen und was der Inhalt sein soll.

Danach wird direkt mit der Implementierung gestartet. Irgendwann wird klar, dass man irgendetwas hätte tun können, um die Arbeit einfacher zu gestalten. Also wird nun dieses Etwas umgesetzt. Aber dazu gibt es wieder etwas, was helfen könnte.
Nach einer Zeit existieren tausende angebrochene aber nicht abgeschlossene Teile in der Software.

Wenn wir dies auf das Spiel übertragen, wäre das die Tatsache, dass für die Entwicklung eine Visualisierung hilfreich wäre, um den aktuellen Zustand des Spiels darzustellen. Also wird mit der Implementierung einer graphischen Oberfläche begonnen, bevor der erste Teil der Logik abgeschlossen ist. Nun gibt es Hilfsmittel, welche das Entwickeln der Graphik erleichtern. Also wird Eins heruntergeladen, gekauft oder gebaut. Dann stellt man fest, dass einige Gebäude sehr ähnlich aussehen. Dazu wäre ein Editor hilfreich, mitwelchem das Design erleichtert wird.
Das sind bereits vier unvollendete Teile: Die Logik des Spiels, die Graphik-Engine, die Benutzer-Oberfläche und der Editor.

Das mag nach einem extremen Beispiel klingen. Aber glaubt mir, das passiert vielen Software-Entwicklern, wenn sie neu beginnen und ihr erstes privates Projekt umsetzen.
Natürlich lernen sie daraus und machen es das nächste Mal besser. Aber das Schema bleibt nach wie vor Dasselbe.
Selbst-verständlich ist auch das fehlende Projekt-Management ein Teil des Problems. Aber das Wichtige – oder zumindest das was der Entwickler beinflussen kann – ist die fehlende Methodik.

Als Letztes wäre da noch das Hinzufügen von Funktionen (oder „Requirements“) durch Entwickler mitten in der aktuellen Arbeiten. Dies aus dem Grund, weil es für den Entwickler als sinnvoll erscheint.
Das könnte z.B. die Nahrungs-Produktion sein, welche neu von Saatgut abhängig ist. Dieses wird wiederum durch einen bestimmten Beruf erzeugt.
Diese Funktion wird vor der eigentlichen Nahrungs-Herstellung umgesetzt und kann durch die fehlende Planung zu unnötigen Problemen in der Umsetzung führen.

Eine einfache Lösung

Hier kommen wird zum Konzept, welches helfen soll, soche Probleme zu vermeiden und evtl. das Projekt mit weniger Aufwand zu beenden als geplant. Ich nenne es das Zwiebel-Prizip.

Die Lösung wird wie eine Zwiebel aufgebaut. Das umfasst nicht nur die Struktur der Lösung, sondern auch das Vorgehen, wie sie gebaut wird.Von einfach zu komplex wie bei einer Zwiebel

Gestartet wird mit dem zentralsten und wichtigsten Teil; Die Basis des Systems.
Dieser Teil wird auf das zentralste und einfachtste Element – also den innersten Ring der Zwiebel – reduziert.

In unserem Beispiel wäre das die Tatsache, dass es Personen gibt und diese als Gemeinschaft Güter benötigen (es ist auch möglich, direkt ein spezifisches Beispiel wie Nahrung zu implementieren).
Natürlich kann es notwendig sein, eine geeignete Visualisierung zu verwenden, um zu sehen, ob die Logik korrekt funktioniert. Aber diese soll absolut rudimentär sein und es ist zu diesem Zeitpunkt unerwünscht, eine geographische Darstellung der Personen oder Gebäude zu haben. D.h., die Visualisierung muss noch keinen Zusammenhang mit dem endgültigen Spiel aufweisen. Eine einfache Liste mit produzierten und konsumierten Gütern ist völlig ausreichend.

Machnmal ist es nicht ganz einfach, diesen wichtigsten Teil heraus zu schälen.
Falls dies der Fall ist, ist es am Einfachsten sich zu fragen, was das allererste Bedürfnis des Kunden war. Was ist das das eine Ding, weshalb der Kunde überhaupt über ein solches Projekt nachgedacht hat?
In dem Moment sollte nicht Rücksicht auf Anforderungen genommen werden, welche erfüllt sein müssen, damit überhaupt jemand mit der Applikation arbeitet.
Natürlich würde niemand das Spiel benutzen, wenn es bloss diese Liste mit Gütern gäbe. Aber das ist nicht die Kernfrage. Fakt ist, die Software könnte benutzt werden und die Güter sind das Schlüssel-Element des Spiels; der Grund warum die Anwendung gebaut wird.

Die Bedingungen

Nach dem Basis-Teil wird Ring um Ring zur Zwiebel hinzugefügt. Wichtig hierbei ist, dass die Ringe so klein wie möglich sind.
Die einzige Bedingung ist, dass nach Hinzufügen eines jeden Rings eine abgeschlossener Workflow- oder Prozess-Schritt angebaut wurde. D.h., die gesammte Lösung befindet sich nun im nächsten funktionsfähigen Zustand.
Es dürfen jedoch nach wie vor Funktionen fehlen. Z.B., dass ein Maximum von produzierten oder konsumierten Gütern nicht überschritten werden darf, weil die Anwendung ansonsten abstürzt. Eine Validierung dieser Werte könnte nun der nächste Schritt – sprich Zwiebel-Ring – sein.

Wie wird beurteilt, ob es sich bei etwas um einen abgeschlossen Prozess-Schritt handelt, oder nicht? Am Besten, indem man sich fragt, „Ist das ein Resultat, welches ich dem Kunden präsentieren kann?„.
Es ist absolut erlaubt den Benutzer zu diesem Zeitpunkt darauf hinzuweisen, dass er dieses maximum an Gütern nicht überschreiten darf und, dass diese Überprüfung im nächsten Schritt eingebaut wird. Wichtig ist nur, dass der Kunde darüber informiert ist und er weiss, dass dieses Verhalten bekannt oder gar beabsichtigt ist.

Vorteile

Es gibt mehrere Gründe, warum man diese Methodik einsetzen sollte.

Zuerst werden immer ganze „Liefer-Objekte“ abgeschlossen. Da diese sehr klein sind, hat man praktisch zu jedem Zeitpunkt ein funktionsfähiges Resultat. Dies kann zum Aufzeigen des Fortschritts den Stakeholdern präsentiert werden. Das hat den Vorteil, dass Qualität, Kosten und Termine nachverfolgbar und kontrollierbar sind und eine genauere Prognose gemacht und so die Risiken gesenkt werden können.
Wenn der momentane Zustand dem Kunden präsentiert wird, kann direkt ein Feedback eingeholt werden, ob man sich auf dem richtigen Weg befindet und was noch fehlt. Kurz gesagt, man ist näher an den Kunden-Bedürfnissen.

Meiner Erfahrung nach ist es so auch möglich zu merken, wann der Kunde vollumfassend zufrieden-gestellt ist. Das bedeutet – nun da alle Anforderungen erfüllt sind – wann das Projekt beendet ist. Oft ist das vor Umsetzen des letzten geplanten Zwiebel-Ringes der Fall. Der Rest der Zwiebel bleibt dann der Gewinn!

Auf der anderen Seite wird mit dem Abschluss von kleineren Teilen das Risiko von Fehlern massiv verringert, weil es einen zwingt, das Verhalten möglichst einfach zu gestalten.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.