Agile Entwicklung Web-basierter Systeme; Agile software development;

1 EinleitungBei einer im Dezember 2001 durchgefuhr-ten Umfrage des Cutter IT Consortium (einZusammenschluss amerikanischer IT-Bera-ter) unter 200 Unternehmen mit jeweilsmindestens 25Mitarbeitern in der Entwick-lung von Software außerten 48% der be-fragten Unternehmen die Absicht, bis zumJahr 2003 in mindestens einem Entwick-lungsprojekt fur Web-basierte Informati-onssysteme agile Verfahren einzusetzen[Cutt01]. Zumindest in der Industrie ist agi-le Entwicklung – so eine sprachliche Kurz-form unter Praktikern – damit zu einemwichtigen Thema geworden. Die Diskus-sion ist derzeit kontrovers: Von den einenals die Ruckkehr undisziplinierten Hackensund Ruckfall in die Zeiten vor dem Soft-ware Engineering verteufelt, versuchen an-dere, die Verfahren als endgultige Losungaller IT-Probleme zu verkaufen. Beidestrifft nicht den Kern der Sache. Ebenfalls indieser Umfrage ergab sich im Schnitt einehohere Kundenzufriedenheit beim Einsatzagiler Entwicklung: 77% der Kunden agilerProjekte waren mit dem Ergebnis zumin-dest „eher zufrieden“, verglichen mit nur63% bei traditionell arbeitenden Teams. ImUmkehrschluss bedeutet dies aber auch,dass immerhin noch 23% der Kunden agilarbeitender Teams zumindest eher unzu-frieden waren.

Web-basierte Systeme, also Software, die esermoglicht, Geschaftsvorfalle uber dasWorld Wide Web abzuwickeln, zeichnensich durch eine hohe Volatilitat aus. Soschreibt Jim Highsmith: „The new econo-my is not about the Internet, although theInternet certainly qualifies as a key driver,

the new economy is about change – boththe acceleration of change and the emer-gence of multiple types of change“[High02]. Dadurch dass das WWW selbstfur Privatanwender weltweite Vergleich-barkeit einfach ermoglicht, fuhren neueGeschaftsideen sehr schnell zu einem er-heblichen Konkurrenzdruck auf Mit-bewerber. Um diesen sich schnell bewegen-den fachlichen Anforderungen gerecht zuwerden, wird es immer wichtiger, sich zu-mindest mit dem Thema agile Entwicklungauseinanderzusetzen.

Agile Verfahren wurden im Laufe der letz-ten funf bis zehn Jahre in der industriellenPraxis entwickelt und fruher mit dem miss-verstandlichen Begriff „leichte Prozesse“bezeichnet. Diese Verfahren konnen mitt-lerweile eine Reihe von Referenzprojektenaufweisen. Sie versuchen, durch eine neueHerangehensweise an das Managementvon Softwareprojekten auf neue Heraus-forderungen wie die hohe Bedeutung desTime-to-market und gestiegene Volatilitatder Anforderungen zu reagieren. Nebender scharfen Wettbewerbssituation schlagthier auch zu Buche, dass in Web-basiertenAnwendungen neue Geschaftsmodelle aus-probiert werden, die oft erst im Projektver-lauf detailliert werden konnen, weil es zuProjektbeginn keine Erfahrungen mit demModell gab. Techniken, wie die 1-Click-Bestellung von amazon.com oder derenpersonalisierte Einkaufsvorschlage sindnicht auf dem Reißbrett entstanden, son-dern wurden aus der Analyse von Naviga-tionspfaden und Kundenverhalten ent-wickelt und verbessert [RoLS00].

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 237–248

Der Autor

Jens Coldewey

Jens Coldewey,Coldewey Consulting,Curd-Jurgens-Str. 4,D-81739 Munchen,E-Mail: [email protected],http://www.coldewey.com

Agile EntwicklungWeb-basierter SystemeEinfuhrung und �berblick

WI – Schwerpunktaufsatz

Weil Agile Verfahren erst seit wenigen Jah-ren praktisch eingesetzt werden, hat bishernur wenig akademische Forschung zu demThema stattgefunden. Daher kann die Ar-gumentation leider nicht immer mit derwunschenswerten wissenschaftlichen Me-thodik gefuhrt werden. Aufgrund der zu-nehmenden wirtschaftlichen Bedeutungagiler Verfahren scheint es aber dennochberechtigt, bereits jetzt daruber zu publi-zieren – auch in der Hoffnung, dadurchfur eine intensivere wissenschaftliche Un-tersuchung zu werben. Gewarnt werdenmuss jedoch vor einem vorschnellen undnaiven Einsatz agiler Verfahren. Wenn Pro-jektmanagement, Kundenmanagement, Ar-chitektur und Design nicht konsequent aufagile Entwicklung ausgerichtet sind,kommt es immer wieder zu Problemen inden Projekten. Wie mit jedem anderen me-thodischen Ansatz ist eine intensive Be-schaftigung mit dem Thema notwendigeVoraussetzung fur eine erfolgreiche Um-setzung.

Der Beitrag gliedert sich in drei Teile: Ab-schnitt 2 zeichnet die Herausforderungenbei der Entwicklung Web-basierter Syste-me nach und verdeutlicht die Schwachender traditionellen Entwicklungsprozesse.Es folgt in Abschnitt 3 eine kurze Abhand-lung der Grundlagen agiler Entwicklungs-prozesse (Lernende Organisationen undEmergenz). In Abschnitt 4 werden danndrei Verfahren der agilen Entwicklung be-schrieben (Adaptive Software Develop-ment, Chrystal-Methodenfamilie und Ex-treme Programming) und in eine grobeTaxonomie eingeordnet.

2 Das Problem –Herausforderungenbei der EntwicklungWeb-basierter Systeme

Mit dem rasanten technischen Fortschrittist schleichend auch ein grundsatzlicherWandel der Rolle einhergegangen, welchedie IT im betriebswirtschaftlichen Gefugeeines Unternehmens spielt. Bis in die fru-hen neunziger Jahre hinein sollte IT primarKosten einsparen und lastige Routinearbei-ten abnehmen. Konsequenterweise wurdendaher in einem typischen IT-Projekt zu-nachst die bestehenden Ablaufe im Unter-nehmen analysiert, modelliert und dann einunterstutzendes EDV-System konzipiert.Die Unternehmen sahen sich damit in der

Lage, geschaftliche Aufgaben schneller undmit geringerem Ressourceneinsatz zu bear-beiten. Dadurch konnten die Unternehmeneinen Kostenvorteil gegenuber ihren nochnicht umgestellten Wettbewerbern errei-chen und haufig auch einen Qualitatsvor-teil. Zunachst waren die entstehenden Sys-teme aber so teuer und unflexibel, dassgeschaftliche Ablaufe haufig genug von derEDV diktiert wurden, statt im Sinne derUnternehmensstrategie optimal ausgerich-tet zu sein.

In den neunziger Jahren hatte die Technikeinen Stand erreicht, der nicht nur die Fle-xibilitat vergroßerte, sondern auf einmalvollig neue Geschaftsstrategien ermoglich-te. Das bekannteste Beispiel fur solcheFortschritte ist das World Wide Web, dasinnerhalb weniger Jahre das Internet ausseiner Nischenposition fur Universitatenund Spezialisten hinaus katapultierte, wo esmehr als zwanzig Jahre friedlich zugebrachthatte, und zu einem omniprasenten Mas-senmedium machte. Aber auch andereTechnologien, wie Objektorientierung oderEntwurfsmuster [GHJV94], ermoglichtenflexiblere und leistungsfahigere Software,die es Unternehmen erlaubte, mit leistungs-fahigeren Systemen vollig neue Marktstra-tegien umzusetzen.

Fur die Verfahren zur Softwareproduktionhatte dies einschneidende Konsequenzen:Statt wie bisher existierende Geschaftspro-zesse analysieren und nachbilden zu kon-nen, muss Software fur Ablaufe gebautwerden, die hochstens schematisch bekanntsind. Die Geschaftsprozesse entstehenmeist erst parallel mit der Software undmussen entsprechend im laufenden Betriebgeandert werden. Um noch offene Markt-nischen besetzen zu konnen, muss flexibelauf neue Anforderungen oder Entwicklun-gen am Markt reagiert werden. Der Beginndes Projektes ist die strategische Geschafts-idee, nicht die detailliert ausgearbeitete An-forderungsliste. Der Weg zur Implementie-rung der Geschaftsidee ist meist nochunklar und wird erst im Laufe des Projektserschlossen. Das „Moving target“, bishervom Projektmanagement unbedingt zuvermeiden, ist zumindest bei Web-basier-ten Anwendungen zum strategischen Vor-teil geworden. Wer mit sich andernden An-forderungen umgehen kann, eroffnet sichmoglicherweise die Gelegenheit, offeneMarktnischen zu besetzen. Wer daraufwartet, dass sich Anforderungen stabilisie-ren, der wartet haufig, bis die Mitbewerberdas neue Terrain besetzt haben und ver-

