Um bessere Qualität in der Entwicklung zu erreichen, gibt es ein Konzept, das sich “Definition of Done” (DoD) nennt. Die Idee, dass das Team sich selbst Gedanken darüber macht, was alles nötig ist, damit eine Aufgabe (Story, …) wirklich erledigt ist, finde ich einen schönen Ansatz. Die Herausforderung sehe ich aber in der tatsächlichen Umsetzung. Ich habe bisher verschiedene Ausprägungen davon erlebt: Die Umsetzung wird mit dem “Holzhammer” durchgesetzt. Durch Zwang von oben oder Gruppendruck entsteht dann eine (evt. unbewusste) Ablehnung und es werden kreative Wege gesucht, die “ungeliebten” Aufgaben zu umgehen. ...

Vor längerer Zeit habe ich als Product Owner mit einem Entwickler-Team zusammengearbeitet. Das Team entwickelte mit Java + Vaadin eine Webanwendung. Als sich die Probleme und Bugs häuften und auch teilweise wiederholten, erkundigte ich mich, ob zu den aufgetretenen Bugs auch dazugehörige Unit-Tests beim Beheben erstellt worden seien. Für jeden Bug ein Unit-Test Das Prinzip, für jeden Bug einen Unittest zu schreiben, hat den Zweck, sogenannte Regressions zu verhindern. Damit ist gemeint, dass ein Bug in der Zukunft wieder auftaucht und erneut behoben werden muss. ...

Gestern ergab es sich, dass ein Kollege und ich in eine Refactoring-Session gestolpert sind. Verschiedene Vorschläge ergänzten sich, aber eines hat mir besonders Spaß gemacht… Als erstes schlug mir IntelliJ folgendes vor: Danach ging es direkt mit dem nächsten Hinweis weiter … Meiner Meinung nach ist es extrem wichtig, die richtigen bzw. gute Werkzeuge zu nutzen, um gute Ergebnisse zu erzielen. Dann macht die Arbeit Spaß und das ist jeden € wert, den die Werkzeuge letztendlich kosten.

Ein Post-Mortem wird häufig im Projekt-Management eingesetzt, um zu analysieren, warum ein Projekt nicht erfolgreich abgeschlossen werden konnte. Im Bereich IT Operations habe ich das Konzept als RCA (Root Cause Analysis) kennengelernt. In der Software-Entwicklung habe ich dieses Konzept bisher noch nicht angetroffen. Auf Störungen im Betrieb wird meistens durch das Erstellen und Bearbeiten von Tickets reagiert. Wir haben Post-Mortem bei uns vor mehr als einem Jahr eingeführt und pflegen ein Dokument, in dem wir jeden Vorfall eintragen und die daraus abgeleiteten Maßnahmen protokollieren. ...

Diese Aussage kam im Gespräch mit einem Kollegen. Meine anfängliche Verwunderung hat sich über Nacht zu einem Thema entwickelt, das mich mehr beschäftigt als ich erwartet hätte. Meine erste These ist, dass wir als Verantwortliche implizit davon ausgehen, dass die Entwicklung qualitativ hochwertige Lösungen liefert, gleichzeitig aber widersprüchliche Signale geben, weil die gewünschte Lösung ja möglichst günstig und schnell umgesetzt werden soll. Meine zweite These ist, dass Qualität für uns EntwicklerInnen anstrengend und natürlich auch zeitaufwändig ist. Die Versuchung ist groß, sich dem zu entziehen und schnell irgendwas über den Zaun zu werfen, was irgendwie (hoffentlich) das gewünschte Ergebnis liefert. ...