Das Thema Qualität durchzieht heute jedes IT-Projekt und beschäftigt Entwickler, Tester, Projekt-Manager, Anwender und Führungskräfte. Auf die Frage, wie sich Qualität in IT-Projekten etablieren und nachhaltig verankern lässt, haben sich in den letzten Jahren zwei Antworten durchgesetzt, die nicht unterschiedlicher sein könnten: einerseits die Einführung eines ingenieurmäßigen Qualitäts-Managements (QM) und anderseits die Umstellung auf agile Prozesse.
Fazit
Bei klassischem QM ist die explizite Steuerung von Qualität eine eigenständige Aufgabe. Im Gegensatz dazu hat agiles Projekt-Management die Bedeutung des Faktors Mensch wieder in den Vordergrund gestellt. Agiles QM hat das Ziel, beides zu verbinden: QM wird als explizite Aufgabe in die Projektteams hineingetragen und über eine weniger formale "Verpackung" leichter zugänglich gemacht. Erfolgreich ist agiles QM dann, wenn es die Akzeptanz der Projektbeteiligten findet und gleichzeitig Ergebnisse liefert, die über das Projekt hinaus auf der Organisationsebene sichtbar sind. Somit erhält das Management einen Ansatz, die Organisation systematisch zum QM zu erziehen.
Aspekte von Qualität
Qualität besitzt verschiedene Dimensionen, die jeweils mit eigenständigen Maßnahmenbündeln adressiert werden. Deshalb unterscheidet der Ansatz Aspect Q folgende Aspekte:
• Kundenbezogene Qualität: stellt die Sicht des Auftraggebers dar - Qualitätskriterien sind hier Faktoren wie Kosten, Termine oder Investitionssicherheit.
• Anwenderbezogene Qualität: Das sind vor allem funktionale Eigenschaften von Software, deren Spezifikation und Test sowie der Umgang mit Klärungen und Änderungen während des Projekts. Auch der Umgang mit nicht ausgesprochenen Erwartungen und die Benutzerfreundlichkeit der Software gehören dazu.
• Technologiebezogene Qualität: Dies meint die Qualitätsmerkmale des ausführbaren Programms, die zu stark mit der Technik verknüpft sind, als dass sie von den Anwendern allein vorgegeben werden könnten. Hier geht es vor allem um Performance, Stabilität und Sicherheit.
• Innere Qualität: Qualitätsmerkmale, die zunächst nur im Sourcecode selbst erkennbar sind und deshalb auch dort geprüft werden. Dazu gehören Klarheit des Designs, saubere Codestrukturen, Verständlichkeit und Wartbarkeit.
• Nachhaltigkeit: Der Nutzungszeitraum von Software beginnt erst mit dem Abschluss des Entwicklungsprojekts. Deshalb ist es wichtig, von Anfang an den Betrieb der Anwendung und ihre Betreuung im Blick zu haben. Weil Entwickler und Betreiber Software hier unterschiedlich sehen, geht es dabei vor allem um Konfigurierbarkeit, Monitoring, einheitliches Change- und Release-Management, Offenheit der Schnittstellen und Fehlertoleranz.
Hier lesen Sie …
• was Qualitäts-Management (QM) im klassischen Sinn bedeutet;
• welchen Qualitäts-Ansatz agile Softwareprojekte verfolgen;
• wie sich mit Hilfe von Aspekten und Qualitätsmaßnahmen ein agiles QM einführen lässt.
QM wurde eingeführt, um Qualität systematisch zu steuern. Systematik ist hier schon deshalb notwendig, weil unter Qualität jeder etwas anderes versteht: Für Entwickler sind Klarheit des Designs und wartbarer Code wichtig. Die für den Betrieb Verantwortlichen achten vor allem auf Stabilität und Flexibilität. Bei den Anwendern stehen vollständige Umsetzung ihrer Anforderungen und Softwareergonomie im Vordergrund. Projektleiter legen Wert auf die Einhaltung des Projektprozesses, Auftraggeber auf die Budget- und Termintreue.
Die Unternehmenssicht
Angesichts dieser vielfältigen Betrachtungsweisen, die alle ihre Berechtigung haben, richtet sich das klassische QM nach den Gesamtzielen des Unternehmens und leitet daraus die Ziele 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). Hier werden Prozesse und Ergebnisse ganzheitlich betrachtet, also im Hinblick auf die verschiedenen Zielgruppen: Kunden, Mitarbeiter und Gesellschaft.
Qualitätssteigerungen einer Organisation lassen sich nur schrittweise umsetzen. Daher haben sich im Softwarebereich neben den bekannten Konzepten der ISO 9000 ff. 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 Spice-Modell bewertet dagegen den Reifegrad einzelner Prozesse.
Die Vorteile der genannten QM-Verfahren sind: Sie bieten Führungskräften einen Handlungsrahmen, um Qualität systematisch weiterzuentwickeln und den erreichten Stand zu bewerten. Qualität lässt sich somit verwalten und auditieren. Unterhalb der Management-Ebene, bei den Entwicklern und Projekt-Managern, finden die Verfahren jedoch weit weniger Akzeptanz. Ein Grund dafür ist eine zu starke Prozessorientierung: Denn gut kontrollierte Prozesse allein können noch keine Produktqualität sicherstellen. Auch orientiert sich die Prozess-Standardisierung häufig an den größten Szenarien und ist damit für kleinere und mittlere Softwareprojekte überdimensioniert. Hinzu kommt: Für eine externe Auditierbarkeit gilt es oft, Dokumente zu erstellen, was in den Augen des Projektteams nicht selten eine lästige bürokratische Zusatzarbeit ist. Welche Gründe es auch immer geben mag: Mangelnde Akzeptanz hat zur Folge, dass QM nur pro forma umgesetzt wird und sich so die eigentlichen Ziele nicht erreichen lassen.
Agile Verfahren
Ein Gegenentwurf zum klassischen QM sind die agilen Verfahren. Hier liegen die Schwerpunkte auf der Kommunikation beziehungsweise dem Faktor Mensch statt auf Prozessen, auf der Software selbst anstatt auf umfassender Dokumentation, auf aktivem Änderungs-Management statt auf hoher Planbarkeit. Es gilt zu unterscheiden zwischen agiler Softwareentwicklung und agilem Projekt-Management: Agile Softwareentwicklung bezieht sich auf die Gestaltung der eigentlichen Entwicklung. Es gibt unterschiedliche Ausprägungen, die bekannteste ist das Extreme Programming (XP).
Von agilem Projekt-Management spricht man im Zusammenhang mit der Gestaltung des gesamten Projektablaufs. Hier geht es also um die Anpassung von Prozessmustern an die konkreten Erfordernisse des IT-Projekts. Agiles Projekt-Ma- nagement gibt es auch in IT-Projekten ohne einheitliches Entwicklungsteam, also etwa bei der Einführung von Standardsoftware.
Leider finden sich in der internationalen Literatur zur agilen Softwareentwicklung wenig spezifische Aussagen zum Umgang mit Qualität. Viele Autoren setzen eher darauf, dass Qualität von selbst entsteht, wenn erfahrene "Softwerker" gut zusammenarbeiten. Nur wenige Beiträge handeln davon, wie sich QM in die Arbeit der Projektteams integrieren lassen könnte.
Subjektive Deutung
Auch wenn die agilen Verfahren in ihrem Ansatz eine Qualitätsorientierung vorsehen, so fehlt ihnen ein explizites QM. Damit besteht die Gefahr, dass sich der subjektive Qualitätsbegriff der Beteiligten durchsetzt und zum Beispiel ein Softwareentwickler nicht genügend Rücksicht auf die Anforderungen der Anwender nimmt. Auch gibt es bei Qualität nicht nur die Entscheidung für mehr oder weniger, sondern auch für die eine oder andere Art von Qualität. Zum Beispiel ist eine besonders benutzerfreundliche Web-Oberfläche sehr wartungsintensiv. Hinzu kommt: Eine nur innerhalb eines Projekts wirksame Qualitätsorientierung trägt wenig zum Fortschritt der Gesamtorganisation bei. Zu Recht steht daher das Management agilen Verfahren häufig skeptisch gegenüber, auch wenn die konkreten Projekterfolge sehr wohl für die agilen Methoden sprechen.
QM-Steuerung
Aus diesem Grund wurden in jüngster Zeit Ansätze zum agilen Qualitäts-Management entwickelt - also einem expliziten Verfahren zur Steuerung von Qualitätsmaßnahmen, das sich mit den drei Prinzipien der agilen Verfahren verträgt:
1. Agiles QM fügt sich flexibel und angemessen in ein konkretes Projektvorgehen ein.
2. Agiles QM ist ergebnisorientiert und daher technologiezentriert. Es umfasst konkrete technische Maßnahmen zur Sicherung der Software-Qualitätsmerkmale.
3. Agiles QM zeigt Qualität als besondere Leistung und motiviert die Kompetenzträger zur Übernahme von Qualitätsaufgaben.
Keine Formalismen
Damit setzt sich agiles QM bewusst von den rein prozessorientierten Ansätzen des klassischen QM ab. Ziel ist es, mit diesem personen- und technologiezentrierten Ansatz diejenigen Mitarbeiter zu erreichen, die in der Vergangenheit von überbordenden Formalismen abgeschreckt wurden.
Ein von uns als "Aspect Q" bezeichnetes Denkmodell für agiles QM soll wesentliche Elemente aus der aspektorientierten Programmierung auf die Konzeption eines Qualitätsmodells übertragen. Mit Aspect Q werden Qualitätsthemen als zusätzliche Aspekte des Projektvorgehens betrachtet. Diese werden separat vom Projektprozess festgelegt und dann an zu definierenden Stellen in den Projektprozess eingefügt.
Die Klassifikation der Qualitätsthemen in mehrere Aspekte erfolgt so, dass innerhalb eines Aspekts ein möglichst starker Zusammenhang zwischen den Maßnahmen besteht. Keineswegs lassen sich die Aspekte einem einzigen Projektabschnitt zuordnen. Sie werden vielmehr durchgängig in den Ablauf "eingewoben" und bilden damit das "Quality Pattern" des Projektes.
Fünf Qualitätsaspekte
In Aspect Q gibt es fünf Aspekte von Qualität: kunden-, anwender- und technologiebezogene Qualität sowie innere Qualität und Nachhaltigkeit (Details siehe Kasten "Aspekte von Qualität"). Mit der expliziten Unterscheidung dieser Aspekte wird die Komplexität des Qualitätsbegriffs sichtbar und die Diskussion um die jeweilige Priorisierung von Qualitätszielen gefördert. Darauf aufbauend definiert Aspect Q zwei Ebenen von QM-Verfahren: das Verfahren innerhalb eines Projekts und das Verfahren, mit dem eine Organisation projektübergreifende Qualität erlernt.
Workshops planen
Innerhalb eines Projekts findet die Qualitätsplanung in speziellen Workshops statt. Dort werden Maßnahmen und ihre Einsatzzeitpunkte für alle Aspekte festgelegt. Die Maßnahmen können vielfältig sein und auch kreative Ansätze haben, die in den jeweiligen Projekten entstehen: zum Beispiel Pair Usage (Entwickler arbeiten mit Anwendern zusammen), Refactoring Breaks (gezielte Design-Weiterentwicklung zwischen zwei Iterationen), Shortcut-Analysen oder frühzeitige Troubleshooting-Dokumentation. Mit entsprechenden Visualisierungs- und Kreativitätstechniken lässt sich im Rahmen eines solchen Workshops erreichen, dass sich die Beteiligten stärker eingebunden fühlen und sich besser mit den Qualitätszielen identifizieren können. Die Teilnehmer werden dabei jeweils zu Stellvertretern eines Aspektes und stehen für dessen Qualitätsanforderungen.
Alle Maßnahmen werden auf "Maßnahmen-Karten" beschrieben und im Intranet veröffentlicht. Dieser Fundus an vorgefertigten Karten bildet dann nicht nur einen Grundstock für die Workshops anderer Projekte, sondern ist auch die Basis für das "Qualitätslernen" der Organisation. Somit wird QM nicht aus einem formalen Gesamtkonzept heraus in die Projekte getragen, sondern umgekehrt aus den Erfahrungen der Projekte in die Organisation hinein entwickelt.
Die Maßnahmenbeschreibungen im Intranet umfassen Angaben zu den Randbedingungen, unter denen eine bestimmte Maßnahme sinnvoll erscheint, zu den Projekten, die bisher diese Maßnahme getroffen haben, und zu den Erfahrungen damit. Die Beschreibung der Maßnahme "Performance Unit Test", bei der es um die Ausführung automatisierter Tests geht, kann beispielsweise folgendermaßen aussehen: Es wird darauf hingewiesen, dass sich die Ergänzung um eine automatisierte Zeitmessung und somit um eine Performance-Auswertung nur bei den Projekten lohnt, in denen Antwortzeiten auch ohne Lastsituation eine hohe Relevanz haben oder bei denen aufgrund einer sukzessiven Erweiterung der Funktionalität mit schleichenden Performance-Verlusten zu rechnen ist.
Daraus lassen sich direkt Bewertungen zur Akzeptanz (Anzahl der zu nutzenden Projekte), Effektivität (Anzahl der Einsätze, die als Erfolg klassifiziert wurden) und häufig auch zur Effizienz (Anzahl frühzeitig identifizierter Risikopunkte) ableiten. Ebenso sind in einem evolutionären Prozess die erfolgreichsten Maßnahmen identifizierbar oder die Maßnahmen, die bei Vorliegen der notwendigen Randbedingungen die höchste Erfolgsrate aufwiesen. Diese lassen sich dann standardisieren und durch geeignete Hilfsmittel wie Softwarewerkzeuge oder Check-Listen/Dokumenten-Templates unterstützen - ihre Akzeptanz dürfte gesichert sein. (ue)