Prototyping versus Walking Skeleton

“Schau’ doch bitte mal, ob sich das Feature überhaupt umsetzen lässt. Und gib mir schnellstmöglich Dein Ergebnis.” – so oder so ähnlich könnte eine Aufforderung an einen Software-Entwickler lauten, einen Prototypen zu implementieren.

Die meisten Software-Entwickler haben vermutlich bereits Prototypen realisiert, sei es um Projektideen schnell ausprobieren zu können oder um herauszufinden, ob technische Hürden bei der Verwirklichung auftreten. Die Prototypenentwicklung ist ein großartiges Instrument, das wichtige Erkenntnisse liefert, ohne viel Zeit zu investieren.

Allerdings haben Prototypen in der täglichen Praxis einen bitteren Beigeschmack, der gerne in Organisationen ignoriert wird: Ein Prototyp ist ein Wegwerfprodukt, eine “Hauptsache-es-funktioniert-erstmal-und-wir-können-was-zeigen”-Software. Dieser Wegwerfaspekt fällt gerne unter den Tisch und Prototypen werden immer wieder in bestehende Lösungen integriert. Natürlich bleibt eine solche Integration nicht ohne Folgen: nachträgliche Fehlerbeseitigungen, Mehraufwände bei der Entwicklung, unzufriedene Anwender – um nur einige Nachteile zu nennen. Eine mögliche Alternative zum Prototyping mit Wegwerfprodukten als Ergebnis ist das sogenannte Walking Skeleton – das laufende Skelett.

Das Prototyping

Der Begriff Prototyping wird in verschiedenen Branchen unterschiedlich interpretiert. Meist bedeutet Prototyping, dass man eine Idee oder eine technische Umsetzung möglichst schnell zum Laufen bringen möchte, um ihre Machbarkeit zu bewerten. Unterschieden wird zwischen explorativem, experimentellem oder evolutionärem Prototyping. Beim explorativen Prototyping geht es um die schrittweise Klärung von Anforderungen und die Verfeinerung des Prototypen. Der Prototyp als solcher ist das Ergebnis des Prototyping und das Prototyping ist ein Prozess. Das experimentelle Prototyping soll den Nachweis der Realisierbarkeit vor der tatsächlichen Implementierung liefern. In der Praxis eines Software-Entwicklers kommt es oft vor, dass Anforderungen an ein Feature noch nicht vollständig geklärt sind, weil die Auftraggeber oder Anwender selbst noch nicht wissen, was sie genau möchten. Organisationen tun sich regelmäßig schwer, einen definierten Prozess im Anforderungsmanagement zu etablieren. Die Präsentation eines Prototyps hilft dabei, Anforderungen besser zu verstehen. Der Auftraggeber erkennt, ob sich eine Entwicklung in die gewünschte Richtung bewegt, und ein Anwender erlebt, ob die Bedienung so leicht wie erhofft funktioniert. Der Prototyp wird so zum Proof of Concept.

Das evolutionäre Prototyping geht einen Schritt weiter und verfolgt ein anderes Ziel: es möchte durch das regelmäßige Feedback der zukünftigen Anwender den Prototypen bis zur Produktreife weiterentwickeln. Damit unterscheidet sich dieser Prototyping-Ansatz maximal von den beiden anderen. Den beschriebenen Wegwerfaspekt gibt es hier theoretisch nur, wenn der initiale Prototyp das Thema der Entwicklung deutlich verfehlt und es mehr Sinn macht, ihn durch einen gänzlich neuen Prototypen zu ersetzen.

Nach meiner persönlichen Erfahrung ist das Prototyping immer dann ein phantastisches Instrument, wenn es um das schnelle Finden und Präsentieren von Lösungen geht. Mit ihm lassen sich Anforderungen präzisieren und verifizieren, das Risiko von Fehlentwicklungen senken und auch die Qualitätssicherung frühzeitig einbinden. Es ist aber wichtig zu wissen, dass die Testbarkeit der Implementierung, die Einhaltung einer Softwarearchitektur oder Ansätze wie Test-Driven-Development (TDD) der Erkenntnis unterordnet werden, ob eine Lösung überhaupt und wie gewünscht funktioniert. Daher sollte man einen explorativen und/oder experimentellen Prototypen auch niemals produktiv setzen. Benutzt man den Prototypen so weiter wie er ist, wird diese Form der Abkürzung im Laufe des Projektes mit großer Wahrscheinlichkeit bestraft. Im besten Fall müssen ein Mapping auf die vereinbarte Softwarearchitektur hergestellt, unbeabsichtigte Wechselwirkungen zwischen einzelnen Komponenten und Features beseitigt, und zahlreiche Tests nachträglich durchgeführt werden. Im schlimmsten Fall muss die gesamte Funktionalität neu implementiert werden. Das bedeutet mindestens doppelte Arbeit, doppelter Aufwand und eine verspätete Lieferung, selbst wenn sich der Prototyp als Vorlage für eine Neuimplementierung zum Nachschauen anbietet.

