Dulden Sie keine Abstriche in Sachen Qualität
Ein klares Bekenntnis von Agile PM in Richtung Qualität.
von Klemens Loschy
Dulden Sie keine Abstriche in Sachen Qualität
Diesem vierten (von insgesamt acht Prinzipien von AgilePM) ist als einziges ein eigenes Kapitel im Agile Project Management Handbook gewidmet, auch das ist ein klares Bekenntnis von AgilePM in Richtung Qualität.
An sich unterscheidet sich die Herangehensweise von AgilePM zu diesem Thema nicht von anderen agilen Prozessen grundlegend: sowohl die Qualität der Lösung (Lösungsqualität) als auch des angewandten Prozesses (Prozessqualität) muss stimmen. Dazu gibt es eine Reihe von bewährten Praktiken und Tipps die bei der Wahrung bzw. Steigerung der Qualität helfen. Die Einbeziehung von Qualität in diese Methode und die Ehrlichkeit im Umgang damit macht AgilePM in dieser Hinsicht aber herausragend.
Lösungsqualität
Ganz im Sinne von „Das Richtige richtig tun“ hängt die Lösungsqualität von zwei Faktoren ab: Umfang der Lösung und technische Qualität.
Umfang der Lösung
Die passenden Features zur richtigen Zeit, darauf kommt es an. Gesetze treten zu gewissen Zeitpunkten in Kraft, dementsprechend müssen etwaige Änderungen der Software bis dahin fertig werden. Weihnachten ist genau am 24. Dezember, erst danach mit dem Verkauf von Christbäumen zu beginnen wird kein Erfolg sein (und sei es noch so ein hübscher Baum).
AgilePM adressiert diese Herausforderung damit, dass Anforderungen mit Hilfe von MoSCoW in drei (bzw. vier) Kategorien eingeteilt werden:
- MUST: Muss Kriterien, ohne die die Lösung nicht verwendet werden kann
- SHOULD: Wichtige Kriterien, aber nicht mehr erfolgsentscheidend
- COULD: Wünschenswert, aber nicht mehr wichtig
- WONT: Sind (jetzt) nicht Teil der Lösung
Um sicherzustellen, dass die MUSTs mit höchst möglicher Wahrscheinlichkeit (die Praxis hat uns gelehrt, dass Pläne niemals 100% halten) auch umgesetzt werden, wird jede Development-Timebox zu max. 60% mit MUSTs verplant, die restlichen 40% werden in etwa zu gleichen Teilen auf SHOULDs und COULDs aufgeteilt. Innerhalb jeder Development-Timebox werden zuerst die MUSTs, und erst danach SHOULDs und COULDs umgesetzt. Die Praxis zeigt, dass mit diesem planerischen Ansatz die MUSTs und ein Großteil der SHOULDs zur geplanten Zeit in der geplanten Qualität umgesetzt werden.
Technische Qualität der Lösung
Als Tester fühlt man sich in diesem Bereich gut aufgehoben, ist die Absicherung der Qualität doch unser täglicher Job. AgilePM legt den Grundstein für die technische Qualität schon in der sehr frühen Feasibility Projektphase: das zu erreichende Qualitätsniveau (auf funktionaler und natürlich nicht funktionaler Ebene) wird abgestimmt und fixiert und damit im weiteren Projektverlauf zu keiner flexiblen Variable.
Nicht unbedingt neu, aber allzu oft nicht hinreichend berücksichtigt ist die Tatsache der Instandhaltbarkeit der Lösung oder Teile davon: es ist nicht immer notwendig dieselben Qualitätskriterien für alle Teile der Lösung anzuwenden. AgilePM spricht von drei typischen Gruppen: „Instandhaltbarkeit ist obligatorisch“, „Erst liefern, dann überarbeiten“, „Kurzfristig und taktisch“. Für jede dieser Gruppen ist Qualität anders zu definieren – eine taktische Lösung kann zu meist mit weit weniger technischer Qualität geliefert werden als eine langfristige Lösung. Das gilt es als Tester unbedingt zu wissen und zu berücksichtigen, denn damit können Testintensität und -tiefe besser geplant werden.
Prozessqualität
AgilePM bietet mit der Definition des Prozesses, der Rollen und der Produkte eine solide Basis für Projekte. Darüber hinaus wird durch Templates und Beispiele der theoretische Nutzen weiter praktisch aufgewertet. Dabei bleibt AgilePM aber praxisnahe und ehrlich zu sich selbst: nicht jedes Projekt bedingt den vollen Umfang von AgilePM. Im Sinne von: Lassen Sie einzelne Produkte weg, wenn das Projekt und die Lösung dadurch nicht besser werden. Aber treffen Sie diese Entscheidung ganz bewusst!
In AgilePM sind eine Reihe von Quality Gates vorgesehen, die sowohl die Qualität der Lösung formell und informell immer wieder beleuchten, als auch die Verbesserung des Prozesses an sich forcieren.
AgilePM spricht dabei auch eine Tatsache an, die oft nicht oder zu wenig berücksichtigt wird: das gesamte Unternehmen, jeder einzelne, ist dafür verantwortlich den Prozess zu leben und kontinuierlich zu verbessern. Jede Ausnahme davon ist ein potentielles Risiko für das gesamte Projekt. Die erste Frage im Project Approach Questionaire (eine Checkliste, die anhand 17 Fragen Optionen und Risiken beurteilt) lautet dementsprechend auch: „Alle Mitglieder des Projekts verstehen und akzeptieren den DSDM-Ansatz.“ (Anmerkung: Der „DSDM Ansatz“ ist die Foundation des AgilePM.)
Als Software Tester hat es mich bei AgilePM gefreut zu sehen und zu hören, dass Qualität ein elementarer Bestandteil dieser Methode ist, der auch nicht als selbstverständlich angesehen wird und im Laufe des Projektes immer wieder im Auge behaltet werden muss, gerade auch in stressigen Projektzeiten. Denn: Dulden Sie keine Abstriche in Sachen Qualität!
