Anwendung von agilen Methoden im industriellen Umfeld

Inhaltsverzeichnis

Zusammenfassung

Danksagung

Abbildungsverzeichnis

1 Einleitung
1.1 Wandel in der Software-Entwicklung
1.2 Motivation, Vorgehen und Aufbau der Arbeit
1.2.1 Limitationen agiler Methoden
1.2.2 Definition von Projekten im industriellen Umfeld
1.2.3 Vorgehen und Aufbau der Arbeit
1.3 Stand der Wissenschaft
1.3.1 Barry Boehm und Richard Turner
1.3.2 Philippe Kruchten
1.3.3 Jutta Eckstein
1.3.4 Fazit

2 Agile Software-Entwicklung
2.1 Traditionelle Software-Entwicklung
2.2 Entstehung der agilen Bewegung
2.3 Das agile Manifest
2.3.1 Einführung
2.3.2 Die vier agilen Werte
2.3.3 Die zwölf agilen Prinzipien

3 Methoden der agilen Software-Entwicklung
3.1 Extreme Programming – XP
3.1.1 Die vier Werte von XP
3.1.1.1 Kommunikation
3.1.1.2 Einfachheit
3.1.1.3 Feedback
3.1.1.4 Courage
3.1.1.5 Verzahnung der einzelnen Werte
3.1.2 Praktiken
3.1.2.1 Planungsspiel
3.1.2.2 Kleine Release
3.1.2.3 Systemmetapher
3.1.2.4 Einfaches Design
3.1.2.5 Tests
3.1.2.6 Refaktorisierung
3.1.2.7 Programmieren in Paaren
3.1.2.8 Gemeinsames Eigentum am Code
3.1.2.9 Kontinuierliche Code-Integration
3.1.2.10 40-Stunden-Woche
3.1.2.11 Kundenvertreter im Team
3.1.2.12 Programmierrichtlinien
3.2 Scrum
3.2.1 Praktiken
3.2.1.1 Product Backlog
3.2.1.2 Daily Scrum Meeting
3.2.1.3 Sprint Planning Meeting
3.2.1.4 Sprint
3.2.1.5 Sprint Review Meeting

4 Problembereiche agiler Methoden im industriellen Umfeld und deren Lösung
4.1 Organisatorisches Umfeld und Kultur
4.1.1 Unternehmensweite Vorgehensweise
4.1.2 Organisationsstruktur
4.1.2.1 Projektplanung und -steuerung
4.1.2.2 Werkzeuge und Tools
4.1.2.3 Qualitätssicherung und -kontrolle
4.1.3 Kulturunterschiede
4.1.4 Vertragsgestaltung
4.2 Initialisierung des Projektes und Aufbau der Teamstruktur
4.2.1 Entwicklung eines Basissystems
4.2.2 Aufbau der Teamstruktur
4.2.3 Einbeziehung örtlich getrennter Teams
4.3 Beteiligung des Kunden
4.3.1 Kein expliziter Kunde pro Team
4.3.2 Unterschiedliche Kundeninteressen
4.3.3 Örtliche Trennung von Team und Kunde
4.4 Koordination des Projektes
4.4.1 Länge der Release- und Iterationszyklen
4.4.2 Iterationsplanung
4.4.3 Regelmäßige Abstimmung
4.4.4 Gesamtkoordination im Projekt
4.5 4.4.5 Codeverantwortlichkeit
4.4.6 Integration
4.4.7 Abhängigkeiten zu anderen Projekten Kommunikation der Beteiligten
4.5.1 Direkte Kommunikation
4.5.1.1 Besprechungen
4.5.1.2 Kommunikationsteam
4.5.1.3 Austausch von Teammitgliedern
4.5.2 Informelle Kommunikation
4.5.3 Kommunikationshilfsmittel

5 Analyse von Projekten
5.1 Projekt A
5.1.1 Organisatorisches Umfeld und Kultur
5.1.2 Kunde
5.1.3 Methodisches Vorgehen
5.1.4 Koordination und Kommunikation
5.1.5 Lessons Learned
5.2 Projekt B
5.2.1 Organisatorisches Umfeld und Kultur
5.2.2 Kunde
5.2.3 Methodisches Vorgehen
5.2.4 Kommunikation und Koordination
5.2.5 Lessons Learned
5.3 Projekt C
5.3.1 Organisatorisches Umfeld und Kultur
5.3.2 Kunde
5.3.3 Methodisches Vorgehen
5.3.4 Koordination und Kommunikation
5.3.5 Lessons Learned
5.4 Projekt D
5.4.1 Organisatorisches Umfeld und Kultur
5.4.2 Kunde
5.4.3 Methodisches Vorgehen
5.4.4 Kommunikation und Koordination
5.4.5 Lessons Learned
Inhaltsverzeichnis VI
5.5 Projekt E
5.5.1 Organisatorisches Umfeld und Kultur
5.5.2 Kunde
5.5.3 Methodisches Vorgehen
5.5.4 Kommunikation und Koordination
5.5.5 Lessons Learned
5.6 Projekt F
5.6.1 Organisatorisches Umfeld und Kultur
5.6.2 Kunde
5.6.3 Methodisches Vorgehen
5.6.4 Kommunikation und Koordination
5.6.5 Lessons Learned
5.7 Fazit
5.7.1 Organisatorisches Umfeld und Kultur
5.7.2 Kunde
5.7.3 Methodisches Vorgehen
5.7.4 Kommunikation und Koordination

6 Theorie vs. Praxis
6.1 Organisatorisches Umfeld und Kultur
6.2 Initialisierung des Projektes und Aufbau der Teamstruktur
6.3 Beteiligung des Kunden
6.4 Koordination des Projektes
6.5 Kommunikation der Beteiligten
6.6 Fazit

7 Schlussbetrachtungen
7.1 Fazit
7.2 Zukünftiger Forschungsbedarf

8 Literaturverzeichnis

A Anhang
A.1 Extreme Programming
A.1.1 Extreme Programming - Prozess
A.1.2 Extreme Programming - Rollen und Verantwortlichkeiten
A.2 Scrum
A.2.1 Scrum - Prozess
A.2.2 Scrum - Rollen und Verantwortlichkeiten
A.3 Die agilen Prinzipien
A.4 Fragebogen
A.5 Interviewleitfaden

Zusammenfassung

Software wird meist anhand von Prozessen und Methoden entwickelt, die die Vorgehensweise und Praktiken bei der Entwicklung beschreiben.

In den letzten Jahren traten agile Methoden ins Rampenlicht der Software-Entwicklung. Ihr Hauptaugenmerk liegt im Gegensatz zu den traditionellen Methoden

- auf Menschen und deren Zusammenarbeit,
- auf der Entwicklung lauffähiger Software in kurzen Iterationen,
- auf der intensiven Zusammenarbeit zwischen Entwickler und Auftraggeber und
- auf der Fähigkeit auf Änderungen der Anforderungen kurzfristig zu reagieren.

Agile Methoden eignen sich vor allem für den Einsatz in kleinen unabhängigen Projekten, deren Umfeld keine Vorgaben bezüglich der Vorgehensweise im Projekt macht.

Die vorliegende Arbeit beschäftigt sich mit der Frage, wie sich agile Methoden in industriellen Projekten einsetzen lassen und welche Beschränkungen und Erweiterungen der Methoden dabei bedacht werden müssen. Industrielle Projekte zeichnen sich dabei aus durch viele Beteiligte, mehrere Entwicklungsstandorte, Abhängigkeiten zu anderen Systemen oder Projekten, sowie einer Organisationsstruktur und Kultur, die nicht ideal für die Anwendung agiler Methoden ist.

Die Grundlage für die Beantwortung der zugrunde liegenden Fragestellung ist die Einführung in die agile Entwicklung und die Beschreibung der Methoden Scrum und Extreme Programming. Darauf folgend erörtert der Autor dieser Arbeit, welche Problembereiche sich theoretisch beim Einsatz von agilen Methoden im industriellen Umfeld ergeben können und welche Lösungen sich dazu anbieten. Hauptbestandteil der Arbeit ist die Analyse von Projekten aus dem industriellen Umfeld, die agile Methoden einsetzen. Interviews mit Projektbeteiligten zeigen auf, auf welche Probleme Projekte in der Praxis beim Einsatz agiler Methoden stoßen und wie sie diese zu lösen versuchen. Abschließend werden die theoretischen mit den praktischen Betrachtungen verglichen und allgemeingültige Schlüsse gezogen.

Danksagung

An dieser Stelle möchte ich allen danken, die mich bei dieser Arbeit unterstützt haben.

Besonderer Dank geht an Herrn Prof. Christian Märtin für die Übernahme der Betreuung meiner Diplomarbeit: Sie waren stets offen für Fragen und Probleme und unterstützten mich mit Kräften, was ich sehr zu schätzen weiß.

Herrn Prof. Wolfgang Kowarschick danke ich für die Übernahme der Zweitkorrektur meiner Arbeit.

Weiterhin möchte ich mich bei allen Kollegen von Siemens Corporate Technology Software & Engineering bedanken, die mich bei meiner Diplomarbeit unterstützt haben. In erster Linie bei meiner Betreuerin Frau Sabine Canditt.

Meinen Interviewpartnern Herr Rainer Bulling, Herr Jens Coldewey, Frau Jutta Eckstein, Herr Michael Egner, Herr Jiri Lundak, Herr Roman Pichler, Herr Gero Seifert und Frau Babette Spörl danke ich für ihre uneigennützige Unterstützung und für ihre Bereitschaft, mir immer wieder Rede und Antwort zu stehen. Ohne sie wäre diese Arbeit nicht möglich gewesen.

Insbesondere danke ich auch meiner Familie, die mir mein Studium ermöglicht hat und mich während dieser Zeit in jeglicher Hinsicht unterstützt hat. Nicht zuletzt gilt mein Dank Alex, Michael, Sonja und Zenzi für ihre tatkräftige Unterstützung.

Abbildungsverzeichnis

Abbildung 1: Abhängigkeiten zum Umfeld eines Teams

Abbildung 2: Einsetzbarkeit von Methoden

Abbildung 3: Entwicklung der Struktur im zeitlichen Ablauf

Abbildung 4: Das Wasserfallmodell

Abbildung 5: Das iterative Modell

Abbildung 6: Feedback in XP

Abbildung 7: Scrum-Praktiken und deren Zusammenspiel

