Ist es fertig oder ist es fertig-fertig?

In einer agilen Welt ist die Definition von "Done" interessant. Manchmal wird eine Funktion als "Done" betrachtet, aus der Perspektive des Entwicklers oder des Entwicklungsprozesses, wenn sie in die "Done"-Spalte verschoben wird. Nun braucht sie "nur" noch getestet und veröffentlicht zu werden. Einfache Sache. Nicht so schnell.

Lass uns diesen Satz in kleine Teile zerlegen und durchgehen - nur dann können wir verstehen und eine Meinung bilden. Vertrau mir, es gibt viele kleine Konzepte, die hier versteckt sind.

Definition von "Done"

Im Scrum erstellt das Team (im besten Fall) eine Definition von "Done". Dies ist ein "Vertrag" zwischen den Teammitgliedern. Es ist wichtig, diese Definition zu erstellen, da wir sonst nicht wissen, wann wir fertig sind. Wenn eine User Story (oder ein Ticket) als "Done" betrachtet wird und sie als Pull Request zur Release-Zweigstelle (eine Anfrage, den Code zum nächsten Release hinzuzufügen) gesendet wird, kann sie als "Done" betrachtet werden. Dies ist nur ein Beispiel. Ich werde dir das Problem mit diesem Ansatz erklären.

Etwas über den Zaun werfen

Die meisten Entwickler, mit denen ich gearbeitet habe, mögen es nicht, spät in den Gedankenprozess einer User Story (oder eines Tickets) einbezogen zu werden. Die meisten möchten das Problem verstehen und selbst eine Lösung dafür finden, anstatt nur die Lösung umzusetzen, die ihnen ein Architekt oder der Product Owner (oder der Ticket-Berichterstatter) vorgibt. Bisher gut. Warum machen Entwickler dann manchmal das Gleiche? Das bedeutet, sie werfen etwas über den Zaun in dem Sinne, dass sie mit ihrem Ticket fertig sein möchten, sobald es in die Release-Zweigstelle eingefügt wurde? Was ist mit dem Testen? Was ist mit der Benachrichtigung des Berichterstatters? Was ist mit dem Sehen im Einsatz? Was ist mit der Integration?

Wie man Entwickler von der Rechenschaftspflicht befreit

Das Schlimmste, was wir als Teammitglieder, Teamleiter oder Manager tun können, ist unsere fähigen Arbeitskräfte aus dem Entscheidungs- sowie dem Release-Prozess zu entfernen. Was ich damit meine, ist dieses Szenario: Pat arbeitet an einem Ticket und sobald sie "fertig" ist, wird es vom QA-Team getestet. Sie finden eine Menge Fehler und entdecken Szenarien, in denen der Code bricht (neben anderen unzusammenhängenden Dingen), an die kein Entwickler je gedacht hätte. Sie fügen so viel Wert hinzu... oder saugen sie nur die Energie aus Pat? Indem wir die Testverantwortung an jemand anderen abgeben, entfernen wir die Rechenschaftspflicht von den Entwicklern. Sie sind dann nur ein kleiner Teil des Prozesses, ein Zahnrad in der Maschine. Sie sehen nie den gesamten Prozess. Aus meiner Erfahrung fühlen sie sich weniger beteiligt und schreiben möglicherweise sogar suboptimale Code, weil sie wissen, dass er später ohnehin getestet wird und sie die Probleme beheben müssen. Natürlich sollten Entwickler ihre eigenen Funktionen testen.

Sie sind dann nur ein kleiner Teil des Prozesses, ein Zahnrad in der Maschine.

Ein anderer Entwicklungsprozess

Eine Alternative dazu ist, einen anderen Entwicklungsprozess einzurichten. Einen, der die Entwickler befähigt. Es ist einfach, aber auch komplex. Und es hält den Entwickler verantwortlich, bis zum wirklichen "Done".

Ein Beispiel für einen Kanban-Entwicklungsprozess:

1. Eine User Story oder ein Ticket kommt herein und wird vom Product Owner priorisiert.
2. Entwickler nehmen es vom oberen Ende des Backlogs (wie in jedem agilen Projekt).
3. Entwickler sind zu 100% verantwortlich für das Verschieben des Tickets in die anderen Prozesszustände (In Progress, Testing, Blocked, Done).
4. Sobald der Entwickler an seiner lokalen Version gearbeitet hat, macht er einen PR (Pull Request) zur Testumgebung (peer reviewed), wo der Reporter oder der Product Owner die visuelle Implementierung überprüft und möglicherweise sogar den Stakeholdern zeigt. Der Entwickler ist voll verantwortlich dafür, seine eigene Funktion vollständig zu testen. Verantwortlich bedeutet nicht, dass er es selbst tun muss. Vielleicht können Kollegen helfen. Vielleicht baut er Tests. Aber er ist verantwortlich.

• Sobald alles gut ist – und es ist potentiell auslieferbar – kann es in den Master-Zweig übernommen werden. Warte, was? Wo ist der Release-Zweig? Es gibt keinen. In einem schnell voranschreitenden Kanban-Entwicklungsprozess wird durch das Durchführen von Integration und Release über Release-Zweige nichts verlangsamt. Stattdessen geht es direkt in den Master-Zweig, was einen Deploy der Zweig auf dem Server auslöst. Dies kann zehnmal am Tag passieren, wenn nötig. Und wir erhalten kleine inkrementelle Releases, was das Risiko reduziert und die Agilität verbessert.
• Erledigt.

Das oben Beschriebene beschreibt den Prozess, bei dem der Entwickler voll verantwortlich ist von In Progress bis Done ohne vage Bereiche wie Done-Done, Released oder Done-Done-Done. Done ist, wenn es fertig ist, wenn es ausgeliefert und in Produktion ist und es Wert schafft. Wie bei allen schlanken Flüssen ist alles, wofür wir Zeit verwenden, bis es ausgeliefert ist, vollkommen vergeudet. Kein Wert. Nur Müll. Erst wenn es in Produktion, auf der Website, voll funktionsfähig ist, schafft es (potentiell) Wert. Aber das ist ein anderer Post...