Bevor wir ins Thema dieser Lektion einsteigen, möchte ich den Begriff des Unternehmensbereichs in dieser Kursreihe definieren:

Ein Unternehmensbereich (Englisch: Business Unit) bezeichnet nicht eine Abteilung wie z.B. den Personalbereich, den Fertigungsbereich, Logistikbereich usw. im Unternehmen, sondern z.B. den Bereich Bahntechnik, Energietechnik, Medizintechnik usw. Eine Bereichsleitung führt demnach relativ unabhängige Unternehmenseinheiten, die selbst über alle Abteilungen verfügen. Doch jetzt zum Thema.

Wenn mir heute in einem Projekt jemand sagt, er hat da eine Anforderung, dann ist meine erste Reaktion: was für eine Anforderung? Und das „was“ bezieht sich dann nicht auf den Inhalt, sondern welche Granularität die Anforderung hat. Ist es eine Anforderung aus der Geschäftsleitung, schon präzisierter aus der Bereichsleitung? Oder ist es eine Anforderung, die im Projektverlauf erst innerhalb eines Programms entstanden ist? Ist sie schon auf angeforderte Leistungsfeatures heruntergebrochen oder sogar im Fachbereich schon umsetzungsreif mit allen Abnahmekriterien beschrieben worden? Oder ist es eine Anforderung genereller Art, wie z.B. eine Performance-Definition? Ist es eine Kundenanforderung, eine aus dem Team stammende Infrastrukturanforderung oder eine Anforderung an eine zur Lösung notwendige Drittlösung?

Um diese schrittweise Präzisierung von Anforderungen von der Geschäftsleitung bis zum mitwirkenden Fachbereich abzubilden, gibt es in der Agilität Anforderungsobjekte.

Abb.: Portfolio Epic – *Quellenangabe: 07

Das oberste Anforderungsobjekt ist die „Portfolio Epic“. Sie beschreibt eine Anforderung zur Lösungsentwicklung aus der Geschäftsleitung, die sich in Großunternehmen in der Regel an die Bereichsleitungen wendet.

Abb.: Epic Owner – *Quellenangabe: 07

Der Verfasser einer Portfolio Epic nennt sich Portfolio Epic Owner und vertritt den Geschäftsleitungsbereich, in dessen Zuständigkeit die Anforderung fällt. Der Epic Owner wird bei seiner Arbeit teilweise durch einen Enterprise Architekt unterstützt. Der Enterprise Architekt ist oft ein externer Unternehmensberater mit der Erfahrung, das Unternehmen in die geforderte Richtung zu entwickeln.

Abb.: Capability – *Quellenangabe: 07

Die Bereichsleitungen arbeiten für die Ableitung der Anforderungen aus einer Portfolio Epic in der Regel zusammen und entscheiden dabei, ob die Anforderung den Bereich überhaupt betrifft, und wenn ja, welche Bereichsanforderungen zur Umsetzung notwendig sind. Für die Anforderungen aus den Bereichen gibt es das Anforderungsobjekt „Capability“. Die Umsetzung der Anforderung aus einer Portfolio Epic wird in der Regel mit mehreren Capabilities beschrieben.

Abb.: Large Solution Rollen – *Quellenangabe: 07

Die Bereichsleitung wird bei seiner Arbeit teilweise durch Solution Architekten und ein Solution Management unterstützt, welche für die bereichsübergreifende Lösungsentwicklung verantwortlich sind.

Die Capabilities aus den Bereichen werden der Geschäftsleitung vorgestellt, gemeinsam abgestimmt und gegebenenfalls so angepasst, dass die Capabilities für alle Bereiche nutzbar sind. Im Interesse der Wirtschaftlichkeit gilt es Sonderlösungen für Bereiche zu vermeiden, weil alle darunter liegenden Anforderungen sonst parallel mit doppeltem oder mehrfachem Aufwand in parallelen Lösungen umgesetzt werden müssten. Ziel ist immer eine für alle Bereiche funktionierende Lösungsentwicklung durch möglichst wenige Projekt-Teams – nicht nur wegen der Aufwandsreduzierung, sondern auch um die Übersicht und Möglichkeit der Zusammenarbeit im Unternehmen zu bewahren sowie in der Zukunft bei Umstrukturierungen der Unternehmensbereiche flexibel zu bleiben.

Die Large Solution Ebene bietet sich vor allem bei Großunternehmen an, bei denen eine Lösung verschiedene Geschäftsbereiche bedienen muss. Die Capability entfällt ohne Large Solution Ebene. In diesem Fall werden aus der Portfolio Epic gleich die Features zur Anforderung definiert.