Abbildung 8: Beispiel für einen Product Backlog

Abbildung 9: Komplexität durch viele Beteiligte

Abbildung 10: Struktur des Projektes B und des Gesamtprojektes

Abbildung 11: Struktur des Projektes D und des Gesamtprojektes

Abbildung 12: Struktur des Projektes E und der Organisation

Abbildung A1: XP – Prozess

Abbildung A2: Scrum - Prozess

1 Einleitung

1.1 Wandel in der Software-Entwicklung

Seit Jahren nimmt Software einen immer größer werdenden Teil unseres täglichen Lebens ein. Dies trifft nicht nur auf große Computersysteme zu, sondern selbst triviale technische Geräte werden heutzutage oft durch Software gesteuert oder kontrolliert. Die Entwicklung von Software geschieht meist anhand von Methoden, die das Vorgehen beschreiben. Bis zum heutigen Tag werden dazu in der Regel traditionelle Methoden, die oft auch „schwergewichtige“ Software-Entwicklungsmethoden genannt werden, eingesetzt. Diese starten mit dem Finden und ausgedehnten Dokumentieren der kompletten Anforderungen an das System, gefolgt von Design, Programmierung und Testen des zu entwickelnden Systems [Cohen03, 1].

Diese traditionellen Methoden versuchen den Entwicklungsprozess so zu definieren, dass er immer wieder auf die gleiche Art und Weise ausgeführt und somit Software von immer gleicher Qualität erzeugt werden kann. Die Anforderungen an das zu entwickelnde System werden bereits zu Beginn des Projektes festgelegt und die Software auf Grundlage dieser geplant und entwickelt. Dadurch sind Änderungen der Anforderungen, die erst spät in der Entwicklung bekannt werden, schwierig umzusetzen und verursachen nicht selten erheblichen Zusatzaufwand.

Aufgrund des sich schnell ändernden Marktes und vor allem bei Neuentwicklungen sind Kunden aber oft nicht in der Lage, Anforderungen bereits zu Beginn eines Projektes definitiv zu bestimmen. Außerdem gewinnen die Beteiligten erst im Laufe der Zeit Kenntnis und Verständnis des Problembereiches der Anwendung und können so die Relevanz der einzelnen Funktionen der Software besser einschätzen.

Zudem wird es immer wichtiger, schnell mit einem Produkt auf dem Markt zu erscheinen - zumindest schneller als die Mitbewerber. Auch wenn die erste Version nur eingeschränkte Funktionalität hat [Eckstein04, 1]. Heute entwickelte Systeme sind aufgrund der Interaktion verschiedener Disziplinen, wie zum Beispiel Mechanik, Hardware und Software, zunehmend komplexer. Dies führt wiederum zu einer schwierigen Planung des Systems und zu zunehmenden technischen Risiken. Bei den traditionellen Methoden erfolgt die technische Realisierung sehr spät im Entwicklungsprozess. Dadurch können die technischen Risiken oft erst zu diesem Zeitpunkt aufgedeckt werden und führen im schlimmsten Fall zum Abbruch des Projektes.

Mitte der 1990er Jahre entwickelten sich daher mehrere Ansätze, um diese veränderten Voraussetzungen zu bewältigen. Diese so genannten agilen Methoden sind oft eine Sammlung von Techniken und Praktiken und basieren auf der schrittweisen Entwicklung, sowie der häufigen Auslieferung von lauffähiger Software an den Kunden. So kann der Kunde bereits früh dem Entwicklungsteam Feedback geben und gegebenenfalls Anforderungen verändern. Die agilen Methoden zeichnen sich darüber hinaus durch ausgeprägte Kommunikation und Zusammenarbeit im Team, sowie zwischen Team und Kunde aus. Dadurch kann schnell auf Veränderungen reagiert werden und dem Kunden werden Lösungen für seine aktuellsten Probleme geliefert. Die zwei wohl populärsten Methoden im Bereich der agilen Software-Entwicklung sind Extreme Programming von Kent Beck und Scrum von Ken Schwaber und Mike Beedle [Shine03, 4].

Nach Abrahamsson et al. zeichnen sich agile Methoden durch die folgenden Eigenschaften aus [Abrahamsson02, 17]:

- Inkrementell: Inkrementelle Entwicklung der Software
- Kooperativ: Ausgeprägte Zusammenarbeit aller Projektbeteiligten
- Unkompliziert: Die Methoden sind leicht zu erlernen, leicht modifizierbar und gut dokumentiert
- Adaptiv: Änderungen der Anforderungen sind zu einem späten Zeitpunkt der Entwicklung möglich

1.2 Motivation, Vorgehen und Aufbau der Arbeit

1.2.1 Limitationen agiler Methoden

Agile Methoden haben aber auch einige Limitationen, die den Bereich ihrer Anwendbarkeit einschränken. Die wohl am weitesten reichende Limitation ist die Einschränkung auf kleine Teams, deren Mitglieder alle in unmittelbarer Nähe zueinander arbeiten sollten. Grund dafür ist die geforderte ausgeprägte Zusammenarbeit zwischen allen Projektbeteiligten, die vor allem aus der direkten Kommunikation von Person zu Person besteht. Laut Kent Beck eignet sich Extreme Programming für Teams mit bis zu circa zehn Entwicklern [Beck00, 157]. Ken

Schwaber gibt für Scrum eine ideale Teamgröße von nicht mehr als neun an [Schwaber02, 36]. In beiden Fällen sollten alle Teammitglieder am besten in einem einzigen großen Büro arbeiten.

Oft wird deshalb der Rat gegeben, Projektteams „gesund zu schrumpfen“. Zum Beispiel anstatt mit 100 verfügbaren Entwicklern das System nur mit 20 zu entwickeln. Damit entfällt viel Zusatzaufwand für die erforderliche Kommunikation und Abstimmung und die Produktivität der einzelnen Teammitglieder steigt. Es ist aber häufig nicht möglich, Projekte einfach zu verkleinern.

Oft ist es auch der Fall, dass Projektbeteiligte über mehrere Standorte verteilt sind, beziehungsweise mehrere Teams an verschiedenen Standorten beteiligt sind. Besonders größere Unternehmen sind heute global tätig. Zusätzlich führt der Kostendruck in der Software-Entwicklung zur Auslagerung von Teilen der Entwicklung in Länder mit niedrigeren Personalkosten, wie zum Beispiel Indien oder China.

Projekte sind häufig nicht völlig von ihrer Umgebung unabhängig. Beteiligte müssen eventuell mit anderen Projekten und Disziplinen, die womöglich eine traditionelle Vorgehensweise verwenden, zusammenarbeiten und sich mit ihnen synchronisieren. Ein Beispiel ist die nötige Synchronisation eines Softwareprojektes mit der Hardware-Entwicklung im Bereich von Mobiltelefonen oder die Verwendung bereits entwickelter Komponenten und Systeme. Letztlich sind Projekte auch von der sie umgebenden Organisation und deren Kultur abhängig. Vor allem große Unternehmen haben starre Strukturen und Regelungen beispielsweise zur Sicherung der Qualität, die den Einsatz von agilen Methoden oft schwierig machen. Sie unterteilen ihre Organisation meist nach Aufgabenbereichen, was im Gegensatz zu agilen Projekten steht. Im Projektteam sollten Spezialisten aller Aufgabenbereiche vertreten sein, die zur Lösung des Problems benötigt werden.

Abbildung 1 zeigt, dass Teams in einem Projekt keine Inseln sind, sondern dass vor allem in großen Unternehmen Abhängigkeiten zu anderen Teams im Projekt und zum Umfeld des Projektes bestehen.

Abbildung 1: Abhängigkeiten zum Umfeld eines Teams

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, modifiziert nach [Lindvall04, 30]

Das Konsortium, das die agile Methode DSDM¹ weiter entwickelt, listet eine Reihe von Projekten auf, in denen die Anwendung ihrer Methode problematisch ist [DSDM03, 22]. Diese Bereiche gelten auch für die Anwendung anderer agiler Methoden:

- Steuerungs- und Echtzeitsysteme: Die meisten Abläufe in solchen Systemen bleiben dem Anwender verborgen. Beispiele sind die Steuerung von Produktionsanlagen oder von Kraftwerken. Diese sind meist sehr komplex und lassen sich nicht in kleinere, weniger komplexe Systeme zerlegen.
- Sicherheitskritische Systeme: Systeme, die unter Umständen das Leben von Menschen gefährden, erfordern ausführliche Überprüfungen und Tests. Es ist deshalb fraglich, ob iterative Entwicklung für diese Art von Systemen vorteilhaft ist und ob agile Praktiken die besonderen Anforderungen bei der Entwicklung erfüllen können.
- Entwicklung wieder verwendbarer Komponenten: Die agile Entwicklung versucht, das aktuell vorliegende Problem unter Nichtbeachtung möglicher späterer Anforderungen zu lösen. Wieder verwendbare Komponenten erfordern hingegen eine Lösung, die für mehrere Probleme passt. Deshalb eignen sich agile Methoden für ihre Entwicklung nicht.

Es ist also nicht immer sinnvoll, traditionelle Methoden durch agile zu ersetzen. Es gibt keinen Ansatz, der sich für alle Projekte eignet. Sowohl agile als auch traditionelle Methoden passen am besten für nur eine bestimmte Art von Projekten. Abbildung 2 verdeutlicht dies graphisch. Mit traditionellen Methoden können am besten umfangreiche und komplexe Systeme entwickelt werden, solange die Anforderungen bereits zu Beginn bekannt sind und sich diese nicht mehr verändern. Auf der anderen Seite kommen agile Methoden mit Veränderungen der Anforderungen an das zu entwickelnde System während der Entwicklung besser zurecht. Sie eignen sich aber weniger bei komplexen und großen Systemen. Problematisch ist daher die Entwicklung von Systemen im Bereich der schwierigen Zone in Abbildung 2. Sie sind zum einen komplex und groß, unterliegen aber zugleich Veränderungen der Anforderungen während der Entwicklung.

Abbildung 2: Einsetzbarkeit von Methoden

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung, modifiziert nach [Känsälä04, 425]

Will man die Vorteile der agilen Methoden auch in Projekten nutzen, die theoretisch nicht ideal für ihre Anwendung sind, bleibt nur der Weg, die Methoden anzupassen beziehungsweise zu erweitern. Zu dieser Art von Projekten gehören beispielsweise industrielle Projekte. Ziel dieser Arbeit ist es deshalb, zu erforschen, wie agile Methoden angepasst und erweitert werden können, um auch industrielle Projekte erfolgreich mit ihnen zu entwickeln. Dies beschränkt sich nicht auf die Betrachtung einzelner agiler Methoden, sondern konzentriert sich auf eine mögliche Kombination von Praktiken verschiedener Methoden. Neben theoretischen Betrachtungen analysiert diese Arbeit auch Projekte aus der Praxis. Dazu werden Beteiligte interviewt, die agile Methoden in industriellen Projekten anwenden. Durch die Analyse ihrer Aussagen werden Erfolgs- und Misserfolgsfaktoren herausgestellt, die den Einsatz agiler Methoden fördern beziehungsweise behindern.

1.2.2 Definition von Projekten im industriellen Umfeld

Software-Projekte im industriellen Umfeld zeichnen sich zum einen durch ihre überdurchschnittliche Größe aus. Aber was ist ein überdurchschnittlich großes Projekt? Jutta Eckstein definiert Größe als eine Kombination aus Umfang, Dauer, Kosten, Personenanzahl und Risiken [Eckstein04, 3]. Diese einzelnen Faktoren sind wiederum teilweise voneinander abhängig. Hat ein Projekt einen großen Umfang, resultiert dies entweder in einer langen Dauer oder in einem größeren Bedarf von Beteiligten oder in beidem. Eine große Anzahl von Beteiligten kann wiederum die Kosten und die Dauer des Projektes beeinflussen, zum Beispiel bei ungeschulten Mitarbeitern, die zuerst ausgebildet werden müssen. Große Risiken können wiederum zu einer langen Dauer, einer hohen Personanzahl sowie hohen Kosten führen [Eckstein04, 2ff]. In dieser Arbeit wird deshalb als erstes Kriterium für industrielle Projekte eine hohe Anzahl von Beteiligten bestimmt.

In Projekten von global tätigen Unternehmen wird die in agilen Methoden geforderte Art der Kommunikation und Zusammenarbeit oft durch mehrere Entwicklungsstandorte erschwert. Das heißt, nicht alle Projektbeteiligte sind am gleichen Ort tätig, sondern oft über mehrere Zeitzonen hinweg getrennt. Auch die Organisationsstruktur und die Kultur großer Unternehmen sind selten auf agile Methoden ausgerichtet. So gibt es meist eigene Abteilungen für bestimmte Tätigkeiten. Dies ist in agilen Methoden nicht vorgesehen. Dazu zählen beispielsweise Abteilungen für die Qualitätssicherung, Werkzeugbeschaffung oder Systemtests. Des Weiteren zeichnen sich industrielle Projekte oft durch interdisziplinäre Arbeit aus. Es ist also eine Synchronisation notwendig oder das Projektteam muss sein zu entwickelndes System in ein größeres Rahmenprogramm einpassen. Die beteiligten Bereiche sind dadurch in ihren Entscheidungsmöglichkeiten eingeschränkt.

Zusammenfassend lässt sich also feststellen, dass sich industrielle Projekte durch folgende Eigenschaften auszeichnen. Es ist aber nicht notwendig, dass alle vier Kriterien erfüllt sind.

- Es sind viele Personen am Projekt beteiligt.
- Nicht alle Beteiligten im Projekt arbeiten am selben Ort.
- Die Organisationsstruktur und Kultur ist nicht auf den Einsatz agiler Methoden ausgerichtet.
- Es bestehen Abhängigkeiten, beziehungsweise notwendige Synchronisation zu anderen Disziplinen, Projekten oder Systemen.

1.2.3 Vorgehen und Aufbau der Arbeit

Im folgenden Kapitel werden die Gründe und die Geschichte der agilen Software-Entwicklung vertieft. Daneben stellt diese Arbeit die agilen Grundsätze, insbesondere das agile Manifest vor, und grenzt die agile von der traditionellen Vorgehensweise ab.

Das anschließende dritte Kapitel stellt die am häufigsten verwendeten agilen Methoden Extreme Programming und Scrum vor.

Problembereiche, die sich bei der Anwendung von agilen Methoden im industriellen Umfeld ergeben können werden im vierten Kapitel identifiziert. Mögliche Lösungen für diese Bereiche werden erarbeitet.

Das fünfte Kapitel untersucht mehrere Projekte, in denen agile Methoden zum Einsatz kamen. Grundlage der Untersuchung sind Interviews mit Beteiligten, deren Projekte einzeln analysiert und die agile Vorgehensweise, sowie mögliche Anpassungen und Erweiterungen beschrieben werden.

Das darauf folgende Kapitel vergleicht die theoretischen Betrachtungen aus dem vierten Kapitel mit den Ergebnissen der analysierten Projekte aus dem fünften Kapitel. Besonderes Augenmerk wird auf die Unterschiede gerichtet. Das heißt, welche Problembereiche aus den theoretischen Betrachtungen haben sich nicht bestätigt und welche zusätzlichen Probleme traten auf. Das gleiche gilt für die vorgeschlagenen, beziehungsweise tatsächlich verwendeten Problemlösungen in Theorie und Praxis.

Das Fazit der gesamten Arbeit und der Ausblick, der Vorschläge über das weitere Vorgehen in diesem Forschungsgebiet enthält, bilden den Abschluss dieser Arbeit.

1.3 Stand der Wissenschaft

In der Literatur gibt es mehrere Arbeiten, die sich mit dem Problem der Anwendbarkeit agiler Methoden in großen Organisationen und deren Skalierung befassen. Diese lassen sich in zwei Arten von Arbeiten unterscheiden: Ein Teil behandelt die agile Entwicklung im Generellen. Der andere Teil beschränkt sich auf spezielle agile Methoden, wie beispielsweise Extreme Programming. Die Veröffentlichungen „Balancing Agility and Discipline“ von Barry Boehm und Richard Turner [Boehm04], „Scaling down large projects to meet the agile sweet spot“ von Philippe Kruchten [Kruchten04] und „Agile Software Entwicklung im Großen“ von Jutta Eckstein [Eckstein04] haben für die vorliegende Arbeit die größte Relevanz. Die drei Werke geben meist nur allgemeine Ratschläge, wie agile Entwicklung in industriellen Projekten eingesetzt werden kann. Zwar werden große Projekte erwähnt, die agile Methoden eingesetzt haben, aber konkret untersucht werden diese nicht.

1.3.1 Barry Boehm und Richard Turner

Barry Boehm und Richard Turner argumentieren in ihrem Buch „Balancing Agility and Discipline“ [Boehm04], dass jede Art von Methode ihre Stärken und Schwächen hat. Sowohl traditionelle Methoden der Software-Entwicklung als auch die agilen Methoden haben nach Boehm und Turner aber nur für jeweils einen bestimmten Projekttyp große Vorteile. Außerdem benötigt jedes Projekt zum Erfolg ein gewisses Maß an Disziplin und ein gewisses Maß an Agilität. Es kommt demnach auf die Balance zwischen Disziplin und Agilität an. Boehm und Turner argumentieren, dass es eine Gruppe von Projekten mit spezifischem Umfeld gibt, in denen entweder die agile oder die traditionelle Entwicklung von Vorteil ist. Dafür sind die Charakteristiken des zu entwickelnden Systems, des Managements, der verwendeten Technologie sowie der beteiligten Persönlichkeiten ausschlaggebend. Für Projekte, für die teilweise die agile Entwicklung von Vorteil ist, aber auch in Teilen die traditionelle, schlagen sie eine Kombination der beiden Entwicklungsansätze vor. Damit sollen die jeweiligen Vorteile genutzt und die Nachteile vermieden werden.

Boehm und Turner stellen in einem Fallbeispiel vor, welche drei Praktiken von Extreme Programming verändert werden müssen, um diese Methode in großen Projekten erfolgreich einsetzen zu können. In einem zweiten Beispiel beschreiben sie, wie in einem Projekt des US Verteidigungsministeriums eine traditionelle Entwicklungsmethode durch einige agile Praktiken „aufgeweicht“ wurde.

1.3.2 Philippe Kruchten

Im Artikel „Scaling down large projects to meet the agile sweet spot“ [Kruchten04] stellt Philippe Kruchten seinen Ansatz vor, wie große Projekte mit verteilten Teams den Anforderungen agiler Methoden angepasst werden können. Er stellt dabei fest, dass es keinen Sinn macht, agile Methoden zu verändern. Stattdessen muss das Projekt so aufgeteilt werden, dass agile Methoden angewandt werden können. Er schlägt vor, mehrere kleine Teams zu bilden, wobei die jeweiligen Mitglieder an einem Ort arbeiten. Die Arbeit beginnt in nur einem agilen Team. Dieses erarbeitet die Grundlage für das zu entwickelnde System und entwickelt einen Prototyp für die Architektur. Die Mitarbeiterzahl steigt ständig an und wird nach einiger Zeit in ein Architektur- und in ein Prototypteam aufgeteilt. Das erste trifft zusammen mit dem Kunden Architekturentscheidungen, während das zweite schrittweise den Prototyp weiterentwickelt. Dieses Prototypteam wächst an Mitgliedern und es kann in der Folge in zwei bis drei Teams geteilt werden, die jeweils an unterschiedlichen Teilen arbeiten. Das Architekturteam stellt dabei den Kunden dar, indem es Anforderungen formuliert und Feedback gibt [Kruchten04, 3f].

Wenn die Architektur ausreichend entwickelt ist, werden weitere Teams gebildet und jedem wird ein Teil zugeordnet, für den es verantwortlich ist. Die Prototypteams lösen sich auf und unterstützen die neu geformten Teams. Dazu stoßen weitere Mitglieder des ursprünglichen Architekturteams, das allerdings in verkleinerter Form fortbesteht. Diese Mitarbeiter nehmen den Posten des Architekten ein und bilden die Schnittstelle zum Architekturteam. Die neu geformten Teams sind entweder Funktionalitäts- oder Infrastrukturteams. Die ersteren entwickeln Funktionalität, mit der die späteren Systembenutzer arbeiten. Die letzteren entwickeln die Elemente, die von den Funktionalitätsteams für die Entwicklung benötigt werden. In den meisten Fällen kann nicht in jedem Team ein Vertreter des Kunden präsent sein. Deshalb vertreten das Architekturteam sowie die Architekten der einzelnen Teams die Kunden. Zusätzlich stehen die Funktionalitätsteams bei Bedarf in direktem Kontakt mit den eigentlichen Kunden [Kruchten04, 4].

