Agile Muster und Methoden

Manfred Steyer ist verantwortlich für den Fachbereich Software Engineering des Studienganges IT und IT-Marketing an der FH CAMPUS 02 in Graz. Zuvor war er ca. 10 Jahre lang als Projektleiter sowie Teamleiter im Bereich der Softwareentwicklung für ein großes österreichisches Systemhaus tätig. Steyer hat berufsbegleitend IT studiert und stellt sein Expertenwissen zurzeit als Buch- und Magazinautor (.Net-Magazin) unter Beweis. Daneben ist er seit einigen Jahren als ausgebildeter Trainer im Bereich der Erwachsenenbildung tätig.

1;Inhaltsverzeichnis;6
2;Einleitung;10
2.1;1.1 Aufbau dieses Buchs;11
3;Ausgewählte klassische Vorgehensmodelle;12
3.1;2.1 Wasserfallmodell;12
3.2;2.2 Spiralmodell;15
4;Ausgewählte agile Methoden;18
4.1;3.1 Das agile Manifesto;18
4.2;3.2 Extreme Programming (XP);19
4.3;3.3 Scrum;23
4.4;3.4 Die Crystal-Methodenfamilie;25
4.5;3.5 Crystal Clear und Orange;28
5;Katalog agiler Muster;32
5.1;4.1 Überblick;32
5.2;4.2 Organisatorische Muster;34
5.3;4.3 Anforderungsbezogene Muster;69
5.4;4.4 Technische Muster;93
5.5;4.5 Zusammenfassung;102
6;Überlegungen zu agilen Mustern und Methoden;106
6.1;5.1 Agile Muster und Fixpreisprojekte;106
6.2;5.2 Verwenden von agilen Mustern;107
6.3;5.3 Einführen agiler Methoden;107
7;Agile Methoden als Musterkompositionen;110
7.1;6.1 Crystal Clear;110
7.2;6.2 Crystal Orange;112
7.3;6.3 Scrum;112
7.4;6.4 Extreme Programming;113
8;Zusammenfassung;116
9;Einrichten einer agilen Arbeitsumgebung;120
9.1;A. 1 Subversion ( SVN);120
9.2;A.2 Automatisierte Tests;130
9.3;A. 3 Continuous Integration mit Hudson;135
10;Das agile Manifesto;150
10.1;B. 1 Werte;150
10.2;B.2 Prinzipien;150
11;Literaturverzeichnis;152
12;Stichwortverzeichnis;156

5 Überlegungen zu agilen Mustern und Methoden (S. 105-106) 5.1 Agile Muster und Fixpreisprojekte Eine häufige Frage, die im Zusammenhang mit iterativen Modellen und agilen Mustern auftritt, ist, wie sie bei Fixpreisprojekten anzuwenden seien. Auf den ersten Blick scheinen sich diese mit solchen Projekten nicht vereinbaren zu lassen, da sie ein ständiges Ändern des Umfangs erlauben. Im Grunde ist die Vorgehensweise diesbezüglich ähnlich wie bei Verwendung klassischer Modelle, z. B. des Wasserfallmodells: Bei jedem Änderungswunsch gilt es abzuwägen, ob er im Rahmen des Projekts realisiert wird, oder ob es dazu einer separeten Beauftragung bedarf. Alternativ dazu kann auch ein geplantes und budgetiertes Leistungsmerkmal gegen die Änderung getauscht werden. Damit sich der Auftraggeber entsprechend absichern kann, wird in solchen Projekten die Iteration Zero naturgemäß etwas schwergewichtiger ausfallen als in Projekten, in denen vom Auftraggeber lediglich ein bestimmtes Stundenkontingent gekauft wird. Darüber hinaus wird man sich bei solchen Projekten vielleicht auch eher für den Einsatz von Use Cases als für User Stories entscheiden, da mit diesen mehr Informationen festgehalten werden können und mit ihnen somit eine größere juristische Sicherheit einhergeht. Vor einem agilen Hintergrund gilt allerdings auch hier die Regel, abzuwägen, wie viel methodisches Gewicht in den einzelnen Bereichen des Projekts wirklich nötig ist. Idealerweise kauft der Auftraggeber ein bestimmtes Stundenkontingent, über das er nach den Regeln der festgelegten agilen Methode verfügen kann. Die Erfahrung hat gezeigt, dass Kunden in Folgeprojekten, nachdem eine Vertrauensbasis zwischen Auftraggeber und Auftragnehmer etabliert werden konnte, zu solch einer Vorgehensweise bereit sind – vor allem dann, wenn es gelingt, ihnen klar zu machen, dass es sich dabei um eine Win-Win-Situation handelt: Der Auftragnehmer muss weniger Arbeit in das Schätzen und Ausformulieren von Use Cases oder anderen Anforderungsdokumenten investieren und kann die verrechnete Zeit so stärker zur Umsetzung der gewünschten Software nutzen. Darüber hinaus würde der Auftragnehmer bei einem Fixpreisprojekt etwas Puffer einrechnen, was bei dieser Vorgehensweise ebenfalls nicht notwendig ist.