Ausgewählte Themen zu den Auswirkungen der Informationswirtschaft auf das Management

Inhaltsverzeichnis

Teil 1: Das Management von Softwareentwicklungsprojekten: Unternehmen lernen aus eigenen Erfahrungen

Kapitel 1: Methodische Ansätze zur Projekt- und Personalorganisation in der Softwareentwicklung
1 Einleitung
2 Projektmanagement
2.1 Institutionelles Projektmanagement
2.2 Funktionelles Projektmanagement
2.3 Instrumentelles Projektmanagement
2.4 Verwandte Ansätze

3 Unified Process

4 Agile Methoden
4.1 Crystal Methoden
4.2 Adaptive Software Development
4.3 Scrum
4.4 ARTE
4.5 Extreme Programming

5 Personenzentrierter Ansatz

Kapitel 2: Erfolgsfaktoren für ein mitarbeiterzentriertes Projektmanagement in der Softwareentwicklung am Beispiel eines österreichischen KMU

6 Organisationsstruktur
6.1 WEB Abteilung
6.2 IT Abteilung

7 Unternehmenskultur

8 Projekte und Kunden
8.1 Projekte
8.2 Kunden

9 Lernen im Projektmanagement

10 Agilität

11 Praktische Umsetzung

Kapitel 3: Fallstudien zur Unterstützung des Kommunikations- und Wissensmanagements in IT-Projekten

12 Modul Wissen

13 Module Issues, Meetings, Workflow
13.1 Modul Issues
13.2 Modul Meetings
13.3 Modul Workflow

14 Schlussfolgerungen

15 Anhang

Teil 2: Mensch-Computer-Interaktion bei der Implementierung von Prozess- und Kommunikationsmanagementsystemen

Kapitel 4: Benutzerfreundlichkeit bei webbasierten Informationssystemen

16 Grundlagen
16.1 Einführung und Definition von Usability
16.2 Entwicklung und Umsetzung von Usability
16.3 Einführung und Definition von Accessibility
16.3.1 Betroffene Nutzergruppen
16.3.2 Zugänglichkeitsrichtlinien für Web-Inhalte nach W3C
16.4 Kapitelzusammenfassung

17 Usability und Accessiblility bei webbasierten Informations- und Kommunikationssystemen
17.1 Usability bei webbasierten Informations- und Kommunikationssystemen
17.1.1 Das Page Design
17.1.2 Das Content Design
17.1.3 Das Site Design
17.1.4 Das Intranet Design
17.2 Accessibility bei webbasierten Informations- und Kommunikationssystemen
17.3 Methoden zur Usability Evaluation von Systemen
17.3.1 Design-Guidelines/Gestaltungsrichtlinien
17.3.2 Formal-analytische Verfahren
17.3.3 Inspektionsmethoden
17.3.4 Usability -Tests
17.3.5 Fragebogen
17.4 Kapitelzusammenfassung

Kapitel 5: Benutzerfreundlichkeit und Gebrauchstauglichkeit von Intranet-Systemen in der Wohnungswirtschaft – Fallstudie PORTEGO

18 Einleitung

18.1 Das Guided User Interface der Intranetplattform PORTEGO
18.1.1 Die Navigationsleiste
18.1.2 Die Benutzerleiste
18.1.3 Die Verwaltung
18.2 Systemkonzept und modularer Aufbau
18.3 Kapitelzusammenfassung

19 Heuristische Evaluation von PORTEGO
19.1 Der Untersuchungsgegenstand
19.1.1 Die Nutzergruppen, Aufgaben und der Untersuchungsumfang
19.1.2 Die verwendeten Heuristiken
19.1.3 Die verwendeten Kommentartypen
19.1.4 Die Evaluierung von PORTEGO
19.1.5 Die Evaluierung des Userinterface
19.1.6 Die Evaluierung der Verwaltung
19.1.7 Die Evaluierung der Benutzerleiste
19.2 Das Ergebnis der Evaluierung
19.3 Kapitelzusammenfassung

Kapitel 6: Technologien für webbasierte Informationssysteme und deren Implementierung

20 Technologien und technische Hilfsmittel
20.1 WEB 2.0
20.1.1 Ajax als Schlüsseltechnologie des Web 2.0
20.1.2 .NET Framework
20.1.3 Programmiersprache C#
20.1.4 ASP.NET
20.1.5 Web Forms
20.1.6 Code-Behind
20.2 Kapitelzusammenfassung

21 Implementierung der evaluierten Technologie
21.1 Implementierung der Ajax-Technologie in PORTEGO
21.2 Anpassungen der globalen Web.config
21.3 Implementierung der Ajax-Elemente
21.4 Kapitelzusammenfassung

22 Schlussbetrachtung
22.1 Zusammenfassung
22.2 Ausblick

23 Abkürzungsverzeichnis

24 Anhang A zur Evaluierung

25 Anhang B zur Implementierung

Editors

N. Kryvinska, Faculty of Management, Comenius University in Bratislava

M. Greguš, Faculty of Management, Comenius University in Bratislava

Th. Lenhard, Faculty of Management, Comenius University in Bratislava

Authors

J. Kosmál, Fakultät für Informatik, Universität Wien

T. Jagereder, Informationstechnik und System Management, Fachhochschule Salzburg

B. Van den Nest, Elektronische Informationsdienste, Fachhochschule Technikum Wien

C. Steinringer, Faculty of Management, Comenius University in Bratislava

L. Gregusova, Deapartment of Management and Informatics, Academy of the Police Force in Bratislava

Reviewers

Doc. RNDr. Viliam Malcher, PhD.

PhDr. Ing. Monika Dávideková, PhD.

GRIN VERLAG

München 2018

Teil 1

Das Management von Softwareentwicklungsprojekten: Unternehmen lernen aus eigenen Erfahrungen

Kapitel 1 – J. Kosmál, C. Steinringer „Methodische Ansätze zur Projekt- und Personalorganisation in der Softwareentwicklung“

Kapitel 2 – J. Kosmál, C. Steinringer, L. Gregušova „Erfolgsfaktoren für ein mitarbeiterzentriertes Projektmanagement in der Softwareentwicklung am Beispiel eines österreichischen KMU“

Kapitel 3 – J. Kosmál, C. Steinringer „Fallstudien zur Unterstützung des Kommunikations- und Wissensmanagements in IT-Projekten“

Teil 2

Mensch-Computer-Interaktion bei der Implementierung von Prozess- und Kommunikationsmanagementsystemen

Kapitel 4 – T. Jagereder, C. Steinringer „Benutzerfreundlichkeit bei webbasierten Informationssystemen“

Kapitel 5 – T. Jagereder, B. Van den Nest, C. Steinringer „Benutzerfreundlichkeit und Gebrauchstauglichkeit von Intranet-Systemen in der Wohnungswirtschaft – Fallstudie PORTEGO“

Kapitel 6 – T. Jagereder, C. Steinringer „Technologien für webbasierte Informationssysteme und deren Implementierung“

Vorwort

Im vorliegenden Band der Reihe setzen wir die Betrachtung unseres Schwerpunktthemas der Auswirkungen der Informationswirtschaft auf das Management fort und richten den Fokus auf ausgewählte Aspekte der Planung und Realisierung von IT-Projekten. Im Besonderen wird dabei auf die verschiedenen Aufgaben- und Problemstellungen für ein effizientes Personalwesen in derartigen Realisierungsvorhaben eingegangen.

