Software-Reuse in agilen Projekten

In den neunziger Jahren war Software Reuse die große Hoffnung der neuen objektorientierten Informationstechnologie. Sie versprach eine Beschleunigung der Entwicklung, eine Erhöhung der Qualität und eine Verringerung der Wartungskosten. Dabei war und ist die Wiederverwendung von Software häufig eingebettet in einen traditionellen, Dokumenten-gestützten Software-Entwicklungsprozess. Anfang der 2000er Jahre machen in der Software-Entwicklung neben den traditionellen Prozessen so genannte leichtgewichtige oder Agile Projekte von sich reden. Der Grund für ihren Einsatz liegt in der Notwendigkeit, effektivere und verlässlichere Methoden zu finden, um den neuen Herausforderungen in der Software-Entwicklung gerecht zu werden.
Mit dem Aufkommen der Agilen Methoden wurde die Frage diskutiert, ob Software Reuse auch im agilen Umfeld möglich ist und auch hier die erwarteten Erfolge bringt.

Hasko Heinecke und Christian Noack haben sich im folgenden Beitrag aus dem Jahr 2003 damit beschäftig, unter welchen Umständen Software Reuse und Agile Projekte kombiniert werden können und zeigen Chancen und Risiken einer Kombination auf.

Agile Prozesse

The cost of change may not rise dramatically over time (siehe [1], S. 23).

In der schnelllebigen Welt von heute ändern sich Anforderungen an eine Software oft bereits während ihrer Entwicklung mit hohem Tempo. In traditionellen, in Phasen (Analyse, Design, Implementierung, Auslieferung, Testen) gegliederten, Software-Entwicklungsprozessen ist der Umgang mit Anforderungsänderungen nur durch ein aufwändiges Change-Management zu bewältigen. Agile Prozesse — ihr wohl bekanntester Vertreter ist Extreme Programming (XP) — zeichnen sich aus durch ein hohe Flexibilität gegenüber sich ändernden Anforderungen. Ihr gemeinsames Ziel ist es, die “Cost of Change” so gering wie möglich zu halten. Sie brechen damit die Gesetze von traditionellen Prozessen (z.B. Wasserfall), bei denen die Kosten von nachträglichen Änderungen während der Entwicklung exponentiell zum Projektfortschritt wachsen. Agile Software-Entwicklung konzentriert sich darauf, möglichst früh einen Kundennutzen zu erzielen (“Business Value First”), um dann in fortwährenden Iterationszyklen das Produkt zu erweitern und zu verbessern. Der bei Agilen Prozessen übliche Verzicht auf große Teile der traditionellen Prozess-Dokumentation, die informelle Entscheidungsfindung sowie die Konzentration auf mündliche Kommunikation zwischen den Teammitgliedern stellen oft einen Bruch mit den Gewohnheiten in den IT-Abteilungen großer Unternehmen dar. Der dadurch oft empfundene Kontrollverlust wird kompensiert durch die regelmäßige Auslieferung der Software jeweils am Ende einer Iteration. Der Kunde bekommt dabei eine funktionsfähige und in seinem Sinne brauchbare — wenn auch zu Beginn der Entwicklung funktional eingeschränkte — Software.

Software Reuse

Software reuse is the systematic practise of developing software from a stock of building blocks, so that similarities in requirements and/or architecture between applications can be exploited to achieve substantial benefits in productivity, quality and business performance (siehe [3]).

Um das Thema Software Reuse ist es in der letzten Zeit ruhiger geworden. Der Grund dafür ist vermutlich in der Schwierigkeit zu suchen, sowohl in traditionellen wie auch in Agilen Prozessen folgende Fragen zufriedenstellend zu beantworten:

Wie erfahre ich, welche Bausteine für die Wiederverwendung zur Verfügung stehen?
Wie stelle ich meine eigenen Bausteine für Software Reuse zur Verfügung?
Wie entwickle ich Bausteine, so dass sie sich für Software Reuse eignen?

Diese zentralen Fragen sind in der Vergangenheit entweder ignoriert oder mit organisatorischen Lösungen beantwortet worden. Dabei soll eine zentrale Koordinationsstelle für ein nützliches Maß”s von Software Reuse sorgen. Diese hat mehrere Aufgaben:

Untersuchung von neu entwickelter Software auf fachliches und technisches Reuse-Potential incl. Design-Review, welches auf gute Wiederverwendbarkeit der in Frage kommenden Komponenten abzielt
Festlegung von Richtlinien für die Erstellung wiederverwendbarer Bausteine
Archivierung von wiederverwendbaren Software-Bausteinen
Wartung und Anpassung von Software-Bausteinen an neue technische Gegebenheiten sowie neue Anforderungen
Beratung und Unterstützung bei der Auswahl und beim Einsatz wiederverwendbarer Bausteine

Diese Koordinationsaufgaben übernimmt häufig ein sogenannter “Bibliothekar”. Dieser Name beschreibt einerseits den archivierenden und beratenden Charakter der Aufgaben, andererseits jedoch auch, vermutlich unbeabsichtigt, deren Ambivalenz. Dem Bibliothekar wird einerseits ein umfassendes Wissen um den Bestand des Archivs zugeschrieben. Jedoch trägt die Bezeichnung auch das Bild des verstaubten, realitätsfernen Bücherwurms mit sich. Weder das Ignorieren der zentralen Fragen von Software Reuse noch die Einführung eines administrativen Apparats scheinen in eine agile Vorgehensweise hineinzupassen. Damit jedoch die Verträglichkeit zwischen Software Reuse und Agilen Prozessen genauer beleuchtet werden kann, ist die Klassifizierung von Software Reuse nach zwei Kriterien erforderlich: Entwicklungsgeschichte und Granularität.

Motive zur Entwicklung wiederverwendbarer Bausteine

Wiederverwendbare Software-Bausteine können anhand der Motive ihrer Entwicklung in drei Klassen aufgeteilt werden:

M1: Entwickeln ohne Absicht der Wiederverwendung, späteres Identifizieren und Anpassen von Bausteinen
M2: Entwicklung auf ein bestimmtes Ziel hin mit Hintergedanken der zukünftigen Generalisierung
M3: Proaktives Erstellen von wiederverwendbaren Software-Bausteinen wie Frameworks, Libraries; Hierbei geht es jedoch ausschließlich um Bausteine, die innerhalb des gleichen Umfelds erneut eingesetzt werden sollen. Software Reuse in dem Sinne, dass Software von Drittanbietern eingesetzt wird, ist nicht Gegenstand dieses Papers, da der Focus hier auf Software-Bausteinen liegt, bei denen die Möglichkeit zur eigenverantwortlichen Änderung durch Projekt-Teams gegeben ist.

Granularität von Software Reuse

Orthogonal zu den drei Klassen der Entwicklungsgeschichte von Bausteinen lassen sich diese außerdem gemäß ihrer Größe wie folgt klassifizieren:

Kleine Software-Einheiten: Klassen, Statements, Methoden
Software-Module als Zusammensetzung kleinerer Einheiten (z.B. Packages)
Applikationen und Services

Verträglichkeit von Agilen Prozessen und Software Reuse

Software Reuse der Motivklasse M1 ist ganz im Sinne von Agilen Prozessen. XP als prominentester Vertreter von Agilen Prozessen hat den Leitsatz: “Do the simplest thing that could possibly work” (siehe [1]). Dieser fordert den Entwickler geradezu auf, keine Funktionalität auf Vorrat zu erzeugen, da entwickelte Funktionalität, die über die für die aktuelle Iteration spezifizierten Anforderungen hinaus geht, mit sehr großer Wahrscheinlichkeit nie gebraucht wird — “You ain’t gonna need it” (Kent Beck). Die spätere Identifikation von wiederverwendbaren Bausteinen (gemäß Motivklasse M1) innerhalb des gleichen Projekts oder in einem neuen Projekt und die Restrukturierung und Verbesserung des Software-Designs zur Erreichung der Wiederverwendbarkeit ist eine übliche Entwicklungstechnik bei Agilen Prozessen und nennt sich Refactoring (siehe [1]). Refactoring geht einher mit einer hohen Abdeckung durch Unit Tests, welche zeigen, dass die Anforderungen an einen Software-Baustein nach dem Refactoring immer noch fehlerfrei erfüllt werden. Tool-Unterstützung hilft dem Entwickler, dieser Aufgabe gerecht zu werden. Der Verzicht auf Refactoring und stattdessen die Verwendung von Copy & Paste-Programmierung ist weder als Software Reuse noch als agiles Vorgehen zu bezeichnen (vergleiche dazu [2], S. 84: “Once and only once”).

Die Entwicklung von Software auf ein bestimmtes Ziel hin, jedoch mit dem Hintergedanken der zukünftigen Generalisierung (siehe Motivklasse M2:), ist kein agiles Vorgehen, denn hier wird die Struktur der Software nicht aussschließlich an den Anforderungen für die aktuelle zu entwickelnde Software, sondern auch an sich potentiell ergebenden zukünftigen Anforderungen ausgerichtet.

