Alles rund um die Qualitätssicherung von Lastenheften
Die Ergebnisse, die wir als Geistesleister erstellen, existieren meist im virtuellen Raum. D.h., wir können sie nicht anfassen oder ausprobieren. Wir können zwar heutzutage mittels moderner Methoden, gewisse Aspekte automatisch prüfen lassen. Allerdings sind Reviews, an denen Menschen beteiligt sind, für unsere Arbeit enorm wirkungsvoll.
Warum das so ist und wie sie effektiv eingesetzt werden können, beschreibe ich im Artikel auf meiner Webseite näher.
In diesem Beitrag möchte ich Prozess-Reviews beschreiben. Dieser Review-Typ bzw. das Audit ist für das gesamte Entwicklungsprojekt entscheidend.
Das Prozess- oder Reifegrad-Review weist die Entwicklungsreife eines Projekts nach. Dabei geht es nicht mehr um den Inhalt der Ergebnisse, sondern um den Nachweis der zu erbringenden Arbeitsergebnisse, also zum Beispiel Spezifikationen, Planungsdokumente, Testdurchführungen etc. Als Basis dienen hier meist Prozessreifegradmodelle wie z.B. SPICE oder CMI. Weiterlesen
Für ein gelungenes Lastenheft sind Reviews meiner Erfahrung nach unerlässlich. Ich habe bereits über die allgemeinen Vorteile von Reviews und die spezielle Form der Peer Reviews berichtet. Kommen wir nun zu den Freigabe-Reviews.
Im Gegensatz zu Peer Reviews ist dieser Typ Geheimwaffe deutlich formaler. Ein Freigabe-Review wird oft in einer Gruppe von Entwicklungsingenieuren durchgeführt. Das bedeutet, sie müssen geplant, vor- und nachbereitet werden. Welche Schritte genau das beinhaltet, möchte ich im Folgenden erläutern. Weiterlesen
Ich habe bereits in anderen Beiträgen über Reviews und ihre Funktionen berichtet: Zwischenergebnisse und Prozesse absichern, Feedback erhalten, Ergebnisse freigeben – ich bezeichne Reviews nicht umsonst als Geheimwaffe.
Im Folgenden möchte ich ein bisschen tiefer in das Thema Peer Reviews einsteigen. Der Begriff kommt eigentlich aus dem wissenschaftlichen Umfeld und geht bis ins 17. Jahrhundert zurück. Das Konzept fokussiert seitdem die Begutachtung von Ergebnissen durch einen gleichwertigen Kollegen – und lässt sich bei Lastenheften natürlich ebenso gut anwenden. Weiterlesen
Wenn ich Projekte begleite, kommt früher oder später folgende Frage auf: „Woran erkenne ich, ob ich mit meinen Requirements fertig bin?“
Es ist immer schwierig, geistige Leistung – und Requirements sind die Ergebnisse geistiger Arbeit – zu bewerten, und gerade bei den eigenen Arbeiten tun wir uns oft schwer.
Die meisten unter uns haben diese Erfahrungen mit selbstgeschriebenen Texten gemacht: Irgendwann sehen wir unsere Fehler einfach nicht mehr. Und leider schleichen sich aus diesem Grund auch schnell Fehler in die Requirements-Dokumente ein.
Damit das nicht passiert, nutze ich in der Praxis drei einfache Checks, die mir enorm weiterhelfen:
Wenn ich Requirements beschreibe, ist es meine Aufgabe als Systemingenieur, bei jedem Requirement auch für die Testebene eine Empfehlung abzugeben. Fällt es mir schwer, nur eine Ebene anzugeben, und habe ich stattdessen mehrere Möglichkeiten, die ich auswählen kann, ist das Requirement sehr wahrscheinlich nicht gut beschrieben.
Als Konsequenz ändere ich also das Requirement, formuliere es detaillierter, teile es auf, schreibe es um – bis ich sicher nur eine Testebene empfehlen kann. Das hilft gleichzeitig auch dem Testkollegen, denn so kann er seine Tests frühzeitig entwerfen und die Abdeckung nachweisen.
Im zweiten Schritt nutze ich den Filter meines Requirements-Management-Werkzeuges und schaue, ob es in meinem Dokument irgendwelche Requirements gibt, die keinen Link zu übergeordneten Anforderungen besitzen. Wenn mir der Filter Einträge dieser Art anzeigt, ziehe ich diese Links nach.
Anschließend prüfe ich mit einem weiteren Filter, ob es übergeordnete Anforderungen gibt, die keinen Link zu meinem Dokument haben. Wenn mir der Filter Einträge dieser Art anzeigt, prüfe ich, ob ich noch etwas in meinem Dokument vergessen habe, und erstelle entsprechende Anforderungen auf meiner Ebene (und verlinke diese natürlich!).
Ich gebe meine Arbeitsergebnisse regelmäßig anderen Kollegen mit der Bitte, mir mit einem Peer-Review ein kurzes Feedback zu geben. Anschließend arbeite ich die Ergebnisse ein und lade zu einem formalen Review.
In dieser Review-Session übernehme ich alle Auffälligkeiten in ein Review-Protokoll und gewichte gemeinsam mit den Teilnehmern die Schwere der Auffälligkeiten. Wenn ich keine „Major“-Punkte und nicht mehr als zehn „Minor“-Punkte habe, ist die Reife der Requirements nach dem aktuellen Wissensstand gut genug. Ansonsten muss ich die Auffälligkeiten entsprechend korrigieren, bis ich unter meinem Grenzwert liege.
Wo genau Eure Grenzen sind, müsst Ihr in Euren Projekten selbst ausloten – die Requirements zu beschreiben, ist für mich eine sehr gute und ausreichende Hilfe.
Mit dieser Vorgehensweise in drei Schritten habe ich die Möglichkeit, schnell zu erkennen, ob ich mit meinen Ergebnissen wirklich eine hohe Qualität erreiche.
Um diese für ein Lastenheft sicherzustellen und eine klare Aussage dazu treffen zu können, sind also die folgenden Aspekte hilfreich: