Möglichkeiten der agilen Softwareentwicklung - lippo

Transcription

Möglichkeiten
der agilen Softwareentwicklung
in einer konservativen Umgebung
Hochschule Bremen
Fakultät Elektrotechnik und Informatik
Masterstudiengang Informatik „Komplexe Softwaresysteme“
Gutachter
Prof. Dr.-Ing. Andreas Spillner
Dipl.-Ing. Thorsten Reinken
Master-Thesis
Patrick Rehder (199379), 03.08.2012
>>> Erklärung
I.
Master-Thesis
Erklärung
Ich versichere, die vorliegende Master-Thesis ohne Hilfe Dritter und nur mit den angegebenen
Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die den Quellen entnommen wurden,
sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch
keiner Prüfungsbehörde vorgelegen.
Bremen, den 3. August 2012
Patrick Rehder
(Ort, Datum)
(Unterschrift)
Patrick Rehder
2
>>> Hinweise
II.
Master-Thesis
Hinweise
Danke!
Ich möchte insbesondere den Kollegen aus der Business-Unit „Externe Produkte“ (Commerz Systems
GmbH) danken. Sie standen mir immer rasch mit Rat und Antworten zur Seite. Vielen Dank!
Anonymisierung
Folgende Namen wurden zwecks Anonymisierung frei erfunden: Rot AG, ASTAT, NIOB, TANTAL.
Ähnlichkeiten oder Übereinstimmungen mit echten Projekten und Firmen sind rein zufällig und nicht
beabsichtigt.
Legende
Englische Eigennamen werden kursiv dargestellt.
Zum Beispiel: Extreme Programming.
Abkürzungen und Übersetzungen werden in runde Klammern eingefasst.
Zum Beispiel: Mit freundlichen Grüßen (MFG).
Werden Wörter im Glossar erklärt, wird dies beim ersten Vorkommen wie folgt dargestellt: Glossar.
Verweise auf Quellen werden in eckige Klammern eingefasst. Zum Beispiel: [5] oder [18, p. 17].
Bei digitalen Quellen ohne Seitenzahlen wird das Kapitel genannt. Zum Beispiel: [2, p. 'Vorwort']
Beiliegender Datenträger
Auf dem beiliegenden Datenträger befinden sich:

Eine PDF-Version dieser Master-Thesis.

Jeweils eine PDF-Version zu genutzten und frei verfügbaren Onlineinhalten.
Hilfreiches und verwendete Werkzeuge
Dieses Dokument wurde mithilfe von Microsoft Office Word 2010 erstellt.
Skizzen von Benutzeroberfläche wurden unter Verwendung von Balsamiq Mockups designet (siehe
www.balsamiq.com).
Das Buch slide:ology von Nancy Duarte gab wertvolle Hinweise zum Entwickeln von Präsentationen,
welche im Master-Seminar angewendet wurden und im Kolloquium angewendet werden.
Patrick Rehder
3
>>> Kurzfassung
Master-Thesis
III. Kurzfassung
Im Zentrum dieser Arbeit steht die agile Softwareentwicklung, welche im Rahmen einer Abteilung
der Commerz Systems GmbH betrachtet wird.
Der Einstieg erfolgt über das Agile Manifest, welches die Werte einer agilen Vorgehensweise einfängt
und als Grundstein der Agilität zu betrachten ist. Die im Folgenden umfassend betrachteten agilen
Prozesse zeigen konkrete Lösungen für eine agile Softwareentwicklung auf. Betrachtet werden
Scrum, Feature Driven Development und Extreme Programming. Es zeigt sich, dass die Prozesse in
vielen Punkten unterscheiden und jeder über eigene Stärken und Schwächen verfügt.
Um das Vorgehen bei der Softwareentwicklung für die Abteilung zu bestimmen, werden drei abgeschlossene Projekte betrachtet. Es wird ein allgemeines Vorgehensmodell entwickelt, genutzte
Methoden identifiziert und eine Umfrage durchgeführt. Als Ergebnis wird festgehalten, dass die
Abteilung bereits eine agile Kultur aufweist oder zumindest auf dem Weg dorthin ist.
Auf den vorherrschenden Bedingungen in der Abteilung werden Scrum und Extreme Programming
als passende Vorgehensmodelle identifiziert und deren mögliche Einführung betrachtet. Als Alternative wird ein Ansatz aufgezeigt, um das bisherige Adaptieren von Methoden systematisch fortzuführen.
Patrick Rehder
4
>>> Inhaltsverzeichnis
Master-Thesis
IV. Inhaltsverzeichnis
I.
Erklärung ..........................................................................................................................................2
II.
Hinweise ..........................................................................................................................................3
III. Kurzfassung ......................................................................................................................................4
IV. Inhaltsverzeichnis ............................................................................................................................5
1.
2.
Einleitung .........................................................................................................................................7
1.1.
Motivation .............................................................................................................................7
1.2.
Ziele .......................................................................................................................................8
1.3.
Vorgehen ...............................................................................................................................8
1.4.
Umfeld ................................................................................................................................ 10
Grundlagen: Agile Softwareentwicklung ...................................................................................... 11
2.1.
Agile Manifest..................................................................................................................... 11
2.2.
Scrum .................................................................................................................................. 16
2.3.
2.4.
2.5.
3.
2.2.1.
Rollen .................................................................................................................. 18
2.2.2.
Ereignisse ............................................................................................................ 21
2.2.3.
Artefakte ............................................................................................................. 25
2.2.4.
Das Zusammenspiel ............................................................................................ 31
Feature Driven Development ............................................................................................. 32
2.3.1.
Rollen .................................................................................................................. 33
2.3.2.
Prozesse .............................................................................................................. 36
2.3.3.
Nachbetrachtung ................................................................................................ 40
Extreme Programming ....................................................................................................... 42
2.4.1.
Werte .................................................................................................................. 44
2.4.2.
Prinzipien ............................................................................................................ 46
2.4.3.
Methoden ........................................................................................................... 49
2.4.4.
Rollen .................................................................................................................. 58
2.4.5.
Nachbetrachtung ................................................................................................ 58
Zusammenfassende Betrachtung ....................................................................................... 60
Derzeitiges Vorgehen ................................................................................................................... 61
3.1.
Business-Unit „Externe Produkte“ (CtB10) ........................................................................ 61
3.2.
Vorgehensmodell ............................................................................................................... 63
3.2.1.
Vorgehensmodell: ASTAT .................................................................................... 64
3.2.2.
Vorgehensmodell: NIOB...................................................................................... 65
3.2.3.
Vorgehensmodell: TANTAL ................................................................................. 66
3.3.
Techniken und Methoden .................................................................................................. 67
3.4.
Umfrage in der Business-Unit ............................................................................................ 73
3.4.1.
Entwicklung des Fragebogens ............................................................................. 73
3.4.2.
Auswertung der Antworten ................................................................................ 77
Patrick Rehder
5
>>> Inhaltsverzeichnis
3.4.3.
4.
Master-Thesis
Fazit zur Umfrage ................................................................................................ 80
Mögliches Vorgehen ..................................................................................................................... 81
4.1.
4.2.
Einsatz eines bestimmten Vorgehensmodells.................................................................... 82
4.1.1.
Warum nicht Feature Driven Development? ...................................................... 83
4.1.2.
Scrum als eine Möglichkeit ................................................................................. 83
4.1.3.
Extreme Programming als andere Möglichkeit .................................................. 85
Einsatz eines eigenen Vorgehensmodells .......................................................................... 86
4.2.1.
4.3.
Continuous Method Evaluation .......................................................................... 87
Nachbetrachtung ................................................................................................................ 92
5.
Ergebnis ........................................................................................................................................ 94
A.
Glossar .......................................................................................................................................... 96
B.
Abbildungsverzeichnis ................................................................................................................ 100
C.
Tabellenverzeichnis .................................................................................................................... 101
D.
Quellenverzeichnis ..................................................................................................................... 102
E.
Anhang ........................................................................................................................................ 106
Patrick Rehder
6
>>> Einleitung
1.
Master-Thesis
Einleitung
Im Mittelpunkt dieser Master-Thesis steht die agile Softwareentwicklung. Da dieses Gebiet sehr
umfassend ist, muss der betrachtete Bereich eingeschränkt werden. Die Antworten zu folgenden
Fragen helfen dabei:

Warum dieses Thema?
Unterkapitel 1.1: Motivation (Seite 7)

Welche Ziele hat diese Arbeit?
Unterkapitel 1.2: Ziele (Seite 8)

Was kann wie erreicht werden?
Warum dieses Vorgehen und kein anderes?
Unterkapitel 1.3: Vorgehen (Seite 8)

Gibt es bereits Arbeiten zu diesem Thema?
Wenn ja, wo fließen diese Arbeiten ein?
Unterkapitel 1.4: Umfeld (Seite 10)
1.1.
Motivation
Das Thema wurde in der Business-Unit „Externe Produkte“ entwickelt, einer Abteilung der Commerz
Systems GmbH. Die Commerz Systems GmbH ist ein mittelständisches Unternehmen mit etwa 350
Mitarbeitern, verteilt auf zwei Standorte: Frankfurt am Main und Bremen. Es handelt sich bei der
Commerz Systems GmbH um eine 100%ige Tochter der Commerzbank. Der Mutterkonzern gibt vor,
dass sich das Geschäftsfeld der Commerz Systems GmbH auf die Commerzbank beschränken soll. Da
die Commerzbank Inhaber und Kunde zugleich ist, wird das Vorgehen bei der Softwareentwicklung
maßgeblich durch die Commerzbank beeinflusst.
Agile Vorgehensweisen werden in der Commerzbank nur vereinzelt eingesetzt. Es ist das Ziel der
Bank erst Erfahrungen zu sammeln. Dies lässt sich beispielsweise am Beta-Status der hauseigenen
Scrum-Erweiterung erkennen, dem Information Technology Project Management Framework Agile.
Derzeit wird ein agiles Vorgehen von der Commerzbank weder aktiv beworben, noch verlangt.
Einige Mitglieder der Business-Unit „Externe Produkte“ beschäftigen sich schon seit längerem mit
agilen Ideen im Allgemeinen und Scrum im Speziellen. Sie halten ein agiles Vorgehen für wünschenswert und setzen sich dafür ein. Dies ist der Grund dafür dass einzelne Elemente in der Business-Unit bereits ausprobiert wurden und gegebenenfalls weiter eingesetzt werden. Flächendeckend
sind in der Business-Unit „Externe Produkte“ nur die eingesetzten Elemente bekannt.
Die Motivation begründet sich damit auf dem Interesse für agile Vorgehenswesen in der BusinessUnit „Externe Produkte“.
Patrick Rehder
7
>>> Einleitung
1.2.
Master-Thesis
Ziele
Agile Softwareentwicklung betrachten
Diese Master-Thesis soll einen Überblick über die agile Softwareentwicklung geben. Dieser Überblick
soll jedem Mitglied der Business-Unit „Externe Produkte“ dazu dienen, sich ein Gesamtbild von agilen
Vorgehensmodellen zu machen. Folgende Punkte der agilen Softwarentwicklung werden betrachtet:

Werte und Prinzipien im Rahmen vom Agile Manifest1

Prozesse, welche weit verbreitetet sind

Methoden im Kontext der Prozesse
Vorgehen analysieren und dokumentieren
Da aktuell (März 2012) kein größeres Entwicklungsprojekt von der Business-Unit „Externe Produkte“
durchgeführt wird, stehen die letzten drei Projekte2 im Fokus: ASTAT, NIOB und TANTAL. Das Vorgehen in den genannten Projekten soll analysiert und dokumentiert werden, wobei insbesondere auf
die agilen Elemente einzugehen ist.
Mögliches Vorgehen zeigen
Es sollen Möglichkeiten erarbeitet werden, wie ein agiles Vorgehen weiter zu intensivieren ist.
Folgende Punkte sind zu betrachten:

Einsatz eines bestimmten agilen Prozesses

Erweiterung des derzeitigen Vorgehens um weitere agile Elemente
1.3.
Vorgehen
In diesem Kapitel wird erläutert, welches Vorgehen zum Erreichen der Ziele genutzt wird. Die Ziele
finden sich in der Gliederung der Arbeit wieder (siehe Tabelle 1).
Ziel
Kapitel
Grundlagen: Agile Softwareentwicklung
(Kapitel 2, ab Seite 11)
Derzeitiges Vorgehen
Mögliches Vorgehen
Tabelle 1 - Gegenüberstellung der Ziele und Kapitel
1
2
Das agile Manifest wird in Kapitel 2.1 (ab Seite 12) erläutert.
Die Projekte ASTAT, NIOB und TANTAL werden in Kapitel 3.1 (ab Seite 71) erläutert.
Patrick Rehder
8
>>> Einleitung
Master-Thesis
In jedem der aufgezählten Kapitel wird ein Ziel behandelt. Die Kapitel werden ihrer Anordnung nach
abgearbeitet. Folgendes spricht für diese Reihenfolge:

Die Business-Unit „Externe Produkte“ setzt bereits agile Methoden ein. Um diese identifizieren zu können, werden zunächst die Grundlagen zur agilen Softwareentwicklung erarbeitet.

Das derzeitige Vorgehen soll als Basis für das mögliche Vorgehen dienen.
Beim Erarbeiten der Grundlagen werden die am weitest verbreiteten agilen Prozesse betrachtet.
Hierzu wurden vier Umfragen zusammengefasst (siehe Tabelle 2).
Agilität wird
Mainstream:
Ergebnisse der
Online-Umfrage
[1, p. 1]
Forrester/Dr.
Dobb’s Global
Developer
Technographics
Survey [2, p. 2]
State of Agile
Servey
[3, p. 4]
Softwaretest in
der Praxis
[4, pp. 8, 9]
Jahr
2008
2009
2010
2011
Teilnehmer
207
1.298
4.770
248
Scrum
(21%)
Scrum
(10,9%)
Scrum
(58%)
Scrum
(57%)
FDD
(17%)
FDD
(3,8%)
Scrum/XP Hybrid
(17%)
FDD
(5,2%)
XP
(14%)
XP
(2,9%)
XP
(4%)
XP
(4,0%)
-
Crystal
(0,3%)
FDD
(2%)
Crystal
(0,4%)
Quelle
Verbreitung
(Ausschnitte!)
Tabelle 2 - Ausschnitte aus Umfragen zur Anwendung agiler Prozesse
Diese drei Prozesse wurden am Häufigsten genannt:

Scrum

Feature Driven Development (FDD)

Extreme Programming (XP)
Der Umfang, mit dem die agilen Prozesse behandelt werden, ergibt sich aus der Zielgruppe. Die
Prozesse sind so zu beschreiben, dass alle Mitglieder der Business-Unit „Externe Produkte“ ein
gemeinsames Verständnis der agilen Softwarentwicklung aufbauen. Auf Basis dieses gemeinsamen
Verständnisses besteht die Möglichkeit, einen agilen Prozess zu etablieren oder weitere agile Methoden einzuführen. Die Grundlagen sollen außerdem als Nachschlagewerk für einzelne Bestandteile
der agilen Softwareentwicklung genutzt werden.
Als Möglichkeit für ein zukünftiges Vorgehen sollen die agilen Prozesse Scrum, Feature Driven
Development und Extreme Programming unter den vorherrschenden Bedingungen betrachtet
werden.
Patrick Rehder
9
>>> Einleitung
Master-Thesis
Bisher wurden agile Methoden vereinzelt erprobt und gegebenenfalls adaptiert. Es soll auch untersucht werden, ob es eine Alternative darstellt, den eigenen Prozess systematisch um weitere agile
Methoden anzureichern.
1.4.
Umfeld
Der Hype zur agilen Softwareentwicklung ist ungebrochen. Es wird viel in Blogs, Artikeln und Büchern
darüber geschrieben und auf Konferenzen präsentiert und diskutiert. Viel wichtiger ist, dass das agile
Vorgehen in der Praxis angekommen ist. Dies kann den folgenden Umfrageergebnissen entnommen
werden:

2008, 1. Quartal - Agilität wird Mainstream: Ergebnisse der Online-Umfrage 2008 [1]
36% der 207 Befragten gaben an agil vorzugehen.

2009, 3. Quartal - Forrester/Dr. Dobb’s Global Developer Technographics Survey [2]
35% der 1.298 Befragten gaben an agil vorzugehen.

2010, 3. Quartal - Agile Softwareentwicklung am Standort Deutschland [5]
44% der 237 Befragten gaben an bereits Erfahrungen mit agilen Methoden gesammelt zu
haben.

2011, 2. Quartal - Umfrage 2011: Softwaretest in der Praxis [4]
28% der 1.211 Teilnehmer gaben an ein agiles Vorgehensmodell zu nutzen.
Aufgrund der zunehmenden Verbreitung und dem vorherrschenden Interesse gibt es viele Informationsquellen zur agilen Softwareentwicklung. Eine gelungene Übersicht bietet die Broschüre „Agile
Softwareentwicklung - Ein Überblick“ [6], welche jedoch nicht die gewünschte Tiefe dieser MasterThesis erreicht. Die Grundlagen werden aus verschiedenen Quellen zusammengetragen, wobei sich
auf die Werke der Erfinder konzentriert wird. Auf die verwendete Literatur wird in den entsprechenden Kapiteln verwiesen.
Möglichkeiten zur Einführung agiler Prozesse und Methoden werden in der Literatur bereits vielfach
genannt. Hier ist beispielsweise ein Kapitel aus dem Buch von Boris Gloger zu nennen: „Einführung
von Scrum in großen Projekten und Organisationen“ [7, pp. 273-352]. Es gibt aber auch ganze
Bücher, die sich mit dem Thema beschäftigen: „A Practical Guide to Feature-Driven Development“
[8], „Extreme Programming Applied: Playing to Win“ [9] und „Agile Projekte mit Scrum, XP und
Kanban in Unternehmen durchführen“ [10]. Diesen Werken werden hilfreiche Ideen und Ratschläge
entnommen, um Möglichkeiten für das weitere Vorgehen zu bestimmen.
Speziell auf Banken bezogene Werke werden in dieser Arbeit mangels öffentlicher Verfügbarkeit
nicht einbezogen. Allerdings wurde Feature Driven Development bei einem Projekt in einer Bank
entwickelt. Hierauf wird in der Literatur jedoch ausschließlich historisch Bezug genommen und nicht
auf den Prozess selber.
Patrick Rehder
10
>>> Grundlagen: Agile Softwareentwicklung
2.
Master-Thesis
Grundlagen: Agile Softwareentwicklung
Nach dem Agile Manifest werden die folgenden drei agilen Prozesse betrachtet:

Scrum

Feature Driven Development

Extreme Programming
2.1.
Agile Manifest
Februar 2001, Snowbird Ski Resort (Nord Amerika): Siebzehn anerkannte und erfahrene Softwareentwickler3 mit ähnlichen Ideen trafen sich für ein Wochenende, um sich über das Vorgehen in der
Softwarenentwicklung auszutauschen. Dieses Treffen kann als Geburtsstunde der agilen Softwareentwicklung bezeichnet werden. Die Teilnehmer einigten sich auf den Begriff der „Agilität“, welcher
seither verwendet wird. Außerdem wurde das Agile Manifest [11] verfasst, welches die Gedanken
hinter der agilen Softwareentwicklung einfängt und von allen Teilnehmern anerkennend unterzeichnet wurde. [12, pp. 5, 6] [13, pp. vii, viii, ix]
Doch was macht das Agile Manifest aus? – Es sind die Werte, die vom Manifest beschrieben werden.
Sie sind die Basis für ein gemeinsames Verständnis der agilen Softwareentwicklung.
wichtiger
wichtig
Individuen und Interaktionen
Prozesse und Werkzeuge
funktionierende Software
umfassende Dokumentation
Zusammenarbeit mit dem Kunden
Vertragsverhandlungen
Reagieren auf Veränderung
Befolgen eines Plans
Abbildung 1 - Die Werte vom Agile Manifest
Das Agile Manifest nennt acht Bereiche der Softwareentwicklung, die paarweise miteinander verglichen werden (siehe Abbildung 1). Hierbei handelt es sich um einen wertenden Vergleich, der immer
3
zum Beispiel: Ken Schwaber (Scrum), Jeff Sutherland (Scrum) und Kent Beck (Extreme Programming)
Patrick Rehder
11
Master-Thesis
einen Bereich als wichtiger und wertvoller herausstellt. Durch diese Wertung entsteht ein Bild, auf
was es in der agilen Softwareentwicklung ankommt.
Im Zusammenhang mit der Wertung ergibt sich oft das Missverständnis, dass die agile Softwareentwicklung ohne Prozesse, ohne Dokumentation, ohne Verträge und ohne Planung auskommt. Dies
stimmt nicht: Die Werte auf der rechten Seite werden zwar nicht primär verfolgt, sie sind aber
dennoch wichtig.
Warum agile Methoden sinnvoll sind geht nur indirekt aus dem Agile Manifest hervor. Folgendes
spricht dafür:
Individuen und Interaktion sind wichtiger als Prozesse und Werkzeuge
Das Wesen der Softwareindustrie liegt in der Verarbeitung von Wissen. Genauer gesagt der Abbildung von Prozessen und Arbeitsabläufen in Software. Diesem Umstand wird sich in der Softwareentwicklung traditionell über Ideen der Massenfertigung4 genähert. Es wird versucht Arbeitsabläufe in möglichst kleine Einheiten zu zerbrechen, die von spezialisierten Mitarbeitern ausgeführt
werden: Analysten analysieren, Architekten entwerfen, Programmierer programmieren und Tester testen. Jeder Mitarbeiter übernimmt hierbei immer ähnliche Aufgaben. Dies führt im besten
Fall zu einer hohen Produktivität und im schlechtesten Fall zur Ermüdung und Demotivation des
Mitarbeiters. [14, p. 28 f.]
Die oft verwendete Bezeichnung „Ressource“ verdeutlich, dass Menschen aus Prozesssicht betrachtet werden und nicht als Individuum. Der dahinterliegende Gedanke ist aus Prozesssicht
wünschenswert, aber nicht realistisch: Wenn zwei Menschen die Anforderungen gemäß Prozessdefinition erfüllen, können sie einfach ausgetauscht werden. Das im gleichen Zusammenhang
gerne erwähnt wird, wie wichtig der „Faktor Mensch“ ist, wirkt widersinnig. [15]
Dieser Widerspruch wird vom Manifest zugunsten des Menschen entschieden.
Das Manifest hebt außerdem die Interaktion zwischen den Beteiligten hervor. In traditionellen
Prozessmodellen wird selbstverständlich auch miteinander interagiert, allerdings meist über Dokumente. Zu nennen ist das Wasserfallmodell, welches bei Phasenübergängen prozessbedingt
Dokumente verlangt. Das Weiterreichen von Informationen über Dokumente führt jedoch zu einem immensen Wissensverlust. [12, p. 18] Der Grund hierfür liegt in der Kommunikationsart „Papier“. In Abbildung 2 werden unterschiedliche Kommunikationsarten hinsichtlich Effektivität und
Vielfalt des Kommunikationskanals (Sprache, Gestik, …) aufgeführt. Die Gedanken hierzu stammen ursprünglich von Alistair Cockburn [16, p. 84] und wurden von Scott Amber übernommen
und erweitert. [17, p. 84]
Wie Tom DeMarco und Timothy Lister bereits 1987 festhielten, sind die größten Probleme nicht
technologischer sondern soziologischer Natur. [18, p. 5]
4
Schülerduden Wirtschaft: „Bei der Massenfertigung werden gleiche Erzeugnisse über eine längere Zeit hinweg in großen
Mengen hergestellt.“ [67, p. 139]
Patrick Rehder
12
Master-Thesis
hoch
Effektivität der
Kommunikation
Diskussion
Gespräch
Gespräch mit Hilfsmitteln
(z.B. Whiteboard)
Videokonferenz
Telefon
E-Mail Videoaufnahme
Tonaufnahme
Dokumentation
Papier
niedrig
Vielfalt des
Kommunikationskanals
hoch
Abbildung 2 - Kommunikationsarten zur Diskussion und Dokumentation [17, p. 84]
Funktionierende Software ist wichtiger als eine umfassende Dokumentation
Der Zweck der Softwareentwicklung ist es Softwaresysteme zu entwickeln, die dem Anwender
einen Nutzen bringen. Dieser Nutzen kann nur von einem funktionierenden System erbracht
werden, nicht von einer umfassenden Dokumentation. Die Dokumentation kann ein funktionierendes System aus Anwendersicht höchstens unterstützten, so dass das System leichter zu verstehen ist oder die Weiterentwicklung beschleunigt wird.
Da das primäre Ziel der Softwareentwicklung darin besteht Software zu entwickeln, ist es nur logisch sich auf die Entwicklung von Software zu konzentrieren. Das alleinige Erstellen von Dokumenten führt dazu, dass sich der Kunde in falscher Sicherheit wiegt. Ihm wird ein Fortschritt
aufgezeigt, der ihm keinen Nutzen bringt. Es ist nicht zielstrebig mit einer umfassenden Dokumentation zu beginnen – dieses Vorgehen wird besser durch „Dokumentationsentwicklung“ beschrieben, nicht durch Softwareentwicklung. [9, p. 17] [17, pp. 6, 7]
Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
Im Buch „The Art of Lean Software Development“ wird die 80/20 Regel genannt. Diese besagt,
dass in der Regel 80% der Anforderungen des Anwenders durch 20% der Funktionen abgedeckt
werden. Außerdem wird auf eine Studie aus dem Jahr 2001 verwiesen, die 400 Projekte über einen Zeitraum von 15 Jahren betrachtet hat und herausfand, dass weniger als 5% des erzeugten
Quelltextes genutzt werden. [12, p. 17] Dies zeigt, dass es wichtig ist, mit dem Kunden und dem
Anwender zusammenzuarbeiten. Die Anforderungen des Kunden müssen hinsichtlich des Nutzens bestimmt werden, es gilt „goldene Wasserhähne“ zu vermeiden.
Die Zusammenarbeit mit dem Kunden wird im Manifest wichtiger eingestuft, als die Verhand-
Patrick Rehder
13
Master-Thesis
lung von Verträgen. Hierzu passt eine Aussage von Traian Kaiser5, die er auf dem ScrumDay 2011
machte. Sinngemäß: „Verträge sind weder produktiv, noch risikominimierend, noch transparent!“. Anstatt Geld in Juristen zu investieren, die sich damit beschäftigen was passiert, wenn
das Projekt scheitert, könnte das Geld bereits in die Entwicklung fließen und Nutzen für den
Kunden generieren.
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Einen Plan zu machen ist sinnvoll. Sich auf den Plan zu beziehen ebenfalls – zumindest solange
der Plan nicht von der Realität abweicht. Einen veralteten Plan mit Scheuklappen zu verfolgen ist
sogar kontraproduktiv. Schließlich wird Zeit investiert um in eine falsche Richtung zu arbeiten,
anstatt auf Abweichungen zu reagieren. [16, p. 179]
Softwareprojekte unterliegen einer hohen Wahrscheinlichkeit für sich verändernde Bedingungen. Die Tatsache dass Software von und für Menschen entwickelt wird, reicht aus um dies zu
verdeutlichen. Menschen können sich irren, Fehler machen, sich falsch verstehen oder ihre
Meinung ändern. Der Wert einer Software definiert sich über deren Nutzen für den Kunden. Da
die Welt während der Entwicklung nicht still steht, können sich die Anforderungen schnell wieder ändern. Wird nicht auf Veränderungen reagiert, sinkt der Wert der Software. Außerdem
werden neue Ideen, Wünsche und Probleme meist erst erkannt, wenn eine Aufgabe im Detail
bearbeitet wird. [14, p. 44]
Es wird von Software sogar erwartet veränderbar zu sein. Durch Software werden Probleme gelöst, die schwierig zu überblicken sind und sich ändern. Andernfalls würde es sich anbieten die
Lösung direkt über Hardware zu realisieren. [9, pp. 9, 10]
Die zwölf Prinzipien helfen dabei, die Idee hinter dem Agile Manifest besser zu verstehen. Ins Deutsche übersetzt, lauten sie wie folgt [11]:

„Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.“

Anforderungsänderungen sind auch spät in der Entwicklung willkommen. „Agile Prozesse
nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

„Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und
bevorzuge dabei die kürzere Zeitspanne.“

„Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.“

„Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“
5
Traian Kaiser (XING AG, Director Agile Project Management und PMO)
Patrick Rehder
14
Master-Thesis

„Funktionierende Software ist das wichtigste Fortschrittsmaß.“

„Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer
sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.“

„Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.“

„Einfachheit -- die Kunst, die Menge nicht getaner Arbeit zu maximieren -- ist essenziell.“

„Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte
Teams.“

„In regelmäßigen Abständen reflektiert das Team wie es effektiver werden kann und passt
sein Verhalten entsprechend an.“
In der Umfrage „Forrester/Dr. Dobb’s Global Developer Technographics Survey“ wurden die Prozesse
zur Softwareentwicklung in drei Kategorien unterteilt [2, p. 2]: agile, iterative und phasenorientierte6
Prozesse. Doch was unterscheidet die agile von der iterativen Softwareentwicklung? – Nach der
Ausarbeitung dieses Unterkapitels wird der Unterschied klar. Bei der agilen Softwareentwicklung
geht es in erster Linie um die im Manifest genannten Werte. Es geht nicht um den Prozess selbst,
welcher beim iterativen Vorgehen im Vordergrund steht.
6
In der Studie werden phasenorientierte als Wasserfall-Prozesse bezeichnet, was als nicht so passend empfunden wurde.
Patrick Rehder
15
2.2.
Master-Thesis
Scrum
Die Basis von Scrum liegt in der empirischen Prozesssteuerung. Diese geht davon aus, dass Wissen
aus Erfahrung gewonnen wird und dass Entscheidungen aufgrund bekannter Tatsachen getroffen
werden. [19, p. 4] Sofern sich Prozesse exakt definieren lassen, werden in der Praxis normalerweise
definierte anstelle empirischer Prozesse verwendet. Dies ist allerdings nur möglich, wenn die einzelnen Zwischenschritte vom Prozess anschaulich beschrieben werden können. Ist dies nicht der Fall, ist
die Komplexität der Zwischenschritte zu hoch. Als Indikator hierfür kann der Aufwand zur Nachbesserung der Produktqualität genutzt werden. Ist der Aufwand zu hoch, ist eine empirische Prozessteuerung in Betracht zu ziehen. [20, p. 3] In der Massenfertigung stellt sich die Frage: definiert oder
empirisch? In der Softwareentwicklung lautet die Antwort klar: empirisch. Der Prozess der Softwareentwicklung weist eine hohe Komplexität auf. Dies wird von Ken Schwaber in „Agiles Projektmanagement mit Scrum“ weiter erläutert, siehe hierzu [20, p. 4].
Der Scrum Guide nennt drei Säulen (siehe Abbildung 3). Auf diese stützt sich die empirische Prozesssteuerung und damit auch Scrum.
Transparenz
„Die wesentlichen Aspekte
des Prozesses müssen für
diejenigen Personen erkennbar sein, die für das
Prozessergebnis verantwortlich
sind.
Transparenz
erfordert, dass diese Aspekte
durch einen gemeinsamen
Standard definiert sind, so
dass Beobachter ein gemeinsames Verständnis über das
Beobachtete teilen.“
Überprüfung
„Scrum Anwender müssen
ständig die Scrum Artefakte
und den Fortschritt auf dem
Weg zur Erreichung des Ziels
überprüfen, um unerwünschte Abweichungen zu entdecken. Die Häufigkeit der
Überprüfungen sollte […]
nicht so hoch sein, dass die
eigentliche Arbeit dadurch
behindert wird. Der größte
Nutzen kann aus einer
Überprüfung
gezogen
werden, wenn sie ständig
durch sachkundige Personen
am Ort des Geschehens
vorgenommen wird.“
Anpassung
„Wenn bei einer Überprüfung festgestellt wird, dass
einer oder mehrere Aspekte
des Prozesses außerhalb
akzeptabler Grenzen liegen
und das Produktergebnis
dadurch ebenfalls nicht zu
akzeptieren sein wird, muss
so schnell wie möglich eine
Anpassung des Prozesses
oder des Arbeitsgegenstandes vorgenommen werden,
um weitere Abweichungen
zu minimieren.“
Abbildung 3 - Scrum: „Die drei Säulen der empirischen Prozesssteuerung“ [19, p. 4]
Es geht bei Scrum darum Transparenz zu schaffen, um das Vorgehen bewerten und anpassen zu
können. Ein Kollege hat passend hierzu einen Satz von einem Seminar mitgebracht: „Scrum löst deine
Probleme nicht von alleine. Es sorgt nur dafür, dass sie sichtbar werden und wehtun.“ Daran schließt
sich folgender Gedanke an: „Einsicht ist der erste Schritt zur Besserung.“
Patrick Rehder
16
Master-Thesis
Der Scrum Guide enthält eine interessante Beschreibung: „Scrum ist ein Framework, dass die Entwicklung komplexer Produkte unterstützt.“ [19, p. 5] Scrum kann also zur Entwicklung von Produkten
genutzt werden. Damit ist es nicht auf die Softwareentwicklung beschränkt.
Der Erklärung von Scrum als Begriff bleibt der Scrum Guide jedoch schuldig. Übersetzt bedeutet er
Gedränge – und zwar im Kontext der Sportart Rugby. „Zwei Mannschaften stehen sich in einem
kreisförmigen Gebilde […] gegenüber und versuchen gemeinschaftlich den Gegner daran zu hindern,
Raum zu gewinnen […].“ [14, p. 10] Die Idee, Rugby metaphorisch zu nutzen, stammt nicht von Ken
Schwaber oder Jeff Sutherland7 selbst, sie entspringt einem Artikel, der die Beiden faszinierte. [21, p.
2] Hirotaka Takeuchi und Ikujiro Nonaka beschrieben in „The New New Product Development
Game“, dass eine hohe Qualität, geringe Kosten und die Abgrenzung zu anderen Produkten alleine
nicht ausreichen, um sich auf dem heutigen Markt (1980er) hervorzutun. Es ist ebenfalls nötig schnell
und flexibel zu agieren. Der „Rugby“-Ansatz (auch ganzheitlicher Ansatz genannt) verspricht diese
Anforderungen an die Produktentwicklung besser zu erfüllen – ein Team versucht gemeinsam als
Einheit voranzukommen. [22, pp. 2, 3] Unter der Überschrift „Moving the Scrum downfield“ erläutern sie, welche Eigenschaften der Produktentwicklungsprozess in führenden Unternehmen aufweist.
[22, p. 4] Der Begriff „Scrum“ wird in dieser Überschrift das erste Mal erwähnt.
Abbildung 4 - Scrum: „Der Begriff als Zeichnung“ [www.scrum-kompakt.de]
7
Ken Schwaber und Jeff Sutherland sind die Schöpfer von Scrum.
Patrick Rehder
17
Master-Thesis
In den folgenden Unterkapiteln werden die einzelnen Bestandteile vom Scrum Framework erläutert.
Da sich einige der betrachteten Begriffe gegenseitig bedingen, soll Tabelle 3 die Orientierung erleichtern:
Rollen
Seite
Ereignisse
Seite Artefakte
Seite
Product Owner
18
Sprint
21
Vision
25
Scrum Master
19
Sprint Planning 1 + 2
22
Sprint Ziel
26
Entwicklungs-Team
19
Grooming
22
Product Backlog
27
Kunde
20
Daily Scrum
23
Sprint Backlog
28
Anwender
20
Sprint Review
23
Impediment Backlog
29
Manager
20
Sprint Retrospektive
24
Releaseplan
29
Definition of Done
29
Produkt-Inkrement
30
Tabelle 3 - Scrum: „Register der Bestandteile“
2.2.1. Rollen
Rollen werden im Rahmen von Scrum als Container für Verantwortlichkeiten gesehen. Es ist nicht
möglich, in eine Rolle eingesetzt zu werden. Der betroffene Mitarbeiter muss die Rolle freiwillig
übernehmen; die Entscheidung liegt bei ihm. Es existiert auch keine Idealbesetzung für eine Rolle
durch eine bestimmte Position8. [14, pp. 73-75]
Zu den Rollen im Detail: Product Owner, Scrum Master und Entwicklungs-Team sind im offiziellen
Scrum Guide [19, pp. 5-8] aufgeführt. Kunde, Anwender und Manager werden zusätzlich von Boris
Gloger [14, pp. 14, 15] genannt.
Product Owner
Der Product Owner (PO) ist verantwortlich für die Eigenschaften und die Wertschöpfung des Produkts. Hierzu erledigt er die folgenden Aufgaben:

Er entwickelt die Vision, um alle am Projekt beteiligten Personen anzutreiben und für ein gemeinsames Verständnis zu sorgen.

Er vermittelt die Bedeutung und Dringlichkeit des Projekts.

Er erstellt, verbessert und entfernt Einträge im Product Backlog gemeinsam mit dem Entwicklungs-Team.

8
Er priorisiert die Einträge im Product Backlog nach dessen Geschäftswert.
Position meint in diesem Fall eine Position in einem Unternehmen, wie Abteilungsleiter oder Vorstand.
Patrick Rehder
18

Master-Thesis
Er steht als primärer Ansprechpartner für fachliche Fragen vom Entwicklungs-Team zur Verfügung.

Er nimmt die vom Entwicklungs-Team umgesetzten Einträge des Product Backlogs im Sprint
Review ab. [14, p. 95] Dies geschieht unter Berücksichtigung der Akzeptanztests und der Definition of Done.

Er beendet das Projekt, wenn die Wirtschaftlichkeit nicht mehr gegeben ist. [23, p. 221]
Scrum Master
Der Scrum Master ist verantwortlich für die korrekte Anwendung von Scrum und der Beseitigung von
Impediments (deutsch: Hindernisse). Hierzu erledigt er die folgenden Aufgaben:

Er sorgt dafür, dass Scrum von allen Beteiligten verstanden und gelebt wird.

Er pflegt das Impediment Backlog und sorgt dafür, dass die darin enthaltenen Impediments
gelöst werden.

Er unterstützt das Entwicklungs-Team und den Product Owner, im Sinne von „fördern“, nicht
im Sinne von „Aufgaben übernehmen“. Letzteres soll die Ausnahme bleiben. [14, p. 112]
Der Scrum Master lässt sich gut mit einem Trainer vergleichen. Beide schaffen ein ideales Umfeld für
ihr Team und sorgen dafür, dass das Team zu Höchstleistungen aufläuft.
Entwicklungs-Team
Das Entwicklungs-Team ist dafür verantwortlich, dass alle Einträge im Sprint Backlog zum Ende des
Sprints fertiggestellt sind. Hierzu werden folgende Aufgaben vom Entwicklungs-Team bewältigt:

Das Entwicklungs-Team organisiert sich selbst. Es arbeitet nicht auf Anweisung von „Oben“.

Das Entwicklungs-Team hält täglich ein Daily Scrum ab.

Das Entwicklungs-Team schätzt den Arbeitsumfang der Einträge des Product Backlogs.

Das Entwicklungs-Team stellt das Sprint Backlog auf Basis der verfügbaren Kapazität9 zusammen und gibt die Zusage, alle Einträge im kommenden Sprint fertigzustellen.

Das Entwicklungs-Team erstellt im Sprint Planning 2 Aufgaben zu den Einträgen im Sprint
Backlog.

Das Entwicklungs-Team demonstriert die fertiggestellten Einträge des Sprint Backlogs im
Sprint Review.
Ein Entwicklungs-Team muss interdisziplinär aufgestellt sein. Es müssen alle Kompetenzen und
Fertigkeiten zur Bewältigung des Projekts vorhanden sein. Dies ist hinsichtlich der Größe des Entwicklungs-Teams zu berücksichtigen. Das Entwicklungs-Team darf nicht zu klein sein, da dies die Wech9
Die Kapazität setzt sich aus der Anzahl der Entwickler und ihrer verfügbaren Zeit zusammen. Bekannte Abwesenheiten,
wie Fortbildungen, Urlaub und private Angelegenheiten sind abzurechnen.
Patrick Rehder
19
Master-Thesis
selwirkungen innerhalb des Teams reduziert; aber auch nicht zu groß, da dies einen erhöhten Koordinationsaufwand bedeutet. Der Scrum Guide nennt drei Personen als Minimum und sieben Personen als Maximum. [19, p. 6]
Hinsichtlich ihrer Bezeichnung werden alle Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Egal ob sie mehr entwickeln, eher testen oder sich lieber um die Architektur kümmern. [19,
p. 6]
Kunde
Der Kunde ist für die Finanzierung des Projekts verantwortlich. Hierfür verlangt er einen Gegenwert:
die zu entwickelnde Software. Der Wert für den Kunden entsteht durch den Nutzen, den die Software erbringt. [14, pp. 118, 119]
Es bietet sich meist an, dass die Rolle des Product Owners von einem Kunden besetzt wird. Dies ist
jedoch nicht zwingend notwendig. Eine Trennung zwischen Kunde und Product Owner hat den
Vorteil, dass der Product Owner damit näher ans Team rückt; er ist schließlich kein „Externer“. [14,
pp. 118, 119]
Anwender
Die Rolle des Anwenders bringt keine Verantwortung mit sich. Er ist derjenige, der das Produkt
benutzen wird. Deswegen stellt er eine wesentliche Informationsquelle dar, die aktiv vom Team
abgerufen werden soll. Letztlich soll die zu erstellende Anwendung einen Nutzen für den Kunden
generieren. Dieser Nutzen wird jedoch maßgeblich durch den Anwender beeinflusst. Nur wenn die
Software vom Anwender ohne Probleme eingesetzt werden kann, kann der beabsichtigte Nutzen
generiert werden. [14, pp. 120, 121]
Manager
Der Manager ist dafür verantwortlich, die idealen Rahmenbedingungen für alle Scrum Teams zu
schaffen. Hierzu übernimmt er die folgenden Aufgaben:

Er beseitigt die vom Scrum Master aufgezeigten Impediments, da er über die notwendigen
Befugnisse verfügt.

Er kümmert sich um das Umfeld der Scrum Teams. Beispielsweise ermöglicht er das Bereitstellen von Büroausstattung und Infrastruktur.

Er beobachtet die Scrum Teams und nimmt sich Zeit für sie.
Da sich das Scrum Team selbst organisiert befürchten viele Manager, dass sie überflüssig werden.
Vor allem das mittlere Management hegt diese Ängste. Sie sind jedoch unbegründet. Das mittlere
Management kann die Rolle Manager annehmen. Es ist jedoch umzudenken: Aus anweisenden
Führungskräften werden unterstützende Führungskräfte. Sie empfangen und verarbeiten Impulse
aus den Scrum Teams, anstatt Anweisungen von Oben zu erteilen. [14, pp. 121, 124]
Patrick Rehder
20
Master-Thesis
2.2.2. Ereignisse
Für jedes Ereignis wird in Scrum ein Start- und Endzeitpunkt definiert. Das sich ergebende Zeitfenster
soll dafür sorgen, dass Besprechungen nicht ausufern und Ereignisse besser in den Tagesablauf
eingeplant werden können. Wenn das Zeitfenster nicht ausreicht, muss ein neues vereinbart werden
– das bestehende Zeitfenster wird nicht einfach verlängert. Dieses Vorgehen wird in Scrum als
Timeboxing bezeichnet. Damit keine Zeit von Kollegen verschwendet wird ist außerdem Pünktlichkeit geboten. [19, p. 8], [14, p. 183]
Sprint
Der Sprint stellt das größte Zeitfenster im Scrum Prozess dar und dient als Container für die Produktentwicklung und kleinere Ereignisse. In der Praxis wird die Länge üblicherweise in Wochen festgelegt.
Ein Sprint dauert entweder eine, zwei, drei oder vier Wochen, wobei die Obergrenze von einem
Monat durch den Scrum Guide festgelegt wird. [19, p. 8] Die Sprintdauer soll während eines Projekts
immer gleich sein, um für Kontinuität und Sicherheit zu sorgen. Aus diesem Grund haben Ereignisse
im Sprint auch ihren festen Platz. Ein Sprint beginnt immer mit dem Sprint Planning und endet mit
dem Sprint Review und der Retrospektive. Außerdem hält das Entwicklungs-Team an jedem Tag, zur
selben Uhrzeit ein Daily Scrum ab. Einzig das Grooming (deutsch: Körperpflege) hat keinen festen
Zeitpunkt oder Rhythmus.
Außerdem bietet der Sprint den nötigen Raum für eine kontinuierliche Verbesserung. Im Sprint sind
die Phasen vom Shewhart Cycle zu erkennen: plan, do, check, act (siehe Tabelle 4). Beim Shewhart
Cycle handelt es sich um ein anerkanntes Vorgehen, welches bei mehrfacher Iteration sowohl
Prozess, als auch Produkt verbessern kann. Bekannt gemacht wurde der Shewhart Cycle in den 50ern
durch Dr. W. Edwards Deming, weswegen er auch unter dem Namen Deming Cycle anzutreffen ist.
[14, pp. 48, 49]
Sprint
Grooming
Produktentwicklung
Daily Scrum
Shewhart Cycle
plan
do
Sprint Review
check
act
Tabelle 4 - Scrum: „Der Shewhart Cycle im Sprint“ [14, p. 49]
Zeitlich betrachtet steht der größte Teil des Sprints für die eigentliche Produktentwicklung zur
Verfügung – etwa 80%. In der folgenden Tabelle 5 ist eine Rechnung abgebildet, die auf Basis eines
vierwöchigen Sprints, die empfohlenen Zeitfenster je Ereignis darstellt und die verbleibende Zeit zur
Produktentwicklung berechnet.
Patrick Rehder
21
160,00 Stunden
=
Master-Thesis
(100%)
Stunden im Sprint
Stunden
Stunden
Stunden
Stunden
Stunden
Stunden
(2,5%)
(2,5%)
(7,5%)
(≈3%)
(2,5%)
(≈2%)
Sprint Planning 1
Sprint Planning 2
Grooming
Daily Scrums
Sprint Review
128,25 Stunden
(≈80%)
verbleibende Zeit zur Produktentwicklung
4,00
4,00
12,00
4,75
4,00
3,00
(4 Wochen á 40 Stunden)
(5-10% je Sprint [14, p. 184])
(19 Tage10 á 15 Minuten)
Tabelle 5 - Scrum: „Zeit zur Produktentwicklung in einem vierwöchigen Sprint“ [19]
Als Ergebnis soll jeder Sprint ein potentiell auslieferbares Produkt-Inkrement liefern. [19, p. 16]
Bevor mit der Entwicklung begonnen werden kann, ist zu bestimmen, was in diesem Sprint zu
erledigen ist und wie dies getan werden soll. Hierzu dient das Sprint Planning.
Im ersten Teil vom Sprint Planning wird ausschließlich das „was“ betrachtet. „Der Product Owner
stellt dem Entwicklungs-Team die geordneten [und geschätzten] Einträge des Product Backlogs vor
und das gesamte Scrum Team verschafft sich gemeinsam ein Verständnis über die […] zu verrichtende Arbeit.“ [19, p. 10] Danach erfolgt die Auswahl der fertigzustellenden Backlog Items durch das
Entwicklungs-Team. Entscheidend sind hierbei Priorität und Arbeitsumfang der Backlog Items.
Letzteres steht im Bezug zur Kapazität des Entwicklungs-Teams. In den ersten Sprints muss das
Entwicklungs-Team seine Kapazität abschätzen. Später ist es möglich die Auswahl anhand von
Erfahrungen der vergangenen Sprints zu treffen. Nach der Auswahl sucht das Scrum Team gemeinsam eine passende Beschreibung für diesen Sprint: das Sprint Ziel.
Der zweite Teil dreht sich um das „wie“. Sprich: Welche Aufgaben sind zu erledigen, um die ausgewählten Backlog Items fertigzustellen. Der Product Owner muss beim Sprint Planning 2 nicht
zwingend anwesend sein. Ist er anwesend, können jedoch Fragen des Entwicklungs-Teams direkt
geklärt werden.
Für beide Planungsrunden gilt: „Nicht der Plan, […] die Artefakte [oder] die Dokumente […] sind der
Kern. Am Ende zählt nur das Bild in den Köpfen der Beteiligten.“ [14, p. 134]
Grooming
In der Praxis finden sich häufig alternative Bezeichnungen zu Grooming [14, p. 184]:
10

Estimation Meeting

Pre-Planning Meeting

Release-Planning Meeting
Die 19 Tage ergeben sich daraus, dass am Tag des Sprint Plannings kein Daily Scrum durchgeführt wird.
Patrick Rehder
22
Master-Thesis
Aus diesen Begriffen lässt sich schon besser deuten, was sich hinter Grooming verbirgt. Beim Grooming wird das Product Backlog durch den Product Owner und das Entwicklungs-Team gepflegt. Als
wichtigster Bestandteil werden die Backlog Items vom Entwicklungs-Team auf ihren Arbeitsumfang
geschätzt. Die Schätzung erfolgt relativ in einer imaginären Einheit. Als Referenz dient hierbei ein
leicht zu überblickendes Backlog Item. Der Grund für die relative Schätzung liegt darin, dass nur der
Umfang des Backlog Items betrachtet werden soll und nicht der Aufwand. Es soll das „was“ und
nicht das „wie“ betrachtet werden.
Für das Grooming gibt es keine festen Vorgaben, wie oft und wann es in einem Sprint stattfinden
muss. Zu Beginn eines Projekts kann es sinnvoll sein, mehrere Termine anzusetzen, da das Product
Backlog erfahrungsgemäß einer größeren Veränderung unterliegt. Später kann es genügen, ein
Grooming je Sprint durchzuführen. [14, p. 185] Es ist jedoch wichtig, dass das Grooming im Sprint
Planning berücksichtigt wird, damit der Sprint weiterhin planbar ist.
Daily Scrum
Das Daily Scrum dient zur Abstimmung des Entwicklungs-Teams untereinander. Das Daily Scrum
wird täglich durchgeführt und dauert nie länger als 15 Minuten. In diesen 15 Minuten muss jeder
Entwickler die folgenden drei Fragen möglichst knapp beantworten [14, p. 200], [19, p. 11]:

Was habe ich seit dem letzten Daily Scrum erreicht?

Was will ich bis zum nächsten Daily Scrum erreichen?

Welche Impediments sind dabei im Weg?
Wenn Probleme oder Fragen auftauchen, die nicht innerhalb weniger Sekunden besprochen werden
können, müssen diese unabhängig vom Daily Scrum geklärt werden.
Sprint Review
Im Sprint Review demonstriert das Entwicklungs-Team die fertiggestellten Backlog Items. Die
Vorbereitung hierfür soll möglichst gering ausfallen. Zur Orientierung nennt Ken Schwaber den
maximalen Zeitraum einer Stunde [24, p. Appendix A]. Dies ist eine realistische Obergrenze, denn die
Entwickler müssen lediglich festlegen, in welcher Reihenfolge welcher Entwickler welches Backlog
Item vorstellt. Außerdem werden nur abgeschlossene Backlog Items präsentiert. Der Geschäftswert
eines Backlog Items ergibt sich ausschließlich aus der vollständig brauchbaren Funktion. [14, p. 209]
Um die Funktion darzustellen, wird das aktuelle Produkt-Inkrement genutzt. Beim Sprint Review soll
sich herausstellen, was funktioniert und was nicht – dies ist im Sinne der Transparenz. Nach der
Demonstration entscheidet der Product Owner ob ein Backlog Item als fertiggestellt gilt oder nicht.
Die Vorführung ist aber nicht nur für den Product Owner interessant. Sie kann von allen Interessenten dazu genutzt werden, sich über den aktuellen Stand des Projekts zu informieren. Außerdem
sollen alle relevanten Interessenvertreter (Product Owner, Kunde, Anwender) über ihre Eindrücke
berichten, um daraus neue Einträge im Product Backlog zu gewinnen oder vorhandene zu aktualisieren.
Patrick Rehder
23
Master-Thesis
Die Idee der Retrospektive bringt Holger Koschek gut auf den Punkt: „Sie ist der Schlüssel zur Prozessverbesserung, gibt die Teamstimmung wieder […] [und] deckt Motivationsprobleme auf. Wer auf
die Retrospektive verzichtet, […] verzichtet auf die Möglichkeit sich kontinuierlich zu verbessern und
sein Projektvorgehen an veränderte Bedingungen anzupassen.“ [10, p. 25]
Jeder Sprint endet mit einer Retrospektive – einem Rückblick11. In diesem Ereignis beantwortet das
Scrum Team die folgenden Fragen im Hinblick auf den vergangenen Sprint [23, pp. 94-100]:

Welche wichtigen Ereignisse gab es?

Was lief gut?

Was kann verbessert werden?
Die erste Frage dient dazu, sich den Sprint anhand wichtiger Ereignisse wieder ins Gedächtnis zu
rufen. Durch die zweite Frage werden gute Ereignisse und Abläufe aufgezeigt und damit bewusst
vom Team wahrgenommen. Der letzte Punkt enthält den eigentlichen Kern der Retrospektive: das
Finden von Möglichkeiten zum Verbessern.
Boris Gloger nennt einen Sechs-Punkte-Ablauf, der seiner Meinung nach den gelungenen Ablauf
einer Retrospektive garantiert [14, pp. 216-226]:
1. Sicherheit schaffen
2. Fakten sammeln
3. Funktionierende Prozesse finden
4. Nicht funktionierende Prozesse finden
5. Kompetenz zur Veränderung bestimmen
6. Priorisierung
Zum 1. Schritt: Jeder Teilnehmer soll im Rahmen einer Retrospektive frei und offen reden können,
ohne dass ihm daraus ein Nachteil entsteht. Durch die explizite Abhandlung dieses Schritts steigt die
Wahrscheinlichkeit, dass alle Mitglieder des Scrum Teams ihre wahre Meinung kundtun. Es gilt: Jede
Meinung ist willkommen und bereichert die Retrospektive.
Die Schritte zwei bis vier beantworten schlicht die oben genannten Fragen.
Nachdem die Probleme im vierten Schritt identifiziert wurden, geht es im fünften Schritt darum, die
Probleme in zwei Listen einzuteilen. Als Kriterium gilt, ob das jeweilige Problem vom Team behandelt
werden kann oder nicht.
Der letzte Schritt wird vom Team dazu genutzt, die Probleme je Liste zu priorisieren.
11
Retrospektive (lat. retrospectare „zurückblicken“) [wikipedia.org]
Patrick Rehder
24
Master-Thesis
Die Retrospektive wird nicht dazu genutzt Maßnahmen zu bestimmen. Dies wird im anschließenden
Sprint Planning gemacht. Nur so besteht die Möglichkeit Maßnahmen direkt einplanen zu können.
[25, p. 21]
2.2.3. Artefakte
Alle vom Scrum Team erzeugten Resultate werden als Artefakt bezeichnet. Die Übersicht in Tabelle 6
zeigt, dass je Quellen unterschiedlich viele Artefakte genannt werden:
Scrum Guide [19, pp. 13-16]
Boris Gloger [14, pp. 16, 17]
wibas Scrum Browser [26]
Produkt Backlog
Product Backlog
Product Backlog
Sprint Backlog
Sprint Backlog
Sprint Backlog
Inkrement
Das Produkt-Inkrement
Increment
Vision
Product Backlog Item
Sprint Goal
Sprint Goal
Selected Product Backlog
Die Aufgaben
Der Releaseplan
Das Impediment Backlog
Definition of Done
Tabelle 6 - Scrum: „Übersicht möglicher Artefakte“
Im Folgenden erläutert werden: Product Backlog, Sprint Backlog, Produkt-Inkrement, Vision, Sprint
Ziel, Releaseplan, Impediment Backlog und Definition of Done. Drei von Boris Gloger genannte
Artefakte werden nicht als eigenständiges Artefakt betrachtet. Die Product Backlog Items sind
Bestandteil vom Product Backlog und die Aufgaben sind Bestandteil vom Sprint Backlog; diese
werden im Rahmen ihres Elternelements betrachtet. Das Zwischenprodukt zwischen dem ersten und
zweiten Teil vom Sprint Planning wird als Selected Product Backlog bezeichnet. Damit handelt es
sich um eine spezielle Bezeichnung vom Sprint Backlog zu einem bestimmten Zeitpunkt, was nicht
als eigenständiges Artefakt anzusehen ist.
Vision
„Wenn Du ein Schiff bauen willst, dann trommle nicht Männer zusammen um Holz zu beschaffen, Aufgaben zu
vergeben und die Arbeit einzuteilen, sondern lehre sie die Sehnsucht nach dem weiten, endlosen Meer.“
― Antoine de Saint-Exupéry (1900-44), französischer Flieger und Schriftsteller
Ein Scrum Projekt beginnt mit einer Vision. Sie gibt dem Projekt einen Sinn und definiert das gemeinsame Ziel. [24] Die Vision muss möglichst präzise und klar sein, damit sie leicht aufgenommen wird
und in Erinnerung bleibt. Sie soll aber nicht beschreiben, wie das Ziel zu erreichen ist. Dies würde den
Raum der Lösungsmöglichkeiten unnötig einschränken. [14, p. 141] Die Vision wird vom Product
Owner entwickelt und kommuniziert.
Patrick Rehder
25
Master-Thesis
Eine Vision zu entwickeln und zu präzisieren ist keine leichte Aufgabe. Zur Orientierung kann beispielsweise das von Jim Highsmith entwickelte Schema genutzt werden [14, p. 143] [27]:
Für <Welche Kunden?>
die <Welches Bedürfnis haben die Kunden?>
ist <Wie soll das Produkt heißen?> eine <Welcher Produktkategorie gehört es an?>
die <Welchen besonderen Nutzen bringt das Produkt?>
anders als <Welche Alternative gibt es auf dem Markt?>
unser Produkt <Welches Alleinstellungsmerkmal hat unser Produkt zur Alternative?>
Hier beispielhaft ausgefüllt:
Für Besitzer eines Smartphones mit Android
die ihre Daten schützen wollen
ist FileSafe eine App
die ein bestimmtes Verzeichnis verschlüsselt
anders als Encrypt/Decrypt
wird unser Produkt über Werbung finanziert, nicht über einen Kaufpreis.
Sprint Ziel
Mit dem Sprint Ziel setzt sich das Scrum Team in jedem Sprint eine schwierige, aber durchführbare
Aufgabe. Es bietet dem Scrum Team die Möglichkeit, sich gemeinsam auf etwas zu konzentrieren. So
steht das zu erreichende Ziel im Raum und nicht die zu erledigenden Aufgaben. Außerdem sorgen
leichter Druck und eine echte Herausforderung für mehr Leistung im Scrum Team, dies zeigt die
Kreativitätsforschung, wie Boris Gloger anführt. [14, p. 188]
Unabhängig von Scrum sind gute Ziele SMART; so auch die Sprint Ziele [14, p. 189] [28, p. 120]:

Spezifisch
(Ist das Ziel verständlich und nicht zu allgemein?)

Messbar
(Kann der Erfolg des Ziels gemessen werden?)

Akzeptiert
(Hat das Ziel einen Sinn, eine Bedeutung?)

Realistisch
(Ist das Ziel überhaupt erreichbar?)

Terminiert
(Hat das Ziel einen zeitlichen Rahmen?)
Das Sprint Ziel wird im Sprint Planning 1 zwischen Product Owner und Entwicklungs-Team auf Basis
der ausgewählten Backlog Items vereinbart.
Patrick Rehder
26
Master-Thesis
Product Backlog
Das Product Backlog beschreibt „was“ entwickelt werden soll. Die gewünschten Eigenschaften,
Erweiterungen, Funktionen und Merkmale des Produkts werden in Form von Backlog Items erfasst.
[26] Ein Product Backlog Item verfügt hierzu über die folgenden Attribute [19, p. 14]:

Beschreibung

Priorität
(durch den Product Owner festgelegt)

Arbeitsumfang
(durch das Entwicklungs-Team geschätzt)
Für die Beschreibung von Backlog Items können zum Beispiel User Stories genutzt werden [29]:
Als <Benutzerrolle> will ich <das Ziel>[, so dass <Grund für das Ziel>].
Hier beispielhaft ausgefüllt:
Als Kunde will ich mich anmelden können.
Als Kunde will ich mich anmelden können, so dass ich meine bisherigen Bestellungen einsehen
kann.
Die Form des Product Backlogs ist nicht entscheidend und wird nicht vorgegeben.
Im Kapitel 2.2.1 Rollen wurde bereits erwähnt, dass der Product Owner auf Basis des Geschäftswerts
die Priorität der Backlog Items festlegt. Ein Backlog Item, dass nach der Umsetzung einen großen
Geschäftswert liefert, ist zu bevorzugen. Hierdurch ergibt sich ein optimales Kosten-NutzenVerhältnis.
Da es in der Praxis oft Missverständnisse zum Product Backlog gibt, führt Boris Gloger fünf Punkte
auf, die nicht auf ein Product Backlog zutreffen [14, pp. 146, 147]:
Das Product Backlog besteht nicht aus Anforderungen.
Das IEEE definiert „Anforderung“ wie folgt: „Eine Anforderung ist:
(1)
Eine Bedingung oder Fähigkeit, die von einem Benutzer (Person oder System) zur Lösung
eines Problems oder zur Erreichung eines Ziels benötigt wird.
(2)
Eine Bedingung oder Fähigkeit, die ein System oder Teilsystem erfüllen oder besitzen
muss, um einen Vertrag, eine Norm, eine Spezifikation oder andere, formell vorgegebene Dokumente erfüllen.
(3)
Eine dokumentierte Repräsentation einer Bedingung oder Eigenschaft gemäß (1) oder
(2).“ [30, p. 11]
Ein Backlog Item als Anforderung zu bezeichnen, ist nicht falsch. Der Inhalt eines Backlog Items
wird durch Punkt (1) beschrieben und die schriftliche Repräsentation über Punkt (3).
Boris Gloger meint an dieser Stelle, dass ein Backlog Item nicht beschreiben darf, wie etwas umzusetzen ist: „Auf der Produkt-Katalog-Hauptseite gibt es ein Displayfeld für den Preis.“ Was er als
Patrick Rehder
27
Master-Thesis
klassische Anforderung bezeichnet. Es muss wie folgt heißen: „Als Kunde kann ich den Preis eines
Buches einfach erkennen, so dass ich entscheiden kann, ob ich das Buch kaufe.“ [14, p. 146]
Das Product Backlog ist keine Spezifikation eines Produktes.
Eine Spezifikation ist sehr detailliert. Dies geht aus der Definition von Cynthia Stackpole im Rahmen der Projektmanagementmethode PMBOK hervor: “Specification. A document that specifies,
in a complete, precise, verifiable manner, the requirements, design, behavior, or other characteristics of a system, component, product, result, or service and, often, the procedures for determining whether these provisions have been satisfied. […]” [31, p. 794]
Ein Product Backlog soll diesen Detailgrad nicht erreichen. Es soll vor allem als Gedächtnisstütze
dienen und Diskussionen provozieren.
Das Product Backlog ist nie vollständig.
Der Satz findet sich im Scrum Guide – nahezu wörtlich: „Ein Product Backlog ist niemals vollständig.“ [19, p. 14] Mit nie vollständig ist gemeint, dass das Product Backlog nie fertig ist. Es ist immer möglich neue Backlog Items aufzunehmen und vorhandene Backlog Items anzupassen oder
zu verwerfen.
Das Product Backlog wird nicht alleine vom Product Owner geschrieben.
Der Product Owner ist für die Pflege des Product Backlogs verantwortlich. Er muss sie jedoch
nicht selber durchführen. Den Arbeitsumfang eines Backlog Items einzuschätzen ist ihm sogar
untersagt, da er nicht über die notwendige Kompetenz verfügt. Es ist von daher möglich, dass das
Entwicklungs-Team dem Product Owner dabei hilft, die Ideen in Form von Backlog Items zu erfassen.
Es gibt keine technischen Product Backlogs.
Eine der wichtigsten Eigenschaften von Product Backlog Items ist es, dass sie einen Geschäftswert liefern. Bei fachlichen Funktionen ist dies der Fall; bei rein technischen in der Regel nicht. Ein
Refactoring kann beispielsweise den Aufwand für andere Aufgaben reduzieren. Es liefert aber für
sich gesehen keinen Nutzen für den Kunden. Vielmehr müsste das Refactoring, als Teil der Aufgaben gesehen werden, die hierdurch schneller umgesetzt werden kann.
Sprint Backlog
Das Sprint Backlog besteht aus den im Sprint Planning 1 ausgewählten Backlog Items und den
zugehörigen im Sprint Planning 2 definierten Aufgaben. Damit stellt das Sprint Backlog die Grundlage für die Entwicklung innerhalb des Sprints dar. Das Entwicklungs-Team bedient sich an den
Aufgaben und arbeitet diese über den Sprint ab.
Patrick Rehder
28
Master-Thesis
Impediment Backlog
Das Impediment Backlog wird vom Scrum Master gepflegt und enthält alle Impediments die im
Laufe des Projekts identifiziert wurden und den Projektverlauf stören. Insbesondere das Daily Scrum
und die Sprint Retrospektive sind Ereignisse in denen Impediments benannt, beziehungsweise
aufgedeckt werden.
Für die Struktur eines Impediment Backlogs nennt Holger Koschek12 die folgenden vier Spalten [23,
p. 161]:

Bezeichnung vom Impediment

Wer kann das Impediment beseitigen? (Scrum Master, Scrum Team oder Andere)

Wann wurde das Impediment bekannt?

Wann wurde das Impediment gelöst?
Die Form ist nicht vorgegeben. Dem Scrum Master stehen alle Möglichkeiten offen.
Releaseplan
Der Releaseplan ergibt sich aus drei Faktoren [14, p. 130]:

Reihenfolge der Backlog Items auf Basis der Priorität

geschätzter Arbeitsumfang der Backlog Items

