Walking Skeleton – Das laufende Skelett

Jetzt wird es gruselig – könnte man meinen. Stimmt aber nicht, wie Sie gleich sehen werden.

In der Praxis können Produktbacklogs schnell sehr groß werden. Hinzu kommt, daß sich Wünsche an das Produkt häufig ändern. Um mit den Anforderungen umzugehen, die sich daraus ergeben, benötigen sowohl das Entwicklungsteam als auch der Produktowner Methoden, die ihnen dabei helfen, den Produktbacklog zu strukturieren, und die Software iterativ zu erweitern.

Das Konzept des „Walking Skeleton“ zusammen mit den Ansätzen rund um das Thema „Specification by Example“ helfen hierbei. Beide ermöglichen es, das entstehende Produkt mittels der beiden Testmethoden „Acceptance-Test-Driven-Development“ (ATDD) und „Test-Driven-Development“ (TDD) zu überprüfen. Hierdurch wird das Produkt „rund“ und „qualitativ hochwertig“.

Funktionsweise der Methoden

Definition vorab

Softwareprodukte können schnell groß und beliebig komplex werden. Unter einem „Walking Skeleton“ eines Softwareprodukts versteht man die einfachste Umsetzung eines kompletten Funktionsbereiches, bzw Geschäftsprozesses. Dabei handelt es sich um eine Version, die „gerade so“ funktioniert.

Das „Walking“ bezieht sich hierbei auf den Umstand, daß diese Umsetzung bereits lauffähig ist. Der Begriff „Skeleton“ umschreibt, daß bei dieser Umsetzung bereits die wichtigsten funktionalen Teile vorhanden sind, und arbeiten, während der überwiegende Teil der Funktionalität, d.h das Fleisch, selbst noch nicht zur Verfügung steht.

Ein solches Skeleton entsteht iterativ, d.h. man erweitert es „gerade eben so“, testet das Resultat entweder mit den Stakeholdern (ATDD) oder im Team (TDD), und erweitert das Resultat dann entsprechend.

Einordnung des Walking Skeleton

Jeff Patton (siehe Weiterführende Informationen am Artikelende) erklärt sehr ausführlich das Probem eines großen, flachen Backlogs, und zeigt auf, wie einem die Methode dabei hilft, den Überblick über die wichtigten Szenarien zu behalten. Ein Produkt Backlog wird als flach bezeichnet, wenn jedes Backlogitem neben dem anderen beschrieben wird – ohne, daß irgendwelche Hierarchien benutzt werden.

Man kann sich vorstellen, dass diese Methode des flachen Backlogs ab mehreren 100 Backlogitems zunehmend unhandlich wird – soviel einzelne Funktionen kommen schnell zusammen.

Patton stellt einen hierarchischen Backlog dar, den er über das sogenannte User Story Mapping strukturiert. Er benutzt einen Hauptprozess als Gruppierungskriterium, den das Produkt erfüllen soll, mit dessen Hilfe er diesen Backlog weiter strukturiert. Diesen Hauptprozess nennt er Walking Skeleton.

Sie sehen also, daß das Walkings Skeleton nichts anderes ist, als ein definierter, zusammenhängender Produktstrang, an dem man sich orientiert, und den man schrittweise mit Features auffüllt.

In den Artikeln von Alistair Cockburn, und Stephan Schwab (siehe Weiterführende Informationen am Artikelende) wird klarer, dass dieser Walking Skeleton noch weitere Funktionen hat. Zum Beispiel gestattet er dem Entwicklungsteam, sich in der Entwicklungsphase auf die unmittelbar notwendige Basisfunktionalität zu beschränken.

Diese spezielle Funktion des Walking Skeleton ist in meiner Praxis besonders wichtig. Dort kommen häufig komplexe Prozessabläufe ins Spiel, die es zunächst zu klären gilt. Hier ist es ganz gut, wenn man über eine Methode verfügt, die einen dabei unterstützt, die Funktionalität Schritt für Schritt zu erweitern.