In der Large Solution Ebene lassen sich aber auch hervorragend programmübergreifende Projektgrundlagen organisieren und umsetzen. Von daher schlage ich diese Zusatzebene jedem vor, der im Projekt mehrere Programme unterstützen muss – auch wenn es nur einen Unternehmensbereich zu bedienen gilt.

In der Portfolio- und Large Solution Ebene werden nur strategische und technische Anforderungen beschrieben. Es wäre schlimm, wenn fachliche Vorgaben aus den oberen beiden Ebenen die tatsächlichen fachlichen Anforderungen in der Programm-Ebene beschränken oder gar verhindern würden. Fachliche Anforderungen können deshalb frühestens mit dem Fachwissen aus den Abteilungen und deren Abstimmung untereinander in der nun folgenden Programm-Ebene beschrieben werden.

Abb.: Feature – *Quellenangabe: 07

Je nach Skalierung werden mit einer Large Solution Ebene aus der Capability oder ohne eine Large Solution Ebene aus der Portfolio Epic die notwendigen Features für die Anforderung beschrieben. Jedes Feature wird dabei in einem eigenen Anforderungsobjekt beschrieben. Die Programm-Ebene befindet sich in der Unternehmenshierarchie bereits im mittleren Management, sprich der IT-Leitung, Personal-Leitung, Fertigungsleitung oder wie in unserem Schwerpunkt der Leitung der Software-Entwicklung. Wir bezeichnen diese Abteilungsleiter in der Agilität auch als Business Owner, weil sie für ihre Abteilungen verantwortlich sind. Wir befinden uns mittlerweile auch deshalb im mittleren Management, weil die Definition der Features bereits fachspezifisches Wissen aus den Abteilungen voraussetzt, welches in der Unternehmensleitung nicht erwartet werden kann. Zudem wird das Projekt in dieser Ebene auf unterschiedliche Abteilungen aufgeteilt, die zusammen eine funktionierende Lösung liefern sollen. Jede Abteilung führt dann sein Programm aus dem Projekt durch und liefert als Ergebnis seine mit den anderen Programmen zeitlich und inhaltlich abgestimmten Teil-Lösungen zurück.

Zusätzlich zur Definition von Features zu einem darüber liegenden Anforderungsobjekt kann in einem Programm auch eine gänzlich neue Anforderung beschrieben werden, die sich erst mit dem Fachwissen aus einer Abteilung ergeben hat. Dieses zusätzliche Anforderungsobjekt oberhalb des Features nennt sich dann „Program Epic“. Auch von diesem Objekt werden wieder die geforderten Features beschrieben.

Abb.: Program-Rollen – *Quellenangabe: 07

Die Abteilungsleiter werden von System-Architekten und einem Produkt-Management unterstützt, so dass die Anforderungen aus allen Abteilungen eine für alle funktionierende Lösung beschreiben.

Abb.: User Story – *Quellenangabe: 07

Ein Team aus einem Fachbereich oder mehreren Fachbereichen erhält als Arbeitsgrundlage ein Feature aus dem Programm und bringt seine ganz spezifischen Anforderungen in Form von Stories (auch User Stories genannt) an eine Lösung ein. Da in der Regel viele Teams parallel mit der Anforderungsermittlung betraut werden, müssen sich die Teams miteinander so abstimmen, dass ähnlich wie in der Large Solution Ebene eine für alle passende Lösung beschrieben wird – sowohl inhaltlich als auch zeitlich!

Abb.: Team-Rollen – *Quellenangabe: 07

Jedes Team hat bei Scrum einen Scrum Master und einen Product Owner für die zu entwickelnde Teil-Lösung. Der Product Owner steht in engem Kontakt zum Produkt-Management um die Anforderungsdefinition in die geplante Richtung der darüber liegenden Ebenen auszusteuern. Der Scrum Master steht in engem Kontakt mit dem Release Train Engineer (hier RTE), um die Lieferung der Teil-Lösung mit anderen Teams so zu koordinieren, dass am Ende eines jedem Product Inkrements eine funktionierende Lösung im Programm gewährleistet wird. Die RTEs stehen wiederum in engem Kontakt mit den Solution Train Engineers (auch STE genannt) aus der Large Solution Ebene, damit die gelieferten Releases aller Einzelprogramme so abgestimmt sind, dass alle Bestandteile, sprich: Software, Change-Management, IT, Gebäude-Management usw. eine für den Anwender möglichst perfekte Gesamtlösung ergeben, die dann wertschöpfend eingesetzt werden kann. Und der STE steht wieder im engen Austausch mit den Bereichsleitern, welche die Umsetzung stets im Auge haben. Die Geschäftsleitung selbst wird über geeignete Instrumente und KPIs informiert.

