Anforderungen auf einzelne Projekte verteilen

Aus organisatorischer Sicht kann es wünschenswert sein, Anforderungen aus unterschiedlichen Quellen zu sammeln und in einem zentralen Pool zu erfassen, um sie dann gezielt auf einzelne Projekte zu verteilen. Ein typisches Beispiel ist das Sammeln und Umsetzen von Kundenanforderungen in der Produktentwicklung. An diesem Beispiel zeige ich Ihnen heute, wie Sie als Administrator in-STEP BLUE für projektübergreifendes Anforderungsmanagement einrichten.

Ein typischer Fall aus der Praxis

Stellen Sie sich dazu folgende Situation vor: Alle Kundenanforderungen werden bei Ihnen in einem eigenen Projekt, dem Kundenanforderungsprojekt, gesammelt. Dort werden sie von den Kunden selbst und/oder von Ihnen als Hersteller abgelegt. Die Anforderungen werden dann vom Produktmanager bewertet, priorisiert und in die Produktentwicklung eingeplant. Die Entwicklung selbst erfolgt – sagen wir – nach Scrum. Das heißt, aus den Anforderungen im Kundenanforderungsprojekt müssen Stories in den Entwicklungsprojekten werden.

Wie richten Sie als Administrator in-STEP BLUE nun so ein, dass der Produktmanager zukünftig Anforderungen aus dem Kundenanforderungsprojekt mit wenigen Klicks als Stories in ein Entwicklungsprojekt übernehmen kann?

Wenn Sie mit in-STEP BLUE arbeiten, kennen Sie die Möglichkeit, innerhalb von Projekten Produkte von anderen Produkten abzuleiten. Genau diese Funktionalität können Sie hier nutzen – nur auf projektübergreifender Ebene.

Das müssen Sie als Administrator einmalig vorbereiten

Die Stories im Entwicklungsprojekt sollen später natürlich noch „wissen“, aus welcher Kundenanforderung sie hervorgegangen sind. Das ist z.B. notwendig, um eine Rückmeldung an diese Kundenanforderung zu senden oder zu dieser navigieren zu können. Als Erstes ergänzen Sie deshalb die Kategorie für Stories um eine Eigenschaft vom Typ Produkt, in der auf die Kundenanforderung verwiesen werden kann.

Das sieht dann etwa so aus:

Eigenschaft ergänzen

Als Nächstes benötigen Sie die Komponente, die die Funktionalität, Produkte von anderen abzuleiten, bereitstellt. Und zwar brauchen Sie diese in dem Entwicklungsprojekt, also dem „Ziel“. Als Administratorkönnen Sie unter Projekt/Komponenten prüfen, ob die benötigte Komponente bereits im Projekt registriert ist. Zu finden wäre sie dann unter CommandServer mit dem Namen … für Produkte (CoreProcess, systemweit).

Komponente prüfen

Ist diese Komponente im Entwicklungsprojekt noch nicht vorhanden, fügen Sie sie dort hinzu: Dazu klicken Sie auf Registrieren und wählen aus dem in-STEP BLUE Installationsverzeichnis die CoreProcExtension.dll aus. Es werden Ihnen nun verschiedene Komponenten zur Registrierung angeboten. Sie benötigen wie gesagt den CommandServer … für Produkte (CoreProcess, systemweit). Markieren Sie das zugehörige Kontrollkästchen.

Komponente registrieren

Ein Klick auf OK und Sie finden ihn in der Liste der CommandServer des Projekts. Ist der Commandserver registriert, haben Sie alle Voraussetzungen geschaffen, um den Befehl für die Übernahme von Anforderungen als Story in das Entwicklungsprojekt zu definieren.

Befehl hinzufügen

Wählen Sie nun den CommandServer … für Produkte (CoreProcess, systemweit) in der Liste aus und klicken Sie auf Konfigurieren. Sie erhalten einen Dialog mit allen bisher konfigurierten Befehlen.

Befehl hinzufügen

Mit  Neuer Befehl können Sie hier eigene Befehle definieren. Wählen Sie Produkt ableiten im Untermenü und los geht’s:

Produkt ableiten

Der Konfigurationsdialog gibt Ihnen die Möglichkeit, den Befehl bis ins Kleinste zu detaillieren. Unter Beschriftung geben Sie den Namen an, den der Befehl haben soll – in unserem Beispiel  also Kundenanforderung übernehmen. Mit genau dieser Beschriftung erscheint der Befehl dann später im Kontextmenü einer Anforderung. Der Name ist der interne Name des Befehls und ergibt sich automatisch aus der Beschriftung.

Bei den Einstellungen zum Quellprodukt stellen Sie alles Notwendige zu dem Produkt ein, das als Grundlage für das Ableiten dient, in diesem Fall also zu den Anforderungen aus dem Kundenanforderungsprojekt. Sie wählen also als Produkttyp Anforderung aus. Eine referenzierende Eigenschaft geben Sie in diesem Beispiel nicht an, weil Sie dafür ja in der Story eine Eigenschaft definiert haben. Auch ein zu empfangendes Ereignis brauchen Sie im Moment nicht. Hier wäre denkbar, der Kundenanforderung durch ein entsprechendes Ereignis zu signalisieren, dass sie in das Entwicklungsprojekt übernommen wurde und auf diese Weise deren Zustand zu ändern.

