Mittwoch, 30. Oktober 2013

Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.

Beispiel zum System der Anforderungsermittlung

Artikelübersicht
1. Teil Ideen, Themenobjekte und die Roadmap im praktischen Beispiel.
2. Teil Praktisches Beispiel zur Kontextuntersuchung.
3. Teil Praktisches Beispiel zu User Stories.
4. Teil Drei Basismodelle guter Software im praktischen Beispiel.
5. Teil Das Bauen von Use Cases mit Hilfe von User Stories im praktischen Beispiel.
6. Teil Die praktische Umsetzung verschiedener Perspektiven bei der Suche nach Anforderungen.


In diesem Post möchte ich die theoretischen Ausführungen der Artikel zum Ideenraum und zu den Themenobjekten in einem praktischen Beispiel verdeutlichen. Dazu benötigen wir eine Vision eines umzusetzenden Projektes. Ich wähle ein Programm zur Erfassung von Stakeholdern und ihren Beziehungen. Dazu habe ich bereits eine kleine Artikelreihe geschrieben, was für die Vorstellung des zu entwickelnden Programms sicherlich hilfreich ist.

Trotzdem möchte ich hier noch einmal kurz beschreiben, worum es in diesem Programm gehen soll. Während der Kontextanalyse werden unter anderem Anforderungsquellen ermittelt. Eine der Wichtigsten, wenn nicht die Wichtigste, sind die Stakeholder. Unser Programm soll diese Stakeholder mit den wichtigsten Attributen erfassen, deren Beziehungen untereinander abbilden, den Einfluss auf das Projekt kenzeichnen und sie ggf. zu Gruppen zusammenfassen können. Wer eine genauere Vorstellung entwickeln will sollte die folgenden Artikel lesen:

Stellen wir uns jedoch vor, am Anfang ist es nur eine relativ unklare Vision. Der Visionär hat die Idee der Erfassung von Stakeholdern und deren wichtigsten Beziehungen. Welche das genau sind, ist zu diesem Zeitpunkt noch nicht klar. Mit einem relativ kleinen Kreis beginnt der Visionär Ideen zu sammeln. Er kennt einen Requirements Engineer, der in diesem Fall auch gleich Fachwissender ist, mit dem zusammen er die Ideensammlung beginnt. Der Visionär ist gleichzeitig Product Owner des Projekts und richtet einen Ideenraum ein. Beide Ideengeber tragen nun spontane Ideen ein, wann immer sie Ihnen in den Kopf kommen. Über die Zeit ergibt sich eine kleine Liste:
  • (1) Stakeholder sollen grafisch angebildet werden.
  • (2) Die Projektbetroffenheit der Stakeholder soll größenmäßig dargestellt werden.
  • (3) Die Akzeptanz gegenüber dem Projekt soll durch Farben dargestellt werden.
  • (4) Ein Stakeholder kann Promotor des Projektes sein.
  • (5) Ein Stakeholder kann Unterstützer des Projektes sein.
  • (6) Ein Stakeholder kann Unentschlossen in Bezug auf das Projekt sein.
  • (7) Ein Stakeholder kann Gegner des Projektes sein.
  • (8) Ein Stakeholder benötigt einen Titel.
  • (9) Ein Stakeholder benötigt einen Namen.
  • ...

Diese Liste an relativ unstrukturierten Ideen ist einen geraumen Zeitraum angefertigt worden. Auch in Zukunft werden weiterhin Ideen im Ideenraum gesammelt. Zu keinem Zeitpunkt des Projektes wird dieser Raum geschlossen. Mit der Zeit werden mehr und mehr Personen in das Projekt involviert und demzufolge auch Ideengeber. Jeder Ideengeber bekommt eine Punktezahl, die er teilweise oder ganz, positiv oder negativ an die Ideen vergeben kann. In unserem Fall kann der Product Owner 5 Punkte vergeben und der Requirements Engineer auch 5 Punkte, weil der der Fachmann für das Vorhaben ist.

Die Idee (1) bekommt von Beiden eine +5 und die Idee (8) erhält vom Product Owner eine +3 und vom Requirements Engineer eine -1. Dami erhält die Idee (1) eine +10 und die Idee (8) eine +2. Dadurch steht das grafische Abbilden eines Stakeholders weit über dessen Titelerfassung. Später hinzukommende Ideengeber und ihre Punktzahlen können dieses Kräfteverhältnis im Nachhinein ändern.

Das die Idee (8) so schlecht abgeschnitten hat ist für den Product Owner ein Ärgernis. Er hat nun die Möglichkeit Zusatzpunkte zu vergeben, wenn er die Idee strukturierter ablegt. In unserem Beispiel ist das möglich, wenn der Geschäftswert einer Idee mit angegeben wird. Dann kann derjenige, der den Geschäftswert beschrieben hat, 2 Zusatzpunkte verteilen. In unserem Fall gibt der Product Owner an:
  • (8) Ein Stakeholder benötigt einen Titel.
    • Geschäftswert: In Anschreiben wird der Titel des Stakeholders benötigt.

Damit kann der Product Owner die Punktzahl für die Idee (8) auf +4 erhöhen. Außerdem hat das den Effekt, dass andere Ideengeber ihre Punkzahl noch einmal überdenken, weil ihnen der Sinn wesentlich klarer erscheint. Der Requirements Engineer ändert seine Punkzahl auf +1 und erhöht damit die Gesamtpunktzahl auf +6. Die Idee (8) ist in der Priorität an eine weit höhere Stelle gerückt.

Desweiteren können durch die Ideengeber Themenvorschläge gemacht werden. Der Requirements Engineer ordnet den Ideen (3) bis (7) den Themenvorschlag Projektakzeptanz zu. In diesem Fall sind sich Product Owner und Requirements Engineer einig und der Product Owner schließt sich diesem Vorschlag an. Für die Idee (3) sähe das dann so aus:
  • (3) Die Akzeptanz gegenüber dem Projekt soll durch Farben dargestellt werden.
    • Themenvorschlag: Projektakzeptanz (2x)


Inzwischen ist einige Zeit vergangen und die Zahl der Ideengeber ist auf ein Duzend Personen angewachsen. Es wird Zeit Ordnung in das Chaos der Ideen zu bringen. Der Product Owner, der Requirements Engineer und ein Referenzkunde, als Vertreter der späteren Nutzer, bilden auf Initiative des Product Owners ein Gremium. In diesem Kreis wird über die Ideen entschieden. Anhand der Themenvorschläge können die Mitglieder des Gremiums nun Themenobjekte bilden. Der Product Owner legt das Themenobjekt Projektakzeptanz an. Diesem Themenobjekt werden die Ideen (3) bis (7) zugeordnet. Weitere Themenobjekte sind Stakeholderbetroffenheit, Stakeholderbeziehungen, abstrakte Stakeholder und Gruppen. Im Fall der abstrakten Stakeholder ordnet der Produkt Owner alle Ideen zu, die sich auf Personas und extreme Charaktere beziehen. Der Requirements Engineer sieht hier durchaus kein einheitliches Themobjekt. Er unterteilt in die Themenobjekte Personas und extreme Charaktere. Danach verteilt er die gleichen Ideen, die der Product Owner seinem Themenobjekt zugeordnet hat, auf beide Themenobjekte. Dadurch ist ein Konflikt entstanden. In einem Meeting des Gemiums, welches periodisch stattfindet, werden diese Konflikte gelöst. Eine hitzige, aber sachliche Diskussion, führt am Ende zu den Themenobjekten des Requirements Engineer.

Der Product Owner ist dafür verantwortlich den Themenobjekten Umsetzungszeiten zuzuordnen. In unserem Fall könnte das wie folgt aussehen. Zu Beginn des Umsetzungszeitraums werden die Themenobjekte für die Aufnahme von Ideen geschlossen und alle Konflikte müssen gelöst sein.


Die finalisierten Themenobjekt werden durch das Gremium priorisiert. Dazu besitzt der Referenzkunde ein Punktevorrat von 10 Punkten, der Product Owner besitzt auch 10 Punkte und der Requirements Engineer 5 Punkte. In der obigen Zeichnung ist erkennbar, dass alle 25 Punkte vergeben wurden. Themobjekte in einem Umsetzungszeitraum sind nun priorisiert. Sehr niedrig priorisierte Themenobjekte können für die Bearbeitung auch zurückgestellt werden. Darüber wird auch in einem Meeting des Gremiums entschieden. Dort werden die Themenobjekte beauftragt oder zurückgestellt. Zurückgestellte Themenobjekte können zu einem späteren Zeitpunkt beauftragt werden. Für die beauftragten Themeobjekte erzeugt der Product Owner nun Aufgaben für den Requirements Engineer. Der hat für die Themenobjekte eine Kontextanalyse durchzuführen. Doch damit weiter im nächsten Artikel.

folgender Post dieses Themas


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

Keine Kommentare:

Kommentar veröffentlichen