Auswirkungen von Altlasten auf die Neuentwicklung von Features.


Altlasten in Softwaresystemen sind beinahe immer alte Anforderungen, die von anderen Personen vor längerer Zeit umgesetzt wurden. Trotz Dokumentationen in Form von JIRA-Tickets, WIKI-Einträgen und Testdokumentation ist es sowohl für Softwareentwickler als auch für das Anforderungsmanagement kaum möglich all diese Informationen in adäquater Zeit auszuwerten, um ein neues Feature kostengünstig liefern zu können.</p>

Die in der Praxis gängige Herangehensweise, um dieses Problem zu lösen ist daher einfach nachzuvollziehen: Man versucht möglichst nichts an der bestehenden Funktionalität zu ändern (d.h. der Softwareentwickler versucht bestehenden Code nicht zu verändern) und fügt seine neuen Änderungen einfach hinzu. Dieses Vorgehen funktioniert bei den ersten Änderungsanfragen auch wie gewünscht. Nach einiger Zeit stellt sich jedoch eine Situation ein, die es unabdingbar macht bestehenden Code anzufassen. Spätestens, wenn neue Anforderungen im Widerspruch zu alten stehen. Dies ist der Knackpunkt an dem nun auch alle alten Überlegungen mit bedacht werden müssten, um den Überblick über das System beibehalten zu können. Das Produktrisiko steigt enorm an und die QA-Phase verlängert sich deutlich stärker als nur linear (alte Anforderungen müssen "erforscht" und intensiv nachgetestet werden).
Folge: Die Kosten für Neuentwicklungen steigen rasant an, jedoch sind die eben genannten Punkte den Auftraggebern oft nicht transparent.

Warum man ein System nicht vorab so planen kann, dass es auf alle Eventualitäten erweiterbar ist.


In klassischer Softwareentwicklung ist eine Strategie gegen das Altlastenproblem die Software so zu planen, dass das Altlastenproblem nie entstehen wird. Das heißt, dass die Software ohne Änderung bestehender Softwareteile ewig erweiterbar bleibt. Dass dies ein reiner Wunschgedanke bleibt, ist spätestens mit einer fachlichen Anforderung belegt, die im Widerspruch zu bestehenden, und bereits umgesetzten Anforderungen steht. Aus Geschäftsstrategischer Sicht ist es einleuchtend, dass eine solche Situation in einer schnelllebigen Welt sehr oft eintreten kann. Einen statischen Plan zu entwickeln steht auch im gravierenden Widerspruch zur dynamischen Komplexität, die die geschäftliche Situation hier deutlich besser abbildet (siehe auch “Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum: Successful Large, Multisite and Offshore Products with Large-scale Scrum”, Craig Larmen und Bas Vodde).</p>

Wie man sich von Altlasten befreit und Agilität erreicht.


Wie aus dem ersten Punkt hervorgeht ist es sehr einfach neue Altlasten aufzubauen. Welche Lösungen schlägt nun die Wissenschaft und Praxis vor, um das Altlastenproblem zu lösen?</p>

Die einstimmige Meinung unter agilen Softwareentwicklern ist, sich der Tatsache bewusst zu werden. Wenn man sich im klaren darüber ist, dass Softwaresysteme über die Zeit fehlerhaft und schwergewichtig werden, kann man Maßnahmen umsetzen, die das kontinuierlich abmildern.
Dazu gehören folgende Punkte:

1) Testgetriebene Softwareentwicklung (Test-Driven Development, Jeff Langr, http://pragprog.com/magazines/2011-11/testdriven-development, Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum, Craig Larmen und Bas Vodde)
2) Spezifikationen anhand von Beispielen (Specification by Example, Gojko Adzic)
3) Kontinuierliche Upgrades von eingebundener Fremdsoftware
4) Die einfachste Lösung umzusetzen, die die Anforderung erfüllt (“You Ain’t Gonna Need It”, http://de.wikipedia.org/wiki/YAGNI)

Wie äußern sich diese Maßnahmen mittel- bzw. langfristig aus monetärer Sicht?

Ad 1) Testgetriebene Softwareentwicklung ist trotz seines Namens nicht gleichzusetzen mit Software zu testen ("Test-first coding is not a testing technique", Ward Cunningham). Vielmehr führt es implizit zu einer jederzeit änderbaren Software, durch das kontinuierliche schreiben von automatischen Tests und dem noch wichtigerem kontinuierlichem Refactoring des neu geschriebenen Codes. Zusammengefasst: Die Kosten für Neuentwicklungen bleiben über die Zeit relativ konstant.

Ad 2) Wenn Anforderungen mit klaren Beispielen dokumentiert sind, werden diese schneller verstanden. Missverständnisse werden reduziert und die rückblickende Information was umgesetzt wurde ist klarer. Ebenso lassen sich Beispiele einfach automatisiert testen, wodurch Anforderungen kontinuierlich qualitativ gesichert werden können, ohne zusätzlichen Kostenaufwand über die Zeit.

Ad 3) Veraltete Fremdsoftware führt langfristig dazu, dass keine Softwareentwickler mehr gefunden werden, die mit diesen Versionen arbeiten können. Das Umsetzen neuer Features wird bei alter Fremdsoftware also verlängert, wodurch die Kosten steigen.

Ad 4) Das Feature wird so umgesetzt wie gefordert, aber auch nicht mehr. Der Aufwand wird auf das nötigste reduziert und Kosten für Planungs-Overhead werden obsolet. Der Return of Investment steigt.

Warum das eine kontinuierliche Tätigkeit bleiben muss


Refactoring ist keine Tätigkeit, die in einem Entwicklungszyklus erledigt werden kann, sondern es ist eine kontinuierliche Tätigkeit. Man kann diese Aufgabe am besten mit der Büroreinigung vergleichen: Würde man das Büro nur einmal im Jahr reinigen, hätte man auch hier einen deutlich höheren Aufwand und das Unbehagen in der übrigen Zeit wäre bei allen Beteiligten nach kurzer Zeit sehr groß.</p>