Bei den Einstellungen zum abgeleiteten Produkt wählen Sie als Produkttyp Story. Hier geben Sie nun die referenzierende Eigenschaft an. In unserem Beispiel ist das die Eigenschaft Kundenanforderung, die Sie zu Beginn angelegt haben. Auch hier geben Sie im Moment kein Ereignis mit.

Schließlich müssen Sie noch definieren, in welchem Zustand sich eine Anforderung befinden muss, damit der Befehl sichtbar ist. Wählen Sie unter Sichtbar im Zustand die Zustände aus, in denen Sie den Befehl benötigen. Entscheiden Sie sich hier z.B. für den Zustand definiert.

Als letzten wichtigen Punkt wählen Sie aus, welche Eigenschaften der Anforderung in die Story übernommen werden sollen. Behalten Sie die Standardeinstellung bei, werden alle Eigenschaften mit gleichem Namen und Typ aus der Anforderung in die Story übernommen.

Nach Bestätigung mit OK finden Sie den neuen Befehl in der Liste der verfügbaren Befehle.

Verfügbare Befehle

Eins ist jetzt noch zu beachten: Sie müssen die Rollen auswählen, für die der Befehl angeboten wird. Nur Mitarbeiter mit der geforderten Rolle können diesen Befehl dann ausführen. Auf diese Weise stellen Sie sicher, dass nicht jeder Mitarbeiter neue Stories aus Anforderungen ableiten kann.

Den Befehl haben Sie konfiguriert, doch wo finden Sie ihn? Natürlich auf den Anforderungen – nur sind die ja in einem eigenen Projekt. Was Sie brauchen, ist eine systemweite Sicht. Die definieren Sie sich jetzt.

Systemweite Sicht anlegen

Legen Sie eine neue systemweite Sicht vom Typ Produkte oder Produkte (Oracle) an.

Sicht anlegen

Diese Sicht wird gefiltert nach dem Produkttypen Anforderung und dem Zustand definiert. Auf anderen Produkten wird der neue Befehl ja auch gar nicht angezeigt.

Eigenschaften der Sicht

Als Datenquelle wählen Sie das Kundenanforderungsprojekt, aus dem die Anforderungen stammen, aus denen Stories abgeleitet werden sollen.

Sicht anlegen mit entsprechenden Informationen

Und bei den Menüpunkten geben Sie den CommandServer an, in dem Sie den Befehl konfiguriert haben.

CommandServer auswählen

Haben Sie sich die Spaltenkonfiguration der Sicht auf der Registerkarte Allgemein genau angeschaut? Dann denken Sie vielleicht, dass in der Sicht nur sehr wenige Informationen angezeigt werden. Insbesondere fehlen Ihnen spezielle, in den Anforderungen definierten Eigenschaften wie z.B. dieAnforderungsnummer. Genau die will der Produktmanager bestimmt sehen? Kein Problem. Dazu benötigen Sie die Informationen aus dem Kundenanforderungsprojekt. Sie werden dort in der Kategorie REQUIREMENT gespeichert – nur die gibt es in dem Scrum-Projekt nicht. Mit einem kleinen Trick können Sie diese Kategorie in das Entwicklungsprojekt übernehmen. Dann können Sie auch diese Eigenschaften als Spalten in Ihrer Sicht auswählen.

Hier können Sie nachlesen, wie Sie ein Prozessteil in ein anderes Projekt übernehmen können. Wenn Sie diesem Trick anwenden, könnte die Sicht  beispielsweise so aussehen:

Liste mit Kundenanforderungen

Sie haben in-Step jetzt so konfiguriert, dass der Produktmanager es von nun an beim Verteilen der Anforderungen ganz leicht hat:

So übernimmt der Produktmanager mit wenigen Klicks zentrale Anforderungen als Stories in ein Scrum-Projekt

Dazu öffnet er die von Ihnen definierte Sicht der Kundenanforderungen, wie in obiger Abbildung. Die dort angezeigten Anforderungen kann er jetzt mit dem neuen Befehl Kundenanforderung übernehmen als Stories in das Entwicklungsprojekt übernehmen.  Führt er das Kommando aus, erhält er einen Dialog, in dem er Namen und Zielverzeichnis der jeweiligen Story bei Bedarf anpassen kann.

Kundenanforderungen übernehmen

Mit dem Klick auf OK wird die Story angelegt.

Die übrigen drei Anforderungen will er eins zu eins in das Entwicklungsprojekt übertragen. Dazu kann er alle drei gleichzeitig auswählen.

Multi-Selekt bei Kundenanforderungen

Zu den Anforderungen gibt es jetzt vier Stories im Product Backlog des Scrum-Projekts. Damit kann der Product Owner genauso verfahren, wie er das üblicherweise in seinem Entwicklungsprojekt tut.

Das Product Backlog

Mit diesem Plus: Über Gehe zu im Kontextmenü kann man zwischen Kundenanforderung und Entwicklungsstory navigieren und so jederzeit den aktuellen Entwicklungsstand zu einer Kundenanforderung abfragen oder die Kundenanforderung zu einer Entwicklungsstory ansehen.

Probieren Sie es aus. Und bei Fragen helfen wir Ihnen sehr gerne.