3 Schritte vor und 5 zurück? Wie Qualität uns schneller macht

Keine Kommentare

Führt man Qualitätsmaßnahmen wie TDD, Pair Programming und generell agile Praktiken in Entwicklungsteams ein, wird oft befürchtet, man werde langsamer. Zusätzlich zu der „eigentlichen Aufgabe“ müsse man nun noch Tests schreiben, Reviews durchführen und dann auch noch so viele Meetings …

Dies scheint intuitiv Sinn zu ergeben: Bessere Qualität muss eben teuer erkauft werden. Die Management-Zahlen scheinen diesen Verdacht dann auch noch zu bestätigen: „Wo wir vorher acht Tickets geschafft haben, schaffen wir nun nur noch fünf!“

Menge getaner Arbeit

Dabei werden meine Kolleg*innen und ich nicht müde zu betonen, dass die Steigerung der Qualität dazu führt, dass Teams *schneller* werden. Wie passt das mit den vermeintlichen Fakten zusammen?

Schaut man sich an, was ein Team qualitativ macht, stellt man fest, dass es sich eigentlich „rückwärts bewegt“:

Menge wertvoller Arbeit

Mit jedem Feature erzeugen sie neue Bugs und Code Smells oder arbeiten an den eigentlichen Anforderungen der Kund*innen vorbei. Die Arbeit für die nächsten Wochen beschafft man sich so selbst. Man hat immer etwas zu tun, schafft vermeintlich viel, kommt aber eigentlich nicht voran.

Deshalb zielt z. B. Scrum darauf ab, dass Teams effektiv zusammenarbeiten und wertvolle Features ausliefern, statt möglichst viel abzuarbeiten. Es gilt, die „Menge nicht getaner Arbeit“ zu maximieren und gezielt das umzusetzen, was wirklich Wert schafft. Aus diesem Blickwinkel ist das Team nach Einführung der Maßnahmen deutlich besser aufgestellt:

Qualität: Menge wertvoller Arbeit - vorher & nachher

Es gibt vielfältige praktische Ausprägungen dieser Rückwärtsbewegung:

  • Bugs
  • unnötige Features
  • unnötige Prozessschritte
  • Missverständnisse
  • Operative Notfälle

In der Regel fallen mehrere Faktoren zusammen. Ich möchte zur Verdeutlichung ein konkretes Beispiel bringen: Ein Team wendet 50 % seiner Zeit zum Bugfixing auf und schafft in einer Woche zehn Tickets, also fünf Bugfixes und fünf Features. Innerhalb der gleichen Zeit entstehen acht neue Bugs. Hier läuft also etwas grundsätzlich falsch, obwohl das Team oberflächlich betrachtet mit der Geschwindigkeit von zehn Tickets sogar zufrieden ist und 50 % „Bugzeit“ suggerieren, dass man in Qualität investiert.

Nur auf die Auslastung der einzelnen Teammitglieder und die Menge getaner Arbeit zu schauen, ist also keine sinnvolle Metrik. Wichtig ist, dass sich Teams gezielt in die richtige Richtung bewegen und dabei hochwertige, nützliche Software an den Start bringen.

Avatar

Angelo Veltens arbeitet als Web-Developer bei codecentric Hamburg. Er begeistert sich sowohl für die Frontend-Entwicklung mit JavaScript, als auch die Backend-seitige Entwicklung mit Frameworks wie Grails oder Spring Boot.
Testautomatisierung auf allen Ebenen von Unit- bis Akzeptanztests, sowie der Aufbau von Continuous-Delivery-Pipelines zählen dabei ebenfalls zu seinen Stärken.

Über 1.000 Abonnenten sind up to date!

Die neuesten Tipps, Tricks, Tools und Technologien. Jede Woche direkt in deine Inbox.

Kostenfrei anmelden und immer auf dem neuesten Stand bleiben!
(Keine Sorge, du kannst dich jederzeit abmelden.)

* Hiermit willige ich in die Erhebung und Verarbeitung der vorstehenden Daten für das Empfangen des monatlichen Newsletters der codecentric AG per E-Mail ein. Ihre Einwilligung können Sie per E-Mail an datenschutz@codecentric.de, in der Informations-E-Mail selbst per Link oder an die im Impressum genannten Kontaktdaten jederzeit widerrufen. Von der Datenschutzerklärung der codecentric AG habe ich Kenntnis genommen und bestätige dies mit Absendung des Formulars.

Kommentieren

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