Das Walking Skeleton

Unter einem Walking Skeleton versteht man die einfachste Umsetzung eines kompletten Features. Es implementiert eine Anforderung an ein System, mit einer bereits durchdachten und tragenden Architektur. Zusätzlich legt das Walking Skeleton im Gegensatz zur Prototypenentwicklung von Beginn an Wert auf Testbarkeit, Unit-Tests und auch Modularität. Begrifflich deutet Walking darauf hin, dass die Realisierung bereits lauffähig ist. Ein Prototyp hingegen muss nicht zwingend lauffähig sein; denken Sie bspw. an eine Bedienoberfläche einer Software oder eine Landingpage im Internet – hier geht es häufig um ein Look & Feel, um einen Eindruck. Ergänzt wird das Walking vom Skeleton. Das Skeleton entspricht einer Beschränkung auf die Basisfunktionalität des Features oder Funktionsbereiches. Um in dem Bild zu bleiben: das Fleisch – also weitere Funktionen – kommt erst zu einem späteren Zeitpunkt hinzu.

Nach meiner Auffassung ist ein Walking Skeleton deutlich nachhaltiger als die Erstellung eines Prototypen. Ein Walking Skeleton lebt allerdings auch mit der Einschränkung, dass es genau ein Feature beherrscht. Nicht zwei oder drei, sondern genau eins. Dieses Feature basiert – bei entsprechender Implementierung – auf einer vernünftigen Architektur, die als Gerüst für die zukünftige Weiterentwicklung dient. Dabei muss das Feature nicht einmal die finale Architektur beinhalten, es sollte aber bereits die wichtigsten Architekturkomponenten miteinander verbinden. Architektur und Funktionalität lassen sich später parallel weiterentwickeln wie es das Twin Peaks Modell beschreibt.

Die Wahl des umzusetzenden Features fällt Organisationen nicht immer leicht und erfordert etwas Erfahrung. Idealerweise finden Sie ein Feature, das als Teil des Systems durch alle Ebenen der Softwarearchitektur hindurch implementiert werden kann. In der Literatur wird dieser Durchstich auch als vertikales Prototyping beschrieben. Einen ähnlichen Gedanken verfolgt die Entwicklung der sogenannten Minimum Viable Products. Die Begriffe im Kontext der Prototypenentwicklung liegen also sehr nah beieinander.

Fazit

Sowohl das Prototyping als Prozess mit dem Prototypen als Ergebnis als auch das Walking Skeleton haben Ihren Charme. Organisationen müssen sich anhand ihrer Herausforderungen und ihrem Kontext genau überlegen, welches Vorgehen für sie am meisten bringt und was sie sich vom Ergebnis erhoffen. Wollen sie Anforderungen besser verstehen oder eine grundsätzliche Funktionsweise belegen, dann ist die Entwicklung eines Prototypen sinnvoll. Wollen Sie das Ergebnis weiterverwenden, dann machen ein evolutionäres Prototyping bzw. ein Walking Skeleton Sinn. Müsste ich zwischen diesen beiden Alternativen entscheiden, würde ich mich für das Walking Skeleton entscheiden. Die frühzeitig integrierten Tests über die Schichten des Systems hinweg sorgen nach meiner Erfahrung automatisch für eine höhere Qualität. Allerdings nimmt ein Walking Skeleton im Vergleich zum Prototyping deutlich mehr Zeit und Kosten in Anspruch; der realisierte Gegenwert ist natürlich auch größer.

Unabhängig von meiner persönlichen Präferenz bieten sowohl Prototyping als auch Walking Skeleton einen guten Ausgangspunkt für den Dialog mit Auftraggebern und Anwendern. Frühzeitig können alle Beteiligten erkennen, ob die formulierten oder nicht explizit formulierten Erwartungen, die gestellten Anforderungen und der Kern der Funktionalität getroffen wurden. Final lässt sich also nicht eindeutig sagen, was besser oder schlechter ist. Beides kann gut oder weniger gut funktionieren – die jeweilige Alternative sollten Organisationen allerdings kennen.

 

Hinweise:

Interessieren Sie sich für weitere Tipps aus der Praxis? Testen Sie unseren wöchentlichen Newsletter mit interessanten Beiträgen, Downloads, Empfehlungen und aktuellem Wissen.

Peter Friedland hat im t2informatik Blog einige weitere Beiträge veröffentlicht, u. a.

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.