passt moglicherweise erhebliche Chancen.In dieser Umgebung bringt es Vorteile,wenn die Softwareentwicklung in der Lageist, sich mit dem beweglichen Ziel mit-bewegen zu konnen und nicht vergeblichversucht, das Ziel anzuhalten, wenn esnicht in ihrer Macht steht.

Anhanger agiler Entwicklung argumentie-ren nun, traditionelle Entwicklungsprozes-se hatten grundsatzliche Probleme, mit sol-chen „Moving targets“ umzugehen. DieseAussage ist so provokant, dass sie eine ge-nauere Diskussion verdient. Die folgendenAbschnitte beschreiben daher zunachst dieVorgehensweise in traditionellen Entwick-lungsprozessen, um anschließend aus ei-nem systemanalytischen Blickwinkel diedort inharenten strukturellen Probleme derAufwandskontrolle herauszuarbeiten.

2.1 Vorgehensweisebei traditionellenEntwicklungsprozessen

Traditionelle Entwicklungsprozesse wiedas V-Modell [BrDr95; DHMi98] oder derRational Unified Process (RUP) [JBRu99;Kruc00] basieren auf dem Bestreben, dieSoftwareentwicklung anderen Ingenieurs-disziplinen moglichst ahnlich zu gestalten.Der Begriff des Software-Engineering gehtauf die gleichnamige Garmischer NATO-Konferenz von 1968 zuruck [NaRa69]. Alsquantitative Argumentationsgrundlage die-nen heute aber meist die Untersuchungenzur �nderbarkeit großer Softwaresysteme,die Barry Boehm in den spaten siebzigerJahren durchgefuhrt hat [Boeh81]. Er hatteherausgefunden, dass die Kosten fur �nde-rungen an Softwaresystemen annahrendexponentiell mit der Zeit wachsen, die biszum Erkennen des Problems vergeht1 (vgl.Bild 1). Um diese Kosten moglichst geringzu halten, sollen ausgedehnte Analysepha-sen und detailliertes Design helfen, Fehlergar nicht erst in den Code kommen zu las-sen. So schrieb Boehm 1996:

„I can’t overemphasize how critical theLife Cycle Architecture milestone is toyour project and your career. If you ha-ven’t satisfied the LCA milestone criteria,do not proceed into full-scale development.Reconvene the stakeholders and work outa new project plan that will successfullyachieve the LCA criteria“ ([Boeh96] zitiertnach [JBRu99]).


238 Jens Coldewey

Schon hier fallt der Konflikt mit den ein-gangs diskutierten Veranderungen der IT-Welt auf. Zwar ist es naheliegend, dass dieKenntnis aller Anforderungen und diegrundliche Ausarbeitung der technischenArchitektur spatere �nderungen erspart.Eine vier- oder sechsmonatige Start- undEvaluierungsphase kann aber heute dazufuhren, dass das Projekt scheitert, weil dieKonkurrenz mittlerweile die Marktnischebesetzen kann. Auch ist das Warten auf sta-bile Anforderungen keine Option, wennerst das lauffahige Softwaresystem dieMoglichkeit schafft, diese Anforderungenauch zu entdecken. Die Softwareentwick-lung hat sich seit Boehms Untersuchungenin den siebziger Jahren so verandert, dassdie damaligen Ergebnisse heute nicht mehrunbedingt gelten mussen.

2.2 Ein systemanalytischer Blick-winkel zur Herausarbeitungder strukturellen Problemebei der Aufwandskontrolle

Bei der mangelnden Flexibilitat handelt essich nicht um leicht zu behebende Luckenin den traditionellen Prozessen, sondernum ein strukturelles Problem in deren An-satz zur Aufwandskontrolle. Um dasstrukturelle Problem zu erkennen, hilft ei-ne systemanalytische Diskussion der Mit-tel, mit denen traditionelle Prozesse ver-suchen, das exponentielle Wachstum derFehlerkosten zu bekampfen. Eine ausfuhr-liche Beschreibung der Systemanalyse wur-de hier den Rahmen sprengen. Interessierteseien auf Peter Senges Arbeiten verwiesen[Seng90].

Bei der Softwareentwicklung mussen un-prazise Anforderungen in einer Analyseprazisiert werden, die sowohl betriebswirt-schaftliche als auch technische und ergono-mische Aspekte berucksichtigt, damit sie inprazise Anweisungen an die Maschine um-gesetzt werden konnen. Hier bestehen vie-le Freiheitsgrade, die in einem kreativenProzess ausgefullt werden. Dieser Vorgangist daher einer Automatisierung grundsatz-lich nicht zuganglich, er ist auf menschlicheKreativitat und Intuition angewiesen. Da-bei schleichen sich immer auch Fehler ein,sei es aufgrund von Missverstandnissen,aufgrund von Kommunikationsluckenoder weil Beteiligte die Konsequenzen ih-rer Entscheidungen nicht vollstandig uber-blicken. Alle drei Fehlerquellen konnenangesichts der enormen Komplexitat, die

moderne Softwaresysteme aufweisen, nichtvermieden werden.

Andererseits gehen traditionelle Prozessedavon aus, dass die Kosten von Fehlern ex-ponentiell mit der Zeitspanne bis zu ihrerEntdeckung steigen und Fehler daher mog-lichst fruh gefunden oder sogar vollig ver-mieden werden sollten. Dafur werden vorallem zwei „Werkzeuge“ eingesetzt: Doku-mentation und Redundanz.

Dokumentation wird sowohl in Form nor-maler Dokumente wie im V-Modell alsauch mit Hilfe von grafischen Modellen inspeziellen Verwaltungswerkzeugen wie imRUP eingesetzt. Sie hat zum Ziel, einzelneAspekte des geplanten Systems aufzuberei-ten, sodass diese zunachst vom Autor aufVollstandigkeit gepruft und dann von an-deren Mitgliedern des Teams begutachtetwerden konnen. Wird die Dokumentationdaruber hinaus mit dem entstehenden Sys-


Kernpunkte fur das Management

Agile Verfahren wie „Crystal“ oder „Extreme Programming“ werden derzeit intensiv dis-kutiert. Sie bieten vor allem dann Alternativen zu traditionellen Prozessen, wenn schnelleReaktionsfahigkeit gefordert ist oder sich die Anforderungen erst wahrend der Entwicklungergeben, typische Anforderungen bei Web-basierter Entwicklung:

& Das Projekt kann uber die ganze Laufzeit schneller auf veranderte Anforderungen reagie-ren, sowohl bei kleineren �nderungen, also auch bei grundsatzlicher Neuoerientierung.

& Lauffahige Resultate liegen wesentlich fruher vor.& Dafur sind langfristige Planbarkeit und Vergleichbarkeit schwieriger.

Stichworte: Softwareentwicklungsprozesse, agile Softwareentwicklung, Time-to-market,Extreme Programming, Crystal-Methodenfamilie, Adaptive Software Development

1

10

100

1000

Anfor

deru

ngen

Design

Code

Entwic

kler

test

Abnah

met

est

Betrie

b

Rela

tive

Koste

nein

er

Änderu

ng

IBM-SSD

GTE

TRW

SAFEGUARD

Trendlinie

Bild 1 Die Kosten fur �nderungen an Software in Abhangigkeit von der Entwick-lungsphase nach [Boeh81]. Dargestellt sind die relativen Kosten einer �nderung derSoftware aus vier großen Projekten sowie eine exponentielle Approximation der Daten.

Agile Entwicklung Web-basierter Systeme 239

tem konsistent gehalten, so kann sie spaterauch zur Unterstutzung der Wartung die-nen oder zur Erlangung von Sicherheits-zertifikaten. Dokumentation ist alsogrundsatzlich geeignet, Fehler bereits fruh-zeitig zu vermeiden und damit die Ent-wicklungskosten zu senken.

Redundanz ermoglicht es, Fehler nicht nurbei der Begutachtung durch Kolleginnenoder Kollegen aufzudecken, sondern auchbei maschinellen �berprufungen zu finden.Ein Beispiel fur solche Redundanz ist dasTypsystem der meisten Programmierspra-chen, das Konsistenzprufungen zwischenDeklarationen und ihren Verwendungenerlaubt.