Im ersten Teil beschreiben die Autoren, wie Unternehmen ihre Prozesse zum Management von IT-Projekten anhand der eigenen Erfahrungen stetig verbessern können und welche organisatorischen Maßnahmen hierfür von Bedeutung sind.

Teil zwei widmet sich der Evaluierung und Optimierung von webbasierenden, internen Informations- und Kommunikationssystemen und untersucht die Frage, welche Faktoren auf die Gebrauchstauglichkeit dieser Systeme maßgeblichen Einfluss haben

Verzeichnis der Abbildungen, Tabellen und Listings

Abbildung 1: Wasserfallmodell

Abbildung 2: Aufgabenabgrenzung (nach der Quelle: PM/GT)

Abbildung 3: Institutionelles Projektmanagement (nach der Quelle: Jenny 2001, S 97)

Abbildung 4: Kosten der Fehlerbehebung (nach der Quelle: Jenny 2001, S 303)

Abbildung 5: Beta-Methode Formel

Abbildung 6: Rational Unified Process (nach der Quelle: Agility kompakt 2004, S 81)

Abbildung 7: Dokumentationstechniken (nach der Quelle: Agility kompakt 2004, S 16)

Abbildung 8: Vergleich von Aspekten (nach der Quelle: Agility kompakt 2004, S 55)

Abbildung 9: Phasen von ASD (nach der Quelle: Agility kompakt 2004 S 62)

Abbildung 10: Scrum Prozess (nach der Quelle: Agility kompakt 2004 S 68)

Abbildung 11: Drei Ergebnisspeicher (nach der Quelle: Agility kompakt 2004 S 77)

Abbildung 12: Formelle Organisationsstruktur

Abbildung 13: Castello Pro (Quelle: Steinringer)

Abbildung 14: Rechteverwaltung (Quelle: Steinringer)

Abbildung 15: Folgenden möglichen Rollenkombinationen.

Abbildung 16: Rollenkombination nach Microsoft Solution Framework

Abbildung 17: Beta Methode vs. Drei-Punkte-Schätzung

Abbildung 18: Datenmodell

Abbildung 19: Datendiagramm Projektverwaltung (Quelle: Steinringer)

Abbildung 20: Workflow bei Modulen Issues, Meetings und Workflow (Quelle: Steinringer)

Abbildung 21: Modul Issues (Quelle: Steinringer)

Abbildung 22: Modul Meetings (Quelle: Steinringer)

Abbildung 23: Modul Workflow (Quelle: Steinringer)

Abbildung 24: Castello Pro (groß)

Abbildung 25: Rechteverwaltung (groß)

Abbildung 26: Datenbankdiagramm Projektverwaltung (groß)

Abbildung 27: Workflow bei Modulen Issues, Meetings und Workflow (groß)

Abbildung 28: Modul Issues (groß)

Abbildung 29: Modul Meetings (groß)

Abbildung 30: Modul Workflow (groß)

Abbildung 31: Der Gestaltungsprozess von benutzerorientierten Produkten

Abbildung 32: Dreispaltiges Layout[Rad06]

Abbildung 33: Das grundlegende Designinterface

Abbildung 34: Die PORTEGO Startseite

Abbildung 35: PORTEGO-Navigationsleiste

Abbildung 36: Ausgeklappte Benutzerleiste mit einem Baustein

Abbildung 37: Organisationsstruktur PORTEGO

Abbildung 38: Systemaufbau von PORTEGO

Abbildung 39: Profilseite mit angezeigten Schwachstellen, Teil 1

Abbildung 40: Profilseite mit angezeigten Schwachstellen, Teil 2

Abbildung 41: Nachrichtenseite mit angezeigten Schwachstellen in der Benutzerleiste

Abbildung 42: Vergleich Ajax Web-Anwendung mit klassischer Web-Anwendung [Gar07]

Abbildung 43: Die allgemeine Personenseite

Abbildung 44: Abbildung mit angezeigtem Hinweis

Abbildung 45: Die Abteilung-Detailansichtsseite

Tabelle 1: Zehn Grundsätze für benutzerfreundliches Design nach Nielsen [Nie93].

Tabelle 2: Ausgewählte Heuristiken nach Jakob Nielsen

Tabelle 3: Ausgewählte Heuristiken nach der DIN NORM ISO 9241

Tabelle 4: Ausgewählte Heuristiken nach den W3C Richtlinien

Listing 1: Einbindung des Scriptmanagers

Listing 2: Einbindung eines Elements (Webliste)

Listing 3: Einbindung und Definition des Hinweises

Teil 1 Das Management von Softwareentwicklungsprojekten: Unternehmen lernen aus eigenen Erfahrungen

Kapitel Methodische Ansätze zur Projekt- und Personalorganisation in der Softwareentwicklung

J. Kosmál , C. Steinringer ^[1]

1 Einleitung

Projekte gibt es, seitdem die Menschen gelernt haben, selbständig zu denken und die Zukunft zu planen. Wir haben erkannt, dass wir komplexere Vorgaben besser bewältigen können, wenn wir sie in einzelne Schritte teilen und diese planen bzw. steuern. Diese Vorgehensweise half den Ägyptern beim Bau von Pyramiden, Leonardo Da Vinci beim Bau seiner zahlreichen Erfindungen oder Gustave Eiffel beim Bau des Eiffelturms bzw. der Freiheitsstatue. Mancher Leser würde wahrscheinlich an dieser Stelle das Deckblatt noch einmal betrachten wollen um den Titel der Arbeit zu überprüfen. Das Bauwesen hat aber viel mit der Softwareentwicklung gemeinsam. Das Ergebnis der Softwareentwicklung kann man zwar nicht mit den Händen angreifen, aber genauso wie beim Bauvorhaben wird auch für das Errichten einer Software ein Grundgerüst benötigt. Man kann kaum tragende Säulen ohne ein Fundament bauen oder das Dach legen ohne die Wände aufgestellt zu haben. Jede Software braucht ebenfalls eine unterstützende Struktur, auf der sie aufgebaut werden kann. Diese Struktur nennt man Architektur. Erst wenn die Architektur steht, können die einzelnen Komponenten entwickelt werden. Ihre Entwicklung muss in der Anlehnung an die Architektur passieren. Es ist besonders darauf zu achten, dass die Architektur nicht verletzt wird. Die Aufgabe des Projektmanagements ist unter Anderem die ständige Überprüfung, ob diese Regeln eingehalten werden und die Begleitung der Projektbeteiligten bei der Durchführung von einzelnen Projektschritten.

Die Art und Weise, wie die Projektschritte durchgeführt werden, kann von Projekt zu Projekt unterschiedlich sein. In den letzten Jahrzehnten, die seit der Entwicklung der ersten Software vergangen sind, sind mehrere Ansätze entstanden, die die empfohlene Vorgehensweise bei der Softwareentwicklung beschreiben. Zu den wichtigen Vertretern gehört auch das Wasserfallmodell.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Wasserfallmodell

Das Wasserfallmodell unterteilt den Softwareentwicklungsprozess in sechs Phasen, die chronologisch nacheinander folgen. Der Vorteil eines solchen Modells ist die klare Abgrenzung von Phasen und die relativ einfache Planung und Steuerung. Problematisch ist hingegen die Tatsache, dass im Realleben die klare Abgrenzung kaum möglich ist. Der weitere Nachteil ist auch der späte Einsatz und die damit zusammenhängende späte Fehlererkennung und der verspätete Investitionsrückfluss.

Das Spiralmodell versucht die Nachteile des Wasserfallmodells abzufedern, in dem es die Phasen des Wasserfallmodells zyklisch wiederholt. Das Spiralmodell gehört somit zu den inkrementellen und iterativen Vorgehensmodellen.

