Leseprobe
Inhaltsverzeichnis
I
Inhaltsverzeichnis
Inhaltsverzeichnis ... I
Abbildungsverzeichnis ... II
Abkürzungsverzeichnis ... IV
1.
Einleitung ... 1
1.1
Thematik ... 1
1.1.1
Arbeits- & Erkenntnisziel... 1
2.
Agile & Softwareentwicklung ... 3
2.1
Definition & Begriffliche Abgrenzung ... 3
2.1.1
Agile Fundamentals ... 8
2.1.2
Scrum & XP ... 11
2.1.3
Potenziale und Grenzen ... 17
3.
Acceleration ... 20
3.1
Definition & Begriffliche Abgrenzung ... 20
3.1.1
Complexity ... 20
3.1.2
Human Accelerators ... 27
3.1.3
Requirements Accelerators ... 30
3.1.4
Technology Accelerators ... 32
4.
Application Lifecycle Management ... 34
4.1
Begriffserklärung ... 34
4.2
Best Practices im Einsatz ... 43
4.2.1
Projektumgebung ... 48
4.2.2
Entwicklungsumgebung ... 55
4.2.3
Testumgebung ... 57
4.2.4
Tools ... 58
4.4
Das Ideale Tool-Set ... 60
5.
Fazit & Ausblick ... 62
Anhang ... VI
Literaturverzeichnis ... VII
Literaturverzeichnis: Online ... X
Abbildungsverzeichnis: Quellen ... XII
Abbildungsverzeichnis
II
Abbildungsverzeichnis
Abb. 1: Agile characteristics ... 3
Abb. 2: The Industrial paradigm ... 5
Abb. 3: Open loop system ... 5
Abb. 4: Standish Chaos Report ... 7
Abb. 5: The house of Scrum ... 12
Abb. 6: The Scrum gameboard ... 12
Abb. 7: Scrum flow ... 14
Abb. 8: Closed loop system ... 15
Abb. 9: Scrum/XP-Vergleich ... 17
Abb.10: The magic barrel ... 22
Abb.11: Stacey Complexity Matrix ... 22
Abb.12: Accelerator-Pyramide ... 32
Abb.13: Modern ALM ... 34
Abb.14 : Früher SCM-Ansatz ... 38
Abb.15: Wissensmanagement
Foswiki(1) ... 48
Abb.16: Wissensmanagement
Foswiki(2) ... 48
Abb.17: Zentrale Versionsverwaltung(1) ... 49
Abb.18: Zentrale Versionsverwaltung(2) ... 49
Abb.19: Projekt- & Build Management - Maven(1)... 50
Abb.20: Projekt- & Build Management - Maven(2)... 50
Abb.21: Repository-/Konfigurations-Management - Nexus(1) ... 51
Abb.22: Repository-/Konfigurations-Management - Nexus(2) ... 51
Abb.23: Continuous Integration - Jenkins(1) ... 52
Abb.24: Continuous Integration - Jenkins(2) ... 52
Abb.25: Bug Tracking - Bugzilla(1) ... 53
Abb.26: Bug Tracking - Bugzilla(2) ... 53
Abb.27: Test-Management - Testlink(1) ... 54
Abb.28: Test-Management - Testlink(2) ... 54
Abb.29: Eclipse Mylyn(1) ... 55
Abb.30: Eclipse Mylyn(2) ... 55
Abb.31: Versionskontrolle - Tortoise(1) ... 56
Abb.32: Versionskontrolle - Tortoise(2) ... 56
Abb.33: Testumgebung
IBM RAD ... 57
Abb.34: Business Process Modeling
Enterprise Architect(1) ... 58
Abb.35: Business Process Modeling
Enterprise Architect(2) ... 58
Abbildungsverzeichnis
III
Abb.36: Security-/Password-Manager(1) ... 59
Abb.37: Security-/Password-Manager(2) ... 59
Abkürzungsverzeichnis
IV
Abkürzungsverzeichnis
XP
Extreme Programming
ALM
Application Lifecycle Management
VCS
Version Control System
SCM
Software Configuration Management
Praxisprojekt: Accelerators für Agile Softwareentwicklung
1
1. Einleitung
1.1 Thematik
Die moderne Softwareentwicklung ist eine noch relativ junge Disziplin, die im
Hinblick auf die Erfordernisse der Zielerreichung mit der Zeit immer weiter an
dynamischeren Vorgehensmodellen und eingebettet darin, Methodologie,
gewinnt. Die Zielerreichung legt gute Software im qualitativen Sinne nahe.
Das wahre Ziel einer jeden Software ist die Schaffung von Mehrwerten für
den Endverbraucher, egal ob für den Geschäftskunden oder den Privatan-
wender. So werden aus technischer und methodologischer Sicht Hilfsmittel
geschaffen, die die Zielerreichung im Hinblick auf vorhandene Arbeitsmittel
möglichst zufriedenstellend erfüllen sollen. Qualität bedeutet also gute Soft-
ware in der Art der Entwicklung und in der Güte des vorgegebenen Prozes-
ses.
Eine Möglichkeit hierzu soll im nachfolgenden Praxisprojekt untersucht wer-
den: Accelerators
1
für die Agile Softwareentwicklung. Welchen genauen
Zweck erfüllen Accelerators und wie können diese zu einer bedeutsamen Ef-
fizienzsteigerung in Agile Softwareprojekten verhelfen? Darüber hinaus kann
sich der Softwareentwicklungsprozess im Zeitverlauf schnell als zunehmend
komplex darstellen
zur effizienteren Beherrschung werden hierbei Hilfsmit-
tel wie die Stacey Complexity Matrix herangezogen. Abschließend soll es
auch darum gehen, ob das ideale Tool-Set, bestehend aus unterschiedlichen
Accelerator-Typen, überhaupt existiert.
1.1.1 Arbeits- & Erkenntnisziel
Zum Zeitpunkt der Ausarbeitung bin ich bei
einem Beratungs- und IT-
Dienstleistungsunterhmen
als Werkstudent tätig
und betrachte speziell für
dieses Projekt eine Handvoll passender Tools im Rahmen eines agilen
Entwicklungsprojektes
2
für
Steuerangelegenheiten,
sowie
deren
Zusammenspiel. Das Ziel dieses Praxisprojektes ist die Erkenntnis darüber,
welche Acceleratoren das Agile Vorgehensmodell verbessern können und ob
es basierend darauf, eine ideale Infrastruktur von Software-Komponenten für
das Application Lifecycle Management gibt.
1
In dieser Ausarbeitung wird für alle gängigen technischen Begriffe jeweils die englische Bezeichnung
verwendet.
2
Für die laufende Ausarbeitung soll die Bezeichnu
ng ,,Projekt X" Verwendung finden.
Praxisprojekt: Accelerators für Agile Softwareentwicklung
2
In Abschnitt (2) wird einführend der Begriff Agile betrachtet und welche Impli-
kationen durch verkörperte Werte, Prinzipien und Prozesse sowie Praktiken
der Softwareentwicklung zu Mehrwerten verhelfen. Vor allem soziale und
technische Aspekte sind hier von besonderer Bedeutung, da sich hier be-
sondere Potenziale verbergen. Bevor es in Abschnitt (3) vertiefend um die
drei Accelerator-Kategorien Human, Requirements, Technology und den Be-
zug zu Agile geht, wird als Beispiel für dieses Projekt, das agile Framework
Scrum sowie der agile Prozess XP
3
betrachtet. In Abschnitt (4) wird der App-
lication Lifecycle besprochen, und die Kernfragestellung dieser Ausarbeitung
abschließend geklärt. Neben Tool-Arten wie heavy- und lightweight tools wird
auch ein exemplarisches Tool-Set aus der Praxis betrachtet.
Um dem Argumentationsleitfaden dieser Ausarbeitung Ausdruck zu verlei-
hen, wird die oben gezeigte Pfeildarstellung nach Abschluss des jeweiligen
Kapitals verwendet.
3
Extreme Programming, vgl. Wolf (2005).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
3
2. Agile & Softwareentwicklung
2.1 Definition & Begriffliche Abgrenzung
Agile (lat. Agilis, dt. Agilität
4
: flink; beweglich) bezeichnet in der gleichnami-
gen Agilen Softwareentwicklung eine übergeordnete Verhaltens- und Denk-
weise.
,,
Agile development is a philosophy. It´s a way of thinking about soft-
ware development."
5
Agilität oder Agile
6
kann im Kern auf die Charakteristi-
ken people driven, facilitation, iterative-incremental-process, measuring suc-
cess sowie change, hin, definiert werden.
7
Abb. 1: Agile characteristics
Es geht also zum einen um eine menschzentrierte Entwicklung, indem die
Fähigkeiten des einzelnen Individuums innerhalb eines Teams herausgestellt
und sein empirisches Handeln gefordert wird. Bei Agile spricht man darüber
hinaus von einem iterativ-inkrementellen-Prozess
8
, der ständigen Messbar-
keit aller eingehenden Parameter
9
und der grundsätzlichen Überzeugung,
dass Veränderung
10
ein notwendiges Gut zur stetigen Verbesserung eines
Endproduktes ist
11
. Agile versteht sich hierbei allerdings nicht als fertiges Pat-
tern zur Umsetzung von Projekten:
,,...Agile is not one fixed process, method
4
http://www.duden.de/node/651087/revisions/1338268/view.
5
Shore (2007), S.9.
6
An dieser Stelle soll für den restlichen Verlauf der Ausarbeitung der englische Begriff Verwendung fin-
den.
7
Vgl. Verheyen, S.19.
8
Ein Prozess mit aufeinanderfolgend-wiederholbaren Schritten innerhalb fester Zeitintervalle).
9
Darunter wird zusammengefasst: Anforderungen, Informationen und Wissen bezüglich des Produktes.
10
Natürliche Veränderung, die nicht aus Zwang, sondern aus sich heraus und organisch entsteht.
11
Vgl. Hüttermann (2012), S. 34.
Praxisprojekt: Accelerators für Agile Softwareentwicklung
4
or practice. It is the collection of principles that the methods for agile software
devel
opment have in common."
12
Agile ist mehr eine Sammlung von Prinzi-
pien und übergeordneten Verhaltens- und Denkweisen, die die Methoden der
agilen Softwareentwicklung gemeinsam haben. Um Agile anzuwenden muss
das Individuum allmählich Agile ,,annehmen". Es handelt sich also auf dem
Weg dorthin um einen Verhaltensprozess, den das Individuum bei der Arbeit
auf organische Weise, frei und selbstorganisiert durchläuft.
13
Das Annehmen
von ,,Ag
i
le" setzt die in der Philosophie dieses Vorgehensmodells veranke
r-
ten Werte und Prinzipien voraus. Diese werden im nächsten Abschnitt be-
schrieben. Doch woher die natürliche Evolution zu Agile? In der Geschichte
der Softwareentwicklung begann alles mit dem traditionellen Wasserfall-
Modell
14
bzw. dem industriellen Ansatz der schrittweise getrennten Entwick-
lung von Produkten. Man spricht hierbei gezielt auch vom ,,industrial par
a-
digm
15
. Wir bewegen uns für den Moment zurück in eine Zeit ab Mitte der
1950er Jahre in der die Denkweise sehr stark der taylorist conviction
16
ent-
spricht: die Arbeit wird durch eine Minderheit an befähigten Managern dele-
giert und grundsätz
lich per ,,carrots and sticks"
17
das ,,Gute" durch Belohnung
angenommen und das ,,Schlechte" durch Strafe abgelehnt. Das bedeutet,
dass das gewünschte Verhalten zur Exekution gesetzter Ziele konsequent
durchgesetzt wurde, indem Arbeitskraft gekauft und zumeist persönliche
Ideen oder Kreativität weder gewünscht noch gefragt waren. Übertragen auf
die Softwareentwicklung verfolgte der ursprüngliche Ansatz die Überzeu-
gung, dass Software nicht nur vorab planerisch vollständig durchdrungen
werden sollte, sondern alle Anforderungen vorhersehbar waren. Darüber
hinaus sollte es möglich sein, die angegebene Zeit und das Budget punktuell
zu planen und einzuhalten.
,,...software must be delivered o
n time, on budget
and with all the promised scope."
18
12
Verheyen (2013), S. 19.
13
Vgl. Smith (2009), S.5.
14
Vgl. Office of Naval Research, Dept. of the Navy (1956).
15
Vgl. Capgemini (2012).
16
"workers can´t be trusted", vgl. Verheyen (2013), S. 13.
17
dt. Entsprechung: Zuckerbrot und Peitsche.
18
Verheyen (2013), S. 17.
Praxisprojekt: Accelerators für Agile Softwareentwicklung
5
Abb. 2: The Industrial paradigm
Das vorangestellte Modell, welches auf dem industriellen Paradigma beruht,
kann als open loop system bezeichnet werden. Ein open loop system ver-
sucht vorab möglichst alle benötigten Variablen und eingehenden Parameter
im Detail zu bestimmen, ohne dabei neue oder sich ändernde Größen im
Verlauf eines Projektes zu berücksichtigen.
19
Abb. 3: Open loop system
Bedingt durch das open loop system entpuppte sich die Vorgehensweise
eher als wenig effektiv. Softwareprojekte brachten ein noch höheres Risiko-
potenzial mit sich als heute und ein Großteil aller Projekte wurde nicht voll-
ständig oder wie vertraglich abgestimmt, umgesetzt.
20
,,It was accepted that
only 10
20% of software projects would be successful."
21
Am Ende hatte
man eine Software entwickelt die seitens des Auftraggebers teilweise oder
nicht den Vorstellungen entsprach. Der niedrige qualitative Output wurde je-
doch hingenommen.
19
Vgl. ebd., S.68.
20
An dieser Stelle muss festgehalten werden, dass Softwareprojekte zur damaligen Zeit nur im Ge-
ringsten der Komplexität heutiger Projekte entsprachen.
21
Standish Group (2011).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
6
Einige Jahrzehnte später, ab Ende der 1980er
22
über die 1990er bis ins frühe
neue Jahrtausend, entwickelte sich allmählich ein neues übergeordnetes
Vorgehensmodell für die Softwareentwicklung und mit diesem, der Begriff
des ,,Agile".
Agile versteht sich in seiner inneren Philosophie als Gegenbe-
wegung zu eher traditionell unflexiblen Softwareentwicklungsprozessen wie
dem V-Modell. Beide verfolgen dabei grundsätzlich dasselbe Ziel: ein Projekt
soll erfolgreich
23
und möglichst kostengünstig umgesetzt werden. Beide Vor-
gehensmodelle folgen allerdings unterschiedlichen Vorgehensweisen und
Grundsätzen. Die Vorgehensweise des V-Modell XT sieht eine generelle Ori-
entierung am Ziel und Ergebnis vor, da hier das Produkt im Mittelpunkt steht.
Das bedeutet, dass durch das ,,Tailoring" zu Proje
ktbeginn alle zu erstellen-
den Artefakte bereits vorgegeben werden. Im Folgenden wird für das Projekt
ein Handlungsrahmen festgesetzt, der die Reihenfolge der Produkte im Hin-
blick auf die Erzeugung und Absicherung definiert.
24
Dementgegen
25
basiert
ein agiles Vorgehensmodell auf Werten und Prinzipien. Die Handlungen der
Projektbeteiligten werden durch dieses Wertesystem angeleitet; seinen Leit-
sätzen folgen auch die konkreten Praktiken.
,,...a reaction to many of the e
x-
isting project management approaches at that time that were perceived to be
overly prescriptive, bureaucratic, and not very effective[...]."
26
Statistiken be-
legen, dass agile Softwareprojekte in Folge dazu tendierten, 3 mal so häufig
erfolgreich zu verlaufen und 3 mal so selten fehlzuschlagen als traditionelle
Vorgehensmodelle.
27
Der Standish Chaos Report zeigt diesen Trend in ei-
nem Vergleich des letzten Jahrzehnts auf; Projekte, die just-in-time und mit
genau den erforderlichen Ressourcen abgeschlossen wurden, fallen unter
die Kategorie ,,Challenged". Pro
jekte die über den Erwartungen lagen und
etwa Vorarbeit leisten konnten, fallen unter die Kategorie Successful.
22
Vgl. Nonaka (1986).
23
Im Sinne qualitativ guter Software.
24
Vgl. Rausch (2007), S.13.
25
Die weitreichenden Unterschiede dieser beiden Vorgehensmodelle ähneln insofern einem Paradig-
menwechsel, wie z.B. beim Übergang von der prozeduralen Programmierung zur Objektorientierung.
26
Cobb (2015), S.15.
27
Standish Group (2011).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
7
Bei agilen Projekten wurden zunehmend Anteile des Bereiches Challenged
durch erfolgreiche Projekte eingenommen, was sich ebenso in den fehlge-
schlagenen Projekten deutlich machte. Diese waren mit kaum mehr als 10%
vertreten.
Abb. 4: Standish Chaos Report
,,Agile understands the core purpose of the "normal" IT activities, but breaks
the sequential organization of these." [...] ,,In agile all discip
lines are per-
formed in a non-linear, incremental way, in parallel and on a daily basis, by
cross-skilled teams with continuous collaboration and negotiation over emer-
gent ideas, techniques and practices."
28
Agile Softwareentwicklung fokussiert essenziell das zu erreichende Ziel und
bemüht sich darum, den Softwareentwicklungsprozess im Vergleich zu klas-
sischen Vorgehensmodellen beherrschbar und in der Konsequenz, sicherer
zu machen. Auf diese Weise können geordnet fachliche, technische und so-
ziale Probleme während der Entwicklung behandelt werden. Eine der Beson-
derheiten von Agile liegt darin begründet, dass Fehler und das Eingestehen
dieser notwendig ist um Fortschritte bei der Entwicklung zu verzeichnen. Das
Lernen aus Fehlern und der Mut zu Neuem stehen hierbei an erster Stelle
29
.
Diese Besonderheit wird allgemein mit Kontinuität und spezifisch dem Begriff
Continuous Improvement
30
, der kontinuierlichen Verbesserung, beschrieben.
,,Je mehr du nach Plan arbeitest, desto mehr bekommst du das, was du g
e-
plant hast
, aber nicht das, was du brauchst."
31
Die Erwartung zielt also expli-
28
Verheyen (2013), S.24.
29
,,Fehlerkultur", vgl. CIO.de (2014).
30
Es herrschen hier enge Verbindungen zum Vorgehensmodell Lean und spezifisch dem Konzept:
,,reduce waste", vgl. MacInnes (2002).
31
Agiler Leitsatz, Wolf (2011).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
8
zit darauf ab, dass sich während eines Projektes Änderungen an Anforde-
rungen, Markt, Konkurrenz oder technischen Aspekten ergeben können.
Nicht zu vernachlässigen und von besonderer Relevanz ist hierbei auch der
Mensch, der als Hauptakteur und Risikofaktor zugleich einen hohen Stelle-
wert einnimmt. Übergeordnet dienen die genannten Aspekte der Schaffung
von qualitativ hochwertiger Software, und nachgelagert etwa der besseren
Beherrschung von Prozessen sowie deren Sicherheit.
2.1.1 Agile Fundamentals
Im vorherigen Abschnitt wurde ein erster Einblick zu Agile gegeben; doch
worauf basiert Agile und was sind die Inhalte? Das Fundament von Agile sind
die agilen Werte, denen durch entsprechende Prinzipien Ausdruck verliehen
wird. Agile Prozesse und Praktiken sind hingegen konkrete Anwendungen
auf die Softwareentwicklung. Agile Prozesse bestehen in der Regel aus agi-
len Praktiken und/oder agilen Methoden.
32
Die agilen Werte Kommunikation, Einfachheit, Feedback, Mut und Respekt
bilden das moralische Fundament des Agilen Manifest
33
. Man kann diese gut
mit den Ansprüchen der Werte unserer Gesellschaft vergleichen; so wird al-
len Beteiligten während des Entwicklungsprozess derselbe Anspruch morali-
schen Handelns abverlangt wie dem Umgang mit Mitbürgerinnen.
Nachfolgend ein Überblick des vollständigen agilen Wertesystems:
34
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
32
Vgl. Smith (2009), S.329 f.
33
Vgl. AgileManifesto.org (2001).
34
Enzyklopaedie-der-wirtschaftsinformatik.de (Agile Vorgehensmodelle).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
9
Die agilen Werte bilden das Fundament für agile Prinzipien. Diese Prinzipien
dienen als Handlungsgrundsatz für die agile Arbeit
35
:
Die frühe und kontinuierliche Auslieferung von wertvoller Software zu-
gunsten der Zufriedenstellung des Kunden
Gezielte Nutzung von Veränderungen bei agilen Prozessen zum
Wettbewerbsvorteil des Kunden
Lieferung von funktionierender Software in regelmäßigen, bevorzugt
kurzen Zeitspannen (wenige Wochen oder Monate)
Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern
während des Projektes (Bsp.: Gemeinsamer Code-Besitz)
Bereitstellung des Umfeldes und der Unterstützung, welche von moti-
vierten Individuen für die Aufgabenerfüllung benötigt wird
Informationsübertragung nach Möglichkeit im Gespräch von Angesicht
zu Angesicht
Als wichtigstes Forschrittsmaß gilt die Funktionsfähigkeit der Software
Einhalten eines gleichmäßigen Arbeitstempos von Auftraggebern,
Entwicklern und Benutzern für eine nachhaltige Entwicklung
Ständiges Augenmerk auf technische Exzellenz und gutes Design
Einfachheit ist essenziell
Selbstorganisation der Teams bei Planung und Umsetzung
Selbstreflexion der Teams über das eigene Verhalten zur Anpassung
im Hinblick auf Effizienzsteigerung
Prinzipien werden in der agilen Softwareentwicklung dazu genutzt, um die
Werte richtig zu steuern; als konkretes Beispiel könnte man den Wert ,,Ko
m-
munikation" nennen: ohne ein zugrundeliegendes Prinzip, könnte man r
e-
gelmäßig ohne ein übergeordnetes Ziel mehrstündige Meetings abhalten,
einzig um diesen Wert zu würdigen. Da dies aber nicht die Intention der Mo-
delle ist, führen die meisten Modelle Prinzipien ein, um diese klarer zu defi-
nieren. Die Prinzipien bilden den fließenden Übergang zwischen den Werten
und den Praktiken.
35
Vgl. AgileManifesto.org/principles (2001).
Praxisprojekt: Accelerators für Agile Softwareentwicklung
10
Eine agile Praktik bezeichnet eine an Agile ausgerichtete Handlung innerhalb
der Softwareentwicklung. Konkret sind Praktiken Arbeitsschritte, die täglich
vom Projektteam angewandt werden. Ohne entsprechende Werte könnte ei-
ne Praktik z.B. zu einem unnötigen Zwang verkommen und die ursprüngliche
Intention verfehlen. In der Folge sind Werte und Prinzipien dazu dienlich, um
agile Praktiken anzuwenden, damit im Hinblick auf das Agile Vorgehensmo-
dell das Projektziel erreicht werden kann.
Beispiele für Praktiken:
Paarprogrammierung
36
Kurze Iterationen
Ständige Refaktorierungen
Automatisierter Build-Prozess
Agiles Schätzen
Agile Methoden sind ganzheitliche Vorgehensweisen die sich während der
Softwareentwicklung, konkret auf die Werte und Prinzipien stützen.
37
Um
Verwechslungen zu vermeiden, soll zur Unterscheidung gegenüber agilen
Praktiken an dieser Stelle das Beispiel RUP
38
genannt werden. Es lässt sich
grundsätzlich festhalten, dass agile Methoden gegenüber den Praktiken ei-
nen eher ganzheitlicheren Bezug besitzen. Methoden sind eine geschlosse-
ne Sammlung von einzelnen Handlungen.
39
Ein agiler Prozess ist die Zusammenfassung aller angewandten Praktiken
bzw. Methoden. Agilen Prozessen liegt das Bestreben zu Grunde, schnell
und effektiv zu ausführbarer Software zu gelangen die dann, in regelmäßigen
und kurzen Abständen, dem Kunden zur gemeinsamen Abstimmung geliefert
wird. Der Vorteil der hierbei resultiert ist die flexible Reaktion auf Kunden-
wünsche einzugehen, die insgesamt die Kundenzufriedenheit erhöht.
Dieses Vorgehen wird bei Agile einerseits durch den generellen Abbau von
Bürokratie und die Reduzierung der reinen Entwurfsphase auf ein Mindest-
36
Programmieren in Paaren meint, dass zum Programmieren ständig zwei Entwickler vor einem Ent-
wicklungsrechner sitzen und gemeinsam arbeiten.
37
Vgl. Innovation-hat-methode.de (Industrie- und Handelskammer).
38
Rational Unified Process: ein Vorgehensmodell mit dazugehörigen Programmen zur Entwicklung.
39
Vgl. It-agile.de.
Praxisprojekt: Accelerators für Agile Softwareentwicklung
11
maß erreicht. Im Gegensatz werden menschliche Aspekte, vor allem die der
Interaktion, stärker berücksichtigt. Beispiele für Agile Prozesse gibt es viele,
jedoch soll hier exemplarisch XP in Bezug zum Rahmenwerk und defacto
Standard Scrum besondere Beachtung finden.
40
2.1.2 Scrum XP
Im nächsten Schritt wird zunächst das agile Framework Scrum und getrennt
davon, XP, behandelt. Anschließend soll das Zusammenspiel der beiden be-
trachtet werden. Die Wahl zur Vorstellung von Scrum innerhalb dieser Aus-
arbeitung liegt in der optimalen Umsetzung der Regeln des Agilen Manifest
begründet und kann darüber hinaus in der Praxis als defacto-Standard
(81,5% Verwendung unter agile und zumindest Teilnutzung 72%) bezeichnet
werden.
41
Scrum wird bewusst als Rahmenwerk (Framework) betitelt und
nimmt Abstand zur Definition als Vorgehensmodell, da der Umfang sich aus-
schließlich auf das Wesentliche bezieht. Man kann sich ein Rahmenwerk in
dieser Hinsicht also als Schablone vorstellen, die aus dem Notwendigsten
zusammengesetzt und in Folge durch die persönlichen Erfordernisse ange-
reichert wird. Scrum selbst stellt keine Praktiken zur Umsetzung vor, sondern
dient zwangsläufig nur dazu, einen äußeren Rahmen zu schaffen, damit ver-
schiedene Praktiken eingesetzt werden können. Dieser Rahmen besteht
hauptsächlich aus den roles, rules principles sowie artefacts.
42
Die be-
schriebenen Aspekte von Scrum werden durch das Scrum Gameboard in
Abbildung 6 visuell dargestellt um die besonderen Aspekte dieses Rahmen-
werkes zu verdeutlichen. In der Theorie wird häufig auch eine Auslegung als
Prozess aufgegriffen, die jedoch problematisch ist: es soll ein Unterschied
gezogen werden, ob die Definition als Prozess sich deutlich auf einen
,,servant
-
process"
43
bezieht oder auf einen ,,commanding
-
process"
44
. Ein Pro-
zess als solcher wird als feste Abfolge von Schritten definiert und dieser Aus-
legung folgt Scrum in seiner Funktionalität nunmehr nicht.
40
Vgl. Cobb (2015), S. 5.
41
Forrester Research (2012), S.15; VersionOne (2013), S.5.
42
Vgl. Wolf (2005), S.133.
43
Keine feste Abfolge von Schritten, sondern ein unterstützender Prozess, der Verbesserungen unter-
liegt.
44
Ein Prozess als feste Abfolge von wohldefinierten statischen Schritten.