Allerdings konnen diese Werkzeuge nichtnach Belieben ausgereizt werden, weil sienicht frei von Nebenwirkungen sind. Beigenauerer Betrachtung tragen sie imGegen-teil sogar zu den hohen Fehlerkosten bei.Boehm schreibt: „If the . . . error is not cor-rected until the maintenance phase, the cor-rection involves a much larger inventory ofspecifications, code, user and maintenancemanuals, and training material“ [Boeh81].

Eindrucksvoll sind auch die Kosten fur einekonsequente Umsetzung traditioneller Feh-lervermeidung, wie sie in der Raumfahrtverwendet wird: Die hochstens mittelgroßeSteuerungssoftware (420000 Zeilen Code)der Triebwerke des Space Shuttle kosteteetwa US $ 1.700 pro Zeile Code [Fish96].Solche Kosten sind fur die haufig deutlichgroßeren betriebswirtschaftlichen Systeme,wie sie Web-basierte-Anwendungen meistdarstellen, unrentabel.

Aber selbst derartig aufwandige Verfahrengarantieren noch immer keine Fehlerfrei-heit, wie spektakulare Fehlschlage in Berei-chen wie der Raumfahrt zeigen. So konntesowohl die Explosion der Ariane 5 auf ih-rem Jungfernflug als auch das Scheitern derMars Climate Orbiter Mission auf Soft-warefehler zuruckgefuhrt werden – auchwenn sich durchaus einwenden ließe, dassbeide Fehlschlage durch entsprechend aus-gelegte Tests hatten vermieden werdenkonnen [Lion95; Step99].

Auch bei der �nderbarkeit von Softwarewirken die Werkzeuge Dokumentationund Redundanz eher kontraproduktiv.Zwar vereinfacht konsistente und ausfuhr-liche Dokumentation das Auffinden vonStellen, die zu andern sind. Da jede �nde-rung aber Auswirkungen an mehreren Stel-

len nach sich zieht, manchmal sogar anmehreren hundert Stellen, wird sie entspre-chend aufwandig. Zudem ist konsistenteDokumentation in der Praxis so selten, dasssichWartungsprogrammierer ublicherweisenur auf den Code selbst verlassen [Cock02].

Erschwerend kommt hinzu, dass diese ne-gativen Auswirkungen von Redundanzund Dokumentation zeitverzogert auftre-ten, namlich erst, wenn die ersten �nde-rungen am Code anfallen. Verwendet manein traditionelles Vorgehen, so startet dieCodierung erst relativ spat im Projektver-lauf, weil Fehler bis dahin moglichst voll-standig entdeckt werden sollen. Selbst beiden iterativen Vorgehensweisen wie demV-Modell 97 [DHMi98] oder dem RUP[Kruc00] entstehen bei großeren ProjektenVorlaufzeiten von sechs Monaten odermehr. So empfahl mir Phillippe Kruchtenin einem personlichen Gesprach fur denRUP einen Vorlauf („Elaboration Phase“)von 10% der Gesamtlaufzeit eines Pro-jekts, also bei einem Projekt, das auf vierJahre angelegt ist, alleine etwa funf MonateVorlaufzeit.

Wenn die Inkrementlange, also die Zeitzwischen zwei Auslieferungen lauffahigenCodes, drei Monate betragt, bedeutet dieseRegel, dass die erste Auslieferung lauffahi-gen Codes nach acht Monaten erfolgt. Bisdie Anwender diese Auslieferung ausrei-chend ausprobiert haben, um �nderungs-wunsche formulieren zu konnen, vergehtnochmals ein Monat. Fruhestens hier, alsoneun Monate, nachdem der Grundstein desProjektes gelegt wurde, konnen also Prob-leme mit der �nderbarkeit offensichtlichwerden, haufig sogar erst sehr viel spater.Lange zeitliche Verzogerungen zwischenEntscheidungen und deren Auswirkungenfuhren aber dazu, dass ihren negativenKonsequenzen kaum mehr entgegen-gesteuert werden kann. Zudem nimmt manzeitlich stark verzogerte Auswirkungenhaufig gar nicht mehr in Verbindung mitihrer Ursache wahr.

Der Einsatz von Dokumentation und Fehl-erbehebung hat also zwei Konsequenzen,eine kurzfristig erkennbare positive Aus-wirkung und eine langfristig wirkende ne-gative Folge. In der Systemtheorie bezeich-net man ein solches Muster als „Shiftingthe burden“ [Seng90]: Die Burde der Prob-lemlosung wird von der erst langfristigwirksamen ursachlichen Strategie, die Soft-ware anderungsfreundlicher zu machen,verschoben auf die offensichtliche und

kurzfristiger wirksame Ersatzstrategie:Fehler und damit �nderungen vermeiden.

Nun beziehen sich die Kosten von �nde-rungen ja nicht nur auf Fehler, die sich zugewissen Teilen durch Werkzeuge des Soft-ware Engineering vermeiden lassen. �n-derungen sind gerade bei Web-basiertenSystemen haufig auch Folge eines betriebs-wirtschaftlichen und technischen Lern-prozesses. Traditionelle Vorgehensansatzeverlagern solche �nderungen in die War-tungsphase, die von den meisten Prozessenaber nur ungenugend abgedeckt wird. Da-gegen entstehen wiederum nach Boehm50% bis 75% der Gesamtkosten einesSoftwaresystems uberhaupt erst in derWartung [Boeh81]. Gerade wenn ein Sys-tem fachliches Neuland betritt, mussen hin-gegen schon moglichst fruh im praktischenEinsatz Erfahrungen gesammelt werden,und die betriebswirtschaftliche Strategiemuss anhand dieser Erfahrungen angepasstwerden. �nderungen sind in diesem Kon-text nicht Zeichen schlechten Projektmana-gements, sondern inharenter Bestandteilder Marktstrategie. Traditionelle Prozesseleisten hier zu wenig Unterstutzung.

Naturlich musste diese Darstellung die rea-len Verhaltnisse grob vereinfachen. In derPraxis sind die Zusammenhange wesentlichkomplexer. So musste auch der Aufwandberucksichtigt werden, der zur Erstellungder Dokumentation erbracht werden mussund dieser verglichen werden mit demNutzen durch vermiedene Fehler. DemAutor sind aber keine Untersuchungen imindustriellen Projektumfeld bekannt, diediese Fragen quantitativ oder auch nurqualitativ beantworten wurden. Dies konn-te zum Teil auch an dem hohen Aufwandliegen, den ein solches Experiment erfor-dern wurde, mussten doch im Idealfall ge-eignete Projekte mit einem Kostenaufwandjeweils im zweistelligen Millionenbereichmehrfach mit verschiedenen Strategiendurchgefuhrt werden. Entsprechend ange-legte Forschungsprojekte in Kollaborationzwischen Universitaten und der Industriewaren wunschenswert.

3 Grundlagenagiler Entwicklung

Agile Softwareentwicklung verwendet hiereine andere Strategie: Statt Fehler und da-mit �nderungen zu vermeiden, wird dieEntwicklung konsequent daran ausgerich-


240 Jens Coldewey

tet, �nderungen so einfach wie moglich zuhalten [Beck00]. Das erfordert nicht nurden Einsatz bestimmter Techniken beimDesign und Test von Systemen, sondern ei-ne andere Ausrichtung des gesamten Pro-jekts im Kunden-, Risiko- und Anforde-rungsmanagement sowie mit Blick auf dieRolle des Teams. Dabei werden Erkennt-nisse aus der Organisationsforschung undaus den Forschungen an komplexen Syste-men eingesetzt. Es ist daher sinnvoll, furdie agile Entwicklung relevante Aspekteaus beiden Gebieten kurz vorzustellen. Fureine detaillierte Beschreibung sei auf dieangegebene Literatur verwiesen.

3.1 Lernende Organisationen

Der Begriff der lernenden Organisationwurde in den achtziger Jahren gepragt undinsbesondere durch die Arbeiten von PeterSenge einem breiteren Kreis bekannt[Seng90; SKRR94; SKRR99]. Ziel ist es,große Organisationen an den sich immerschneller andernden Anforderungen desMarktes auszurichten. Dafur wird eineAbkehr von klassischem Kommando-Kontroll-Management hin zu einer ko-operativen Fuhrungsstruktur gefordert.Regelmaßige Reflexionsworkshops auf al-len Ebenen ermoglichen es, Schwachstellenfruhzeitig ausfindig zu machen und schnellauf sich andernde Anforderungen zu rea-gieren. Im Rahmen dieser Veranstaltungenwerden die Probleme analysiert und Lo-sungen beschlossen, deren Wirkung dannbeim nachsten Workshop uberpruft wird.