Für die Integration des Programmcodes wird ein spezielles Integrationsteam gebildet. Seine Aufgabe ist es, die nötigen Voraussetzungen für die Integration und das Testen des Programmcodes zur Verfügung zu stellen. Außerdem organisiert es die Benutzung der Testeinrichtung und führt bestimmte Tests selbst aus [Kruchten04, 4].

In Abbildung 3 ist der Lösungsvorschlag von Philippe Kruchten nochmals graphisch aufgezeigt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Entwicklung der Struktur im zeitlichen Ablauf

Quelle: Eigene Darstellung, modifiziert nach [Kruchten04, 5]

1.3.3 Jutta Eckstein

Jutta Eckstein beschreibt in „Agile Software Entwicklung im Grossen“ [Eckstein04] was bei großen und verteilten Projekten, sowie bei Projekten in großen Organisationen bei Verwendung agiler Methoden zu beachten ist. Ihre Überlegungen resultieren aus Erfahrungen. Sie stellt dabei fest, dass ein großes Projektteam in mehrere kleine agile Teams aufgeteilt werden muss. Deshalb muss es einen Prozess geben, der die einzelnen Teams miteinander verbindet und agile Zusammenarbeit ermöglicht. Auf die Beschreibung eben dieses Prozesses konzentriert sich die Autorin. Dabei unterstreicht sie die Wichtigkeit von direkter Kommunikation, da diese neben Transparenz Vertrauen bei allen Projektbeteiligten sowohl im einzelnen Teilteam als auch zwischen den Teams aufbaut. Durch dieses Vertrauen werden die Mitglieder wiederum Verantwortung übernehmen, was laut Eckstein Grundvoraussetzung eines erfolgreichen Projektes ist. Es muss ein Teamgeist entstehen, so dass jeder Projektbeteiligte Spaß bei der Arbeit hat und gerne und erfolgreich am Projekt arbeitet. Für ein erfolgreiches Projekt muss also ein Gefühl der gemeinsamen Verantwortlichkeit für das Projekt entstehen. Als Hemmschuh sieht Eckstein dabei die Struktur und Kultur an, die in vielen großen Organisationen herrscht. Sie sind oft konträr zur agilen Entwicklung, da sie Arbeiten meist nach Aufgaben aufteilen, die dann von Spezialisten verschiedener Abteilungen übernommen werden. Häufig entstehen dadurch – oft inoffizielle – Hierarchien, indem bestimmte Tätigkeiten als qualifizierter angesehen werden als andere. Zur Lösung schlägt sie die aktive Beteiligung aller Abteilungen über die gesamte Projektlaufzeit hinweg vor. Dadurch lässt sich die starre Struktur aufweichen und eine mehr projektorientierte Organisation formen.

Für den Aufbau einer Teamstruktur schlägt Eckstein einen ähnlichen Ansatz wie Philippe Kruchten [Kruchten04] vor. Zu Beginn eines Projektes sollte ein so genanntes Startteam, welches nicht mehr als 20 Personen umfasst, eine erste Architektur entwickeln. Sie ist die Basis des späteren Systems und sollte bereits exemplarische Funktionalität enthalten. Dadurch zeigt die Architektur, dass das System auf ihrer Grundlage entwickelt werden kann. Nach Fertigstellung dieser ersten Architektur werden mehrere Teilteams gebildet, die in der Anfangsphase von Mitgliedern des Startteams unterstützt und eingearbeitet werden. Diese Erweiterung des gesamten Projektteams sollte langsam erfolgen, da die Integration von zu vielen Personen auf einmal kontraproduktiv sei. Das Startteam bleibt weiterhin bestehen, um die Architektur auf Grundlage der Anforderungen der Teilteams weiter zu entwickeln. Es können also nicht alle Mitglieder für die Integration neuer Projektmitarbeiter eingesetzt werden. Die einzelnen Teilteams sind jeweils für möglichst lose gekoppelte Subsysteme verantwortlich, die sich aus verwandter Funktionalität zusammensetzen. Die Fähigkeiten der Mitglieder dieser neu geformten Teilteams sollten gemischt sein, so dass das Team seine Aufgaben selbstständig lösen kann. Eckstein schlägt des Weiteren die Etablierung eines Chefarchitekten vor. Dieser behält den Gesamtüberblick, koordiniert die grundlegende Entwicklung und garantiert somit eine konsistente und möglichst einfache Architektur.

In großen Projekten sollten möglichst kurze Iterations- und Releasezyklen verwendet werden. Eckstein beschreibt, dass es schwierig ist, ein großes Projekt wieder auf Kurs zu bringen, wenn es eine Weile in die falsche Richtung gelaufen ist. Zur ständigen Standortbestimmung ist ein häufiges Feedback notwendig, was durch kurze Iterationen und häufige Release gewährleistet wird. Des Weiteren muss der von den Projektbeteiligten verwendete Prozess ständig angepasst werden. Dafür ist auch hierzu Feedback notwendig. Dies kann durch regelmäßige Besprechungen unter den Projektbeteiligten erreicht werden. Weiteres Feedback kann durch den Einsatz von Kommunikationsmanagern gesammelt werden, die die Mitglieder der Teams in regelmäßigen Abständen besuchen.

1.3.4 Fazit

In allen drei vorgestellten Arbeiten wird deutlich, dass agile Methoden bei der Anwendung in industriellen Projekten angepasst, beziehungsweise erweitert werden müssen. Die Entwicklung des Systems sollte im Kleinen begonnen werden und dann wachsen. Das Projekt sollte dabei in eine Struktur kleiner agiler Projekte zerlegt werden. Diese Subsysteme können dann von kleinen Teams wie ideale agile Projekte entwickelt werden. Zusätzlich ist ein Prozess nötig, der die einzelnen Subsysteme verbindet. Dieser koordiniert die Arbeiten im Projekt, sowie die Zusammenarbeit der Teams und regelt die Kommunikation zwischen den Teams. Grundsätzlich lässt sich sagen, dass dadurch eine stärkere Formalisierung und Strukturierung nötig ist, als es in kleinen agilen Projekten der Fall ist.

2 Agile Software-Entwicklung

Dieses Kapitel führt in die Grundlagen der agilen Software-Entwicklung ein. Es erklärt, warum und wie es zur agilen Bewegung kam und was man darunter versteht. Dazu stellt es die traditionelle Software-Entwicklung vor und zeigt die Gründe für die Entstehung von agilen Methoden auf. Darauf folgend führt es in den agilen Ansatz ein und charakterisiert diesen. Dies ist insbesondere deshalb wichtig, weil oftmals ganz unterschiedliche Definitionen von Agilität existieren. Die Grundlage dieses Kapitels ist deshalb die Vorstellung des agilen Manifests, dessen Werte und Prinzipien die Basis der agilen Bewegung darstellen.

2.1 Traditionelle Software-Entwicklung

Die Ursprünge der Methoden der traditionellen Software-Entwicklung kommen aus der ingenieurmäßigen Entwicklung von Nicht-Software-Systemen. Diese versuchen die Entwicklung von Systemen zwischen einer großen Zahl von zusammenarbeitenden Subsystemen zu organisieren. Dabei werden zuerst die Anforderungen an das System gesammelt, dann das System geplant, gebaut und getestet. Dies geschieht mit Hilfe von definierten Vorgehensweisen. Vor allem große Organisationen wie zum Beispiel das US-Verteidigungsministerium oder IBM entwickelten solche Software-Entwicklungsprozesse. Dies geschah aus zweierlei Gründen: Zum einen sollte die bis dato oft chaotische und unstrukturierte Vorgehensweise diszipliniert werden. Diese führte oft dazu, dass die Vorgaben für Zeit, Budget, Qualität oder Funktionalität nicht eingehalten werden konnten. Zum anderen fand eine Anpassung an die bereits bestehenden ingenieurmäßigen Prozesse zur Entwicklung von Nicht-Software-Systemen statt [Boehm04, 9ff].

Methoden der traditionellen Software-Entwicklung gehen wie bereits oben beschrieben nach definierten Schritten vor. Diese werden in der Regel ausführlich dokumentiert. Dazu gehören meist die Anforderungsanalyse, das Design, die Programmierung, Tests und der Einsatz sowie die Wartung des fertigen Systems. Ursprünglich wurden diese Entwicklungsschritte nacheinander im so genannten Wasserfallmodell durchlaufen. Das heißt, zuerst wird die komplette Anforderungsanalyse durchgeführt, darauf folgt das komplette Design, dann die Programmierung und so weiter. Abbildung 4 zeigt das Wasserfallmodell. Im Laufe der Zeit wurde dieses aber zum Teil aufgeweicht und andere Modelle wie zum Beispiel das inkrementell vorgehende Spiralmodell entwickelt [Boehm04, 11].

Abbildung 4: Das Wasserfallmodell

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung, modifiziert nach [Wika]

Traditionelle Methoden legen viel Wert auf die Definition und Standardisierung ihrer Prozesse sowie ihrer ständigen Verbesserung. Diese Prozesse definieren detaillierte Pläne, Aktivitäten, Arbeitsabläufe, Rollen und Verantwortlichkeiten in der Entwicklung. In manchen Fällen sind Mitarbeiter nur dafür zuständig, dass diese Prozesse eingehalten werden. Die Stärke der traditionellen Entwicklungsmethoden liegt deshalb auch in ihrer Vergleich- und Wiederholbarkeit. Durch die Standardisierung findet sich jeder im Entwicklungsprozess geschulte Mitarbeiter in den Abläufen schnell zurecht und benötigt keine lange Einarbeitungszeit. Die Betonung liegt also nicht auf den individuellen Fähigkeiten der einzelnen Projektmitarbeiter [Boehm04, 11f].

2.2 Entstehung der agilen Bewegung

Die Umgebung, in der heute Software entwickelt und eingesetzt wird, hat sich in den letzten Jahren extrem geändert. Das Internetzeitalter fordert Flexibilität, Schnelligkeit und Innovationen, was von traditionellen Methoden der Software-Entwicklung nicht hinreichend gewährleistet wird. Durch ihre strikten Vorgaben werden vielmehr Innovationen eher gehemmt. Das kann dazu führen, dass das Hauptaugenmerk nicht mehr auf dem eigentlich zu entwickelnden Produkt, sondern eher auf der Einhaltung der Entwicklungsprozesse und der Vorgaben für die Dokumentation liegt.

Durch die in traditionellen Methoden angestrebte Optimierung können Kosten bei ähnlichen, stets wiederkehrenden Abläufen eingespart werden. Diese unterstützen aber keine Innovation. Insbesondere versuchen traditionelle Methoden, sich während des Projektes verändernde Anforderungen an das zu entwickelnde Produkt zu vermeiden. Experimente und Veränderungen sind aber Grundvoraussetzungen für Innovation. Deshalb sollte nicht versucht werden, die Anzahl der Veränderungen zu reduzieren, sondern die Kosten für die Umsetzung der veränderten Anforderungen zu verringern [Highsmith02, 10].

Craig Larman führt in seinem Buch „Agile and Iterative Development“ folgende Faktoren an, die es schwierig machen, Anforderungen zu Beginn eines Projektes festzulegen und zu fixieren [Larman04, 5]:

- Die Kunden und Nutzer sind sich nicht sicher, was sie wollen.
- Sie haben Schwierigkeiten, ihr Wissen und ihre Anforderungen an die Software auszudrücken.
- Viele Details der Anforderungen werden erst im Laufe des Projektes klar.
- Wenn die Kunden die lauffähige Software sehen, wird ihnen klar, dass sie es doch anders wollten.
- Externe Faktoren (Konkurrenz etc.) führen zu Veränderungen oder Erweiterungen der Anforderungen.

Als Antwort auf diese Probleme entwickelten Spezialisten der Software-Entwicklung verschiedene „leichtgewichtigere“ Methoden. Diese sind heute unter dem Namen agile Methoden bekannt. Beispiele hierfür sind:

- Extreme Programming (XP) von Kent Beck, Ward Cunningham und Ron Jeffries [Beck00].
- Scrum von Ken Schwaber und Jeff Sutherland [Schwaber95].
- Crystal von Alistair Cockburn [Cockburn02].
- Adaptive Systems Development (ASD) von Jim Highsmith [Highsmith00].
- Dynamic Systems Development Method (DSDM) [Stapleton97].

x Feature Driven Development (FDD) von Jeff DeLuca [Palmer02].

Ein Hauptbestandteil dieser Methoden sind inkrementelle und iterative Techniken. Diese brechen den Entwicklungsprozess des Wasserfallmodells (vgl. 2.1) in kleine Stücke auf, so genannte Iterationen [Beck99, 70]. Das Ergebnis jeder Iteration ist eine lauffähige Software. Die Funktionalität des Programms wird also sukzessive erweitert. Zwar werden auch hier die Anforderungen am Anfang des Projektes gesammelt, jedoch können sich diese im Laufe des Projektes noch ändern. Dies gilt allerdings nicht für die Anforderungen, die in der aktuellen Iteration umgesetzt werden. Jede Iteration umfasst also alle Phasen des Wasserfallmodells, was in Abbildung 5 dargestellt ist [Cohen03, 2].

Abbildung 5: Das iterative Modell

Das Iterative Modell

Abbildung in dieser Leseprobe nicht enthalten

Quelle: eigene Darstellung

Inkrementelle und iterative Techniken sind nicht neu. Sie wurden bereits vor dem Auftreten der agilen Methoden praktiziert, zum Beispiel im Spiralmodell. Was agile Methoden zusätzlich auszeichnet, ist die besondere Stellung der Mitarbeiter und Beteiligten im Projekt. Sie sind zusammen mit der Konzentration auf Effektivität und Flexibilität die Kombination, welche Agilität definiert [Highsmith01a, 122].

Laut Alistair Cockburn [Cockburn02, xxii] ist der Kern der agilen Software-Entwicklung die Verwendung von schwachen aber ausreichenden Regeln. Diese legen das Projektverhalten fest und organisieren die Zusammenarbeit und Kommunikation zwischen den Beteiligten.

Durch die Verwendung von schwachen Regeln bleibt das Projekt flexibel. Sie müssen aber soweit einschränkend sein, dass das Projekt nicht aus dem Ruder läuft.

2.3 Das agile Manifest

2.3.1 Einführung

Die agile Bewegung wurde während einer Konferenz in Snowbird, Utah vom 11. – 13. Februar 2001 ins Leben gerufen. Teilnehmer waren 17 führende Repräsentanten der bis dahin noch „leichtgewichtig“ genannten Prozesse Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature Driven Development und Pragmatic Programming sowie weitere Sympathisanten dieser Idee [Highsmith01b]. Ziel war es, Gemeinsamkeiten der verschiedenen Methoden zu finden. Das Ergebnis war der Name „agil“ als Ausdruck von Anpassungsfähigkeit und der Fähigkeit, mit Veränderungen umzugehen. Die Gruppe gab sich selbst den Namen „Agile Alliance“ und erarbeitete ein Manifest, welches die Grundwerte der agilen Bewegung enthält. Das Manifest erweiterten die Beteiligten in den folgenden Monaten um weitere Prinzipien [Highsmith01b]. Der Zusammenschluss will diese gemeinsamen Werte aber nicht zu einem Entwicklungsprozess ausbauen oder die bestehenden Entwicklungsmethoden unter einem einzigen Prozess vereinen [Eckstein04, 14]. Durch das Manifest sollte vielmehr ihr Unmut über die vorherrschenden Methoden zum Ausdruck gebracht und gezeigt werden, wie Software besser entwickelt werden kann [Dogs05, 22].

2.3.2 Die vier agilen Werte

„Wir entdecken bessere Wege zur Entwicklung von Software, indem wir Software entwickeln und anderen bei der Entwicklung helfen. Durch diese Tätigkeiten haben wir gelernt, dass uns

Abbildung in dieser Leseprobe nicht enthalten

Natürlich sind auch die Dinge rechts wichtig, aber im Zweifelsfall schätzen wir die linken höher ein.“²

Die Merkmale auf der rechten Seite stehen für die Werte und Eigenschaften der traditionellen Methoden der Software-Entwicklung. Die linke Seite nennt Werte, denen in agilen Methoden die höchste Priorität gegeben wird. Damit wird bereits klar, dass die Autoren nicht alle Eigenschaften der traditionellen Methoden als schlecht und unnütz betrachten. Viele davon finden sich in den agilen Methoden wieder, allerdings sind die Werte auf der linken Seite wichtiger. Im Folgenden sollen diese noch weiter erläutert werden [Fowler01].

Menschen und Zusammenarbeit sind wichtiger als Prozesse und Werkzeuge

Prozesse und Werkzeuge können für den Projekterfolg sehr wichtig sein, allerdings dürfen sie nicht überschätzt werden. Menschen sind für ein erfolgreiches Projekt wichtiger. So wird ein guter Prozess das Projekt nicht vor dem Scheitern bewahren, wenn die Projektmitglieder nicht gut genug sind. Natürlich ist es wünschenswert nur überdurchschnittliche Mitarbeiter im Projekt zu haben, ein erfolgreiches Projekt garantiert dies jedoch nicht. Ein durchschnittlicher Programmierer, der mit den anderen Teammitgliedern kommuniziert und zusammen arbeitet, kann von sehr großem Nutzen für ein Projekt sein. Dieser kann weitaus größer sein als eine Gruppe von überdurchschnittlichen Experten, denen es nicht gelingt, als Team zusammen zu arbeiten. Deshalb sollten Manager nicht den Fehler machen, Vorgaben zu machen, mit denen das Team während des Projektes zurechtkommen muss. Sie sollten vielmehr versuchen, das Projektteam so zu formen, dass es Entscheidungen über die zukünftige Arbeit selbst treffen kann [Martin01, 9].

In den existierenden agilen Methoden spiegelt sich dies in engen Beziehungen im Team wider, sowie in Arbeitsumgebungen, die die Zusammenarbeit fördern. Außerdem sind meist explizite Praktiken zur Förderung des Teamgeistes definiert [Abrahamsson02, 11].

Lauffähige Software ist wichtiger als umfangreiche Dokumentation

Nur anhand des eigentlichen Produktes, sprich der lauffähigen Software, kann beurteilt werden, ob die Bedürfnisse und Anforderungen des Kunden befriedigt wurden. Das heißt nicht, dass Dokumentation überflüssig ist. Programmcode ist kein ideales Medium für die Kommunikation und reicht daher alleine nicht aus. Dokumentation darf aber nicht das Haupterzeugnis des Projektes sein. Das heißt knappe, übersichtliche und aktuelle Dokumentation des Systems und der Designentscheidungen ist wünschenswert.

Agile Methoden versuchen ausführliche Dokumentation durch Kommunikation und Zusammenarbeit im Team zu ersetzen. Dokumentation ist nur eine Momentaufnahme und sehr arbeitsaufwändig, da sie ständig aktuell gehalten werden muss, soll sie mit dem sich weiterentwickelnden Programmcode übereinstimmen [Coldewey02, 70]. Statt durch umfangreiche Dokumentation werden neue Projektmitglieder durch die Mitarbeit im Team und durch Kommunikation mit den anderen trainiert und geschult [Martin01, 10]. Wo allerdings Dokumentation notwendig ist, wird versucht, sie so kurz wie möglich zu halten. Dies geschieht häufig erst nach der Fertigstellung der Software, da sie dann dem aktuellen Stand der Software entspricht und so ihren Zweck beim Kunden erfüllt [Coldewey02, 70].

Der Wert „Lauffähige Software ist wichtiger als umfangreiche Dokumentation“ kommt bei agilen Methoden dadurch zum Ausdruck, indem sie versuchen, fortlaufend funktionsfähige Software mit größerer Funktionalität zu erstellen und an den Kunden auszuliefern. Die Entwickler müssen den Programmcode so einfach wie möglich halten, um somit eine zu umfangreiche Dokumentation zu vermeiden [Abrahamsson02, 11].

Zusammenarbeit mit Auftraggebern ist wichtiger als Vertragsverhandlungen

Kunde und entwickelndes Unternehmen spezifizieren üblicherweise zu Beginn eines Projektes die geforderte Funktionalität des zu entwickelnden Systems und fixieren diese vertraglich. Häufig ist aber zu Beginn des Projektes noch gar nicht klar, was das System im Detail leisten soll. Vielmehr ist es Gegenstand des Projektes, dies heraus zu finden. Selbst wenn es im Einzelfall möglich ist, die Anforderungen vorweg festzulegen, ist ständige Kommunikation zwischen Kunde und Entwicklungsteam notwendig. Der Kunde kann nicht davon ausgehen, das Team einige Zeit ohne weitere Kommunikation arbeiten zu lassen und dann genau die Software zu erhalten, die er sich wünscht.