(Quelle: Wikipedia)

Der Unified Process ist ein Methodenframework und entstand 2001. Er betrachtet den Softwareentwicklungsprozess aus der Entwickler- und aus der Managementsicht. Um die gleiche Zeit entstanden auch mehrere Methoden, die sich in die Familie der agilen Methoden einordnen lassen. Diese letzten Entwicklungen werden in gesonderten Kapiteln dieser Arbeit betrachtet.

Was ist ein Projekt?

Der zentrale Punkt dieser Arbeit ist die Steuerung und Überwachung von Projekten. Daher ist es wichtig genau zu wissen, was unter einem Projekt verstanden wird. Eine kompakte Definition wird in PM/GT gegeben:

Ein Projekt ist ein Vorhaben, das sich durch folgende Merkmale charakterisiert: zielorientiert, zeitlich begrenzt, komplex und dynamisch, interdisziplinär und abteilungsübergreifend, neuartig und riskant, bedeutend für das Unternehmen. (Quelle: PM/GT)

PM/GT liefert gleichzeitig auch eine Abgrenzung von unterschiedlichen Vorhaben. Die folgende Abbildung bietet eine Unterstützung bei der Entscheidung, nach welchen Kriterien Prozesse, Programme, Projekte und Maßnahmen definiert werden können:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Aufgabenabgrenzung (nach der Quelle: PM/GT)

Zusätzlich zur Einmaligkeit und der Koordination über eine Projektorganisation muss ein Projekt die folgenden Kriterien erfüllen:

- definiertes Ziel
- erhöhtes Risiko
- komplexes Vorhaben
- Zeitdruck
- definiertes Projektbudget
- innovative Aufgabenstellung
- Beteiligung von mehr als 4 Mitarbeitern
- Laufzeit zwischen 2 Monaten und 1 Jahr

Werden diese Kriterien erfüllt, geht es laut PM/GT um ein Projekt und die Phase der Überprüfung der Projektwürdigkeit kann abgeschlossen werden.

Je nachdem welche Zielsetzung ein Projekt hat, werden Organisationsprojekte, Bauprojekte, Marketingprojekte, Produktentwicklungsprojekte, Investitionsprojekte, Softwareprojekte, Hardwareprojekte, Greenfieldprojekte und Forschungsprojekte unterschieden. Diese Arbeit legt den Fokus auf Softwareprojekte.

2 Projektmanagement

In diesem Kapitel werden Projektmanagementmethoden bzw. Projektmanagement- und Kommunikationsansätze aus der Literatur vorgestellt, welche breite Anerkennung finden.

Viele Publikationen (z.B. Jenny 2001, Royce 1998, Patzak 2004, Mangold 2004, Schmid 2003, Thaller 2002) haben sich schon mit dem Thema Projektmanagement beschäftigt. Um Projektmanagement in dieser Arbeit zu beschreiben, werden Quellen verwendet, die als Nachleselektüre an der Universität Wien empfohlen werden. Überwiegend ist es das Buch Projektmanagement in der Wirtschaftsinformatik von Bruno Jenny. Bruno Jenny ist in diversen öffentlichen Einrichtungen und Firmen vor Allem in der Schweiz als Dozent zum Thema Projektmanagement tätig. Er ist gleichzeitig Geschäftsführer und Inhaber der SPOL AG und Autor von mehreren Fachbüchern. Seit über 20 Jahren realisiert er Großprojekte. (Quelle: Spol AG)

Jenny 2001 definiert Projektmanagement wie folgt:

„Unter Projektmanagement wird die Gesamtheit der Führungsaufgaben, -organisation, -techniken, und –mittel zur Abwicklung eines Projektes verstanden.“ (Quelle: Jenny 2001 S 61)

Gleichzeitig definiert er drei Dimensionen des Projektmanagements:

- institutionelles Projektmanagement (Aufbau)
- funktionelles Projektmanagement (Ablauf)
- instrumentelles Projektmanagement (Methoden)

2.1 Institutionelles Projektmanagement

Das institutionelle Projektmanagement beschreibt die Aufbauorganisation eines Projektes. Diese betrifft mehrere Aspekte. An erster Stelle steht die Organisationsform. Die Wahl dieser ist wichtig, um die Kommunikationsflüsse in der Projektorganisation zu optimieren. Wird die reine Projektorganisation gewählt, haben alle Projektmitarbeiter zu 100% mit dem Projekt zu tun und sind einzig und allein dem Projektleiter gegenüber verantwortlich. Wählt man die Stab-Linien-Projektorganisation bleiben die Mitarbeiter weiterhin in der Linie, arbeiten zugleich am Projekt und sind nur dem Linienleiter gegenüber verantwortlich. Der Projektleiter verfügt über keine Weisungsrechte, er hat eher die Rolle des Projektkoordinators. Eine weitere mögliche Organisationsform ist die Matrix-Projektorganisation. Bei dieser unterstehen die Mitarbeiter dem Linienleiter und dem Projektleiter. Im Gegenteil zur Stab-Linien-Projektorganisation hat der Projektleiter eine Weisungsbefugnis. Üblicherweise entscheidet der Linienleiter wer, wie, wo und womit, der Projektleiter was und wann.

An zweiter Stelle müssen Instanzen und Stellen im Projekt definiert werden. Jede Instanz und jede Stelle übernimmt gewisse Aufgabenbereiche, Kompetenzen und Verantwortungen. Wie die Projektmitarbeiter untereinander kommunizieren, kann in einem Informationssystem festgelegt werden. Sollten regelmäßige Sitzungen, Dialoge oder Präsentationen stattfinden, können ihre Häufigkeit und ihr Aufbau bestimmt werden. Sollten Berichte zur Kommunikation verwendet werden, können wiederum ihre Form und ihr Umfang bestimmt werden.

Ein Dokumentationssystem ist ebenfalls von großer Bedeutung, wenn gewährleistet werden soll, dass es zu keinen Missverständnissen und Widersprüchen kommt, dass die Richtigkeit der durchgeführten Tätigkeiten überprüfbar ist, dass die Projektorganisation personenunabhängig wird, und dass das Projekt an die sich ändernde Umgebung angepasst werden kann.

Im Projekt-Kommunikationssystem kann die Art und Weise beschrieben werden, wie die Kommunikationsflüsse auszusehen haben. Die Beschreibung der Form und die Zuführungsverantwortung (Holschuld / Bringschuld) können ebenfalls Bestandteile des Kommunikationssystems sein. Der letzte wichtige Punkt beim institutionellen Projektmanagement ist das Sach- und Hilfsmittelsystem. In diesem wird festgelegt, welche Räumlichkeiten, Büromaterialien, Software und Hardware das Projektteam zum Arbeiten braucht.

(Quelle: Jenny 2001, S 97 ff)

Abbildung 3: Institutionelles Projektmanagement (nach der Quelle: Jenny 2001, S 97)

2.2 Funktionelles Projektmanagement

Das funktionelle Projektmanagement beschäftigt sich mit den Aufgaben, die während des Projektes durchgeführt werden müssen. Die Hauptaufgaben des funktionellen Projektmanagements sind (Quelle: Jenny 2001, S 197):

- Projektplanung
- Projektsteuerung und Koordination
- Projektüberwachung und Projektkontrolle

