Ziele definieren, aber richtig

Die Details der Definition of Done: Wann ist ein Produkt fertig? Natürlich nie!

Ann-Cathrin Klose

© Shutterstock.com / Andrei Simonenko

Schneller ans Ziel kommen – das versprechen sich viele Unternehmen von agilen Methoden. Das ist natürlich eine schöne Vision, in der Praxis warten aber auch auf agile Teams viele Hürden, die es zu bewältigen gilt. Mit der richtigen Vorgehensweise lässt sich wirklich eine Menge Zeit auf dem Weg zum fertigen Projekt sparen.

Wann ist ein Produkt fertig? Natürlich nie! Je nachdem, woran man die Fertigstellung eines Produkts definiert, ist das die einzig wahre Antwort. Es gibt immer noch einen Bug zu beheben oder ein Feature zu optimieren. Auf der anderen Seite steht aber die Deadline, die eine Frist zur Fertigstellung setzt und oft nur begrenzt verhandelbar ist. Irgendwann muss das Produkt also in die freie Wildbahn entlassen werden, komme was wolle.

Die richtige Definition of Done

Wie schafft man es also, mit knappen Deadlines das Beste für den Kunden herauszuholen? Woran erkennt man, ob Code nun gut genug ist oder ob man noch etwas daran tun sollte? Für agile Teams ist eine Definition of Done natürlich die Leitlinie für all diese Fragen, sodass die Antworten bereits zu Projektbeginn feststehen. Und doch lohnt es sich, auch einmal darüber nachzudenken, wie genau man die Definition of Done formuliert, um sowohl den Entwicklern, als auch dem Kunden gerecht zu werden.

W-JAX
 
Frank Sons

Effective Code Reviews

with Frank Sons (code-quality.de)

Alexander Casall

UX für Techies

mit Alexander Casall (Saxonia Systems)

Ansprüche überdenken

Was braucht der Kunde wirklich? Das sollte die erste Frage sein, die vor einer technischen Entscheidung für bestimmte Lösungen beantwortet wird. Nicht immer ist es nämlich die allerneuste Technologie, die der Kunde gerade braucht. Natürlich kann man in der Definition of Done festhalten, dass das Projekt dem State of the Art entsprechen sollte. Bei bestimmten Aspekten ist das auch durchaus sinnvoll. Aber nicht immer.

Wenn der Kunde sich vor allem eine schnelle Lösung wünscht, um eine Idee zu testen oder Mitbewerbern zuvor zu kommen, sind bewährte Technologien oft ausreichend und sinnvoller. Gleiches gilt auch für die Tests: Es mag durchaus sinnvoll sein, jeden Bug im Backend zu finden; das Frontend muss allerdings genau so gründlich getestet werden. Nur, wenn die Usability stimmt, kann das Projekt zum Erfolg werden, egal wie gut die Technologie dahinter ist. Das alles gehört in den Bereich der geschäftlichen Perspektive auf ein Projekt, die Entwickler oft vergessen. Sie einzubeziehen führt häufig zu einer besseren Definition of Done.

Gute Schulden machen …

Zur Fertigstellung eines Projekts gehören auch technische Schulden, die manchmal in Kauf genommen werden müssen. Es gibt gute und schlechte Schulden: Gute Schulden sind Lösungen im Code, die zwar nicht so elegant sind, wie man gern hätte, aber einem definierten Zweck dienen, der über „wenig Aufwand“ hinaus geht. Gute Schulden sind eine Investition in die Zukunft!

Harry Roberts erklärt das Problem mit den technischen Schulden am Beispiel des Studienkredits: Wer einen Studienkredit aufnimmt, um später in einem guten Job ein hohes Einkommen zu erzielen, macht nichts falsch. Er investiert in eine Zukunft, in der er diese Schulden abtragen kann. Wer hingegen einen Kredit für einen neuen Fernseher aufnimmt und weiß, dass er diesen Kredit eigentlich nicht abzahlen kann, bekommt über kurz oder lang Probleme. Auf Code bezogen heißt das: Kurzfristige Workarounds sind okay, wenn dadurch ein Ziel erreicht werden kann, das eine spätere, bessere Lösung ermöglicht. Das darf sich auch in der Definition of Done niederschlagen. Ein Projekt kann durchaus mit ein paar technischen Schulden ausgeliefert werden, wenn die Schulden gerechtfertigt sind. Man darf nur nicht den Überblick verlieren und braucht einen Plan zum Schuldenabbau.

… und schlechte Bugs abarbeiten