Ein weiterer Aspekt ist, daß man so schnell iterieren kann. Das Walking Skeleton ist schneller fertig, als die komplette Software, und man kann dieses Stück bereits liefern und einsetzen, z.B. um von den Testern zu erfahren, ob der abgebildete Prozess passt, oder wo noch Features, bzw Spezialfälle fehlen.

Bei fehlenden Features entsteht schnell die Frage, was diese Features denn leisten sollen. Hier kommen Methoden, wie das „Specification by Example“ zum Einsatz, die helfen, solche Features zielgerichtet zu beschreiben.

Specification By Example

Zur Thematik „Specification by Example“ habe ich bereits in früheren Artikeln Informationen zusammengestellt n(siehe Links weiter unten). Hierbei handelt es sich letztendlich um eine Methode, die einen dabei unterstützt, die Anforderungen des Nutzers auf der einen Seite mit der Realisierung in Form von Software auf der anderen Seite anhand konkreter Aussagen und Beispiele zu verknüpfen.

Man beschreibt hierbei zunächst die typischen Anwendungsszenarien, möglichst in Form von Beispielen, entwickelt dann die entsprechende Software, und stellt zum Schluss Testautomaten zur Verfügung, mit denen man diese Software prüfen kann.

Dieses Gesamtdesign hilft dem Entwicklungsteam in einem späteren Schritt, die Software kontrolliert zu erweitern – man ist ja jederzeit durch Tests abgesichert.

Ein konkretes Beispiel wäre, daß man von der vorhandenen Software (Walking Skeleton) statt „Die Performance soll groß sein“ zusätzlich einfordert, „die Antwortzeit muss auf diesem Screen unter 50 ms liegen“, und „hier darf der Speichervorgang von 10 TB Daten höchstens n Sekunden dauern“.

Wie sie sich vorstellen können: Diese Anforderungen lassen sich wesentlich konkreter umsetzen, und man kann zudem viel einfacher prüfen, ob man richtig liegt.

Die galante Lösung

Die sicherlich galanteste Lösung wäre es nun, wenn man einfach beide Methoden verknüpfen würde, wie ich es oben im Beispiel bereits getan habe.

  • Hierbei würde man zunächst damit beginnen, sich über ein User Story Mapping die Kundenanforderungen zu strukturieren.
  • Anschließend würde man die jeweiligen Kernprozesse identifizieren, und diese als Walking Skeletons festhalten.

Wenn man so vorgeht, kennt man die Kundenanforderungen, und die Anforderungen, die dem Kunden so wichtig sind, daß von deren Umsetzung abhängt, ob der Kunde die Software später kauft.

  • So vorbereitet, benutzt man anschließend die Ideen des Specification by Example dazu, um diese Szenarien näher auszuarbeiten, und um die entstehende Software mit Tests abzusichern, und anschliessend zu dokumentieren.
  • In einem letzten Schritt würde man damit beginnen, die Software geordnet zu erweitern, indem man sich die nächsten Kernprozesse vornimmt, und die einzelnen Ideen dort ergänzt und umsetzt.

In der Software selbst bestünde der Erweiterungsbedarf dort, wo die Tests anzeigen, daß die bisher realisierte Software nicht ausreicht, und Fehler produziert.

Merkmale

Folgende Merkmale zeichnen die Methoden aus:

  • Ein Walking Skeleton zeigt dem Abnehmer bereits früh, ob ein Entwicklungsteam den Kern der Funktionalität verstanden hat. Er stellt einen guten und konkreten Startpunkt für weiterführende Diskussionen und Verfeinerungen dar.
  • Der Skeleton stellt einen frühen Integrationserfolg dar, und zeigt, dass der Abstimmungsprozess innerhalb des Teams funktioniert.
  • Beide Methoden zusammengenommen, unterstützen den Produktowner dabei, mit dem Team komplette User Storys zu bearbeiten, anstatt nur einzelne Backlog-Items vorzugeben. Diese Verbreiterung der Basis sorgt normalerweise dafür, daß eine Funktionalität runter wird, weil wir nun mehrere Köpfe mitwirken.
  • Ein Walking Skeleton trägt ebenfalls zu einer Verkleinerung des Backlogs bei, da er eine iterative Vorgehensweise unterstützt.
  • Die eingearbeiteten Testmethoden sorgen dafür, dass man die Qualität auf eine reproduzierbare Art und Weise sicherstellt.
  • Solche frühen Modelle, die zudem auch noch arbeitsfähig sind, lassen sich auch sehr gut mit Kunden besprechen, um auf diesem Weg zu neuen und besseren Anforderungen zu gelangen.

