26. März 2014

Definition of Done – oder was heißt eigentlich „fertig“?

Share

„Hast du die Änderungen fertig?“ „Ja, letzten Freitag schon.“ „Ah, super. Schau ich mir gleich mal an.“ „Äh, nee, also sie sind noch nicht auf der Webseite.“ „Oh, ok. Aber könntest du sie dann heute noch live stellen?“ „Hm, naja, also die Tests sind noch nicht alle durchgelaufen und wir müssen noch prüfen ob es Auswirkungen hat auf die anderen Seiten und ...“
Typische Situation. Hier haben offensichtlich zwei Menschen ganz unterschiedliche Vorstellungen davon, was ‚fertig’ eigentlich bedeutet. Während der erste, der Auftraggeber, gedanklich die Gleichung „fertig = benutzbar und zur Benutzung freigegeben“ aufmacht, versteht der zweite, vermutlich der Entwickler, unter ‚fertig’, dass alle geplanten Aufgaben erledigt und das isolierte Feature abgeschlossen ist und er oder sie daran nichts mehr zu tun hat.
Beide Definitionen haben in einem semantischen, inhaltlichen Sinne ihre Berechtigung. Das Problem entsteht nur dadurch, dass man sich nicht einig ist.
In Scrum gibt es daher die Idee der ‚Definition of Done’, also einer gemeinsamen, allen Beteiligten bekannten und sichtbaren Festlegung, was erledigt sein muss, damit eine Aufgabe als „fertig“ bezeichnet werden darf. In der Software-Entwicklung ist dann zum Beispiel vermerkt, wie ein Feature dokumentiert sein muss, dass bestimmte (bzw. alle vorhandene) Tests fehlerfrei durchgelaufen sind und auf welchen Browsern und Browserversionen ein Feature laufen muss.

Definition of Done nicht nur für IT-Themen

Doch während es in der IT viele Beispiele und Erfahrungen mit Definition of Done gibt, wäre eine solch explizite und transparent gemachte Vereinbarung überall sinnvoll, wo Menschen als Team zusammen arbeiten und Verantwortung übernehmen.
So taucht in den meisten technischen Definitions of Done das Kriterium des Peer Review auf, also der Check durch einen Kollegen, Vier-Augen-Prinzip. Dies darf getrost als Maßgabe für so ziemlich alle Ergebnisse gelten, egal ob es um die Vermeidung von inhaltlichen Fehlern, Tippfehlern oder Bugs geht. Auch die Frage nach ausgelieferten Formaten – egal ob Powerpoint oder PDF oder HTML 5 oder Java – ist in jedem Team relevant, Regeln des Speicherortes und Dokumentennamens und nicht zuletzt die Frage, wer über Ergebnisse in welcher Form benachrichtigt werden sollte.
All solche Dinge bürgern sich in Teams, die länger in der gleichen Zusammensetzung miteinander arbeiten, irgendwann ein – oder auch nicht. Diese Regeln klar anzusprechen und transparent zu machen, birgt deshalb nicht nur ein Chance für die bestehenden Mitarbeiter, die ein Bewusstsein über entstandene oder mögliche Missverständnisse und Abweichungen entwickeln, sondern erleichtert vor allem auch neuen oder nur selten anwesenden Kollegen die Einarbeitung.

Common Sense, nicht Vorgabe

Dabei sollte die Definition of Done eine Einigung zwischen den Teammitgliedern sein und die entwickelte gemeinsame Meinung abbilden und weder utopisches Ziel sein noch aufdiktierte Richtlinie. Und sie sollte, gerade weil man so alltäglich mit ihr zu tun haben wird, nicht in der Ablage oder dem hintersten Winkel des Firmenverzeichnisses verstauben, sondern offen sichtbar sein, für jeden der vorbei kommt und im Zweifel auch jeden Tag aufs Neue.
Denn eine solche Definition ist keine Pedanterie. Sie verhindert einfach nur Ärger, Leerlaufzeiten oder Fehler, die entstehen wenn Leute aneinander vorbei reden oder vielleicht sogar bewusst so wenig wie möglich machen.
Was „fertig“ bedeutet, ist dann nicht mehr Ansichtssache.

 

Share

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hiermit akzeptiere ich die Datenschutzbedingungen.

Rufen Sie uns an: 030 – 555 74 70 0

Made with 
in Berlin. 
© leanovate 2024