Die Projektplanung bietet unterschiedliche Planungsinstrumente an. Der Gesamtprojektplan bietet eine Übersicht über das gesamte Projekt, er ist so zu sagen ein Metaplan für die Gestaltung und Realisierung des Projektes. Im Projektplan wird das ganze Projekt in Teilprojekte unterteilt. Die Aufgabe des Projektleiters ist dann, diese Teilprojekte während des Projektablaufs zu koordinieren. Der Phasenplan beschäftigt sich - wie der Name verrät - mit der Planung der einzelnen Projektphasen. Diese Planung geht bereits tiefer, die konkreten Termine, Ressourcen, Kosten und Leistungen bilden einen wichtigen Bestandteil. Der Qualitätssicherungsplan definiert die Anforderungen für das zu erstellende Produkt. Es kann um unterschiedliche Standards und Normen gehen, deren Einhaltung folglich im Prüfplan überprüft wird. Der Produktstrukturplan, der Projektstrukturplan und der Kostenstrukturplan gehören in die Gruppe der Strukturpläne. Die Aufgabe dieser ist die Zerlegung des Projektes in kleine modulare Stücke, die das Projekt überschaubar machen. Bei jedem der genannten Strukturpläne liegt der Fokus anderswo. Der Produktstrukturplan beschäftigt sich mit der technischen Gliederung, der Projektstrukturplan mit den Beziehungen zwischen den Projektelementen und der Kostenstrukturplan mit den Kosten und deren Zusammenstellung.

Die Projektsteuerung bildet die Gruppe an Tätigkeiten, die sich zwischen der Projektplanung und der Durchführung einzelner Aktivitäten befindet. Um ein Projekt gut steuern zu können, bedarf es an viel Erfahrung und Fertigkeiten seitens des Projektleiters. Er muss gefühlsvoll auf die Änderungen innerhalb möglichst kurzer Frist reagieren. Zu den Maßnahmen zählen unter Anderem: Anordnen, Motivieren, Förderungen und ständige Qualitätsüberwachung. Die Koordination aller Tätigkeiten vor Allem im Bezug auf den Arbeitsaufwand ist ebenfalls ein wichtiger Bestandteil der Arbeit eines Projektleiters.

Bei Softwareprojekten ist es besonders kritisch, Fehlern sobald wie möglich auf die Spur zu kommen. Die folgende Grafik zeigt die Abhängigkeit des Kostenfaktors von der Zeit bzw. Projektphase. Zu beachten ist, dass die Skala logarithmisch und nicht linear ist.

Die wichtigste Aufgabe der Projektüberwachung und der Projektkontrolle ist daher die frühzeitige Fehlererkennung und Fehlerbeseitigung. Im Bezug auf das Projektmanagement definiert Jenny 2001 die folgenden sechs Kontrollbereiche:

- Terminkontrolle
- Aufwand- und Kostenkontrolle
- Sachfortschrittskontrolle
- Qualitätsprüfungskontrolle
- Dokumentationskontrolle
- Informationskontrolle

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Kosten der Fehlerbehebung (nach der Quelle: Jenny 2001, S 303)

Die Kontrollen können dann auf unterschiedliche Art und Weise durchgeführt werden. Typisch sind Audits, formelle oder informelle Reviews, Walkthroughs, Inspektionen oder Ratings.

(Quelle: Jenny 2001, S 197 ff)

2.3 Instrumentelles Projektmanagement

Instrumentelles Projektmanagement beschäftigt sich mit Techniken und Methoden, die beim Projektmanagementprozess verwendet werden können. An erster Stelle sind es die Planungstechniken und Aufwandschätzverfahren. Die Kontroll- und vor Allem die Führungstechniken werden im Unternehmen allgemein angewandt, sind also keine projektmanagementspezifischen Techniken und werden somit in diesem Kapitel nicht erörtert. Bei ihnen geht es um Audits, Reviews, Präsentationstechniken, Moderationen, Konfliktmanagement und Kommunikationstechniken. Projektmanagementspezifisch sind Planungstechniken und Aufwandschätzverfahren, deren Vertreter im Folgenden in Kürze beschrieben werden.

Netzplan

Der Netzplan ist ein hilfreiches Planungsinstrument, mit welchem die Abfolge von aufeinander folgenden Tätigkeiten grafisch dargestellt werden kann. Zu den bedeutendsten Arten gehören Critical Path Method (CPM), Program Evaluation and Review Technic (PERT) und Metra-Potential-Method (MPM). Die grafische Darstellung ist bei allen ähnlich, verwendet wird ein gerichteter Graph. Die Knoten symbolisieren Ereignisse, die einen konkreten Zustand beschreiben und werden als Kreise oder Vierecke dargestellt. Die Kanten symbolisieren Tätigkeiten, die zwischen zwei Ereignissen durchgeführt werden. Diese Tätigkeiten werden auch Vorgänge genannt. Ein Vorgang kann erst dann beginnen, wenn alle vorigen Vorgänge abgeschlossen sind. Jeder Vorgang läuft nur einmal ab, Schleifen werden nicht erlaubt. Die parallele Durchführung von Vorgängen darf stattfinden, daher kann es passieren, dass voneinander abhängige Vorgänge zu unterschiedlichen Zeitpunkten fertig gestellt werden. Die Abfolge von Vorgängen, deren Verlängerung die Verlängerung des gesamten Projektes bedeutet, wird im Kontext der Netzplanerstellung „kritischer Pfad“ genannt.

Balkendiagramm

Das Balkendiagramm ist eine zweidimensionale Darstellung, in der die Zeit auf einer Seite und Sachmittel, Aufgabenträger oder Tätigkeiten auf der anderen gegenüber gestellt werden. Je nach dem welche Größe sich auf der Y-Achse befindet, sprechen wir von dem Belegungsplan, Einsatzplan oder Tätigkeitsplan. Die Größe des Balkens bestimmt die in Anspruch zu nehmende Zeit, zusätzlich kann direkt beim Balken noch eine dritte Dimension erfasst werden. Balkendiagramme sind wegen ihrer Übersichtlichkeit beliebt und werden manchmal nach ihrem Entwickler auch Gantt-Diagramme genannt.

Delphiverfahren

Das Delphiverfahren ist eine Aufwandschätzmethode, deren Prinzip darin besteht, die in durchgeführten Projekten gewonnene Erfahrung in den neuen Projekten einzusetzen. Zum Projektvorhaben werden Experten befragt, die zu den einzelnen Arbeitspaketen ihre Schätzwerte eintragen. Sollten sich diese viel zu viel voneinander unterscheiden, werden die betroffenen Arbeitspakete tiefer gehend erörtert. Dies wird solange wiederholt bis der Projektleiter ein für ihn annehmbares Ergebnis bekommt. Das endgültige Schätzergebnis ergibt sich aus dem Durchschnitt der von den Experten gelieferten Schätzergebnissen.

Beta-Methode

Bei der Beta-Methode werden für jedes Arbeitspaket drei Zeitwerte geschätzt. Der erste Wert ist die optimistische Dauer, der zweite die häufigste Dauer und der dritte die pessimistische Dauer. Die geschätzte Durchschnittsdauer ist der Mittelwert der drei Zeitwerte, wobei die häufigste Dauer mit dem Faktor 4 in die Berechnung einfließt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Beta-Methode Formel

Die Beta-Methode wird vor allem bei innovativen Projekten verwendet, damit die Unsicherheiten, mit denen das Projekt behaftet ist, auch in die Berechnung einfließen.

Function-Point-Methode

Die Function-Point-Methode ist eine Aufwandschätzmethode, die von IBM entwickelt wurde. Die Vorgehensweise besteht aus fünf Schritten. Im ersten Schritt werden alle Arbeitspakete einer der folgenden Funktionsarten zugeordnet:

