Softwareübergabe: was ein neues Team selbst schaffen muss

Eine vollständige Softwareübergabe sollte daran gemessen werden, ob ein anderes Team die Anwendung aufsetzen, gezielt ändern und in einer Testumgebung bereitstellen kann. Der Quellcode ist dafür nötig. Ob das übrige Wissen mit übergeben wurde, zeigt erst dieser unabhängige Versuch.

Das ist für den Auftraggeber eine praktische Frage: Wie viel hängt weiterhin an einer bestimmten Person oder einem bestimmten Rechner? Ein vorhandener Download beantwortet sie noch nicht.

Der saubere Rechner zeigt die Lücken

In einem fiktiven Beispiel erhält das neue Team den freigegebenen Stand R-1 eines Bestellportals. Auf dem bisherigen Laptop startet alles. Auf einem frischen Testsystem fehlen jedoch die genaue Laufzeitversion, die Einrichtung einer leeren Datenbank und die Bedeutung zweier Umgebungsvariablen. Der Code ist angekommen; der Aufbau der Anwendung bleibt teilweise ungeklärt.

Eine lange allgemeine Dokumentation kann diese Lücke ebenfalls offenlassen. Nützlich ist eine Anleitung, mit der das neue Team die tatsächlich benötigten Schritte nachvollziehen kann. Die Twelve-Factor-Prinzipien trennen veränderliche Konfiguration vom Code und betonen ähnliche Entwicklungs- und Produktionsumgebungen. Sie liefern dafür Orientierung, aber kein vollständiges Übergabeprotokoll für jede Technik.

Eine kleine Änderung als Nachweis

Für den Beispielversuch wird R-1 mit festgelegten Abhängigkeiten installiert. Das Team legt eine leere Testdatenbank an, verwendet künstliche Zugangsdaten und führt Testauftrag T-31 vollständig aus. Produktionsschlüssel gehören dabei nicht in das Repository oder die Anleitung.

Danach ändert es die Feldbezeichnung „Referenz“ zu „Kundenreferenz“, erstellt die Anwendung neu und stellt sie im Testsystem bereit. Zuletzt wird der vorherige Stand wiederhergestellt. Dieser kleine Eingriff prüft, ob Aufbau, Änderung, Bereitstellung und Rückkehr zusammen verstanden wurden. Er beweist nicht, dass jede spätere Funktion beherrscht wird.

Müssen dabei Schritte vom bisherigen Team nachgereicht werden, gehören sie in die Übergabe und werden erneut ausprobiert. Eine mündliche Erklärung während des Versuchs kann eine Lücke schließen; sie ist erst dauerhaft gelöst, wenn das Wissen für den nächsten Versuch verfügbar bleibt.

Wann ein schmalerer Umfang genügt

Bei einer klar begrenzten Erweiterung einer bereits gemeinsam betriebenen Plattform kann die Übergabe des geänderten Codes ein sinnvoller Teilschritt sein. Eine vollständige neue Betriebsumgebung wäre für diesen einzelnen Auftrag möglicherweise unverhältnismäßig. Dann muss jedoch feststehen, welche Plattformkenntnisse und Zugriffe bereits vorhanden sind und wer sie weiter verantwortet.

Auch Testdienste sind zulässig, wenn echte Schnittstellen im Versuch nicht genutzt werden sollen. Halten Sie fest, welcher Teil dadurch nicht geprüft wurde. Ein simuliertes Zahlungssystem belegt keine funktionsfähige Produktionsanbindung.

Für einen vollständigen Teamwechsel ist der unabhängige Versuch der stärkere Maßstab. Er macht den verbleibenden Übergabeaufwand sichtbar, bevor der bisherige Ansprechpartner nicht mehr verfügbar ist. Das Abnahmeergebnis sollte deshalb den verwendeten Stand, den gelungenen Ablauf und die noch offenen Abhängigkeiten nennen.

Quellen

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity