Donnerstag, 10. Oktober 2013

Der Ideenraum

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.


Eine Software entsteht aus einer Vision oder aus einer Notwendigkeit heraus. Sie kann auch schon jahrelang betrieben worden sein und nach Veränderung schreien. Ob wir nun ein neues Produkt bauen, ein altes Produkt umgestalten oder erweitern, es sind immer Ideen notwendig, dies zu tun. Eine Idee ist zuerst einmal ein unstrukturierter Einfall in Bezug auf das zu schaffende System. In der Kette der Prozesse befinden wir uns zwischen Vision und Systemkontextanalyse. Es macht keinen Sinn, Ideen abzublocken, nur weil sie unstrukturiert, beziehungslos und oft ungenau formuliert sind. Das Sammeln von Ideen ist die Vorordnung der Analyse. Alle einfach dahin gesagten Ideen sind von jedermann willkommen, der Stakeholder des zukünftigen Systems ist.


Das Sammeln von Ideen ermöglichen wir, indem ein Raum geschaffen wird, in dem diese Ideen erfasst und priorisiert werden. Dazu kann jeder diesen Ideenraum betreten und eine Idee hinterlassen. Diese Idee besitzt mehrere Attribute, die auszufüllen sind. Des Weiteren kann man alle Ideen, die man vorfindet, priorisieren. Dazu verfügt ein Stakeholder über eine Priorisierungsstufe. In der Höhe seiner Priorisierungsstufe kann er + bzw. - Punkte verteilen.

Ein kleines Beispiel zur Verdeutlichung. Ein zu entwickelndes System besitzt genau drei Stakeholder: den Kunden, den Product Owner und den Entwickler. Der Kunde verfügt über vier mögliche Punkte, der Product Owner über zwei und der Entwickler besitzt einen Punkt. Der Kunde betritt den Ideenraum und hinterlässt die folgende Idee:

Name Alarmauslösung
Idee Das System soll bei allen wichtigen Ereignissen einen Alarm auslösen können.
Autor Kunde X


Diese Idee bekommt vom Kunden drei Punkte. Er hätte vier verteilen können, aber so wichtig erschien ihm das Ganze denn nun doch nicht. Nachdem die Idee vom Kunden im Ideenraum hinterlassen wurde, können der Product Owner und der Entwickler ebenfalls Punkte verteilen. Der Product Owner vergibt seine zwei möglichen Punkte und der Entwickler setzt einen Minuspunkt. Mehr Minuspunkte kann der Entwickler in diesem Fall auch nicht verteilen. Am Ende besitzt diese Idee vier Punkte.

Alle Ideen aus dem Ideenraum können in einer Ideenliste dargestellt werden Die Ideenliste unseres Beispiels könnte wie folgt aussehen.

Name Autor Punkte
Alarmauslösung Kunde X 4
Blinder Alarm Entwickler Y 1


Eine höhere Differenzierung des Ideenraums wäre dadurch zu erreichen, indem man verschiedene Autorenkategorien (Kunde, Hersteller) unterscheidet. Die zu vergebenden Punkte könnten dann auch gesondert für diese Autorenkategorien erfasst werden.



Bis hier hin erinnert das Ganze an die mehr oder weniger unstrukturierten Emails, die vom Kunden kommen, wenn er mal Zeit hat und etwas Neues braucht. Die einzige, wenn auch wesentliche Verbesserung ist der Ideenraum und die Ideenpriorisierung. Im Folgenden wollen wir nun überlegen, wie man die Ideengeber dazu motivieren kann, mehr Struktur in die Ideen einfließen zu lassen.

Eine erste Idee ist es, den Ideengeber in die Richtung einer User Story zu lenken. In einer User Story wünscht sich ein Autor in einer Rolle eine Funktion, die einen Geschäftswert haben sollte. Dazu werden Hinweise und Randbedingungen erfasst und mögliche Akzeptanztests. Nun könnte man die Ideenschablone mit einigen dieser Attribute erweitern. Damit der Autor motiviert wird, diese Attribute auszufüllen, könnte sein zu vergebendes Punktereservoir entsprechend vergrößert werden. Damit könnte er die Idee höher priorisieren.

Bisher befinden sich im Ideenraum eine Menge priorisierter Ideen. Nun könnte der Ideenraum in kleinere Räume unterteilt werden. Diese Arbeit sollte man dem Requirements Engineer in Zusammenarbeit mit dem Product Owner überlassen. Eine Empfehlung könnte ein jeder, der zum Ideenraum Zugang hat, jedoch abgeben. Diese Unterräume nennen wir Themen. Ein Stakeholder kann also einen Themenvorschlag machen oder einem Themenvorschlag zustimmen.

In unserem Beispiel hätte die Idee z.B. den Themenvorschlag "Alarmmodul" vom Kunden bekommen. Der Entwickler würde diesem Vorschlag zustimmen. Der Product Owner erstellt den Themenvorschlag "Auswertungsmodul". Damit hätte der Themenvorschlag "Auswertungsmodul" 2 Stimmen und der Vorschlag "Auswertungsmodul" eine. Als Thema sollte ein funktionales Modul gewählt werden.

Im nächsten Post möchte ich beschreiben, wie Ideen geordnet werden und wie daraus eine Roadmap werden kann.

vorheriger Post dieses Themas     folgender Post dieses Themas


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

1 Kommentar:

  1. Kann es sein, dass sich hier ein Fehler eingeschlichen hat?
    Damit hätte der Themenvorschlag "Auswertungsmodul" 2 Stimmen und der Vorschlag "Auswertungsmodul" eine

    AntwortenLöschen