Gegensätzlichkeit als Chance

Qualitätsmanagement und Agilität – was beide voneinander lernen können

Elmar Borgmeier

Ein gepflegtes Feindbild ist ja auch was Feines. Für viele Softwareentwickler ist das ingenieurmäßige Qualitätsmanagement ein beliebtes Feindbild. Und Qualitätsmanager umgekehrt können sich mit agiler Softwareentwicklung oft nur schwer anfreunden. Nicht weil das Ziel strittig wäre: bessere Software wünschen sich alle. Die Wege dahin könnten aber unterschiedlicher nicht sein. Dabei lohnt sich für beide ein Blick über den Zaun: Mit der richtigen Auswahl kann jeder vom anderen lernen und damit ganz konkret dem Ziel näher kommen.

Die Softwareentwicklung ist reich an leidenschaftlichen Diskussionen über die richtigen Methoden, Architekturen und Tools. Kaum ein Thema ist jedoch so erstaunlich wie die Diskussion um das Thema „Qualität“ – denn die prominentesten Ansätze sind hier gleichzeitig die größten Gegensätze: ingenieurmäßiges Qualitätsmanagement und agile Softwareentwicklung. Das agile Manifest, in dem die Prinzipien der agilen Softwareentwicklung plakativ formuliert sind, wurde meist als Gegenentwurf zum klassischen Projektmanagement verstanden. Viel mehr jedoch richtet es sich gegen die Werte und Mittel des ingenieurmäßigen Qualitätsmanagements: Das agile Manifest legt den Schwerpunkt auf Kommunikation statt auf Prozesse, auf die Software selbst anstatt auf umfassende Dokumentation, auf aktives Änderungsmanagement statt auf hohe Planbarkeit.

Zwei Denkschulen stehen sich unversöhnlich gegenüber und begegnen sich gegenseitig mit Ignoranz. Dabei liegt gerade in der Gegensätzlichkeit die Chance: Die Schwächen des einen Ansatzes lassen sich durch eine gezielte Dosis des jeweils anderen Verfahrens abmildern – wer die Ignoranz überwindet und sich mit den anderen beschäftigt, findet in jedem Fall praktisch verwertbare Lösungen für bessere Software. Beide Ansätze werden im Folgenden kurz vorgestellt und durch ihre Kernmerkmale charakterisiert. Anschließend werden konkrete Bestandteile aufgezeigt, die in den anderen Ansatz übernommen werden können.

Qualitätsmanagement

Qualitätsmanagement (QM) wurde eingeführt, um Qualität systematisch zu steuern. Der systematische Ansatz ist schon deshalb notwendig, weil unter Qualität unterschiedliche Dinge verstanden werden, die alle ihre Berechtigung haben: Entwickler achten auf Klarheit des Designs und wartbaren Code, die Verantwortlichen für den Betrieb achten auf Stabilität und Änderbarkeit, Anwender auf vollständige Umsetzung ihrer Anforderungen und Softwareergonomie, Projektleiter auf die Einhaltung des Projektprozesses und Auftraggeber auf Budget- und Termintreue.

Um sich innerhalb dieser vielfältigen Ziele auszurichten, geht das klassische Qualitätsmanagement von den Gesamtzielen des Unternehmens aus und leitet daraus die Zielsetzungen für Softwareprojekte ab. Dieser Ansatz wird insbesondere beim Total Quality Management (TQM) verfolgt. Eine Konkretisierung von TQM ist das Modell der European Foundation for Quality Management (EFQM), das in einem Gesamtbild Prozesse und Ergebnisse im Sinne der verschiedenen Zielgruppen wie Kunden, Mitarbeiter und Gesellschaft betrachtet. Besonders der ganzheitliche Ansatz überzeugt daran. Qualitätssteigerungen einer Organisation können nur schrittweise umgesetzt werden. Daher haben sich im Softwarebereich neben den bekannten Konzepten der ISO 9 000ff. vor allem so genannte Reifegradmodelle etabliert, die eine stufenweise Verbesserung vorsehen. Beim CMMI-Modell der Carnegie-Mellon University wird dabei der Reifegrad einer Organisation insgesamt betrachtet, das europäische Gegenstück SPICE bewertet den Reifegrad einzelner Prozesse.

Die Vorteile der genannten Verfahren zum Qualitätsmanagement liegen vor allem darin, dass sie den Führungskräften einer Organisation einen Handlungsrahmen bieten, innerhalb dessen Qualität systematisch weiterentwickelt und der erreichte Stand bewertet werden kann. Qualität kann gemanagt und auditiert werden – und da Compliance stetig an Bedeutung gewinnt, gilt auch für Software: Sie muss nicht nur korrekt funktionieren, diese Korrektheit muss auch extern nachprüfbar sein. Unterhalb der Managementebene, bei den Entwicklern und Projektmanagern, finden die Verfahren jedoch weit weniger Akzeptanz. Die Hauptkritikpunkte sind:

  • Klassische Verfahren zum Qualitätsmanagement sind stark prozessorientiert. Auch sehr gut kontrollierte Prozesse können bei Entwicklungstätigkeiten allein aber noch nicht die Produktqualität sicherstellen.
  • Prozessstandardisierung orientiert sich häufig an den größten und anspruchsvollsten Szenarien und ist damit dann überdimensioniert für kleinere und mittlere Softwareprojekte.
  • Um eine externe Auditierbarkeit zu gewährleisten, wird häufig die Erstellung von Dokumenten vorgesehen, die das eigentliche Projektteam für sich als wenig hilfreich und als bürokratische Zusatzarbeit betrachtet.

Mangelnde Akzeptanz führt dann regelmäßig zu einer Pro-Forma-Umsetzung des Qualitätsmanagements, mit der die eigentlichen Ziele nicht mehr erreicht werden können. Letztlich wirken die Maßnahmen sogar kontraproduktiv und beschädigen das Image des Qualitätsmanagements bei den technisch orientierten Beteiligten erheblich. Gerade die Entwicklung negativer Einstellungen zur Organisation von Qualität ist besorgniserregend, und wenn sie sich einmal eingeschliffen hat, ist sie schwierig zu korrigieren.

Geschrieben von
Elmar Borgmeier
Kommentare

Schreibe einen Kommentar

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