Damit hätten wir die grundsätzlichen Anforderungsobjekte beschrieben.

Eine Sonderrolle nimmt dann noch das Anforderungsobjekt des „Nonfunctional Requirement“ ein. Diese Anforderung kann in jeder Ebene – vom Portfolio bis hin zum Team – beschrieben werden und ist dann zusätzlich auf alle zugeordneten Anforderungsobjekte anzuwenden. Ein Beispiel ist die Definition, dass eine Anforderung (Portfolio Epic, Capability, Program Epic, Feature oder Story) unter beschriebenen Bedingungen funktionieren muss. Dass können im Fall von Software Ladezeiten sein, oder eine bestimmte Auflösung, oder eine einzuhaltende Bandbreitenbeschränkung, irgendetwas in dieser Art.

Bisher haben wir nur Kundenanforderungen beschrieben. Daneben gibt es aber auch noch Anforderungen aus dem eigenen Team. Das wären dann zum Beispiel Infrastruktur-Anforderungen, Anforderungen zur Beseitigung von Bugs oder Anforderungen an Lieferanten zu eingesetzten Drittanbieterlösungen. Im Team werden alle diese Anforderungen in Stories beschrieben. Um genau zu sein Kundenanforderungen in User Stories und teaminterne Anforderungen in Stories. Im Alltag wird da aber keinerlei Unterscheidung gemacht. Da wird einfach das gleiche Anforderungsobjekt genutzt und über ein Anforderungsobjekt-Attribut unterschieden.

Abb.: Stream/Train-Hierarchie

Ich möchte jetzt noch ganz kurz eine Grundlage ansprechen, die uns dabei hilft die nächsten Lektionen besser zu verstehen, auch wenn es sich bei diesem Inhalt nicht um Anforderungsobjekte, sondern um Instrumente zur Organisation von Anforderungen handelt.

Das agile Werkzeug des Value Stream sammelt Herausforderungen aus der Portfolio Ebene (hier z.B. Challenge 1) und bricht diese in Anforderungen herunter (hier z.B. Req. 1 zu Challenge 1).

Für die Anforderungen werden im Solution Train Lösungen entwickelt (hier z.B. Solution Release 1 + 2). Die Lösung wird in Arbeitspakete, nämlich die Releases unterteilt und dabei sowohl inhaltlich als auch zeitlich strukturiert. Die Solution Releases werden im Solution Train wiederum in besser erfüllbare kleinere Einheiten, die Solution Increments heruntergebrochen.

Die Lieferinhalte zu den Solution Increments werden im Release Train geplant. Jedes Release erfüllt ein Solution Increment. Nicht jeder Lieferinhalt wird sofort in einem Release zur Verfügung gestellt, sondern mehrere Release Increments werden in der Regel von unterschiedlichsten Teams eingesammelt, bevor sie in einem funktionierenden Release zur Nutzung veröffentlicht werden.

Der Inhalt für die Release Increments wird im Rahmen der Product Increment Planung (nennt sich dann PI Planning) von den Business Ownern und den Projektteams vereinbart und dann in zeitlich begrenzten Sprints umgesetzt.

• Ein Value Stream unterteilt sich in der Regel in mehrere Solution Trains
• Ein Solution Train unterteilt sich in der Regel in mehrere Release Trains
• Ein Release Train unterteilt sich in der Regel in mehrere Product Trains

• Die Arbeitsinhalte der Sprints landen im Product Increment,
• die Inhalte des Product Increments landen im Release Increment,
• mehrere Release Increments bilden ein Release,
• ein Release bedient ein Solution Increment,
• mehrere Solution Increments bilden ein Solution Release,
• ein Solution Release bedient eine Anforderung aus einer Herausforderung und
• mehrere Anforderungen erfüllen eine Herausforderung.

Und damit ist die ganze Sache rund. Mit diesem Verständnis sollte es Dir leichter fallen, die folgenden Lektionen und die dahintersteckende Logik zu verstehen. In den nächsten Lektionen beschäftigen wir uns also mit diesen Streams und Trains und in welchen Streams und Trains welche Anforderungsobjekte geplant und wohin Lösungen geliefert werden. Du meinst, dass sich das schräg anhört? Warte ab, da fügt sich der Kurs-Inhalt aus den bereits behandelten Projektmanagement-Grundlagen sehr schön ineinander.