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.
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.
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?
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.
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:
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...
We help companies with their technology, providing CTO-services and Product Management. Trusted for our CTO-services, we work with both startups and established businesses in the Nordics, Switzerland and US.
We are a Swiss Company (LLC) based in 
Switzerland.