Test Driven Development

Das Thema Test driven Development bespreche ich an anderer Stelle genauer. Daher gehe ich hier nur kurz darauf ein. Die oben geschilderten Methoden ergeben, wenn man es richtig anstellt, eine Liste von Anforderungen, Akzeptanzkriterien und Testparametern.

Auf der anderen Seite ging es in der Entwicklung schon immer darum, daß man solche Anforderungen passend umsetzt. Hierfür gibt es (sehr) grob gesprochen zwei Ansätze:

  • Features entwickeln, und solange Testen und ändern, bis sie passen.
  • Klären der Anforderungen, Erstellen der Tests, die anzeigen, daß die Anforderungen erfüllt werden, und solange entwickeln, bis die Tests erfolgreich sind.

Die zweite Methode hat die klaren Vorteile auf seiner Seite.

Über die Methode des Walking Skeletons kennt hier das Entwicklungsteam einen Hauptprozess, und diesen genau so, wie es der User anfordert, und kann nun mit Hilfe von konkreten Beispielen prägnant und präzise ausdrücken, was über die einzelnen Funktionen erreicht werden soll. Dabei bewegt man sich eher auf der Ebene der Geschäftsanforderungen und läßt Umsetzungsdetails wie das GUI oder die Datenbank aus.

In diesem Prozess wird das Skeleton am Ende präziser. Paralell hierzu arbeitet das Scrumteam daran, aus den  Beispielen automatisierte Tests abzuleiten, die später dabei helfen, die fertige Umsetzung zu testen.

Es ist gut zu erkennen, daß das Team mithilfe der erwähnten Methoden nach einem strikten und gerichteten Outside-In-Prozess arbeitet. Dieser Prozess und speziell die ebene der Tests (vorausgesetzt, daß das Team den entsprechenden Reifegrad hat, und strikt so arbeitet) stellt letztendlich sicher, daß die Anwendung das leistet was sie soll, und, daß sie so robust ist, daß es einfach ist, geänderte Anforderungen einzuarbeiten.

Die beiden Testmethoden ATDD und TDD ergänzen sich unmittelbar, arbeiten aber nach denselben Prinzipien. Der Unterschied ist, daß ATDD auf der „Acceptance-Ebene“ arbeitet (d.h. Kundenanforderngen), und TDD eher auf der Modulebene (Unit Tests, etc). Beide zusammen stellen sicher, daß der Code richtig geschrieben ist, und genau das tut, was er soll.

Das Walking Skeleton stellt schlussendlich sicher, daß diese Kette genau immer für einen definierten Funktionsumfang und Prozess gilt. Über eine Sammlung von sich ergänzenden Skeletons kommt man am Ende zum kompletten und getesteten, robusten Produkt.

Weiterführende Informationen

… im Internet

Im Internet finden Sie weiterführende Artikel, in denen Sie mehr Informationen über die vorgestellten Konzepte:

… auf www.Produkt-Manager.net

In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema Innovationsmanagement generell:

Kontakt

Das Original dieses Artikels ist auf Der Produktmanager erschienen (©Andreas Rudolph). Regelmäßige Artikel gibt es über die (→Mailingliste), oder indem Sie →mir auf Twitter folgen. In der Online Version finden Sie hier die versprochenen weiterführenden Links:

Comments are closed.