Sonntag, 20. Oktober 2013

Themenobjekte ordnen Ideen in eine Roadmap

Gute Software benötigt gute fachliche Anforderungen.

Artikelübersicht
1. Teil Ein Objekt-Aufgaben-Modell für das Requirements Engineering.
2. Teil Der Ideenraum.
3. Teil Themenobjekte ordnen Ideen in eine Roadmap.
4. Teil Themen müssen einer Systemkontextanalyse unterzogen werden.
5. Teil Ein hierarchisches System von Kontextobjekten.
6. Teil Die Geschichten der Benutzer - User Stories erstellen.
7. Teil Die Analyse des Problemraums führt zum Zielmodell.
8. Teil Wie User Stories Use Cases gebären.
9. Teil Szenarien setzen sich zu Use Cases zusammen.
10. Teil Drei Perspektiven öffnen uns den Weg zu den Anforderungen.
11. Teil Noch mehr Zusammenhänge durch die CRUD-Matrix.
12. Teil Die Vielfalt der Szenarien.
13. Teil Qualitätsanforderungen bilden einen Übergang zur Softwarearchitektur.
14. Teil Ohne Abnahmekriterien läuft nichts.
15. Teil Startschuss zur testgetriebenen Entwicklung.


Im zweiten Teil der Requirements-Engineering-Reihe wurde eine Möglichkeit aufgezeigt, noch unstrukturierte Ideen abzugreifen und ggf. schon eine gewisse Struktur und Priorität zu ermitteln. Diese Ideen im Ideenraum warten nun auf eine sinnvolle Weiterverarbeitung. Im Ideenraum können sich mit der Zeit eine Unmenge von Ideen ansammeln. Wir benötigen eine Methode, um unseren Blick auf die wichtigen Ideen zu lenken. Dabei vertrauen wir auf die Mitarbeit der Erzeuger und Priorisierer der Ideen. Mit Hilfe des Priorisierungssystems ziehen wir einen Betrachtungshorizont in das System ein. Alle Ideen, die eine Mindestpriorität erreichen, werden in den nachfolgenden Prozessen betrachtet. Ideen, die diese Priorität nicht besitzen, werden (noch) nicht in die Weiterverarbeitung mit einbezogen.


Die reine Idee ist kein Bestandteil des Aufgaben-Objekt-Modells. Sie ist ein mehr oder weniger spontan erfasster Text. Sie ist der Geburtshelfer für den ersten Objekttyp, das Themenobjekt. Beim Anlegen und bewerten der Ideen hatten die Stakeholder bereits die Möglichkeit, Empfehlungen für Themen zu erteilen. Die Erzeugung von Themenobjekten ist jedoch die Arbeit eines verantwortlichen Gremiums. Falls das benutzte Vorgehensmodell Scrum ist, sollten diesem Gremium in jedem Fall der Product Owner und der Requirements Engineer angehören. Außerdem empfehle ich, dass mindestens je ein Vertreter des Entwicklerteams und des Kunden in diesem Gremium sitzen.

Zuerst sollten wir jedoch klären, wozu Themenobjekte dienen. Ihr Ziel ist es, Ideen gleichartiger Funktionalität zusammenzufassen. Damit können wir bereits Funktionsgruppen zu einem sehr frühen Zeitpunkt ausfindig machen. Die Arbeit der Mitglieder des Gremiums besteht nun darin, auf der Grundlage der Themenvorschläge der Stakeholder geeignete Vorschläge für Themenobjekte zu erzeugen. Dazu wird bereits ein Themenobjekt angelegt. Ein anderes Mitglied des Gremiums kann dieselbe Idee diesem Themenobjekt zuordnen oder ein neues Themenobjekt anlegen. Falls eine Idee mehreren Themenobjekten zugeordnet ist, entsteht ein Konflikt. Alle Ideen, die über dem Betrachtungshorizont liegen, müssen innerhalb einer festgelegten Frist von den Mitgliedern des Gremiums zu Themenobjekten zugeordnet werden.

In periodischen Meetings werden die Konflikte per Diskussion gelöst. Nach dem Meeting gibt es durch das Gremium beschlossene Themenobjekte und eindeutig zugeordnete Ideen. Während dieses Prozesses werden Themenobjekte erstellt (create) und auch wieder gelöscht (delete). Themenobjekte, auf die sich das Gremium geeinigt hat, werden durch ein entsprechendes Flag gekennzeichnet. Ein solches Themenobjekt kann dann durch das Gremium priorisiert werden.

Trotzdem können weiterhin Ideen zu diesen Themenobjekten zugeordnet werden. Bei erneut auftretenden Konflikten verliert das Themenobjekt sein Flag und zeigt so an, das erneut ein Konflikt gelöst werden muss.

Mit der Zeit nehmen die Themenobjekte immer mehr Gestalt an. Die Arbeit des Product Owners ist es nun, diese Themenobjekte Umsetzungszeiträumen zuzuordnen. Eine bestimmte Frist vor Erreichen dieses Umsetzungszeitraumes wird das Themenobjekt für weitere Zuordnungsarbeiten gesperrt und es müssen endgültig alle Konflikte für dieses Themenobjekt gelöst werden. Das kann mit Hilfe eines weiteren Flags kenntlich gemacht werden. Durch das Zuordnen der Themenobjekte in einen Zeitplan entsteht auf ganz natürliche Art und Weise eine Roadmap. Diese Roadmap kann für den Kunden transparent sein. Man muss erkennen können, welche Themenobjekte für Zuordnungsarbeiten offen sind und welche bereits finalisiert sind.


Finalisierte Themenobjekte werden durch das Gremium priorisiert. Jedes Mitglied des Gremiums besitzt einen Vorrat an Punkten, die er bestimmten Ideen anteilig zuordnen kann. Wenn unser Gremium z.B. aus vier Mitgliedern besteht, so könnte das wie folgt aussehen:

Summe Kunde Product Owner Requirements Engineer Teammitglied
Punktevorrat 60 25 20 10 5
Themenobjet A 15 10 5 - -
Themenobjet B 21 5 10 5 1
Themenobjet C 5 3 2 - -
Themenobjet D 11 5 2 2 2
Themenobjet E 8 2 1 3 2


Natürlich sind andere Priorisierungsmethoden vorstellbar. Die (finalisierten) Themenobjekte sind nun so geordnet, dass die wichtigsten Themenobjekte oben stehen. Nun können die Mitglieder des Gremiums in einer gemeinsamen Sitzung darüber entscheiden, ob das Themenobjekt beauftragt oder zurückgestellt werden soll. In der Roadmap muss der Zustand der Themenobjekte erkennbar sein. Für beauftragte Themenobjekte wird eine Aufgabe erzeugt. Diese Aufgabe beinhaltet eine durchzuführende Kontextanalyse und wird normalerweise dem Requirements Engineer übertragen. Mit dem Inhalt der Kontextanalyse in diesem Prozess befassen wir uns im nächsten Post dieser Reihe. Über die Grundlagen der Kontextanalyse können Sie sich auch in meiner kleinen Artikelreihe über die Systemkontextanalyse informieren.

Im Kapitel Praktische Beispiele werde ich ein Unterkapitel "Beispiel zum System der Anforderungsermittlung" einrichten. Dort werde ich demnächst ein praktisches Beispiel für den Ideenraum, die Bildung von Themenobjekten und die Roadmap publizieren. Damit hoffe ich meine Ideen noch deutlicher und nachvollziehbarer zu machen.

vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen