Gegensätzlichkeit als Chance

Voneinander lernen

Agile Softwareentwicklung setzt auf die Gestaltung der Aktivitäten nah an der Software und auf die Motivation der Beteiligten – und damit auf einen Erfolg, der aus der Kraft des Teams erwächst. Qualität ist hier eine emergente Eigenschaft richtiger Softwareentwicklung. Klassisches Qualitätsmanagement hingegen stützt das Management von außerhalb des eigentlichen Teams – und bietet damit mehr Möglichkeiten, der Eigendynamik eines Entwicklungsteams eine gezielte Steuerung im Sinne der Auftraggeber und Nutzer entgegenzusetzen. In diesen Grundprinzipien sind die beiden Ansätze fundamental anders. Komplementäre Ansätze bergen aber immer auch die Chance, Elemente von beidem zu verbinden, ohne die Grundprinzipien des präferierten Vorgehens zu verraten. Anhänger agiler Verfahren müssen sich nicht zuerst die dokumentenlastigen Elemente des Qualitätsmanagements zu eigen machen: Es gibt genügend konstruktive Verfahren, die im Qualitätsmanagement etabliert sind, in der IT aber noch der Entdeckung harren (Kasten: „Arbeitstechniken für Qualität“). Solche Elemente können gezielt in den eigenen Softwareentwicklungsprozess integriert werden, ähnlich wie man technische Tools zu Spezialthemen integriert. Agile Verfahren können auch bewusst mehr Stakeholder einbeziehen, um die Anforderungen besser zu verstehen. XP fokussiert auf den fachlichen Ansprechpartner und lässt andere berechtigte Interessen außen vor: Wer stellt bei XP denn eigentlich sicher, dass die Anforderungen des IT-Betriebs berücksichtigt sind? Scrum macht es sich einfach, indem die gesamte Anforderungspriorisierung an den Product Owner delegiert wird. Dieser muss also abwägen zwischen Anforderungen der Fachabteilung, des IT-Betriebs sowie der Unternehmensvorgaben und auch noch Budgets und Termine im Blick haben. Er ist bestimmt dankbar, wenn das Entwicklungsteam ihn unterstützt, indem es beispielsweise die Methode des Quality Function Deployments einsetzt, um Zielkonflikte zwischen Anforderungen aufzuzeigen. Die konstruktiven Qualitätssicherungstechniken und das Einbeziehen aller Stakeholder kann für agile Teams eine ähnliche Bedeutung gewinnen wie der Einsatz von Unit-Tests: Eine unverzichtbare Arbeitstechnik, mit der man stets sehen kann, ob man im grünen Bereich ist. Die Teams werden dabei die Arbeitstechniken für sich adaptieren. Und das sollten sie auch über ein konkretes Projekt hinaus ins Unternehmen tragen und damit zum Organisationslernen beitragen.

Umgekehrt kann das Qualitätsmanagement aus dem Studium agiler Verfahren lernen, sich besser in die spezifischen Arbeitsweisen der Softwareentwicklung zu integrieren. Es gibt tatsächlich einen eklatanten Unterschied zwischen Software und den meisten anderen Produkten: Das, was in der Softwareentwicklung erstellt wird, der Sourcecode nämlich, ist bereits ein lesbares Dokument. Es beschreibt die Software sehr präzise und kann bei guter Versionierung auch nicht abweichen. Viele andere Disziplinen würden sich wünschen, ihre Produkte durch einen automatischen Prozess direkt aus der Dokumentation erzeugen zu können. Deswegen ist alles, was im Softwareentwicklungsprozess „Dokumentation“ genannt wird, immer zusätzliche Dokumentation – und da muss man schon genau fragen, was und für wen sie erstellt wird. Es wird immer noch zu viel Dokumentation erstellt, die nur in unpräziserer Form Dinge wiederholt, die schon besser im Sourcecode stehen. Wichtig ist, die Dinge zusätzlich zu dokumentieren, die man im Sourcecode nicht findet: Übersicht, Kontext und vor allem Begründungen für Designentscheidungen. Denn damit kann ein Softwarewartungsteam später nachvollziehen, welche Überlegungen der ursprünglichen Software zugrunde liegen. XP schlägt vor, den grundlegenden Architekturansatz in Form einer Metapher zu formulieren, was aber selten umgesetzt wird. Im Kleinen hat sich die Angabe von Pattern direkt als Kommentar im Sourcecode etabliert, aktuell erlebt der Einsatz von Metadaten als hilfreiche Beschreibung von Strukturen und ihrer Bedeutung einen Aufschwung.

Qualitätsmanagement berücksichtigt nicht nur die Interessen des eigentlichen Entwicklungsteams. Qualität muss zunehmend nicht nur vorhanden, sie muss auch auditierbar sein, um Compliance-Anforderungen zu erfüllen. Und das langfristig: Fachliche Korrektheit, Sicherheit und Berechtigungen müssen auch dann noch zuverlässig prüfbar sein, wenn das ursprüngliche Entwicklungsteam sich längst ganz neuen Themen zugewandt hat und jeder Code-Review einen hohen Einarbeitungsaufwand bedeuten würde. Hier hilft aber eine separate Dokumentation auch nur bedingt weiter – Dokumentation veraltet meist schneller als die Software selbst. Hilfreich ist es, wenn die besonders relevanten Bereiche in einer besonders gut wartbaren und auditierbaren Form umgesetzt werden: als Regeln in einer Rule Engine, ausgelagerte Konfigurationen oder durch Spezialprodukte mit Benutzerschnittstellen für Audits. Damit werden die entscheidenden Informationen lesbarer und sie bleiben aktuell – schließlich wird die ausgelieferte Software direkt aus ihnen generiert. Fachliche Funktionen werden meist in Rule Engines abgelegt. Für die Authentifikation und Authorisierung gibt es Spezialsoftware, die z. B. im Web alle Zugriffe auf URLs prüft und die Berechtigungen in lesbarer Form als Konfiguration hinterlegt. Andere Spezialprodukte übernehmen die Berechtigungsverwaltung für Web-Service-Zugänge in der Business-to-Business-Integration.

