Im letzten Teil der Kolumne haben wir die Differenzen zwischen Product Owner / Sponsor und dem Entwicklungsteam bei Refactorings, die keinen direkten Business Value erzeugen, besprochen (auch zur zweiten Kolumne gab es ein Quickvote!). In der neuen Ausgabe wollen wir die Differenzen zwischen Team und PO / Sponsor bei einem anderen, oft sehr heiß diskutierten, technischen Requirement diskutieren. Es geht um die Einhaltung von Test- und Deploymentabläufen während Livegängen.
Noch ein wichtiger Punkt, der unbedingt angemerkt werden muss: Alles, was ich hier schreibe, ist meine persönliche Meinung und spiegelt auch nur diese wieder. Diskussionen sind herzlich willkommen! Falls sich der eine oder andere Kollege angesprochen fühlt, natürlich ist alles frei erfunden und Ähnlichkeiten sind rein zufällig... :-)
"Test", "Stage" oder "Production" ?
Los geht es also nun mit dem dritten Teil der Kolumne. Dieses Mal ist es, meiner Meinung nach, eine spannende Mischung aus technischen und geschäftsrelevanten Themen.Innerhalb eines von uns seit einigen Jahren betreuten Kundenprojektes wurde nach einigen Auslieferungen und Deployments immer klarer, dass die IT-Infrastruktur wie auch die Auslieferungszyklen für die angeforderte Qualitätssicherung nicht ausreicht. Nach einigen Diskussionen wurde beschlossen, dass wir zukünftig ganz klassische Abläufe "Develop → Test → Stage → Production" installieren werden.
Während der Livegangvorbereitung des nächsten Releases wurde dies einigermaßen eingehalten, und man einigte sich mit dem Kunden darauf, dass die Abnahmen auf der Stage gemacht werden, da er sich wiederum weigerte, Test, Stage und Production exakt gleich auszustatten (Kosten zu hoch). Soweit ist das alles noch kein größeres Problem oder gar ein Showstopper gewesen. Natürlich kam es, wie es meist kommt: Dem Kunden fällt drei Tage vor Livegang und drei Tage nach Abnahme auf dem Stagesystem auf, dass einige Funktionalitäten doch nicht dem Erwarteten entsprechen.
Wie konnte das passieren? Man sparte an Testflankierung, an fachlichen Testprotokollen sowie an Manpower, um das System wirklich auf Herz und Nieren komplett durchzutesten („Soo kompliziert ist das nun ja doch nicht“). Auf die Ansage, dass Entwickler das System nur so gut testen können, wie die Spezifikation geschrieben ist, und die Erfahrung den Entwicklern vielleicht gerade noch hilft, offensichtliche Fehler innerhalb der Domäne zu erkennen, wurde mit einem Schulterzucken reagiert. (Klar ist es eine Aufgabe eines Entwicklers, sich in die Fachlichkeit des Kunden einzuarbeiten und exakte Spezifikationen mit dem Kunden in Kooperation auszuarbeiten!)
Letztlich wurde dem Entwicklerteam am Ende erklärt, dass einfach zuviel Zeit für die verschiedenen Test-Stationen während des Livegangs drauf gingen. Somit konnte man einfach nicht noch ordentlich alle Prozesse durchtesten, man solle doch nicht so stur sein. Es entstand kein größerer Schaden, und auch die Kundenbeziehung selbst wurde nicht allzu sehr unter Spannung gesetzt.
Warum also beschreibe ich dann aktuell dieses Thema? Weil es mir seit Jahren in nahezu allen Projekten, in denen ich arbeite, begegnet!
Meine Meinung zu dieser Kontroverse:
Aus meiner Sicht ist es sehr wichtig, konsequent und stur mit Themen, die die Qualitätssicherung in einem Projekt angehen, umzugehen. Jede kleine Anpassung, jeder kleine Kompromiss kann die Arbeit von Wochen gefährden. Der Kunde erwartet höchste Qualität vom entwickelnden Team, oft jedoch ist er nicht bereit, seinen Anteil zur Qualitätssicherung beizusteuern.Leider wird hierbei auch immer sehr transparent, wie exakt der Kunde testet, wie es um fachliche Testszenarien bestellt ist, und wie sehr diese im Alltag noch angepasst werden. Das Team der Entwickler hat natürlich letztlich jede Änderung mit der heißen Nadel auf dem Produktivsystem zusammengestrickt. Auch dieses Mal hat es wieder funktioniert, was in letzter Konsequenz eigentlich schade ist: So wurden die Folgen wieder verschleppt, und es gab wenig bis keine Eskalation des Dilemmas. Die Entwickler haben technische Entwicklungsschulden aufgebaut. Jedoch macht es natürlich auch wenig Sinn, sich hier stur zu stellen und dem Kunden dadurch noch mehr zu schaden.
Auch die Retrospektiven, wenn es denn welche gibt, sind aus meiner Sicht hier nur bedingt hilfreich. Sie kommen zu spät, da man die Tage nach dem Livegang natürlich zuerst einmal andere Dinge zu erledigen hat, bzw. vielleicht auch einfach das nächste freie Wochenende benötigt, um die „Akkus wieder aufzuladen“. Jedoch sollten solche Themen zeitnah in kritisch geführten und moderierten Retrospektiven ausgearbeitet werden. Dadurch werden die Argumente klar, und man passt entweder die Zyklen an und bespricht die potentiell niedrigere Qualität bewusst mit dem Kunden - oder aber der Kunde passt seine eigenen Qualitätsanforderungen seiner bereitgestellten Teamstärke und Zeit an.
Letztlich ist ein Livegang, solange es keine Continous-Delivery-Ansätze im Projekt gibt, immer ein Kompromiss zwischen zu erreichender Qualität und der bereitgestellten Zeit für die fachlichen Tester. Natürlich spielen Spezifikationen, Stories und all diese Dinge auch eine Rolle, aus meiner Sicht aber in dieser Phase nicht mehr die tragende. Ich habe es leider noch nie erlebt, dass ich eine Spezifikation oder eine Story erhalten habe, die ich ohne jede Anpassung live nehmen konnte (egal wieviele Zyklen durch Nutzermeetings eine Story hinter sich hatte). Daher kann ich hier nur sehr dogmatisch die Sicht der Entwickler unterstützen und die Sponsoren, Geldgeber und Projektleiter dazu auffordern, sich mehr Gedanken über diese Thematik zu machen!
Ich würde mich sehr über eine anregende Diskussion freuen und verspreche auch, die Sicht potentiell antwortender Sponsoren nicht einfach abzuwiegeln, sondern wirklich zu versuchen, die Argumente aufzunehmen und auch hier eine sachliche Diskussion in den Kommentaren zu liefern :-)
Wenn wir dauernd unsere Abläufe aufgrund der engen Maintenance-Zyklen aufweichen, werden wir nie nachvollziehbar bessere Livegang-Ergebnisse erhalten.
