Im ersten Teil dieser kleinen Serie zu agiler Datenbankentwicklung habe ich mich mit der Vorgeschichte befasst, die zu unserer Entscheidung geführt hat, agile Methoden in die Entwicklung einfliessen zu lassen. Dieser Teil endete mit dem Hinweis auf unsere erste Sprint Planung. Der vorliegende Teil nun setzt an diesem Punkt an und beschreibt unser Vorgehensmodell.

Für Leser, die bereits mit der Entwicklung in Sprint-Zyklen vertraut sind, werden die folgenden Ausführungen wenig Neues darstellen, dennoch halte ich es für notwendig, einige grundlegende Begriffe, die ich in Artikel verwende, vorab zu erklären, damit diejenigen Leser, die mit dieser Art von Entwicklung nicht vertraut sind, zumindest einigermassen auf einem identischen Wissenstand sind.

Business Owner

Scrum^[1] nennt ihn auch "Product Owner". Ihm "gehört" das Software-Produkt. Er gibt die strategische Richtung vor, in die das Produkt gehen soll. Er entscheidet - nach Rücksprache mit den Endkunden - über diese Richtung und ist alleine verantwortlich für die Ziele und Prioritäten und die damit verbundenen Termine. In unserem Fall ist der Business Owner zufällig auch Anwender der Produkte.

Entwicklerteam

Diese Gruppe von Personen brauche ich wahrscheinlich nicht näher zu erläutern. Wichtig erscheint mir nur in diesem Zusammenhang das Wort "Team". Es gibt keine "Stars" in dem Team, jeder ist gleichwertig und der Erfolg/Misserfolg fällt stets auf das gesamte Team zurück. Auch auf die Gefahr hin, hier Plattitüden zu wiederholen, aber jedes Team ist nur so gut, wie sein schwächstes Mitglied. Ich habe über die letzten Jahre einige fachlich sehr gute Entwickler erlebt, die bedauerlicherweise schlechte Team-Player waren. Der Performance des Teams als Ganzem waren solche eher Entwickler abträglich und wurden nach und nach durch vermeintlich „fachlich schwächere“ Entwickler ersetzt, die sich aber besser eingefügt haben und dadurch im Endeffekt zur Stärkung des gesamten Teams beigetragen haben.

Unser Team besteht zurzeit aus:

• 1 Architekten
• 1 Business Analysten
• 1 Tester
• 2 Datenbank-Entwicklern
• 9 Client-Entwicklern

Das Team ist derart interdisziplinär aufgestellt, dass beispielsweise kleinere und einfachere Datenbank Tasks von einem Client Entwickler erledigt werden können. Einer der hauptberuflichen Datenbank-Entwickler überprüft anschliessend den so erstellten Code und bringt ihn gegebenenfalls auf die team-internen Standards bevor dieser dann in Produktion gesetzt wird. Ein anderes Beispiel kann vielleicht so aussehen, dass der Architekt kleinere Aufgaben in C# übernimmt.

ScrumMaster

Dies ist zwar ein feststehender Begriff in der Literatur, dennoch mag ich ihn nicht und werde ich auch hier vermeiden, sofern dies möglich ist. Stattdessen fasse ich seine Tätigkeit unter dem Begriff "Projektmanagement" zusammen.

Product Backlog

Das Backlog ist eine Liste aller Anforderungen, die an die Software gestellt werden, aber (noch) nicht implementiert sind. In unserem Fall gelangen Anforderungen sowohl von Seiten des Kunden, bzw. des Business Owners als auch Anforderungen von Seiten des Entwicklungsteams in das Backlog. Naturgemäss ist das Backlog jemals weder vollständig noch komplett leer. Viele Einträge ergeben sich erst während der täglichen Arbeit mit der Software. Einträge von Seiten des Entwicklungsteam ergeben sich meistens durch Code Review nachdem der ursprüngliche Code einige Zeit in Produktion ist, mit dem Ziel, die Software stabiler, leistungsfähiger und/oder skalierbarer zu gestalten.

Was genau sollte nun ein Eintrag im Backlog enthalten? Der bereits mehrfach zitierte Wikipedia Artikel gibt dazu die folgende Antwort:

„Die im Product Backlog eingetragenen Anforderungen sollten nicht technik-, sondern fachlich- und anwenderorientiert sein. Eine etablierte Möglichkeit, um diese Sichtweise zu unterstützen, ist die Arbeit mit sogenannten User Stories.^[29] Eine gute User Story sollte die Antwort auf folgende drei Fragen liefern:

Als User (Wer?) möchte ich diese Funktionalität (Was?), damit ich folgenden Nutzen habe (Wozu?).^[30]“

Das heisst, User Stories wie "Erstellung eines Index x für Tabelle y, um Abfrage z zu beschleunigen" haben im Backlog nichts zu suchen, sondern sind technische Implementierungsdetails. Stattdessen könnte man es vielmehr folgendermassen formulieren: "Als User möchte ich nicht lange auf Funktionalität x in der Applikation warten, da diese wichtig für mein Tagesgeschäft ist." Aus dieser User Story heraus könnte nun ein konkreter Task für den Entwickler die Erstellung dieses Index sein. Jede User Story erhält eine Einschätzung der Priorität. Die Skala für diese Prioritäten reicht von „Trivial“ bis „Blocker“.

Generell können User Stories mehr als einen konkreten Task umfassen. In solchen Fällen arbeiten wir mit Sub Tasks. Je nach Komplexität der User Story und der Anzahl der damit zusammenhängenden Sub Tasks kann es daher auch gut sein, dass nicht alle Sub Tasks und damit auch die komplette User Story nicht in einem einzigen Sprint komplett abgearbeitet werden kann. Laut Literatur sind (Sub) Tasks Arbeitseinheiten, die eine bestimmte Dauer nicht überschreiten sollten. Vielfach wird diese Dauer mit 12 Stunden angegeben. Überschreitet die Einschätzung für den Task diese Dauer, sollte der Task weiter aufgeteilt werden in mehrere kleinere. Wir halten uns zwar nicht buchstabengetreu an solche Vorgaben, versuchen aber schon, Tasks in logisch unabhängige Teile zu zerlegen.

Als Einheit zur Bewertung der Komplexität eines Tasks verwenden wir Story Points mit einem Range von 1 - 20, wobei 1 für einen trivialen Task steht und 20 für einen Task, bei dem man überhaupt nicht einschätzen kann, wie lange er dauern wird oder was er alles noch nach sich ziehen mag. Die Vergabe von Story Points entspricht dem Kenntnisstand über diesen Task zu diesem Zeitpunkt.

Das Backlog stellt also zu jedem Zeitpunkt den Pool der bekannten Anforderungen an die Software dar aus dem der Business Owner in Kooperation mit dem Entwicklungsteam diejenigen auswählt, die im nächsten Sprint realisiert werden sollen. Diese Auswahl geschieht im Rahmen des Sprint Planung Meetings.

Sprint Planung Meeting

In Vorbereitung auf ein solches Meeting gehen der Business Owner und das Entwicklerteam unabhängig voneinander durch das Backlog und setzen die User Stories, die sie im nächsten Sprint realisiert sehen möchten auf die Liste der Aufgaben für den Sprint. Scrum nennt diese Liste auch das "Sprint Backlog".

Wir haben es uns zur Angewohnheit gemacht direkt bei Durchsicht des Backlog, die einzelnen Aufgaben auch gleichzeitig aufwandsmässig einzuschätzen, wenn sie auf die Aufgabenliste gesetzt werden, sofern dies nicht bereits früher geschehen ist, bzw. die frühere Aufwandseinschätzung neu zu beurteilen und gegebenenfalls anzupassen. Das erleichtert die Diskussion darüber im Meeting selber doch erheblich, da alle Teilnehmer direkt abschätzen können, ob sie es mit einem trivialen oder komplexen Task zu tun haben. Eine nachträgliche Überprüfung dieser Einschätzung findet dann später im Sprint Retrospektive Meeting statt.

Im Sprint Planung Meeting selber dann werden nacheinander die einzelnen Stories und/oder Sub Tasks besprochen, die im Sprint realisiert werden sollen. Gemeinsam klärt man die Anforderungen, die hinter den einzelnen Tasks stehen, sofern diese unklar sein sollten. Diese Klärung bedeutet nun aber nicht, dass alles bis ins letzte Detail durchgesprochen wird. Wir diskutieren unklare Stories im Meeting selber nur bis zu dem Punkt, an dem es möglich ist, eine hinreichend genaue Einschätzung des damit verbundenen Aufwands abgeben zu können. Alles Weitere kann dann in separaten Gesprächen in einer kleineren Runde besprochen werden.

