Der Einstieg

Nach dem erfolgreichen Kalender 2014 mit Anti-Pattern rund um das Thema Testing gibt es im neuen Jahr einen Kalender und eine Blogserie zum Thema Agil. Den Überblick und Einstieg in den Kalender findet ihr hier. Als Einstieg und für alle, die es nicht mehr erwarten können, hier ein Amuse-Geule vorab zum Thema Missing Definition of Done. Im Kalender selbst ist dies als Rubrik Zugabe bzw. als Titelbild zu finden.

Das Thema

Wir alle kennen das: „Ja, ist fertig. Noch 1-2 kleine Bugs beheben, dann kann das raus. Das Handbuch muss ich natürlich noch aktualisieren. Vielleicht sollten wir auch im Integrationstest noch mal einen intensiveren Blick drauf werfen, wie sich das tatsächlich im Zusammenspiel verhält …“.
Um den Fortschritt und die Qualität eines Projekts angemessen einschätzen zu können, braucht es ein gemeinsames Verständnis davon, wie „fertig“ die getane Arbeit denn tatsächlich ist. Was auf den ersten Blick für jemanden von der Fachseite schon ganz fertig aussieht, muss aus der Perspektive des Entwicklers noch lange nicht so weit sein, und umgekehrt gilt das natürlich genauso.
Agile Entwicklungsprozesse verstärken dabei häufig noch den Druck, Aufgaben vorzeitig als „gut genug erledigt“ zu deklarieren, um innerhalb der Iteration fertig zu werden. Aber auf diese Art und Weise häuft das Projekt schrittweise Entwicklungsschulden an, die dann am Ende doch wieder ganz unagil aufgeräumt werden müssen. Tun wir dies nicht, wird die Velocity des Teams zunächst schleichend und schließlich dramatisch sinken, weil sich die Codebasis in einem unaufgeräumten Zustand befindet, der sowohl die effiziente Weiterentwicklung als auch die Fehlersuche erheblich behindert.

Die Definition of Done

Aus diesen Gründen gibt es die „Definition of Done“. Eine kurzgefasste Liste mit allen Qualitätskriterien, die jeder Eintrag des Entwicklungsbacklogs erfüllen muss, bevor es tatsächlich als „fertig“ im Sinne des Projekts gilt.
Diese Liste kann individuell sehr unterschiedlich aussehen. Neben selbstverständlichen Dingen wie z.B. Check-In, Code-Review und Deployment auf einer Test-Instanz gibt es Punkte, die je Team differenziert betrachtet werden sollten:
– Sind Bugs vollständig behoben oder reicht es, sie dokumentiert zu haben?
– Ist die Dokumentation erstellt (welche?) oder gibt es dafür einen Extra-Punkt?
– Sind alle ToDos im Code behoben, neu ins Backlog eingestellt oder zumindest markiert?
– Vom Entwickler-Unit-Test bis zum Test durch den Anwender: wer hat was, wie, wo schon getestet und mit welchem Ergebnis?
– Änderungen an Rollout- und Migrations-Skripts sind realisiert und getestet, beschrieben oder lediglich identifiziert?
– …

Das große Ziel in agilen Projekten ist, zum Ende jeder Iteration einen produktionsreifen Entwicklungsstand zu haben. Das heißt, wenn die realisierte Funktionalität ausreichend wäre, könnte diese ohne nachzudenken jederzeit in Produktion gegeben werden. Das spricht dafür, in der obigen Aufzählung das Gewicht eher auf die linke Seite der jeweiligen Aussage zu legen, was in der Realität aber nicht immer ganz einfach ist. Hohe Setup-Kosten für Tests und Deployment sowie fehlendes Know-how im Team stehen hier häufig im Weg.
In der Praxis finden wir häufig zwei Ausgangssituationen:

1. Die Definition of Done wird gar nicht erst oder nur sehr halbherzig erstellt, so dass sie im Prinzip keine relevanten Punkte enthält, oder
2. sie ist zur Wunschliste mutiert und enthält all die schönen Dinge, die man schon immer machen wollte oder sollte, aber nie hinbekommen hat

In der Konsequenz wird sie in beiden Fällen vom Team ignoriert. Damit Ihnen das nicht passiert, kommen hier unsere Tipps & Tricks zur Arbeit mit der Definition of Done.

Tipps & Tricks

• Realismus – Für eine gute Definition of Done gilt: sie sollte das Team ein wenig fordern, aber nicht ernsthaft weh tun. Dinge, die vom Team nicht zuverlässig geleistet werden können, sind nicht Bestandteil der Definition of Done.
• Weiterentwicklung – Im besten agilen Sinne sollte sich die Definition of Done stetig weiterentwickeln. Im Rahmen von Review und Retrospektive sollten Teams ausgehend vom aktuellen Qualitätsstand entscheiden, welche neuen kleinen Maßnahmen sie in ihrem Entwicklungsprozess neu aufnehmen wollen. Mit der Aufnahme in die Definition of Done sind diese Maßnahmen verpflichtend für das Team.
• Definition of Ready – Bei der Analyse von Qualitätsproblemen im Rahmen einer Retrospektive kann es passieren, dass das Team feststellt, dass die Kernursachen schon im Vorfeld der Entwicklung liegen. Für diesen Fall gibt es die Definition of Ready, die die Punkte enthält, die ein Product-Backlog-Eintrag erfüllen soll, bevor er überhaupt in einen Sprint eingeplant wird.
• Liegengebliebenes – Im Rahmen des Review-Meetings sollten Teams auch Baustellen und Liegengebliebenes ansprechen, was ihnen bei der Entwicklung aufgefallen ist. Es empfiehlt sich, genau dies als Teil der Definition of Done dem Team immer wieder ins Gedächnis zu rufen.
• Das Ziel – Das Ziel in agilen Projekten ist, immer alle Arbeiten zum Sprintende auf einem Qualitätsniveau abgeschlossen zu haben, das „produktionsreif“ ist. Das heißt, wenn die Funktionalität ausreichend wäre, um in Produktion zu gehen, würde es nicht an der Qualität scheitern. Das klappt in der Regel nicht auf Anhieb, aber eine Definition of Done ermöglicht zumindest realistisch einzuschätzen, welchen Qualitätsstand das Projekt regelmäßig erreicht.

Fazit

Die Definition of Done ist kein notwendiges Übel, das erfahrene Teams nicht brauchen, weil sie ohnehin wissen, was zu tun ist. Sie ist auch nicht reine Schikane von herbeigerufenen Scrum Coaches, die analysieren sollen, warum das agile Entwicklungsteam nicht so „performt“, wie es soll. Vielleicht hilft ein kleiner Vergleich aus einem anderen Bereich: Möchten Sie, dass der 50-jährige Pilot mit 25-jähriger Flugerfahrung, der dieselbe Strecke sechsmal jeden Tag fliegt, seine Checklisten ignoriert, weil er ja genau weiß, was er zu tun hat? Sicher nicht! Softwareentwicklung ist sicher nicht vergleichbar mit Luftfahrt, aber beides sind komplexe Tätigkeiten, bei denen es auf die Einhaltung von vermeintlichen Kleinigkeiten ankommt. Bestmögliche Resultate werden nur erzielt, wenn alle Aspekte bedacht und erfüllt sind. Warum freiwillig schlechter sein, als man könnte? Es ist doch so einfach: es steht alles in der Definition of Done!