Kapazität13 des Entwicklungs-Teams
Aus diesen Faktoren kann errechnet werden, welche Funktionalität voraussichtlich in welchem Sprint
fertiggestellt wird. Der Ausblick erfolgt auf Basis des derzeitigen Wissens und muss nach jeder
Änderung der Faktoren neu berechnet werden. Hierbei wird der Releaseplan jedes Mal etwas
genauer. Der Arbeitsumfang von Backlog Items wurde auf Basis neuer Erkenntnisse noch einmal neu
geschätzt oder die Kapazität des Entwicklungs-Teams wurde nach einem Sprint aktualisiert.
Die Pflege obliegt dem Product Owner. Er hat schließlich ein Interesse daran zu wissen, welche
Funktionen in einem Release enthalten sein werden. Bei einem Release stellt der Product Owner
dem Kunden das aktuelle Produkt-Inkrement zur Verfügung. [26]
Definition of Done
Die Definition of Done soll für ein gemeinsames Verständnis im Scrum Team sorgen, wann ein
Backlog Item fertig ist. Für das Produkt bedeutet dies, dass die durch fertige Backlog Items geforderten Funktionen uneingeschränkt zur Verfügung stehen müssen.
Das gemeinsame Verständnis ist insbesondere für die Kommunikation zwischen Entwicklungs-Team
und Product Owner wichtig. Schließlich nimmt der Product Owner die Backlog Items im Sprint
12
13
Holger Koschek arbeitet als Berater und Coach für agile Vorgehensweisen bei der Holisticon AG. [23, p. ii]
Anmerkung: Die Kapazität wird bei Scrum in Form der Velocity (deutsch: Geschwindigkeit) erfasst.
Patrick Rehder
29
Master-Thesis
Review ab. Dem Entwicklungs-Team muss folglich bewusst sein, was der Product Owner verlangt.
Außerdem hilft die Definition of Done dem Entwicklungs-Team beim Schätzen der Backlog Items. Sie
gibt an, was bei der Entwicklung bedacht werden muss und damit auch was den Arbeitsumfang des
Backlog Items beeinflusst. [19, p. 16]
Die Definition of Done enthält die nicht-funktionalen Anforderungen14. [26] Bei einem frischen
Scrum Team wird der Umfang der Definition geringer ausfallen, als bei einem erfahrenen Scrum
Team. Gemäß dem Prinzip der Verbesserung wird die Definition of Done über die Zeit ausgebaut und
damit für eine Qualitätssteigerung gesorgt. [19, p. 17]
Produkt-Inkrement
Der fertige Teil eines Produkts wird bei Scrum als Produkt-Inkrement bezeichnet. Es setzt sich aus
den Funktionen aller fertiggestellten Backlog Items unter Berücksichtigung der Definition of Done
zusammen. Das Produkt-Inkrement muss zum Ende jedes Sprints in einem einsatzfähigen Zustand
sein, so dass der Product Owner es ohne weitere Anpassungen an den Kunden ausliefern kann –
auch wenn die Auslieferung tatsächlich nicht nach jedem Sprint erfolgt. [19, p. 16]
14
Eine ausführliche Erläuterung zu nicht-funktionalen Anforderungen befindet sich im ISO/IEC 25010:2011.
Patrick Rehder
30
Master-Thesis
2.2.4. Das Zusammenspiel
Nachdem die einzelnen Bestandteile betrachtet wurden, wird der Ablauf im Gesamten anhand des
Artikels „The Scrum Framework in 30 Seconds“ skizziert [32]:
1. Der Product Owner entwickelt eine Vision vom zu entwickelnden Produkt.
2. Der Product Owner erstellt mit dem Entwicklungs-Team eine Liste der gewünschten Funktionen: das Product Backlog.
3. Die einzelnen Einträge werden vom Entwicklungs-Team auf ihren Umfang geschätzt und
durch den Product Owner über ihren Geschäftswert priorisiert.
4. Im ersten Teil des Sprint Plannings wählt das Entwicklungsteam die wichtigsten Einträge aus
dem Product Backlog aus und erstellt damit das Sprint Backlog.
5. Im zweiten Teil des Sprint Plannings entscheidet das Entwicklungs-Team über die Umsetzung der Einträge des Sprint Backlogs und zerteilt diese hierzu in kleine Aufgaben.
6. Die gefundenen Aufgaben werden in einem definierten Zeitraum (ein bis vier Wochen) abgearbeitet: dem Sprint.
7. Jeden Tag informiert sich das Entwicklungs-Team gegenseitig im Daily Scrum über den Fortschritt und aufgetretene Probleme.
8. Die Pflege des Product Backlogs erfolgt während des Sprints im sogenannten Grooming.
9. Die Entwicklung endet mit dem Sprint Review, hier werden die fertiggestellten Einträge des
Sprint Backlogs am Produkt-Inkrement vorgestellt. Die umgesetzten Funktionen müssen ohne Anpassungen produktiv eingesetzt werden können.
10. Der Sprint endet mit einer Retrospektive. Diese wird vom Scrum Team dazu genutzt den vergangenen Sprint zu reflektieren und primär Maßnahmen zur Steigerung der Produktivität zu
finden.
11. Es beginnt ein neuer Sprint (siehe Schritt 4).
Dieser Kreis wird solange wiederholt bis das Kosten-Nutzen-Verhältnis kippt. Dies ist der Fall, wenn
der zu erwartende Geschäftswert die Entwicklung nicht mehr rechtfertigt.
Es existieren viele Grafiken zu Scrum, die den Ablauf übersichtlich darstellen. Insbesondere der
wibas Scrum Browser ist zu nennen. Er bietet sowohl einen schnellen Überblick, als auch detaillierte
Informationen zu den Rollen, Ereignissen und Artefakten von Scrum. Aufgrund der gelungen Übersicht wird auf eine Grafik verzichtet und auf den wibas Scrum Browser verwiesen:
 www.scrumbrowser.com
Patrick Rehder
31
2.3.
Master-Thesis
Feature Driven Development (FDD) ging aus einem gescheiterten Projekt für eine Bank hervor. Eine
externe, namhafte Firma war mit diesem Projekt betraut. Sie konzipierte über zwei Jahre und kam
letztlich zu dem Ergebnis, dass das Projekt nicht durchführbar sei. Zu diesem Zeitpunkt waren rund
dreieinhalbtausend Seiten mit Modellen der zukünftigen Software entstanden, aber noch keine
einzige Zeile Quelltext. Für den zweiten Versuch entwickelten Jeff De Luca und Peter Coad einen
neuen Prozess, der später als Feature Driven Development bekannt wurde. Sie stellten das Projekt
fertig: pünktlich und signifikant unter dem festgelegten Budget – ein glänzender Erfolg. [33, p. 1], [13,
p. 150]
Im Zuge dieses Erfolgs wurde Jeff De Luca von John Gage (Sun Microsystems) gebeten, das in der
Praxis entwickelte Verfahren aufzuschreiben. [13, p. 149] Im Jahr 1999 erschien das Buch „Java
Modeling in Color with UML“. Dessen letztes Kapitel die Überschrift „Feature-Driven Development“
[34] trägt. Ansonsten ist die Fülle an Literatur verglichen mit Scrum jedoch gering. Auch die Community (www.featuredrivendevelopment.com) macht einen verschlafenen Eindruck. Die letzten offiziellen Beiträge wurden 2008 erstellt, einzig die Liste der Zertifizierten wird aktuell gehalten. (Stand:
April, 2012)
Laut Jeff De Luca zeichnet sich Feature Driven Development dadurch aus, dass es die Bedürfnisse
aller am Entwicklungsprozess Beteiligten berücksichtig. Alle Entwickler werden mit den Aufgabenfeldern Analyse, Design und Implementierung betraut. Aufgrund von kurzen Iterationen stellen sie
häufig etwas fertig und werden dadurch regelmäßig mit neuen Aufgaben15 betraut. Manager erhalten Methoden zum Planen, Überwachen und Berichten vom Projektstatus. Außerdem wirkt das
regelmäßige Fertigstellen von Programmteilen risikominimierend. Kunden und Anwender erhalten
früh greifbare Ergebnisse und können sich darauf beziehen. [34, pp. 183, 184] [8, pp. xix, xxii]
Zusammenfassend werden Feature Driven Development folgende Eigenschaften zugesprochen [8, p.
xxii]:

Das Vorgehen erfolgt iterativ, in kleinen Zyklen.

In jedem der fünf Prozesse16 wird betont auf Qualität geachtet.

Greifbare Ergebnisse werden regelmäßig erarbeitet.

Der Projektstatus und -fortschritt wird klar und mit möglichst wenig Aufwand dargestellt.
Die Begriffe der Bestandteile von Feature Driven Development sind der aktuellen Prozessbeschreibung [35] entnommen. Einzig der Chief Modeler bildet eine Ausnahme, dies wird später erläutert.
Um die Orientierung zu erleichtern, wird in Tabelle 7 ein Überblick über die Begriffe von Feature
Driven Development gegeben.
15
16
„Developers love new things.“ [34, p. 183]
Feature Driven Development besteht aus fünf Unterprozessen, diese werden in Kapitel 2.3.2 erläutert.
Patrick Rehder
32
Rollen
Master-Thesis
Seite
Prozesse
Seite
Project Manager
33
Develop an Overall Model
36
Domain Expert
33
Build a Features List
37
Chief Modeler
34
Plan by Feature
38
Development Manager
34
Design by Feature
39
Chief Programmer
34
Build by Feature
40
Class Owner
35
Tabelle 7 - FDD: „Register der Bestandteile“
2.3.1. Rollen
Feature Driven Development verfügt über sechs Schlüsselrollen: Project Manager, Domain Expert,
Chief Modeler, Development Manager, Chief Programmer und Class Owner. Im Buch „A Practical
Guide to Feature-Driven Development“ werden noch neun weitere Rollen genannt. Diese werden
aufgrund des Umfangs nicht in dieser Arbeit erläutert. [8, pp. 28-31]
Die Übernahme einer Rolle ist nicht auf eine Person beschränkt. Es ist sowohl möglich dass eine
Person mehrere Rollen einnimmt, als auch dass eine Rolle von mehreren Personen übernommen
wird. Dies ist je nach Größe des Projekts und den damit einhergehenden Anforderungen an die Rolle
zu überlegen. [8, p. 29]
Project Manager
Der Project Manager ist dafür verantwortlich den Fortschritt darzustellen, die Kosten zu beobachten,
benötigte Ressourcen bereitzustellen und sich um das Projektteam zu kümmern. Er erkennt, beseitigt
und verhindert Störungen, die auf das Projekt einwirken. Der Project Manager soll seine Aufgabe im
Sinne eines Service verstehen. Er stellt seinem Projektteam eine ideale Umgebung zur Verfügung und
sorgt dafür, dass das Projektteam effizient arbeiten kann. [8, p. 28]
Domain Expert
Der Domain Expert benötigt ein fundiertes Verständnis vom Fachgebiet, als auch die nötigen Fähigkeiten dieses Wissen anderen Menschen verständlich zu machen. Ist eine dieser Voraussetzungen
nicht gegeben, ist der Erfolg des Projekts gefährdet. In diesem Fall geht der Domain Expert entweder
von falschen Anforderungen aus oder die Entwickler verstehen ihn nicht richtig. Außerdem muss der
Domain Expert im neuen Softwaresystem eine Verbesserung zur jetzigen Situation sehen. Wenn von
fachlicher Seite kein Mehrwert zu erkennen ist, sollte das System auch nicht entwickelt werden.
Letztlich muss der Domain Expert wissen, was sinnvoll ist und was nicht. Dies trifft auch auf den
Detailgrad der Anforderungen zu. Bei Feature Driven Development werden die Anforderungen zu
Beginn nicht bis ins kleinste Detail erfasst. Die Anforderungen werden über die Laufzeit des Projekts
immer weiter verfeinert. Dies wiederum erfordert, dass der Domain Expert erreichbar ist. [13, p.
154] [8, p. 30]
Patrick Rehder
33
Master-Thesis
Chief Modeler
In einem Interview (2007) sagte Jeff De Luca, dass er mit der Bezeichnung Chief Architect nicht mehr
zufrieden sei. Er nennt die Rolle nun Chief Modeler und begründet dies damit, dass die Rolle unter
dem alten Titel zu hoch gehandelt wurde. Der Chief Modeler soll die Domain Experts und Chief
Programmer auf Basis seiner Erfahrung anleiten und zusammenbringen – und nicht das Design in
Eigenregie entwickeln. [33, p. 4] Der Chief Modeler ist dafür verantwortlich, dass ein in sich schlüssiges Overall Design erstellt wird. Um dies zu gewährleisten benötigt er ein exzellentes technisches
Verständnis, viel Erfahrung im Modellieren und ausgeprägte zwischenmenschliche Fähigkeiten. Mit
diesen Eigenschaften organisiert und moderiert er die Treffen der Domain Experts und Chief Programmer, in denen gemeinsam das Overall Design entwickelt wird. Bei Meinungsverschiedenheiten
stellt er die letzte Instanz dar. [8, pp. 28, 29]
Feature Driven Development ist in fünf Prozesse unterteilt. Da das Overall Design bereits im ersten
Prozess entwickelt wird, wird die Rolle des Chief Modelers nur in diesem Prozess benötigt. [35, pp. 1,
2]
Development Manager
Der Development Manager ist für die störungsfreie Arbeit der Chief Programmer untereinander
verantwortlich. Sofern sich Konflikte zwischen Chief Programmern nicht direkt lösen lassen, muss
der Development Manager einschreiten und eine Lösung herbeiführen.
In kleineren Projekten bietet es sich an, die Rolle des Development Managers mit dem Chief Modeler
oder dem Project Manager zu kombinieren. [8, p. 29]
Chief Programmer
Ein Chief Programmer ist an allen Prozessen von Feature Driven Development beteiligt. Hierbei
muss er sich stets mit den anderen Chief Programmern abstimmen. Begonnen wird mit dem Overall
Design, das die Chief Programmer zusammen mit den Domain Experts unter Leitung des Chief
Modelers entwickeln. Danach bestimmen die Chief Programmer die benötigten Funktionen in Form
von Features und verteilen diese untereinander. Die Features werden nicht direkt durch die Chief
Programmer umgesetzt. Sie bilden hierzu Feature Teams, welche das Design im Detail und die
Implementierung übernehmen. [8, p. 29]
Gemäß Brooks Gesetz sorgt der Einsatz zusätzlicher Entwickler für eine Verlangsamung: “Adding
manpower to a late software project makes it later.” [36, p. 25] Jeff De Luca unterstützt diese Aussage, sagt aber auch, dass es eine Ausnahme gibt. Mit leichtgewichtigen Prozessen, die Funktionalität
möglichst klein und auf den Kundennutzen bezogen betrachten, ist es möglich weitere Entwickler
zum Projekt hinzuzuziehen und dadurch eine Steigerung der Geschwindigkeit zu erreichen. Durch
weitere Chief Programmer, können weitere Feature Teams gebildet werden, die Features parallel zu
den bestehenden Feature Teams umsetzen. Diese Skalierung ist nicht beliebig möglich, da Features
auch in Abhängigkeit zueinander stehen können. [34, p. 196]
Patrick Rehder
34
Master-Thesis
Class Owner
Über die Rolle des Class Owners, übernimmt ein Entwickler die Verantwortung für eine oder mehrere
Klassen. Er ist derjenige, der alle seine Klassen betreffenden Arbeiten durchführt. Dieses Prinzip wird
als Class Ownership bezeichnet; eine Klasse gehört einem Entwickler. Feature Driven Development
grenzt sich in diesem Punkt von Scrum und Extreme Programming ab. Letztere nutzen das gegenteilige Prinzip – Collective Ownership. Die Vorteile von Class Ownership und Collective Ownership sind
in Tabelle 8 gegenübergestellt.
Vorteile der Class Ownership
Vorteile der Collective Ownership
Der Verantwortliche für eine Klasse kennt sich in
dieser sehr gut aus. Hierdurch kann er schnell
Anpassungen vornehmen oder Auskunft über die
Funktionsweise geben ohne sich erst einarbeiten
zu müssen.
Der Sinn, Aufbau und die Funktionsweise einer
Klasse ist mehreren Entwicklern bekannt. Die
Abwesenheit eines Entwicklers kann somit besser
vom Team aufgefangen werden.
Da eine Klasse nur von einem Entwickler bearbei- Die Verteilung von Aufgaben gestaltet sich
tet wird, kann es nicht zu Versionskonflikten17 einfacher, da die Aufgaben nicht noch weiter auf
kommen.
einzelne Klassenbesitzer aufgeteilt werden
müssen.
Die Klassen eines Entwicklers weisen einen Die Auslastung der Entwickler ist einfacher zu
einheitlichen Schreibstil auf. Dies sorgt für eine gewährleisten, da nicht nur bestimmte Entwickler
bessere Lesbarkeit der Klassen.
Änderungen durchführen dürfen.
Durch die Kombination aus Verantwortung und Da die Verantwortung für den Quelltext im Team
Ehrgeiz kann ein Entwickler dazu motiviert liegt, wird die Schuld im Falle eines Fehlers vom
werden, seine Klassen möglichst effizient zu gesamten Team übernommen.
gestalten.
Da Entwickler nur ihre Klassen bearbeiten, kann Fehler werden mit einer höheren Wahrscheines nicht dazu kommen, dass ein Entwickler durch lichkeit entdeckt, da der Quelltext durch andere
das Ändern einer fremden Klasse, einen Fehler Entwickler angesehen werden muss.
verursacht.
Tabelle 8 - FDD: „Die jeweiligen Vorteile von Class Ownership und Collective Ownership“
Sofern die Klasse eines Class Owners für die Umsetzung eines Features benötigt wird, wird der Class
Owner temporär zu einem Feature Team hinzugefügt. Das Feature Team besteht aus allen Class
Ownern, die zur Umsetzung eines Features benötigt werden. Das Feature wird in Gänze durch das
Feature Team bearbeitet: es wird analysiert, entworfen, entwickelt, getestet und dokumentiert.
[33, p. 5] [13, p. 155] [34, p. 196] [8, pp. 29, 30] [37, pp. 9-11]
17
Versionskonflikte: Eine Datei wird parallel von mehreren Personen verändert, so dass die Änderungen nachträglich
zusammengeführt werden müssen.
Patrick Rehder
35
Master-Thesis
2.3.2. Prozesse
Feature Driven Development besteht aus fünf Prozessen [35]: Develop an Overall Model, Build a
Features List, Plan by Feature, Design by Feature und Build by Feature. Die Anordnung der Prozesse wird in Abbildung 5 dargestellt. Vor allem die Prozesse #4 und #5 fallen auf. Sie machen zusammen über Dreiviertel der Zeit aus und werden mindestens alle zwei Wochen erneut durchlaufen. Was
auf den ersten Blick nicht aus der Grafik hervorgeht ist, dass die fünf Prozesse insgesamt auch erneut
durchlaufen werden. Ein solcher Durchlauf darf maximal sechs Monate in Anspruch nehmen, danach
muss eine Iteration erfolgen. [6, p. 19] Die Grafik liefert einen Hinweis darauf: Es wird zwischen
initialem und fortlaufendem Anteil unterschieden wird.
Abbildung 5 - FDD: „Prozessübersicht mit zeitlicher Verteilung“ [34, p. 198]
Die fünf Prozesse werden auf Basis der aktuellsten Prozessbeschreibung [35] erläutert:
Develop an Overall Model
Im Prozess #1 wird das Overall Model des zu entwickelnden Systems erstellt. Hierzu resultiert der
Prozess in folgenden Ergebnissen:

Die zentralen Klassen sind identifiziert und werden durch ein UML Klassendiagramm in Verbindung gebracht.

Komplexe, fachliche Abläufe werden über UML Sequenzdiagramme abgebildet.

Notizen zu getroffenen Entscheidungen reichern die Diagramme an.
Der Detailgrad ist im Prozess #1 gering zu halten. Sonst besteht die Gefahr, dass sich während der
Modellierung in Detailfragen verloren wird. Diese Fragen werden in den Prozessen #4 und #5 beantwortet.
In der Prozessbeschreibung werden die folgenden Schritte genannt:
1. Der Project Manager stellt das Modeling Team aus Chief Programmern, Domain Experts
und einem Chief Modeler zusammen.
Patrick Rehder
36
Master-Thesis
2. Ein Domain Expert gibt einen Überblick über das Fachgebiet. Das Modeling Team sichtet
vorhandene Dokumente, wie beispielsweise Datenmodelle, Anforderungsbeschreibungen
oder Richtlinien.
Das Modeling Team teilt sich in kleine Gruppen auf, die maximal drei Personen umfassen. Jede
dieser Gruppen entwickelt ein mögliches Modell für das Fachgebiet. Die Ergebnisse der einzelnen
Gruppen werden anschließend dem gesamten Modeling Team vorgestellt. Für diesen Schritt kann es
hilfreich sein, wenn der Chief Modeler zuvor ein Schema vorgibt. Dies sorgt für vergleichbare Ergebnisse, schränkt aber zugleich den Lösungsraum ein.
3. Nun verständigt sich das gesamte Modeling Team unter Moderation vom Chief Modeler auf
ein gemeinsames Overall Model. Dieses kann entweder von einer Gruppe übernommen werden, eine Mischung aus verschiedenen Modellen darstellen oder auch ein neues Modell sein.
4. Die Schritte 3 und 4 werden mehrfach durchlaufen und das Overall Model bei jedem Durchlauf weiter verfeinert. Der Chief Modeler beendet diese Schleife, wenn er mit dem Ergebnis
zufrieden ist. [8, p. 133]
Während des gesamten Prozesses werden signifikante Entscheidungen schriftlich fixiert. Es wird
notiert, warum sich für etwas entschieden wurde als auch betrachtete andere Lösungen. Hierdurch
wird gewährleistet, dass die getroffenen Entscheidungen später nachvollzogen werden können.
Die Überprüfung der Ergebnisse erfolgt durch die Domain Experts. Diese können anhand des entwickelten Overall Models und den geführten Gesprächen erkennen, ob ihre Anforderungen richtig
verstanden wurden. Außerdem besteht die Möglichkeit den Kontakt mit der Fachabteilung zu
suchen.
Build a Features List
Der Prozess #2 besteht aus den folgenden Schritten:
1. Der Project Manager stellt mithilfe vom Chief Modeler und dem Development Manager das
Features List Team zusammen. Das Features List Team besteht aus den Chief Programmern, die am Prozess #1 teilgenommen haben. Domain Experts können ebenfalls beteiligt
sein. Meist gehören sie jedoch nicht zum Features List Team, sondern stehen ausschließlich
für Fragen zur Verfügung.
2. Das Features List Team identifiziert die Features auf Basis seiner Erfahrungen aus Prozess
#1. Die Features werden gruppiert und schriftlich fixiert.
Ein Feature stellt die Beschreibung einer Funktion dar, die einen Kundennutzen bringt. Der Umfang
eines Features wird durch die maximale Entwicklungsdauer eingeschränkt. Sie darf maximal 2
Wochen [6, p. 19] betragen. Außerdem erfolgt die Bezeichnung nach folgendem Muster:
<action> <result> <object>
Patrick Rehder
37
Master-Thesis
Hier zwei Beispiele:
Berechne die Summe des Warenkorbs.
Stelle eine Auswahl der möglichen Versandarten für eine Bestellung dar.
Da Features sehr granular sind, und bei großen Projekten18 in einer entsprechenden Anzahl identifiziert werden, ist es unerlässlich die Features zu strukturieren. Hierfür werden sogenannte Feature
Sets und Major Feature Sets verwendet. Ein Feature Set beschreibt eine Tätigkeit und ein Major
Feature Set ein Fachgebiet.
Das folgende Beispiel könnte der Planung einer Webpräsenz entnommen sein:
Major Feature Set
Online Shop
Feature Set
......... Bestellung durchführen
Feature
......... ......... Berechne die Summe des Warenkorbs.
Feature
......... ......... Stelle eine Auswahl der möglichen […].
Der Prozess #2 endet, wenn der Project Manager und der Development Manager mit der erstellten
Features List zufrieden sind. [8, p. 143] Zu diesem Zeitpunkt sind die Features zwar strukturiert, aber
noch nicht priorisiert. [13, p. 153]
Plan by Feature
In Prozess #3 werden die Features priorisiert und verteilt. Es wird mit folgendem Schritt begonnen:
1. Der Project Manager stellt das Planning Team aus dem Development Manager und den
Chief Programmern zusammen.
Die folgenden Schritte werden nicht der Reihe nach, sondern parallel abgearbeitet:

Das Planning Team ordnet jedem Feature Set ein Fertigstellungsdatum zu – es sind nur Monat und Jahr anzugeben.

Die Feature Sets werden unter den Chief Programmer verteilt.

Jede Klasse wird einem Entwickler zugeteilt, dem Class Owner. Wobei auch Chief Programmer Klassen übernehmen können und damit Class Owner werden.
Die parallele Bearbeitung ist notwendig, da sich die Schritte aufgrund neuer Erkenntnisse gegenseitig
beeinflussen. Außerdem müssen noch folgende Punkte bei der Planung berücksichtigt werden:
18

Abhängigkeiten zwischen Features müssen beachtet werden.

Risikoreiche und komplexe Feature Sets sollen möglichst früh realisiert werden.

Die Arbeitsbelastung von Class Ownern soll gleichmäßig verteilt sein.

Meilensteine müssen berücksichtigt werden, beispielsweise Vorabversionen.
Um eine Größe zu nennen: Im ersten FDD-Projekt wurden 2000 Features identifiziert. [13, p. 150]
Patrick Rehder
38
Master-Thesis
Die Ergebnisse von Prozess #3 werden als Development Plan bezeichnet. Es handelt sich hierbei um
eine erweiterte Features List und eine Liste mit der Zuordnung von Entwicklern auf „ihre“ Klassen:
der Class Owner List. Sofern der Project Manager und der Development Manager mit dem Development Plan zufrieden sind, wird der Prozess #3 beendet. [8, pp. 154, 155]
Design by Feature
Die lineare Abfolge der vorherigen Prozesse, wird an dieser Stelle durchbrochen; Prozess #4 wird je
Feature durchgeführt. Der Chief Programmer ist für das Durchführen der folgenden Schritte verantwortlich:
1. Der Chief Programmer stellt je Feature ein Feature Team zusammen. Ein Feature Team besteht aus allen Class Ownern, deren Klassen vom umzusetzenden Feature betroffen werden.
2. Sofern vorhanden, können referenzierte Dokumente durch das Feature Team gesichtet werden. In Abhängigkeit zur Komplexität des Features kann es sinnvoll sein, dass ein Domain
Expert dem Feature Team den Anwendungsbereich noch einmal erläutert.
3. Das Feature Team entwickelt nun ein UML Sequenzdiagramm, welches das Feature beschreibt. Wie in Prozess #1 sind signifikante Entscheidungen schriftlich zu fixieren.
4. Der Chief Programmer reichert das Overall Model mit neu identifizierten Klassen, Methoden
und Attributen an.
5. Jeder Class Owner schreibt Klassen- und Methodenkommentare für seine Klassen. Auf Basis
der Kommentare generiert der Chief Programmer die API-Dokumentation.
6. Die Ergebnisse prüft das Feature Team bei einer Inspektion19. Hierbei aufgezeigte Fehler
werden direkt durch das Feature Team behoben.
7. Jeder Class Owner erstellt je Klasse eine Liste mit durchzuführenden Aufgaben. Danach entwickelt er einen persönlichen Terminplan, in dem er notiert, wann er welche Aufgabe erledigen wird.
Das Ergebnis von Prozess #4 wird als inspiziertes Design Package bezeichnet, es setzt sich aus den
folgenden Bestandteilen zusammen:

Referenzierte Dokumente

UML Sequenzdiagramm

aktualisiertes Overall Model

generierte API-Dokumentation

Terminplan der Class Owner
19
Der Umfang oder exakte Ablauf einer Inspektion wird nicht weiter erläutert. Da es standardübergreifend keine einheitliche Definition gibt, sind Umfang und Ablauf selbst zu bestimmen.
Patrick Rehder
39
Master-Thesis
Build by Feature
Im Prozess #5 werden die Features umgesetzt. Das zuvor erarbeitete Design Package dient hierbei
als gemeinsame Basis. Die im Folgenden genannten Schritte werden je Klasse durchgeführt:
1. Der Class Owner passt die Methoden seiner Klassen so an, dass sie den Anforderungen des
Features genügen.
2. Der Quelltext wird einer Inspektion unterzogen. Hierbei sind die folgenden Szenarien durch
den Chief Programmer abzuwägen:

Keine Inspektion für triviale Änderungen durchführen. [8, p. 185]

Inspektion für mehrere Klassen in einer Sitzung durchführen.