Die Erstellung von Frameworks und Bibliotheken, die keinen anderen Sinn als ihre zukünftige Wiederverwendung verfolgen (siehe Motivklasse M3:), ist aus o.g. Gründen ebenfalls nicht als agile Entwicklung zu betrachten. Die Verwendung von Frameworks hingegen kann durchaus im Rahmen eines Agilen Prozesses erforderlich sein, um sich auf die eigentlichen Anforderungen besser konzentrieren (“business value first”, Kent Beck), und um große Aufwände bei technischen Details verringern zu können.

Grundsätzlich ist die Vermeidung von Duplikation und Redundanzen im Sinne eines jeden Software-Prozesses. Betrachten wir nun Software Reuse als ein Mittel, um dieses Ziel zu erreichen. Wir gehen davon aus, dass es trotz der geschilderten Differenzen zwischen Agilen Prozessen und Software Reuse möglich ist, die beiden Konzepte nutzbringend zu vereinigen. Anhand einiger ausgewählter Prinzipien Agiler Prozesse belegen wir im Folgenden die Vereinbarkeit der Konzepte.

Prinzipien aus dem “Agilen Manifest”

Die mit Agilen Prozessen befasste Gemeinde hat sich auf einen Satz von gemeinsamen Prinzipien geeinigt, die im sogenannten Agilen Manifest zusammengefasst sind. Im Folgenden sind die im Zusammenhang mit Software Reuse relevant Prinzipien aufgeführt.

Welcome changing requirements, even late in development. Agile Processes harness change for the customer’s competetive advantage.

Hier stellt sich die Frage, wie mit Änderungen der Anforderungen umgegangen wird, die sich auf wiederverwendete Software-Bausteine auswirken. Dabei sind zwei Parteien betroffen: die Entwickler des Bausteins und seine Benutzer. Wenn sich während der Software-Entwicklung die Anforderungen ändern und weitere hinzukommen, sind ggf. auch Modifikationen an wiederverwendeten Bausteinen erforderlich. Diese Anpassungen werden von den Benutzern des jeweiligen Bausteins eigenverantwortlich durchgeführt. Nach entsprechenden Tests werden die Modifikationen den Entwicklern des Bausteins zugänglich gemacht. Diese lassen die Veränderungen in die Weiterentwicklung einfließen, sofern sie die bisherige Funktionalität nicht beeinträchtigen.

Business people and developers must work together daily throughout the project.

Business-Vertreter verfügen häufig über ein breites Wissen der im Unternehmen auftretenden Geschäftsprozesse und können so sich wiederholende oder ähnelnde Geschäftsprozesse erkennen. Darauf aufbauend lassen sich häufig potentiell wiederverwendbare Software-Bausteine identifizieren.

The most efficient method of conveying information to and within a development team is face-to-face conversation.

Während Software Reuse der Motivklasse M1 sich in der Regel in kurzen Zeiträumen, zumindest aber innerhalb eines Projekts abspielt, werden bei den beiden anderen Klassen von Software Reuse die Bausteine häufig erst erheblich nach ihrer Erstellung innerhalb des gleichen Projekts oder in einem ganz anderen Projektumfeld wiederverwendet. Hinzu kommt, dass durch die Fluktuation zumindest in großen Organisationen die Entwickler von Bausteinen vielleicht nicht mehr verfügbar sind. Die direkte zwischenmenschliche Kommunikation ist in diesen Fällen nicht gegeben. Bei der Entscheidung für Software Reuse und bei der Auswahl der wiederzuverwendenden Bausteine sollte dieser Aspekt berücksichtigt werden, um die Agilität der Software-Entwicklung möglichst erhalten zu können.

Working Software is the primary measure of progress.

Von diesem Maßstab darf man sich nicht dazu verleiten lassen, eine Unzahl von vorhandenen Bausteinen heranzuziehen und diese Menge aus einzeln funktionsfähigen Elementen als großen Projektfortschritt zu betrachten. Die mit der Zahl unabhängiger Bausteinen exponentiell ansteigende Komplexität der Integration darf nicht vernachlässigt werden. Zudem bringt jeder Baustein unter Umständen einen gewissen Ballast von mitgelieferter, aber nicht benötigter Funktionalität mit.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Die Nachhaltigkeit der Software-Entwicklung muss auch bei Wiederverwendung von Software-Bausteinen gegeben sein. Daraus folgt:

durch Software Reuse darf die Komplexität des Design nicht steigen, sondern sollte sinken — so sollte durch Software Reuse die Anzahl der Bausteine eines Projekt reduziert werden
wiederverwendbare Bausteine müssen sich in ihrer Struktur sowohl in das Design als auch in den Prozess eingliedern
Software Reuse darf nur erfolgen, wenn es für den Kunden einen direkten oder indirekten Nutzen bringt
Software Reuse darf den Prozess nicht behindern

Continuous attention to technical excellence and good design enhances agility.

Oft steht das kontinuierliche Optimieren und Perfektionieren eines Bausteins im Widerspruch zum Versuch, Upgrade-Aufwände zu minimieren. Letztere Haltung eines Beharrungsvermögens suggeriert die Existenz von zeitlos-gutem Design. Unserer Erfahrung nach gibt es diese allerdings nicht. “Stabile” Software ist tot, gute Software lebt und ist immer noch verbesserungsfähig. Mit abnehmender Granularität der Wiederverwendung (siehe oben) sind die wiederverwendeten Bausteine zunehmen statisch. Je kleiner der Baustein, desto einfacher ist seine Modifikation und desto eher passt er sich in ein agiles Umfeld ein.

Simplicity—the art of maximizing the amount of work not done—is essential.

Ganz offensichtlich reduziert Software Reuse das Maß an Neuentwicklung. Andererseits werden Änderungs- und Integrationsaufwände an den wiederverwendeten Bausteinen notwendig. Allgemeingültig lässt sich die Frage, ob die Wiederverwendung eines Bausteins die Einfachheit fördert, nicht beantworten. Auch im Konkreten ist die Beantwortung schwierig, da nicht abzusehen ist, ob zukünftige Anforderungen oder Anforderungsänderungen den jeweiligen Baustein betreffen. Der wiederverwendete Baustein sollte entweder möglichst klein sein oder aber sich von den anderen Bausteinen des Projekts klar und deutlich abgrenzen und ggf. sogar austauschen lassen.

Extreme Programming: Werte

Da XP der zur Zeit erfolgreichste Agile Prozess ist, lohnt es sich auf diese konkrete Ausprägung leichtgewichtiger Vorgehensweisen näher einzugehen und zu beleuchten wie Software Reuse bzgl. der Werte und Praktiken von XP zu bewerten ist.

Kommunikation:
Der zeitliche Versatz, der zumindest potentiell Erst- und Wiederverwendung trennt, erschwert die Kommunikation im Sinne von XP und anderen Agilen Methoden. Ein Gespräch von Angesicht zu Angesicht ist oft nicht möglich.

Einfachheit:
Aus Sicht von XP gilt es darauf zu achten, dass durch Software Reuse kein zusätzlicher administrativer Aufwand entsteht.

Feedback:
Je mehr Benutzer einen Baustein einsetzen, desto mehr Feedback bekommen die Entwicker des Bausteins, denn durch die applikationsspezifischen Tests wird die Testabdeckung für den Baustein erhöht.

Mut:
Wiederverwendung braucht den Mut sich mit ggf. nicht selbst entwickelten Bausteinen auseinanderzusetzen, daran ein Refactoring durchzuführen, danach Anpassungen vorzunehmen und ggf. den veränderten Baustein zur erneuten Wiederverwendung freizugeben. Auf einen Fundus vorhandener, verläßlicher Bausteine zugreifen und diese anpassen zu können, gibt allerdings auch Mut, im Projekt zügiger voranzuschreiten. Die Verläßlichkeit von wiederverwendbaren Bausteinen muss dafür durch ausreichende, automatisierte Tests belegbar sein. Es muss jedoch auf die Gefahr hingewiesen werden, durch Wiederverwendung überflüssige Funktionalität in das Projekt zu holen und dabei die Kreativität für einfachere, kleinere Lösungen einzubüßen.

Extreme Programming: Praktiken

Das Planning-Game:
Während des Planning-Games werden die Anforderungen des Kunden in sog. User Stories festgehalten. Wenn der Kunde zwei ähnliche Geschäftsprozesse hat, werden auch die entsprechenden User Stories Ähnlichkeiten aufweisen. Diese Übereinstimmungen verweisen auf Kanditaten für den Software Reuse. Es liegt in der Verantwortung der Teilnehmer am Planning Game, Übereinstimmungen in User Stories zu finden, auch wenn die Bearbeitung zweier ähnlicher Stories zeitlich auseinanderliegt.