In Anlehnungen an diese �berlegungen se-hen alle agilen Verfahren regelmaßige Feed-backrunden vor, in denen das Team denbisher eingesetzten Entwicklungsprozessreflektiert, Verbesserungspotential suchtund Anpassungen des Softwareentwick-lungsprozesses diskutiert. Die konkreteVorgehensweise wird damit von den ein-zelnen Teams aufgrund der Erfahrungen indem individuellen Projekt gestaltet undnicht als organisationsweites Werkzeug ge-pflegt [High02]. Es wird Abstand genom-men von der Vorstellung eines einheitli-chen, wiederholbaren Prozesses fur dieganze Organisation, wie sie z. B. das „Cap-ability Maturity Model“ des SoftwareEngineering Institute als Ziel propagiert[Capu98]. Dass dadurch die Vergleichbar-keit von Projekten untereinander leidet,wird bewusst in Kauf genommen. Ebensomussen neue Teammitglieder zunachst

auch in die Vorgehensweise eingearbeitetwerden. Dies stellt jedoch in der Praxismeist keinen Nachteil dar, da agile Vor-gehensweisen stark auf Kollaboration set-zen und daher Einarbeitung durch Zusam-menarbeit stattfindet und nicht durchStudium von Dokumentation oder Pro-zessbeschreibungen. Ob der Anspruch agi-ler Verfahren berechtigt ist, durch hohereMotivation die Fluktuation zu senken unddamit die Notwendigkeit von Einarbeitungzu vermindern, werden die nachsten Jahreerweisen.

3.2 Komplexe Systemeund Emergenz

Beschreibungen agiler Vorgehensweisenscheinen zunachst sehr unvollstandig zusein, vergleicht man sie mit traditionellenVerfahren, die oft mehrere hundert bis tau-send Seiten Beschreibung umfassen. AgileVerfahren versuchen nicht, vollstandigeProzessbeschreibungen zu liefern, sondernbieten eher einen Rahmen, der dem Teamermoglicht, den eigenen Prozess zu finden.Sie berufen sich dabei auf Emergenz2, ei-nem Phanomen aus der Komplexitatsfor-schung, zu dessen umfassender DiskussionInteressierte auf die formalen Ausarbeitun-gen von Holland [Holl95] oder Coveneyund Highfield [CoHi95] verwiesen seienoder auf eine ebenfalls von Holland ver-fasste popularwissenschaftliche Darstellung[Holl98].

Holland zeigt, dass bei Systemen, die ein-fachen Regeln gehorchen, komplexes Ver-halten auftreten kann, das nicht trivial ausden Regeln ableitbar ist. Als Beispiele dis-kutiert er verschiedene Systeme, wie staa-tenbildende Insekten, Strategiespiele wieGo oder Schach, die Borse, Evolution oderneuronale Netze. Er zeigt, dass sich daskomplexe Verhalten in vielen Fallen als in-harente Eigenschaft kombinierter einfacherRegeln erklaren lasst und bezeichnet einsolches Verhalten als Emergenz: „Emer-gence occurs in systems that . . . are com-posed of copies of a relatively small num-ber of components that obey simple laws“[Holl98, 225]. Als wesentliche Elementesolcher Systeme identifiziert er Agenten,die einen internen Zustand besitzen undmit anderen Agenten uber definierte Kom-munikationsmechanismen kollaborieren.Ruckkopplungsschleifen ermoglichen demSystem dabei, Gedachtnis aufzubauen undsich neuen Rahmenbedingungen anzupas-

sen. Formal entspricht dieses Modell modi-fizierten zellularen Automaten, die ihreeigenen Zustandsubergangsfunktionen ve-randern konnen. Holland weist nicht nurnach, dass solche Systeme Turing-vollstan-dig sind, also mit ihnen alle Probleme bear-beitet werden konnen, die mit festgelegtenAlgorithmen gelost werden konnen. Daru-ber hinaus gelingt es ihm auch, die Emer-genz in den zuvor erwahnten komplexenSysteme mit seinem Formalismus zu simu-lieren, wodurch er den Nachweis erbringt,dass Emergenz eine inharente Eigenschaftder modellierten Regeln und deren Inter-aktionen in dem System ist.

Das World Wide Web ist selbst ein Beispielfur solche Effekte: Basierend auf der ein-fachen Definition von Hypertext-Doku-menten mit HTML und dem Internet isteine neue Kommunikationsform entstan-den mit nachhaltigen Auswirkungen aufdas tagliche Leben, die Forschung und dieWirtschaft.

Agile Softwareentwicklungsverfahren ver-suchen nun, ein solches System in demProjektteam zu etablieren. Statt das Teamals hierarchisch steuerbare Organisation zuinterpretieren, deren Ablaufe durch detail-lierte Prozessbeschreibungen zu steuernseien, werden sie als komplexes Systemverstanden, in dem die Teammitgliederdurch intensive Kollaboration das Soft-waresystem schaffen. Aus dem gesteuertenProzess wird so ein geregeltes Verfahren.Die Idee, Projekte nicht als steuerbare Hie-rarchie, sondern als komplexes System zubegreifen ist nicht neu. So forderte GeraldWeinberg bereits 1971, man solle Projekteals soziale Systeme begreifen und aus psy-chologischer Sicht erforschen [Wein98].Allerdings standen ihm damals weder dieWerkzeuge der Komplexitatsforschungnoch eine ausgefeilte Systemtheorie zurVerfugung – letztere ein wesentlicherSchwerpunkt Weinbergs spaterer Arbeit.

4 Drei ausgewahlteVerfahren der agilenSoftwareentwicklung

Die oben vorgestellten Konzepte der Or-ganisations- und Komplexitatsforschunghaben Eingang in verschiedene Verfahrender agilen Softwareentwicklung gefunden.Bevor jedoch einige Verfahren beschriebenwerden, soll zunachst eine Taxonomie ent-



wickelt werden, die es erleichtert, die Un-terschiede zwischen den Verfahren zu ana-lysieren.

4.1 Taxonomie agiler Verfahren

Eine grundlegende Eigenschaft aller agilenVerfahren ist die inkrementelle Vorgehens-weise. In regelmaßigen Abstanden vonzwei Wochen bis vier Monaten wird nichtnur lauffahige Software ausgeliefert, son-dern auch das Vorgehen in einem Team-prozess uberpruft. Dieses Konzept bildetgleichsam die Basisregeln des komplexenSystems „Projekt“, aus denen sich mittelsEmergenz das Vorgehen ergibt.

Um eine Taxonomie der verschiedenenVerfahren zu bilden, ist eine weitere Eigen-schaft komplexer Systeme hilfreich: Sie nei-gen dazu, Hierarchien zu bilden. So lasstsich ein einzelnes Insekt als Bestandteil deskomplexen Systems Insektenstaat interpre-tieren. Das einzelne Individuum lasst sichaber seinerseits wieder als komplexes Sys-tem von Zellen interpretieren, die manwiederum als komplexes biochemischesSystem interpretieren kann. Jede neueHierarchiestufe gehorcht den Regeln derunter ihr liegenden Stufen und fugt neueRegeln hinzu, die ihrerseits zu Emergenzfuhren.

Auch die agilen Verfahren bilden eine Hie-rarchie in diesem Sinne. Sie unterscheiden

sich nicht nur in der Ausgestaltung einzel-ner Details, sondern in der Ebene, auf dersie Regeln aufstellen: Auf unterster Ebenestehen jene Vorgehensweisen, die lediglichdie Voraussetzungen schaffen, um ein ler-nendes Team einzusetzen. In der Tat sinddiese reinen Metaprozesse nicht beschranktauf die Softwareentwicklung. So wurdezum Beispiel Scrum [ScBe02] auch bei demjapanischen Kamerahersteller Canon einge-setzt, um die erfolgreiche AE-1-Serie zuentwickeln3. Auf dieser Ebene bieten dieVerfahren vor allem ein konsistentes Wer-tesystem und die organisatorischen Maß-nahmen, um dieses Wertesystem in derPraxis auch umzusetzen. Ein Beispiel furein solches Wertesystem ist die in Ab-schnitt 4.2 diskutierte Folge „Speculate,Collaborate, Learn“ des Adaptive SoftwareDevelopments. Die Metaprozesse sind oh-ne weitere Hinweise vor allem fur profes-sionelle Teams geeignet, die viel Erfahrunghaben. Dafur bieten sie ein Maximum anFlexibilitat und ermoglichen den Teams,sehr schnell auf geanderte Anforderungenzu reagieren.

Die nachste Ebene oberhalb der reinenMetaprozesse gibt Hinweise, wie ein Ent-wicklungsprozess effizient organisiert wer-den kann. Allerdings werden hier nurZusammenhange aufgezeigt und keine Vor-gaben fur die Teams gemacht. Als Beispielmogen die Prinzipien der Crystal-Metho-den dienen, die in Abschnitt 4.3. diskutiertwerden. Diese Empfehlungen konnen beider Moderation des Metaprozesses helfen,