Aus diesem Grund setzen agile Methoden auf Kundenbeteiligung während der gesamten Projektlaufzeit, um regelmäßiges und häufiges Feedback zu erhalten. Dies geschieht häufig durch einen Kundenvertreter vor Ort, der kurzfristig Fragen beantworten kann. Darüber hinaus sollte auf Verträge, die detaillierte Funktionalität, Planungen sowie Kosten des Projektes beinhalten, verzichtet werden. Stattdessen sollten sie die Art und Weise der Zusammenarbeit zwischen Kunde und Projektteam regeln [Martin01, 10].

Reagieren auf Änderungen ist wichtiger als das Befolgen eines Plans

Die traditionelle Software-Entwicklung versucht einen möglichst vollständigen und detaillierten Plan von Beginn bis zum Ende des Projektes zu erstellen. Dies kann nur unter Zuhilfenahme von Annahmen geschehen. Diese Annahmen können sich jedoch schnell als falsch erweisen, sei es durch Änderungen der Anforderungen durch den Kunden oder durch technischen Fortschritt während der Projektdauer. Mit zunehmender Größe und Komplexität eines Projektes verschärft sich dieses Problem und eine verlässliche Planung ist kaum noch realisierbar.

Die Vergangenheit hat gezeigt, dass kaum ein Projekt genau nach Plan verläuft - vor allem in neuen bisher noch wenig bekannten Gebieten. Je detaillierter die Pläne sind, desto schneller stimmen sie nicht mehr mit der Realität überein. Wird strikt dem Plan gefolgt, dann wird auf Basis von veralteten Informationen gearbeitet. Das Produkt wird die Funktionalität und das Aussehen haben, die der Kunde zu Beginn des Projektes für richtig hielt, aber nicht, was den aktuellen Ansprüchen entspricht [Coldewey02, 70f].

Agile Methoden haben den Anspruch, den Kunden nicht nur beim Beginn des Projektes zufrieden zu stellen, sondern vor allem zum Zeitpunkt der Auslieferung der Software. Deshalb schlägt Martin vor, detaillierte Pläne für die nächsten Wochen, grobe Pläne für die nächsten Monate und vage Pläne für den Rest des Projektes zu machen [Martin01, 11]. Dies hat allerdings aus Sicht der traditionellen Methoden den Nachteil, dass das Projekt seine Vorhersagbarkeit einbüßt, was diese ja gerade für sich in Anspruch nehmen [Coldewey02, 71].

2.3.3 Die zwölf agilen Prinzipien

Die vier agilen Werte haben die Autoren des agilen Manifests zu zwölf weiteren Prinzipien inspiriert. Diese konkretisieren die agilen Werte und stellen die Merkmale eines agilen Prozesses dar. Die Übersetzung ins Deutsche ist dem Buch von Dogs und Klimmer [Dogs2005, 41] entnommen. Die englische Originalfassung ist unter www.agilemanifesto.org zu finden.

(1) „Unsere höchste Priorität liegt darin, den Kunden durch frühzeitige und kontinuierliche Auslieferungen wertvoller Software zufrieden zu stellen.“ Spezifikationen und Diagramme helfen dem Kunden kaum bei der tatsächlichen Lösung seiner Probleme, sondern nur lauffähige Software. Agile Methoden liefern die erste Version der zu entwickelnden Software bereits zu einem sehr frühen Zeitpunkt des Projektes aus und von dort an in häufigen und regelmäßigen Abständen. Jedes Release hat dabei erweiterte Funktionalität. Der Kunde entscheidet daraufhin, ob er mit Umfang und Qualität der Funktionalität zufrieden ist und kann Änderungen fordern [Martin01, 12].

(2) „Begrüße sich verändernde Anforderungen, selbst wenn sie erst spät bei der Entwicklung auftreten. Agile Prozesse nutzen Änderungen zugunsten des Wettbewerbsvorteils des Kunden.“

Änderungen werden begrüßt, da sie der Kunde wünscht, durch ihre Erfüllung seine Zufriedenheit steigt und ihm ein Wettbewerbsvorteil gegenüber seinen Konkurrenten entsteht. Das Umsetzen der Änderungen – speziell zu einem späten Zeitpunkt im Projekt – erfordert allerdings eine spezielle Architektur des Systems, die dies zulässt. Änderungen müssen mit geringem Aufwand und mit wenigen Auswirkungen auf das bereits in Teilen entwickelte System möglich sein.

(3) „Liefere häufig funktionierende Software aus, innerhalb weniger Wochen oder Monate, wobei der kürzeren Zeitspanne eindeutig der Vorzug zu geben ist.“

Agile Methoden liefern häufig lauffähige Software an den Kunden aus. Dieser überprüft die entwickelte Funktionalität und gibt Feedback und eventuelle Änderungswünsche an das Entwicklungsteam zurück. Je öfter dies geschieht, desto schneller kann eingegriffen werden, um mögliche Fehlentwicklungen zu korrigieren. Im Fall von seltenem Feedback würde die Fehlentwicklung erst zu einem späteren Zeitpunkt erkannt und dadurch hohe Kosten durch die nötigen Korrekturen verursacht.

(4) „Geschäftsleute und Entwickler müssen während des gesamten Projektes täglich zusammenarbeiten.“

Zu Beginn des Projektes werden nur undetaillierte Anforderungen gesammelt und ein grober Plan für die Implementierung erarbeitet, was für die Entwicklung des Systems nicht ausreichend ist. Deshalb entwickeln Softwareentwickler und Kunden das System gemeinsam über die gesamte Laufzeit des Projektes hinweg, was tägliche Kundenpräsenz erfordert [Fowler01]. Daher sehen die meisten agilen Methoden einen ständigen Kundenvertreter vor Ort vor.

(5) „Baue deine Projekte mit motivierten Mitarbeitern auf. Gib ihnen die Umgebung und die Unterstützung, die sie benötigen und vertraue ihnen, dass sie ihre Arbeit erfolgreich beenden.“

Der Mensch ist das Wichtigste im Projekt und entscheidet letzten Endes über Erfolg oder Misserfolg. Deshalb sind motivierte Mitarbeiter sehr wichtig, Faktoren wie Arbeitsumgebung und Prozesse dagegen zweitrangig und müssen deshalb dem Faktor Mensch angepasst werden [Fowler01]. Führungskräfte sollten der Meinung und dem Wissen ihrer Mitarbeiter vertrauen und sie mit den erforderlichen Entscheidungsbefugnissen ausstatten [Dogs05, 43].

(6) „Die effektivste und effizienteste Methode, Informationen einem Entwicklungsteam zukommen zu lassen bzw. innerhalb eines Entwicklungsteams auszutauschen, ist die direkte Kommunikation von Angesicht zu Angesicht.“

Der Mangel an Dokumentation wird durch direkte Kommunikation nicht nur ausgeglichen, sondern übertroffen. Im direkten Gespräch gibt es weit weniger Verständnisschwierigkeiten und Missverständnisse als bei allen anderen Arten der Kommunikation. Sollten sie dennoch auftreten, werden sie bei der Kommunikation von Angesicht zu Angesicht rasch erkannt und können aufgeklärt werden.

(7) „Funktionierende Software ist der primäre Maßstab für Fortschritt.“

Der Fortschritt des Projektes wird gemessen anhand der entwickelten Funktionalität, also den bereits fertig gestellten Teilen des Programms [Martin01, 13]. Ist zum Beispiel eine bestimmte Funktionalität bereits implementiert aber noch nicht getestet, wird sie nicht als fertig gestellt betrachtet.

(8) „Agile Methodiken fördern die kontinuierliche Entwicklung. Geldgeber, Entwickler und Anwender sollten in der Lage sein, ein endlos beständiges Tempo beizubehalten.“

Regelmäßige Überstunden führen zu überarbeiteten und erschöpften Mitarbeitern, die dadurch Fehler machen. In Folge entsteht zusätzlicher Aufwand für die Korrektur dieser Fehler. Darüber hinaus leidet im Regelfall die Qualität des zu entwickelnden Systems.

Agile Software-Entwicklung setzt auf kreative und wachsame Projektbeteiligte, die konzentriert und über die gesamte Projektlaufzeit hinweg in kontinuierlichem Tempo hochwertige Software entwickeln [Fowler01]. Dies ist nur bei einer moderaten Zahl von Wochenarbeitsstunden möglich.

(9) „Ständige Aufmerksamkeit gegenüber technisch hervorragender Qualität und gegenüber gutem Design erhöht die Agilität.“

Nur mit sauber und robust programmierter Software ist schnelle und flexible Entwicklung möglich [Martin01, 14]. Mit unordentlichem Programmcode kann schlecht gearbeitet werden, er produziert Fehler und führt zu zusätzlicher Arbeit. Darüber hinaus sollten Entwickler über den neuesten technischen Fortschritt informiert sein, um ihn zum Vorteil der zu erstellenden Software einzusetzen [Dogs05, 44].

(10) „Einfachheit – die Kunst, unnötige Arbeit zu minimieren – ist essentiell.“

In der agilen Software-Entwicklung sollte die einfachste Lösung realisiert werden. Dies ermöglicht zum einen einfache und schnelle Änderungen des Programmcodes. Zum anderen ist einfacher, weitere Funktionalität hinzuzufügen [Fowler01]. Grundsätzlich soll nur die gegenwärtig benötigte Funktionalität implementiert werden. Zukunftsprognosen sind ungewiss und bergen die Gefahr von unnötigem Entwicklungsaufwand in sich. Zudem ist fraglich, ob die Funktionalität in der Zukunft überhaupt benötigt wird. Zusätzlich wird der Programmcode dadurch komplexer und Erweiterungen lassen sich schwieriger realisieren.

(11) „Die besten Architekturen, Anforderungen und Designs ergeben sich aus sich-selbst-organisierenden Teams.“

Verantwortlichkeiten werden dem Entwicklungsteam als ganzes übertragen und nicht einzelnen Personen. Das Team entscheidet dann gemeinsam über den besten Weg diese zu erfüllen. Es ist also selbst-organisiert. Dabei ist kein Teammitglied für nur eine bestimmte Aufgabe verantwortlich. Jeder hat das Recht und die Pflicht seinen Beitrag zur Lösung des Ganzen beizutragen [Martin01, 14].