Small Releases/Short Iterations:
Durch die Wiederverwendung von vorhandenen Software-Bausteinen, können sich die Entwickler auf die Umsetzung der eigentlichen Funktionalität der jeweiligen User Story konzentrieren. Dadurch wird die Entwicklungszeit verkürzt und die Einhaltung kurzer Iterationszyklen ermöglicht. Allerdings ist im Einzelfall zu prüfen, ob der durch Projekt-übergreifende Wiederverwendung entstehende administrative Overhead diess Vorgehen rechtfertigt. Außerdem darf die Refactoring- und Anpassungszeit für wiederverwendete Komponenten nicht größer sein als die benötigte Zeit zur Selbtentwicklung der gewünschten Funktionalität.

Simple Design:
Der erneute Einsatz eines bereits vorhandenen Bausteins muss nicht zwangsläufig das Design kompliziert machen. Es hängt ganz von der Qualität des Bausteins, seiner Granularität und der Eignung für den jeweiligen konkreten Einzelfall ab, ob auch nach der Wiederverwendung eines Bausteins, das Design des Software-Projekts einfach bleibt.

Testing:
ist bei Software Reuse sehr wichtig, denn Teams können wiederverwendete Bausteine verändern und dadurch Schwierigkeit bei anderen Verwendern verursachen.

Refactoring:
ist Software Reuse der Motivklasse M1 und der kleinen Granularitätsklasse. Es ist aus XP-Sicht unbedingt notwendig, um wiederverwendbare Bausteine entstehen zu lassen.

Collective Ownership:
ermöglicht bei Software Reuse erforderliche Änderungen an den wiederverwendeten Bausteinen ad hoc durchführen zu können.

Continuous Integration:
bedeutet im Fall von Software Reuse, dass Änderungen (ggf. durch andere Teams) an verwendeten Bausteinen direkt in das eigene Projekt einfließen. Dieses Vorgehen fordert vollständige Tests.

On-Site Customer:
kann Reuse-Möglichkeiten aus Geschäftsprozess-Sicht aufdecken.

Coding Standards
gewinnen bei Software Reuse zusätzlich an Bedeutung um eine weitere Wartung und Anpassung wiederverwendeter Bausteine zu erleichtern.

Fazit

Software Reuse ist auch in Agilen Prozessen möglich und u.U. sogar wünschenswert, wenn folgenden Empfehlungen beachtet werden.

Bei der Initialentwicklung sollte nicht auf wiederverwendbare Komponten abgezielt werden (“You ain’t gonna need it!”). Nicht einmal eine besondere Bausteinstruktur wird eingehalten. Erst wenn eine weitere Anwendung oder Teilanwendung, die gleiche Funktionalität benötigt und entschieden wird, diese wiederzuverwenden, wird ggf. in projektübergreifender Kooperation der entsprechende Baustein durch gezieltes Refactoring generalisiert und isoliert.
Das wiederverwendende Team entscheidet, was und wie wiederverwendet wird. (und nicht die Architektur-Polizei bzw. das Management). Die Information über bereits vorhandene Bausteine und deren Eignung zur Wiederverwendung wird durch Kommunikation der Projektmitglieder und durch den gemeinsamen Zugriff auf ein geeignetes Repository verteilt. Bausteine sollten nur wiederverwendet werden, wenn ihre Qualität durch ausreichende Unit Tests nachgewiesen werden kann.

Die Entscheidung für oder gegen Software Reuse muss nicht zwangsläufig eine Make- or Buy-Entscheidung sein. Aus Sicht Agiler Prozeese ist die Alternative Make or Adpat deutlich sinnvoller. Die Entscheidung für Software Reuse sollte nicht generell, sondern im Einzelfall gefällt werden. Dabei gilt es anhand der oben genannten Kriterien zu untersuchen, ob durch die Wiederverwendung die agile Vorgehensweise eingeschränkt wird oder ob es im Einzelfall sogar gelingt, durch Software Reuse dem Kunden in kürzerer Zeit zu angemessenen Kosten und bei hoher Qualität die Software zur Verfügung stellen zu können, die genau seinen Anforderungen entspricht.

Literatur

[1] BECK, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.
[2] JEFFRIES, R., ANDERSON, A., AND HEND- RICKSON, C. XP Installed. Addison-Wesley, 2000.
[3] ESRAN, M., MORISIO, M., AND TULLY, C. Practical Software Reuse. Spinger Verlag, London, 2002.
[4] FOWLER, M. Refactoring–ImprovingtheDe- sign of Existing Code. Addison-Wesley, 1999.