also wenn es gilt, das Team bei der Prozess-findung zu unterstutzen. Auch diese Ver-fahren sind nicht auf bestimmte Entwick-lungstechniken festgelegt, zeigen aberschon deutlich ihre Herkunft aus der Soft-wareentwicklung.

Die oberste Ebene enthalt schließlich Ver-fahren, die detaillierte Startvorschlage zumEntwicklungsprozess machen und damitden traditionellen Prozessen am ahnlichstensind. In diese Kategorie fallt zum Beispieldas Extreme Programming (XP), das inAbschnitt 4.4 ausfuhrlicher diskutiert wird.

Im Folgenden wird stellvertretend fur jedeEbene ein Verfahren vorgestellt. Zunachstwird Adaptive Software Development vor-gestellt, dann die Crystal-Methodenfamilieund schließlich Extreme Programming.

4.2 Adaptive SoftwareDevelopment (ASD)

Kern von ASD ist die Schrittfolge „Specu-late, Collaborate und Learn“ [High00], diein Inkrementen von wenigen Wochendurchlaufen wird. Die Anforderungenwerden zu Beginn eines Inkrements ge-meinsam mit dem Auftraggeber priorisiert.Aus dieser Liste erstellt das Team einengroben Plan fur das kommende Inkrement,den Highsmith als „Spekulation“ bezeich-net, um zu betonen, dass der Plan lediglichdas aktuelle Wissen uber die Aufgabe vor


Lernendes

Team

Effizienzregeln

Verfahren mit Startvorschlägen

Adaptive Software Development

Crystal-Methoden

Scrum

Dynamic SystemsDevelopment Method (DSDM)Feature-driven Development (FDD)Extreme Programming (XP)

Detaillierungsgrad

Flexibilität

Möglicher Schaden

L Verlust von

Menschenleben

E „Essenzielle“

finanzielle

Verluste

D Mäßige

finanzielle

Verluste

C Verlust an

Komfort

RedClear Yellow Orange

Teamgröße

C80C40C20C6

D80D40D20D6

E80E40E20E6

L80L40L20L6

RedClear Yellow Orange

Teamgröße

C80C40C20C6

D80D40D20D6

E80E40E20E6

L80L40L20L6

Bild 2 Die drei Ebenen agiler Verfahren. Die Breite jeder Ebene symbolisiert denUmfang, in dem das jeweilige Verfahren das Vorgehen festlegt.

Bild 3 Die verschiedenen Mitglieder der Crystal Me-thodenfamilie mit ihrer Eignung je nach Teamgroße(horizontale Achse) und Kritikalitat (vertikale Achse).Die Grafik wurde [Cock98] mit freundlicher Genehmi-gung des Autors entnommen.

242 Jens Coldewey

deren Bearbeitung darstellt und daher mithoher Wahrscheinlichkeit den realen Ab-lauf nur sehr schlecht modelliert. ImAnschluss an diese „Spekulationsphase“werden im Kollaborationsteil die Anforde-rungen des Auftraggebers mit Vertreternder Anwender gemeinsam analysiert unddas System so weit weiterentwickelt, dasses diesen neuen Anforderungen genugt.Diese Phase nimmt den großten Teil desProjektes ein. Ihr Ende ist stets ausgeliefer-te Software, die im so genannten Timebox-Verfahren fertiggestellt wird. Das bedeutet,dass Planungsverzug oder neu auftauchen-de Anforderungen nicht in traditionellerWeise durch eine verspatete Auslieferungoder schlechtere Qualitat ausgeglichenwerden, sondern durch Reduktion oder�nderung des Auslieferungsumfangs.

Nicht alle Anforderungen werden dabeiproblemlos umsetzbar sein und nicht allePlanungsannahmen werden eintreffen. Da-her sieht ASD als Abschluss des Inkre-ments eine dritte Phase vor, in der das ge-samte Team gemeinsam aus dem zu Endegehenden Inkrement lernt. Probleme wer-den dabei gemeinsam analysiert, Verbes-serungsvorschlage zum Vorgehen gesam-melt und im nachsten Inkrementausprobiert. Neuerungen fuhrt man inzwei Stufen ein. Zunachst werden sie einInkrement lang ausprobiert, aber ohne beider Planung Berucksichtigung zu finden.Erst wenn sich die Neuerung bewahrt hat,wird sie dann bei der Planung der uber-nachsten Inkrements berucksichtigt. Sokann man allzu optimistische Annahmenbei der Planung vermeiden, und der Ent-wicklungsprozess bleibt in der Kontrolledes Teams.

4.3 Crystal-Methodenfamilie

Agile Verfahren beabsichtigen also garnicht, organisationsweite Prozesse zu defi-nieren. Sie sollen vielmehr eine Arbeits-umgebung schaffen, in der das Team in dieLage versetzt wird, den fur das Projektspezifischen Prozess zu definieren.Highsmith spricht daher in [High02] be-wusst nicht von „agilen Prozessen“, son-dern von „Agile Software DevelopmentEnvironment“. Hier schlagt sich die �ber-zeugung nieder, dass Prozesse im Wesent-lichen von den Rahmenbedingungen desProjekts bestimmt werden, ein Gedanke,den der Berater Alistair Cockburn zurGrundlage seiner Arbeit gemacht hat.

Cockburn hat aus der Untersuchung Dut-zender von Projekten sieben Prinzipien ex-trahiert, die bei erfolgreichen Projekten be-rucksichtigt werden. Diese Prinzipien sinddas Ruckgrat der von ihm entworfenen„Crystal-Methodenfamilie“ [Cock02]:

& Direkte, interaktive Kommunikationzwischen zwei Anwesenden ist derpreisgunstigste und schnellste Kanal, umInformationen auszutauschen.

& Je großer das Team wird, umso mehrRegeln braucht das Team zur Koordina-tion und um eine akzeptable Konfor-mitat der Ergebnisse zu erreichen.

& �berflussige Regeln in einer Methodekosten uberproportional viel Geld.

& Je hoher die Kritikalitat eines Projektsist, um so hoher muss der Zeremonie-Anteil sein, also der Anteil von außennachvollziehbarer Interaktionen undEntscheidungen.

& Formalismus bedeutet nicht Disziplin,Prozess bedeutet nicht Fahigkeit, Doku-mentation bedeutet nicht Verstandnis.

& Mehr Feedback und Kommunikationvermindern die Notwendigkeit vonZwischenprodukten.

& Effizienz wird zur Dispositionsmasse,sobald man sich nicht auf dem kritischenPfad befindet. Fur Teammitglieder ab-seits vom kritischen Pfad kann es loh-nender sein, statt schneller Resultatemoglichst stabile Ergebnisse in den kri-tischen Pfad des Projektes einzuspeisen,oder die Kollegen auf dem kritischenPfad auf andere Art zu entlasten.

Diese Prinzipien bilden gemeinsam mitden beiden Forderungen, mindestens alledrei Monate Software auszuliefern undmindestens zweimal pro Inkrement denProzess im Team gemeinsam zu uberpru-fen, das Rahmenwerk der Methodenfami-lie. Cockburn geht davon aus, dass ein er-fahrenes Team mit Hilfe dieser wenigenPrinzipien einen Prozess entwickeln kann,der eine gute Gratwanderung zwischenFormalismus und Dokumentation auf dereinen Seite und schneller Auslieferungguter Software auf der anderen Seite dar-stellt. Dies bestatigt sich auch in der Pra-xis, wenn Projekte, die nach den genann-ten Prinzipien organisiert sind, auch unterschwierigen organisatorischen und tech-nischen Rahmenbedingungen erfolgreichdurchgefuhrt werden konnen [CoDo99;High02]. Auch wenn die Einhaltung die-ser Prinzipien einen Projekterfolg genausowenig garantiert, wie jedes andere Verfah-ren, zeigen erfolgreiche Projekte aber zu-mindest die grundsatzliche Eignung der

Vorgehensweise im professionellen Um-feld.

Cockburn hat aus den untersuchten Pro-jekten verschiedene nach Farben benannteMethoden extrahiert, die gemeinsam dieCrystal-Methodenfamilie bilden (Bild 3).Zu jeder dieser Methoden gibt Cockburnan, bei welcher Kritikalitat sie erfolgreicheingesetzt wurden und mit welchen Team-großen. So ist „Crystal Yellow“ geeignetfur Teamgroßen zwischen zwanzig undvierzig Personen und Systeme, von denenkeine Menschenleben abhangen. Die ein-zelnen Bereiche sind durch ein Kurzel ka-tegorisiert, das sich aus der Kritikalitat undder Teamgroße zusammensetzt. So charak-terisiert die Klasse E40 Projekte, die essen-zielle finanzielle Verluste verursachen kon-nen und mit einem Team zwischen 40 und60 Personen bearbeitet werden. Cockburnversteht diese Methoden aber nur als „Ba-sismethoden“, die vom gesamten Team inWorkshops zu Beginn des Projekts undnach jedem Inkrement angepasst und ver-bessert werden mussen. Das „Tailoring“ istdamit Aufgabe des gesamten Teams undnicht nur des Projektmanagements, wiedies z. B. beim V-Modell der Fall ist[BrDr95, 7–17].