- Eingabedaten
- Ausgabedaten
- Abfragen
- Anwenderdateien
- Referenzdateien

Im zweiten Schritt wird in jeder Funktionsart eine Unterteilung in drei Komplexitätskategorien (einfach, mittel, komplex) vorgenommen, die Ergebnisse werden folglich mit einem gegebenen Faktor multipliziert. Im dritten Schritt werden die Einflussfaktoren erörtert und auf der Skala von 0 bis 5 bewertet. Im vierten Schritt werden die Ergebnisse aus den Schritten zwei und drei zusammengerechnet. Der fünfte Schritt dient der Überleitung der errechneten Werte in Personenmonate.

Kostenvergleichs-, Rentabilitäts- und Amortisationsrechnung

Zu den Methoden und Techniken, die beim Projektmanagement verwendet werden, zählen auch die allgemeinen betriebswirtschaftlichen Kennzahlen. Mit ihrer Hilfe können Systeme kostenmäßig verglichen werden, der wirtschaftliche Erfolg oder der Rückfluss von Investitionen in Projekte kann errechnet werden.

(Quelle: Jenny 2001, S 335 ff)

Die Aufteilung, wie sie in Jenny 2001 präsentiert wird, ist sehr umfangreich. Für den Aufbau von großen betrieblichen Informationssystemen kann man sich sehr wohl an der beschriebenen Systematik orientieren, für kleinere Projekte könnte sie manchen Projektmanagern zu komplex erscheinen. Die Konzentration auf das Wesentliche ist die primäre Eigenschaft der Agilen Methoden, die im Abschnitt 2.4 beschrieben werden.

2.4 Verwandte Ansätze

Das Projektmanagement hat viele verwandte Ansätze. An dieser Stelle möchte ich die folgenden erwähnen:

- Projektprogrammmanagement
- Multiprojektmanagement
- Projektportfoliomanagement

Die Aufgabe des Projektprogrammmanagements ist die Koordination von mehreren Projekten, die ein gemeinsames Ziel verfolgen. Dies können äußerst komplexe Vorhaben sein, wie zum Beispiel der Bau einer Autobahn oder eines Flughafens.

Die Aufgabe des Multiprojektmanagements ist die Steuerung und Koordination aller laufenden Projekte im Unternehmen. Der Multiprojektmanager entscheidet über die Strategie, Kosten, Zeit und die Zuteilung von Ressourcen.

Das Projektportfoliomanagement ist eine Teilaufgabe des Multiprojektmanagements, es zeigt Projekte aus unterschiedlichen Sichten. Die meist angewandte Sicht ist die Controllingsicht. Die Aufgabe des Projektportfoliomanagements besteht vor Allem darin, die richtigen Projekte auszuwählen und somit eine höhere Effektivität zu fördern.

(Quellen: PM/GT, Wikipedia)

3 Unified Process

Der Unified Process ist ein Softwareentwicklungsprozess (bzw. ein Methodenframework), der eine Sammlung an Best Practices beinhaltet, die darüber Aussage treffen, wie bei der Softwareentwicklung vorgegangen werden kann. Er erlaubt Organisationen, sich an seinem reichen Angebot an Werkzeugen zu bedienen und erfordert die Anpassung an die spezifischen Anforderungen des durchgeführten Projektes. Kruchten 2001 definiert die folgenden Best Practices:

- iterative Entwicklung
- Anforderungsmanagement
- Verwendung der komponentenbasierten Architektur
- graphische Softwarevisualisierung
- laufende Qualitätsprüfung
- Steuerung von Softwareänderungen

Der Unified Process wurde in der Firma Rational Software entwickelt. Bevor er seinen heute bekannten Namen erhielt, wurden einige Vorgängermodelle entwickelt. Erst die Version 5.0 erhielt 1998 den Namen Rational Unified Process. Entwickelt wurde er von Ivar Jacobson, der Hauptarchitekt war Philippe Kruchten. Der Unified Process hat eine präzise definierte Struktur und wird mit Hilfe des objektorientierten Ansatzes beschrieben. Er wird auf mehreren Prinzipien aufgebaut:

- Anwendungsfälle: Um die Anforderungen richtig interpretieren zu können, verwendet Unified Process die graphische Modellierungssprache UML. UML bietet systematische und intuitive Mittel zur Erfassung von funktionalen Anforderungen (Quelle: Jacobson 1999, S 37). Seine definierten graphischen Elemente ermöglichen ein besseres Verständnis zwischen der geschäftlichen und der technischen Welt.
- Architektur im Zentrum der Planung: Eine Systemarchitektur wird benötigt, um ein System zu verstehen, die Entwicklung zu organisieren und die Wiederverwendung von Komponenten anzustreben. Deshalb ist es von großer Bedeutung, zu Beginn der Entwicklung eine Architektur Schritt nach Schritt aufzubauen. Zuerst müssen die systemspezifischen Merkmale bedacht werden, sei es das Betriebssystem, auf dem die Software laufen soll, oder das Datenbankmanagementsystem, das die Daten speichert. Anschließend können die Anwendungsfälle der Wichtigkeit nach integriert werden. Sie sollten als eigene Subsysteme bedacht und entwickelt werden.
- Inkrementelles und iteratives Vorgehen: Dieses Vorgehen erlaubt durch seine Art und Weise die frühzeitige Erkennung von Risiken. Es teilt das Projekt in Iterationen die durchaus als Miniprojekte angesehen werden können. Während jeder Iteration werden ausgewählte Anwendungsfälle analysiert, entworfen, implementiert und getestet. Das Ergebnis der Iteration heißt Inkrement.

(Quellen: Jacobson 1999, Kruchten 2001)

Der Unified Process kann aus zwei Sichten betrachtet werden. Die erste Sicht ist die Entwicklungssicht. Sie beinhaltet Kerndisziplinen wie Geschäftsprozessmodellierung, Anforderungsanalyse, Analyse und Design, Implementierung, Testen und Verteilung und begleitende Disziplinen wie das Konfigurationsmanagement, das Projektmanagement und die Entwicklungsumgebung. Die zweite Sicht ist die Managementsicht, welche den Unified Process in vier Workflows unterteilt. Dies sind Konzeption, Entwurf, Konstruktion und Übergabe. Graphisch könnte diese zweidimensionale Struktur wie folgt abgebildet werden:

Abbildung 6: Rational Unified Process (nach der Quelle: Agility kompakt 2004, S 81)

Entwicklungssicht

Der Unified Process konzentriert sich auf drei Konzepte: Rollen, Aktivitäten und Ergebnisse. Aktivitäten und Ergebnisse werden Disziplinen genannt und aus der Entwicklungssicht beschrieben. In jeder Iteration werden verschiedene Tätigkeiten durchgeführt und es hängt sehr stark von der Phase des Projektes ab, in welcher Intensität sie durchgeführt werden. Tätigkeiten wie Geschäftsprozessmodellierung und Anforderungsanalyse werden vor Allem zu Beginn des Projektes verstärkt durchgeführt, weil sie ermöglichen, die Anforderungen des Kunden besser zu verstehen. Gerade die Geschäftsprozessmodellierung bildet mit Hilfe von UML eine Brücke zwischen der Geschäfts- und Softwareentwicklung, da sie über ein besonders reiches Angebot an Werkzeugen verfügt. Dieser können sich die Entwickler und Projektmanager je nach Projektart bedienen. Die Analyse, die Implementierung, das Testen und die Verteilung sind gewöhnliche Softwareentwicklungstätigkeiten, die auch im UML eine Unterstützung finden, allerdings nicht in dem Ausmaß, wie es bei der Geschäftsprozessmodellierung und der Anforderungsanalyse der Fall ist.

Managementsicht

In jeder Iteration werden alle Disziplinen zu einem gewissen Anteil durchgeführt. Das Ziel jeder Iteration ist die qualitative Bewertung der gelieferten Ergebnisse. Sie sollen geeignet für die weitere Vorgehensweise und die damit verbundenen Entscheidungen sein. Am Ende der Konzeptionsphase soll unter allen Stakeholdern das allgemeine Verständnis über Anforderungen und Klarheit über die Ziele herrschen. Die Systemgrenzen müssen definiert werden, ein erster Architekturvorschlag wird erstellt und es muss entschieden werden, ob es überhaupt zu einem Projekt kommt. In der Entwurfsphase wird die tragfähige Architektur definiert, die Anwendungsfälle werden nahezu vollständig entwickelt, der Gesamtprojektplan wird erstellt. Es ist noch immer Zeit zu entscheiden, ob das Projekt umgesetzt oder abgebrochen wird. Die Konstruktionsphase der Softwareentwicklung ist die Phase, in der die Architektur stabilisiert und die meiste Entwicklungsarbeit geleistet wird. Während dieser Phase erhält man nach dem Ablauf von Iterationen die ersten extern präsentierbaren Ergebnisse. In der Übergabephase wird der Endbenutzer mit dem System konfrontiert. Der Endbenutzer – in dieser Phase auch Betatester genannt – überprüft, ob das System seinen Anforderungen entspricht. Ist dies der Fall, so ist der Entwicklungszyklus abgeschlossen.

(Quellen: Jacobson 1999, Kruchten 2001Kruchten 1999, Essigkrug 2007, Agility kompakt 2004, Wikipedia)

4 Agile Methoden

Um die Jahrtausendwende sind einige Bücher erschienen, die die Prozesse beim Projektmanagement anders als es bislang üblich war angesehen haben. Die beschriebenen Werte waren so ähnlich, dass sich 2001 die Autoren entschieden, sich zum Ideenaustausch zu treffen. Das Treffen fand im US Staat Utah statt. In gemütlicher Atmosphäre haben viele Gespräche stattgefunden und am Ende konnten sich die Autoren einigen, dass

- Menschen und Zusammenarbeit mehr als Prozesse und Werkzeuge,
- lauffähige Software mehr als umfangreiche Dokumentation,
- Zusammenarbeit mit Auftraggebern mehr als Vertragsverhandlungen und
- Reagieren auf Änderungen mehr als das sture Befolgen eines Plans

