Agile Datenbankentwicklung? Kenne ich nicht? Brauche ich das? Was ist das überhaupt? So oder ähnlich habe ich bis vor kurzem auch gedacht, bis wir es dann einfach mal ausprobiert haben. 

Wir haben also jetzt vor kurzem unseren ersten Sprint erfolgreich beendet und mein Plan ist, diese Erfahrung und die noch kommenden in einer Art "Mini-Serie" weiterzugeben und vielleicht sogar die eine oder andere Reaktion darauf aus der Leserschaft zu provozieren. Es würde mich freuen, zu hören, wie andere Datenbank-Entwicklung praktizieren. Wo es Gemeinsamkeiten gibt und wo es Unterschiede gibt. 

In diesem ersten Teil widme ich mich zunächst einmal den Hintergründen, die zu unserer Entscheidung geführt haben, agile Prozesse in die Datenbankentwicklung einfliessen zu lassen.

DISCLAIMER

Um es gleich vorweg zu nehmen: Ich nehme keineswegs für mich in Anspruch, ein "Experte" in den diversen Methodologien der Softwareentwicklung zu sein oder die Unterschiede und Feinheiten der verschiedenen (agilen) Prozesse zu kennen, resp. im Detail zu verstehen. Andererseits kann ich auch nicht wirklich behaupten, dass mich der ganze theoretische Überbau übermässig interessiert. Das Philosophieren darüber überlasse ich lieber den wahren Experten, die meinen, etwas dazu beitragen zu können (oder zu müssen). Ich denke, dass ich ein gewisses Mass an gesundem Menschenverstand besitze, ergebnisorientiert handle und nicht komplett prozessorientiert bürokratisch denke, sprich flexibel auf sich ändernde Gegebenheiten und Prioritäten reagieren kann und von daher recht gute Voraussetzungen für einen "agilen Entwickler" mitbringe.

Daher sollte man idealerweise meine Ausführungen am besten als das sehen, was sie darstellen sollen: Beobachtungen eines Datenbank-Entwicklers in einem dynamischen Arbeitsumfeld. Nicht mehr und nicht weniger.

Das soll als Vorwort genügen...

Begriffsdefinition

Was ist nun dieses "Agile" genau? Wikipedia gibt dazu die folgende Antwort:

"Das Ziel agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell. " ^[1]

Mein Hintergrund

Was heisst diese Definition nun konkret für mich und für das Arbeitsumfeld, in dem ich arbeite? Dazu einige Hintergrundinformationen: Ich arbeite in der Investment Banking IT eines grossen Finanzinstitutes für die Abteilung für Strukturierte Aktienprodukte. Meine primären Kunden sind die Händler und Quantitativen Analysten dieser Abteilung. Die Systeme, für die ich verantwortlich bin, sind ausnahmslos eigenentwickelte klassische Front-Office Systeme, die aber (auch) fast schon naturgemäss zahlreiche Schnittstellen in nachgelagerte Abteilungen besitzen. Somit sitzen viele gewichtige Empfänger unser Daten im  Controlling, Risk Management, Mid-Office, Back-Office usw...

Mein gesamtes berufliches Umfeld ist ohne falsche Übertreibung als dynamisch zu bezeichnen. Prioritäten kommen und gehen und ändern sich kurzfristig. Wir hatten noch nie den "Luxus", 6-monatige Release Zyklen zu besitzen, die somit lange im Voraus planbar sind mit klar definierten Requirements, die von einem Heer von Business Analysten entgegengenommen werden und weiter an die Entwickler kommuniziert werden. Überspitzt könnte man es vielleicht so ausdrücken, dass eine zu 90% funktionierende Software, die innerhalb von 3 Wochen zur Verfügung steht, einer Software vorgezogen wird, die vielleicht 95% - 99% abdeckt, dafür aber erst in 3 Monaten verfügbar ist. Die Teile, die dann noch fehlen und/oder nicht ganz einwandfrei funktionieren, werden nachgeliefert und gefixed und fertig. Hauptsache ist, dass schon damit gearbeitet werden kann, während sich das ganze System dann im Laufe der Zeit um diese Kernfunktionialitäten herum entwickelt, grösser, stabiler und reifer wird. Neue Features kommen hinzu, alte werden nicht mehr gebraucht und/oder müssen verändert werden, um veränderten Anforderungen gerecht werden zu können.