Inspektion erst nach dem Erstellen der Unit-Tests durchführen.
3. Der Class Owner schreibt für jede Methode Unit-Tests.
4. Die Klasse wird nun durch den Class Owner freigegeben. Dieser Schritt verdeutlicht, dass die
Klasse fertig ist und bezüglich dieses Features nicht mehr bearbeitet wird. Der Grad der freigegebenen Klassen dient dem Chief Programmer als Fortschrittsmaß.
Nachdem ein Feature umgesetzt wurde, werden die Prozesse #4 und #5 erneut für weitere Features
durchlaufen.
2.3.3. Nachbetrachtung
Beim Betrachten der einzelnen Prozesse entsteht schnell der Anschein, dass Menschen bei Feature
Driven Development keinen hohen Wert besitzen. Das Gegenteil ist jedoch der Fall: Wenn die
Projektbeteiligten nicht über die benötigten Fähigkeiten verfügen, können die Prozesse noch so gut
sein – das Projekt wird mit hoher Wahrscheinlichkeit scheitern. Gute Prozesse wiederum können
guten Projektteams dabei helfen effizienter zu arbeiten. Ein gutes Projektteam stellt den Schlüssel
für ein erfolgreiches Projekt dar. Der Grund hierfür liegt darin, dass es sich bei der Softwareentwicklung um eine Aktivität zwischen Menschen handelt. [13, p. 150]
Um die Kommunikation zwischen den am Projekt beteiligten Menschen zu erleichtern, werden
Modelle gegenüber Texten bevorzugt. Durch die Nutzung von UML zur Modellierung entsteht ein
weiterer Vorteil: Mithilfe entsprechender Tools ist es möglich, das Modell und den Quelltext synchron zu halten. [13, p. 149] Generell wird bei Feature Driven Development viel Wert auf das Generieren von Inhalten gelegt (siehe API-Dokumentation in Prozess #4).
Gemäß dem agilen Manifest sollen Anforderungsänderungen zu jeder Zeit des Projekts willkommen
geheißen werden. [11] Dies wird bei Feature Driven Development über die maximale Laufzeit von
sechs Monaten für einen kompletten Prozessdurchlauf sichergestellt, als auch über die 10%Schlupfregel20. Die Begrenzung der maximalen Laufzeit sorgt dafür, dass die Anforderungen spätestens nach sechs Monaten neu betrachtet werden. Die 10%-Schlupfregel handelt noch kurzfristigere
Anforderungsänderungen ab. Sie besagt, dass eine Features List um knapp zehn Prozent anwachsen
20
Übersetzt aus dem Englischen: „10% Slippage Rule“. [8, p. 235]
Patrick Rehder
40
Master-Thesis
darf, ohne dass Maßnahmen vom Project Manager erforderlich werden. Danach muss der Project
Manager über einen der folgenden Punkte eingreifen [8, pp. 235-237]:

weniger wichtige Features streichen

Projektlaufzeit verlängern

Kapazität durch neue Chief Programmer und Entwickler erhöhen
Damit der Prozentsatz der neuen und geänderten Features nachverfolgt werden kann, empfiehlt es
sich die betroffenen Features entsprechend zu markieren. [13, p. 155]
Feature Driven Development auf einen Blick [6, p. 19]:

bietet eine elegante Strukturierungsmöglichkeit für Anforderungen

auch für große Projektteams gut geeignet

bietet durch sein Rollenmodell eine gesunde Basis für ein diszipliniertes Vorgehen

ist für Festpreisprojekte gut geeignet

lässt sich leichter als andere agile Vorgehen in große Organisationen einführen
Patrick Rehder
41
2.4.
Master-Thesis
Extreme Programming
Extreme Programming (XP) nimmt anerkannte Methoden der Softwareentwicklung und kombiniert
diese mit dem Ansatz: „Wenn ich aus Erfahrung weiß, dass etwas gut funktioniert, setze ich es im
maximal möglichen Rahmen ein.“ Kent Beck, der Erfinder von Extreme Programming, hatte hierbei
das Bild eines Steuerpults im Kopf. Jede Methode stellt darauf einen Regler dar, welcher bis zum
Anschlag aufgedreht wird. Er wollte sehen was passiert – „Überraschenderweise erwies sich dieses
Paket von [Methoden] als stabil, vorhersehbar und flexibel.“ [38, p. xv]
Abbildung 6 - XP: „Den Regler auf 10 drehen.“ [38, p. xv]
Laut Kent Beck verspricht Extreme Programming [38, p. xvi]:

Projektrisiken zu reduzieren.

Sich ändernde, geschäftliche Anforderungen zu berücksichtigen.

Die Produktivität fortlaufend zu erhöhen.

Dass Softwareentwicklung im Team Spaß macht.
Hierzu werden vier Tätigkeiten für die Entwicklung von Software genannt: Zuhören, Entwerfen,
Programmieren und Testen. Diese Tätigkeiten werden über Methoden realisiert, welche wiederum
definierte Werte und Prinzipien berücksichtigen. Der Zusammenhang wird in Abbildung 7 verdeutlicht. [39, p. 'Defining XP']
Patrick Rehder
42
Master-Thesis
Abbildung 7 - XP: „Unter der Lupe betrachtet.“
Im Folgenden werden die Bestandteile von Extreme Programming einzeln erläutert. Angefangen mit
den Werten, werden folgend die Prinzipien und zum Schluss die Methoden betrachtet. Die vier
Tätigkeiten werden nicht weiter im Detail behandelt, da diese bereits aufgelistet wurden und die
Begriffe sprechend sind. Zur besseren Übersicht sind die einzelnen Bestandteile in Tabelle 9 indexiert.
Werte
Seite Methoden
Seite
Communication
44
Energized Work
49
Simplicity
45
Whole Team
50
Feedback
45
Sit Together
50
Courage
45
On-Site Customer
51
Respect
46
Informative Workspace
51
Prinzipien
Seite User Stories
51
Rapid Feedback / Reflection
46
Weekly Cycle
52
Assume Simplicity
46
Quarterly Cycle
52
Incremental Change / Baby Steps
47
Metaphor
53
Embrace Change / Improvement
47
Slack
53
Quality Work / Quality
47
Incremental Simple Design
53
Humanity
47
Collective Ownership
54
Economics
47
Coding Standards
54
Mutual Benefit
47
Test-First Programming
55
Self-Similarity
48
Pair Programming
56
Diversity
48
Refactoring
57
Patrick Rehder
43
Master-Thesis
Flow
48
Continuous Integration
57
Opportunity
48
Ten-Minute Build
58
Redundancy
48
Failure
48
Accepted Responsibility
48
Tabelle 9 - XP: „Register der Bestandteile“
Es ist auffällig, dass das Bestandteil-Register für Extreme Programming mehr Begriffe enthält, als die
Register von Scrum und Feature Driven Development. Dies liegt daran, dass Extreme Programming
feiner strukturiert ist. Des Weiteren wird neben der ersten Version [38] auch die weiterführende
Version [40] berücksichtigt. In der weiterführenden Version wurden unter anderem neue Methoden
aufgenommen; aber auch vorhandene angepasst und umbenannt. Holger Breitling bezeichnet die
weiterführende Version in einem Artikel als Extreme Programming 2.0 und findet folgende Adjektive: „[…] nachdenklicher, durchdachter, differenzierter als das ursprüngliche XP, aber auch weniger
frisch, komplizierter und unübersichtlicher.“ [41]
2.4.1. Werte
Software wird von Menschen entwickelt. Jeder Beteiligte am Prozess, hat hierbei eine eigene Vorstellung davon, was wertvoll ist und was nicht. Für eine effektive und effiziente Zusammenarbeit der
Beteiligten ist es jedoch entscheidend eine gemeinsame Wertvorstellung zu entwickeln. Ein gemeinsames Wertverständnis sorgt dafür, dass das Vorgehen einheitlich wahrgenommen wird. Extreme
Programming nennt für eine gemeinsame Basis fünf Werte. Gemäß Kent Beck sortiert, lauten diese
wie folgt:

Communication

Simplicity

Feedback

Courage

Respect
Die Werte werden im Kommenden einzeln erläutert. Als Quelle dienen die beiden Werke von Kent
Beck, in der ersten [38, pp. 29-35] und zweiten Auflage [40, p. 'Chapter 4. Values'].
Communication
In der Softwareentwicklung lassen sich viele Probleme auf einen Mangel an Kommunikation zurückführen. Die Ausprägungen sind vielfältig. Zum Beispiel:

Aus Bequemlichkeit werden Annahmen über die Wünsche des Kunden getroffen, anstatt ihn
zu fragen.
Patrick Rehder
44

Master-Thesis
Aus Angst vor Konsequenzen werden negative Nachrichten nicht mitgeteilt.
 Aus Scham werden Probleme langwierig alleine gelöst, statt auf das Wissen eines Anderen
zuzugreifen.
Viele Methoden bei Extreme Programming verlangen deswegen explizit die Kommunikation
zwischen den Beteiligten.
Hinter dem Wert Communication verbirgt sich aber nicht nur, dass überhaupt kommuniziert wird. Es
geht auch darum über welches Medium kommuniziert wird. Dieses Thema wurde bereits im Rahmen
vom Agile Manifest erläutert (siehe „Individuen und Interaktion sind wichtiger als Prozesse und
Werkzeuge“ ab Seite 12). In Extreme Programming soll ein Gespräch stets einem anderen Medium
vorgezogen werden.
Simplicity
Der Wert Simplicity lässt sich als Einfachheit übersetzen. Dahinter verbirgt sich, dass in Extreme
Programming immer eine möglichst einfache Lösung gewählt werden soll. Die gewählte Lösung
muss hierbei den Anforderungen des Kunden genügen, aber eben nicht mehr. Sie lässt sich deswegen schneller und kostengünstiger umsetzen, als eine allgemeine Lösung. Hierbei wird in Kauf
genommen, dass eine Änderung im Nachhinein eventuell mehr kostet. Diese Ansicht ist vor allem für
den Kunden wertvoll, denn er erhält nur die Funktionen die er auch wirklich benötigt.
Feedback
Bei Extreme Programming wird davon ausgegangen, dass sich innere und äußere Begebenheiten
stets ändern können. Um sich daran anpassen zu können, müssen diese Änderungen wahrgenommen werden. Das Feedback (deutsch: Rückmeldung) übernimmt diese Aufgabe. Hierbei gilt: Feedback ist möglichst häufig einzuholen, damit Änderungen unmittelbar bekannt werden und darauf
reagiert werden kann. Als Beispiel lassen sich Unit-Tests nennen. Unit-Tests geben schnell Aufschluss
darüber, ob die getesteten Methoden so arbeiten wie erwartet. Vor dem Hintergrund späterer
Änderungen ist dies besonders hilfreich; es bildet Vertrauen ins System.
Courage
Courage bedeutet Mut, welcher bei Extreme Programming durch die Beteiligten aufzubringen ist.
Mut ist vor allem im Kontext der zuvor genannten Werte wertvoll:

Kommunikation wird gefördert, wenn der Mut aufgebracht wird unangenehme und wahre
Tatsachen offen anzusprechen. Es sorgt auch für Vertrauen.

Einfachheit wird gefördert, wenn der Mut aufgebracht wird vorhandene Lösungen zu verwerfen, um bessere Lösungen und neue Ideen zu finden.

Feedback wird gefördert, wenn der Mut aufgebracht wird nach Problemen zu suchen und
wirkliche Lösungen zu bestimmen.
Patrick Rehder
45
Master-Thesis
Respect
Ursprünglich nannte Kent Beck vier Werte. In seiner überarbeiteten Version fügte er noch einen
fünften Wert hinzu: Respekt. Die Beteiligten müssen sich sowohl gegenseitig, als auch das Projekt
respektieren – sonst funktioniert Extreme Programming nicht. Es geht bei der Softwareentwicklung
um die Menschen und ihr Miteinander: jede Meinung ist wichtig, jeder Gedanke ist wichtig, jede Idee
ist wichtig – jeder ist wichtig.
2.4.2. Prinzipien
Werte sind sehr allgemein. Es ist deswegen wahrscheinlich, dass die Werte von unterschiedlichen
Personen, unterschiedlich gedeutet werden. Aus diesem Grund nennt Extreme Programming
Prinzipien. Sie geben den Werten eine Ausrichtung.
Die erste Version nennt fünf Grund- und zehn weiterführende Prinzipien. Die überarbeitete Version
vierzehn Prinzipien. Da Kent Beck die Prinzipien hierbei komplett überarbeitet hat, ist es schwierig
die Versionen gegenüberzustellen. In der überarbeiteten Version sind sowohl bestehende, als auch
neue Ideen eingeflossen.
Im Folgenden werden zuerst die fünf Grundprinzipien der ersten Version und danach die thematisch
nicht genannten Prinzipien der überarbeiteten Version erläutert. Aufgrund des Umfangs wird darauf
verzichtet, die weiterführenden Prinzipien der ersten Version explizit zu nennen; zumal einige der
Prinzipien in den überarbeiteten Prinzipien aufgehen.
Als Quelle dienen die beiden Werke von Kent Beck, in der ersten [38, pp. 38-42] und zweiten Auflage
[40, p. 'Chapter 5. Principles'], als auch die Zusammenfassung von Eckhart Hanser [42, pp. 17-20].
Die fünf Grundprinzipien
Rapid Feedback / Reflection
Unmittelbares Feedback (engl. Rapid Feedback) und Reflexion (engl. Reflection) beschreiben den
Wert Feedback genauer. Der Gedanke hinter unmittelbarem Feedback ist, dass bereits früh Erkenntnisse gewonnen werden, so dass zeitnah darauf reagiert werden kann. Unmittelbares Feedback
ergibt allerdings nur Sinn, wenn das Team an Verbesserungen interessiert ist. Dieser Punkt wird von
der Reflexion aufgegriffen. Ein gutes Team erledigt seine Arbeit nicht nur, es überlegt wie es sich
verbessern kann.
Assume Simplicity
Hinter Assume Simplicity verbirgt sich die Idee, Probleme so zu betrachten, als seien sie ganz einfach
zu lösen. Dieses Prinzip verkörpert damit direkt den Wert der Einfachheit, welcher zuvor bereits
erläutert wurde.
Patrick Rehder
46
Master-Thesis
Incremental Change / Baby Steps
Die Prinzipien Incremental Change und Baby Steps beschreiben im Kern, dass es besser ist, immer
wieder kleine Schritte zu machen, als einmal einen Großen. Kleinere Schritte sind besser zu überblicken und damit zu kontrollieren. Dies trifft sowohl auf Änderungen am Prozess, als auch auf Entwicklungsarbeiten zu. Bei Entwicklungsarbeiten ist es außerdem hilfreich regelmäßig vorzugehen. Dies
sorgt für Routine und reduziert damit den Organisationsaufwand.
Embrace Change / Improvement
Bei der Entwicklung von Software gibt es kein perfektes Vorgehen. Es gibt nur die Möglichkeit, sein
derzeitiges Vorgehen weiter zu perfektionieren. Die eigenen Prozesse müssen ständig hinterfragt
werden, um für Verbesserung (engl. Improvement) zu sorgen. Hierbei ist es eine Grundvoraussetzung, dass alle Beteiligten auch bereit sind Veränderungen zu begrüßen (engl. embrace changes).
Quality Work / Quality
Qualität (engl. Quality) wird bei Extreme Programming als unantastbare Größe gesehen. Sie dient
nicht als Stellgröße, falls ein Projekt in Verzug gerät. Es ist ein Trugschluss zu denken, dass mindere
Qualität für eine schnellere Lieferung sorgt. Durch das Vernachlässigen von Qualität schleichen sich
Fehler ein, die nachträglich zu mehr Aufwand führen. Außerdem ist es bei einer geringeren Qualität
wahrscheinlicher, dass die gelieferte Software nicht den erwarteten Nutzen erbringt. Damit ist weder
dem Kunden, noch dem Entwicklungsteam geholfen.
Weitere Prinzipien
Humanity
Das Prinzip der Menschlichkeit (engl. Humanity) besagt: Software wird von Menschen entwickelt,
dies muss bedacht werden. Für eine optimale Leistung, müssen menschliche Bedürfnisse berücksichtigt werden. Zum Beispiel: Sicherheit des Arbeitsplatzes, persönliche Weiterbildung und Akzeptanz
im Team.
Economics
Wirtschaftlichkeit (engl. Economics) ist stets zu gewährleisten. Wenn die Kosten den Nutzen übersteigen, gibt es keine Rechtfertigung für ein Projekt. Außerdem ist folgende Regel für Investitionen zu
bedenken: Je früher Geld eingenommen wird, desto besser und je später Kosten entstehen, desto
besser. [28, p. 1309]
Mutual Benefit
Bei Extreme Programming soll kein Nutzen auf Kosten anderer, sondern gegenseitiger Nutzen (engl.
Mutual Benefit) gewonnen werden. Tätigkeiten sollen stets Vorteile für alle Beteiligten mit sich
bringen.
Patrick Rehder
47
Master-Thesis
Self-Similarity
Das Prinzip der Selbstähnlichkeit (engl. self-similarity) besagt, dass gute Lösungen auch in einem
anderen Kontext funktionieren können – dies gilt es auszuprobieren.
Diversity
Die Vielfalt (engl. Diversity) der Teammitglieder und Ideen ist ein weiteres Prinzip. Es geht darum,
dass unterschiedliche Eigenschaften und Fähigkeiten von Teammitgliedern zu völlig neuen Lösungen
führen können. Die entstehende Vielfallt an Ideen ist als Chance zu sehen: Es kann immer die beste
Idee ausgewählt werden.
Flow
Damit der Kunde den aktuellen Stand der Software nutzen und sich darauf beziehen kann, ist ein
ständiger Fluss (engl. Flow) anzustreben. Die Software soll dem Kunden schnellstmöglich zur Verfügung gestellt und danach kontinuierlich angepasst werden.
Opportunity
Jedes Problem soll bei Extreme Programming als Gelegenheit (engl. Opportunity) betrachtet werden. Gelegenheiten sich zu verbessern. Es darf nicht das Ziel sein, Probleme nur zu überstehen.
Dieses Prinzip minimiert die Schwächen und maximiert die Stärken des Teams.
Redundancy
Redundanz (engl. Redundancy) sorgt für Sicherheit, dieses Prinzip ist deswegen in kritischen und
komplexen Bereichen der Softwareentwicklung anzuwenden. Das Auffinden von Fehlern ist ein gutes
Beispiel für einen solchen Bereich, es ergibt Sinn nicht einmalig nach Fehlern zu suchen, sondern
hierfür mehrere Instanzen vorzusehen.
Failure
Ein Misserfolg (engl. Failure) kann dazu genutzt werden, Wissen zu gewinnen. So ist trial and error
ein zweckmäßiger Weg, schnell Erkenntnisse zu gewinnen. Außerdem kann es günstiger sein, eine
Lösung auszuprobieren, statt lange darüber zu diskutieren. Im Kern besagt dieses Prinzip, dass Fehler
nicht immer schlecht sind – wenn aus ihnen gelernt wird.
Accepted Responsibility
Wenn Aufgaben vorgeschrieben werden, ist es unwahrscheinlich dass sie engagiert umgesetzt
werden. Um das Engagement einer Person zu wecken, muss sie die Verantwortung für eine Aufgabe
übernehmen (engl. Accepted Responsibility). Verantwortung kann nicht zugewiesen werden. Letztlich muss nicht nur jeder die Verantwortung für seine Aufgaben übernehmen; das Team muss sich für
das Produkt verantwortlich fühlen.
Patrick Rehder
48
Master-Thesis
2.4.3. Methoden
Die Methoden von Extreme Programming geben sich wie ein Baukasten. Sie müssen nicht alle auf
einmal eingeführt werden, sondern können nach und nach etabliert werden. Der Einsatz einer
Methode führt bereits zu einer Verbesserung. Für eine entschiedenere Verbesserung müssen sich die
Methoden jedoch gegenseitig stützen. Hierbei ist es nicht sinnvoll den Einsatz einer Methode zu
erzwingen. Wenn eine Methode nicht funktioniert, ist sie nicht einzusetzen.
Die erste Version von Extreme Programming enthält 12 Methoden. In der überarbeiteten Version
sind 25 Methoden genannt, die sich in 13 primäre und 12 resultierende Methoden aufteilen. Die 12
resultierenden Methoden werden in dieser Arbeit nicht weiter erläutert, da sie erst nach den primären Methoden relevant werden. Wenn bei den verbleibenden Methoden die Übereinstimmungen
zusammengefasst werden, ergibt sich eine Summe von 18 Methoden. Die 18 Methoden wurden in
drei Kategorien eingeordnet, siehe Tabelle 10.
Allgemein
Ablauf und Planung
Entwicklung
Energized Work
User Stories
Whole Team
Weekly Cycle
Sit Together
Quarterly Cycle
Coding Standards
On-Site Customer
Metaphor
Slack
Pair Programming
Refactoring
Ten-Minute Build
Tabelle 10 - XP: „Strukturierung der Methoden“
Als Quelle dienen die beiden Werke von Kent Beck, in der ersten [38, pp. 53-62] und zweiten Auflage
[40, p. 'Chapter 7. Primary Practices'], als auch die Zusammenfassung von Eckhart Hanser [42, pp. 2140] und das Buch „Software entwickeln mit eXtreme Programming“ [43, pp. 23-120].
Allgemein
Energized Work
„Niemand kann […] über viele Wochen hinweg, 60 Stunden in der Woche arbeiten und dann immer
noch frisch, kreativ, sorgfältig und voller Selbstvertrauen sein.“ [38, p. 60] Bei regelmäßigen Überstunden kann nicht von energiegeladener Arbeit (engl. energized work) gesprochen werden. Dies
zeigt vielmehr, dass es ein Problem gibt, welches erkannt und gelöst werden muss. Wer krank oder
müde ist, wer ständig Anrufe erhält oder auf E-Mails antwortet, der kann nicht 100% seiner Leistung
erbringen.
Patrick Rehder
49
Master-Thesis
Für energiegeladene Arbeit müssen die genannten Störungen beseitigt werden: wer krank ist bleibt
zuhause, wer müde ist legt sich früher hin und wer ständig abgelenkt wird, der stellt das Telefon auf
lautlos und beendet das E-Mail-Programm. Es bietet sich an, den Arbeitstag in Abschnitte zu unterteilen: Programmierzeit, Verwaltungszeit und Pausen. In den einzelnen Abschnitten wird sich auf die
entsprechende Arbeit konzentriert. Dies gilt auch für Pausen, sie sind genauso intensiv wahrzunehmen wie die vorangegangene Arbeit.
Whole Team
Ein ganzes Team (engl. Whole Team) vereint alle Fähigkeiten in sich, die derzeit zur Bearbeitung des
Projekts benötigt werden. Es ist möglich, dass Teammitglieder im Laufe eines Projekts aufgrund ihrer
Fähigkeiten aufgenommen oder abgegeben werden. Das derzeitige Team sieht sich hierbei stets als
Ganzes, der Team-Gedanke ist wichtig – nur wenn alle an einem Strang ziehen ist die Wirkung
maximal.
Sit Together
Diese Methode besagt, dass das Team zusammensitzen (engl. Sit Together) soll. Dies ist zum einen
die Voraussetzung für andere Methoden (zum Beispiel: Pair Programming), aber auch förderlich für
den Wert der Kommunikation. Nur wenn das Team gemeinsam in einem Raum sitzt, besteht die
Möglichkeit, kurzfristig Fragen in die Runde zu werfen oder Gespräche zwischen anderen Kollegen
aufzugreifen, um hilfreiches beizusteuern.
Eine förderliche Anordnung der Büromöbel ist in Abbildung 8 skizziert. Im Zentrum des Raums
befinden sich Arbeitsplätze fürs Pair Programming und an den Wänden kleine Parzellen für ungestörte Einzelarbeit.
Abbildung 8 - XP: „Team Workspace“ [40, p. 'Figure 5. A team workspace']
Patrick Rehder
50
Master-Thesis
On-Site Customer
Die Methode On-Site Customer oder „Kunde vor Ort“ sieht vor, dass der Kunde nicht nur zu Beginn
des Projekts einmal vorbeischaut und sagt was er haben möchte, sondern täglich für Fragen zur
Verfügung steht. Hierbei ist es im Sinne der Kommunikation von Vorteil, wenn der Kunde im TeamBüro sitzt und bei Unklarheiten direkt kontaktiert werden kann.
Der Nutzen wird maximiert wenn der On-Site Customer die folgenden Punkte erfüllt:

Er verfügt über fundierte fachliche Kenntnisse.

Er arbeitet mit der zu ersetzenden Anwendung.

Er soll die zu entwickelnde Anwendung später nutzen.
Für die Entwickler gilt: Wenn die fachlichen Anforderungen nicht eindeutig sind, ist der On-Site
Customer zu fragen. Es sollen keine Annahmen von Entwicklern getroffen werden. Auch bei gleichwertigen Lösungen gilt: Nicht selber entscheiden, sondern den On-Site Customer fragen.
In der Praxis ist es meist schwierig eine Person aus der Fachabteilung zu 100% freizustellen – dies ist
erfahrungsgemäß auch nicht notwendig. Der On-Site Customer verfügt über Freiräume, in denen er
sich um seine eigentlichen Aufgaben kümmern kann. Für den Fall, dass es dem On-Site Customer
nicht möglich ist im Team-Büro zu sein, nennt Eckart Hanser eine interessante Lösung: Der On-Site
Customer erhält ein „rotes Telefon“, dessen Nummer im Idealfall nur den Entwicklern bekannt ist.
Das „rote Telefon“ kann beispielsweise ein Prepaid-Handy sein. Anrufe auf diesem Telefon werden
vom On-Site Customer schnellstmöglich entgegengenommen und zeitnah beantwortet.
Eine informative Arbeitsumgebung (engl. Informative Workspace) bietet die Möglichkeit, sich
innerhalb weniger Sekunden über den aktuellen Stand des Projekts zu informieren. Dies lässt sich
beispielsweise über die Anordnung der User Stories in Kategorien (zum Beispiel: offen, in Arbeit,
erledigt) an einer Wand erreichen. Anstatt aktuelle Messdaten21 über E-Mail zu verschicken oder auf
einer internen Webseite bereitzustellen, soll eine große Tafel im Team-Büro zum Darstellen genutzt
werden.
Ablauf und Planung
User Stories
User Stories oder Benutzergeschichten benennen Funktionen, die von der Anwendung zur Verfügung
gestellt werden sollen. Jede User Story verfügt hierbei mindestens über die folgenden Informationen:
21

Bezeichnung

Beschreibung
(zwei bis drei Halbsätze)
zum Beispiel: Fehler in Produktion oder Anzahl der Klassen
Patrick Rehder
51

Aufwand
Master-Thesis
(durch die Entwickler geschätzt)
Der geringe Detailgrad gewährleistet, dass die Informationen auf einer DIN A5 Karte Platz finden.
Hierbei ist eine physische Repräsentation, laut Kent Beck, stets einer digitalen vorzuziehen. Die User
Stories lassen sich so einfacher in Besprechungen verwalten, außerdem können sie an einer Wand
aufgehängt (siehe Informative Workspace) und anhand ihres Status sortiert werden.
Die Gesamtheit der User Stories reicht nicht aus, um das System zu spezifizieren. Eine Funktion lässt
sich nicht allein auf Basis der zugehörigen User Story umsetzen. Die kurze Beschreibung reicht nicht
aus, um die Gedanken des Kunden vollständig wiederzugeben. Dies ist gewünscht; der Entwickler soll
die Details vom Kunden erfragen. Aus diesem Grund ist es wichtig, dass der Kunde auch zur Verfügung steht.
User Stories werden zur Iterationsplanung genutzt. Alle vom Kunden gewünschten Funktionen
werden in Form von User Stories aufgeschrieben. Danach wird der Aufwand zur Umsetzung für jede
User Story von den Entwicklern geschätzt und notiert. Der Kunde erhält damit einen Überblick, wie
viel je Funktion investiert werden muss. Auf Basis dieser Information kann der Kunde die User Stories
priorisieren und damit festlegen, was zuerst umgesetzt werden soll. Die Entwickler können nun,
anhand ihrer Kapazität, die User Stories für die kommende Iteration auswählen.
Weekly Cycle
Die User Stories werden in Iterationen abgearbeitet. Zu Beginn einer Iteration werden die umzusetzenden User Stories vom Team ausgewählt. Die Auswahl erfolgt im sogenannten Iteration Planning
Meeting und wird auf Basis der Priorität für den Kunden und der Kapazität des Teams durchgeführt.
Als Zeitraum nannte Kent Beck ursprünglich ein bis vier Wochen. In der überarbeiteten Version legte
er sich letztlich auf einen wöchentlichen Zyklus (engl. Weekly Cycle) fest. Dieser sei Ideal, da er eine
natürliche Grenze hat – das Wochenende. Das Team kann sich darauf konzentrieren, die gewählten
User Stories bis zum Wochenende zu erledigen und nach dem Wochenende, ausgeruht in die neue
Iteration starten.
Am Ende der Iteration werden dem Kunden die umgesetzten User Stories vorgestellt. Dieser kann
sich ein Bild von der Umsetzung machen und unmittelbar Feedback geben. Dadurch können neue
User Stories entstehen, alte verworfen, verändert oder umpriorisiert werden. Ziel jeder Iteration ist
es, eine produktiv einsetzbare Anwendung zu haben, die den Anforderungen des Kunden genügt.
Quarterly Cycle
Der Quartalszyklus (engl. Quarterly Cycle) lehnt sich am Quartal eines Jahres an und umfasst damit
drei Monate. Dies ist der von Kent Beck empfohlene Zeitraum für ein Release. Für die Planung eines
Release ist es schwierig, den Inhalt anhand von User Stories zu überblicken. Es bietet sich an, für ein
Release Themen zu definieren. Die User Stories können dann anhand solcher Themen gruppiert
werden.
Patrick Rehder
52
Master-Thesis
Außerdem soll in jedem Quartal eine Reflexionssitzung erfolgen, in der Probleme identifiziert und
Lösungen gesucht werden.
Metaphor
Eine Metapher (engl. Metaphor) kann dazu genutzt werden, das Softwaresystem in einem übertragenen Sinn zu betrachten. Als Beispiel kann für ein Textverarbeitungsprogramm, eine Schreibmaschine als Metapher verwendet werden. Der Vorteil liegt darin, dass alle Beteiligten hierdurch eine
vertraute Vorstellung vom zu entwickelnden System erhalten. Außerdem kann eine Metapher die
Kreativität im Team anregen und zu neuen Ideen führen. Es ist jedoch nicht einfach eine gute Metapher zu finden, die gleichzeitig von allen Beteiligten auf die gleiche Weise verstanden wird.
Slack
Slack lässt sich unter anderem mit Pufferzeit oder Leerlauf übersetzten. Diese Methode wird durch
beide Begriffe in Kombination ideal beschrieben:
Jeder Plan soll über Pufferzeiten verfügen. Hierbei ist ein Teil der verfügbaren Zeit entweder gar nicht
oder mit niedrig priorisierten, notfalls wegzulassenden Aufgaben zu verplanen. Das eigentliche Ziel
bleibt damit erreichbar, auch wenn unvorhersehbare Ereignisse eintreten (zum Beispiel: Krankheit
oder Fehleinschätzung). Bleiben Pufferzeiten unangetastet, besteht immer noch die Möglichkeit,
weitere Aufgaben im Nachhinein einzuplanen.
Leerlauf bezeichnet einen Zeitraum, der nicht durch vorgegebene Aufgaben definiert wird. Die freie
Zeit soll von den Entwicklern für eigene Interessen genutzt werden, dies kann beispielsweise eine
neue Technologie oder andere Vorgehensweise sein, aber auch die Mitarbeit an einem Open Source
Projekt. Hierbei gewonnene Ideen können sich positiv auf das eigentliche Projekt auswirken.
Entwicklung
Ziel des schrittweisen, einfachen Entwurfs (engl. Incremental Simple Design) ist es, zu jedem Zeitpunkt der Entwicklung die einfachst mögliche Architektur zu haben, die den bekannten Anforderungen entspricht. Die Architektur wird beim Incremental Simple Design regelmäßig kontrolliert und
angepasst, damit sie den momentanen Anforderungen bestmöglich gerecht wird. Hierbei ist es nicht
untersagt eine grundlegende Struktur festzulegen oder Frameworks zu verwenden. Der Einsatz von
Architectural Patterns ist zum Beispiel sinnvoll, da hierdurch ein gemeinsames Verständnis der
Struktur gewährleistet wird.
Jeder Teil, eines auf einem einfachen Entwurf basierenden Systems, muss sein Vorhandensein
rechtfertigen. Das System soll die folgenden Merkmale erfüllen:

Das System besteht alle Tests.

Das System ist selbstbeschreibend.
Patrick Rehder
53

Das System einhält keinen gleichen Quelltext an verschiedenen Stellen.

Das System besteht aus so wenigen Klassen wie möglich.

Die Klassen im System enthalten so wenige Methoden wie möglich.
Master-Thesis
Die Merkmale sind hierbei in absteigender Reihenfolge zu berücksichtigen. Es ist beispielsweise
wichtiger, dass sich das System selbst beschreibt, als dass die Zahl der Klassen möglichst gering ist.
Eine beliebte Ausprägung von Incremental Simple Design ist die Quick Design Session. Eine Runde
mit wenigen Entwicklern (drei sind am besten, fünf das Maximum) trifft sich, um die Architektur des
Systems zu besprechen und weiterzuentwickeln. Es gilt die Regel: „Lieber ausprobieren, statt zu
diskutieren.“
Die Methode vom Kollektivbesitz (engl. Collective Ownership) besagt, dass das Team gemeinsam für
den Quelltext verantwortlich ist. Jeder Entwickler darf jede Stelle im Quelltext anpassen – es wird
sogar von ihm erwartet: „Von jedem, der eine Möglichkeit sieht, irgendeinen Teil des Codes etwas
Sinnvolles hinzuzufügen, wird erwartet, dass er dies jederzeit tut.“ [38, p. 59]
Hauptsächlich lassen sich die folgenden Vorteile gegenüber der Einzelverantwortlichkeit auflisten:

Der Ausfall eines Teammitglieds kann leichter kompensiert werden, da der Quelltext auch
anderen Entwicklern bekannt ist.

Oft genutzter Quelltext, wird durch mehrere Entwickler begutachtet. Fehler fallen hier mit
einer größeren Wahrscheinlichkeit auf und werden direkt behoben.

Bei Fehlern versucht der Entdecker schnellstmöglich eine Lösung zu finden und nicht einen
Schuldigen. Der Schuldige steht automatisch fest: das Team.
Bei einem stark schwankenden Qualitätsniveau im Team und in großen Softwaresystemen stößt
Collective Ownership jedoch an seine Grenzen:
Bei Ersterem ist es wahrscheinlich, dass der Quelltext von schwächeren Teammitgliedern überarbeitet und angepasst werden muss, um den Qualitätsansprüchen des Teams zu genügen. Um dieses Problem zu lösen, muss das Qualitätsniveau im Team vereinheitlicht werden. Hier eignet sich
vor allem die später erläuterte Methode Pair Programming.
Der zweite Punkt bezieht sich darauf, dass Entwickler in großen Systemen viel Zeit aufwenden,
sich in unbekannten Quelltext einzuarbeiten. Der Aufwand hierfür kann jedoch reduziert werden,
wenn die Methoden übersichtlich gestaltet und ausreichend dokumentiert sind.
Coding Standards
Coding Standards sind Richtlinien für das Programmieren. Sie geben beispielsweise vor welche Form
der Quelltext haben soll, wie Dateien und Klassen zu benennen und welche Werkzeuge einzusetzen
Patrick Rehder
54
Master-Thesis
sind. Das Vorgehen beim Programmieren soll vereinheitlich werden. Beim optimalen Einsatz von
Coding Standards ist nicht mehr zu erkennen, welcher Entwickler welchen Quelltext geschrieben
hat.
Ein Coding Standard soll den folgenden Punkten genügen:

Der Programmieraufwand soll durch die Richtlinien so gering wie möglich gehalten werden;
sonst hält sich keiner dran.

Die Richtlinien sollen kurz, einfach und klar formuliert sein; sonst liest sie keiner.

Die Kommunikation soll durch ein einheitliches Verständnis beim Programmieren gefördert
werden.

Letztlich muss das gesamte Team die Richtlinien freiwillig befolgen.
Test-First Programming22
Beim Test-First Programming wird nicht mit dem produktiven Quelltext begonnen, sondern mit
automatisierten Testfällen. Daraus ergeben sich mehrere Vorteile:

Da frisch erstellte Testfälle erst einmal fehlschlagen, können sie während der Entwicklung zur
Anzeige des Fortschritts genutzt werden.

Beim Test-First Programming kann nicht drauflos entwickelt werden. Der Entwickler muss
sich über die beabsichtigte Funktion im Klaren sein und sich Gedanken über die Schnittstelle
machen, um die Testfälle erstellen zu können.

Die Schnittstelle wird durch den Testfall von außen betrachtet, was der späteren Nutzung
entspricht. Die Schnittstelle wird damit auf ihre Nutzung optimiert.

Komplexere Komponenten lassen sich schwieriger testen, als einfachere Komponenten. Beim
Test-First Programming entstehen deswegen tendenziell, einfachere Komponenten. Wenn
sich etwas nicht gut testen lässt, ist dies meist ein Hinweis auf ein unzureichendes Design.

Testfälle prüfen, ob sich das System so verhält wie es soll. Wenn alle Testfälle ohne Fehler
durchlaufen, schafft dies Vertrauen in das getestete System. Dies ist besonders wertvoll,
wenn das System geändert oder erweitert wird.

Die beabsichtigte Nutzung einer Komponente wird durch einen Testfall dokumentiert.
Beim Extreme Programming wird zwischen zwei Test-Arten unterschieden:
Ein Komponententest oder Unit-Test bezieht sich auf eine Komponente im System. Zum Beispiel
ein Modul oder eine Klasse. Die Testfälle werden von den Entwicklern geschrieben. Für viele Programmiersprachen gibt es passende Frameworks, die das Erstellen und automatisierte Ausführen
von Testfällen vereinfachen.
22
Die Methode Test-Frist Programming wird auch beim Test-Driven Development (TDD) eingesetzt. [69]
Patrick Rehder
55
Master-Thesis
Durch Akzeptanztests oder auch Funktionstests wird geprüft, ob eine realisierte User Story den
Erwartungen des Kunden entspricht. Aus einem Akzeptanztest können diese Erwartungen extrahiert werden, was die Umsetzung erleichtert. Der Aufwand für eine automatisierte Überprüfung
ist hingegen meist unverhältnismäßig hoch. Es bietet sich deswegen an, zumindest einen Teil der
Tests manuell auszuführen.
Test-First Programming ist auch beim Beseitigen von Fehlern anzuwenden. Bevor ein Fehler behoben wird, wird ein Testfall zu diesem Fehler geschrieben. Falls der Fehler später wieder eingebaut
wird, schlägt der Test fehl und weist darauf hin.
Pair Programming
Wenn sich zwei Entwickler einen Rechner teilen und gemeinsam an einer Aufgabe arbeiten, wird dies
als Pair Programming bezeichnet. Da nur ein Entwickler zurzeit aktiv den Rechner bedient, ist der
Gedankenaustausch zwischen beiden entscheidend. Der eingebende Entwickler erklärt dem beisitzenden Entwickler warum er etwas macht und der beisitzende Entwickler weist den eingebenden
Entwickler auf Fehler hin. Die Paarungen, als auch die Rolle des Eingebenden und Beisitzenden,
sollen hierbei nicht fest vergeben sein, sondern kontinuierlich wechseln.
Es lassen sich die folgenden Vorteile aufzählen:

Je zwei Entwickler wird nur ein leistungsfähiger Entwicklungsrechner zwingend benötigt.
Mögliche Rechner an Einzelarbeitsplätzen (siehe Sit Together, Seite 50) müssen nicht über
das Leistungsniveau eines Entwicklungsrechners verfügen.

Der Quelltext und das Design unterliegen einem ständigen Review durch den Beisitzenden,
hierbei werden Fehler entdeckt und dadurch die Qualität gesteigert.

Durch den fortlaufenden Austausch von Erfahrungen, gleicht sich das Niveau zwischen unerfahrenen Entwicklern und Experten mit der Zeit an.

Wenn der eingebende Entwickler nicht weiterkommt, können die Rollen getauscht werden
und der beisitzende Entwickler übernimmt.

Da zwei Entwickler über die Lösung eines Problems nachdenken, ergeben sich neue Lösungsideen, die einem Entwickler alleine nicht eingefallen wären.

Der Ausfall eines Entwicklers kann, aufgrund des verteilten Wissens, besser vom Team kompensiert werden.

Es ist für ein Entwickler-Paar einfacher sich gemeinsam auf eine Aufgabe zu konzentrieren.
Die Zeit des Kollegen will schließlich nicht mit für ihn belanglosen Dingen23 verschwendet
werden.

Team-Praktiken werden einheitlicher gelebt, da sich ein einzelner Entwickler nicht unentdeckt darüber hinwegsetzen kann.
23
Für den Kollegen können zum Beispiel belanglos sein: Telefonate, E-Mails und Börsenkurse.
Patrick Rehder
56
Master-Thesis
Pair Programming ist eine der bekanntesten Methoden von Extreme Programming und wird
aufgrund unterschiedlichster Meinungen viel diskutiert. Insbesondere die Auswirkung auf Qualität,
Zeit- und Kostenaufwand wurde in vielen Studien untersucht. Die Anzahl an Studien ist sogar so groß,
dass es inzwischen zusammenfassende Studien gibt.
Johannes Brodwall bringt das Ergebnis der zusammenfassenden Studie „Are Two Heads Better than
One? On the effectiveness of pair programming“ in einem Online-Artikel auf den Punkt [44]: Pair
Programming sorgt dafür, dass ein Projekt etwas früher fertig wird, mit einer signifikant besseren
Qualität, aber zu höheren Kosten. Er bemängelt jedoch, dass die folgenden Punkte in der Studie nicht
berücksichtigt werden:

Eine bessere Qualität sorgt langfristig für geringere Kosten.

Der Ausfall eines Entwicklers kann durch Wissensteilung besser kompensiert werden.

Der Einfluss von Erfahrung beim Pair Programming.
Refactoring
Beim Refactoring oder Überarbeiten, nennt Extreme Programming zwei Beweggründe:

Das Hinzufügen einer neuen Funktion wird vereinfacht.

Es gibt eine einfachere Lösung, als die gerade implementierte.
Durch Refactorings wird versucht den Aufwand für zukünftige Änderungen zu reduzieren und das
System damit wartbar zu machen. Hierbei dürfen die Anforderungen der Kunden und Anwender
nicht aus den Augen verloren werden.
Eine Voraussetzung für Refactorings sind flächendeckende Komponententests. Nur so lässt sich
gewährleisten, dass Änderungen keine Seiteneffekte auf die Funktionalität haben. Um das Risiko
weiter zu senken bietet es sich an, große Refactorings in kleine Schritte zu unterteilen.
Bei einer kontinuierlichen Integration (engl. continuous integration) werden die Anpassungen der
einzelnen Entwickler in möglichst kleinen Schritten im Gesamtsystem zusammengefügt. Sie stehen
den anderen Entwicklern damit schnell zur Verfügung. Dadurch fallen konkurrierende Änderungen
schneller auf oder entstehen gar nicht erst.
Die Integration umfasst nicht nur das Zusammenfügen des Quelltextes, sondern auch das Sicherstellen der Funktionalität vom Gesamtsystem. Der Funktionsumfang soll hierbei auf einem extra Integrationssystem geprüft werden, welches der produktiven Umgebung möglichst ähnlich ist. Nur so fallen
fehlende Komponenten auf, die auf dem Entwicklungsrechner installiert sind, aber nicht mit verteilt
werden. Da eine Integration möglichst oft stattfinden soll, sind Tests möglichst zu automatisieren.
Dies spart nicht nur Zeit, sondern stellt auch sicher, dass keine Tests vergessen oder aus Bequemlichkeit ausgelassen werden.
Patrick Rehder
57
Master-Thesis
Ten-Minute Build
Laut der Methode Ten-Minute Build darf ein Build nicht länger als zehn Minuten24 dauern. Unter
Build ist in diesem Fall das Übersetzten der Anwendung und das Ausführen aller automatisierten
Tests zu verstehen. Ein längerer Build würde dafür sorgen, dass die Akzeptanz für den Build sinkt
und dieser nicht mehr so häufig genutzt wird.
Wenn der Build länger dauert, muss der Vorgang optimiert werden. Eine Möglichkeit ist es das
System in Abschnitte zu unterteilen, um nur die Abschnitte übersetzten und testen zu müssen, die
sich auch geändert haben. Ein weiterer Weg ist es die Geschwindigkeit über leistungsfähigere
Hardware zu erhöhen.
2.4.4. Rollen
Die in Extreme Programming genannten Rollen haben sich in vergangenen Projekten etabliert;
beziehungsweise wurden dort vorgefunden. Sie sind jedoch weder ein Garant für den Erfolg eines
Projekts, noch sind sie zwingend in jedem Projekt zu besetzen. Es soll nicht darum gehen die Teammitglieder in Rollen zu pressen, um ein vordefiniertes System zu besetzten; es muss darum gehen,
ein neues System auf Basis der Stärken der Mitglieder zu entwickeln. Zu Beginn eines Projekts kann
es jedoch hilfreich sein, sich an den vordefinierten Rollen zu orientieren. Die Rollen sind hierbei
flexibel zu behandeln: Eine Rolle kann von mehreren Teammitgliedern übernommen werden und ein
Teammitglied kann mehrere Rollen innehaben. Unter dem Begriff „Team“ sind an dieser Stelle
übrigens sowohl Entwickler, Kunden, als auch das Management gemeint. Letztlich müssen alle
Beteiligten das große Ganze im Blick haben: Die Entwicklung einer Anwendung unter ökonomischen
Gesichtspunkten. [38, pp. 139, 140] [40, p. 'Chapter 10. The Whole XP Team'] [43, p. 121]
Aufgrund des Umfangs werden die einzelnen Rollen in dieser Arbeit nicht erläutert.
2.4.5. Nachbetrachtung
Auf den ersten Blick gibt Extreme Programming vor, wie bei der Softwareentwicklung in kleinen,
lokalen Teams25 vorzugehen ist. Dahinter verbirgt sich der Wunsch ein Gemeinschaftsdenken zu
entwickeln. Die Art und Weise soll sich ändern, wie die Beteiligten miteinander umgehen. Die
Aufgaben sollen nicht durch Vorgesetzte diktiert werden – sie sollen bereitwillig übernommen
werden. Dem Kunden soll kein Schauspiel geboten werden. Er soll Nutzen erhalten. Er soll dem Team
vertrauen. [13, p. 28]
Die Methoden alleine reichen hierzu nicht aus. Auch wenn sie detailliert beschrieben sind und auf
bewährten Verfahren beruhen. Sie ergeben erst im Kontext der Werte und Prinzipien betrachtet den
24
Erfahrungswert von Kent Beck
Ein kleines, lokales Team im Sinne von Extreme Programming besteht aus zwei bis zehn Entwickler, welche gemeinsam an
einem Ort arbeiten. [38, p. xviii]
25
Patrick Rehder
58
Master-Thesis
gewünschten Sinn. Neben der Einführung der Methoden ist es entscheidend, die Werte und Prinzipien zu vermitteln. [38, p. xviii]
Die Einführung von Extreme Programming gestaltet sich einfach, da die einzelnen Methoden
schrittweise etabliert werden können [38, p. 123]:
1. Das größte Problem beim derzeitigen Vorgehen identifizieren.
2. Lösung des Problems über ein oder mehrere Methoden von Extreme Programming.
3. Wenn das Problem nicht mehr das Größte ist, geht es wieder zum ersten Punkt.
Die Methoden schrittweise einzuführen birgt weniger Risiken, als alle Methoden auf einmal einzusetzen. Dies gilt insbesondere für laufende Projekte, die auf Extreme Programming umstellen wollen.
Dass Extreme Programming nur richtig erlernt werden kann, wenn es in der Praxis angewendet
wird, spricht ebenfalls für eine schrittweise Einführung. Nur über Methoden zu lesen versetzt einen
noch nicht in die Lage eine Methode zu beherrschen. [40, pp. 'Chapter 3. Values, Principles, and
Practices']
Extreme Programming (XP) auf einen Blick [6, p. 13] [38, p. xvii]:

XP gibt frühzeitig und fortlaufend Feedback durch kurze Zyklen.

XP berücksichtigt sich ändernde geschäftliche Anforderungen.

XP ist vor allem für kleine Projekte geeignet (2 bis 10 Entwickler).

XP legt großen Wert auf Qualität.

XP macht klare Vorgaben für Management, Team und Programmierung.

XP ist eine mächtige, aber anspruchsvolle Methode.
Patrick Rehder
59
2.5.
Master-Thesis
Zusammenfassende Betrachtung
In diesem Kapitel werden die drei zuvor erläuterten Prozesse: Scrum, Feature Driven Development
und Extreme Programming gemeinsam betrachtet. Begonnen wird mit einer gelungenen Übersicht
aus der Broschüre „Agile Softwareentwicklung - Ein Überblick“, siehe Tabelle 11. Die Übersicht
beschreibt, unter welchen Voraussetzungen sich welcher Prozess besser eignet. Je mehr Sterne,
desto besser ist der Prozess unter den gegebenen Voraussetzungen geeignet.
Voraussetzungen
Scrum
FDD
XP
Großes Projekt
Kleines Projekt
Festpreisprojekt
Zugriff auf Fachexperten ist schwierig
Selbstgesteuerte Teams
Entwickler sind räumlich getrennt
Spezialisierung der Teammitglieder
Erfahrung mit agilen Prozessen ist gering
(mehr Sterne = Der Prozess ist unter den jeweiligen Voraussetzungen besser geeignet.)
Tabelle 11 - Prozesseignung hinsichtlich Voraussetzung (angepasst) [6, p. 22]
Die ungleiche Verteilung der Sterne in Tabelle 11 verdeutlicht, dass sich die Prozesse stark voneinander unterscheiden. Scrum konzentriert sich mehr auf die Prozessebene als Feature Driven Development und Extreme Programming, wodurch der Detailgrad auf Methodenebene geringer ausfällt.
Feature Driven Development beschreitet hinsichtlich Organisationsstruktur einen anderen Weg.
Während Scrum und Extreme Programming auf selbstgesteuerte Teams setzen, gibt es bei Feature
Driven Development klare Hierarchien mit strikter Aufgabentrennung. Hierdurch entsteht ein Vorteil
für Feature Driven Development: Es passt sich bequemer in klassische Organisationsstrukturen ein.
Eine Sache haben Scrum, Feature Driven Development und Extreme Programming jedoch gemein:
Sie vertreten alle die Werte und Prinzipien vom Agile Manifest. Letztlich sind es diese Werte und
Prinzipien, die ein agiles Vorgehen ausmachen.
Patrick Rehder
60
>>> Derzeitiges Vorgehen
3.
Master-Thesis
Derzeitiges Vorgehen
Dieses Kapitel ist in vier Unterkapitel untergliedert:

Business-Unit „Externe Produkte“ (CtB10)

Vorgehensmodell

Techniken und Methoden

Umfrage in der Business-Unit
Zunächst wird die Business-Unit „Externe Produkte„ vorgestellt, auch die durchgeführten Projekte
werden betrachtet. Darauffolgend wird ein allgemeingültiges Vorgehensmodell aufgezeigt, welches
das aktuelle Vorgehen beschreibt. Die anschließend beschriebenen Methoden detaillieren das zuvor
gezeigte Vorgehensmodell und verdeutlichen den Stand der Business-Unit beim Entwickeln und
Steuern von Projekten. Im letzten Kapitel wird die Betrachtung durch das Meinungsbild der BusinessUnit abgeschlossen, welches über eine Umfrage ermittelt wurde.
3.1.
Business-Unit „Externe Produkte“ (CtB10)
Die Commerz Systems GmbH ist organisatorisch in drei Bereiche unterteilt:

Steuerung / Service- und Zentralbereiche

Run the Bank (RtB)

Change the Bank (CtB)
Der erste Bereich ist in sechs Business-Units gegliedert. Deren Aufgaben unterteilen sich in: Personalverwaltung, Finanzbuchhaltung und infrastrukturelle Tätigkeiten. Run the Bank teilt sich ebenfalls
in sechs Business-Units auf. Diese kümmern sich um die Administration und den Betrieb von Softwaresystemen in der Commerzbank. Die Business-Unit „Externe Produkte“ ist eine von zehn Business-Units aus dem Bereich Change the Bank. Die Aufgaben dieses Bereichs liegen in der Neu- und
Weiterentwicklung von Softwaresystemen für die Commerzbank. Insgesamt ist die Commerz Systems
GmbH damit in 22 Business-Units untergliedert.
Die Business-Unit „Externe Produkte“ umfasst 13 Entwickler (Stand: Mai 2012), welche durch einen
Business-Unit Manager geleitet werden. Durch die unterschiedlichen Kenntnisse und Interessen der
Team-Mitglieder verfügt die Business-Unit über breit gefächerte fachliche, technische, und methodische Kompetenzen. Neben der täglichen Projekt- und Wartungsarbeit hat das Thema Ausbildung eine
hohe Bedeutung in der Business-Unit.
Im Folgenden werden die letzten drei großen Projekte der Business-Unit beschrieben.
Patrick Rehder
61
Master-Thesis
ASTAT
ASTAT ist eine branchenunabhängige Softwarelösung für Revisionen. Bei einer Revision handelt es
sich um eine Stabsabteilung, zum Beispiel: bei einer Bank oder einem börsennotierten Unternehmen.
Sie ist gesetzlich vorgeschrieben und unterstützt den Vorstand im Rahmen seiner Kontrollfunktion.
Die Entwicklung der Software wird im Auftrag der Rot AG durchgeführt, welche den Vertrieb übernimmt. ASTAT ist damit das einzige Produkt, welches nicht direkt im Auftrag der Commerzbank
entwickelt wird. Hieraus resultiert auch die Bezeichnung der Business-Unit: Externe Produkte. [45,
pp. 5, 6]
NIOB
Die Anwendung NIOB wurde für die unternehmensinterne Nutzung entwickelt. Mit ihr ist es möglich
Verträge zu verwalten, in denen externe Dienstleister auf interne Projekte vermittelt werden. Das
Datenvolumen beträgt etwa 800 Projekte, auf die rund 1000 Dienstleister aus 500 Firmen vermittelt
werden.
TANTAL
Dieses Projekt entstand im Rahmen der Übernahme der Dresdener Bank durch die Commerzbank. Es
handelt sich um ein Produkt zur Depotverwaltung von fondgebundenen Rentenversicherungen,
welche über die Allianz vermittelt und dessen zugehöriges Depot von der Commerzbank verwaltet
wird. Da die EDV Systeme der Dresdener Bank komplett abgeschaltet wurden und das alte Softwaresystem für davon betroffene Großrechner konzipiert war, wurde TANTAL komplett neu entwickelt.
Nach der Neuentwicklung wurde die Wartung für dieses Produkt übernommen.
Patrick Rehder
62
3.2.
Master-Thesis
Vorgehensmodell
Das Vorgehensmodell zur Softwareentwicklung in der Business-Unit „Externe Produkte“ kann nicht
ohne weiteres durch ein klassisches Vorgehensmodell beschrieben werden. Dies ist deswegen schon
schwierig, da sich das Vorgehen in den einzelnen Projekten voneinander unterscheidet. Dennoch
lassen sich Gemeinsamkeiten erkennen, die über ein allgemeines Vorgehensmodell beschrieben
werden (siehe Abbildung 9).
[nach Vorabtest]
Analyse
Design
Implementierung
Test
Verteilung
[nächstes Release]
Abbildung 9 - Allgemeines Vorgehensmodell
Das allgemeine Vorgehensmodell lässt fünf Phasen erkennen, die nacheinander durchschritten
werden. Dieses Vorgehen erinnert auf den ersten Blick an das Wasserfallmodell. Auch die Inhalte der
Phasen spiegeln sich im Wasserfallmodell wieder:

In der Analysephase werden die Anforderungen der zu entwickelnden Anwendung bestimmt
und dokumentiert.

Die technische Umsetzung wird in der Designphase besprochen und festgehalten.

Während der Implementierung wird der Quelltext der Anwendung geschrieben, aber auch
Maßnahmen zur Qualitätssicherung durchgeführt.

Die Testphase wird in Form von Vorabtests oder eines Systemtest durchlaufen.

Bei der Verteilung wird ein Installationspaket zusammen- und bereitgestellt.
Hierbei wird ein Projekt durch alle Phasen von einem Team erfahrener Entwickler begleitet. Im
Übergang von der Designphase zur Implementierung werden weitere Entwickler hinzugezogen. Die
erfahrenen Entwickler stellen Aufgaben für die „neuen“ Entwickler bereit und stehen für Fragen zur
Verfügung. Der Kontakt zum Kunden erfolgt größtenteils über die erfahrenen Entwickler.
Im allgemeinen Vorgehensmodell ist der Rücklauf von der Test- zur Analysephase auffällig. Während
eines geplanten Release werden ein oder mehrere Vorabtests durchgeführt. Bei einem solchen
Vorabtest werden neben Fehlern, auch Änderungswünsche des Kunden identifiziert. Sofern der
Umfang der gewünschten Änderung nicht nennenswert26 ist, wird die Änderung als Kleinstaufgabe
aufgenommen und von einem Entwickler abgearbeitet. Ansonsten wird der Änderungswunsch durch
26
Nicht nennenswert sind beispielsweise kleine Änderungen an der Benutzeroberfläche, wie das Ändern einer Beschriftung
oder das Verschieben eines Kontrollelements.
Patrick Rehder
63
Master-Thesis
das Entwicklungs-Team analysiert und geschätzt. Übersteigt der geschätzte Aufwand die Kapazität
des Entwicklungs-Teams, muss der Kunde eine der folgenden Optionen wählen:

Die Änderung soll nicht durchgeführt werden.

Der Umfang vom Release wird verringert.

Der Zeitraum für das Release wird vergrößert.
Durch Vorabtests wird auch sichergestellt, dass der Kunde nicht erst im Systemtest bemerkt, dass die
Anwendung nicht seinen Wünschen entspricht.
Ein Release läuft im Schnitt über fünf Monate (siehe Tabelle 12). Da je Release ein bis zwei Vorabtestzyklen durchlaufen werden, umfasst ein Zyklus zwischen ein- und zweieinhalb Monaten.
Projekt
Version
Dauer
ASTAT
1
5 Monate
ASTAT
2
ASTAT
3
Projekt
Version
Dauer
NIOB
1
4 Monate
5 Monate
TANTAL
1
6 Monate
4 Monate
TANTAL
2
6 Monate
Tabelle 12 - Projektdauer je Release (Dauer gerundet)
Das allgemeine Vorgehensmodell deckt sowohl die Neu-, als auch die Weiterentwicklung ab. Nicht
betrachtet wird hingegen das Vorgehen bei der Wartung von Software, welche sich vor allem durch
kontinuierlich auftauchende Aufgaben auszeichnet.
3.2.1. Vorgehensmodell: ASTAT
Abbildung 10 bildet das Vorgehen bei der Weiterentwicklung von ASTAT ab. Für die Abbildung gilt: In
der linken, oberen Ecke ist je Phase zu erkennen, ob der Kunde oder das Entwicklungs-Team (ETeam) maßgeblich involviert ist.
Kunde
Fachkonzept
erstellen
E-Team
Setup
bereitstellen
E-Team
Fachkonzept
schätzen
Kunde
Systemtest
durchführen
Kunde/E-Team
E-Team
Fachkonzept
anpassen
Kunde
Vorabtest
durchführen
DV-Konzept
anpassen
E-Team
Implementierung
durchführen
[Entwicklung abgeschlossen]
Abbildung 10 - Vorgehen bei der Weiterentwicklung von ASTAT
Die Analyse-Phase ist im abgebildeten Vorgehensmodell in drei Schritte unterteilt. Zu Beginn erstellt
der Kunde das Fachkonzept, welches die im Release umzusetzenden Funktionen nennt und beschreibt. Nachfolgend werden die im Fachkonzept enthaltenen Themen durch das Entwicklungsteam
Patrick Rehder
64
Master-Thesis
geschätzt. Da der Zeitraum für das Release und die vom Entwicklungs-Team zu erbringende Leistung
meist festgelegt sind, kann nur der Umfang variieren. Damit die Anforderungen von der zur Verfügung stehenden Kapazität gedeckt werden, wird das Fachkonzept entsprechend angepasst. Außerdem wird das Fachkonzept in diesem Schritt weiter detailliert und Fehler korrigiert.
Aufbauend auf dem Fachkonzept, wird das Datenverarbeitungskonzept (DV-Konzept) erstellt. Dieser
Schritt beschreibt die Design-Phase aus dem allgemeinen Vorgehensmodell. Das Datenverarbeitungskonzept beschreibt aus technischer Sicht, wie die Funktionen umgesetzt werden sollen. Da
ASTAT weiterentwickelt wird, steht die grundlegende Architektur der Anwendung bereits fest.
Die Schritte Implementierung, Vorab-, Systemtest und das Bereitstellen eines Setups weisen keine
nennenswerten Merkmale auf, die nicht bereits genannt wurden.
3.2.2. Vorgehensmodell: NIOB
Das Vorgehen bei der Neuentwicklung von NIOB ist in Abbildung 11 dargestellt.
Kunde/E-Team
Anforderungen
ermitteln
E-Team
E-Team
DV-Konzept
erstellen
Kunde
Implementierung
durchführen
Kunde
Diskussion
mithilfe von
Entwürfen der
Benutzeroberfläche
Systemtest
durchführen
E-Team
Vorabtest
durchführen
Anwendung
verteilen
[nächste Stufe]
Abbildung 11 - Vorgehen bei der Neuentwicklung von NIOB
Die Neuentwicklung von NIOB erfolgte in zwei Stufen, wobei das Vorgehensmodell je Stufe durchlaufen wurde.
Im Gegensatz zum Vorgehen bei ASTAT sammelte der Kunde seine Anforderungen nicht in einem
Fachkonzept. Der Kunde und das Entwicklungs-Team entwickelten die Anforderungen in einem
Gespräch und hielten diese im Datenverarbeitungskonzept fest. Bei den Gesprächen halfen Entwürfe
der Benutzeroberfläche ein gemeinsames Verständnis der Benutzeroberfläche zu schaffen. Die
Designphase fiel entsprechend gering aus, da dieselbe Architektur wie bei ASTAT genutzt wurde.
Die Schritte Implementierung, Vorab- und Systemtest weisen keine nennenswerten Merkmale auf,
die nicht bereits genannt wurden.
Da es sich bei NIOB um ein internes Projekt handelte, wurde die Verteilung der Software vom
Entwicklungs-Team in Kooperation mit der Infrastruktur durchgeführt.
Patrick Rehder
65
Master-Thesis
3.2.3. Vorgehensmodell: TANTAL
In der folgenden Abbildung 12 wird das Vorgehensmodell bei TANTAL beschrieben.
Kunde
Kunde/E-Team
Konzeption
Neusystem
Design
entwerfen
Fach- und Datenverarbeitungskonzept
Use Cases
E-Team
Implementierung
durchführen
Kunde
UML Klassen, Ablauf- und Sequenzdiagramme
Datenmodell
E-Team
Installationspaket
bereitstellen
Vorabtest
durchführen
Kunde
Konzept vom
Altsystem
E-Team
Systemtest
durchführen
Abbildung 12 - Vorgehen bei der Neuentwicklung von TANTAL
Die Anforderungen an TANTAL ergaben sich weitgehend aus dem Altsystem, welches mit einigen
Anpassungen nachgebildet werden sollte. Der Kunde stellte das Konzept des Altsystems bereit, auf
dessen Basis ein Konzept für das Neusystem entwickelt wurde. Hierbei wurden vom EntwicklungsTeam Use Cases erarbeitet, die mit dem Kunden abgestimmt wurden, aber auch ein Fach- und ein
Datenverarbeitungskonzept.
Ein Use Case bildete jeweils die Grundlage für eine Aufgabe, die von einem Entwickler bearbeitet
wurde. Design und Implementierung hingen in diesem Fall eng zusammen. Jeder Use Case wurde von
einem Entwickler durch ein UML Ablauf- oder Sequenzdiagramm dargestellt. Die dabei identifizierten
Klassen und Methoden wurden in ein Klassendiagramm eingefügt. Nachdem die Ergebnisse einem
informellen Review unterzogen wurden, konnte der Entwickler mit der Umsetzung beginnen.
Die Schritte Vorab-, Systemtest und Bereitstellen des Installationspakets weisen keine nennenswerten Merkmale auf, die nicht bereits genannt wurden.
Patrick Rehder
66
3.3.
Master-Thesis
In diesem Kapitel werden einzelne Techniken und Methoden genannt, die in den Projekten Anwendung gefunden haben.
Freiräume
Damit sich das Vorgehen in der Business-Unit „Externe Produkte“ verbessern und weiterentwickeln
kann, werden Freiräume27 vorgesehen. Freiräume bieten Teammitgliedern die Möglichkeit sich mit
neuen Technologien, Prozessen und Methoden auseinandersetzen; beispielsweise beim Vorstellen
von Themen durch Kollegen oder dem Besuch von Schulungen und Konferenzen. Es ist aber auch die
Zeit gemeint, um neue Ideen umsetzen und etablieren zu können – den Veränderungen benötigen
Zeit zur Ein- und zur Durchführung.
Die Freiräume sind nicht fest vorgegeben, sondern werden nach Bedarf genommen. Hierbei bedarf
es der Zustimmung des Vorgesetzten, dem Business-Unit Manager. Damit ist es entscheidend, dass
der Vorgesetzte den Nutzen von Freiräumen erkennt und diese auch gewährt. In der Business-Unit
„Externe Produkte“ ist dies der Fall.
Die Methode Slack (siehe Seite 53) von Extreme Programming beschreibt ähnliches.
Architecture Board
Das Architecture Board besteht aus drei bis fünf erfahrenen Entwicklern. Diese treffen sich einmal in
der Woche, um projektübergreifende Architekturthemen zu besprechen. Zum Beispiel: Verwendung
neuer Technologien, Aufstellen von Programmierrichtlinien und Diskussionen über Zweckmäßigkeit
von gemachten Umsetzungen. Jeder Entwickler hat außerdem die Möglichkeit Themen im Architecture Board zu platzieren; über diese Themen wird beraten und ein Vorgehen vorgeschlagen. Dies
zeigt, dass es sich beim Architecture Board um eine beratende Einheit handelt.
Bei Extreme Programming findet sich mit der Quick Design Session aus der Methode Incremental
Simple Design (siehe Seite 53) eine ähnliche Einrichtung.
Stand-Up Meetings
Zweimal in der Woche trifft sich die Business-Unit zum Stand-Up Meeting. Dieses Treffen lehnt sich
an die Idee des Daily Scrums (siehe Seite 23) an und soll 30 Minuten nicht überschreiten. Im Stehen
sind von jedem Teilnehmer drei Fragen zu beantworten:
1. Was habe ich seit dem letzten Meeting erreicht?
2. Was will ich bis zum nächsten Meeting erreichen?
3. Welches Problem hindert(e) mich an der Erreichung?
27
Warum Freiräume so wichtig sind wird von Tom DeMarco in seinem Buch „Slack“ [70] beschrieben.
Patrick Rehder
67
Master-Thesis
Planning Poker
Planning Poker ist eine Methode zum Schätzen mit mehreren Personen. Der Begriff wurde 2002 von
James Grenning [46] eingeführt und über das Buch „Agile Estimation and Planning“ von Mike Cohn
[47] weit verbreitet. Mittlerweile stellt Planning Poker einen essentiellen Bestandteil des agilen
Methodenkoffers dar.
Beim Planning Poker gibt es zwei Arten von Teilnehmern: Kunden und Entwickler. Der Kunde bringt
die zu schätzenden Themen ein und steht für Fragen zur Verfügung. Die Entwickler schätzen die
Themen gemeinsam ein. Hierzu erhält jeder Entwickler einen Satz Planning Poker Karten, wie in
Abbildung 13 dargestellt.
„Ist bereits umgesetzt.“ oder „Kann in wenigen Minuten umgesetzt werden.“
0
½
1
2
3
5
8
13
20
40
100
? ∞ c
„Ich brauche mehr Informationen, bevor ich schätzen kann.“
„Diese Anforderung ist zu groß zum Schätzen.“
„Ich brauche eine Pause.“
Abbildung 13 - Umfassender Kartensatz für Planning Poker
Die Zahlenkarten repräsentieren ihren Wert in einer festzulegenden Einheit. Ein Kartensatz muss
nicht unbedingt alle der abgebildeten Karten enthalten. So bestand der ursprüngliche Kartensatz von
James Grenning aus den Werten: 1, 2, 3, 5, 7, 10 und dem Unendlichkeitszeichen. Bei einer Schätzung in Tagen war es somit nicht möglich, über zwei Wochen zu schätzen. Dies zwingt den Kunden
dazu, die Anforderungen feiner zu gliedern; Grenning erachtet dies für sinnvoll. [46, p. 3] Durchgesetzt haben sich jedoch die Werte von Mike Cohn, welche sich an die Fibonacci-Folge28 anlehnen.
Durch die sich vergrößernden Abstände zwischen den Werten, wird die Unsicherheit beim Schätzen
großer Anforderungen berücksichtigt. [23, p. 50]
Je zu schätzender Anforderung werden die folgenden Schritte durchlaufen:
1. Der Kunde stellt die zu schätzende Anforderung vor.
2. Unklarheiten zur Anforderung werden in der Gruppe diskutiert.
3. Jedes Mitglied der Schätzrunde wählt verdeckt eine Karte.
4. Sobald alle gewählt haben, werden die gewählten Karten aufgedeckt.
5. Eine der folgenden Situationen tritt ein:
a. Alle Karten sind nahezu identisch; das Schätzergebnis steht fest.
b. Die Karten weichen voneinander ab. In diesem Fall wird über die Abweichung gesprochen. Diejenigen mit dem kleinsten und dem größten Wert stehen hierbei im
28
Fibonacci-Folge: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …
Patrick Rehder
68
Master-Thesis
Vordergrund. Danach wird eine neue Schätzrunde durchgeführt. Dies wird solange
wiederholt, bis sich auf ein Schätzergebnis geeinigt wurde.
In den Projekten ASTAT und TANTAL wurden die Anforderungen in der Analyse-Phase mithilfe von
Planning Poker geschätzt. Als Einheit wurden Personentage gewählt. Außerdem war der Kunde in
den Schätzrunden nicht vor Ort, stattdessen wurde auf Basis vom Fachkonzept oder der Use Cases
geschätzt. Unklarheiten wurden hierbei notiert und zur nächsten Runde Planning Poker geklärt.
Visual Studio Team Foundation Server
Den Projekten ASTAT, NIOB und TANTAL ist die Verwendung der gleichen Programmiersprache
gemein; alle Projekte nutzen C#. Da C# von Microsoft entwickelt wird ist Visual Studio die Entwicklungsumgebung der Wahl. Als zentrale Plattform, für die Softwareentwicklung in Teams, bietet
Microsoft den Visual Studio Team Foundation Server an.
Der Visual Studio Team Foundation Server wird in der Business-Unit „Externe Produkte“ für folgende Aufgaben verwendet:

Versionsverwaltung des Quelltextes

Verwaltung der Aufgaben (Work Item Tracking)

zentralisierte Builds (Team Builds)
Der Funktionsumfang vom Team Foundation Server wird damit im Kern ausgeschöpft. [48]
Analoges Task Board
An einer großen freien Wand wurde ein Whiteboard angebracht, dass eine Fläche von etwa 2m ×
4,5m hat. Dieses Whiteboard wird unter anderem
als Task Board genutzt. Ein Task Board ist eine
tabellarische Darstellung von Aufgaben, die den
aktuellen Stand je Aufgabe darstellt. (siehe
Abbildung 14)
Folgende Punkte sind im Zusammenhang zum
Task Board zu nennen:

Abbildung 14 - Schema: Task Board [25, p. 12]
Die Methode ist leicht zu verstehen und mit
einfachen Mitteln durchzuführen.

Es entsteht ein Aufgabenpool, an dem sich die Entwickler bedienen können.

Die aufgrund der Kartengröße in Kürze notierten Aufgaben sind ohne Kontextwissen nur zu
erahnen. Hierdurch werden Diskussionen im Team und mit dem Kunden angeregt.

Der Fortschritt kann auf einen Blick erkannt werden.
Patrick Rehder
69
Master-Thesis
In den genannten Projekten der Business-Unit „Externe Produkte“ wurde ein Task Board eingesetzt,
allerdings nicht einheitlich. So wurde es zur Strukturierung von großen Aufgaben genutzt, bei denen
viele kleine Schritte zu erledigen waren. Aber auch als analoge Repräsentation der Aufgabenverwaltung des Team Foundation Servers. Letzteres umfasste die doppelte Pflege in beiden Medien. Alle
Projekte nutzten die Spalten: offen, in Arbeit, zum Review freigegeben, in Review und erledigt.
Ein Task Board wird in der Praxis häufig für das Sprint Backlog (siehe Seite 28) bei Scrum eingesetzt.
Bei Extreme Programming bedient es die Methode User Stories (siehe Seite 51) in Verbindung mit
dem Informative Workspace (siehe Seite 51).
Regeln für die Entwicklung
Um ein einheitliches Vorgehen in der Business-Unit zu gewährleisten, werden Regeln festgelegt.
Hierbei darf jedes Teammitglied neue Regeln vorschlagen, aber auch vorhandene Regeln in Frage
stellen. Beispielhaft können folgende Bereiche für Regeln genannt werden:

Namenskonventionen für Ordner, Dateien, Klassen und Methoden

Richtlinien zur Formatierung und Strukturierung von Quelltext

Einsatz bestimmter Technologien, wie zum Beispiel Logging oder Unit-Testing
Mit steigender Zahl nimmt die Häufigkeit zu, mit der Regeln vergessen oder missachtet werden. Das
Einhalten der Regeln muss deswegen geprüft werden und dass möglichst automatisiert. Bei Regeln
mit Bezug zum Quelltext können hierzu beispielsweise Werkzeuge zur statischen Code Analyse
eingesetzt werden. Ist eine Automatisierung nicht oder nur mit unverhältnismäßigem Aufwand
möglich, bleibt das Review, um Entwickler auf vergessene Regeln aufmerksam zu machen.
Beim Extreme Programming entspricht dies den Coding Standards (siehe Seite 54). Scrum sieht die
Möglichkeit vor allgemeingültige Regeln über die Definition of Done (siehe Seite 29) festzulegen.
Knowledge Database
Eine Knowledge Database oder Wissensdatenbank stellt das Langzeitgedächtnis des Teams dar. Sie
dient dazu Wissen zu konservieren und anderen Teammitgliedern zugänglich zu machen.
Für diese Zwecke wird in der Business-Unit „Externe Produkte“ die Kollaborationsplattform SharePoint von Microsoft eingesetzt. Hierbei handelt es sich um eine browsergestützte Plattform, welche
die Zusammenarbeit im Team vereinfachen soll. Der SharePoint stellt unter anderem ein Wiki zur
Verfügung, dient als Versionsverwaltung für Dokumente und bietet die Möglichkeit Umfragen
anzulegen.
Reviews
Das Ergebnis jeder Entwicklungsaufgabe wird in der Business-Unit „Externe Produkte“ von einem
anderen Kollegen aus fachlicher und technischer Sicht geprüft. Diese Art des Reviews wird in der
Literatur [49, p. 96] als informelles Review bezeichnet. Bei einem informellen Review wird der
Patrick Rehder
70
Master-Thesis
Aufwand möglichst gering gehalten. Aufgrund der geringen Vorgaben hängt das Ergebnis stark von
den Ansprüchen und der Wahrnehmung des Gutachters ab.
Die Durchführung eines Reviews ist sowohl im Task Board als auch in der Aufgabenverwaltung vom
Team Foundation Server integriert. Eine Aufgabe gilt erst als erledigt, wenn die im Review gefunden
Anmerkungen mit dem Entwickler abgestimmt und von diesem behoben wurden; die Korrektur
wiederum ist vom Gutachter zu prüfen.
Für das Durchführen eines Reviews gab es eine Checkliste, die an eine Definition of Done (siehe Seite
29) erinnert.
Retrospektiven
In Anlehnung an Scrum wurden bei ASTAT, NIOB und TANTAL Retrospektiven durchgeführt, jeweils
zum Ende eines Release. Durch das Betrachten eines großen Zeitraums, dehnten sich die Retrospektiven entsprechend aus.
Der Ablauf der Retrospektiven orientierte sich stark am Sechs-Punkte-Ablauf einer Retrospektive von
Boris Gloger (siehe Seite 24) und gestaltet sich wie folgt:
1. Einleitung
In diesem Schritt erklärt der Moderator was eine Retrospektive ist und welche Ziele durch sie
verfolgt werden. Dieser Schritt wird übersprungen, wenn dies allen Anwesenden bereits bekannt ist.
2. Geschützten Raum herstellen / Sicherheit erzeugen
Der Moderator erläutert folgende Punkte: Alle Gespräche und Anmerkungen bleiben im
Raum; Es sollen keine Sündenböcke gesucht werden; Der Moderator verhält sich neutral.
Danach holt sich der Moderator von jedem Teilnehmer das Einverständnis für eine offene
Aussprache der Projekterlebnisse ein.
3. Faktensammlung
Auf einem Zeitstrahl werden Ereignisse gesammelt, die prägnant für den Zeitraum waren. Je
Ereignis wird eine Karte erstellt, an den Zeitstrahl geheftet und mündlich mit zwei bis drei
Sätzen erklärt.
4. Welche Prozesse haben funktioniert?
In diesem Schritt werden Prozesse gesammelt, die gut funktioniert haben. Je Prozess wird eine Karte erstellt, an eine Pinnwand geheftet und ebenfalls mit zwei bis drei Sätzen erläutert.
Danach wird nach Prozessen Ausschau gehalten, die in dieser Form unbedingt erhalten werden müssen; diese werden besonders markiert.
5. Welche Prozesse haben nicht funktioniert?
In diesem Schritt werden Prozesse gesammelt, die nicht gut funktioniert haben. Für jeden
Prozess wird eine Karte erstellt, an eine Pinnwand geheftet und auch mit zwei bis drei Sätzen
veranschaulicht.
Patrick Rehder
71
Master-Thesis
6. Gruppierung der Ergebnisse des fünften Punkts
Die nicht funktionierenden Prozesse werden in zwei Gruppen unterteilt: In Prozesse die das
Team verändern kann und in Prozesse die nicht vom Team beeinflusst werden können.
7. Weglassbar: Festlegung von Maßnahmen zur Veränderung
Das Festlegen von Maßnahmen ist weglassbar, da es je nach betroffenem Prozess und nachfolgendem Projekt, nicht immer sinnvoll ist eine Maßnahme direkt zu bestimmen.
8. Feedbackrunde
In der Feedbackrunde erhält jeder Teilnehmer die Möglichkeit zu sagen, ob ihm die Retrospektive gefallen hat oder nicht.
9. Protokoll erstellen
Der Moderator erstellt Fotos von den Pinnwänden/Whiteboards und bereitet diese in einem
Dokument auf.
Patrick Rehder
72
3.4.
Master-Thesis
Umfrage in der Business-Unit
Die Umfrage erfolgt in drei Schritten:
1. Fragebogen entwickeln
2. Umfrage durchführen
3. Antworten auswerten
In den folgenden Unterkapiteln werden Schritt 1 und 3 betrachtet.
3.4.1. Entwicklung des Fragebogens
Die Umfrage wurde unter Zuhilfenahme des Dokuments „Online Befragungen mit echnopoll.com“
der Preyer GmbH [50] und dem „Leitfaden für die Erstellung eines Fragebogens“ von 2ask [51]
entwickelt. Die einzelnen Schritte stellen sich wie folgt dar:
Ziele bestimmen
Es wurden die folgenden Ziele bestimmt:

Das Vorgehen der Business-Unit soll für die Projekte ASTAT, NIOB und TANTAL ermittelt werden.

Der aktuelle Kenntnisstand zur agilen Softwareentwicklung soll aufgezeigt werden.

Sofern vorhanden, soll das Interesse an der agilen Softwareentwicklung aufgezeigt werden.
Teilnehmerkreis festlegen
Der Teilnehmerkreis beschränkt sich auf die Business-Unit „Externe Produkte“, es handelt sich
deswegen um eine geschlossene Umfrage. Da zwei Mitglieder der Business-Unit bereits seit längerem in „fremden“ Projekten tätig sind und weiterhin sein werden, ergibt sich eine Summe von elf
Teilnehmern.
Medium bestimmen
Die Umfrage soll über die Kollaborationsplattform SharePoint 2010 durchgeführt werden. Diese
enthält alle benötigten Funktionen, um eine Umfrage zu erstellen. Für die Teilnahme wird lediglich
ein Browser benötigt. Über diesen wird die Umfrage aufgerufen und durchgeführt. Die folgenden
Punkte sprechen für eine „Online Umfrage“:

Einige Mitglieder der Business-Unit sind derzeit in Frankfurt tätig und deswegen nur selten im
Bremer Büro anzutreffen. Der Zugriff zum SharePoint steht den Kollegen jedoch unternehmensweit zur Verfügung.

Die Anonymität kann bei Online Umfragen besser gewahrt werden, es ist keine Handschrift zu
erkennen und die Abgabe erfolgt vertraulich. Voraussetzung hierfür ist, dass die Teilnahme
nicht protokolliert wird.
Patrick Rehder
73

Master-Thesis
Es wurden bereits Umfragen in dieser Form durchgeführt. Das Vorgehen ist dem Team bekannt. Außerdem steht der SharePoint schon zur Verfügung und muss nicht extra eingerichtet werden.

Teilnehmer können durch die Fragen geführt werden. Je nach Antwort lassen sich nachfolgende Fragen ein- oder ausblenden.

Die Ergebnisse sind nach der Teilnahme direkt verfügbar und müssen nicht erst aufbereitet
werden.
Fragen erstellen
Der Fragebogen ist in fünf Abschnitte unterteilt (siehe Tabelle 13).
Nr.
Bezeichnung des Abschnitts
Fragen
1
Projektbewertung
2
2
Vorgehensmodelle
4
3
3
4
Agile Softwareentwicklung
3
5
Feedback
1
∑
Summe
13
Tabelle 13 - Auflistung der fünf Abschnitte des Fragebogens
In Summe setzt sich der Fragebogen aus dreizehn Fragen zusammen. Mit Ausnahme der letzten
Frage, sind zu jeder Frage Antwortkategorien vorgegeben – es handelt sich damit um geschlossene
Fragen. Aus den Antwortkategorien kann der Teilnehmer eine oder mehrere auswählen. Der Vorteil
gegenüber offenen Fragen ist, dass die Fragen schneller und leichter zu beantworten sind. Außerdem
wird die Auswertung vereinfacht, da die Antworten bereits gruppiert vorliegen. Dafür ist es aufwendiger geschlossene Fragen zu erstellen, weil die Antwortkategorien zusätzlich zur Frage entwickelt werden müssen.
Der Fragebogen befindet sich im Anhang. Im Folgenden werden die Fragen abschnittweise näher
erläutert:
Abschnitt 1
Frage 1.1: Wie zufrieden bist Du mit dem Vorgehen in Bezug auf die Softwareentwicklung in den Projekten?
Diese Frage soll die Zufriedenheit der Entwickler mit dem derzeitigen Vorgehen erfassen. Die Projekte ASTAT, NIOB und TANTAL werden hierbei einzeln bewertet. Damit in jeder Antwort eine Tendenz
zu erkennen ist, wurde eine gerade Anzahl von Antwortkategorien gewählt. Aufgrund des guten
Projektverlaufs und der positiven Stimmung in der Business-Unit, ist davon auszugehen, dass die
Antworten zur „zufrieden“-Seite tendieren.
Patrick Rehder
74
Master-Thesis
Frage 1.2: Wie schätzt Du die Zufriedenheit der Auftraggeber mit dem Ergebnis ein? (Auftraggeber = Fachabteilung/Rot AG)?
Diese Frage soll bestätigen, dass die Projekte gut verlaufen sind und die Auftraggeber mit den
Ergebnissen zufrieden sind. Aufgrund des Aufwands wurde darauf verzichtet einen separaten Fragebogen für die Auftraggeber zu entwickeln.
Abschnitt 2
Frage 2.1: Wie gut kennst Du die folgenden Vorgehensmodelle zur Entwicklung von Software?
Durch diese Frage soll ein Überblick darüber gewonnen werden, welche Vorgehensmodelle dem
Team bekannt sind. Die zur Auswahl stehenden Vorgehensmodelle wurden primär der Umfrage
2011: "Softwaretest in der Praxis" [4, pp. 7, 9] entnommen. Kanban wurde nicht übernommen, da
Kanban als Methode in der Umfrage berücksichtigt wird. Des Weiteren wurden das Spiralmodell und
Lean Development auf Grundlage der Studie „Agile Development: Mainstream Adoption Has
Changed Agility“ ergänzt. [2, p. 2]
Frage 2.2: Welches der genannten Vorgehensmodelle entspricht dem Vorgehen in den Projekten ASTAT,
NIOB und TANTAL am ehesten?
Für das Vorgehen in den genannten Projekten wurde kein bestimmtes Vorgehensmodell festgelegt.
Es ist allerdings wahrscheinlich, dass die Antworten „Wasserfallmodell“ und „V-Modell“ gewählt
werden, da in den Projekten phasenorientiert vorgegangen wurde.
Frage 2.3: Wenn Du Dir ein Vorgehensmodell zur Softwareentwicklung für die Business-Unit „Externe
Produkte“ aussuchen darfst, welches der folgenden wählst Du?
Auf Basis vom allgemeinen Interesse der Business-Unit „Externe Produkte“ für Scrum, wird dies
wahrscheinlich die häufigste Wahl sein; zumindest werden die Antworten zu agilen Vorgehensmodellen tendieren. Sollte dies nicht der Fall sein, wäre es umso schwieriger ein agiles Vorgehensmodell zu
etablieren.
Frage 2.4: Denkst Du, dass es realistisch ist, ein Vorgehensmodell in der Business-Unit „Externe Produkte“
einzuführen?
Sofern Teilnehmer den Einsatz von Vorgehensmodellen ablehnen, können sie dies in Frage 2.3
mitteilen. Die Sicht in Frage 2.4 wird auf die Business-Unit erweitert. Der Befragte kann zeigen, dass
er Bedenken damit hat, dass ein Vorgehensmodells vom Team angenommen wird.
Abschnitt 3
Frage 3.1: Wie gut kennst Du die folgenden Techniken und Methoden?
Durch diese Frage soll ein Überblick darüber gewonnen werden, welche Techniken und Methoden
dem Befragten in welchem Grad bekannt sind. Die genannten Techniken und Methoden entstammen
der agilen Softwareentwicklung oder werden dort zumindest intensiv genutzt. Die Liste ergibt sich
aus einem Brainstorming, welches über folgende Quellen ergänzt wurde:

Agile Techniken aus „State of Agile Survey“ [3, p. 4]

Ereignisse und Artefakte aus Scrum (siehe Kapitel 2.2, ab Seite 16)
Patrick Rehder
75
Master-Thesis
Es handelt sich nicht um eine erschöpfende Liste aller agilen Techniken und Methoden. Dies ist auch
nicht erforderlich, da nur ein Eindruck gewonnen werden soll.
Frage 3.2: Welche der genannten Techniken und Methoden wurden in den Projekten ASTAT, NIOB und
TANTAL eingesetzt? (Achtung: Mehrfachauswahl.)
Diese Frage soll zeigen, dass bereits einige der genannten Techniken und Methoden in der Vergangenheit eingesetzt wurden.
Frage 3.3: Welche der genannten Techniken und Methoden sollen Deiner Meinung nach zukünftig eingesetzt
werden? (Achtung: Mehrfachauswahl.)
Durch diese Frage wird kenntlich gemacht, welche Techniken und Methoden für sinnvoll erachtet
werden.
Abschnitt 4
Frage 4.1: Für wie wichtig hältst Du die folgenden Punkte in der Softwareentwicklung?
Die zu bewertenden Punkte wurden dem agilen Manifest entnommen, wobei „Individuen und
Interaktion“ und „Prozesse und Werkzeuge“ in vier Punkte aufgetrennt wurde (siehe Tabelle 14).
Dadurch lässt sich prüfen, ob die Teilnehmer der Gewichtung des Manifests zustimmen. Da das
Manifest den Kern der Agilität beschreibt, ist dies eine wichtige Erkenntnis.
Punkt im Agile Manifest
zu bewertende Punkt in der Umfrage
Ideen des Einzelnen
Interaktion zwischen den Beteiligten
definierte Prozesse
Werkzeuge/Tools
Funktionierende Software
eine umfassende Dokumentation
Verträge mit dem Kunden
schnelle Reaktion auf Veränderungen
Festhalten an getroffenen Plänen
Tabelle 14 - Zuordnung: Punkte im Agile Manifest und Punkte im Fragebogen
Frage 4.2: Glaubst Du, dass die folgenden Punkte bei einer agilen Vorgehensweise mehr oder weniger
ausgeprägt sind als bei einem nicht agilen Vorgehen?
Über die positive oder negative Einschätzung der genannten Punkte kann festgestellt werden, ob die
Teilnehmer in agilen Methoden eher eine Verbesserung oder eine Verschlechterung sehen.
Frage 4.3: Welche dieser Aussagen trifft Deine Meinung zum Agilen Manifest am besten?
Wie Frage 4.2 zielt diese Frage darauf ab, die Meinung zur agilen Softwareentwicklung zu bestimmen. Zugleich wird in Erfahrung gebracht, wer das Agile Manifest bereits kennt.
Patrick Rehder
76
Master-Thesis
Abschnitt 5
Frage 5.1: Hier ist der Platz für Anregungen, Wünsche, Kommentare und Kritik; alles auf diesen Fragebogen
bezogen:
Über dieses Freitextfeld kann der Befragte seine Meinung zum Fragebogen äußern. Was nicht nur für
zukünftige Fragebögen interessant ist. Falls ein Teilnehmer beispielsweise schreibt, dass er einige
Fragen nicht richtig verstanden hat, sind seine Antworten besonders kritisch zu betrachten.
Qualitätssicherung
Damit Fehler und missverständlich formulierte Fragen identifiziert werden, wurde der Fragebogen
von mehreren Personen in mehreren Versionen Korrektur gelesen.
3.4.2. Auswertung der Antworten
Die gewählten Antworten können der zusammenfassenden Übersicht29 entnommen werden, welche
im Anhang hinterlegt ist. Dieses Kapitel behandelt die aus der Übersicht gewonnen Erkenntnisse.
Einschätzung der Zufriedenheit
Im ersten Abschnitt des Fragebogens musste jeder Teilnehmer die eigene Zufriedenheit mit dem
derzeitigen Vorgehen und die Zufriedenheit des Kunden bewerten. Die Antworten jeder Antwortkategorie wurden gewichtet30 und je Projekt summiert. Über die Summe lässt sich bestimmen, ob die
Teilnehmer in der Gesamtheit eher unzufrieden oder zufrieden sind. Das Ergebnis kann Tabelle 15
entnommen werden.
Zufriedenheit …
… zum Vorgehen
… des Kunden
ASTAT
zufrieden
unzufrieden
NIOB
neutral
zufrieden
TANTAL
zufrieden
sehr zufrieden
Tabelle 15 - Einschätzung der Zufriedenheit
Die folgenden zwei Punkte sind festzuhalten:

Die Teilnehmer sind mit dem derzeitigen Vorgehen insgesamt zufrieden. Es lässt sich jedoch
keine Tendenz zu einem „sehr zufrieden“ erkennen, damit gibt es hier Verbesserungspotential.

Die Zufriedenheit des Kunden mit ASTAT wird überwiegend als unzufrieden eingeschätzt. Der
Grund hierfür liegt im zuletzt angespannten Verhältnis zwischen dem Kunden und der Business-Unit. Die Spannung entstand durch Schätzzahlen für neue Funktionen, die nach Meinung
des Kunden ungerechtfertigt hoch waren.
29
Da die Antworten in der Übersicht zusammengefasst wurden, ist es nicht möglich, die Antworten eines einzelnen
Fragebogens nachzuvollziehen.
30
sehr unzufrieden = Wert -2, unzufrieden = Wert -1, zufrieden = Wert 1, sehr zufrieden = Wert 2
Patrick Rehder
77
Master-Thesis
Bekanntheitsgrad von Vorgehensmodellen
Die Teilnehmer mussten zu jedem der genannten Vorgehensmodelle eine der folgenden Optionen
wählen: nie gehört, schon mal gehört, ich weiß was das ist, bereits eingesetzt. Vorgehensmodelle, bei
denen mindestens fünf von zwölf Teilnehmern angaben, noch nie davon gehört zu haben, wurden in
der Gruppe unbekannt eingestuft (siehe Tabelle 16).
bekannt
unbekannt
Wasserfallmodell
Scrum
Extreme Programming
V-Modell
Rapid Prototyping
Spiralmodell
W-Modell
V-Modell XT
Crystal
Lean Development
Rational Unified Process
Tabelle 16 - Bekanntheitsgrad der Vorgehensmodelle
Interessant ist vor allem die Einstufung der Vorgehensmodelle, die in dieser Arbeit betrachtet
werden: Keiner der Befragten gab an, noch nie von diesen gehört zu haben. Scrum haben die meisten bereits eingesetzt, während Extreme Programming eher theoretisch bekannt ist und von
Feature Driven Development in der Mehrheit nur schon mal gehört wurde. Dies zeigt, dass agile
Vorgehensmodelle bereits bekannt sind.
Derzeitiges Vorgehensmodell
Die Teilnehmer wählten, welches der genannten Vorgehensmodelle dem derzeitigen Vorgehen am
ehesten entspricht. Das Ergebnis fiel unerwartet gemischt aus. Die Annahme, dass aufgrund des
phasenorientierten Vorgehens bevorzugt das „Wasserfall-“ oder „V-Modell“ gewählt wird, bewahrheitete sich nicht. Drei Teilnehmer wählten zwar das Wassermodell, genauso viele aber auch Scrum.
Es ist wahrscheinlich, dass Scrum aus zwei Gründen gewählt wurde: Einmal gibt es eine Iteration im
derzeitigen Vorgehen und zum Zweiten wurden einzelne Elemente verwendet, die den agilen Techniken und Methoden zuzuordnen sind.
Es bleibt festzuhalten, dass das derzeitige Vorgehen keinem bestimmten Vorgehensmodell entspricht. Dennoch ist es plausibel das derzeitige Vorgehen als Mischung aus Wasserfallmodell und
Scrum zu bezeichnen.
Ein zukünftiges Vorgehensmodell?
Wenn sich die Teilnehmer ein zukünftiges Vorgehensmodell aussuchen könnten, würden sich zweidrittel für Scrum entscheiden. Das Ergebnis entspricht damit der getroffen Annahme, dass ein
starkes Interesse für agile Vorgehensweisen in der Business-Unit „Externe Produkte“ vorherrscht.
Da sich klar für ein bestimmtes Vorgehensmodell ausgesprochen wird und auch keine Probleme bei
der Einführung eines Vorgehensmodells gesehen werden, ist die Einführung eines agilen Vorgehensmodells als realistisch anzusehen – zumindest aus Sicht der Business-Unit „Externe Produkte“.
Patrick Rehder
78
Master-Thesis
Bekanntheitsgrad von Techniken und Methoden
Die Techniken und Methoden wurden in vier Kategorien eingeteilt (siehe Tabelle 17).
sehr bekannt
Automatisierter Buildprozess
Daily Standup
Pair Programming
Planning Poker
Refactoring
Retrospektive
Task Board
Unit-Testing
bekannt
User Stories
Clean Code Development
Definition of Done
Burn Down Chart
Timeboxing
wenig bekannt
Kanban
Product Vision
unbekannt
Collective Code Ownership
On-site Customer
Tabelle 17 - Bekanntheitsgrad von Techniken und Methoden
Nur vier der genannten Techniken und Methoden sind den Teilnehmern der Umfrage wenig oder
unbekannt. Dies unterstützt die getroffene Aussage, dass agile Vorgehensmodelle bekannt sind. Es
ist jedoch zu beachten, dass die Product Vision, der On-site Customer und die Collective Code
Ownership wichtige Techniken und Methoden von Scrum und Extreme Programming sind. Da diese
Vorgehensmodelle zuvor als bekannt eingestuft wurden und diese Techniken und Methoden unbekannt sind, ist noch nicht von einer tiefgreifenden Kenntnis zu sprechen.
Derzeit eingesetzte Techniken und Methoden
Die Hälfte der Teilnehmer wählten 8 der 18 genannten Techniken und Methoden aus, die in den
Projekten ASTAT, NIOB und TANTAL eingesetzt wurden. Dies deckt sich mit der Aussage in der
Motivation (Seite 7), dass agile Techniken und Methoden in der Business-Unit vereinzelt erprobt und
genutzt werden. Außerdem finden sich die in Kapitel 3.3 (Seite 67) genannten Techniken und Methoden unter den meistgenannten Techniken und Methoden wieder.
Zukünftig einzusetzende Techniken und Methoden
Aus den Antworten zur Frage, welche Techniken und Methoden zukünftig eingesetzt werden sollen,
können drei Punkte extrahiert werden:

Techniken und Methoden die den Teilnehmern wenig oder unbekannt sind, wurden nicht für
den zukünftigen Einsatz ausgewählt. Hierbei ist es denkbar dass die Methoden gewählt werden würden, wenn sie bekannt wären.

Alle Techniken und Methoden die bereits eingesetzt werden, sollen auch weiterhin eingesetzt
werden.

Neben den bereits eingesetzten Techniken und Methoden besteht seitens der Befragten das
Interesse weitere Techniken und Methoden einzusetzen.
Patrick Rehder
79
Master-Thesis
Einstellung zum agilen Vorgehen im Allgemeinen
Die aus dem Agile Manifest gewonnenen zehn Punkte31 zur Softwareentwicklung wurden von den
Teilnehmern bewertet. Um die Antworten auszuwerten, wurde die folgende Gewichtung genutzt:
sehr wichtig = 2 Punkte, wichtig = 1 Punkt, neutral = 0 Punkte, unwichtig = -1 Punkt, sehr unwichtig =
-2 Punkte. Das Ergebnis kann Abbildung 15 entnommen werden.
wichtiger
wichtig
24
16
13
15
13
3
3
-7
Abbildung 15 - Die Werte vom Agile Manifest in der Business-Unit „Externe Produkte“
Ohne explizit das Agile Manifest zu bewerten, stimmen die Teilnehmer der Wertung des Manifests
zu. Im Zusammenhang mit der positiven Einschätzung einer agilen Vorgehensweise, welche aus den
Antworten zu den Fragen 4.2 und 4.3 hervorgeht, stellt dies einen idealen Nährboden für die Einführung agiler Techniken, Methoden und Prozesse dar.
3.4.3. Fazit zur Umfrage
Zusammenfassend können folgende Punkte zum Meinungsbild der Business-Unit genannt werden:
31

Es herrscht Zufriedenheit mit dem derzeitigen Vorgehen.

Agile Vorgehensmodelle sind dem Team bereits bekannt.

Das derzeitige Vorgehensmodell ist eine Mischung aus Scrum und dem Wasserfallmodell.

Zweidrittel im Team würden sich bei Wahlfreiheit für Scrum entscheiden.

Es werden keine Probleme gesehen ein Vorgehensmodell einzuführen.

Viele agile Techniken und Methoden sind im Team bekannt.

Bereits eingesetzte agile Techniken und Methoden sollen weiterhin eingesetzt werden.

Das Team stimmt der Wertung vom Agile Manifest zu.
Die im Fragebogen genannten Punkte werden den Punkten im Agile Manifest in Tabelle 14 auf Seite 76 zugeordnet.
Patrick Rehder
80
>>> Mögliches Vorgehen
4.
Master-Thesis
Mögliches Vorgehen
Das derzeitige Vorgehen in der Business-Unit „Externe Produkte“ bietet einen guten Ausgangspunkt,
um das agile Vorgehen zu intensivieren. Folgende Punkte werden in Kapitel 3 (ab Seite 61) belegt:

Der Kunde wird über Iterationen in den Prozess einbezogen.

Schätzungen erfolgen nicht durch einzelne Personen, sondern durch Mehrere.

Es wird nicht strikt nach Funktionen wie Entwickler, Tester und Datenbankspezialist getrennt
– wobei es Vorlieben im Team gibt.

Die Aufgaben werden nicht zugeteilt, sondern aus einem Aufgabenpool von den Entwicklern
ausgewählt.

Das Team setzt bereits agile Methoden ein.

Die Werte vom Agile Manifest werden geschätzt.
Dies bedeutet jedoch nicht, dass zukünftige Änderungen am Vorgehen zur Softwareentwicklung
einen Freibrief erhalten. Jede Änderung betrifft Menschen. Menschen die von ihren Gewohnheiten
abweichen müssen. Sie werden gezwungen unbekannte Wege zu gehen, die sie meist nicht beeinflussen können – es werden Ängste geweckt. Im Kern fällt die Reaktion der Betroffenen deswegen
immer emotional aus; logische Argumente können daran nichts ändern. Veränderungen müssen sich
für die Betroffenen gut anfühlen, damit sie akzeptiert werden. Denn es ist immer bequemer, dass
bekannte Vorgehen beizubehalten. [9, p. 177] [8, p. 251]
Es ist gefährlich zu glauben, dass sich eine Idee nur deswegen durchsetzt, weil sie gut ist. Die Vorteile
rational zu vermarkten und eine Änderung anzustoßen reicht nicht aus. Eine nachhaltige Einführung
benötigt die Akzeptanz aller Beteiligten – egal ob der Zündfunke im Management oder in Projekten
entsteht. Vorträge auf dem ScrumDay2011 bestätigen dies, eine optimale Einführung geschieht von
„Oben“ und von „Unten“. Alle Beteiligten zu überzeugen ist jedoch schwierig; folgende Punkte helfen
dabei [52]:

der Glaube an die Idee

Leidenschaft, um die Idee zu verbreiten

ein strategisches und geplantes Vorgehen

Zeit um einen (kulturellen) Wandel zu ermöglichen

mit Widerstand rechnen
Patrick Rehder
81
Master-Thesis
Die Einführung agiler Prozesse und Methoden kann außerdem durch einen erfahrenen Coach32
begünstigt werden. So wurde Scrum bei ImmobilienScout2433 von einem externen Coach eingeführt,
was im Nachhinein als wesentlicher Erfolgsfaktoren genannt wurde. Der Grund hierfür liegt in der
objektiveren Sicht des Coaches, da dieser die internen Prozesse des Unternehmens nicht kennt. [10,
p. 49] Generell wurde in vielen Beiträgen auf dem ScrumDay2011 empfohlen, einen externen Coach
zu beauftragen – und das nicht nur von Beratungsunternehmen. Neben dem Argument der Objektivität wurde häufig erwähnt, dass einem Coach meist mehr Gehör zuteilwird, als einem Mitarbeiter. Es
gibt auch Unternehmen die eigene Coaching Teams aufbauen, um darüber agile Prozesse zu verbreiten. So zum Beispiel: die Deutsche Telekom AG [ScrumDay2011] und die XING AG [10, p. 137].
Für die Business-Unit „Externe Produkte“ sind folgende Punkte zu betrachten:

Soll ein bestimmtes Vorgehensmodell eingesetzt werden?

Ist ein eigenes Vorgehen mit weiteren agilen Methoden erstrebenswert?
4.1.
Einsatz eines bestimmten Vorgehensmodells
Ein bestimmtes Vorgehensmodell einzusetzen bedeutet in der agilen Welt nicht, dass sich dies nicht
ändern kann. Einer der wichtigsten Eigenschaften agiler Teams ist, dass sie sich den Prozess auf ihre
Bedürfnisse anpassen. Es ist vielmehr eine Frage des passenden Ausgangspunkts. Dieser ist entsprechend der Voraussetzungen zu wählen. Eine erste Orientierung liefert Tabelle 11 auf Seite 60; welche
die Eignung von Scrum, Feature Driven Development und Extreme Programming bei unterschiedlichen Voraussetzungen bewertet.
In der Business-Unit „Externe Produkte“ sind folgende Voraussetzungen zu finden:

Der Größe der Business-Unit entsprechend handelt es sich um kleine Projekte.

Die Projekte sind keine Festpreisprojekte.

Fachexperten stehen meist nur über Telefon/E-Mail zur Verfügung.

Das Team ist selbstgesteuert, es wird kein Vorgehen vorgeschrieben.

Die Entwickler sitzen in einem Büro zusammen.

Die Teammitglieder sind nicht spezialisiert, haben aber Vorlieben für Themengebiete.

Es sind Erfahrungen mit agilen Methoden vorhanden, weniger mit agilen Prozessen.
Laut Tabelle 11 (Seite 60) eignen sich unter diesen Voraussetzungen vor allem Scrum und Extreme
Programming.
32
33
Statt Berater wird im agilen Umfeld häufig der Begriff Coach (deutsch: Trainer) verwendet.
„ImmobilienScout24 ist der größte deutsche Internet-Marktplatz für Immobilien.“ [www.immobilienscout24.de]
Patrick Rehder
82
Master-Thesis
4.1.1. Warum nicht Feature Driven Development?
Feature Driven Development ist insbesondere für große Softwareprojekte geeignet. Softwareprojekte in denen viele Entwickler mit unterschiedlichem Talent und Hintergrund, sowie unterschiedlicher
Erfahrung und Kultur aufeinandertreffen. [8, p. xxi] Vor allem die Größe der Projekte ist in der
Business-Unit „Externe Produkte“ nicht gegeben.
Dennoch ist es eine interessante Eigenschaft von Feature Driven Development, dass es sich gut in
einen Rahmen aus Anforderungsanalyse und Test integrieren lässt. Die Anforderungen werden in
Features überführt und das Softwaresystem wird nach der Entwicklung noch einmal einem Test
unterzogen. [8, p. 260] Damit ließe sich Feature Driven Development gut ins derzeitige Vorgehen
einsetzen (siehe Abbildung 16). Die Einführung von Feature Driven Development würde sich auf die
Business-Unit beschränken. Der Kunde ist erst einmal nicht betroffen. Er kann nach und nach in den
Prozess einbezogen werden.
[nach Vorabtest]
Analyse
Test
Verteilung
[nächstes Release]
Abbildung 16 - Vorgehensmodell mit Feature Driven Development
Dass Feature Driven Development in einer Bank entwickelt wurde, kann vernachlässigt werden. In
der Literatur wird nirgends ein spezifischer Bezug zur Softwareentwicklung in einer Bank hergestellt.
Einzig die Vorgabe einer klaren Hierarchie mit festgelegten Zuständig- und Verantwortlichkeiten kann
einer Bank zugeordnet werden – wie aber auch vielen anderen Unternehmen.
Aufgrund der zu erwartenden Projektgrößen und der Teamkultur ist der Einsatz von Feature Driven
Development nicht sinnvoll.
4.1.2. Scrum als eine Möglichkeit
Viele Punkte sprechen für den Einsatz von Scrum:

Laut Umfrage ist Scrum das Vorgehensmodell der Wahl.

Die Kultur der Business-Unit passt zu Scrum.

Die Größe der Projekte eignet sich für Scrum.

Die Größe der Business-Unit eignet sich für Scrum.

Viele der eingesetzten Techniken und Methoden sind Scrum entlehnt.
Patrick Rehder
83
Master-Thesis
Teamintern existieren damit gute Voraussetzungen für die Einführung von Scrum. Die Herausforderung liegt darin, den Kunden mit einzubeziehen. Im Falle der Commerzbank ist dies aufgrund der
vielen unterschiedlichen Interessenvertreter umso schwieriger. Abhängig vom Projekt sind neben
den Interessen der Fachabteilung, beispielsweise auch die Interessen der IT-Infrastruktur oder der ITSicherheit zu berücksichtigen.
Eine Berücksichtigung der Interessen kann über den Product Owner gewährleistet werden:

Wünscht der Kunde bestimmte Informationen zum Projekt, um beispielsweise die Sicherheit
des Produkts über Architekturdiagramme zu bewerten, kann der Product Owner diese bereitstellen. Gegebenenfalls muss er ein Backlog Item zum Gewinnen von Informationen erstellen. Sofern der Kunde darin einen fachlichen Nutzen sieht, wird folgende Aussage auch nicht
verletzt (siehe Seite 28): „Es gibt keine technischen Product Backlogs.“

Außerdem hat der Product Owner Einfluss auf die Definition of Done. Über sie kann er beispielsweise sicherstellen, dass bei jedem Backlog Item das Architekturschaubild aktualisiert
werden muss.
Eine Bündelung der verschiedenen Interessen über den Product Owner sorgt dafür, dass die Schnittstellen mit dem Kunden erhalten bleiben. Damit ist eine ähnliche Integration von Scrum in das
derzeitige Vorgehensmodell denkbar, wie beim Feature Driven Development (siehe Abbildung 16).
Ob ein solcher Rahmen bei neuen Projekten erforderlich ist, wäre zu prüfen. Der Kunde könnte
beispielsweise Gefallen daran finden, wenn er kein Fachkonzept entwickeln muss und die Anforderungen stattdessen in einem Product Backlog gemeinsam gesammelt werden. Generell bieten neue
Projekt die Chance dem Kunden die Vorteile von Scrum aufzuzeigen und mit ihm Scrum zu versuchen.
Hierbei ist die Anzahl der benötigten Entwickler eine entscheidende Größe. Handelt es sich um ein
kleines Projekt, ist es schwierig einen Product Owner und Scrum Master als Vollzeitaufgabe zu
rechtfertigen – was Scrum so vorsieht. Eine Lösung hierfür sind Doppelrollen, was jedoch nicht
unproblematisch ist. Mehrere Rollen in einer Person bergen das Risiko von Interessenskonflikten:
Wird beispielsweise der Product Owner von einem Entwickler wahrgenommen, so kann dieser dazu
tendieren das Product Backlog nach technologischem Interesse zu priorisieren, anstelle vom Geschäftswert. Doppelrollen gefährden außerdem die Qualität, mit der Aufgaben bearbeitet werden.
Ein Scrum Master benötigt Zeit, um sich mit dem gelebten Prozess im Detail zu beschäftigen. Er sorgt
dafür, dass das Scrum Team im Alltag motiviert ist innezuhalten, zurückzublicken und sich weiterzuentwickeln. [10, pp. 168-170]
Insgesamt bleibt festzuhalten, dass die Einführung von Scrum als realistisch anzusehen ist.
Patrick Rehder
84
Master-Thesis
4.1.3. Extreme Programming als andere Möglichkeit
Gemäß den Voraussetzungen in der Business-Unit „Externe Produkte“ eignet sich auch Extreme
Programming als mögliches Vorgehensmodell. Dem Kapitel 2.4 (ab Seite 42) ist zu entnehmen, dass
es sich bei Extreme Programming um eine Sammlung bewährter Methoden zur Softwareentwicklung handelt, welche maximal möglich eingesetzt werden. Auch bei der Einführung von Extreme
Programming wird diese extreme Art verfolgt:
Es gilt nicht Extreme Programming zu verkaufen; Extreme Programming muss gemacht werden, um
dann die Resultate zu verkaufen. Der Einsatz von Extreme Programming erfolgt nicht zum Selbstzweck, sondern um zu gewinnen34. [9, pp. 27, 28, 176]
Durch das offensive Vorgehen soll Erfahrung gewonnen werden, die zur Bewertung des Vorgehens
genutzt werden kann. Dennoch wird nicht empfohlen blind loszustürmen. Es wird nahegelegt Extreme Programming in einem unkritischen Projekt zu erproben. Außerdem gilt es klein anzufangen
und nicht sofort alle Methoden einzusetzen. Folgendes Vorgehen wird vorgeschlagen [38, p. 123]:
1. Das größte Problem im Entwicklungsprozess identifizieren.
2. Passende Methode(n) von Extreme Programming auswählen.
3. Gewählte Methode(n) einführen.
4. Wenn es das größte Problem nicht mehr gibt, wieder bei Punkt 1 beginnen.
Hierbei wird es empfohlen maximal zwei Wochen zwischen einem Zyklus zu lassen. Der Grund hierfür
liegt in der Wechselwirkung, die von den Methoden untereinander erzeugt wird. Diese Wechselwirkung wirkt sich positiv auf den Gesamtprozess aus und stellt damit einen wichtigen Effekt von
Extreme Programming dar. [9, pp. 34, 35]
Im Kapitel 2.4.4 (Seite 58) wird auf die Rollen von Extreme Programming hingewiesen. Für die
Einführung von Extreme Programming ist insbesondere eine zu nennen: Der Coach. Ein Coach
begleitet das Team und unterstützt beim Einführen vor allem mit seiner Erfahrung. Damit ist diese
Rolle, der Rolle des Scrum Masters ähnlich; es sind die im vorigen Kapitel aufgeführten Doppelrolleneffekte zu beachten. [38, p. 73]
Der Einsatz von Extreme Programming bedeutet, sich mit allen Aspekten des Prozesses zu beschäftigen und nicht nur einzelne Methoden zu selektieren. Derzeit werden Methoden in der BusinessUnit bereits selektiv genutzt, zu nennen sind Coding Standards, Continuous Integration und Refactoring. Weitere Methoden einzuführen ist aufgrund der Voraussetzungen als realistisch anzusehen
und damit Extreme Programming als Ganzes einzuführen.
34
Unter „gewinnen“ ist zu verstehen, dass Softwareprojekte erfolgreich durchgeführt werden.
Patrick Rehder
85
4.2.
Master-Thesis
Einsatz eines eigenen Vorgehensmodells
Ein eigenes Vorgehensmodell einzusetzen, ist in der Praxis nicht unüblich:

17% von etwa 4.700 Befragten (2010) gaben an, einen Hybriden aus Scrum und Extreme
Programming zu nutzen; 5% setzen einen eigenen Hybriden ein. [3, p. 4]

27% von etwa 250 Befragten (2011) gaben an ein eigenes oder angepasstes Modell zu nutzen. [4, p. 9]

„Die wenigsten agilen Teams folgen genau einer dieser Methoden, sondern arbeiten mit agilen Praktiken aus unterschiedlichen Methoden und passen ihren Prozess ihren Bedingungen
an.“ [6, p. 20]

Ein Erfahrungsbericht berichtet von einer pragmatischen Mischung aus Scrum, Extreme Programming und Feature Driven Development. [10, p. 105]
Vor dem Agile Manifest ist die Entstehung eines eigenen Vorgehensmodells sogar als logische
Konsequenz der agilen Softwareentwicklung zu sehen. Aus dem Agile Manifest geht hervor, dass der
Prozess den beteiligten Individuen untergeordnet ist. Bei Problemen sind nicht die Beteiligten in den
Prozess zu pressen – es ist der Prozess zu überdenken. Dieser Gedanke stellt die Basis für das Streben
nach Verbesserungen dar. Der eingesetzte Prozess wird immer weiter an die eigenen Bedürfnisse
angepasst, so dass er irgendwann als eigener, angepasster Prozess gelten kann. Die Grenzen zwischen einem bestimmten und einem eigenen Prozess verschwimmen. Damit ist es eine Frage der
Ausgangsposition.
Der Vorteil direkt ein eigenes Vorgehensmodell zu entwickeln liegt darin, dass es einem die maximale
Freiheit liefert. Um nicht von den Möglichkeiten erdrückt zu werden, ist es hilfreich sich an anderen
Vorgehensmodellen zu orientieren. Dieses Vorgehen wurde in der Business-Unit „Externe Produkte“
bereits genutzt: Einzelne agile Methoden wurden erprobt und gegebenenfalls adaptiert. So ist das
derzeitige Vorgehensmodell entstanden. Es ist denkbar dieses Vorgehen zur Weiterentwicklung
beizubehalten.
Wird das Erproben und Adaptieren neuer Methoden systematisch durchgeführt, ergibt sich daraus
die Möglichkeit sein eigenes Vorgehensmodell zu entwickeln.
Patrick Rehder
86
Master-Thesis
4.2.1. Continuous Method Evaluation
Hinter diesem Namen verbirgt sich die Idee Methoden fortlaufend abzuschätzen, um daraus ein
strukturiertes Vorgehen abzuleiten. Hierzu wird eine Liste mit Methoden regelmäßig vom Team
hinsichtlich Kenntnis und Sinn bewertet. Über diese Informationen kann bestimmt werden, in
welcher Reihenfolge die Methoden zu betrachten und mit welcher Intensität Schulungen durchzuführen sind. Um Störungen bei der Einführung neuer Methoden so gering wie möglich zu halten, soll
sich zurzeit auf eine Methode oder eine Gruppe passender Methoden konzentriert werden. Bei einer
kontinuierlichen Einführung sorgt dies zwar für einen konstanten Störpegel, dafür bleibt der Überblick gewahrt.
Jede Methode durchläuft folgende Schritte:
1. Schulung zur Methode durchführen
2. Methode einsetzen
3. Einsatz der Methode prüfen
Damit folgt dieser Ansatz der Idee von Extreme Programming eine Methode erst einmal einzusetzen, um diese danach zu bewerten. Die zuvor stattfindende Schulung stellt sicher, dass alle im Team
ein gemeinsames Verständnis entwickeln. Der Aufwand je Methode ist hierbei als gering einzuschätzen, er variiert je Methode und Kenntnisstand im Team. Ein denkbares Vorgehen ist, dass sich ein
Teammitglied mit einer Methode beschäftigt und sein Wissen in einer Präsentation oder einem
Workshop weitervermittelt.
Auflistung der zu bewertenden Methoden
Eine beispielhafte Liste mit Methoden kann auf Basis der Grundlagen (Kapitel 2, ab Seite 11), dem
Kapitel 3.3 „Techniken und Methoden“ (ab Seite 67) und Abschnitt 3 der Umfrage (Kapitel 3.4.1, ab
Seite 73) erstellt werden (siehe Tabelle 18):
Architecture Board
Burn Down Chart
Class Ownership
Coding Standards
Daily Standup
Definition of Done
Energized Work
Impediment Backlog
Kanban
Metaphor
On-site Customer
Pair Programming
Planning Poker
Product Backlog
Product Vision
Quarterly Cycle
Refactoring
Retrospektive
Reviews
Sit Together
Slack
Task Board
Ten-Minute Build
Timeboxing
Unit-Testing
User Stories
Weekly Cycle
Whole Team
Tabelle 18 - Beispiel: Liste mit 35 Methoden (alphabetisch sortiert)
Patrick Rehder
87
Master-Thesis
Da eine regelmäßige Befragung angestrebt wird, ist es unproblematisch mit einer kleinen Liste zu
beginnen und diese dann zu erweitern. Dieses Vorgehen bietet sogar den Vorteil, dass die Befragten
zu Beginn nicht von der Masse an Methoden erschlagen werden.
Bewertung der Methoden
Die Methoden sollen hinsichtlich Kenntnisstand und Sinnhaftigkeit von jedem Teammitglied bewertet werden. Es gilt außerdem in Erfahrung zu bringen, ob eine Methode bereits eingesetzt wird oder
nicht. Um dies in Erfahrung zu bringen eignet sich ein Fragebogen, der dem dritten Abschnitt aus der
Umfrage in der Business-Unit (Kapitel 3.4.1, ab Seite 73) ähnelt.
Kennst Du „…“?
Wertung
Ja, kenne ich sogar sehr gut.
3
Ja, kenne ich.
1
Ja, aber nur vom Namen her.
0
Nein, nie gehört.
0
Möchte ich nicht einschätzen.
?
Tabelle 19 - Frage 1: „Ist die Methode bekannt?“
Die in Tabelle 19 aufgeführte Frage bringt in Erfahrung, wie gut ein Teammitglied die entsprechende
Methode kennt. Da jeder Antwortkategorie ein Wert zugeordnet ist, kann eine Teamwertung je
Methode erfolgen. Anhand dieser Wertung kann eine Reihenfolge gebildet werden. Eine niedrige
Wertung entspricht hierbei einem geringen Bekanntheitsgrad. Die Antwortkategorie „Möchte ich
nicht einschätzen.“ wird bei der Wertung nicht berücksichtigt (deswegen das Fragezeichen) und kann
vom Befragten dazu genutzt werden, keine Bewertung abzugeben.
Wird die Antwortkategorie „Nein, nie gehört.“ oder „Ja, aber nur vom Namen her.“ gewählt, entfallen weitere Fragen zur Methode.
Wird „…“ derzeit eingesetzt?
Wertung
Ja.
1
Nein.
-1
Weiß ich nicht.
?
Tabelle 20 - Frage 2: „Wird die Methode derzeit eingesetzt?“
Die Frage in Tabelle 20 gibt Auskunft darüber, ob eine Methode bereits eingesetzt wird. Die Antwortkategorien sind hierzu mit einem Wert versehen. Ist die Summe über alle Antworten zu einer Methode größer Null, ist davon auszugehen, dass die Methode aktuell eingesetzt wird. Falls der Befragte
es nicht einschätzen kann, kann er die Antwortkategorie „Ich weiß nicht.“ wählen. Diese Antwortkategorie wird in der Wertung nicht berücksichtigt.
Patrick Rehder
88
Master-Thesis
Ist es Deiner Meinung nach sinnvoll „…“ einzusetzen?
Wertung
Ja, es ist sehr sinnvoll.
2
Ja, es ist sinnvoll.
1
Nein, es ist nicht sinnvoll.
-1
Nein, es ist gar nicht sinnvoll.
-2
Kann ich nicht einschätzen.
?
Tabelle 21 - Frage 3: „Ist es sinnvoll die Methode einzusetzen?“
Über Frage 3 (Tabelle 21) kann ermittelt werden, ob eine Methode als sinnvoll eingeschätzt wird. Auf
Basis der Teamwertung zur Methode lässt sich eine Reihenfolge erstellen. Bei Methoden die sich
derzeit nicht im Einsatz befinden kann die Reihenfolge dazu genutzt werden, um die nächste einzuführende Methode auszuwählen. Befindet sich die Methode im Einsatz, kann aus der Teamwertung
abgelesen werden, ob der Einsatz der Methode als sinnvoll erachtet wird.
Für Anmerkungen und Kommentare soll zu jeder Methode ein Textfeld angeboten werden.
Nachdem jede Methode eine Teamwertung zur Kenntnis, zum Einsatz und zur Sinnhaftigkeit erhalten
hat, können Ranglisten in folgenden Kategorien gebildet werden:

Methoden mit großem Schulungsbedarf
Alle Methoden sortiert nach einer niedrigen Kenntniswertung.

Einsatzbereitschaft der Methoden
Alle Methode die nicht im Einsatz sind, sortiert nach einer hohen Sinnhaftigkeit.

Erfolgreich angewendete Methoden
Alle Methoden die im Einsatz sind, sortiert nach einer hohen Sinnhaftigkeit.
Die Ranglisten bieten eine Orientierung für welche Methoden es sich lohnt, sich weiter mit ihnen zu
beschäftigen. Für Methoden mit einem großen Schulungsbedarf wird ein Teammitglied gesucht,
welches sich mit dem Thema beschäftigt. Eine Methode deren Einsatz als besonders sinnvoll erachtet
wird, ist in einer Teamrunde zu besprechen und gegebenenfalls zu erproben. Wird eine Methode
eingesetzt und von den meisten Teammitgliedern als nicht sinnvoll eingeschätzt, muss überlegt
werden die Methode nicht weiter einzusetzen.
Über die Ranglisten lässt sich ein Bild für das Vorgehen zur Einführung gewinnen. Dieses kann durch
detaillierte Fragen weiter verfeinert werden, was jedoch den Aufwand je Teilnehmer und für die
Auswertung erhöht.
Digitale Befragung
Für die Datenerhebung ist von jedem Teammitglied ein Fragebogen auszufüllen. Der Zeitbedarf ist
hierbei in Summe nicht unerheblich: Sind für 35 Methoden je 3 Fragen zu beantworten, bei einer
angenommen Antwortzeit von 15-20 Sekunden pro Frage, ergibt sich daraus eine Gesamtbearbeitungszeit von etwa 30 Minuten je Teilnehmer. Da eine regelmäßige Befragung geplant ist, summie-
Patrick Rehder
89
Master-Thesis
ren sich die Aufwände bei jeder Befragung. Um die Ergebnisse möglichst aktuell zu halten, ist insbesondere nach einer Schulung oder dem Einsatz einer Methode, eine Umfrage durchzuführen. Hierbei
ist es jedoch nicht erforderlich immer alle Methoden neu zu bewerten, sondern nur betroffene
Methoden. Dies reduziert den Aufwand für nachfolgende Befragungen.
Der Aufwand zur Auswertung wurde noch nicht betrachtet. Da es sich um geschlossene Fragen
handelt und den Antwortkategorien ein Wert zugewiesen wurde, ist es möglich die Ranglisten
vollautomatisch zu erstellen. Somit entsteht bei wiederholten Umfragen kein Aufwand beim Auswerten. Nur die Freitextfelder können nicht automatisiert berücksichtigt werden. Die Anmerkungen
direkt zu berücksichtigen ist allerdings auch nicht erforderlich. Sie können durchgesehen werden,
wenn sich mit der jeweiligen Methode auseinandergesetzt wird.
Um die Auswertung zu automatisieren ist es hilfreich, dass die Antworten über einen digitalen
Fragebogen erfasst werden. Wobei das eingesetzte Umfrage-System in der Lage sein muss eine
automatische Auswertung durchzuführen. Ist dem nicht so, muss das System zumindest über eine
Exportfunktion verfügen, damit die Auswertung in einer anderen Anwendung erfolgen kann.
Alternative kann auch eine eigene Anwendung entwickelt werden. Die Anzahl der Fragen ist überschaubar und die Auswertungslogik beschränkt sich auf die Grundrechenarten. Damit gestaltet sich
eine solche Anwendung übersichtlich, wie folgenden Skizzen einer möglichen Benutzeroberfläche
zeigen. Die Skizzen verdeutlichen außerdem, wie eine Befragung ablaufen könnte.
Abbildung 17 - Skizze der Benutzeroberfläche: Methodenübersicht
In der Methodenübersicht (siehe Abbildung 17) werden alle Methoden aufgelistet. Oben stehen
Methoden die noch nicht bewertet wurden. Danach folgen in absteigender Reihenfolge die Methoden, deren Bewertung am längsten zurückliegt.
Patrick Rehder
90
Master-Thesis
Abbildung 18 - Skizze der Benutzeroberfläche: Frage 1 und Frage 2
Wird eine Methode in der Methodenübersicht ausgewählt, werden für diese Methode die Fragen zur
Bewertung geöffnet (siehe Abbildung 18). Hat der Benutzer die Methode bereits bewertet, werden
seine zuvor gegebenen Antworten hervorgehoben.
Abbildung 19 - Skizze der Benutzeroberfläche: Frage 3 und Anmerkungen
In Abbildung 19 wird die Bewertung über Frage 3 abgeschlossen, danach hat der Benutzer noch die
Möglichkeit eine Anmerkung in einem Freitextfeld zu verfassen. Wird im Anmerkungsfenster die
Schaltfläche „fertig“ gewählt, öffnet sich die Methodenübersicht des Benutzers.
Patrick Rehder
91
Master-Thesis
Abbildung 20 - Skizze der Benutzeroberfläche: Ranglisten
In den Ranglisten (Abbildung 20) werden die Methoden anhand der Teambewertung entsprechend
einsortiert.
Es ist denkbar die Anwendung als Client-Server-Anwendung oder als Webanwendung umzusetzen. In
den Skizzen wurde die Administration von den Benutzern und Methoden nicht berücksichtigt.
4.3.
Nachbetrachtung
Egal ob ein bestimmtes oder ein eigenes Vorgehensmodell als Basis für die Einführung genutzt wird,
folgende Voraussetzungen müssen erfüllt sein:

Die Projektbeteiligten müssen motiviert sein neue Wege zu gehen.

Es muss Zeit zur Verfügung stehen und eventuell auch Geld, beispielsweise für Material.
Wollen sich die Projektbeteiligten nicht anpassen, klammern sie sich am alten Vorgehen fest und
versuchen die neuen Prozesse zu umgehen. Außerdem können sie Veränderungen bei anderen
Projektbeteiligten schlecht machen und damit für eine schlechte Stimmung sorgen. Vorgesetzte
haben darüber hinaus Befugnisse, mit denen sie Zeit und Geld zur Verfügung stellen – oder auch
nicht. Ohne Zeit ist es nicht möglich sich mit einem neuen Prozess zu beschäftigen und diesen
umzusetzen.
Sind die Voraussetzungen gegeben, ist zwischen einer radikalen und einer iterativen Prozesseinführung zu wählen. Die Vorteile einer iterativen Einführung wurden zuvor bereits genannt, sie birgt
jedoch auch Nachteile. Werden ständig Neuerungen etabliert, führt dies zu einer ständigen Belastung
Patrick Rehder
92
Master-Thesis
des Projektteams. Dies kann dazu führen, dass die Motivation über die Zeit versiegt und weitere
Einführungen damit blockiert werden. Bei einer radikalen Prozesseinführung hingegen, wird zu
einem Stichtag oder zu Beginn eines neuen Projekts das Vorgehen „komplett“ umgestellt. Hierdurch
müssen sich die Beteiligten zwar geballt an etwas Neues gewöhnen, dafür ist die Gefahr geringer
dass an alten Gewohnheiten festgehalten wird. [10, p. 70]
Die beste Lösung liegt in einem gemischten Vorgehen: Zu Beginn wird ein Rahmen radikal eingeführt
und danach kann dieser über Schleifen verbessert und angepasst werden. Vor diesem Hintergrund ist
Continuous Method Evaluation nicht die beste Wahl, um ein agiles Vorgehen in einem klassisch
organisierten Projektteam zu etablieren. Es bietet sich vielmehr an, wenn ein agiles Vorgehen bereits
vorhanden ist und dieses um weitere Methoden erweitert werden soll.
Für die Einführung agiler Prozesse und Methoden wird außerdem eine treibende Kraft benötigt, in
Scrum und Extreme Programming sind hierfür extra Rollen vorgesehen. Es muss sich jemand
verantwortlich fühlen, der sich zumindest mit dem Prozess oder der Methoden beschäftigt hat und
die Umsetzung im Auge behält.
Zu Beginn von Kapitel 4 wurden folgende Fragen in Bezug auf die Business-Unit gestellt:

Soll ein bestimmtes Vorgehensmodell eingesetzt werden?

Ist ein eigenes Vorgehen mit weiteren agilen Methoden erstrebenswert?
Beide Szenarien sind denkbar. Aufgrund der Voraussetzungen sind Scrum und Extreme Programming geeignet, wobei Scrum vom Team bevorzugt wird. Beide würden das derzeitige Vorgehensmodell ablösen. Die Alternative besteht darin das aktuelle Vorgehen um weitere Methoden anzureichern. Hierfür könnte Continuous Method Evaluation erprobt werden.
Patrick Rehder
93
>>> Ergebnis
5.
Master-Thesis
Ergebnis
Kapitel 1.2 (Seite 8) führt die Ziele dieser Arbeit auf:



Beim Betrachten der agilen Softwareentwicklung konnten wertvolle Erkenntnisse gewonnen werden.
Ein agiles Vorgehen definiert sich über die Werte, welche im Agile Manifest festgehalten sind.
Werden diese Werte in Softwareprojekten geschätzt, entsteht eine Kultur die berücksichtigt, dass
Software von Menschen für Menschen entwickelt wird. In einer solchen Umgebung können sich Agile
Prozesse wie Scrum, Feature Driven Development und Extreme Programming entfalten.
Werden die Prozesse miteinander verglichen, zeigt sich die Agilität von ihrer vielfältigen Seite:

Scrum beschreibt einen Rahmen mit einer flachen Hierarchie und gibt wenig Details vor.

Feature Driven Development ist hierarchisch organisiert und kann gut skaliert werden.

Extreme Programming konzentriert sich auf das Programmieren und detailliert auf Methodenebene beschrieben.
Die Analyse des derzeitigen Vorgehens in der Business-Unit „Externe Produkte“ ergibt, dass das Team
entweder bereits agil unterwegs ist oder zumindest eine Kultur vorherrscht, die zu einem agilen
Vorgehen passt. Das identifizierte Vorgehensschema verfügt über Iterationen, die auch in agilen
Prozessen vorgesehen sind. Außerdem werden bereits agile Methoden eingesetzt, wie beispielsweise
Planning Poker oder ein Task Board. Aus der durchgeführten Umfrage geht hervor, dass die Teilnehmer mit den im Agile Manifest genannten Werten übereinstimmen und ein starkes Interesse an
der Einführung von Scrum besteht.
Das etablierte Vorgehen und die Kultur der Business-Unit „Externe Produkte“ zeigen, dass es auch in
einer konservativen Umgebung möglich ist agile Ideen umzusetzen. Ein solches Vorgehen stellt erst
einmal eine Insellösung dar. Das Etablieren einer agilen Insel ist im Falle der Business-Unit über
folgende Voraussetzungen zu begründen:

Vorhandenes Interesse im Team sich zu verbessern.

Eine treibende Kraft im Team für ein agiles Vorgehen.

Bereitstellen von Freiräumen durch den Vorgesetzten.
Jeder der genannten Punkte bezieht sich auf Menschen. Die beteiligten Personen sind der maßgebliche Erfolgsfaktor für die Einführung einer agilen Vorgehensweise.
Patrick Rehder
94
>>> Ergebnis
Master-Thesis
Das weitere Vorgehen für die Business-Unit lässt sich nicht eindeutig bestimmen, vielmehr konnten
Möglichkeiten ausgemacht werden. Es ist sowohl denkbar, ein bestimmtes Vorgehensmodell zu
etablieren, als auch das eigene Vorgehensmodell weiterzuentwickeln.
Die aktuelle Situation (Stand: Juli 2012) zeigt, dass Scrum in einem neuen Projekt als Vorgehensmodell eingesetzt wird. Das gewünschte Vorgehen wurde zu Beginn mit dem Kunden in der Commerzbank besprochen, welcher letztlich gewillt war dies auszuprobieren. Aufgrund der geringen Projektbesetzung mit vier Entwicklern werden Scrum Master und Product Owner jeweils von einem Entwickler wahrgenommen. Zuvor wurde der Ablauf von Scrum bereits in einem Modell-Projekt mit
Auszubildenden begutachtet, welches von der Business-Unit begleitet wurde. Letztlich wurde sich
dafür entschieden ein bestimmtes Vorgehensmodell einzusetzen, nämlich Scrum.
Patrick Rehder
95
>>> Glossar
A.
Master-Thesis
Glossar
keit zeugt, also regsam und wendig ist.
[duden.de]
Akzeptanztest
30
27
24
21
18
15
12
9
6
3
0
Tag 1
Tag 2
Tag 3
Tag 4
Tag 5
Tag 6
Tag 7
Tag 8
Tag 9
Tag 10
Tag 11
Tag 12
Tag 13
Tag 14
Etwas ist agil, wenn es von großer Beweglich-
offene Aufgaben
Agil
Ein Akzeptanztest prüft, ob eine User Story
den Erwartungen des Kunden entspricht. Vor
der Umsetzung einer User Story sind vom
Abbildung 21 - Beispiel: „Burn Down Chart“
Kunden sogenannte Akzeptanzkriterien zu
Business-Unit
definieren, die im Rahmen eines Akzeptanz-
In der Commerz Systems GmbH werden
tests geprüft werden.
Abteilungen als Business-Unit bezeichnet.
API
Als Application Programming Interface (API)
Clean Code Development bezeichnet ein
wird eine Schnittstelle bezeichnet, die von
normgebendes Wertesystem für Software-
anderen Komponenten, Programmen und
entwickler, dessen Einhaltung die Qualität von
Softwaresystemen genutzt werden kann.
Software sichert. Ihm liegt der Anspruch
Architectural Patterns
zugrunde, die Lesbarkeit von Code zu standar-
Architekturmuster
(englisch:
Architectural
Patterns) beschreiben bewährte Ansätze für
disieren, was allen beteiligten Entwicklern ein
effektives Zusammenarbeiten gestattet. [54]
Architekturen von Softwaresystemen. Da
Crystal
Architekturmuster auf Erfahrungen beruhen,
„Crystal stellt keine einzelne agile Methode
machen sie Erfahrung „wiederverwendbar“.
dar, sondern eine Methodenfamilie. Eine
[53, p. 164]
Grundidee von Crystal besteht darin, dass
Burn Down Chart
kein Projekt dem anderen gleicht, dass jedes
Ein Burn Down Chart stellt die Menge verbleibender Arbeit, der Zeit grafisch gegenüber
Projekt in einer speziellen Situation angesiedelt ist und dass jedes Team besonders ist.“
[55, p. 14]
(siehe Abbildung 21). Diese Darstellungsform
erlaubt es den Gesamtfortschritt auf einen
Blick abzulesen. Es ist jedoch nicht zu erkennen, wie weit eine einzelne Aufgabe abgearbeitet wurde.
Patrick Rehder
96
>>> Glossar
Master-Thesis
Geschäftswert
Overall Design
Der Nutzen den die Funktion eines Software-
Das Overall Design beschreibt bei Feature
systems zur Verfügung stellt, wird als Ge-
Driven Development die Gesamtarchitektur
schäftswert bezeichnet. Der Geschäftswert ist
des zu entwickelnden Systems. Es besteht aus
meist schwer zu beziffern und stark vom
einem
Blickwinkel des Betrachters abhängig.
Sequenzdiagrammen und Notizen zu getroffe-
Kanban
Klassendiagramm,
gegebenenfalls
nen Entscheidungen.
Kanban stellt eine Methode zum Change
PMBOK
Management dar. Es ist das Ziel den beste-
Beim
henden Prozess schrittweise zu verbessern.
Knowledge (PMBOK) handelt es sich um eine
Hierbei spielt Visualisierung eine große Rolle.
Sammlung von in der Praxis als geeignet
[6, p. 14]
identifizierter Vorgehensweisen, zur Durch-
Project
Management
Body
of
führung von Projekten. Er wird vom American
Klasse
National Standards Institute (ANSI) aner-
Eine Klasse ist ein Begriff aus der objektorien-
kannt und vom Project Management Institute
tierten Programmierung. Sie stellt ein abstrak-
(PMI) gepflegt. [56, p. 15]
tes Modell dar, aus welchem Objekte erzeugt
werden können. Durch die Klasse wird vorge-
Rapid Prototyping
geben über welche Eigenschaften und Verhal-
Hinter Rapid Prototyping oder auch nur
tensweisen die Objekte später verfügen.
Prototyping verbirgt sich in der Softwareent-
Logging
wicklung ein Vorgehen, bei welchem möglichst schnell ein Prototyp entwickelt wird.
Das Protokollieren von Ereignissen während
Dieser Prototyp wird dann als Gesprächsge-
der Laufzeit eines Programmes wird als
genstand für weitere Verbesserungen genutzt.
Logging bezeichnet.
Open Source
Beim Rational Unified Process handelt es sich
Open Source bezeichnet Software deren
um ein Vorgehensmodell für die Entwicklung
Lizenz folgende Merkmale aufweist:
von Anwendungen. Der Prozess macht hierbei


Der Quelltext liegt in einer für den
intensiven Gebrauch der Modellierungsspra-
Menschen lesbaren und verständli-
che UML. Sogar der Prozess selber ist in UML
chen Form vor.
beschrieben. [57]
Die Software darf beliebig kopiert,
verbreitet und genutzt werden.

Die Software darf verändert und in
veränderter Form weitergegeben werden.
Patrick Rehder
97
>>> Glossar
Master-Thesis
Refactoring
White-Box-Test zuordnen.
Ein „Refactoring […] bezeichnet in der Soft-
Der Quelltext wird einer Reihe formaler
ware-Entwicklung die manuelle oder automa-
Prüfungen unterzogen, bei denen bestimmte
tisierte Strukturverbesserung von Programm-
Sorten von Fehlern/Schwachstellen im Code
Quelltexten unter Beibehaltung des be-
entdeckt werden können. Das Ziel hierbei ist
obachtbaren
immer nur das Aufzeigen von Fehlern, es wird
Programm-Verhaltens.
Dabei
sollen die Lesbarkeit, Verständlichkeit, Wart-
nichts aktiv am Code verändert […].“ [60]
barkeit
UML
und
Erweiterbarkeit
verbessert
werden, mit dem Ziel, den jeweiligen Aufwand
für Fehleranalyse und funktionale Erweiterungen deutlich zu senken.“ [58]
„Die Unified Modeling Language (UML) dient
zur Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Software-
Release
systeme, unabhängig von deren Fach- und
Ein Release bezeichnet den produktiven
Realisierungsgebiet.“ [61, p. 10]
Einsatz einer Anwendung. Es kann sich hierbei
Unit-Test
entweder um eine neu entwickelte Anwendung handeln oder eine neue Version einer
bestehenden Anwendung.
„Unit-Tests (=Komponententests) überprüfen,
ob die von den Entwicklern geschriebenen
Komponenten so arbeiten, wie diese es
Spiralmodell
beabsichtigen. In agilen Methoden wird zur
Das Spiralmodell ist ein „von Barry W. Boehm
Qualitätssicherung eine sehr häufige Ausfüh-
im
generisches
rung der Komponententests angestrebt. Das
Vorgehensmodell der Softwareentwicklung,
lässt sich nur erreichen, wenn die Tests
das die vier Phasen:
vollständig automatisiert vorliegen, sie also
Jahr
1986
entwickeltes,
selbst ein Programm sind, dessen Ausführung

Festlegen der Ziele

Risikoanalyse
erfordert. Dabei ist es üblich (aber nicht

Entwicklung und Test
zwingend notwendig), dass der Test in der

Planung des nächsten Zyklus
zyklisch durchläuft und so über verschiedene
Prototypen zum Endprodukt gelangt.“ [59]
Statische Code Analyse
nicht mehr Aufwand als einen Knopfdruck
gleichen Sprache wie das Testobjekt geschrieben wird.“ [62]
Use Case
„Ein Anwendungsfall (engl. Use Case) bündelt
alle
möglichen
Szenarien,
die
eintreten
„Statische Code Analyse ist ein statisches
können, wenn ein Akteur versucht, mit Hilfe
Software-Testverfahren. Im Gegensatz zu
des betrachteten Systems ein bestimmtes
dynamischen Testverfahren muss die zu
fachliches Ziel […] zu erreichen. Er beschreibt,
testende Software nicht ausgeführt werden.
was inhaltlich beim Versuch der Zielerreichung
Es wird also nur der Quelltext benötigt. Daher
passieren kann und abstrahiert von konkreten
lässt sich die statische Code Analyse dem
technischen Lösungen. Das Ergebnis des
Patrick Rehder
98
>>> Glossar
Master-Thesis
Anwendungsfalls kann ein Erfolg oder Fehl-

Systemtest
schlag/Abbruch sein.“ [63]

Einsatz/Wartung
V-Modell
„Das V-Modell gliedert den Softwareentwicklungsprozess in sechs Phasen:
[65, p. 211]
Wiki
Bei einem Wiki handelt es sich um eine

Anforderungsanalyse

Systementwurf
zern nicht nur gelesen, sondern auch geändert

Entwurf und Implementierung der
werden kann. Die Grundidee eines Wikis liegt
Module
darin Texte gemeinschaftlich zu bearbeiten.

Modultest

Systemintegration

Systemabnahme
Webanwendung, deren Inhalt von den Benut-
[66]
Wirtschaftlichkeit
„Ein Unternehmen arbeitet wirtschaftlich,
wenn es gemäß der Gewinn-und-Verlust-
Letztere drei Phasen bilden die Tests für die
Rechnung höhere Erträge als Aufwendungen
Produkte der ersten drei Phasen.“
hat […] oder wenn es gemäß der Kosten- und
[64, pp. 3, 4]
Leistungsrechnung höhere Leistungen als
V-Modell XT
Kosten hat […].“ [67, pp. 442, 443] Verallge-
„Das V-Modell XT (V: Vorgehensmodell) ist für
alle IT-Projekte des Bundes einzusetzen […].“
meinert bedeutet dies, dass ein Vorhaben
wirtschaftlich ist, wenn der Nutzen die Kosten
übersteigt.
[65, p. 213] Es handelt sich um eine Erweiterung vom V-Modell.
W-Modell
Wasserfallmodell
„Das W-Modell ist ein Vorgehensmodell für
Das Wasserfallmodell ist ein Vorgehensmodell
zur Softwareentwicklung. Es beschreibt fünf
Phasen die strikt voneinander getrennt sind
und nacheinander durchlaufen werden:
die Softwareentwicklung, es beruht auf dem
weit verbreiteten V-Modell. Beim W-Modell
werden die Testaktivitäten parallel zu den
Entwicklungsaktivitäten
[…]
durchgeführt.
Testaktivitäten beginnen frühzeitig und die

Problemanalyse/Produktdefinition
Abhängigkeiten und Zyklen zwischen testen -

Entwurf
debugging - korrigieren - erneutes testen

Implementierung
werden im W-Modell deutlich.“ [68]
Patrick Rehder
99
>>> Abbildungsverzeichnis
B.
Master-Thesis
Abbildungsverzeichnis
Abbildung 1 - Die Werte vom Agile Manifest ........................................................................................ 11
Abbildung 2 - Kommunikationsarten zur Diskussion und Dokumentation [17, p. 84] .......................... 13
Abbildung 3 - Scrum: „Die drei Säulen der empirischen Prozesssteuerung“ [19, p. 4]......................... 16
Abbildung 4 - Scrum: „Der Begriff als Zeichnung“ [www.scrum-kompakt.de] ..................................... 17
Abbildung 5 - FDD: „Prozessübersicht mit zeitlicher Verteilung“ [34, p. 198] ...................................... 36
Abbildung 6 - XP: „Den Regler auf 10 drehen.“ [38, p. xv] .................................................................... 42
Abbildung 7 - XP: „Unter der Lupe betrachtet.“ ................................................................................... 43
Abbildung 8 - XP: „Team Workspace“ [40, p. 'Figure 5. A team workspace'] ....................................... 50
Abbildung 9 - Allgemeines Vorgehensmodell ....................................................................................... 63
Abbildung 10 - Vorgehen bei der Weiterentwicklung von ASTAT......................................................... 64
Abbildung 11 - Vorgehen bei der Neuentwicklung von NIOB ............................................................... 65
Abbildung 12 - Vorgehen bei der Neuentwicklung von TANTAL ........................................................... 66
Abbildung 13 - Umfassender Kartensatz für Planning Poker ................................................................ 68
Abbildung 14 - Schema: Task Board [25, p. 12] ..................................................................................... 69
Abbildung 15 - Die Werte vom Agile Manifest in der Business-Unit „Externe Produkte“ .................... 80
Abbildung 16 - Vorgehensmodell mit Feature Driven Development .................................................... 83
Abbildung 17 - Skizze der Benutzeroberfläche: Methodenübersicht ................................................... 90
Abbildung 18 - Skizze der Benutzeroberfläche: Frage 1 und Frage 2.................................................... 91
Abbildung 19 - Skizze der Benutzeroberfläche: Frage 3 und Anmerkungen ......................................... 91
Abbildung 20 - Skizze der Benutzeroberfläche: Ranglisten ................................................................... 92
Abbildung 21 - Beispiel: „Burn Down Chart“ ......................................................................................... 96
Patrick Rehder
100
>>> Tabellenverzeichnis
C.
Master-Thesis
Tabellenverzeichnis
Tabelle 1 - Gegenüberstellung der Ziele und Kapitel .............................................................................. 8
Tabelle 2 - Ausschnitte aus Umfragen zur Anwendung agiler Prozesse ................................................. 9
Tabelle 3 - Scrum: „Register der Bestandteile“ ..................................................................................... 18
Tabelle 4 - Scrum: „Der Shewhart Cycle im Sprint“ [14, p. 49] ............................................................. 21
Tabelle 5 - Scrum: „Zeit zur Produktentwicklung in einem vierwöchigen Sprint“ [19] ......................... 22
Tabelle 6 - Scrum: „Übersicht möglicher Artefakte“ ............................................................................. 25
Tabelle 7 - FDD: „Register der Bestandteile“ ........................................................................................ 33
Tabelle 8 - FDD: „Die jeweiligen Vorteile von Class Ownership und Collective Ownership“ ................ 35
Tabelle 9 - XP: „Register der Bestandteile“ ........................................................................................... 44
Tabelle 10 - XP: „Strukturierung der Methoden“ .................................................................................. 49
Tabelle 11 - Prozesseignung hinsichtlich Voraussetzung (angepasst) [6, p. 22] ................................... 60
Tabelle 12 - Projektdauer je Release (Dauer gerundet) ........................................................................ 64
Tabelle 13 - Auflistung der fünf Abschnitte des Fragebogens .............................................................. 74
Tabelle 14 - Zuordnung: Punkte im Agile Manifest und Punkte im Fragebogen .................................. 76
Tabelle 15 - Einschätzung der Zufriedenheit ......................................................................................... 77
Tabelle 16 - Bekanntheitsgrad der Vorgehensmodelle ......................................................................... 78
Tabelle 17 - Bekanntheitsgrad von Techniken und Methoden ............................................................. 79
Tabelle 18 - Beispiel: Liste mit 35 Methoden (alphabetisch sortiert) ................................................... 87
Tabelle 19 - Frage 1: „Ist die Methode bekannt?“ ................................................................................ 88
Tabelle 20 - Frage 2: „Wird die Methode derzeit eingesetzt?“ ............................................................. 88
Tabelle 21 - Frage 3: „Ist es sinnvoll die Methode einzusetzen?“......................................................... 89
Patrick Rehder
101
>>> Quellenverzeichnis
D.
Master-Thesis
Quellenverzeichnis
[1] H. Wolf und A. Roock, „Agilität wird Mainstream: Ergebnisse der Online-Umfrage 2008,“ OBJEKTspectrum,
pp. 10-13, März 2008.
[2] D. West und T. Grant, „Agile Development: Mainstream Adoption Has Changed Agility,“ Forrester
Research, Inc., Cambridge, 2010.
[3] „State of Agile Survey,“ VersionONE Inc., 2010.
[4] P. Haberl, A. Spillner, K. Vosseberg und M. Winter, Umfrage 2011: "Softwaretest in der Praxis", Heidelberg:
dpunkt.verlag GmbH, 2012.
[5] BQI Best Quality Institute GmbH, „Agile Softwareentwicklung am Standort Deutschland,“ 2010.
[6] H. Wolf und A. Roock, Agile Softwareentwicklung - Ein Überblick, 3. Auflage Hrsg., Heidelberg:
dpunkt.verlag, 2011.
[7] B. Gloger, Scrum - Produkte zuverlässig und schnell entwicklen, München Wien: Carl Hanser Verlag, 2008.
[8] S. R. Palmer und J. M. Felsing, A Practical Guide to Feature-Driven Development, New Jersey: Prentice Hall
International, 2002.
[9] K. Auer und R. Miller, Extreme Programming Applied: Playing to Win, Reading: Addison Wesley Publishing
Company, Inc., 2001.
[10] M. Andrezak, A. Bepple, J. Eckstein, S. Günther, H. Koschek, A. Leidig, A. Neubauer, C. Philipps, S. Reppin, S.
Röpstorff, A. Roock, S. Roock, B. Schiffer und H. Wolf, Agile Projekte mit Scrum, XP und Kanban in
Unternehmen durchführen, H. Wolf, Hrsg., Heidelberg: dpunkt.verlag, 2012.
[11] K. Beck, M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith,
A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin, S. Mellor, K. Schwaber, J. Sutherland und D. Thomas,
„Manifest für Agile Softwareentwicklung,“ [Online]. Available:
http://agilemanifesto.org/iso/de/manifesto.html. [Zugriff am 23. Februar 2012].
[12] C. Hibbs, S. Jewett und M. Sullivan, The Art of Lean Software Development, Sebastopol: O'Reilly, 2009.
[13] J. Highsmith, Agile Software Development Ecosystems, Amsterdam: Addison-Wesley Longman, 2002.
[14] B. Gloger, Scrum - Produkte zuverlässig und schnell entwickeln, München Wien: Carl Hanser Verlag, 2008.
[15] A. Kramer, „Vom "Faktor Mensch" und anderen Unwörtern,“ SQ Magazin, pp. 14, 15, Juni 2011.
[16] A. Cockburn, Agile Software Development, Boston: Addison-Wesley Professional, 2001.
[17] S. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, New
York: John Wiley & Sons, Inc., 2002.
[18] J. Dittmar, „Zusammenarbeit in IT Projekten und andere Wunder,“ 28. September 2011. [Online].
Available: http://www.scrumday.de/archiv/scrumdaysept11darmstadt/vortraege/Track4_SD2011_Dittmar_cocondi_Print_v1.0.pdf.
[Zugriff am 1. August 2012].
[19] K. Schwaber und J. Sutherland, „The Scrum Guide,“ Oktober 2011. [Online]. Available:
http://www.scrum.org/scrumguides/. [Zugriff am 23. Februar 2012].
[20] K. Schwaber, „Hintergrund: Die Wissenschaft von Scrum,“ in Agiles Projektmanagement mit Scrum,
Microsoft Press, 2007, pp. 1-16.
[21] J. Sutherland, „Agile Development: Lessons Learned form the First Scrum,“ Oktober 2004. [Online].
Patrick Rehder
102
Master-Thesis
Available: http://www.scrumalliance.org/resources/35. [Zugriff am 13. April 2012].
[22] H. Takeuchi und I. Nonaka, „The New New Product Development Game,“ Harvard Business Review, JanuarFebruar 1986.
[23] H. Koschek, Geschichten vom Scrum, Heidelberg: dpunkt.verlag, 1. Auflage 2010.
[24] K. Schwaber, Agile Project Management with Scrum, Redmond, Washington: Microsoft Press, 2004.
[25] B. Gloger, „Scrum Checklist 2011,“ 23. Februar 2011. [Online]. Available:
http://www.infoq.com/books/scrum-checklists. [Zugriff am 16. April 2012].
[26] wibas GmbH, „wibas Scrum Browser,“ wibas GmbH, [Online]. Available: http://www.scrumbrowser.com.
[Zugriff am 12. April 2012].
[27] J. Spolsky, „Product Vision - Joel on Software,“ 09. Mai 2002. [Online]. Available:
http://www.joelonsoftware.com/articles/JimHighsmithonProductVisi.html. [Zugriff am 03. April 2012].
[28] GPM Deutsche Gesellschaft für Projektmanagement e.V., Kompetenzbasiertes Projektmanagement (PM3),
4. Hrsg., Bd. 1, M. Gessler, Hrsg., Nürnberg: GPM Deutsche Gesellschaft für Projektmanagement e.V.,
2011.
[29] R. Wirdemann, Scrum mit User Stories, 2. erweiterte Auflage Hrsg., München: Carl Hanser Verlag, 2011.
[30] K. Pohl und C. Rupp, Basiswissen Requirements Engineering, Heidelberg: dpunkt.verlag, 2009.
[31] C. Stackpole, PMP Certification All-in-One For Dummies, Hoboken, New Jersey: John Wiley & Sons, Inc.,
2011.
[32] „Scrum: The Basics,“ Scrum Alliance Inc., [Online]. Available:
http://www.scrumalliance.org/pages/what_is_scrum. [Zugriff am 16. März 2012].
[33] S. Roock, „Interview: Jeff De Luca on Feature Driven Development,“ it-agile, [Online]. Available:
http://www.it-agile.de/fddinterview.html. [Zugriff am 11. April 2012].
[34] P. Coad, E. Lefebvre und J. De Luca, „Feature-Driven Development,“ in Java Modeling in Color with UML,
New Jersey, Prentice Hall, 1999, pp. 182-203.
[35] Nebulon Pty. Ltd., „The Latest FDD Processes,“ 21. November 2004. [Online]. Available:
http://www.nebulon.com/articles/fdd/latestprocesses.html. [Zugriff am 11. April 2011].
[36] F. Brooks, The Mythical Man-Month, Boston: Addison-Wesley, 1995.
[37] K. Meergans, „Feature-Driven Development - Bewertung und Voraussetzungen einer erfolgreichen
Anwendung,“ 12. August 2011. [Online]. Available: http://www.frankdopatka.de/reutlingen-seminar.php.
[Zugriff am 11. April 2012].
[38] K. Beck, Extreme Programming - Die revolutionäre Methode für Softwareentwicklung in kleinen Teams,
München: Addison-Wesley Verlag, 2000.
[39] S. Baird, Extreme Programming in 24 Hours, Indianapolis: Sams Publishing, 2003.
[40] K. Beck und C. Andres, Extreme Programming Explained: Embrace Change, Second Edition, Boston:
Addison-Wesley Professional, 2004.
[41] H. Breitling, „Extreme Programming: XP Revisited,“ Software & Support Media GmbH, Februar 2012.
[Online]. Available: http://www.it-republik.de/jaxenter/artikel/4392. [Zugriff am 15. Mai 2012].
[42] E. Hanser, Agile Prozesse: Von XP über Scrum bis MAP.
[43] M. Lippert, S. Roock und H. Wolf, Software entwickeln mit eXtreme Programming, 1. Auflage Hrsg.,
Heidelberg: dpunkt.verlag GmbH, 2002.
[44] J. Brodwall, „Pair programming research misses the most important point,“ 2. Feburar 2011. [Online].
Available: http://johannesbrodwall.com/2011/02/02/pair-programming-research-misses-the-most-
Patrick Rehder
103
Master-Thesis
important-point/. [Zugriff am 1. Juni 2012].
[45] P. Rehder, „Bericht zum Praxissemester,“ Commerz Systems GmbH, Bremen, 2009.
[46] J. Grenning, „Planning Poker or How to avoid analysis paralysis while release planning,“ April 2002.
[Online]. Available: http://www.renaissancesoftware.net/papers/44-planing-poker.html. [Zugriff am 12.
Juni 2012].
[47] M. Cohn, Agile Estimation and Planning, New Jersey: Prentice Hall International, 2005.
[48] Microsoft Corporation, „Visual Studio Team Foundation Server,“ [Online]. Available:
http://www.microsoft.com/germany/visualstudio/products/team/visual-studio-team-foundationserver.aspx. [Zugriff am 13. Juni 2012].
[49] A. Spillner und T. Linz, Basiswissen Softwaretest, 3. Auflage Hrsg., Heidelberg: dpunkt.verlag, 2005.
[50] Preyer GmbH, „Online Befragungen mit echopoll.com,“ 9. August 2002. [Online]. Available:
https://echopoll.com/page/download. [Zugriff am 4. Mai 2012].
[51] 2ask, „Leitfaden für die Erstellung eines Fragebogens,“ 3. März 2007. [Online]. Available:
http://www.2ask.de/Leitfaden-zur-Fragebogenerstellung-allgemein--389d.html. [Zugriff am 5. Mai 2012].
[52] T. Görtz, „Agilität nachhaltig einführen und zwar sofort,“ SQ Magazin, p. 19, Juni 2012.
[53] oose Inovative Informatik GmbH, Trainingsunterlagen - Der agile Software-Architekt, 2008.
[54] „Clean Code Development Company,“ generic.de software technologies AG, [Online]. Available:
http://www.generic.de/de/company/profile/ccd.aspx. [Zugriff am 20. Juli 2012].
[55] H. Wolf und A. Roock, Agile Softwareentwicklung - Ein Überblick, 1. Auflage Hrsg., Heidelberg:
dpunkt.verlag, 2008.
[56] D. Tamke und P. Rehder, „Methoden des Projektmanagements im Vergleich,“ 9. Januar 2012. [Online].
Available: http://www.lippo-design.de/dev/. [Zugriff am 25. Juni 2012].
[57] Informatik Forum Simon GmbH, „Rational Unified Process (RUP),“ [Online]. Available:
http://www.infforum.de/themen/anwendungsentwicklung/thema_SE_rup.htm. [Zugriff am 20. Junli
2012].
[58] Wikipedia, „Refactoring,“ 7. September 2011. [Online]. Available:
http://de.wikipedia.org/w/index.php?title=Refactoring&oldid=93360684. [Zugriff am 20. Juli 2012].
[59] Gabler Verlag, „Gabler Wirtschaftslexikon: Spiralmodell,“ Springer Fachmedien Wiesbaden GmbH,
[Online]. Available: http://wirtschaftslexikon.gabler.de/Archiv/381707692/spiralmodell-v1.html. [Zugriff
am 30. Juli 2012].
[60] P. Rixner, „Statische Code Analyse,“ FH Wedel, 6. Januar 2009. [Online]. Available: http://www.fhwedel.de/~si/seminare/ws08/Ausarbeitung/11.ca/codeanalyse.html. [Zugriff am 30. Juli 2012].
[61] M. Jeckle, C. Rupp, J. Hahn, B. Zengler und S. Queins, UML 2 glasklar, München: Carl Hanser Verlag, 2004.
[62] it-agile GmbH, „Unit-Tests,“ [Online]. Available: http://www.it-agile.de/unittests.html. [Zugriff am 30. Juli
2012].
[63] Wikipedia, „Anwendungsfall,“ 12. Juni 2012. [Online]. Available:
http://de.wikipedia.org/w/index.php?oldid=104299082. [Zugriff am 30. Juli 2012].
[64] A. De Stefani, G. Fischer, M. Rohner, T. Strnad und T. Winkler, „fit 2002,“ TU Wien, 8. April 2002. [Online].
Available: http://cartoon.iguw.tuwien.ac.at/fit/fit01/spiral/konzepte.html#vmodell. [Zugriff am 30. Juli
2012].
[65] westermann, IT-Handbuch, 7. Auflage Hrsg., Braunschweig: Westermann Schroedel Diesterweg Schöningh
Winklers GmbH, 2011.
Patrick Rehder
104
Master-Thesis
[66] Wikiepdia, „Wiki,“ 9. Juli 2012. [Online]. Available:
http://de.wikipedia.org/w/index.php?title=Wiki&oldid=105370017. [Zugriff am 20. Juli 2012].
[67] Dudenverlag, Schülderduden Wirtschaft, Mannheim: Bibliographisches Institut & F. F. Brockhaus AG, 2002.
[68] A. Spillner, „W-Modell Vorgehensmodell für die Softwareentwicklung,“ 01. November 2010. [Online].
Available: http://www.informatik.hs-bremen.de/spillner/ForschungSpillnerWmo.pdf. [Zugriff am 30. Juli
2012].
[69] S. W. Ambler, „Introduction to Test Driven Development (TDD),“ [Online]. Available:
http://www.agiledata.org/essays/tdd.html. [Zugriff am 2. Juli 2012].
[70] T. DeMarco, Slack, Computer Bookshops, 2001.
Foto Deckblatt: Andreas Levers, „Wasserglas“, CC-Lizenz (BY 2.0)
http://creativecommons.org/licenses/by/2.0/de/deed.de
Quelle: www.piqs.de
Patrick Rehder
105
>>> Anhang
E.
Master-Thesis
Anhang
Anhang 1 - Fragebogen ................................................................................................................ 6 Seiten
Anhang 2 - Zusammenfassung der Antworten............................................................................. 6 Seiten
Patrick Rehder
106
Anhang 1 - Fragebogen
FRAGEBOGEN
Umfrage zur Master-Thesis
"Möglichkeiten der agilen Softwareentwicklung in einer konservativen Umgebung"
Seite 1 von 6
1
Abschnitt: Projektbewertung
Seite 2 von 6
2
Abschnitt: Vorgehensmodelle
[…]
[…]
Seite 3 von 6
3
Abschnitt: Techniken und Methoden
[…]
[…]
Seite 4 von 6
4
Abschnitt: Agile Softwareentwicklung
Seite 5 von 6
5
Abschnitt: Feedback
Seite 6 von 6
Anhang 2 - Zusammenfassung der Antworten
Anhang 2 – Zusammenfassung der Antworten
ZUSAMMENFASSUNG DER ANTWORTEN
Umfrage zur Master-Thesis
"Möglichkeiten der agilen Softwareentwicklung in einer konservativen Umgebung"
Seite 1 von 6
Frage 1.1
Wie zufrieden bist Du mit dem Vorgehen in Bezug auf die Softwareentwicklung in den Projekten?
-+
++
?
W
ASTAT
0
3
4
1
3
3
NIOB
0
3
3
0
5
0
TANTAL
0
3
4
2
2
5
0
9
11
3
10
8
∑
Legende
-- = sehr unzufrieden
++ = sehr zufrieden
? = nicht im Projekt
Wertung (W)
Summer über:
-- = -2
- = -1
+=1
++ = 2
Frage 1.2
Wie schätzt Du die Zufriedenheit der Auftraggeber mit dem Ergebnis ein? (Auftraggeber = Fachabteilung/Rot AG)
-+
++
?
W
ASTAT
2
4
2
0
3
-6
NIOB
1
0
2
3
5
6
TANTAL
0
1
2
7
1
15
3
5
6
10
9
15
∑
Legende
-- = sehr unzufrieden
++ = sehr zufrieden
? = nicht im Projekt
Wertung (W)
Summer über:
-- = -2
- = -1
+=1
++ = 2
Seite 2 von 6
Frage 2.1
Wie gut kennst Du die folgenden Vorgehensmodelle zur Entwicklung von Software?
!
!!
!!!
?
W
0
3
8
0
22
Wasserfallmodell
0
4
7
0
22
Scrum
Extreme Programming
2
7
2
0
20
7
4
0
0
15
1
3
4
3
12
V-Modell
6
1
2
2
10
Rapid Prototyping
2
3
1
5
5
Spiralmodell
3
1
2
5
4
W-Modell
5
0
1
5
2
V-Modell XT
Crystal
4
0
1
6
0
4
1
0
6
0
Lean Development
4
1
0
6
0
38
28
28
38
∑
Legende
! = schon mal gehört
!! = ich weiß was das ist
!!! = bereits eingesetzt
? = nie gehört
Wertung (W)
Summe über:
!=1
!! = 2
!!! = 2
? = -1
Frage 2.2
Welches der genannten Vorgehensmodelle entspricht dem Vorgehen in den Projekten ASTAT, NIOB und TANTAL am ehesten?
3
Scrum
3
Wasserfallmodell
1
1
Spiralmodell
1
V-Modell
Crystal
0
Extreme Programming
0
0
Lean Development
0
0
Rapid Prototyping
0
V-Modell XT
0
W-Modell
keines annährend
1
kenne keines
0
nicht in Projekten tätig
1
Frage 2.3
Wenn Du Dir ein Vorgehensmodell zur Softwareentwicklung für die Business-Unit "Externe Produkte" aussuchen darfst, welches der Folgenden wählst Du?
Crystal
0
Extreme Programming
0
0
0
Lean Development
0
8
Scrum
0
Rapid Prototyping
0
Spiralmodell
0
V-Modell
0
V-Modell XT
0
W-Modell
0
Wasserfallmodell
keines der genannten
1
egal
1
gar kein Vorgehensmodell
1
Frage 2.4
Denkst Du, dass es realistisch ist, ein Vorgehensmodell in der Business-Unit "Externe Produkte" einzuführen?
ja
10
nein
1
Seite 3 von 6
Frage 3.1
Wie gut kennst Du die folgenden Techniken und Methoden?
!
!!
0
0
0
0
Refactoring
0
0
Retrospektive
0
0
Taskboard
0
0
Unit-Testing
0
1
Daily Standup
0
2
0
2
Pair Programming
0
2
Planning Poker
0
3
User Stories
1
8
2
1
Definition of Done
4
3
Timeboxing
Burn Down Chart
2
6
6
3
Kanban
2
3
Product Vision
1
0
0
0
On-site Customer
18
34
∑
!!!
11
11
11
11
11
10
9
9
9
7
1
7
3
1
1
2
2
1
117
?
0
0
0
0
0
0
0
0
0
1
1
1
1
2
1
4
8
10
29
W
22
22
22
22
22
22
22
22
22
19
18
17
15
14
13
8
-3
-8
Gruppierung
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
sehr bekannt
bekannt
bekannt
bekannt
bekannt
bekannt
wenig bekannt
wenig bekannt
unbekannt
unbekannt
Legende
! = schon mal gehört
!! = ich weiß was das ist
!!! = bereits eingesetzt
? = nie gehört
Wertung (W)
Summe über:
!=1
!! = 2
!!! = 2
? = -1
Frage 3.2
Welche der genannten Techniken und Methoden wurden in den Projekten ASTAT, NIOB und TANTAL eingesetzt? (Achtung: Mehrfachauswahl.)
9
9
Unit-Testing
8
Planning Poker
8
Refactoring
8
Retrospektive
8
Taskboard
6
6
Daily Standup
5
Definition of Done
3
Pair Programming
2
1
1
Product Vision
Burn Down Chart
0
0
Kanban
0
On-site Customer
0
Timeboxing
0
User Stories
keine der genannten
1
kenne keine
0
nicht im Projekt tätig
1
Frage 3.3
Welche der genannten Techniken und Methoden sollen Deiner Meinung nach zukünftig eingesetzt werden? (Achtung: Mehrfachauswahl.)
11
Planning Poker
11
Refactoring
11
Taskboard
11
Unit-Testing
10
10
Retrospektive
9
9
Definition of Done
8
Daily Standup
7
Pair Programming
6
6
User Stories
Burn Down Chart
4
4
Timeboxing
3
wenig bekannt
(siehe Frage 3.1)
Product Vision
2
unbekannt
(siehe Frage 3.1)
0
wenig bekannt
(siehe Frage 3.1)
Kanban
0
unbekannt
(siehe Frage 3.1)
On-site Customer
keine der genannten
0
kenne keine
0
Seite 4 von 6
Frage 4.1
Für wie wichtig hältst Du die folgenden Punkte in der Softwareentwicklung?
-o
+
++
2
5
3
0
1
Festhalten an getroffenen Plänen
1
0
1
0
9
Funktionierende Software
0
0
4
6
1
Ideen des Einzelnen
0
1
1
1
8
Interaktion zwischen den Beteiligten
0
3
4
0
3
Verträge mit dem Kunden
1
0
4
5
1
Werkzeuge/Tools
1
0
0
5
5
0
2
2
4
3
Definierte Prozesse
0
4
0
7
0
Eine umfassende Dokumentation
0
1
1
2
7
Schnelle Reaktion auf Veränderungen
5
16
20
30
38
∑
?
0
0
0
0
1
0
0
0
0
0
1
W
-7
16
8
16
3
5
13
8
3
15
80
Legende
-- = sehr unwichtig
o = neutral
++ = sehr wichtig
? = weiß nicht
Wertung (W)
Summe über:
-- = -2
- = -1
o=0
+=1
++ = 2
Frage 4.2
Glaubst Du, dass die folgenden Punkte bei einer agilen Vorgehensweise mehr oder weniger ausgeprägt sind als bei einem nicht agilen Vorgehen?
-o
+
++
?
W
Legende
1
0
1
4
5
0
12
-- = viel weniger
Flexibilität erhöhen
1
1
6
3
0
0
0
o = gleich
Kosten einhalten/senken
0
1
4
4
2
0
7
++ = viel mehr
Kundenzufriedenheit erhöhen
1
1
4
3
2
0
4
? = weiß nicht
Mitarbeiterzufriedenheit erhöhen
0
1
2
6
2
0
9
Produktivität erhöhen
0
1
2
7
1
0
8
Wertung (W)
Qualität erhöhen
0
3
1
6
1
0
5
Summer über:
Risiken reduzieren
1
2
4
4
0
0
0
-- = -2
Termintreue erhöhen
0
1
0
6
4
0
13
- = -1
Transparenz erhöhen
4
11
24
43
17
0
58
o=0
∑
+=1
Frage 4.3
++ = 2
Welche dieser Aussagen trifft Deine Meinung zum Agilen Manifest am besten?
ich weiß was drin steht, es ist gut
3
ich weiß was drin steht, es ist schlecht
0
schon mal gehört, soll gut sein
4
schon mal gehört, soll schlecht sein
0
kenne ich gar nicht
4
Seite 5 von 6
Frage 5.1
Hier ist der Platz für Anregungen, Wünsche, Kommentare und Kritik; alles auf diesen Fragebogen bezogen:
- Ich denke, dass eine strikte Befolgung einer der beschriebenen Vorgehensweise in der Praxis nicht sinnvoll ist. Einzelne Teilbereiche sind sicherlich gut und sollten für
das jeweilige Projekt auf "Praxistauglichkeit" überprüft werden.
- IMHO: Die Mischung aus klassischem und agilen Projekt-Management ist die Kunst.
Seite 6 von 6

Möglichkeiten der agilen Softwareentwicklung - lippo

Transcription

Similar documents

1. und (5876) - Täglich laufen

PDF-Version - freiesMagazin

ifz Forschungsheft 14 - Institut für Zweiradsicherheit

Integrierter agiler Entwicklungsprozess für softwareintensive

Master`s Thesis in Wirtschaftsinformatik - sebis

Check_MK für jedermann

- AWO Bremen

Catalogue Outdoor Plus