Des Weiteren entscheidet man zusammen, ob der Task oder die Story überhaupt auf die Aufgabenliste kommen soll oder wieder zurück ins Backlog wandert. Üblicherweise geschieht dies meistens indem man auf die Priorität des Tasks schaut und die Summe der bereits auf der Sprint-Liste angesammelten Story Points. Tasks mit einer geringen Priorität können durchaus auch wieder zurück ins Backlog geschickt werden, wenn bereits genügend andere Tasks mit höherer Priorität auf der Liste stehen und/oder wenn die Diskussionsrunde der Meinung ist, das andere Tasks mit gleicher Priorität „wichtiger“ sind und diesen der Vorzug gegeben werden sollte.

Was sich jetzt nun vielleicht wie ein Feilschen um Tasks und Prioritäten anhören mag, ist in der Realität erstaunlich einfach und unkompliziert. Wir haben kaum Probleme mit der Priorisierung von Tasks beziehungsweise mit dem Hin-und Herschieben von Tasks aus dem und zurück ins Backlog. Das Sprint Planung Meeting ist auf maximal 1 Stunde angesetzt. In der Regel sind wir aber bereits nach 30 – 45 Minuten damit fertig.

Das finale Ergebnis des Meetings ist dann die Liste der Aufgaben für den nächsten Sprint. In unserem Fall also die Aufgabenliste für die nächsten 2 Wochen.

Daily Meeting

Das Daily Meeting ist der Punkt in "Agile", der mir persönlich am besten gefällt. Hier trifft sich das Team täglich mit dem Business Owner und tauscht sich kurz aus. Man erfährt den aktuellen Stand der einzelnen Tasks und was die Team-Mitglieder seit dem letzten Meeting gemacht haben und planen, bis zum nächsten Meeting zu machen. Dieses Meeting dauert bei uns in der Regel zwischen 10 und 15 Minuten. Es findet kein Austausch über technische Einzelheiten und/oder andere Details statt. Dies kann in anderen Meetings erledigt werden. Was sich einfach anhört, ist manchmal erstaunlich schwierig. Einen Überblick über das Wesentliche zu liefern, ohne in „Tech-Talk“ zu verfallen, bei dem sich nicht nur der Business Owner verliert, ist teilweise schwierig und will gelernt sein. Gelingt dies mal nicht, sollte der Projektmanager (oder Scrum Master) beziehungsweise die anderen Diskussionsteilnehmer einspringen und das Meeting wieder in die eigentliche Richtung lenken und auf das Wesentliche fokussieren.

Unsere Daily Meetings sind überdies nicht in der Form einer Art „Berichterstattung“ an das Projektmanagement organisiert. Es mag sein, dass der Projektmanager das Meeting organisiert und es auch eröffnet. Er ist aber nicht der Hauptansprechpartner, sondern eher eine Art Moderator. Hauptakteure sind die Entwickler, die allen anderen Teilnehmern einen kurzen Rapport geben. Dabei gestalten die Entwickler das Meeting aktiv selber. Keiner wartet darauf, dass er angesprochen wird auf seine Tasks. Vielmehr gehen wir durch die Aufgabenliste und jeder berichtet von sich aus zu seinen Tasks. Wir haben es uns ebenfalls zur Angewohnheit gemacht, im Meeting zuerst die Tasks zu besprechen, die seit dem letzten Treffen erledigt wurden. Anschliessend werden die besprochen, die „im Test“ sind und kurz vor der Fertigstellung stehen. Schliesslich folgen diejenigen, welche noch in der Entwicklung sind, bevor dann am Ende die Frage aufkommt, wer welchen neuen Task aufgreifen will.

Wir nutzen das Daily Meeting auch, um frühzeitig auf die Möglichkeit hinzuweisen, dass Tasks eventuell nicht in diesem Sprint erledigt werden können, respektive falls die Prioritäten sich kurzfristig ändern, neue Tasks aufzunehmen und/oder andere von der Aufgabenliste des Sprints wieder ins Backlog zu schieben. Damit tragen wir dem Umstand Rechnung, dass User Stories sich über die Zeit weiterentwickeln und sich dadurch Prioritäten ändern können.