Bugs sind natürlich noch einmal etwas anderes als technische Schulden. Technische Schulden entstehen häufig aus Bugs und Bugs gelegentlich aus nicht gut durchdachten Lösungen, die langfristig keiner mehr versteht. Aber: Während technische Schulden zu einer erst einmal funktionsfähigen Lösung führen, führen Bugs unmittelbar zu Fehlern. Sobald ein paar Bugs im Code toleriert wurden, steigt die Wahrscheinlichkeit, dass es immer mehr werden.

Bugs kommen natürlich in allen Farben und Formen daher, um es einmal bildlich auszudrücken. Vom winzigen Anzeigefehler bis hin zum nicht mehr funktionierenden Produkt ist alles möglich. Insofern müssen agile Teams auf jeden Bug unterschiedlich reagieren. Ein Null-Toleranz-Regel in der Definition of Done kann dabei helfen, einer Bug-Flut vorzubeugen. Gerade dadurch entsteht aber die Notwendigkeit einer schnellen Reaktion – und das passt nicht so gut zu festen, vorgeplanten Sprints in Scrum.

Teams, die mit Scrum arbeiten, stehen darum verschiedene Optionen zur Bearbeitung von Bugs zur Verfügung. Die War-Room-Variante ist schwerwiegenden Problemen vorbehalten: Der Sprint wird unterbrochen, das Team arbeitet gemeinschaftlich an der Lösung des Problems, weil das Produkt nicht mehr läuft. Das ist für kleinere Bugs nicht notwendig. Sie im laufenden Sprint parallel zu bearbeiten, bringt allerdings die Planung durcheinander – vorerst kann das Sprintziel dann nicht mehr erreicht werden. Das gilt jedoch nur kurzfristig. Wenn es zur Regel wird, dass Bugs parallel durch einen Teil des Teams bearbeitet werden, sinkt einfach die Velocity des Teams insgesamt ein wenig und stabilisiert sich dann wieder, weil immer jemand an Bugs arbeitet statt Features umzusetzen.

Richtig planen

Das wirkt sich aber auf die langfristige Planung aus, insofern es so etwas in Agile überhaupt gibt. Zwar wird immer nur von Sprint zu Sprint geplant, am Ende will der Kunde aber ja doch wissen, wann er mit dem fertigen Produkt rechnen kann. Und wenn die Velocity sinkt, verschiebt sich die Einschätzung diesbezüglich erst einmal. Immerhin schafft man vordergründig weniger als geplant. Langfristig zahlt sich das aus, wenn es um die Zahl der später auftretenden Fehler geht; wenn das Team kurzfristig jedoch anhand seiner Velocity bewertet wird, kann das zum Problem werden. Das sollte zwar in Agile nicht vorkommen, ist aber doch ein Maßstab, der immer wieder zur Beurteilung agiler Projektteams herangezogen wird.

Daraus kann eine Art der Inflation von Story Points entstehen, die durch das Team zugewiesen werden. Statt von fünf Punkten auszugehen, werden auf einmal acht Story Points angesetzt, um die Velocity hoch zu halten. Das hilft am Ende jedoch keinem: Das Projekt wird so künstlich aufgebläht und schreitet nicht schneller voran, die Vergleichbarkeit des Umfangs der einzelnen Features geht verloren. Dagegen kann es helfen, vor der endgültigen Entscheidung über die Punktzahl einer Story einen Vergleich mit zwei früher umgesetzten Stories vorzunehmen: Einem kleineren und einem größeren. Dadurch entsteht eine Einschätzung des Umfangs im Verhältnis zum restlichen Projekt, die oft realistischer und weniger von anti-agilem äußerem Druck geprägt ist.

Gute Planung – schneller Erfolg

Ein Projekt innerhalb der Deadline abzuschließen ist nicht immer möglich. Wer die richtigen Prioritäten setzt, auch mal ein paar Abstriche an den richtigen Stellen macht und Fehler in der Planung vermeidet, kann allerdings viel Zeit sparen. So wird das Ziel, den Kunden innerhalb der vorgegebenen Zeitspanne zufrieden zu stellen, erreicht, ohne dass das Produkt darunter signifikant leidet. Technische Schulden sind nämlich nicht immer schlecht, und wer es sich zur Gewohnheit macht, Bugs gleich auszubessern, hat am Ende richtig schönen Code. Man muss nur früh genug darüber nachdenken, wie man mit diesen unvermeidlichen Hürden des Projektalltags umgehen will. Dann kann man sie ganz leicht überwinden. Wenn die Definition of Done jedoch unerreichbar hohe Ziele setzt, für deren Umsetzung an anderen Stellen Abstriche gemacht werden müssen, steht dem Team eine schwere Zeit bevor.

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose studiert allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz. Seit Februar 2015 verstärkt sie als redaktionelle Mitarbeiterin die Redaktion bei Software & Support Media. Zuvor war sie als freie Autorin tätig und hat erste redaktionelle Erfahrungen bei einer Tageszeitung gesammelt.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.