Qualität lernen

Softwarequalität hat sowohl eine exogene als auch eine endogene Perspektive. Die exogene Perspektive wird vom Benutzer wahrgenommen, wenn er die Software benutzt. Diese Wahrnehmung wird durch den Funktionsreichtum und die Benutzerfreundlichkeit der Software verstärkt. Die Benutzerfreundlichkeit umfasst sowohl die visuellen als auch die Leistungsaspekte der Software. Der Benutzer würde schnell den Appetit auf das Produkt verlieren, wenn es zwar gut aussieht, aber zu langsam reagiert. Nehmen wir den Fall eines Finanzprodukts, das Derivatpreise bereitstellt, so bedeutet eine langsame Reaktion, dass das Zeitfenster verloren geht, in das man investieren kann.

Die endogene Qualitätsperspektive wird viel wichtiger, wenn die Software aus Gründen der Sorgfaltspflicht oder aus einem anderen triftigen Grund geprüft wird. Ein solches Audit kann weitaus mehr Probleme mit der Software aufzeigen, alsallein aus der Benutzerfreundlichkeit oder dem Funktionsumfang ersichtlich sind. Diese Mängel werden durch einen undisziplinierten Entwicklungsprozess in die Software eingebracht, unabhängig davon, ob es sich um einen agilen Prozess handelt oder nicht.

Eine der Techniken, die in der Vergangenheit befürwortet und umgesetzt wurden, waren Code-Walkthroughs oder Code-Inspektionen. Diese Aufgabe, die in regelmäßigen Abständen während des Entwicklungsprozesses wiederholt wurde, verbesserte nicht nur die Codequalität, sondern schuf auch bessere Entwicklungsteams, die mit größerer Wahrscheinlichkeit auch in Zukunft eine bessere Codequalität produzieren würden. Agile Prozesse haben diese Vorteile ungewollt ins Gegenteil verkehrt. Kürzere Sprints mit dem zusätzlichen Druck, kontinuierliche Änderungen vorzunehmen, haben dazu geführt, dass Code-Walkthroughs gegenüber der Auslieferung von Funktionen in den Hintergrund getreten sind, was einen falschen Gewinn an exogener Qualitätsperspektive bedeutet, aber möglicherweise zu einem Verlust an endogener Qualität führt. Wenn die interne Qualitätsperspektive schließlich wichtig wird, ist es oft zu spät und zu kostspielig, sie zu korrigieren. Dieses Szenario kann oft vermieden werden, indem man reifere agile Teams (auch bekannt als XP) mit erfahrenen Entwicklern aufbaut, wo dies nicht geschieht, bauen sich endogene Qualitätsprobleme im System auf. Die Produktverantwortlichen sollten gezwungen werden, die Notwendigkeit einiger dieser zusätzlichen Aufgaben anzuerkennen, um sicherzustellen, dass beide Qualitätsperspektiven erfüllt werden.