Cockburn diskutiert zwei Einschrankun-gen seiner Methodenfamilie. Zum einennimmt er Systeme, von denen eine Bedro-hung von Menschenleben ausgehen kann,mit der Begrundung aus, dass er bisher kei-ne Projekte mit diesen Anforderungen un-tersuchen konnte, die mit agilen Verfahrengearbeitet hatten. Dem Autor sind aller-dings lebenserhaltende Systeme bekannt,die sich durchaus mit den Prinzipien vonCrystal vereinbaren lassen. Allerdings dur-fen diese Projekte aus Wettbewerbsgrun-den noch nicht veroffentlicht werden.

Als zweite Einschrankung gibt Cockburnraumlich verteilte Teams an: „[N]one ofthe distributed and offshore developmentprojects I have seen would count as metho-dologically successful [regardless of themethodology they used]. The only recom-mendation I have for such projects is toput the team together at one location.“[Cock02, 200]. Cockburn sieht die man-gelnde Unterstutzung also nicht als Schwa-che der Methoden, sondern stellt grund-satzlich in Frage, ob verteilte Entwicklungdie in sie gesetzten Hoffnungen erfullenkann.



4.4 Extreme Programming (XP)

Die bisher beschriebenen agilen Verfahrenhaben nur organisatorische Vorschlage un-terbreitet und keinerlei Aussagen uber dieeigentliche technische Durchfuhrung desProjekts gemacht. Dies geschah absichtlich,um die Flexibilitat des Verfahrens nichteinzuschranken. Dafur wird allerdings inKauf genommen, dass ein wichtiger Be-reich in der agilen Entwicklung der Erfah-rung des Teams anvertraut wird: Die Auf-gabe, die Software so zu entwickeln, dasssie auch wirklich anderbar wird, was dieVoraussetzung ist fur flexibles Arbeiten beigleichzeitiger Senkung der Entwicklungs-kosten. Die Verfahren der obersten Ebenein Bild 2 machen dagegen bereits konkreteVorschlage zur Ausgestaltung des Projekts.Beispielhaft soll hier Extreme Program-ming (XP) beschrieben werden, das derzeitauch den großten Bekanntheitsgrad auf-weist [Beck00]. Fur die Beschreibung wei-terer Verfahren, wie die Dynamic SystemsDevelopment Method (DSDM) [Stap97]oder Feature Driven Development (FDD)[CLDL99, Kapitel 6] sei auf die Literaturverwiesen.

Extreme Programming wurde von WardCunningham und Kent Beck entwickelt.Ward Cunningham gilt als geistiger Vaterder verbreiteten CRC-Karten [BeSu97] furobjektorientiertes Design, und beide warenauch an der Einfuhrung und Verbreitungvon Entwurfsmustern beteiligt. ExtremeProgramming beruht auf funf Grundprin-zipien:

& Unmittelbare Ruckkoppelung& Streben nach Einfachheit& inkrementelle Weiterentwicklung& �nderungen willkommen heißen& Qualitatsarbeit leisten

Aus diesen Grundprinzipien werden jenach Zahlung zwolf oder dreizehn Prakti-ken abgeleitet4, die drei Bereiche der Ent-wicklung abdecken:

& Der Projektzyklus– Customer on Site: Dem Projekt muss

ein entscheidungsbefugter AnwenderVollzeit in den Projektraumen zurVerfugung stehen. Mit dieser Personwerden fachliche Fragen in direkterDiskussion geklart.

– Short Increments: Alle ein bis zweiMonate wird ein neues Release aus-geliefert, das wirtschaftlichen Mehr-wert bietet.

– Planning Game: Das Team priorisiertzu Beginn eines Inkrements gemein-sam mit dem Anwender Skizzen furAnwendungsfalle (User Stories) nachihrer Bedeutung fur den wirtschaft-lichen Erfolg des Projekts. Fur ein-zelne User Stories wird der Aufwandgeschatzt und der beabsichtigte Lie-fertermin wird festgelegt.

– Acceptance Tests: Die Tests werdenvom Anwender definiert. Sie legenfest, wann ein Anwendungsfall aus-reichend implementiert ist, um abge-schlossen zu sein.

& Der Entwicklungszyklus– Simple Design: Zu jedem Zeitpunkt

stellt das Design immer die einfachsteMoglichkeit dar, die bisher realisier-ten Funktionen zu implementieren.

– Pair Programming: Statt nachtragli-che Inspektionen oder Reviews zurSicherung der Codequalitat einzuset-zen, wird der gesamte Code grund-satzlich nur zu zweit geschrieben.Ein Partner ubernimmt dabei die ak-tive Rolle, der zweite macht Vor-schlage zur Vereinfachung und zu al-len anderen Aspekten, die ihmauffallen.

– Unit Tests: Die Entwickler schreibenihre Tests, bevor sie den Code schrei-ben. Die Tests laufen automatisch abund der Code wird dann so veran-dert, dass die Tests ohne Fehler lau-fen. Entdeckt man fachliche Luckenim so geschriebenen Code, werdenzuerst die Testfalle erganzt, dannwird der Code soweit „korrigiert“,bis die Testfalle wieder laufen.

– Refactoring: Entdecken Entwicklerbeim Programmieren eine Moglich-keit, das Design zu vereinfachen, sowird dies ohne �nderung der fachli-chen Funktionalitat durchgefuhrt. Daman diese Aufgabe standig durch-fuhrt, ist das meist nur eine Angele-genheit von Minuten [Robe99;Fowl99].

& Unterstutzende Praktiken– Common Ownership: Grundsatzlich

gehort der Code allen. Das bedeutetzum einen, dass jedes Programmier-parchen das Recht hat, jeden Codedes Systems zu andern, zum anderenaber auch, dass jeder Einzelne diePflicht hat, dafur zu sorgen, dass dasSystem als Ganzes lauft und das De-sign insgesamt einfach bleibt.

– Programming Standards: Im Teamsollten einheitliche Konventionenexistieren, wie Code zu formatieren

ist und nach welchem Stil program-miert werden soll.

– Continuous Integration: Sobald dieTests eines Parchens laufen, setzt die-ses sich an die Integrationsmaschineund integriert den neuen Code in dasGesamtsystem. Dies passiert in derRegel mehrmals pro Tag. Die Integra-tion ist dann abgeschlossen, wenn alleTestfalle fehlerfrei durchlaufen.

– Metapher: Dies ist ein schlussiges in-formelles Modell des Systems, das diegesamte Entwicklung leitet. Ein Bei-spiel fur eine solche Metapher ist diebekannte „Desktop-Metapher“, diemodernen Fensteroberflachen zu-grunde liegt.

– Sustainable Pace: Nachdem ein XP-Projekt nicht die ublichen Stress- undErholungsphasen hat, ist sicherzustel-len, dass das Team nicht ausbrennt.Das Arbeitstempo muss so bemessensein, dass es uber Monate oder Jahredurchgehalten werden kann.

Die Regeln sind als Startvorschlag vorgese-hen, von dem das Team im Laufe des Pro-jekts abweicht, wenn sich bessere Moglich-keiten ergeben.

Dieser Vorschlag hat eine breite Diskussionausgelost: Wie kann ein Projekt ohne Ar-chitektur, ohne Design und ohne Doku-mentation erfolgreich verlaufen? Zunachstist diese Frage nicht korrekt gestellt. JedesProjekt besitzt eine Architektur und einDesign. Diese konnen fur das gegebeneProblem forderlich oder hinderlich sein, siekonnen bewusst oder unbewusst entstehenund sie konnen unterschiedlich ausfuhrlichdokumentiert sein. Immer aber liegt eineArchitektur und ein Design vor, auch wennsie nicht explizit dokumentiert wurden. Esstellt sich also eher die Frage, ob sich ohneexplizite Architektur- und Designphase einadaquates Design entwickeln lasst. DieEntwickler von XP vertreten hier die An-sicht, ein adaquates Design und eine tragfa-hige Architektur entstehe bei Einhaltungder Regeln durch Emergenz [High02], eineEinschatzung, die der Autor aus der eige-nen Beratungspraxis bestatigen kann.