Anfangs sass ich direkt bei den Händlern im Handelsraum und es gab zahlreiche Tage, wo an geordnete Entwicklung nicht zu denken war, weil entweder dieses oder jenes schief gelaufen war und gefixed werden musste, oder zahlreiche Anforderungen für Ad-Hoc Auswertung vorlagen und abgearbeitet werden mussten. "Geordnete Entwicklung" zu dieser Zeit war die Umsetzung der strategischen Vorgaben vom Business Owner. Dies konnte zum Beispiel die Einrichtung eines Daten-Feeds an ein anderes System, die Implementierung von mittel- und langfristigen Zielen des Businesses, wie etwa das LifeCycle-Management von Produktklassen mit Einführung von neuen Klassen, Umstellung bestehender oder Ablösung alter Klassen oder ähnliches sein. Dafür gab es konkrete Zeitpläne, die einzuhalten waren. Darüber hinaus gab es die taktischen Ziele. Zu diesen gehörten beispielsweise die Übereinkunft mit dem einzelnen Händler und/oder Analysten zur Entwicklung eines Features. Dieses wurde meistens per Mail als Anforderung gestellt, in einem Projektmanagement-Tool erfasst und nachverfolgt und halt mit dem nächsten Release in Produktion gesetzt, sofern es nicht zeitmässig mit der Umsetzung der strategischen Ziele kollidierte. Das war sozusagen das Tagesgeschäft neben dem Support zur Aufrechterhaltung des Produktionsbetriebes.

Wenn es absehbar war, dass eines dieser taktischen Ziele nicht zu dem vereinbarten Termin erreicht werden konnte, hat man sich halt mit der entsprechenden Person, die diese Anforderung gestellt hat, in Verbindung gesetzt, die Gründe für die Verzögerung erklärt und einen neuen Termin abgestimmt. Meiner Erfahrung nach zahlt sich in solchen Fällen aus, persönlich bei dem entsprechenden Kunden vorbeizuschauen und dies in einem Gespräch zu klären, anstatt nur eine unpersönliche Mail zu schicken oder, noch schlimmer, gar nicht zu kommunizieren. Natürlich mag es niemand gerne, wenn vorher getroffene Vereinbarungen nicht eingehalten werden, aber ich habe bisher keine Situation erlebt, die eskaliert ist, nachdem wir das Warum und Wieso erklärt haben.

Mir gefällt diese Art zu arbeiten nach wie vor, weil ich glaube, dass sie mich davon abhält, in eine Art "beruflichen Alltagstrott" zu verfallen. Allerdings besteht auch durchaus eine reelle Gefahr, dass man mittel- und langfristige Ziele aus den Augen verliert und mit den eigentlichen Entwicklungsaufgaben schnell in Rückstand gerät und so eventuell bestimmte Deadlines nicht mehr einhalten kann.

Irgendwann sind wir dann aus dem Handelsraum in eine andere Etage gezogen und damit einher ging, dass unsere "Sichtbarkeit" gegenüber unseren Kunden geringer wurde, weil jeder einzelne von uns halt nicht mehr jeden Tag vor Ort präsent waren. 

Als dieser Zwiespalt zu gross wurde, wurde dem Bedürfnis nach Formalismus in gewisser Weise Rechnung getragen, als das monatliche Release Zyklen eingeführt wurden. Dies hatte zumindest den Vorteil, als das man Releases besser planen konnte und in gewisser Weise auch Druck von uns genommen wurde, insofern als das unseren Kunden klar wurde, das Features nicht direkt sofort nach Entwicklung in Produktion gesetzt wurden, sondern vielmehr zu im Vorfeld bekannten Daten.

Unsere Entwicklungsmethode behielten wir jedoch bei. Hingegen wurde ab diesem Zeitpunkt die Kommunikation zwischen uns und unseren Kunden mehr und mehr von einer einzelnen Person übernommen, welche die Anforderungen nun zentral entgegennahm und an uns weitergab, so dass wir uns mehr auf die Entwicklung konzentrieren können sollten. Was vielleicht im ersten Moment positiv erschien, weil man sich nicht mehr mit dem Kunden rumärgern musste, bis man endlich eine klar formulierte Anforderung gemeinsam erarbeitet hatte, hat sich im Nachhinein als grosser Fehler erwiesen. Die Weitergabe von Anforderungen über Dritte führt meiner Meinung nach nur zu unnötigen Reibungsverlusten, so dass das Endergebnis unter Umständen nicht das ist, was der Kunde gewünscht hat und was besprochen wurde, bzw. hätte effektiver erreicht werden können. Das kann vielfältige Gründe haben, zum Beispiel:

1. Dieser Vermittler hat andere Vorstellungen von der Priorisierung einzelner Anforderungen und kommuniziert diese nicht klar genug nach allen Seiten.
2. Dieser Vermittler hat die Anforderung nicht richtig verstanden und/oder nicht richtig an den Entwickler weitergegeben.
3. Der Vermittler hat seine eigenen Vorstellungen, wie die Anforderung umzusetzen ist und diese Vorstellungen können von einer tatsächlich effektiven Umsetzung abweichen.
4. Dem Entwickler fehlen für ihn notwendige Hintergrundinformationen zu einer Anforderung, weil der Vermittler sie eventuell anders gewichtet und diese für ihn hingegen weniger bis gar nicht wichtig sind.
5. ...

Gerade der erste Punkt führte oftmals zu Missverständnissen und Last-Minute Changes, weil gerade diese oder jene Anforderung, deren Priorität vorher noch anders beurteilt wurde, dann ganz plötzlich doch noch wichtig wurde und unbedingt in den Release rein musste. Es ist unnötig zu erwähnen, dass darunter die Qualität des Codes gelitten hat, ganz zu schweigen davon, dass der Code nicht immer noch vorher komplett Front-to-End getestet werden konnte.

Im Grossen und Ganzen jedoch lief es aber dennoch soweit ganz gut, bis dann schliesslich Diskrepanzen zwischen "uns" als Data Team und den Entwickler unserer Software Clients im Schwester-Team immer offensichtlicher wurden. Diese C# Entwickler praktizierten Agile schon seit längerem mit einem 2-wöchigen Entwicklungszyklus und einem Release eine Woche später, während wir bei unserem monatlichen Zyklus blieben. In der Mehrzahl der Fälle stellte dies kein Problem dar, da man Datenbank-Changes durchaus entweder abwärts-kompatibel kodieren kann, oder halt eine Version 2 einer Prozedur zur Verfügung stellen kann, auf die dann der Client zu einem späteren Zeitpunkt nach seinem Release zugreifen kann. Aber dann gab es halt doch manche Änderungen, die einen kombinierten Client-/Datenbank Release erfordern, sofern man nicht Verzögerungen auf einer Seite in Kauf nehmen wollte. Dies führte dann meistens zu Out-of-Cycle Releases auf unserer Seite, die jeweils einen erheblichen zeitlichen Mehraufwand nach sich zogen für das Erstellen des Change-Tickets, des Skriptes selber, usw...

Irgendwann einmal kam halt die Diskussion auf, die beiden Release Zyklen miteinander zu harmonisieren und sogar noch einen Schritt weiterzugehen in diesem Zusammenhang und die im Schwesterteam bereits erfolgreich praktizierten agilen Entwicklungsmethoden auch auf die Datenbank-Entwicklung anzuwenden. 

Da wir keinen unüberwindbar grossen Unterschied zwischen "Agile" und unserer bisherigen Entwicklungsmethode feststellen konnten und uns das gemeinsame Festlegen von Prioritäten zusammen mit unseren Anwendern als erstrebenswert erschien, haben wir uns spontan entschlossen, es einfach mal zu versuchen und zu schauen, wie wir damit zurechtkommen.

Zugegebenermassen klingt dies wahrscheinlich recht banal, wenn man es so auf einer Webseite liest und tatsächlich lief unsere Entscheidungsfindung auch mehr oder weniger nach folgendem Dialog ab:

Projektmanagement: "Wollt Ihr nicht mal "Agile" probieren?"
Data Team: "Hm, warum nicht?"
Projektmanagement: "Okay, ich bereite da mal was vor..."
Data Team: "Cool..."

Tja, und diese Vorbereitung des Projektmanagements führte dann zu unserem ersten Sprint Planning. Doch dazu mehr im nächsten Teil...

Nachweise:
^[1]: http://de.wikipedia.org/wiki/Agile_Softwareentwicklung