Dieser Blogeintrag ist der Anfang einer Serie von Blogeinträgen, in denen ich meine Erfahrungen mit der Organisation von Wartung und Weiterentwicklung von Individualsoftware weitergeben möchte. Hierbei betrachte ich in einer Art Retrospektive die Erfahrungen, die ich mit meinem Team bei Opitz Consulting gesammelt habe. Dieses Team erbringt unter dem Namen „Managed Services Applications“ Dienstleistungen für unsere Kunden. Zusätzlich fließen auch viele weitere Projekt- und Wartungssituationen aus den vergangenen Jahren ein, bei denen wir in unterschiedlichsten Konstellationen (gemischte Teams, Beratungsdienstleistungen, Professional Services) uns zum Thema Wartung und Weiterentwicklung bei unseren Kunden eingebracht haben.
Wie in einer Retrospektive üblich teile ich meine Erfahrungen in vier Kategorien ein (siehe auch http://www.retrospectives.com/pages/RetrospectiveKeyQuestions.html):
- Was war gut und ich würde es weiter so machen?
- Was sollte ich beim nächsten Mal anders machen?
- Was habe ich gelernt?
- Was verwundert mich immer noch?
Anfangen möchte ich heute mit einer Erfahrung, die ich aus positiver und negativer Sicht gemacht habe und die somit sowohl unter der Kategorie „Was war gut?“ als auch unter „Was sollte ich beim nächsten mal besser machen“ auftauchen kann:
- „Softwareentwicklung und Softwarewartung durch getrennte Teams verursacht Schmerzen“
- „Softwareentwicklung und Softwarewartung ist dann erfolgreich, wenn diese aus einer Hand durch ein Team erfolgt“
Meine Erfahrung zeigt, dass in der Praxis häufig die Entwicklung der Lösung (Projekt) und die anschließende Wartung organisatorisch getrennt werden. Auf die Spitze wird dies getrieben, wenn auch kleinere Erweiterungen (CRs) über ein Entwicklungsteam abgewickelt werden, während das Wartungsteam sich nur um die vermeintlich unangenehmen Dinge wie Bug Fixing und Rufbereitschaft kümmern darf. Aus meiner Sicht sprechen viele Gründe gegen diese strikte Trennung.
Wissenstransfer
Der notwendige Wissenstransfer aus dem Entwicklungs- in das Wartungsteam erzeugt hohe Kosten und Reibungsverluste. Dies verschärft sich noch, wenn der Wissenstransfer nicht nur einmal erfolgt sondern kontinuierlich erfolgen muss. Dies ist für viele Systeme, die sich nicht am Ende ihres Lebenszyklus befinden, aber durchaus der Fall.
Besonders die agile Softwareentwicklung schreit in diesem Zusammenhang nach Entwicklung und Wartung durch ein Team. Optimaler Weise werden in agilen Entwicklungsprojekten bereits frühzeitig erste Ergebnisse produktiv gesetzt. Die erste Produktivsetzung definiert den Beginn der Wartungsphase. Häufig ist zu einem so frühen Zeitpunkt ein dediziertes Wartungsteam nicht denkbar und ein regelmäßiger Wissenstransfer kaum möglich.
Achtung: Eine ausreichende Dokumentation ist trotzdem sinnvoll. Wartung und Entwicklung aus einem Team heraus lässt die Dokumentation im ersten Moment weniger wichtig erscheinen. Hier sollten aber Reviews und ähnliche Maßnahmen dazu führen, dass die Dokumentation nicht vernachlässigt wird. Ich ergänze dies als weitere Karte unter „Was habe ich gelernt?“
Auslastung
Erfolgt Softwareentwicklung und Wartung aus einem Team heraus ist es deutlich leichter die Teams kontinuierlich zu beschäftigen. Auslastungsschwankungen sollten durch das temporäre Hinzufügen von Entwicklern (ggf. auch Externe) ausgeglichen werden. Am Ruder bleibt immer das langfristig eingesetzte Wartungsteam. Dies ist eine weitere Karte (diesmal in der Kategorie „Was habe ich gelernt?“) wert: „Die Wartung gibt den Ton an“.
Verantwortung
Die Trennung von Wartung und Entwicklung wirkt sich negativ auf das Verantwortungsbewusstsein der beteiligten Personen aus. Entwickler identifizieren sich mit der durch sie entwickelten Software und sind um hohe Qualität bemüht. Wurde die Software durch ein anderes Team entwickelt, kann sich das Wartungsteam leicht auf ein „den Fehler haben die Anderen eingebaut“ zurückziehen. Verschärft wird dieses Problem, wenn auch noch unterschiedliche Vertragspartner Entwicklung und Wartung übernehmen. Hier wird dann gerne und lange über den Verursacher und die Übernahme von Kosten (Gewährleistung ja oder nein) diskutiert.
Motivation
Wartungsaufgaben werden eher als uninteressant empfunden. Gleichwohl sind viele Probleme in der Wartung hochkomplex und benötigen sehr fähige Softwareentwickler für die Analyse und Lösung. Das Zusammenlegen von Entwicklungs- und Wartungsaufgaben in ein Team ermöglicht einen Ausgleich zwischen unterschiedlichen Aufgabentypen. Stärken und Schwächen aber auch Vorlieben einzelner Mitarbeiter können und sollten berücksichtigt werden.
Abschließende Überlegungen
Sinnvoll erscheint die Steuerung des Wartungs- und Entwicklungsteams über Kanban. Ich notiere dies auf einer Karte unter der Rubrik „Was verwundert mich immer noch?“ und merke mir dieses Thema für einen späteren Blogeintrag vor.
DevOps treibt den Gedanken weiter. Betrieb wird ebenfalls ins Team integriert. Auch dies ergänze ich als Karte unter „Was verwundert mich immer noch?“ und betrachte es vielleicht später in diesem Blog im Detail.
Und zum Schluss der wichtige Hinweis: „Jede Situation ist anders!“. Es gibt keine Standardvorgehensweisen. Höchstens Best Practices und Rahmenwerke, an denen man sich orientieren kann, die am Ende aber immer individuell angepasst und kontinuierlich hinterfragt und verbessert werden sollten.
