Mit Tests die Kostenkurve kriegen

Bei einem Gespräch unter Kollegen kam wieder einmal das Thema „Qualität der Software“ zur Sprache. Jeder von uns hatte seine eigene Geschichte aus seinem Projekt mitgenommen und mit den anderen geteilt. Wir waren verblüfft, wie schwer es Software-Teams noch immer fällt, Software regelmäßig und funktionstüchtig zu liefern. Um mit gutem Beispiel voranzugehen, entschieden wir daher, diesen Beitrag im sogenannten “Pair Blogging” entstehen zu lassen. Was bedeutet das? Zwei Kollegen arbeiten nebeneinander auf ihren Notebooks in einem Google-Dokument und schreiben was das Zeug hält. Und damit zum eigentlichen Thema.Wir haben das Gefühl, dass auch heute noch viele Unternehmen bzw. das Management die anfänglichen Investitionskosten für einen guten Softwareauslieferungs-Prozess scheuen. Bei Legacy-Systemen ist die Angst vor einem langen und teuren Migrationsprojekt oft noch viel größer. Die Verlockung, schnell Software ohne wirkliche Achtung der Qualitätsgrundsätze zu entwickeln, rächt sich spätestens bei den ersten Anforderungsänderungen der Kunden. Denn zu diesem Zeitpunkt kippt das Verhältnis der anfänglichen Investitionskosten gegenüber den immer stärker steigenden Kosten für jede einzelne Änderung. Das folgende Diagramm, das die "Cost of Change"-Kurven von Berry Boehm, Alistar Cockburn, Scott Ambler und Kent Beck abbildet, macht dieses Phänomen deutlich sichtbar.

Dabei ist es weder notwendig noch sinnvoll, für die Einführung von Testautomatisierung oder Continuous Delivery ein großes Projekt zu starten. Ein erfolgsversprechendes iteratives Vorgehen zeichnet sich durch einen schnellen Return on Investment und geringe Risiken aus. In kleinen Schritten immer genau jenen Teil verbessern, in dem die Schmerzen am größten sind. Welche Komponente sorgt für die meisten Fehler im Test? Diese sollte mit automatisierten Tests überprüft werden, und erstmal nur diese. Wo läuft das Deployment immer wieder schief? Für genau dieses System sollte das Deployment automatisiert werden. Solche Investitionen zahlen sich sofort aus, und wir lernen gleichzeitig für den Umgang mit dem nächsten Problem. Indem man immer das akut größte Problem löst, entsteht Stück für Stück ein Rahmen für agile Softwareentwicklung.Teams benötigen dafür folgende drei Rahmenbedingungen:

1. Verantwortungsbewusstsein für Qualität und Lieferung
2. Die Freiheit und die Freiräume, sich selbstorganisiert darum kümmern zu dürfen
3. Das nötige Können und Wissen

Das Management ist gefragt, diese Rahmenbedingungen zu schaffen. Die Experten für die Etablierung agiler Entwicklungsmethoden seid jedoch ihr in den Teams - fangt einfach mit dem ersten kleinen Schritt an und erfreut euch am Ergebnis eures Schaffens.Der Beitrag entstand im Pair Blogging mit Frank Janisch.