IT-Analyse in agilen Projekten

Einführung

Rollenbilder in einem IT-Projekt

Applikationsentwickler, UI-Designer, Projektmanagement Officer, Product Owner, Requirements Engineer, Qualitätsmanager, Architekt, Projektmanager, Testingenieur, Business Analyst, Programmmanager, UX-Designer, Systems Engineer. Das sind nur einige der IT-bezogenen Job-Titles, die sich auf Visitenkarten und in XING-Profilen finden.

Wie ist das, braucht man alle diese Rollen in einem IT-Projekt um erfolgreich zu sein? Wenn nein, warum gibt es sie dann? Was davon ist wirklich erforderlich?

Eine Antwort davon versucht die deutsche Bitkom auf der Website www.erlebe-it.de zu geben[i]. Bitkom, der deutsche Digitalverband, wirbt auf dieser Seite bei Jugendlichen für IT-Berufe. Für unsere Frage interessant ist dabei, dass dort die IT-Berufe in folgende drei Gruppen geteilt werden:

• Wir brauchen Leute, die sich mit der Technik auskennen – also jemand, der die Programmiersprache beherrscht, eine Datenbank aufsetzen kann, mit all den anderen Werkzeugen umgehen kann, die man für die Herstellung einer Software-Applikation und deren Test so braucht. Wir wollen diese Gruppe die Ingenieure
• Die zweite Gruppe kümmert sich darum, was die Software überhaupt leisten soll. Software ist kein Selbstzweck – sie muss Wert schaffen für die betroffene Organisation. Jemand muss das Wissen über die Gesetzmäßigkeiten des Fachgebietes kennen, muss dafür sorgen, dass die entwickelte Software diesen Gesetzmäßigkeiten entspricht, damit die Ziele erreicht werden können. Diese Gruppe nennen wir die
• Auch ein IT-Projekt muss mit beschränkten Ressourcen umgehen – beschränkter Zeit, beschränktem Budget. Sich darum zu kümmern, das ist die Aufgabe der Software-Manager. Darüber hinaus kümmern sie sich darum, dass aus Gestaltern und Ingenieuren ein Team wird.

Diese drei Rollen sind es, die ein IT-Projekt braucht. Welche der eingangs erwähnten Job-Titles dabei verwendet werden, ist zweitrangig. Es ist auch nicht ausgeschlossen, dass – vor allem in kleinen Projekten – die eine oder andere Rolle von ein und derselben Person wahrgenommen wird.

Es ist offensichtlich, in welcher dieser Rollen sich der Analytiker finden wird: es ist die des Gestalters. Gestaltung – das ist die Aufgabe des Analytikers, unabhängig davon, wie das Projekt organisiert ist, unabhängig davon, ob das Projekt agil oder traditionell abgewickelt wird.

[i] www.erlebe-it.de

Gestaltung im IT-Projekt

Mit „Gestaltung“ verbindet man oft das Design der Oberfläche – Formen und Farben. Hier ist jedoch mehr gemeint: Die Gestaltung des Gesamtsystems, das aus folgenden drei Aspekten besteht:

Statik

Der statische Teil unserer Lösung ist das System aus den Entitäten und den Beziehungen dazwischen. Die im betrachteten Fachgebiet relevanten Dinge, ob abstrakt oder konkret, werden durch ein Datenmodell abgebildet. Die Art der Darstellung hat sich im Lauf der Zeit gewandelt. Wurden früher vorwiegend Entity-Relationship-Diagramme verwendet, so kommen heute in erster Linie UML-Klassendiagramme zur Anwendung. Auch für die technische Implementierung gibt es verschiedene Varianten: Noch immer sind relationale Datenbanken State of the Art. Objektorientierte Datenbanken waren lange im Gespräch, konnten sich aber nie wirklich durchsetzen. Sogenannte NoSQL-Datenbanken werden wohl in naher Zukunft an Bedeutung gewinnen.

Dynamik

Der dynamische Aspekt unserer Lösung bringt die Bewegung in unsere Systeme. Wir sprechen hier im Allgemeinen von Prozessen, die die an sich statischen Daten schaffen und verändern und so die Realität abbilden. Es sind hier zwei verschiedene Typen an Prozessen zu unterscheiden:

Einerseits die „Prozesse im Großen“. Das ist die Reihenfolge, in der einzelne Bausteine oder Funktionen verwendet werden, um ein bestimmtes Ziel zu erreichen. Zum Beispiel ist das die Art und Weise, wie ein bestimmter Geschäftsfall von verschiedenen Stellen in einer Organisation bearbeitet wird. Manchmal spricht man hier auch von einem Workflow. Business Analysten, die sich auf diesen Bereich spezialisieren, werden Prozessanalysten oder Prozessmanager bezeichnet

Andererseits gibt es die „Prozesse im Kleinen“. Darunter sind die Algorithmen zu verstehen, die innerhalb der Bausteine ablaufen. Beispiele dafür sind diverse Berechnungen. In vielen Fällen legt diese Algorithmen erst der Entwickler fest. In manchen Fällen – vor allem dann, wenn es um fachliche Verfahren geht – macht auch bereits der Analytiker einen entsprechenden Vorschlag.