(12) „In regelmäßigen Abständen machen sich die Teams Gedanken darüber, wie effektiver gearbeitet werden kann und passen ihr Verhalten entsprechend an.“

Agile Projekte laufen in einem sich ständig verändernden Umfeld ab. Deshalb müssen die Vorgehensweisen und Praktiken bei der Entwicklung ständig angepasst und verbessert werden. Nur so wird eine ständig optimale agile Entwicklung gewährleistet [Fowler01].

3 Methoden der agilen Software-Entwicklung

In den letzten Jahren entstanden mehrere agile Methoden mit zum Teil sehr unterschiedlichen Ausprägungen. Die Schöpfer dieser agilen Methoden trugen wesentlich zur Entstehung des im vorangegangenen Kapitel beschriebenen Manifests bei.

Der Autor dieser Arbeit beschränkt sich hier auf die Vorstellung der laut einer Studie von Shine Technologies am meisten verwendeten Methoden – Extreme Programming (XP) und Scrum [Shine03, 4]. Die große Popularität dieser Methoden spiegelt sich auch in den im fünften Kapitel analysierten Projekten wider.

Für das Verständnis der folgenden Kapitel sind besonders die Praktiken der beiden Methoden und die Werte von XP von Bedeutung, weshalb sich die Ausführungen dieses Kapitels auch nur auf deren Beschreibung konzentrieren. Praktiken sind Aktivitäten und Arbeitsprodukte, die bei Verwendung einer Methode durchgeführt, beziehungsweise erstellt werden müssen.

Eine ausführliche Beschreibung der Prozesse und der beteiligten Rollen von XP und Scrum befindet sich in Anhang A.1 und A.2. Der Prozess umfasst die einzelnen Phasen im Verlauf eines Projektes bei Verwendung der Methode. Rollen sind besondere Tätigkeiten oder Aufgabenbereiche von Projektbeteiligten.

3.1 Extreme Programming – XP

Extreme Programming oder kurz XP trat ins Rampenlicht der Software-Entwicklung im Jahr 2000/2001 [Highsmith02, 297] und ist seither die am häufigsten eingesetzte agile Methode [Shine03, 4]. Es ist eine iterative Entwicklungsmethode, die wenig formalisierte Arbeitsprodukte kennt und sich hauptsächlich auf Programmcode und Tests beschränkt. XP setzt auf sehr kurze Iterationszyklen und ausgeprägte Kommunikation zwischen den Projektbeteiligten. Deshalb ist es meist nur für kleinere Projekte geeignet. Wie schon das Wort „Programming“ im Methodennamen verrät, definiert XP vor allem Programmiertechniken für die Entwicklung von hochqualitativem, aber flexiblem Programmcode. Dadurch lassen sich in der Regel Änderungen auch noch zu einem sehr späten Zeitpunkt im Projekt ohne größeren Aufwand umsetzen [Larman04, 138ff].

Bei der Verwendung von XP ist es wichtig, alle Praktiken gemeinsam anzuwenden. Dies wird in der Praxis jedoch oft nicht umgesetzt. Das Weglassen einer Praktik kann den Nutzen anderer gefährden, denn sie hängen stark voneinander ab. XP zeichnet sich nicht durch seine einzelnen Praktiken aus, sondern durch deren Kombination. Die hauptsächlich von Kent Beck und Ward Cunningham eingeführten Praktiken für XP waren keine Neuheiten. Die meisten wurden bereits viel früher in verschiedenen Ansätzen verwendet, aber nie in Kombination miteinander. Dies geschah erst in XP [Beck99, 71].

Mittlerweile sind eine Vielzahl von Publikationen für und über XP erschienen, darunter mehrere Bücher von Kent Beck und Ron Jeffries. Für die folgenden Abschnitte wurde vor allem das Buch „Extreme Programming explained“ von Kent Beck [Beck00] als Quelle verwendet. Dieses Werk empfiehlt der Autor dieser Arbeit auch für weiterführende Recherchen.

Im Folgenden werden die vier spezifischen Werte von XP vorgestellt.

3.1.1 Die vier Werte von XP

Die Basis für XP und seine Praktiken bilden die vier Werte Kommunikation, Einfachheit, Feedback und Courage [Beck00, 29].

3.1.1.1 Kommunikation

Viele Probleme in Projekten entstehen durch fehlende Kommunikation zwischen den Projektbeteiligten, seien es Programmierer, Kunden oder Manager. XP setzt deshalb Praktiken ein, wie zum Beispiel

- Programmieren in Paaren (Programmieren in Teams von zwei Personen),

- gemeinschaftliche Schätzung des Entwicklungsaufwandes im Team.

Dafür ist die Kommunikation zwischen Entwicklern, Kunden und Managern sehr wichtig. Zusätzlich gibt es in XP die Rolle eines Beraters, den so genannten Coach. Er achtet unter anderem darauf, dass ausreichend Kommunikation zwischen allen Beteiligten im Projekt stattfindet [Beck00, 29f].

3.1.1.2 Einfachheit

Zur Lösung eines Problems sollten Entwickler immer die einfachste Lösung nutzen. Zukünftige Anforderungen bleiben dabei unberücksichtigt. Diese können sich in agilen Projekten sehr schnell ändern und machen damit den bereits geleisteten Entwicklungsaufwand hinfällig. Grundsätzlich gilt also: Lieber heute etwas einfach implementieren und zusätzlichen

Entwicklungsaufwand für zusätzliche spätere Anforderungen akzeptieren, sofern diese dann wirklich benötigt werden. Außerdem ist in einem einfachen und übersichtlichen System nur wenig Kommunikation nötig und die notwendige wird erleichtert [Beck00, 30f].

3.1.1.3 Feedback

Der dritte Wert in XP ist das Feedback. Der aktuelle Stand der Entwicklung des Systems wird in kurzen Zeitabständen gegenüber dem Kunden und dem Management kommuniziert. Dadurch lassen sich Fehlentwicklungen schnell erkennen und korrigieren. Die Zeitintervalle zwischen den einzelnen Feedbacks können eine Dauer von wenigen Minuten bis hin zu Monaten haben. Das Programmieren in Paaren ergibt ein Feedback sogar innerhalb weniger Sekunden nach dem Entstehen des fraglichen Codes, da sich die zwei Entwickler bei ihrer Arbeit an einem Computer ergänzen. In ähnlich kurzer Zeit lassen sich Fragen an den Kunden klären, denn bei der Anwendung von XP sollte ständig ein Kundenvertreter vor Ort sein. Innerhalb von Minuten kann das Feedback für Tests der gerade fertig gestellten Codeeinheit vorliegen. Ein Beispiel für einen längeren Zyklus ist das Feedback des Kunden für eine ihm ausgelieferte Version des Systems. Abbildung 6 zeigt einen Überblick über die vielfältigen Feedbackmöglichkeiten die XP bietet [Beck00, 31f].

Abbildung 6: Feedback in XP

Abbildung in dieser Leseprobe nicht enthalten

Quelle: [Störrle03, 2]

3.1.1.4 Courage

Beck spricht vom Problem des Bergsteigens: Wenn man immer nur bergauf geht, wird man nur lokale Maxima erreichen. Man muss gelegentlich auch mal ein Stück bergab gehen, um einen noch höheren Gipfel zu erklimmen. Das gleiche gilt auch für XP. Entwickler müssen die nötige Courage haben, Entscheidungen zu treffen und ungewöhnliche Wege zu gehen. Dazu zählt auch, Code zu verwerfen und von neuem zu beginnen, wenn sie sich in eine Sackgasse manövriert haben. Liegt zum Beispiel ein grundsätzlicher Fehler in der Architektur vor, werden Verbesserungen auf der Grundlage dieser Architektur nie dazu führen, den Fehler zu beheben. Es ist besser, gleich ganz neu zu beginnen [Beck00, 33f].

3.1.1.5 Verzahnung der einzelnen Werte

Die einzelnen Werte sind nur im Verbund miteinander im hohen Maß effektiv. Die Werte bauen aufeinander auf.

Kommunikation und Einfachheit ergänzen sich. Durch Kommunikation wird erst klar, was gebraucht und was getan werden muss. Je einfacher ein System ist, desto weniger muss kommuniziert werden. Dies führt wiederum zu effektiverer und effizienterer Kommunikation [Beck00, 30f].

Das gleiche gilt für Feedback, das in enger Beziehung zu Kommunikation und Einfachheit steht. Je mehr Feedback ein Entwickler bekommt, desto einfacher ist die Kommunikation. Wenn zum Beispiel eindeutige Testberichte vorliegen, erübrigt sich bereits ein sehr großer Teil der Diskussionen. Durch Kommunikation wird klarer, was genau zu testen ist und ein einfaches System lässt sich leichter testen als ein komplexes [Beck00, 32].

Ohne Kommunikation, Einfachheit und Feedback ist Courage wenig gewinnbringend. Kommunikation öffnet neue Wege durch den Austausch mit Kollegen. Einfachheit fördert Courage, weil in komplexen Umgebungen Änderungen schwierig und aufwendig sind. Courage ermöglicht wiederum Einfachheit, weil einfache, aber unkonventionelle Lösungsansätze gut und schnell entwickelt werden können. Letztlich unterstützt Feedback Courage, weil es ermöglicht, neue Wege zu gehen [Beck00, 34].

3.1.2 Praktiken

XP beinhaltet zwölf Techniken, die Arbeits- und Vorgehensweisen in einem XP-Projekt definieren. Diese Praktiken sind:

- Planungsspiel

- Kleine Release
- Systemmetapher
- Einfaches Design
- Tests
- Refaktorisierung
- Programmieren in Paaren
- Gemeinsames Eigentum am Code
- Kontinuierliche Code-Integration
- 40-Stunden-Woche
- Kundenvertreter im Team
- Programmierrichtlinien

Die meisten anderen Methoden, die einige dieser Praktiken einführten, ersetzten sie später durch komplexere Regeln, da sie zum Teil durch ihre Einfachheit auch erhebliche Schwächen und Risiken bergen. XP setzt deshalb auf die Kombination aller Praktiken, so gleicht die Stärke einer Praktik die Schwäche einer anderen aus [Beck00, 63].

