Produktmanagement im Technologiesektor – Tipps zu den Themen Produktmanagement und Innovation. Von Andreas Rudolph
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“.
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.
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.
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 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.
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.
In der Software selbst bestünde der Erweiterungsbedarf dort, wo die Tests anzeigen, daß die bisher realisierte Software nicht ausreicht, und Fehler produziert.
Folgende Merkmale zeichnen die Methoden aus:
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:
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.
Im Internet finden Sie weiterführende Artikel, in denen Sie mehr Informationen über die vorgestellten Konzepte:
In meinen älteren Artikeln finden Sie weiterführende Informationen zum heutigen Thema Innovationsmanagement generell:
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:
Ich arbeite seit vielen Jahren in der Softwareentwicklung für Unternehmensanwendungen bei der SAP SE. Dieser Blog ist privat, und die Meinungen sind meine eigenen. Sie sind hier richtig, wenn sie sich für Praxiserfahrungen im Produktmanagement für Investitionsgüter interessieren.
High Def WordPress Theme by Graph Paper Press
Subscribe to entries
Subscribe to comments
All content © 2024 by Der Produktmanager