Wir haben es uns auch zur Angewohnheit gemacht, für Support-Arbeiten, die länger als 30 Minuten dauern, einen eigenen Task zu erstellen. Oberste Priorität für unser Team ist der Gewährleistung eines reibungslosen Produktionsbetriebes. Taucht also eine Störung auf, hat deren Behebung Vorrang vor allem anderen. Erst danach kann wieder zum Tagesgeschäft übergegangen werden.

Die Erstellen eigener Tasks für solche Aufgaben im ersten Augenblick wie unnötiger bürokratischer Aufwand erscheinen, hat aber den Vorteil, dass solche Arbeiten dokumentiert und sichtbar gegenüber dem Business Owner und anderen interessierten Parteien wie Change Management und/oder Audit sind, falls zu irgendeinem Zeitpunkt mal die Diskussion aufkommen sollte, warum Tasks nicht wie ursprünglich geplant erledigt werden konnten, beziehungsweise falls man in der Notwendigkeit geraten sollte, Rechenschaft darüber abzulegen, wann und warum welche Massnahmen zur Behebung der Produktionsstörung ergriffen wurden. Das soll jetzt nicht heissen, dass man minutiös über jeden seiner Arbeitstage Rechenschaft abgelegen und Buch führen sollte oder gar muss, aber in manchen Situationen kann es halt von Vorteil sein.

Sprint Review Meeting

Das Sprint Review Meeting ist eine Zusammenkunft des Entwicklungs-Teams mit allen weiteren interessierten Parteien (Business Owner, User, etc…), um zu zeigen, was während des Sprints realisiert wurde. Die Literatur erwähnt oftmals, dass dies in Form einer informellen Demo der Software erfolgt. Wir verzichten in der Regel auf solch eine Demo. Nur bei wirklich grossen und umfangreichen User Stories, die über mehrere Sprints gehen, greifen wir darauf zurück. Hier dient eine Demo aber mehr dem Zweck, den Business Owner und die Kunden über den Fortschritt auf dem Laufenden zu halten und zu zeigen, dass das Entwicklungs-Team in der Zwischenzeit nicht untätig war.

Da wir räumlich nahe an unseren Business Ownern und vielen unserer Kunden sitzen, erhalten wir Feedback schon vor dem Ende eines Sprints, wenn die entwickelten Teile diesem oder jenem User zum Test und zur Abnahme übergeben werden. Dazu verwenden wir eine ganze Reihe von Testdatenbanken, die speziell für einzelne Usergruppen reserviert sind. In diesen isolierten Umgebungen finden dann die Tests der User statt, ob ein bestimmtes Feature ihren Erwartungen entspricht oder eben nicht.

Dies gibt uns die Möglichkeit, das Review Meeting kurz zu halten. Hauptinhalt des Meetings ist die Einschätzung, ob das Ziel des Sprints erreicht wurde. Diese Einschätzung zeichnet sich aber bereits schon vorher während der Daily Meetings ab, wenn nach und nach absehbar wird, ob und welche Stories komplett realisiert werden, welche nicht und wo die Gründe dafür liegen. In der Regel sind wir damit bereits nach 10 – 15 Minuten fertig und können direkt zum Sprint Retrospektive Meeting übergehen.

Sprint Retrospektive Meeting

Dieses Meeting ist vorrangig für das Entwicklungs-Team und den Projekt-Manager gedacht und findet bei uns zum Abschluss des Sprints oder kurz danach statt. Andere Parteien können gerne daran teilnehmen, in der Regel hat sich aber gezeigt, dass das Interesse ausser dem Business Owner eher gering ist. Sinn und Zweck dieses Meetings ist die Beantwortung folgender Fragen:

1. 1. Was hat im Sprint gut funktioniert und sollte fortgeführt werden?
2. 2. Was hat im Sprint nicht so gut funktioniert und sollte beendet oder verändert werden?
3. 3. Was sollte im nächsten Sprint mal „ausprobiert“ werden?

