Das Konzept der Time To Quality verstehen
Heutzutage gibt es viele Metriken, um den QA-Fortschritt zu verfolgen. Die meisten davon sind recht nützlich, aber sie sind alle eher eindimensional, da sie Momentaufnahmen eines bestimmten Zeitpunkts oder Sprints darstellen. Das gilt selbst für Rate- und Trendmetriken, die zwar extrem wichtig sind, aber auch nur Momentaufnahmen liefern.
Als ich bei Symantec arbeitete, fiel mir Folgendes auf:
Es gab viele Metriken, um das *Niveau* der (angeblich) zum Liefertermin erreichten Qualität zu bestimmen. Aber es wurden keinerlei Metriken erfasst, weder im Prozess noch retrospektiv, um die *Kosten* zur Erreichung dieser Qualität zu messen.
Anders ausgedrückt: Uns war nicht wichtig, wie effizient diese Qualität im Verlauf des Projekts erzielt wurde.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
Vielleicht ist Ihr Produkt mit hoher Qualität ausgeliefert worden, aber war dafür tatsächlich so viel Zeit und Aufwand nötig?
Es handelt sich hierbei um eine Effizienzfrage, nicht per se um eine Qualitätsfrage, aber die beiden hängen eng zusammen.
Der Schnittpunkt von Qualität und Effizienz
Qualität und Effizienz überschneiden sich, weil einer der Hauptgründe, warum Softwareprojekte oft deutlich über den zugesagten Zeitplan hinauslaufen (was in der Schlussphase oft als unerwartetes „Aha-Erlebnis“ auftritt), schlechte Codequalität ist. Nicht nur zu Beginn, sondern während des gesamten Projekts.
Ein weiterer Grund, der eigentlich nur eine unausweichliche Folge von schlechter Codequalität ist, sind Defekte, die mehrere Korrekturschleifen erfordern und sich über mehrere Testdurchläufe oder Sprints hinziehen, bis der Fehler tatsächlich behoben ist. Wenn überhaupt.
Diese endlosen Iterationen aus Beheben, Testen und erneutem Scheitern fügen nahezu jedem Softwareprojekt zahllose Personenwochen hinzu.
Interessanterweise wird dieses Scheitern in keiner anderen Projekt- oder Qualitätsmetrik, die ich kenne, spezifisch erfasst. Denn wie oben erwähnt, sind alle diese Metriken Momentaufnahmen und erfassen dieses Phänomen daher nicht.
Mir kam die Idee, dass es einen einfachen Weg gibt, dieses Muster zu erfassen. Ich habe eine Metrik entwickelt, die ich „Time to Quality" oder TTQ nannte.
Einführung einer neuen Metrik: Time To Quality (TTQ)
Die Metrik selbst ist ganz einfach. Sie funktioniert folgendermaßen:
Für jeden Testdurchlauf (wie auch immer dieser definiert ist) wird nicht nur erfasst, wie viele Tests bestanden oder durchgefallen sind, sondern wie viele Tests bereits beim ersten Versuch bestanden wurden. Und wie viele zwei, drei oder mehr Versuche benötigten, bevor der gleiche Test schließlich bestand.
Ein einfaches Beispiel: Wenn Sie 20 Tests durchführen und 5 davon beim ersten Versuch bestehen, beträgt Ihr TTQ-Verhältnis 25 %. Je höher die Zahl, desto besser. Es ist ein einfaches, berechenbares und leicht zugängliches Indiz für Ihre generelle Codequalität.
Diese Metrik ist ein sehr guter Indikator für die anfängliche Codequalität.
Der Grund: Je besser die Qualität des Codes, desto seltener müssen Sie einen Test erneut darauf anwenden, bevor er besteht. Und umgekehrt. Diese Metrik ist wesentlich aussagekräftiger als Fehlerzahlen oder Trendanalysen.
TTQ ist zudem eine äußerst nützliche Metrik zur Projektverfolgung.
Wenn beispielsweise beim ersten Testdurchlauf 70 % der Tests bestanden werden und 30 % fehlschlagen, können Sie davon ausgehen, dass Ihr Projekt zeitlich noch im Plan liegt. Bestehen allerdings nur 20 % Ihrer Tests beim ersten Mal, dann – um es technisch auszudrücken – „Girl, da hast du echt ein Problem! “
Das bedeutet nämlich, dass Sie keinen erfolgreichen ersten Durchlauf hatten. Diese Zeit muss in einem zukünftigen Durchgang als Qualitäts-"Schulden" wieder aufgeholt werden.
Die TTQ-Metrik ist äußerst hilfreich als so genannte "Frühwarn"-Metrik.
Wenn Sie sie konsequent einsetzen, liefert sie sehr präzise Daten, mit denen das PM schon lange erkennen kann, ob das Projekt aus dem Ruder läuft, bevor der "Zug entgleist".
Das bedeutet, dass viel früher proaktive Maßnahmen ergriffen werden können, um wieder die Kontrolle zu gewinnen – und peinliche Eingeständnisse sehr spät im Verlauf des Projekts zu vermeiden, dass der Terminplan völlig aus dem Ruder läuft. Mit anderen Worten: Verwenden Sie einen TTQ-Schwellenwert, um zu definieren, ob das Projekt noch grün ist, in Gelb steht oder kurz vor Rot ist. Machen Sie es zu einem integralen Bestandteil des Projektstatus selbst.
Seien wir ehrlich: Eines der grundlegenden Probleme in Softwareentwicklungsprojekten ist die anhaltende Verdrängung, dass Dinge schief laufen — und zwar massiv —, sobald das tatsächlich offensichtlich wird. Alle haben Angst davor, als „negativ“ abgestempelt zu werden, als zu faul oder nicht engagiert genug, um Dinge in Ordnung zu bringen, oder als kein „Teamplayer“ zu gelten. Die Parallele zu dysfunktionalen Familien liegt erschreckend nahe.
Diese Verdrängung und das Nicht-Aussprechen dessen, was eigentlich jeder weiß, führt zu dem Misserfolgsmuster, ein Projekt erst auf den allerletzten Drücker als weit, weit im Rückstand zuzugeben.
Wenn das vor dem Management nicht mehr verheimlicht werden kann, bewirkt diese böse Überraschung nur, dass sie ihrem eigenen Entwicklungsteam das Vertrauen entziehen — manchmal dauerhaft. Und wer könnte es ihnen verdenken?
Wenn Sie TTQ jedoch konsequent in Ihre Metriken und Ihr Projektmanagement aufnehmen — und auf die Erkenntnisse aus dieser Metrik reagieren —, können Sie das vermeiden.
Die Messung der Time To Quality entpersonalisiert die Entscheidung, bereits in den frühesten Projektphasen einzugestehen, dass sich Termin- und Qualitätsrisiken aufbauen.
Es wird damit sehr eindeutig – eine Frage von Zahlen. Nicht mehr eine Frage von persönlichem Heldentum, das oft mit großen persönlichen Opfern verbunden ist.
Die TTQ-Metrik ist auch für das Projekt-Retro/Post-Mortem sehr nützlich.
Sie ermöglicht es dem Team, genau die Abschnitte des Codes zu lokalisieren, die während des gesamten Projekts schwach waren und es geblieben sind. Und in der Folge, wie effizient das Team bei der Herstellung von Qualität war. Oder wie aufwendig.
Diese Frage wird in Projekt-Retros meist weitgehend vermieden. Zum einen, weil Teams oft nicht das begriffliche Vokabular haben, um sie zu formulieren, zum anderen, weil es politisch häufig heikel ist, konsequent mangelhafte Codequalität aus dem Engineering zu benennen.
Zusammenfassend
TTQ bringt enorme Transparenz und Vorhersagbarkeit in Ihre Projekte – praktisch ohne zusätzlichen Zeit- oder Arbeitsaufwand, da es sich einfach um eine Meta-Analyse bereits erhobener Metriken handelt.
Ich setze TTQ seit zwei Jahrzehnten bei meinen QA-Projekten ein und es findet aus all den oben genannten Gründen große Akzeptanz bei den von mir darin geschulten Projektleitern.
Probieren Sie es aus, und Sie werden selbst sehen. Es wird für Ihr Team wirklich ein Wendepunkt sein. Wie immer: Viel Erfolg!
P.S. Wenn Sie mehr Geschichten aus der Praxis und die Hintergründe zur TTQ erfahren möchten: Ich habe mit Jonathon Wright im QAL Podcast darüber gesprochen.
