Nehmen wir an, dass es ein Projekt zur Entwicklung einer Individuallösung gibt. Das Software-Produkt ist produktiv im Einsatz, es gibt aber keinen Bedarf an wesentlichen Änderungen. Es soll erhalten werden, das Budget ist aber begrenzt. Unter den geänderten Randbedingungen übernimmt ein Wartungsprojekt die Produktpflege. In meiner Vision gibt es eine Produktdokumentation, die mit der Methode CARDS+ erstellt und gepflegt wurde. Die Qualitätssicherung des Entwicklungsprojektes hat dafür gesorgt hat, dass die Inhalte in einem Wiki erfasst und weitestgehend fehlerfrei und vollständig sind.

05 Vision Produktpflege

Ausgangssituation

Das Projekt wurde vor zehn Jahren gestartet, zu Beginn mit einem Vorgehensmodell, das in Phasen organisiert war. Vor ca. zwei Jahren fand ein Umbruch hin zu agiler Entwicklung mit Scrum statt. Die Transition ist abgeschlossen. Das Projekt ist stabil und das agile Vorgehen ist nach anfänglichen Schwierigkeiten wieder erfolgreich unterwegs. Der Code aller Releases der letzten drei Jahre befindet sich in einem git-Repository. Eine funktionierende Software-Produktionsumgebung ist vorhanden. Ein Glossar und die Systembeschreibung ist im Wiki nach den Vorgaben der Methode CARDS+ für die letzten vier Releases verfügbar. Eine Architekturdefinition beschreibt die wichtigsten Entscheidungen, geht aber wenig ins Detail. Das Benutzer- und Betriebshandbuch für das aktuell eingeführte Release liegt vor.

Projektinitialisierung

Beim Übergang in die Wartung wird sehr häufig sehr schnell das Team verändert. Die Wartung wird von anderen Personen durchgeführt, weil die “guten alten” Entwickler lieber neue Software produzieren wollen (O-Ton: “Wartung ist für andere!”) oder beim bisherigen Team einfach “die Luft draußen” ist. Dadurch bleibt dem neuen Team nicht genug Zeit, um Wissen aus den Köpfen der Spezialisten in die Systembeschreibung zu übertragen.

ktip Ich habe mehr als einmal erlebt, dass ein lange Zeit unaufälliges Projekt in Schieflage gerät, in eine Krise stürzt. Die erfahrenen Mitarbeiter versuchen zu retten, was zu retten ist (Stichwort “task force”). Das Projekt ist in Schockstarre, nichts geht mehr. In dieser Situation wird niemand in der Lage sein, Wissen zu sammeln und zu sichern. Hat das Team in diesem Projekt versäumt, rechtzeitig das Produktwissen zu sichern, dann wird es im Krisenmodus nicht gelingen. Wissen geht verloren, unwiederbringlich, endgültig. Ein Wartungsteam, dass dieses Produkt nach der Krise übernimmt, beginnt seine Arbeit mit vielen Risiken und Problemen und hat nur den Code alleine als Informationsquelle.

Das Team muss mit der aktuell verfügbaren Produktdokumentation zurecht kommen. Die Nagelprobe wird die ersten Behebung eines Defektes oder die Umsetzung einer kleinen Anforderung sein.

Projektdurchführung

Für das Backlog-Management übernimmt der Product-Owner das bereits vorhandene Product-Backlog. Der Umfang des Produktes wird vorerst nicht erweitert, darum sind die Topics und Epics stabil. Der Product-Owner kann punktuelle Verbesserungen als Case erfassen. In vielen Fällen braucht er nur einen bestehenden Case erweitern. Muss er einen neuen Case anlegen, gibt es bereits einen ähnlichen Case als Vorlage. Ein neuer Case ist oft ein Sonderfall, der ursprünglich mit einem Defekt gemeldet, vom Team analysiert und als Lücke erkannt wurde.

Das Team beschäftigt sich von Beginn an mit dem Code, teilweise müssen sie den Code sehr genau analysieren, um die Funktionen des Produktes vollständig zu erkennen. Ich nenne das gerne Software-Archäologie.

ktip Software-Archäologie ist die Rückgewinnung von wesentlichen Details eines existierenden Systems, die ausreichen, um über das System zu reflektieren, es zu reparieren, anzupassen, abzuändern und das System selbst oder Teile davon zu nutzen.

Gut lesbarer Code ist sehr hilfreich bei der Analyse. Durch die Systembeschreibung bekommen die Entwickler schnell einen guten Überblick, was das Produkt leisten soll. Sie können leicht den Zusammenhang zwischen Problem und Lösung herstellen. Die Architekturdefinition verschafft dem Team einen Überblick über die wesentlichen Entscheidungen ihrer Vorgänger.

Fazit

Startet ein Wartungsteam mit einer guten und vor allem korrekten Produktdokumentation, dann wird der Übergang in die Wartung nicht “schmerzhaft” sein. Mit einer angepassten Projektorganisation und Mitarbeitern, die sich bewusst für ein Wartungsprojekt entscheiden, ist kein Motivationsproblem zu erwarten. Auch die Diskussion darüber, ob ein agiles Vorgehen mit Scrum noch angebracht ist, sollte gleich zu Beginn geführt werden. Ein agiles Vorgehen mit Kanban kann in einem Wartungsprojekt sinnvoll sein. Unabhängig von dieser Entscheidung wird die Produktdokumentation weiterhin gepflegt, punktuell verbessert oder erweitert, passend zum Umfang der Aufgaben im Projekt: Die Behebung von Defekten und Umsetzung kleiner Anforderungen. Die Methode CARDS+ hilft auch hier ohne Einschränkung.