Im Folgenden werden nun diese Praktiken auf Grundlage der Werke von Beck [Beck00, 53ff], Larman [Larman04, 147ff] und Reißing [Reißing00] beschrieben.

3.1.2.1 Planungsspiel

In XP dürfen weder Geschäftsprozesse noch technische Überlegungen zuviel Einfluss auf die Software-Entwicklung haben. Programmierer und Kunden müssen eng miteinander interagieren, um die beste Lösung für die Probleme des Kunden zu finden. Deshalb findet zu Beginn einer jeden Iteration das Planungsspiel statt, in welchem die in der nächsten Iteration zu entwickelnden Funktionen festgelegt werden. Der Kunde bestimmt zuerst die Priorität aller noch zu entwickelnden Funktionen. Dann wählt er, mit Hilfe der von den Programmierern abgegebenen Aufwandsschätzungen, die in der folgenden Iteration zu implementierende Funktionalität aus.

3.1.2.2 Kleine Release

Ein kurzer Zeitraum ist besser voraus zu planen als ein langer. In XP sollte möglichst oft lauffähige Software an den Kunden ausgeliefert werden. Dies verkürzt den Feedbackzyklus und es kann auf Fehlentwicklungen früher reagiert werden. Allerdings muss ein Release eine angemessene Größe haben. Es macht keinen Sinn, eine Funktion nur zur Hälfte zu entwickeln und an den Kunden auszuliefern. Für die Entwicklung der allerersten Version wird ein Zeitraum von zwei bis sechs Monaten vorgeschlagen. Die Projektbeteiligten verschaffen sich zuerst einen Überblick und entwickeln das Gerüst des Systems, bevor sie mit der Entwicklung von Funktionalität beginnen können. Der Zeitrahmen ab dem zweiten Release beträgt in der Regel zwischen ein und drei Monaten. Die Release werden in ein- bis dreiwöchige Iterationen unterteilt.

3.1.2.3 Systemmetapher

Die Systemmetapher hilft die grundlegenden Elemente des zu entwickelnden Systems und ihre Verbindung zueinander zu verstehen. Sie ist für Entwickler und Kunden unverzichtbar, damit sie das Ziel der Entwicklung nicht aus den Augen verlieren. In XP wird die Systemmetapher als Ersatz für den Architekturentwurf verwendet.

3.1.2.4 Einfaches Design

In vielen Entwicklungsmethoden sollten beim Entwurf des Systems bereits zukünftige Anforderungen berücksichtigt werden, um diese später leichter implementieren zu können. Dem widerspricht XP. Hier soll der einfachste Weg gesucht werden, um die aktuellen Anforderungen an das zu entwickelnde System zu lösen. Zukünftig erforderliche Funktionalität wird nicht berücksichtigt, da zum heutigen Zeitpunkt nicht absehbar ist, ob und in welcher Form diese wirklich benötigt wird.

3.1.2.5 Tests

Tests nehmen einen hohen Stellenwert in XP ein. Sie werden vor der eigentlichen Implementierung der Funktionen geschrieben und müssen automatisiert ablaufen. Dabei gibt es zwei Arten von Tests. Zum einen schreiben die Programmierer so genannte Unit Tests, um die richtige Ausführung des von ihnen entwickelten Programmcodes zu überprüfen. Daneben entwerfen Kunden Testfälle, die die von ihnen gewünschte Funktionalität überprüfen. Die Testfälle werden dann in automatisierte Tests übersetzt.

3.1.2.6 Refaktorisierung

Der eigentliche Begriff für diese XP-Praktik ist das englische „Refactoring“ und lässt sich nur schwer ins Deutsche übersetzen. Gemeint ist damit die Überarbeitung und Optimierung des bereits bestehenden Programmcodes. Ziel ist es, diesen unter Beibehaltung der Funktionalität zu vereinfachen. Die daraus resultierende einfache Struktur des Programmcodes macht Änderungen oder das Hinzufügen von weiterer Funktionalität einfacher. Ständig automatisierte Tests stellen sofort fest, wenn bei der Refaktorisierung ein Fehler unterlaufen ist.

3.1.2.7 Programmieren in Paaren

Das Programmieren in Paaren ist wohl die bekannteste XP-Praktik. Sie sagt aus, dass jeglicher Programmcode von zwei Programmieren zusammen an einem Computer entwickelt wird. Dabei arbeitet ein Partner mit der Tastatur und der Maus und schreibt den Programmcode für die zu entwickelnde Funktion. Der zweite Partner nimmt eine mehr strategische Sicht ein. Er überprüft ständig die Eingaben seines Partners, zum Beispiel auf Schreib- oder logische Fehler. Er behält aber auch im Auge, dass das übergeordnete Ziel erreicht wird. Dafür überwacht er unter anderem die Übereinstimmung von Code und Entwurf und sollte fehlende Testfälle erkennen.

Die Aufteilung der Rollen sowie die Zusammensetzung der Paare sind nicht starr, sondern werden häufig gewechselt. Vorteile sind ein reger Informationsaustausch und ein ständiges Lernen voneinander.

3.1.2.8 Gemeinsames Eigentum am Code

In traditionellen Projekten verfügt eine einzelne Person über den Programmcode und nur diese darf Änderungen vornehmen. Dadurch können Inkonsistenzen durch Änderungen verschiedener Personen verhindert werden. Allerdings kann diese Methode zu Wartezeiten, aufgrund der eingeschränkten personellen Änderungsvollmacht führen.

In XP hingegen hat nicht nur der entwickelnde Autor oder das entwickelnde Paar das Recht, Änderungen am Programmcode vorzunehmen, sondern jeder Entwickler kann die unterschiedlichen Teile des Programmcodes verändern, wenn er die Notwendigkeit dazu sieht. Das Team trägt die Verantwortung für die Konsistenz des gesamten Programmcodes. Ständige automatisierte Tests decken Fehler, die aus Änderungen im Programmcode resultieren, sofort auf. Der Entwickler, der sie verursacht hat, ist für die Korrektur verantwortlich.

3.1.2.9 Kontinuierliche Code-Integration

Der neu entwickelte Programmcode sollte mehrmals täglich, aber mindestens einmal pro Tag in das bereits bestehende System integriert und getestet werden. Dazu bietet sich die Bereitstellung eines eigenen Rechners für die Integration an, der für alle Programmiererpaare zur Verfügung steht. Bei der Integration laden diese die vorgenommenen Veränderungen in die bestehende Code-Basis und lassen die Tests ablaufen. Sollten Fehler auftreten, ist es die Aufgabe dieses Paares die Fehler zu korrigieren oder gegebenenfalls ihre durchgeführten Änderungen rückgängig zu machen. Beim Verlassen des Integrationsrechners muss das darauf laufende System alle Tests zu 100 Prozent erfüllen.

3.1.2.10 40-Stunden-Woche

Die Art und Weise, wie in XP ein System entwickelt wird, erfordert kreative und wachsame Projektbeteiligte. Dauerhafte Kreativität und Wachsamkeit sind bei einem großen Arbeitspensum von den Projektbeteiligten aber kaum zu leisten. Die Konzentration nimmt mit zunehmender Arbeitsdauer ab, weshalb auf angemessene Arbeitszeiten geachtet werden sollte.

3.1.2.11 Kundenvertreter im Team

Der Kunde vermerkt auf so genannten Storycards die von ihm gewünschte Funktionalität. Diese Beschreibung der Anforderungen an das zu entwickelnde System ist aber meist wenig detailliert. Die Entwickler müssen deshalb oftmals den Kunden für Rückfragen kontaktieren. Darum sollte in einem XP Projekt ständig ein Kundenvertreter beim Team vor Ort sein, um mögliche Fragen in einem direkten Gespräch zu klären. Außerdem kann er so den Entwicklern kurzfristig Feedback für die soeben entwickelte Funktionalität geben. Der Kundenvertreter sollte dabei ein zukünftiger Nutzer des Systems sein, um die Bedürfnisse des Kunden am Besten zu repräsentieren.

3.1.2.12 Programmierrichtlinien

Um Übersichtlichkeit und Verständlichkeit des Programmcodes zu gewährleisten, müssen Programmierrichtlinien vereinbart werden, an die sich jeder Entwickler zu halten hat. Dies ist insbesondere wichtig, weil die einzelnen Programmierer ständig mit anderen Partnern zusammen arbeiten und den von anderen Entwicklern geschriebenen Programmcode refaktorisieren sollen.

3.2 Scrum

Neben XP ist Scrum wohl die bekannteste agile Methode. Sie wurde von Ken Schwaber und Jeff Sutherland entwickelt und das erste Mal auf der OOPSLA’95³ vorgestellt. Neben den beiden Hauptautoren leistete Mike Beedle einen großen Beitrag bei der Weiterentwicklung der Methode. Scrum ist ein Begriff aus der Sportart Rugby. Dabei versucht das gesamte Team durch geschickte Zusammenarbeit den Ball zu erobern.

Ken Schwaber war eigentlich ein Experte für traditionelle Entwicklungsmethoden, als er Ende der 1980er und Anfang der 1990er Jahre die Nachteile dieser Vorgehensweise erkannte und neue Wege für deren Lösung suchte. Dabei erkannte er, dass vor allem ein ganz neuer Stil im Management nötig war. Agiles Vorgehen ist nicht planbar und kann deshalb nicht immer wieder in der gleichen Art und Weise wiederholt werden. Deshalb benötigen diese Prozesse ständige Überwachung und Anpassung. Das ist mit dem Management der traditionellen Vorgehensweise nicht machbar [Highsmith02, 242].

Das Hauptaugenmerk von Scrum liegt auf dem Management von Teams. Es regelt keinerlei Programmierpraktiken wie zum Beispiel XP. Deshalb ist diese Methode auch nicht auf den Einsatz in Softwareprojekten beschränkt. Sie eignet sich für jegliche Art von Projekten, in denen neue Produkte entwickelt werden. Scrum beschreibt in erster Linie, wie ein Entwicklungsteam organisiert sein sollte, wie es am besten zusammen arbeitet und was die Aufgaben des Managements sind. Dies soll gewährleisten, in einer sich konstant verändernden Umgebung erfolgreich Systeme zu entwickeln [Abrahamsson02, 27].

[...]

---

¹ Dynamic System Development Method

² Übersetzung der agilen Werte nach [Haruschka04, 2]. Das englische Orginal ist unter www.agilemanifesto.org zu finden.

³ Conference on Object-Oriented Programming, Systems, Languages, and Applications