Wissenschaftliche Studien liegen allerdingsmittlerweile fur Pair Programming vor[WiKe00]. So wurde bei einer Studie, dieLaurie Williams mit 44 Studenten an derUniversitat von Utah durchgefuhrt hat,festgestellt [Will00]:

1. Paare benotigen ca. 15% mehr Zeit alsEinzelprogrammierer, um die gleichen


244 Jens Coldewey

Aufgaben zu losen. Dieser Mehrauf-wand war nach Aussage der Autorin sta-tistisch nicht signifikant.

2. Die Paare hatten etwa 15% wenigerFehler in ihrem Code. Dieser Unter-schied war nach Angabe der Autorin sta-tistisch signifikant.

3. Wenn man die Einsparungen beruck-sichtigt, die sich durch die hohere Code-qualitat ergeben, ist paarweises Pro-grammieren fur die Organisation billigerals individuelles Programmieren.

4. 95% der Teilnehmer gaben an, dass ih-nen gemeinsames Programmieren bessergefallen hat als individuelles Arbeitenund dass sie großeres Vertrauen zu denErgebnissen haben.

Da diese Studie mit Studenten und nichtmit industriellen Teams durchgefuhrt wur-de, stellt sich die Frage nach der �ber-tragbarkeit der Ergebnisse auf ein profes-sionelles Umfeld. Zu dieser Frage stehenstatistische Studien noch aus. Einen erstenHinweis gibt die eingangs erwahnte Um-frage des Cutter Consortiums [Cutt01]. Inihr bewerteten die Teilnehmer auch dieMoral im Team auf einer Skala zwischen 1(sehr schlecht) und 6 (sehr gut). Das Ergeb-nis ist in Bild 4 dargestellt. Es zeigt, dassdie Moral in 76% der Projekte mit agilerEntwicklung als eher gut oder besser ein-geschatzt wurde, wahrend die Moral beitraditionellen Verfahren in 44% der Falleals eher gut angesehen wurde. Diese Ergeb-nisse sind nur bedingt verwertbar, da ge-nauere Angaben zum verwendeten Verfah-ren und zu wichtigen statistischen Großenwie Signifikanz fehlen. Dennoch deckensie sich mit Williams Arbeit.

Zu beachten ist auch, dass Extreme Pro-gramming und die anderen agilen Verfah-ren nicht aufgrund der einzelnen Maßnah-men funktionieren, sondern nur durchKombination der Mechanismen wie PairProgramming und Refactoring. DieseKombination fullt in der Praxis viele derLucken auf, welche die Verfahren bei ober-flachlichem Studium zu lassen scheinen.Andere Lucken, wie Gute und Umfang derDokumentation, mussen entsprechenddem Projektumfeld ausgefullt werden. Sobenotigt Bankensoftware vor dem Produk-tionsstart ausreichend Dokumentation, umvon der Revision abgenommen zu werden.Ebenso muss medizinische Software ent-sprechend der hohen Verantwortungdokumentiert sein, die der Hersteller demPatienten gegenuber ubernimmt. AgileEntwicklung stellt dem Team aber den

Zeitpunkt frei, wann diese Dokumentationerstellt wird. Wird sie erst nachtraglich er-stellt, konnen moglicherweise große Auf-wande fur �berarbeitungen eingespartwerden.

5 Zusammenfassung

Agile Softwareentwicklung bildet eine Al-ternative zum traditionellen Entwicklungs-prozess. Es gibt unterschiedliche agile Ver-fahren, die auch auf unterschiedlichenAbstraktionsebenen liegen. Sie alle zeigenbestimmte Merkmale:

& Die Entwicklung findet in kurzen In-krementen von wenigen Wochen statt.Diese Inkremente bilden Timeboxes.Als Steuerungselemente steht der Pro-jektleitung vor allem der Auslieferungs-umfang zur Verfugung. Durch die kur-zen Inkremente liegt der Fokus auflauffahiger Software in Produktionsqua-litat, nicht auf Modellen oder Doku-menten.

& Enge Kollaboration im Team und mitdem Kunden ersetzt einen Teil der Do-kumentation. Dafur wird auf Eigen-schaften wie Organisationseinheitlich-keit verzichtet.

& Die Hoheit uber den Prozess liegt beimTeam. Dieses muss den Prozess bewusstgestalten.

& Die Prioritaten werden fur jedes Inkre-ment erneut gemeinsam mit dem Auf-traggeber festgelegt. Dadurch kann das

Projekt schnell auf neue Rahmenbedin-gungen reagieren und die Auftraggeberkonnen Fehlentwicklungen fruhzeitigentgegenwirken.

& Dadurch, dass sich das Projekt vomzweiten Inkrement an im Wartungs-modus befindet, wird hoher Wert auf�nderbarkeit gelegt. Fehlentscheidun-gen werden schneller entdeckt als mittraditionellen Prozessen und konnen da-her fruher behoben werden.

& Die Verfahren sind besonders gut furWeb-basierte Projekte geeignet, wennneue Markte erschlossen werden sollen,deren fachlichen Anforderungen erst imProjektverlauf festgelegt werden kon-nen.

& Gegenstand der Erprobung sind nochder Einsatz bei lebenserhaltenden Syste-men. Ob die Verfahren fur verteilte Ent-wicklung einsetzbar sind, erscheint frag-lich.

Hintergrund agiler Verfahren sind zum ei-nen die Erkenntnisse uber lernende Orga-nisationen, zum anderen Erkenntnisse ausdem Bereich der Komplexitatsforschung.Sie befinden sich derzeit in der industriel-len Erprobung. Die bisherigen Erfahrun-gen mit ihnen stimmen optimistisch, auchwenn die Vorgehen haufig auf erheblichenpolitischen Widerstand stoßen. Ob sich dieVerfahren langfristig als uberlegen erwei-sen, bleibt allerdings noch abzuwarten.

Die wissenschaftliche Aufarbeitung diesesThemas hat erst begonnen. So betreibt derLehrstuhl von Prof. Maurer an der Univer-


10%

38%

28%

14%

8%

2%

1%

15%

28%

41%

13%

3%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

An

teil

der

An

two

rte

n

Agile Entwicklung Traditionelle Prozesse

Moral im Team bei 159 Unternehmen

1 (sehr schlecht)

2 (schlecht)

3 (eher schlecht)

4 (eher gut)

5 (gut)

6 (sehr gut)

Bild 4 Ergebnisse einer Umfrage zur Moral in einem Team in 159 Unternehmen nach[Cutt01].


sity of Calgary derzeit ein Forschungspro-jekt zu agiler Entwicklung, und Prof. Succivon der Universitat Bozen hat das NAMEProjekt beantragt, das „Network for AgileMethodologies Experience“, das die Erfor-schung zwischen Akademikern und Prakti-kern koordinieren soll. Die Ansatze, die inagiler Entwicklung verfolgt werden, klin-gen vielversprechend. Die Praxis zeigt, dassgerade im Bereich der Web-Entwicklungein großer Druck auf den Unternehmenlastet, schnell auf sich andernde Anforde-rungen zu reagieren. Agile Entwicklungscheint hier vielen Unternehmen ein mogli-ches Mittel zu sein, auf diesen Druck zureagieren. Es steht zu hoffen, dass ein bes-seres wissenschaftliches Verstandnis dieserVerfahren hilft, ihr Einsatzgebiet praziserabzugrenzen und die derzeit noch sehrkontrovers gefuhrte Debatte uber ihreTauglichkeit zu versachlichen.

Danksagung

Danken mochte ich Herrn Ralf Kneuperund den Gutachtern fur die konstruktivenund hilfreichen Anmerkungen, sowie Alis-tair Cockburn fur seine Unterstutzung unddie Genehmigung zur Verwendung seinerGrafiken.

Anmerkungen1 Die dargestellte Kurve wird haufig sointerpretiert, dass es sich nur um Fehlerhandele, die aus einer mangelhaften Spezi-fikation der Anforderungen an das Infor-mationssystem resultieren. Auch wenn ausder praktischen Erfahrung heraus einigesfur diese Interpretation spricht, geht sie je-doch nicht zwingend aus der Originalquel-le hervor: „The solid line in this figureshows a summary of current experience onlarger projects [. . .] on the relative cost ofcorrecting software errors (or makingother changes to the software) as a functionof the phase in which the corrections aremade.“ Weiter heißt es dann jedoch: „If asoftware requirements error is detectedand corrected . . .“ [Boeh81, Seite 39]. Diekonkrete Interpretation ist also unklar, be-einflusst jedoch die Argumentation desvorliegenden Artikel nicht wesentlich.