Fängt man gerade mit „Agile“ an, sind die Analysen der ersten 2 – 3 Sprints wahrscheinlich wenig aussagekräftig. Zumindest, was die Analyse der Statistiken anbelangt, die man über den Sprint erstellen kann. Man kann schlecht einschätzen, was genau ein Story Point ist und wie viel tatsächliche Arbeitszeit so einem Story Point gegenübersteht. Wir lagen teilweise mit unserer Einschätzung komplett daneben und haben für einen als „trivial“ klassifizierten Task Tage gebraucht und für komplexe Tasks mit einer hohen Zahl an Story Points gerade mal 1 – 2 Stunden.

Ebenfalls haben wir den "Fehler" gemacht, dass wir mehr Tasks auf die Aufgabenliste eines Sprints gesetzt haben als tatsächlich abgearbeitet werden konnten. Das hängt nicht zwingend mit Fehleinschätzungen unsererseits zusammen, sondern unter anderem auch mit der Tatsache, dass wir nicht nur ein reines Entwicklungs-Team sind, sondern vielmehr darüber hinaus 3rd Level Support leisten und für den störungsfreien Produktionsbetrieb verantwortlich sind. Das sind Variablen, die sich im Vorfeld schwer quantifizieren lassen. In einem Sprint mag es sein, dass kaum Produktionsstörungen auftreten, während in einem anderen Sprint diese gehäuft auftreten. Aber auch wenn wir einmal diese Produktionsstörungen aussen vor lassen, kam es vor, dass zu viele Tasks mit zu vielen Story Points in einen Sprint gepackt wurden. Das Ergebnis war dann letztendlich, dass gegen Ende des Sprints diese in den nächsten verschoben wurden.

Nach einigen Sprints bekommt man aber mehr und mehr ein Gefühl für die Anzahl der Story Points, die das Team innerhalb eines Sprints realistischer weise unter guten Bedingungen erledigen kann. Auch wird die Vergabe von Story Points "genauer", da man nach einigen Sprints auch ein exakteres Verhältnis von Story Points zu benötigter Zeit erhält.

Ein weiterer Effekt den ich bei uns beobachtet habe, ist, dass es nach und nach leichter fällt, User Stories in Sub Tasks herunter zu brechen. Dadurch gelangt man zu einer akkurateren Einschätzung des Aufwands einer User Story und im Endeffekt auch zu einer exakteren Planung eines Sprints. Die Zahl der Tasks, die am Ende eines Sprints in den nächsten verschoben werden hat dadurch mittlerweile stark abgenommen bei uns.

Schlussbetrachtung

Bereits im ersten Teil habe ich beschrieben, dass wir bereits vor unser „offiziellen“ Einführung von „Agile“ ähnliche Methoden verwendet haben. Daher war schlussendlich der Umstieg auch nicht mit grösseren Problemen verbunden. Der Wechsel auf „Agile“ findet meiner Meinung nach hauptsächlich im Kopf der Beteiligten statt. Es ist die veränderte Denkweise in kleinen iterativen Schritten, die sich schnell und flexibel an Gegebenheiten anpassen, die sich zwar einfach und unkompliziert in der Theorie anhört, aber in der Praxis mitunter Probleme bereitet.

Für uns war der Wechsel auf „Agile“ durchweg mit Vorteilen verbunden. Einer der grössten Vorteile ist die erhöhte Sichtbarkeit und Transparenz des gesamten Teams für den Business Owner. Dadurch dass im Daily Meeting stets ein Vertreter dieser Gruppe anwesend ist, ist dieser stets über den Stand der Dinge in der Entwicklung informiert. Auf der anderen Seite erhält das Entwicklungs-Team auch stets zeitnah aus erster Hand Informationen über Wechsel in den Prioritäten.

Bis hierhin war dies eine ganze Menge eher theoretischer Informationen. Im nächsten Teil dieser Serie werde ich konkret darauf eingehen, wie Tasks eines Datenbank-Sprints aussehen bei uns und inwiefern sich die Datenbankentwicklung durch Sprints verändert hat.

Weiterführendes

Stellvertretend für die Unzahl an hilfreichen Links ist hier eine Auswahl derjenigen, die ich selber verwendet habe, um mich über Agile und Scrum zu informieren:

• Manifesto for Agile Software Development
• Agile Softwareentwicklung
• Scrum.org
• Scrum Alliance.org
• Scrum-Master.de
• Scrum Fibel

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