bedeuten. Die herkömmliche Definition dieser Werte ist auf der Webseite zum Agile Manifesto zu finden. Um ihrem Vorhaben an Wichtigkeit zu geben, haben die Autoren die Agile Alliance (http://www.agilealliance.org) gegründet. Dieser Allianz können sich alle Sympathisanten anschließen. Zur Zeit der Erfassung dieser Arbeit hatte die Allianz 2700 unterstützende Mitglieder.

Vergleicht man die erwähnten Werte miteinander, stellt man fest, dass es hier um keine kleinen Änderungsvorschläge zur Softwareentwicklung selbst geht, sondern eher um die Änderung der Softwareentwicklungsphilosophie. Die Glaubwürdigkeit dieser Philosophie wird dadurch erhöht, dass alle Mitgründer der Agile Alliance nicht nur viele Erfahrungen in Softwareprojekten gesammelt haben, sondern sie sammeln diese Erfahrungen immer noch. Somit wird gewährleistet, dass die präsentierten Erfahrungen sehr aktuell sind. Die Werte der Agilität repräsentieren Gedanken, Erfahrungen und Wissen der Autoren über die Projektentwicklung.

Die Grundsätze der Agilität können im gesamten Projektentwicklungsprozess verfolgt werden:

- bei der Systemanalyse
- bei der Architektur
- bei der Programmierung
- bei der Dokumentation
- im Projektmanagement selbst
- in der Organisation

(Quellen: Cockburn 2003, Agility kompakt 2004, S 1 ff)

Agile Systemanalyse

Das Ziel der Systemanalyse ist das gemeinsame Verständnis der Problematik und die angemessene Erfassung dieser Informationen. Wichtig ist, dass alle Stakeholder auf dem gleichen Informationslevel sind. Um dies zu erreichen gibt es viele Möglichkeiten (Brainstorming, Mindmapping, Apprenticing, Fragebögen, Interviews, usw.). Leider ist keine dieser Methoden universal einsetzbar, denn Projekte sind verschieden, jedes hat andere Rahmenbedingungen, beim jedem sind andere Menschen beteiligt. Deswegen ist es wichtig, zuerst die menschlichen Einflussfaktoren, die organisatorischen Randbedingungen und den fachlichen Inhalt zu überprüfen und erst dann die Methodenwahl zu treffen. Die Matrix, welche Methoden für welche Einflussfaktoren in Frage kommen, ist auf der Webseite http://www.sophist.de zu finden.

Zur Dokumentation von Anforderungen können unterschiedliche Dokumentationstechniken verwendet werden. Das Prinzip der Agilität gibt den Entwicklern die Freiheit, bei jedem Projekt die passende Dokumentationstechnik zu wählen. Vorschriften sollte es hier keine geben.

Damit man bei der Dokumentation nicht mit „Papier“ überflutet wird, sollte man sich an die folgenden Regeln halten:

- jedes Dokument kann einer Lesergruppe zugeordnet werden
- jedes Dokument besitzt einen Sponsor
- es gibt keine konkurrierende Dokumentationsart
- jedes Dokument wird in seiner Art explizit benötigt

(Quelle: Agility kompakt 2004, S 13 ff)

Abbildung 7: Dokumentationstechniken (nach der Quelle: Agility kompakt 2004, S 16)

Agile Architektur

Die Architektur von Systemen wird geschaffen, um Stabilität und Flexibilität zu gewährleisten. Diese zwei Begriffe stehen gegensätzlich zueinander, es bedarf an sehr viel Feingefühl, sie im Gleichgewicht zu halten. Um es zu erreichen, müssen zu Beginn der Architekturschaffung Fragen wie „Was ist die Aufgabe des Systems?“, „Wer sind die Benutzer?“, „Welche Schnittstellen gibt es?“, „Wie werden Daten verwaltet?“ beantwortet werden. Die Beantwortung dieser Fragen ermöglicht die Unterteilung des Gesamtsystems in Subsysteme, was wiederum eine bessere Beherrschung hochkomplexer Systeme ermöglicht. Die Beschreibung einer Architektur muss angemessen sein, für jeden Sponsor sollte eine eigene Sicht erstellt werden.

Beim Softwaredesign müssen ebenfalls einige Grundsätze beachtet werden. Jede Klasse soll genau eine Aufgabe übernehmen, alle Komponenten sollen offen für Erweiterungen, geschlossen für Änderungen sein. Die Schnittstellen sollten nach dem Bedarf der Clients erstellt werden, denn die Clients sind der Grund, warum sie entwickelt werden. Komponenten sollten so entwickelt werden, damit sie wiederverwendet werden können.

(Quelle: Agility kompakt 2004, S20 ff)

Agile Programmierung

Die Einhaltung der Softwaredesigngrundsätze bietet viel Flexibilität bei Änderungen. Änderungen sind bei allen Softwareprojekten gegeben – dessen muss sich jeder bewusst sein und gleichzeitig darauf achten,

- dass Feedbacks durch kurze Iterationen frühzeitig eingeholt werden. Durch das regelmäßige und häufige Testen können Änderungen rasch umgesetzt werden;
- dass ergebnisorientiert entwickelt wird. Ohne einen funktionierenden Quellcode sind Zwischenergebnisse von sehr niedriger Bedeutung;
- dass bei Änderungen mutig vorgegangen wird. Vor allem dann, wenn funktionierende Codeteile ersetzt werden müssen;
- dass diszipliniert beim Entwickeln vorgegangen wird. Programmierstandards sollten eingehalten werden;
- dass Wiederholungen vermieden werden;
- dass so oft wie möglich geschätzt und gemessen wird. Häufiges Schätzen macht die zukünftigen Schätzungen immer genauer;
- dass nur hohe Qualität akzeptiert wird.

(Quelle: Agility kompakt 2004, S 29 ff)

Agile Dokumentation

Obwohl es im ersten Moment den Anschein haben könnte, dass das Dokumentieren beim agilen Vorgehen keine Bedeutung hat, trifft es nicht zu. Dokumentieren ist wichtig, jedoch müssen einige Regeln eingehalten werden. Die Angemessenheit als eines der Prinzipien des agilen Vorgehens sagt:

„So wenig Dokumentation wie möglich, aber soviel wie nötig.“ (Quelle: Agility kompakt 2004, S 33)

Weiters soll nicht erfasst werden, wie Dinge umgesetzt wurden, sondern warum sie umgesetzt wurden. Redundanzfreiheit ist beim agilen Vorgehen ein Muss, Dokumente sollten für die einzelnen Sponsoren, jeweils aus ihrer Sicht erstellt werden.

(Quelle: Agility kompakt 2004, S 33 ff)

Agiles Projektmanagement

Es ist nicht ausreichend, bei der Systemanalyse, der Architektur, der Programmierung und der Dokumentation agil vorzugehen. Für das Management gelten auch gewisse Regeln, welche eingehalten werden müssen, um bei agilen Projekten Erfolg zu haben. Werte wie Kommunikation, Änderungsakzeptanz, Vertrauen, Risikomanagement und Angemessenheit entsprechen dem agilen Vorgehen viel mehr als Berichterstattung, stures Befolgen von Plänen, Krisenbewältigung oder extremes Handeln. Um diese Werte zu erreichen, ist es immer gut das durchzuführende Projekt zuerst zu charakterisieren. Eigenschaften wie die Größe, Komplexität, Laufzeit, Umfang und Bekanntheitsgrad müssen in Betracht gezogen werden. Nach der Bewertung dieser Eigenschaften können die angemessene Vorgehensweise und die einzusetzenden Maßnahmen ausgewählt werden. Bei einem kleineren Projekt reicht eine kurze und schnelle Zielfindung, eine einfache Planung und flexible Arbeitszuordnung aus. Ein komplexeres Projekt bedarf einer tieferen Anforderungsanalyse, iterativen Planung und Entwicklung und einer definierten Form der Kommunikation. Dies sind aber nur Beispiele die aussagen sollen, dass die eingesetzten Maßnahmen angemessen sein sollten.

Nicht zu vergessen ist das Risikomanagement. Der Projektmanager muss die unterschiedlichen Risiken im Projekt identifizieren können und diese beseitigen, minimieren, bzw. Korrekturmaßnahmen vorbereiten. Je nach dem befolgt der Projektmanager die Strategie der Risikovermeidung, die Strategie der Risikominimierung oder die Strategie der Risikoakzeptanz.

Einer der wichtigsten Grundsätze im agilen Projektmanagement ist die Konzentration auf das Notwendige, nicht die Nutzung des Möglichen. Weiters sollten klare Ziele definiert und gefordert werden, es soll in Iterationen geplant und entwickelt werden, Risiken sollten ernst genommen werden, auf die Qualität soll geachtet werden und es soll viel Zeit in die Projektkultur investiert werden.

(Quelle: Agility kompakt 2004, S 35 ff)

Agile Organisation

Die agile Organisation entsteht aufgrund des agilen Vorgehens in Projekten, da die Informationsflüsse zwischen dem Auftraggeber und dem Entwickler auf der agilen Basis laufen. Um die Agilität in Organisationen zu unterstützen wird empfohlen zwei Prinzipien einzuhalten. Das Marktprinzip besagt, dass die einzelnen Organisationseinheiten in Unternehmen wie alleinstehende Einheiten agieren sollten. Bei diesem Ansatz erhalten sie mehr Verantwortung, welche unter anderem auch die Kreativität fördert. Kleinere Einheiten benötigen weniger Steuerungs- und Controllingmaßnahmen, was ihnen erlaubt sich nur auf die wesentlichen Dinge zu konzentrieren. Die hierarchische und berichtsorientierte Organisationsform wird somit ersetzt. Das zweite Prinzip – das Netzwerkprinzip – besagt, dass diese allein stehenden Einheiten sich spezialisieren sollten und sich aufeinander verlassen können sollten. Zwischen diesen Einheiten entsteht dann eine enge Kooperation und dadurch eine Wertschöpfungskette, welche die agile Alternative der Organisationsform darstellt.

Das in Agility kompakt 2004 vorgestellte Referenzmodell für agile Organisationen enthält vier Prozessgruppen, die wie folgt beschrieben sind:

- Strategie – enthält die Prozesse, die das Unternehmen wesentlich prägen. Es sind vor allem unterschiedliche Strategien und Visionen
- Beziehungsmanagement – enthält die Prozesse, die die Beziehungen zwischen dem Kunden und dem Unternehmen, zwischen dem Unternehmen und den Partnern und auch zwischen den einzelnen Unternehmenseinheiten (im Sinne vom Marktprinzip) pflegen.
- Innovationsmanagement – enthält die Prozesse, die mit der Bewertung und Einführung von technologischen aber auch organisatorischen Innovationen zu tun haben.
- Wissensmanagement – enthält die Prozesse, die für die Wissensaneignung und den Wissenstransfer zuständig sind.

(Quelle: Agility kompakt 2004, S 44)

In den folgenden Kapiteln werden Methoden vorgestellt, die die Basis für die Idee der Agilität gebildet haben. Ihre Autoren gehören in die Gruppe der Mitgründer der Agile Alliance. Die wahrscheinlich am meisten besprochene Methode ist Extreme Programming. Sie war eine der ersten die erschienen sind, wobei sie nicht die einzige ist, die von der Feder von Kent Beck stammt.

4.1 Crystal Methoden

Der Entwickler von Crystal Methoden heißt Alistair Cockburn und ist einer der Mitgründer der Agile Alliance. Er stellt bei seinem Modell die Menschen an die zentrale Stelle.

„Das Team, gute Zusammenarbeit, vertrauensvolle Kommunikation, die Gemeinschaft, Talente und Fähigkeiten aller Beteiligten sind der Schlüssel zum Projekterfolg.“ (Quelle: Agility kompakt 2004 , S 53)

Die betrieblichen Standardverfahren und Standardprozesse sind dabei im Hintergrund. Cockburn ist der Überzeugung, dass die Prozesse den Menschen angepasst gehören, anstatt dass sich die Menschen an die Prozesse gewöhnen und diese befolgen. Das Hauptziel sei ein funktionierendes Ergebnis, denn ohne dieses sind alle Zwischenergebnisse sinnlos. Zwischenergebnisse wie Analyse- oder Designdokumente sind auf jeden Fall dann bedeutend, wenn sie als Grundlage für die Entwicklung eines benachbarten Systems bzw. der Weiterentwicklung des vorhandenen Systems dienen.

Cockburn behauptet, dass jede Methode, unabhängig wozu sie dient, aus den folgenden 13 Kernelementen besteht: Prozesse, vorgegebene Meilensteine, Qualität, Aktivitäten, Produkte, Techniken, Standards, Werkzeuge, Rollen, Teams, Fähigkeiten, Persönlichkeit und Teamwerte. Je nach der Komplexität jedes einzelnen Kernelementes unterteilt er die Methoden in leichte und schwere. Ist die Gesamtkomplexität hoch, handelt es sich um eine schwere Methode. Ist sie niedrig, geht es um eine leichte Methode. Er hat festgestellt, dass die traditionellen Methoden bei den Kernelementen überwiegend über die Gestaltung der Prozesse sprechen. Seiner Meinung nach sollten aber die menschlichen Aspekte im Vordergrund stehen.

Ohne vordefinierte Prozesse kommt man jedoch nicht aus. Bei der Definition sollte man allerdings vorsichtig vorgehen und sie gerade eben ausreichend definieren. Es ergibt nämlich wenig Sinn, unzählige Rollen bei einem Projekt zu definieren, wenn diese nicht benötigt werden. Genau das Gleiche gilt auch für die erstellten Zwischenergebnisse. Laut Cockburn gilt:

„Je besser die Kommunikation untereinander funktioniert und je öfter und schneller das Hauptziel in Projekten erreicht wird, desto mehr kann man die Anzahl und Formalität von Zwischenergebnissen reduzieren.“ (Quelle: Agility kompakt 2004 S 55)

(Quellen: Cockburn 2005, Agility kompakt 2004, S 53 ff)

Abbildung 8: Vergleich von Aspekten (nach der Quelle: Agility kompakt 2004, S 55)

4.2 Adaptive Software Development

Adaptive Software Development (ASD) ist ebenfalls eher eine Philosophie als eine Methode. Ihr Autor und Entwickler Jim Highsmith versucht nicht Aktivitäten und Phasen vorzuschlagen, denn er behauptet, nichts sei beständiger als der Wandel. Damit sollten sich die Projektzuständigen abfinden und anstatt zu versuchen alles vorherzusehen und zu planen, sollten sie versuchen aus dem Änderungsprozess zu lernen und die erlernten Erfahrungen beim Wandel richtig einzusetzen.

Ein zentraler Punkt von ASD ist der Lebenszyklus, der die folgenden Eigenschaften aufweist:

- zielorientiert
- feature-basiert
- iterativ mit Time-Boxing
- risikogetrieben
- tolerant gegenüber Änderungen

Das Wesentliche bei ASD ist nicht das Befolgen eines Plans, sondern die Erreichung der Ziele. Am Ende jeder Iteration sollte eine weitere Funktionalität zur Verfügung stehen. Iterationen mit Time-Boxing könnten von den Entwicklern als eine unpopuläre Maßnahme angesehen werden. Laut ASD ist aber der Zweck von Time-Boxing nicht die Entwickler zu Überstunden zu zwingen, sondern sie dazu zu bringen, alle Entscheidungen schnell zu treffen und sie nicht aufzuschieben. Denn in einer änderungsreichen Umgebung ist durchaus möglich, dass aufgrund der Vielzahl von Änderungen kaum mehr Entscheidungen getroffen werden.

Die meisten traditionellen iterativen Vorgehensmodelle gehen von drei Phasen aus: Planen, Erstellen, Anpassen. ASD ersetzt

- Planen durch Spekulieren
- Erstellen durch Zusammenarbeiten und
- Anpassen durch Lernen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Phasen von ASD (nach der Quelle: Agility kompakt 2004 S 62)

Verständlicherweise reicht es nicht, das Vokabular anzupassen. Wichtig ist das Umdenken. Anstatt zu planen und einen Plan stur zu befolgen, sollte man sich damit abfinden, dass Vieles einfach nicht vorherzusehen ist. Deswegen sollte ein Projektmanager nur die Richtung vorgeben, Mitarbeiter motivieren und sich nicht vor Änderungen fürchten. Diese bieten oft eine Möglichkeit, neue innovative Wege einzuschlagen, welche oft einen Wettbewerbsvorteil mit sich bringen. Zusammenarbeiten im Sinne von ASD bedeutet ein aktives gemeinsames Schaffen von Ergebnissen. Voraussetzung dafür sind Offenheit, Vertrauen und gegenseitiger Respekt. Für das Lernen gilt:

„Lernende Organisationen zeichnen sich dadurch aus, dass sie in der Lage sind, ihre eigenen Fähigkeiten kritisch zu hinterfragen und die Annahmen hinter ihren Prozessen und Praktiken ständig zu überprüfen.“ (Quelle: Agility kompakt 2004 , S 64)

Laut ASD gilt dies auch für jede einzelne Iteration, da es kaum möglich ist alle Anforderungen mit 100%-iger Präzision zu definieren. Deswegen wird vorgeschlagen, am Ende jeder Iteration dem Kunden die Ergebnisse zu präsentieren um sich Änderungs- und Ergänzungsvorschläge einzuholen.

(Quellen: Highsmith 2000, Agility kompakt 2004, S 60 ff, Burke 1982)

4.3 Scrum

Scrum stellt einen Satz von Regeln vor, die eine Unterstützung bieten sollen, komplexe Projekte im Griff zu halten. Dieser Satz von Regeln wurde von Ken Schwaber, Jeff Sutherland und Mike Beedle definiert. Der Begriff selbst stammt aus der Sportwelt (Rugby) und versucht eine Parallele aufgrund der Ähnlichkeit des Verhaltens der Beteiligten zu erstellen.

Scrum ist ein iteratives Vorgehensmodell. Die Iterationen heißen Sprints. Jeder Sprint dauert 30 Tage. Dieser Zeitraum ist ein empfohlener Erfahrungswert, den man ohne Weiteres verkürzen oder verlängern kann. An jedem Sprint ist ein Team von Entwicklern beteiligt. Alle notwendigen Rollen sind im Team vertreten. Scrum kann man wie folgt abbilden:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Scrum Prozess (nach der Quelle: Agility kompakt 2004 S 68)

Im Produkt-Backlog werden alle Anforderungen und Wünsche gesammelt. Die Reihenfolge, in der sie abgearbeitet werden, wird dem Produkteigner überlassen. Diese Prioritätensetzung erfolgt bei der Sprintplanung. Die ausgewählten Anforderungen wandern in den Sprint-Backlog, wo gleichzeitig vom Team grob geschätzt wird, wie lange die Umsetzung dieser Anforderungen dauert. Eine grobe Schätzung ist hier ausreichend, weil sie nur dazu dient, um sich nicht viel zu viele Aufgaben für einen Sprint vorzunehmen. Die Aufgabenaufteilung liegt dann einzig und allein in der Verantwortung des Teams. Am Ende der Planungsphase wird ein Ziel des Sprints definiert. Meistens geht es um einen prägnant definierten Satz. Am Ende des Sprints wird nämlich nicht überprüft, ob die einzelnen Wünsche aus dem Sprint-Backlog erfüllt wurden, sondern ob die vorformulierten Ziele erfüllt wurden.

[...]

---

^[1] J. Kosmál, Fakultät für Informatik, Universität Wien
C. Steinringer, Faculty of Management, Comenius University in Bratislava