2 Emergenz erklart der Duden als „Begriffder neueren engl. Philosophie, wonach ho-here Seinsstufen durch neu auftauchendeQualitaten aus niederen entstehen“.

3 Scrum teilt das Projekt in Inkrementevon einem Monat Lange ein. Zu Beginn ei-nes solchen Inkrements werden gemeinsammit dem Auftraggeber die zu implementie-renden Features priorisiert, dann geht dieVerantwortung fur das Vorgehen im laufen-den Inkrement vollstandig auf das Teamuber. Nach einem Monat wird anhand deslauffahigen Codes gemeinsam eine Bestand-aufnahme durchgefuhrt und die noch ver-bleibenden Anforderungen neu priorisiert.

4 In der ursprunglichen Veroffentlichung[Beck00] sind Unit Tests und AcceptanceTests noch zu einer Praktik zusammenge-fasst, daher die Zahl zwolf.

Literatur

[Beck00] Beck, Kent: Extreme Programming Ex-plained – Embrace Changes. Addison-Wesley,Reading, Massachusetts 2000.

[BeSu97] Bellin, David; Suchman Simone, Susan:The CRC Card Book. Addison-Wesley, Read-ing, Massachusetts 1997.

[Boeh81] Boehm, Barry W.: Software EngineeringEconomics. Prentice Hall, Eaglewood Cliffs,New Jersey 1981.

[Boeh96] Boehm, Barry W.: Anchoring the Soft-ware Process. In: IEEE Software (1996)6

[BrDr95] Brohl, Adolf-Peter; Droschel, Wolfgang(Hrsg.): Das V-Modell – Der Standard fur dieSoftwareentwicklung mit Praxisleitfaden. Olden-bourg Verlag Munchen, Wien 1995.

[Capu98] Caputo, Kim: CMM ImplementationGuide – Choreographing Software Process Im-provement. Addison-Wesley, Reading, Massa-chusetts 1998.

[CLDL99] Coad, Peter; Lefebvre, Eric; De Luca,Jeff: Java Modelling in Color With UML – En-terprise Components and Processes. PrenticeHall, Eaglewood Cliffs, New Jersey 1999.

[Cock98] Cockburn, Alistair: Designing a lightMethodology.http://members.aol.com/humansandt/,1998, Abruf am 2002-01-29.

[Cock02] Cockburn, Alistair: Agile Software De-velopment. Addison-Wesley, Reading, Massa-chusetts 2002.

[CoHi95] Coveney, Peter; Highfield, Roger: Fron-tiers of Complexity – The Search for Order in aChaotic World. Faber and Faber Ltd, London1995.

[CoDo99] Coldewey, Jens; Donko, Rudolf: SanfterWechsel, Teil 2: Bericht uber einen Prozess-Workshop. In: OBJEKTSpektrum (1999)5,S. 85.

[Cutt01] Cutter Consortium (Hrsg): BenchmarkReviews – Analyzing IT Metrics for InformedManagement Decisions, 1(2001)4, S. 9ff.

[DHMi98] Droschel, Wolfgang; Heuser, Walter;Midderhoff, Rainer (Hrsg.): Inkrementelle undobjektorientierte Vorgehensweise mit demV-Modell 97. Oldenbourg Verlag Munchen,Wien 1998.

[Fish96] Fishman, Charles: They Write the RightStuff in: Fast Company Magazine, 1996(12),

http://www.fastcompany.com/online/06/write-stuff.html

[Fowl99] Fowler, Martin: Refactoring – Improvingthe Design of Existing Code. Addison-Wesley,Reading, Massachusetts 1999.

[GHJV94] Gamma, Erich; Helm, Richard; John-son, Ralph; Vlissides, John: Design Patterns –Elements of Reusable Object-Oriented Soft-ware. Addison-Wesley, Reading, Massachusetts1995.

[High00] Highsmith, James A. III.: Adaptive Soft-ware Development – A Collaborative Approachto Managing Complex Systems. Dorset House,New York 2000.

[High02] Highsmith, James A. III.: Agile SoftwareDevelopment Ecosystems: Problems, Principles,and Practices. Addison-Wesley, Reading, Massa-chusetts, 2002 (in Vorbereitung)

[Holl95] Holland, John H.: Hidden Order – HowAdaptation Builds Complexity. Perseus Books,Cambridge, Massachusetts 1995.

[Holl98] Holland, John H.: Emergence – FromChaos to Order. Oxford University Press, NewYork, Oxford 1998.

[JBRu99] Jacobson, Ivar; Booch, Grady; Rum-baugh, James: The Rational Unified SoftwareDevelopment Process. Addison-Wesley, Read-ing, Massachusetts 1999.

[Kruc00] Kruchten, Phillippe: The Rational UnifiedProcess – An Introduction. 2. Aufl., Addison-Wesley, Reading, Massachusetts 2000.

[Lion95] Lions, Jacques-Louis (Hrsg.): ARIANE 5Flight 501 Failure Report by the Inquiry Board.ESA, Paris. 1996, http://www.mssl.ucl.ac.uk/www_plasma/missions/cluster/ariane5rep.html,Abruf am 2001-12-23.

[NaRa69] Naur, Peter; Randell, Brian (Hrsg.):Software Engineering: Report of a conferencesponsored by the NATO Science Committee,Garmisch, Germany, 7–11 Oct. 1968, Brussels,Scientific Affairs Division, NATO (1969).http://www.cs.ncl.ac.uk/people/brian.randell/home.formal/NATO/, Abruf am 2001-03-11.

[Robe99] Roberts, Donald B.: A Practical Analysisfor Refactoring. PhD thesis at University of Illi-nois, Urbana-Champaign 1999.

[RoLS00] Rossi, Gustavo; Lyardet, Fernando;Schwabe, Daniel: Patterns for E-Commerce Ap-plications. In: Devos, Martine; Ruping, Andreas(Hrsg.): Proceedings of the 5th European Con-ference on Pattern Languages of Programs,2000, Universitatsverlag Konstanz, 2000,S. 269–281.

[ScBe02] Schwaber, Ken; Beedle, Mike: Agile Soft-ware Development with Scrum. Prentice Hall,Eaglewood Cliffs, New Jersey 2002.

[Seng90] Senge, Peter: The Fifth Discipline – TheArt & Practice of The Learning Organization.Currency Doubleday, New York 1990.

[SKRR94] Senge, Peter; Kleiner, Art; Roberts,Charlotte; Ross, Richard; Smith, Bryan: TheFifth Discipline Fieldbook – Strategies andTools for Building a Learning Organization.Doubleday Inc, New York 1994.

[SKRR99] Senge, Peter; Kleiner, Art; Roberts,Charlotte; Ross, Richard; Roth, George; SmithBryan: The Dance of Change – The Challengesto Sustaining Momentum in Learning Organiza-tions. Doubleday Inc, New York 1999.

[Stap97] Stapleton, Jennifer: DSDM – DynamicSystems Development Method. Addison-Wes-ley, Reading, Massachusetts 1997.


246 Jens Coldewey

[Step99] Stephenson, Arthur G.: Mars Climate Or-biter – Mishap Investigation Board – Phase IReport. NASA Jet Propulsion Laboratory, Pasa-dena. 1999.ftp://ftp.hq.nasa.gov/pub/pao/reports/1999/MCO_report.pdf, Abruf am 2001-12–23.

[Wein98] Weinberg, Gerald M.: The Psychology ofComputer Programming – 25th AnniversaryEdition. Dorset House, New York 1998.

[Will00] Williams, Laurie: The Collaborative Soft-ware Process. PhD thesis at University of Utah,Salt Lake City 2000.

[WiKe00] Williams, Laurie; Kessler, Robert R.: Ex-perimenting with Industry’s „Pair-Program-ming‘‘ Model in the Computer Science Class-room. In: Journal on Software EngineeringEducation, 2000 (12).


Abstract

Agile software development – introduction and overview

Both time-to-market and flexibility are becoming more and more important in today’s soft-ware development, especially when heading for web-based information systems. Traditionalprocesses focus on detecting errors early, because they assume that changing existing soft-ware is expensive. Agile software development uses a different strategy: The team is orga-nized to facilitate the design of changeable software. Tight relations to the stakeholders andshort feedback cycles enable the team to put the software into production faster and react tochanging requirements more flexible.

Keywords: software development processes, agile software development environments,time-to-market, Extreme Programming, Crystal methods family, Adaptive Software Develop-ment

Das Diskussionsforum für Wirtschaftsinformatiker unter ...

www.wirtschaftsinformatik.de

�

248 Jens Coldewey

Date post:	26-Aug-2016
Category:	Documents
Upload:	jens
View:	223 times
Download:	8 times

Agile Entwicklung Web-basierter Systeme; Agile software development;

Documents