Definition of Done – Oder wann ist ein Feature einer Software wirklich fertig?

In der agilen Softwareentwicklung sind kurze Releasezyklen am besten im zwei-wöchentlichem Intervall ein wichtiger Bestandteil des Entwicklungsprozesses. Ziel ist es so früh wie möglich Kundenfeedback einzuholen und dieses zu integrieren. Wenn man heutzutage Webapplikationen im Netz verwendet, merkt man aber oft, dass diese kurze Releasezyklen sehr stark auf Kosten der Qualität gehen und die neuen Features für den Kunden nicht einsetzbar sind, da die Qualität stark hinterher hinkt. Grund hierfür ist zum Einen oft der Druck von und auch auf die Führungsebene, möglichst schnell neue Software auszuliefern. Ein anderer Grund existiert aber auch oft im Team selbst, denn es gibt keine vernünftige Definition, wann ein Feature wirklich fertig ist. Und da gibt es wirklich sehr viel Streitpotenzial, wenn es darum geht, eine Definition von “Fertig” (oder neudeutsch “Definition of Done”) festzulegen.

Wann ist ein Feature bei WOGRA “fertig”?

Auch bei WOGRA haben wir diese Diskussion ausführlich geführt, denn zum einen haben wir uns auf die Fahnen geschrieben, wir halten Termine und Budgets ein und wollen höchstzuverlässig gegenüber unseren Kunden sein, zum anderen ist es aber genauso wichtig, eine möglichst gute Software auszuliefern, die unseren Kunden vollständig überzeugt.

Nun kommt es auch bei uns mal vor, das technische Unwägbarkeiten, nachträglicher Klärungsbedarf oder auch mal Krankheit dazu führen, dass die Terminvorgaben nur schwer einzuhalten sind. Da stellt sich schnell die Frage, welchen Weg man in einer solchen Situation wählt. In einem unserer wöchentlichen Teammeetings haben wir für uns folgenden Weg festgelegt:

• Wir haben eine feste Definition of Done, an die wir uns in jedem Projekt halten.
• Wir liefern nur Features aus, bei denen jeder Punkt der Defintion of Done erledigt ist.
• Sobald wir die Gefahr erkennen, dass ein Feature wird nicht zum geplanten Release fertig wird und wir keine Möglichkeiten haben intern gegenzusteuern (z.B. mit zusätzlicher  personeller Unterstützung), wird unverzüglich der Kunde informiert, dass wir bei diesem Feature ein Problem haben.

Wie sieht denn nun die Definition of Done bei WOGRA aus?

In der Versionsverwaltung existiert ein eigener Branch für das Feature

Die erste Regel gilt unserem Versionsverwaltung-System und lautet: Für jedes Feature wird ein eigener Branch in unserem Git angelegt, der Master-Branch ist für die Entwickler gesperrt. Hierfür ist ein Feature so klein zu schneiden, dass die Entwicklungszeit 10 Tage nicht übersteigt. In den 10 Tagen müssen folgende Punkte für ein Feature entwickelt werden um es dem Kunden ausliefern zu können:

Die Anforderungsbeschreibung für das Feature ist vollständig und vom Kunden abgenommen

Da wir nicht hellsehen können und erst einmal wissen müssen, was der Kunden will, ist die Dokumentation der Anforderungen extrem wichtig. Neben der Anforderungsbeschreibung des Features müssen die in der Projektwelt geltenden nicht-funktionalen Anforderungen bekannt sein, wie die Qualitätsanforderungen an die Software. Ansonsten könnten Anforderungen wie Browserkompatibilität, Mobile Devices usw. nachträglich zu Mehraufwänden führen, die wir hätten vermeiden können.

Wir haben ein von unserem Softwarearchitekten abgenommenes Umsetzungskonzept

Das klingt erst einmal aufwendig, aber uns genügen in diesem Fall bereits UML Diagramme, die die Lösung beschreiben. Wir wollen an dieser Stelle keinen ausführlichen Prosatext, der jedes Detail beschreibt, sondern ein verfeinertes Architekturmodell. Die Abnahme durch unseren Architekten stellt sicher, dass keine Stolperfallen in der Architektur enthalten sind, die uns später Probleme bereiten könnten.

Das Feature ist inkl. Unittests entwickelt

Bei WOGRA legen wir sehr viel Wert auf eine frühzeitige Qualitätssicherung. Das bedeutet auch, dass wir mindestens Test-Driven, im Idealfall Behavior-Driven Software entwickeln. Die Testautomatisierung spielt bei uns eine große Rolle.

Die Benutzerdokumentation für das Feature ist geschrieben (falls vom Kunden beauftragt)

Beauftragt der Kunde eine Benutzerdokumentation, wird diese auch pro Feature erstellt. Wir verwenden hierfür Dokumentationstools, die sich in unsere Versionsverwaltung Git integrieren lassen, weil wir so in der Lage sind, Handbücher über unser Repository zu mergen und zu verwalten und so Änderungen zusammenzuführen und Konflikte analog zu Sourcecode Konflikten zu merken und zu beseitigen.

Vier Augen sehen mehr: Das Feature im Review (Code inkl. Tests, Konzepte und Dokumentation)

Review bei WOGRA heißt nicht nur die Änderungen des Codes zu verfolgen und anschließend den Merge Request freizugeben (wir verwenden hierfür Gitlab), sondern, dass der Feature-Branch vom Reviewer ausgecheckt und übersetzt wird. So können auch alle manuellen Tests vom Reviewer durchgeführt werden in Abgleich mit dem Konzept. Falls eine Dokumentation beauftragt wurde, wird diese ebenso geprüft. Wenn der Reviewer das Feature freigibt, ist das Feature fertig entwickelt und wird in den Master-Branch gemergt.

Umstellung von SVN auf Git, Feature-Verwaltung im Ticketsystem

Das klingt ziemlich umfangreich und aufwendig, aber ist es Dank guter Tool-Unterstützung nicht. Um möglichst effizient zu arbeiten sind wir von SVN auf Git umgestiegen, da mit Gitlab ein Tool zur Verfügung stellt, dass den Review erleichtert und den Merge in den Master-Branch stark vereinfacht. Wir haben unser Ticketsystem ausgebaut, in dem nun nicht nur Kunden-Probleme gemeldet werden, sondern auch die umzusetzenden Features angelegt werden. So kann nun bei jedem Commit von neuem Code die Ticket-ID mit eingefügt werden. Der Feature-Branch wird zusätzlich noch nach der Ticket-ID benannt. So schaffen wir es, Transparenz in der Entwicklung zu schaffen und wissen, welcher Code durch welches Ticket ins System kam.

Ist dieser Prozess perfekt? Nein, mit Sicherheit nicht. Deshalb wird er regelmäßig in unseren Meetings geprüft und nachjustiert. Im Interesse unseres Teams und unserer Kunden.