Agile Entwicklung und Qualitätsmanagement werden noch zahlreiche andere Ansatzpunkte finden, an denen sie voneinander lernen können. Dazu müssen sie nichts weiter tun, als miteinander ins Gespräch kommen und Erfahrungen aller Beteiligten respektieren. Denn letztlich gibt es doch nichts Schöneres, als festzustellen, dass vermeintliche Feinde keine sind und man friedlich zusammenarbeiten kann.

Arbeitstechniken für Qualität

Qualitätsmanagement bietet nicht nur Prozesse und Dokumentation, sondern hat Werkzeuge zur Konstruktion von Qualität hervorgebracht, die sich auch in agile Verfahren integrieren lassen:

FMEA: Die Failure Mode Effect Analysis stellt Murphys Gesetz in den Mittelpunkt: Was schiefgehen kann, wird schiefgehen. Deswegen wird hier von vornherein der Blickpunkt gewechselt: Wir testen nicht, ob alles richtig ist, sondern überlegen, was alles schiefgehen kann. Und warum. Und wie schlimm die Auswirkungen wären. Wenn man das einmal richtig durchdenkt, erkennt man, wo die wesentlichen Risiken liegen. Genau dort lohnt es sich, in Vorbeugung und Qualität zu investieren. Wird FMEA umfassend eingesetzt, kann sie sehr aufwändig werden. Für spezifische Bereiche, insbesondere das Verhalten komplexer Systemarchitekturen, lohnt es sich aber oft. Ein Beispiel: Bei einer Anwendung zum Börsenhandel wird der Fall betrachtet: „Was passiert, wenn die Order nicht an die Börse geschickt werden kann?“ Zunächst scheint der Fall bereits behandelt zu sein – der Anwender bekommt sofort nach Orderaufgabe eine Fehlermeldung angezeigt. Die genaue Überlegung „Was kann den Fehler verursachen?“ zeigt aber zwei völlig unterschiedliche Situationen auf: Entweder wird die Verbindung direkt als unterbrochen gemeldet, oder der Server antwortet nicht. Während der erste Fall mit einer klaren Fehlermeldung angezeigt werden kann, führt der zweite Fall zur Frage, wie die Timeouts der vorgelagerten Systeme eingestellt sind, und ob an der Benutzerschnittstelle überhaupt eine eindeutige Information über den Oderstatus vorliegt. Wer also den Serverausfall nur testet, indem das Netzkabel herausgezogen wird, der übersieht gerade den kniffligen Fall. FMEA hilft weiter.

Poka Yoke: Der japanische Begriff bedeutet in etwa „dumme Fehler vermeiden“. Er geht von dem Gedanken aus, dass man menschliche und technische Fehler nie ganz vermeiden kann, dass es aber oft verblüffend einfache Mechanismen dagegen gibt. Die Mechanismen können versehentliche Fehler reduzieren (indem sich Stecker z. B. gar nicht falsch herum einstecken lassen) oder helfen, sie schneller zu erkennen. Auch in Software lassem sich Entsprechungen finden: Eine Prüfziffer in der Kundennummer hilft, Tippfehler bei der Erfassung zu erkennen. Beim Datenaustausch reichen die Durchnummerierung und ein Ende-Kennzeichen, um die Vollständigkeit der Übertragung zu prüfen.

QFD: Das Quality Function Deployment ist ein Verfahren, bei dem die Gestaltung eines Produkts schrittweise aus den Anforderungen abgeleitet wird. Ziel ist es vor allem, Designentscheidungen bewusst zu begründen, um nicht zu viel Aufwand in die Umsetzung weniger wichtiger Anforderungen zu stecken. Oft wir nur der erste Teil des Verfahrens umgesetzt, der sich schön in einer einzigen Darstellung zusammenfassen lässt, dem House of Quality. Ein typisches Beispiel: Wird als Anforderung „Hochverfügbarkeit“ genannt, neigen manche Systemarchitekten reflexhaft zur Entscheidung „Clustering“. Dabei kann es durchaus ausreichend sein, mehrere unabhängige Linien parallel aufzubauen und auf die Komplexität des Clusterings zu verzichten. Entscheiden lässt sich das nur, wenn man die Anforderungen genauer analysiert: Darf wirklich keine Transaktion verloren gehen? Oder ist es nur wichtig, dass immer ein nutzbares System zur Verfügung steht?

Elmar Borgmeier ist Chief Innovation Officer der syngenio AG. Er arbeitet an neuen Lösungen für Online-Finance-Portale, am Modell AspectQ für agiles Qualitätsmanagement und an der Analyse von kognitiven Einflussfaktoren in der Softwarearchitektur.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.