Q-Gates in SAP Cloud ALM: Ein kleiner Schlüssel zur Sicherung von Qualität und Projekterfolg

Titelbild: «Q-Gates in SAP Cloud ALM: Der Schlüssel zur Sicherung von Qualität und Projekterfolg» generiert mit ChatGPT

In den vorherigen Blogposts haben wir erklärt, wie man innerhalb des Fit/Standard-Workshops vom Prozessumfang zum Anforderungsbacklog gelangt, d.h. konkret, wie man anhand von Prozessdiskussionen die passenden Anforderungen erstellt. Zudem haben wir dann aus den Anforderungen sogenannte User Storys  erstellt, die wiederum die zu erledigende Arbeit eines Projektes in kleinere, nachvollziehbare und umsetzbare Aufgaben gliedern.

Ein wichtiger Bestandteil der Projektmanagementstrategie ist die Implementierung von Qualitätskontrollen, den sogenannten Q-Gates, die an bestimmten Punkten im Projektplan platziert sind. Diese Q-Gates fungieren als kritische Überprüfungspunkte, an denen die Qualität und Fortschritte des Projekts bewertet werden, um sicherzustellen, dass alle Systeme und Prozesse bereit für den nächsten Schritt sind. Wie man diese in SAP Cloud ALM nutzt und was unsere Erfahrungen sind, erfahrt ihr in dem folgenden Artikel. Zuerst allerdings, wird auf den Unterschied von Projektaufgaben und User Storys eingegangen.

Projektaufgaben als Aufgaben, die im Projekt halt zu erledigen sind

In SAP Cloud ALM wird zwischen den uns bereits bekannten User Storys und Projektaufgaben unterschieden: Eine User Storys beschreibt ein Benutzerbedürfnis, das erfüllt werden muss, um einen geschäftlichen Nutzen zu erzielen. Sie kann, muss aber nicht mit einer Anforderung verbunden sein.

Wohingegen Projektaufgaben, Aufgaben in einem Projekt sind, die es ebenfalls zu erledigen gilt, aber in der Regel nicht von funktionaler Natur sind. Eine User Story ist z.B. ein Customizing in einem System. Diese User Story ist einem Feature verbunden, in dem z.B. der Transportauftrag mit dem Customizing verknüpft ist, d.h. es ist etwas funktionales. Eine Projektaufgabe ist z.B., dass man noch die Fit/Standard-Workshops nachbereiten oder ein Training für die Tester organisieren muss, d.h. eine Projektaufgabe ist nicht mit einem Feature verbunden und stellt etwas nicht funktionales , aber etwas organisatorisches dar.

Abbildung 1: Einordnung des Q-Gates in den Gesamtkontext von SAP Cloud ALM (eigene Darstellung)

Q-Gates als Checkliste innerhalb von Projektaufgaben

Ein nützliches Werkzeug zur Verwaltung dieser Qualitätskontrollen ist die Q-Gate Checklist Funktion, die in SAP Cloud ALM implementiert ist. Obwohl diese Funktion auf den ersten Blick klein erscheinen mag, spielt sie eine entscheidende Rolle in der Strukturierung und Überwachung des Projektfortschritts. Durch die Einbindung dieser Checklisten in die Projektaufgaben wird eine transparente und messbare Basis geschaffen, um die Einhaltung der festgelegten Kriterien genau zu überprüfen. Dies stellt sicher, dass die vorab vom Projektteam definierten Bedingungen erfüllt sind, bevor das Projekt in die nächste Phase übergeht. Die Klarheit und Präzision, die durch die Q-Gate-Checklisten in die Projektmanagementprozesse gebracht wird, kann die Qualität und Konsistenz des gesamten Projektes erheblich verbessern.

Tracking der Ein- und Ausstiegskriterien für unsere Testphasen

Ein konkretes Beispiel aus unserer Praxis zeigt, die Bedeutung dieser Werkzeuge im Testmanagement. Wir haben die Q-Gate Checklist speziell genutzt, um das Tracking der Ein- und Ausstiegskriterien während der verschiedenen Testphasen zu überwachen. Diese Überwachung hat es uns ermöglicht, dass jede Testphase nur dann abgeschlossen und zur nächsten übergegangen wird, wenn alle spezifizierten “Checklist items” erfüllt waren. Ob dies immer zu einer erhöhten Qualität und Zuverlässigkeit der Tests geführt hat, sei dahingestellt. Wozu es aber beigetragen hat, ist eine klare und abgestimmte Erwartungshaltung transparent darzustellen. D.h. jeder im Projektteam hat bereits Wochen im Voraus gewusst, was uns für den Einstieg und den Ausstieg aus den Testphasen besonders wichtig ist.

Abbildung 2: Beispiel für ein Q-Gate mit Checkliste für einen Functional Integration Test

Natürlich: Die starren Kriterien der Q-Gates erfordern gelegentlich Flexibilität Nicht immer können alle vorgegebenen Bedingungen vollständig eingehalten werden. Diese Herausforderungen haben jedoch innerhalb der Projektteams zu wertvollen Diskussionen geführt. Anstatt den Projektfortschritt zu behindern, haben die Diskussionen rund um die Q-Gates dazu beigetragen, konstruktive Lösungen zu entwickeln. Diese machten es möglich, potenzielle Probleme frühzeitig zu adressieren und zu lösen.

Diese dynamische Anpassung und Problemlösung hat die Funktion der Q-Gates über ihre ursprüngliche Rolle als blosse Kontrollpunkte hinaus erweitert, indem sie die Teammitglieder dazu anregten, aktiv an der Verbesserung des Projekts mitzuwirken. Genau dazu, kann man nämlich dann Folgeaktivitäten aus diesen Diskussionen direkt über die Funktion “Folgeaufgabe erstellen” im System anlegen und dem entsprechenden Verantwortlichen zuweisen.

Wie bei der User Story und deren Unteraufgaben, ist auch der Checklist-Erfüllungsgrad der “Checklist Items” direkt in der Kopfzeile des Quality Gates ersichtlich.

Abbildung 3: Kopf eines Q-Gates inklusive Darstellung des Erfüllungsgrads

Take aways

Wie so oft, sind es die kleinen Dinge im Leben, die es ausmachen. So auch die Funktion der Quality Gates in SAP Cloud ALM. Richtig eingesetzt, garantieren diese zwar noch nicht den Projekterfolg, aber durch deren Sichtbarkeit und regelmässige Überprüfung erzeugen diese sehr viel Transparenz und helfen, die Erwartungshaltung allen Projektmitarbeitenden sichtbar aufzuzeigen. Für noch mehr Erfahrungen, rund um Quality Gates, Ein- und Ausstiegskritieren im Testing und SAP ALM im Allgemeinen, freuen wir uns über eure Nachricht.


Stefan Thomann

Stefan Thomann ist SAP Technology Architect and ALM Consultant. Seine Spezialthemen liegen im Requirements-to-Deploy Prozess (Focused Build, Process Management, Test Management) sowie dem Reporting (z.B. mit Focused Insights) zwischen Prozess und Technik. Stefan ist zugleich der Gründer von blueworks und Geschäftsführer der blueworks AG und hat Wirtschaftsinformatik studiert.

blueworks Logo

Certified
Business Transformation
Professionals.


© blueworksgroup 2024. Alle Rechte Vorbehalten.

blue.works® und alm360® sind eingetragene Marken in der Europäischen Union und in der Schweiz.
SAP ist eine eingetragene Marke der SAP SE.