Friday, September 30, 2011

Agile RE Blog 1: Was ist Requirements Engineering

Ich fange mit auf dem Allgemeinplatz an, als Einstieg, sozusagen in der Komfortzone. Dieser Allgemeinplatz ist die Frage, was ist Requirements Engineering eigentlich?!

Ich mir sicher bin, dass ich bei 100 Experten dazu 200 verschiedene Antworten bekomme. Das nutze ich, die meine einfache Antwort im Kontext des Themas zu geben. Diese lautet: Requirements Engineering ist ein Hilfsmittel, wenn auch ein sehr wichtiges Hilfsmittel. Requirements Engineering ist eines der Hilfsmittel, um ETWAS zu erschaffen. Dieses ETWAS ist in der kommerziellen Welt typisch ein Produkt (wie ein Handy, Auto oder eine käufliche Software), ein Service (wie Bankkonto, Telephonie, Internetanschluss oder Cloud Service), eine Dienstleistung (Hausverwaltung, Consulting oder Kundendienst) oder eine Mischung aus all dem.










Abbildung 1: Das Produkt steht im Mittelpunkt, Requirements Engineering ist ein Hilfsmittel

Das Produkt - ich sage im Weiteren vereinfachend für alles dies Optionen - ist der Gegenstand unseres eigentlichen Bestrebens. Damit verdienen wir unser Geld. Also ist es besser als nur ein Produkt zu erschaffen, dieses mit möglichst niedrigen Total Cost of Ownership (TCO) zu erschaffen.

Requirements Engineering ist also ein HILFSMITTEL, um ein vom Markt verlangtes Produkt zu erschaffen und dies in einer Art und Weise, dass die Ideenfindung dazu, die Herstellung und der Verkauf, eben die TCO, billiger sind als der Erlös.

Dieses "in einer Art und Weise" ist nun genau der springende Punkt. Gute Produkte (oder Services oder Dienstleistungen) sind diejenigen, die mit den richtigen Eigenschaften zum richtigen Zeitpunkt auf dem Markt kommen. Nehmen wir an, wir haben bereits ein Produkt - oder auch zwei oder mehrere Produkte zum Verkaufen in unserer Organisation, die wir am Markt anbieten.

Nun ist klar, dass „Morgen“ die Produkte anders aussehen müssen, wir müssen sie umbauen oder erweitern, damit sie attraktiv bleiben. Wir müssen eine neue Version der Produkte erstellen. Diese Erkenntnis ist trivial. Das typische Gefäß, um Produkte zu erstellen oder zu erweitern sind Projekte. Ein Projekt ist laut Definition eine temporäre Organisationsform, um einen bestehenden Zustand, in dem Fall den Zustand des Produkts (ein Projekt kann auch andere Dinge treiben als Produkte) in einen neuen Zustand zu überführen. Wir haben somit ein oder mehrere Projekte, um von einem Produkt eine neue Version zu bauen oder auch ein komplett neues Produkt zu erschaffen. Irgendwo rund um oder in das Produkt und Projekt stecken wir auch das Hilfsmittel Requirements Engineering hinein, die notwendig ist, um die neue Version des Produkts zu erschaffen.
Ich möchte an der Stelle wiederholen: ein „GUTES PRODUKT“ bringt die richtigen Eigenschaften zum richtigen Zeitpunkt an dem Markt. Eine erfolgreiche Organisation kümmert sich aktiv um diese beiden sehr abstrakten Eigenschaften „RICHTIGE EIGENSCHAFTEN“ und „RICHIGER ZEITPUNKT“. Wichtigen Eckpfeiler dafür ganz am Anfang Innovationsprozesse mit der Identifikation der Produkte, dann die Definition unseres Produktportfolios und die darauf abgestimmte Release Planung. Mit der Release Planung entstehen die Projektportfolios als ausführende (operative) Ebene unterhalb der Produktportfolios. Aus Sicht der Organisation ist die Definition des Produktportfolios die strategische Ebene, das Management und Releasemanagement des Produktportfolios die taktische Umsetzung der Strategie und die Projekte die operative Ausführung von Strategie und Taktik(Regieanweisung: Grafik erweitern).

Die strategische Ebene lasse ich im Weiteren einfach unberücksichtigt. Die taktische Ebene, also das Management des Produktportfolios mit Releaseplanung der Produkte und die damit verbundenen Aktivitäten, das alles ist wichtig jedoch wichtig für die weiteren Überlöegungen. Darin steckt Requirements Engineering und die Chance zur Agilität. Denn Requirements Engineering beschäftigt sich mit den Eigenschaften, die sich bereits in den Produkten befinden und auch mit den Randbedingungen unter denen sie erstellt und eingesetzt werden, wie zum Beispiel regulatorischen Auflagen. Requirements Engineering arbeitet mit dem Innovationsprozess in Form neuer Ideen, welche als neue Anforderungen Eingang finden für kommende Produktversionen. Requirements Engineering arbeitet mit der Marketingabteilung, mit Kunden und / oder mit dem Kundendienst. Requirements Engineering betrachtet die Randbedingungen der Technik und der Erstellungsprozesses, um wirtschaftliche Aspekte zu beachten und den TCO zu optimieren.

Wir haben nun das Bild, wo Requirements Engineering im Kontext der Überlegungen zu finden ist. Wir bewegen uns also noch in der Komfortzone und haben den Einstieg in den nächsten Schritt erarbeitet.


















Abbildung 2: Das Ökosystem der Produktentwicklung mit strategischer, taktischer und operativer Ebene

Wenn wir nun das Ökosystem der Produktentwicklung (siehe Abbildung 2) betrachten, dann fallen zusammen fassend zwei Dinge ins Auge:
  1. Es existiert eine Ebene oberhalb des Projekts, die Ebene des Produktportfolios (auch, wenn sich darin nur ein einziges Produkt befinden sollte). Auf dieser Ebene müssen taktische Entscheidungen getroffen werden, wie sich die Produkte weiter entwickeln sollen, oder welche neuen Produkte benötigt werden. Die Release Roadmap mit resultierendem Projektportfolio ist die taktische Umsetzung des strategischen Produktmanagements. Das Bewirtschaften (Management) eines Produktportfolios ist ein kontinuierlicher Prozess, welcher Marktbedürfnisse, Innovationen, den Zustand meiner Organisation und kommerzielle Randbedingungen gegeneinander abgleicht. All das benötigt ein gutes Maß an Requirements Engineering, welches dafür sorgt, dass unsere Organisation das RICHTIGE Produkt zum RICHTIGEN Zeitpunkt am Markt verkaufen kann. (ANMERKUNG: An der Stelle kann gestritten werden, ob es sich um Requirements Engineering handelt, oder ob das ein Teil der Business Analyse oder ein beliebiger anderer Begriff ist. Wenn wir uns die benötigten Fähigkeiten und in die ausgeführten Tätigkeiten der Personen ansehen, welche hier aktiv werden, so sehen wir, dass diese zu einem hohen Grad deckungsgleich mit Requirements Engineering sind. Ich nenne es daher einfach Requirements Engineering).
  2. Es existiert die operative Umsetzungsebene der Produktreleasemap, die Projekte. Diese Projektebene, eben das Projektportfolio spielt zu definierten Synchronisationspunkten mit der Prozessebene des Produktmanagements eng zusammen. Ein wesentlicher Aspekt fällt hierbei sofort auf: Die taktische Ebene und die operative Ebene verwenden Informationen und Wissen, dass in beiden Ebenen entstanden sein kann und transparent zwischen den Ebenen wandern können muss. Ich denke zumindest auf dieser Ebene sind wir uns einig, dass es sich um Requirements Engineering handelt.
Zusammenfassend stellen wir fest, dass RE in der taktischen Ebene und in der operativen Ebene steckt. Beide Ebenen müssen eng miteinander zusammenarbeiten. Requirements Engineering ist ein wichtiges Bindeglied in der Kommunikation zwischen den beiden Ebenen, eine Schlüsseldisziplin, also eines der wirklich wichtigen Hilfsmittel. Erfolg oder Misserfolg der Organisation hängt ganz stark damit zusammen, ob das Requirements Engineering zwischen diesen beiden Ebenen effizient gestaltet und gemäß der Strategie der Organisation gelebt wird.

Im nächsten Schritt möchte ich das Ökosystems des Projekts unter die Lupe nehmen. Ganz erstaunliche Dinge lassen sich in dem Ökosystem erkennen, die zur Agilität führen und nicht die Wurzel im Agile Manifesto besitzen oder in den Bücher von Mary Poppendieck (die jedoch ihre Bedeutung daher nicht verlieren).

Sunday, September 25, 2011

Agile Requirements Engineering - Eine Blog Serie

Sorry, this blog series about agile requireemnts engineering is in German. Reason is the source - a German conference, where I was asked to talk about this topic. So if somebody is interested in a translation, please let me know and I will care for.

In meiner Rolle als Board Member des IREB International Requirements Engineering Boards e.V. erhalte ich immer wieder Anfragen, wie es denn mit Agilität in Zusammenhang mit Requirements Engineering aussieht. Anfang habe einfachgeantwortet, dass es für mich hier keinen Unterschied zu einem agilen Vorgehen an sich gibt.

Die Anfragen regten mich jedoch an, mich einmal intensiver mit dieser Frage zu beschäftigen und zu hinterfragen, ob es denn eine spezielle Sicht aus dem Blickwinkel des Requirements Engineering auf agiles Arbeiten gibt. Die Antwort war ja – wenn der Kontext weiter gezogen wird als alleine das agile Arbeiten in einem Projekt. Agilität alleine im Projektkontext ist meiner Meinung nach nämlich eine klare Einschränkung.

Das Ziel einer beliebigen Organisation kann ja nicht sein effizient Projekte durchzuziehen. Projekte sind zeitlich begrenzte Vorhaben, um Organisationsziele zu erreichen. Das kann eine Innovation sein, um die Zukunft zu sichern, ein Produkt zu erstellen, um damit Geld zu verdienen oder einfach ein Vorhaben um die Organisation zu optimieren.

Das war der Start meiner Überlegungen, welche Verantwortung dem Requirements Engineering in einer Organisation übertragen ist und welchen Einfluss ein agiles Arbeiten dann auf die Gestaltung dieser Verantwortung ausübt. Aus den Überlegungen wurde ein Vortrag, den ich testweise an einer Konferenz gehalten habe, um ein Feedback zu den Überlegungen zu erhalten. Das dieses Feedback motivierend war und ein vorhandenen Interesse gezeigt hat, setze ich eine Blogreihe zu den Überlegungen auf