Stakeholder verfolgen Ziele. Oft leiten sich diese Ziele aus den Unternehmenszielen ab und haben strategischen Charakter. Für Teams, die Software oder Systeme entwickeln, sind diese Ziele meistens zu vage, um in konkrete Aktionen und Lösungen zu münden. Aufgabe des Requirements Engineerings ist es, die Ziele in konkrete, vom Projektteam umsetzbare Anforderungen zu verfeinern, um daraus Features abzuleiten. Der Schlüssel zur Ableitung von Features ist die Frage an die Stakeholder: Was muss das zu entwickelnde System leisten, um das vorgegebene Ziel zu erreichen? Nicht immer fällt es Stakeholdern leicht, darauf eine direkte Antwort zu geben. Umso wichtiger wird das Review – also die Abstimmung und Prüfung – von Features.
Kriterien zur Prüfung von Features
Auch wenn es sich bei Features um Anforderungen auf sehr hohem fachlichen Niveau handelt, sollten sie bereits eine Reihe von Qualitätskriterien erfüllen. Hier ist eine Checkliste, die Sie für die Prüfung der Features verwenden können:
- Hat jedes Feature mindestens eine Quelle? Haben Sie alle interessierten Stakeholder identifiziert?
- Sind die Features vollständig, decken sie also die Ziele der Stakeholder ab und lassen sie sich auf Ziele oder Use Cases zurückverfolgen?
- Sind die Features verständlich und eindeutig formuliert? Lässt die Formulierung Interpretationen zu? Wenn Sie die Regeln zur natursprachlichen Beschreibung von Features befolgt haben, sollte das kaum noch der Fall sein. Damit haben Sie einen großen Schritt in Richtung der Eindeutigkeit gemacht.
- Sind die Features korrekt? Geben sie also richtig wieder, was die Stakeholder wollen?
- Sind die Features widerspruchsfrei, also konsistent?
- Sind die Features aktuell und spiegeln sie nach wie vor die Wünsche der Stakeholder wider?
Diese Frage klären Sie am schnellsten in einem oder mehreren Review-Meetings mit den Stakeholdern. Aber alle Stakeholder zu einem oder sogar mehreren Review-Meetings an einen Tisch zu bekommen, ist in großen und verteilten Organisationen nicht immer möglich. Oder es ist mit so großem Aufwand verbunden, dass Sie dafür weder von den potenziellen Beteiligten noch vom Management ein Okay bekommen. Hier bietet sich eine Alternative an: maschinelle Reviews. Die Vorteile für die Stakeholder liegen auf der Hand: Sie können die Reviews – im Idealfall mit einer browserbasierten Software – durchführen, wann immer sie Zeit dafür finden und wo immer sie Zugang zum Internet haben.
Vorteile von maschinellen Reviews
Sie haben in Ihrem Projekt keine Chance, alle Stakeholder für Reviews an einen Tisch zu holen? Dann können Sie die Reviews der definierten Features mit dem Tool wie beispielsweise objectiF RPM formalisieren. Maschinelle (genauer: maschinell unterstützte) Reviews sind im Kern Workflows, die nach festen Regeln funktionieren. Der gleichartige Ablauf der maschinellen Reviews ist aber nicht ihr einziger Vorteil. Für maschinelle Reviews spricht, dass
- sie keinen administrativen Overhead verursachen: kein Reservieren von Räumen, keine Terminkoordination und – speziell in verteilten Organisationen – keine Reisezeiten,
- die Stakeholder ein Review im Rahmen der definierten Fälligkeit durchführen können, wann immer sie Zeit dafür finden,
- die Reviews durch schriftliche Kommentare der Stakeholder verbindlicher werden als durch mündliche Stellungnahmen im Review-Meeting,
- die Kommentare und damit auch die Reviews nachvollziehbar sind,
- Reviews aus Tool-Sicht Artefakte sind, die sich auswerten lassen. So können Sie sich zum Beispiel die Reviews auflisten lassen, an denen Sie persönlich teilnehmen sollen bzw. teilgenommen haben. Oder Sie erstellen eine Liste aller Anforderungen mit den zugehörigen Reviews und ihren aktuellen Zuständen.
Die nachfolgend dargestellte Technik können Sie übrigens nicht nur auf Features anwenden. Maschinelle Reviews können Sie für folgende Elemente anlegen und durchführen:
- Anforderungen – unabhängig von ihrem Stereotyp
- Use Cases
- Dokumente
- Elementgruppen
Für maschinelle Reviews empfehlen wir drei Rollen zu unterscheiden:
- den Organisator eines Reviews,
- die Reviewer, die die Prüfung der vorgelegten Elemente durchführen,
- den Autor, der den Prüfgegenstand erstellt hat und ggf. nachbessern muss.
Die Organisation von maschinellen Reviews
Als Organisator sind Sie dafür zuständig, Reviews zu erstellen:
- Legen Sie also für jedes zu prüfende Element (mindestens) ein Review an.
- Beschreiben Sie seine Zielsetzung.
- Legen Sie einen Fälligkeitstermin fest.
- Bestimmen Sie die beteiligten Reviewer und überführen das Review in den Zustand “bereit”.
Ein kleiner Hinweis: Wir gehen davon aus, dass die zu prüfenden Elemente vollständig beschrieben sind und sich deshalb im Zustand “definiert” befinden. Man kann aber auch die Haltung haben, dass ein Feature erst dann vollständig definiert ist, wenn seine Beschreibung abgeschlossen ist und die Reviews zur Prüfung der Beschreibung komplett definiert sind. Wenn Sie diese Haltung teilen, dann belassen Sie ein Feature solange im Zustand “in Definition”, bis Sie alle notwendigen Reviews erstellt haben. Erst dann lösen Sie auf dem Feature das Ereignis “Definition fertig” aus. Das Feature geht dann in “definiert” über und alle geplanten Reviews ändern automatisch ihren Zustand von “geplant” in “bereit”.
Die Durchführung von maschinellen Reviews
Aus Sicht eines Reviewers stellen sich folgende Fragen:
- Was bedeutet es, ein maschinelles Review durchzuführen?
- Wie kann man Review-Ergebnisse nachvollziehbar festhalten?
- Wie sieht der Workflow eines Reviews grundsätzlich aus?
- Wann kann ich mit der Prüfung beginnen?
Gehen wir bei der Beantwortung der Reihe nach vor:
Was bedeutet es, ein maschinelles Review durchzuführen? Ein maschinelles Review besteht darin, dass jeder Projektmitarbeiter, der einem Review als Reviewer zugeordnet ist, die Beschreibung des Prüfgegenstands kritisch würdigt. Orientierung bietet ihm dabei die Zielsetzung, die der Organisator beim Anlegen des Reviews formuliert hat.
Wie kann man Review-Ergebnisse nachvollziehbar festhalten? Erkenntnisse, Fragen, positive oder kritische Anmerkungen, also die Ergebnisse seiner Prüfung fasst der Reviewer in einem Review-Kommentar zusammen.
Wie sieht der Workflow eines Reviews grundsätzlich aus? Sobald ein Review in den Zustand “bereit” gelangt, muss der Reviewer einen Review-Kommentar abgeben. Beginnt er mit seiner Tätigkeit, befindet sich das Review im Zustand “in Durchführung”. Nachdem der Reviewer seinen Kommentar vollständig eingegeben hat, muss er seine Erkenntnisse noch auf den Punkt bringen. Das bedeutet, er muss den vorgelegten Prüfgegenstand “akzeptieren” oder “ablehnen”. Ein Review wird nur dann erfolgreich abgeschlossen und in den Zustand “zugestimmt” überführt, wenn alle Reviewer den Prüfgegenstand “akzeptieren”. Ein einziger ablehnender Kommentar reicht also aus, um das gesamte Review in den Zustand “abgelehnt” zu versetzen.
Sobald ein Review in den Zustand “abgelehnt” gelangt, heißt es für den Autor des Prüfgegenstands: nachbessern. Denn mit dem Zustandswechsel des Reviews in “abgelehnt” geht auch der Prüfgegenstand vom Zustand “definiert” automatisch wieder zurück in den Zustand “in Definition”. Sobald der Autor den Prüfgegenstand nachgebessert hat und der Prüfgegenstand wieder “definiert” ist, kann das Review erneut beginnen. Denkbar sind auch Möglichkeiten des Nachbesserns von Prüfgegenständen oder das Überspringen von Reviews, also das neutrale Verhalten eines Reviewers, durch das ein Review insgesamt in den Zustand “zugestimmt” gelangt, sobald alle anderen Review-Kommentare positiv ausfallen.
Insgesamt könnte ein Zustandsdiagramm zur Durchführung von maschinell unterstützten Reviews wie folgt aussehen:
Ein Zustandsdiagramm zur Durchführung von ReviewsAuch wenn Zustandsdiagramme relativ leicht zu verstehen sind, kann alleine die Menge an Zuständen, Ereignissen, Bedingungen und Benachrichtigungen den Leser überfordern. Umso wichtiger ist daher die Unterstützung von maschinellen Reviews durch eine Software, mit der Sie einerseits Ihre gewünschten Reviews definieren und sie anschließend auch konkret durchführen können.
Was wäre der nächste Schritt nach dem Review von Features? Nun, wenn die Qualität der Features durch Reviews gesichert ist, geht es als nächstes darum zu entscheiden, welche Bedeutung sie für die Stakeholder haben. Doch das ist ein Thema für einen anderen Blogbeitrag.
Fazit
Natürlich schließen sich Review-Meetings und maschinelle Reviews gegenseitig nicht aus. Empfehlenswert ist es, Abstimmungen und Prüfungen auf Entscheider-Ebene „von Angesicht zu Angesicht“ in Review-Meetings vorzunehmen. Für die weit häufigeren detaillierten fachlichen Prüfungen eignen sich maschinelle Reviews wegen des geringeren Rüstaufwands besser. Auch die zeitliche Flexibilität, das Wegfallen von Terminabsprachen und Reisezeiten, und die leichte Nachvollziehbarkeit von Ergebnissen spricht für maschinelle Reviews. Aber sowohl bei maschinellen Reviews als auch bei Review-Meetings gilt: Änderungen kosten Zeit. Planen Sie deshalb für jedes Review auch Zeit ein, um Nachbesserungen vornehmen zu können. Und planen Sie zusätzlich etwas Zeit ein, wenn Sie im Falle von Review-Meetings Zustände und Zustandswechsel „mit der Hand“ dokumentieren müssen. Bei maschinellen Reviews wird dieser Zustand automatisch erreicht, wenn alle Reviewer der Feature-Beschreibung zustimmen.