Die Schnittstellen

Jedes von Analytikern gestaltete System braucht eine Schnittstelle nach außen, über die es mit seiner Umwelt interagiert. In den meisten Fällen, in denen es um die Kommunikation des Systems mit Menschen geht, wird diese Schnittstelle durch Bildschirm-Screens abgebildet, über die Information eingegeben oder zur Verfügung gestellt wird.

Je nach Art des Systems gibt es aber auch andere Schnittstellen nach außen. Vielleicht werden Daten über Sensoren geliefert. Wenn nicht Menschen, sondern andere Software-Systeme die Kommunikationspartner sind, dann wird die Schnittstelle des Systems möglicherweise aus API-Schnittstellen abgebildet.

 „Gestaltung“ bedeutet, alle drei Aspekte so zu beschreiben, dass sie von Entwicklern (den „Software-Ingenieuren“) in Software gegossen werden können. Und genau diese Gestaltung ist die Aufgabe des Analytikers. Die Erhebung und Dokumentation von Anforderungen ist ein notwendiger Teil davon – nicht mehr und nicht weniger.

Diese Gestaltungsaufgabe ist das Wesen der IT-Analyse. Es gilt seit es Software-Entwicklung gibt. Es ändert sich die Technik, die Methoden und die Vorgehensweisen. Aber immer hat ein IT-System Statik, Dynamik und Schnittstellen. Die Definition, wie diese aussehen, ist, war und bleibt die Aufgabe des IT-Analytikers.

Agil und traditionell

Was ändert sich nun an dieser Aufgabe, wenn die Analyse in einem agilen Projekt stattfindet?

Das Gemeinsame …

Die Aufgabe, das IT-System zu gestalten, ist das Wesen der IT-Analyse. Das war so in den Anfängen der IT – und wird auch in Zukunft so bleiben. Und das gilt auch unabhängig von der Organisationsform, also egal, ob ein IT-Projekt traditionell oder agil abgewickelt wird: Die Aufgabe der IT-Analyse ist es, ein IT-System zu gestalten.

… und die Unterschiede

Jenseits dieser Gemeinsamkeiten gibt es aber auch Unterschiede:

Es erfordert andere Vorgangsweisen, je nachdem, ob dem Analytiker die Zeit gegeben ist, dieses System in seiner Gesamtheit zu durchdenken und durchzuspezifizieren. Oder aber, ob schon nach relativ kurzer Zeit Ergebnisse geliefert werden müssen, ohne überhaupt noch alle Details darüber zu wissen, was das System leisten können muss.

Der Trivial-Ansatz, einfach einmal an einer Ecke mit Analyse und Entwicklung zu beginnen, ist zum Scheitern verurteilt. Ohne einen Gesamtüberblick über das Fachgebiet zu haben, ist jede Analyse- und auch Entwicklungstätigkeit reine Verschwendung – es wird im weiteren Projektverlauf nichts davon übrig bleiben.

Ein Ansatz, die sowohl das Gewinnen des Gesamtüberblicks als auch eine schrittweise Gestaltung des zu entwickelnden Systems ermöglicht ist das „T-Stich-Verfahren“. [i]

Abbildung 1 illustriert dieses Modell. Auf der x-Achse ist das zu unterstützende Fachgebiet in seiner gesamten Breite dargestellt. Die y-Achse zeigt den Detaillierungsgrad der einzelnen Teilgebiete.

Um das Ziel zu erreichen, möglichst schnell Gestaltungs-Ergebnisse zu bringen, die auch nachhaltig Nutzen bringen, wird empfohlen, sich zunächst mit dem Fachgebiet in seiner gesamten Breite zu beschäftigen – und ein grobes Konzept zu erstellen, auf dem in weiterer Folge aufgebaut werden kann.

Mit dem so erworbenen Wissen kann für die einzelnen Releases in die Tiefe gegangen werden. Auf diese Art und Weise wird das System inkrementell gestaltet.

Diese Aufteilung der gesamten Gestaltungstätigkeit in einen generellen Überblicksteil und in viele Detaillierungsteile, die inkrementell abgearbeitet werden, ist der markante Unterschied zwischen traditionellen und agilen Vorgehensweisen. Daneben werden, unter anderem in der ‚Agile Extension to the BABOK-Guide“ [ii], etliche Grundsätze eines agilen Mindsets genannt:

• See the Whole
• Think as a Customer
• Analyze to Determine What is Valuable
• Get Real Using Examples
• Understand What is Doable
• Stimulate Collaboration and Continuous Improvement
• Avoid Waste

Bei näherer Betrachtung sind diese Grundsätze zwar modern und deren Anwendung kann vieles erleichtern. Mit agiler Entwicklung an und für sich haben sie aber nur am Rande zu tun. Ihre Anwendung ist bei traditioneller Vorgangsweise ebenso vorteilhaft wie bei agiler.

[i] Hruschka, Peter: Business Analysis und Requirements Engineering, 2014 Carl Hanser Verlag München, S 24 ff

[ii] IIBA, Agile Extension to the BABOK-Guide, 2017