Praxis derHMDHeft 290April 2013

Wirtschaftsinformatik

D 12952 • ISSN 1436-3011 • ISBN 978-3-86490-058-7dpunkt.verlag

Peter Gluchowski · Stefan Reinheimer (Hrsg.)

Agilität in der IT > Chancen und Nutzen agiler IT

> Evolution in der Softwareentwicklung

> Wireframes zur Oberflächenkonzeption

> Anwendungsbereiche agiler Methoden

> Agile Prozesse und Architekturen

> Business Intelligence und Agilität

> Semantische Netze

Praxis der Wirtschaftsinformatik – Inhalt

HM

D 2

90

Agilität in der IT

Weitere Fachthemen Rubriken92 Georg Disterer, Carsten Kleiner

BYOD – Bring Your Own Device101 Andreas Hufgard

Business Integration Trainee – Geschäfts-prozesse systembasiert begreifbar machen

110 HMD Best Paper Award 2012

118 Notizen

121 Bücher

124 Vorschau

126 Stichwortverzeichnis

128 Impressum

2 Cartoon

3 Editorial

4 Einwurf von Peter Chamoni

6 Stefan von BraukZurückeroberung der Zukunft – Chancen agiler IT

17 Alexander Fuchs, Carl Stolze, Oliver ThomasVon der klassischen zur agilen Softwareentwicklung Evolution der Methoden am Beispiel eines Anwendungssystems

27 Verena Berenbrink, Jörg Purucker, Thomas BahlingerDie Bedeutung von Wireframes in der agilen Softwareentwicklung

35 Jan Schümmer, Klaus ReichenbergerSemantische Netze in agilen Projekten

44 Stefan Toth, Uwe VigenschowArchitektur und Agilität – so passt das zusammen

56 Robert Krawatzeck, Michael Zimmer, Stefan TrahaschAgile Business Intelligence – Definition, Maßnahmen und Herausforderungen

64 Albert Fleischmann, Werner Schmidt, Christian Stary, Martina AuglAgiles Prozessmanagement mittels Subjektorientierung

77 Jutta EcksteinAgilität – ein Baustein der dritten industriellen Revolution

84 Ayelt KomusAgile Methoden in der Praxis – Studie zur Anwendung und Zufriedenheit

115 Glossar

Das Blog zum Thema: http://hmdblog.dpunkt.de

HMD 290 3

Editorial

Es gehört wohl zum Zeitgeist, dass alles schnel-ler, dynamischer, mobiler – eben agiler – wird.Nicht nur Stillstand bedeutet Rückschritt, son-dern auch schon langsamer Fortschritt. Selbstseriöse, über Jahrzehnte hinweg erprobte Me-thoden für das Projektmanagement und die Ar-chitektur- und Softwareentwicklung, wie dasWasserfall- oder das V-Modell, werden infragegestellt und durch das agile Manifest in denGrundfesten ihrer Bedeutung erschüttert. An-lass genug, um diese methodische Revolutionzum Gegenstand eines HMD-Schwerpunkt-hefts zu machen – Agilität in der IT.

Das vorliegende HMD-Heft zeigt im Über-blicksartikel, wie die im agilen Manifest vonKent Beck et al. (http://agilemanifesto.org/iso/de/principles.html) aufgeführten Prinzipien zuinterpretieren sind und sich umsetzen lassen.Dabei wird deutlich, welche Bereiche der IT da-von direkt beeinflusst werden. Im Anschluss de-monstriert ein Praxisbeispiel, wie als Reaktionauf ein wenig erfolgreiches »klassisches« Pro-jekt agile Methoden eingesetzt und dadurch dieErwartungen der Anwender erfüllt wurden. Diebeiden darauffolgenden Beiträge befassen sichmit Ansätzen, die den agilen Prinzipien folgenund entsprechend aufgesetzte Projekte umset-zen helfen. Zunächst präsentiert ein Praxisbei-spiel das »Wireframing«, bei dem die Anforde-rungen an eine Softwarelösung in enger Zu-sammenarbeit mit den Anwendern so konkreterhoben werden, dass die Softwareoberflächenvor der Codierung von Funktionen bis ins kleins-te Detail feststehen. Anschließend zeigt einsehr innovativer Ansatz, der in der Zukunft zu-nehmende Bedeutung erlangen könnte, wie se-mantische Mittel die Dynamik und Flexibilitätder Softwareerstellung bereichern können.

Die kritische Anforderung, über große Projek-te hinweg eine effiziente Softwarearchitektur zukonzipieren, ist Gegenstand eines weiteren Bei-trags, bevor Agilität im Umfeld von BusinessIntelligence adressiert und methodisch aufberei-

tet wird. Besonderer Fokus liegt auf den Heraus-forderungen, die dabei zu bewältigen sind.

Prozesse, ihre Dokumentation, Analyse undOptimierung sind die Grundlage für IT-Anforde-rungen. Ein subjektorientierter Ansatz ihrer Be-trachtung mit einem fließenden Übergang vonder Prozessdokumentation zur Softwareerstel-lung ist ebenfalls Gegenstand eines Beitrags. Ineinem übergreifenden Artikel wird die Agilitätals allgemeingültiger Lösungsansatz innerhalbder dritten industriellen Revolution für dieÜberwindung unternehmerischer Defizite pos-tuliert und mit Beispielen konkretisiert. ZumAbschluss dieses HMD-Schwerpunkts zeigt eineempirische Untersuchung die Relevanz und denNutzen agiler Ansätze eindrucksvoll auf.

Auch die Buchbesprechungen widmen sichzwei Veröffentlichungen zu agilen Methoden –eine in englischer und eine in deutscher Spra-che. Zwei ergänzende Außerhalbbeiträge unddie gewohnten Rubriken »Notizen«, »Glossar«und natürlich unser »Cartoon« runden die vor-liegende Ausgabe der HMD ab.

Wir sind überzeugt, ein spannendes und sehraktuelles Thema aufgegriffen und umfassendaufbereitet zu haben, und wünschen Ihnen vielSpaß beim Lesen! Nutzen Sie doch auch den Aus-tausch zum Thema »Agilität in der IT« auf unse-rem Blog unter http://hmdblog. dpunkt.de/.

Peter Gluchowski

Stefan Reinheimer

P.S.: Auf Seite 110 finden Sie Informationen zuden drei prämierten Beiträgen des HMD BestPaper Award 2012.

4 HMD 290

Peter Chamoni

Agile IT – Lernen aus der Vergangenheit

Den profunden Erkenntnissen von Heraklit vonEphesus (500 v. Chr.), der schon konstatierte:»Nichts ist so beständig wie der Wandel«, kannkaum noch etwas hinzugefügt werden, wennman über Softwareentwicklung und Projektma-nagement spricht. Heute heißt das ParadigmaAgilität und trägt den Namen Scrum. Neugieriggeworden prüft man seine Englischkenntnisseund findet sich bestätigt, dass es sich dabei ei-gentlich um ein »Gedränge« handelt, dasscheinbar nichts mit geordneten und geplantenProjektabläufen zu tun hat. Folgt man den Gu-rus der Softwareentwicklung, so entsteht indieser Atmosphäre aber die gewünschteschnelle Adaption oder auch Agilität durchenge Kooperation. Die negative Konnotationvom Gedränge in Bus und Bahn mag uns die Lo-gik nicht erschließen, bei näherem Hinsehenaber wirken Fischschwärme durchaus überle-benstauglich und reaktionsstark. Soll das nundie neue Methodik sein, nach der effektiv undeffizient Kundenanforderungen in Software-produkte umgesetzt werden?

Jahrzehnte haben wir Studenten ausgebil-det und ihnen Leitlinien zur industriellen Pro-duktion von Software vermittelt, die von Pha-senschemata und wohlgeplanten Arbeitsschrit-ten sowie dem ingenieurmäßigen Denkengeprägt war. War das alles nur eine Schimäreund didaktischer Schnickschnack? Nun, die Pra-xis hat uns leider gezeigt, dass die Dynamik derUnternehmensprozesse und der hohe Zeitdruckdie wohldefinierte Planungswelt durcheinan-derwirbeln. Dies gilt für alle auf Dauer angeleg-ten Regeln und Prozesse des betrieblichen All-tags, aber natürlich auch für den Bau von Arte-fakten zu deren Unterstützung.

Wandel statt Festhalten am Gewohnten,Agilität statt Stabilität? Fast 150 Jahre nach

Spencers und Darwins »survival of the fittest«können wir – in einem weiteren Rückgriff aufschlaue Köpfe der Vergangenheit und unsere ei-gene Lebenserfahrung – bestätigen, dass An-passungsfähigkeit einen höheren Reifegrad vonSystemen ausdrückt. Apropos, spricht man ei-gentlich von der Eigenschaft der geschaffenenArtefakte oder der Entstehungsprozesse? Bauenwir mit agilen Methoden stabile Systeme oder infestgefügten Arbeitsschritten agile Systeme?

Und überhaupt, wenn wir in die Vergangen-heit der Prozessoptimierung schauen, findenwir schnell Beispiele, bei denen ein agiles Kan-ban-System der getakteten Fertigung überle-gen ist. Zur Beurteilung der »Optimalität« soll-ten vielleicht die Zielvorstellungen und dieRahmenbedingungen herangezogen werden.Wann sind die agile Vorgehensweise und/oderdas agile Produkt vorteilhaft? Dem agilen Mani-fest zufolge eigentlich immer, denn die Kern-aussagen sind überzeugend und nachvollzieh-bar:

! Einzelpersonen und Interaktionen sind wich-tiger als Prozesse und Werkzeuge.

! Laufende Systeme sind wichtiger als umfas-sende Dokumentation.

! Zusammenarbeit mit dem Kunden ist wichti-ger als Vertragsverhandlungen.

! Reaktion auf Änderungen ist wichtiger alsdas Verfolgen eines Plans.

In der Praxis ergeben sich jedoch die bekanntenStolpersteine der Selbststeuerung von Gruppen.Wo die zentrale Planungs- und Kontrollinstanzfehlt, muss die Motivation und Kooperations-fähigkeit des Einzelnen als Motor dienen. Scrumkann man nicht verordnen, Scrum muss man le-ben! Projekte werden also nur dann erfolgreichsein, wenn das Team den Geist der Agilität verin-

Einwurf

HMD 290 5

nerlicht hat und in Sprints schnelle, am Ge-schäftsnutzen gemessene Erfolge erzielt. DieTrade-offs von Qualitäts-, Zeit- und Kostenzielenwerden dem pragmatischen Ansatz geopfert,möglichst schnell, priorisierte lauffähige Kom-ponenten bis zur Ausschöpfung der Budget-grenze zu erzeugen. Wenn es gut geht, trägt derKunde die Konsequenz, dass das veranschlagteBudget nur für die wichtigsten Bauteile reicht.Allemal besser als Projektbudgets komplett zuversenken! Insgesamt überwiegen wohl die po-sitiven Aspekte der skizzierten Vorgehensweise,dennoch sollte man den kritischen Blick nichtunterlassen. In diesem Sinne wünsche ich denLesern dieser Publikation viele neue Einblicke.

Prof. Dr. Peter ChamoniUniversität Duisburg-EssenMercator School of ManagementLehrstuhl für Wirtschaftsinformatik, insbesondere Business IntelligenceLotharstr. 6347057 Duisburgpeter.chamoni@uni-due.dewww.uni-due.de

6 HMD 290

Stefan von Brauk

Zurückeroberung der Zukunft – Chancen agiler IT

Agile Methoden haben sich mittlerweile in vielenBereichen der Softwareentwicklung etabliertund breiten sich auf angrenzende Domänen aus– auch in den Bereichen Betrieb, IT-Servicema-nagement, IT-Strategie, Business Intelligence undProzessmanagement werden agile Vorgehenetabliert, um die Agilität der IT im Sinne von Kun-den und Mitarbeitern zu erhöhen. Sollen agileMethoden erfolgreich eingeführt werden, ist ne-ben dem Commitment des Managements die ak-tive Steuerung des Einführungsprozesses durchdas IT-Management unabdingbare Vorausset-zung.

Inhaltsübersicht1 Der Status quo – warum ist Agilität relevant?2 Grundlagen der Agilität

2.1 Prinzipien und Werte2.2 Methodische Ansätze

3 Anwendungsgebiete3.1 Softwareentwicklung3.2 Betrieb und Infrastruktur3.3 IT-Servicemanagement3.4 Enterprise Architecture Management

4 Agilität einführen und managen4.1 Ziele definieren4.2 Strategische Entscheidungen treffen

und Risiken managen4.3 Vom Piloten zum Wirkbetrieb

5 Literatur

1 Der Status quo – warum ist Agilität relevant?

Wird über agile und nicht agile Methoden phi-losophiert, kann oft der Eindruck entstehen,dass in »der« IT in den letzten Jahren allesschiefgelaufen ist, was nur schieflaufen kann.Dass Projekte beispielsweise nach dem Wasser-

fallmodell überhaupt erfolgreich abgeschlos-sen werden können, scheint schon rein theore-tisch ausgeschlossen zu sein [Leffingwell 2007].Die Realität sieht bekanntlich oft anders aus:Täglich werden Projekte nach dem Wasserfall-modell zu einem erfolgreichen Ende geführt.Trotzdem sind die vielfach vorgebrachten Argu-mente nicht von der Hand zu weisen. Beispieledafür, dass IT-Projekte unerträglich langsamumgesetzt werden, sehr viel Geld kosten und zukeinem sinnvollen Ergebnis führen, sind eben-falls jedem bekannt – sowohl aus der Privat-wirtschaft als auch aus der öffentlichen Verwal-tung. Warum scheitern so viele IT-Vorhaben?

1. Unrealistische Zieldefinitionen: Stakeholdereines Projekts wünschen sich in der Regeleine exakte Vorhersage zu Kosten, Zeitbe-darf und Qualität eines IT-Vorhabens. DieseForderung impliziert, dass ausnahmslos alleUmstände, die diese Zielgrößen beeinflus-sen können, auch schon zu Projektbeginn be-kannt sind. Ist dies nicht gegeben oder wer-den falsche Annahmen getroffen, ist einScheitern des Projekts wahrscheinlich. Dabei vielen Vorhaben die genannten Zielgrö-ßen vor Beginn zumindest in Teilen unbe-kannt sind, ist die Wahrscheinlichkeit desScheiterns sehr hoch.

2. Falsche Organisationsstrukturen: In der Reali-sierung von IT-Vorhaben hat es sich in vielenUnternehmen und Behörden etabliert, Pro-zessframeworks und Vorgehensmodelle ein-zusetzen, die in der überwiegenden Zahldem Projektmanagementkontext entnom-men wurden. Allerdings ist zu beobachten,dass viele der so umgesetzten Vorhabenüberhaupt kein Projekt sind. Wesentliche Ei-genschaften eines Projekts (z.B.: ein Projekt

Chancen agiler IT

HMD 290 7

hat ein definiertes Ende) liegen nicht vor,aber es werden projektspezifische – zum Teilkontraproduktive – Tätigkeiten durchge-führt; d.h., es fehlt oftmals ein produktent-wicklungsspezifisches Vorgehens- und Orga-nisationsmodell.

3. Bürokratisierung und Generalisierung: Je grö-ßer die IT-Einheiten werden und je mehr sichdas Business auf eine IT-Infrastruktur stützt,desto größer wird das Bedürfnis im IT-Management, regulativ auf die IT selbst ein-zuwirken. Dieses Bedürfnis kann durch tat-sächliche oder gefühlte Fehlentwicklungenund vermeintlichen »Wildwuchs« in der IThervorgerufen sein. Mittlerweile sind eineVielzahl von Frameworks, Best-Practice-Sammlungen, generischen Lösungen undStandards verfügbar, die dieses Bedürfnisbefriedigen wollen. Beispiele sind CMMI,ITIL, TOGAF (The Open Group ArchitectureFramework), die Normen ISO 2700x, ISO900x usw. Bei der Nutzung solcher Frame-works sind aber oft folgende negative Effek-te zu beobachten: – Es entsteht hoher Aufwand und zeitlicher

Bedarf bei der Einführung und Anwen-dung der Frameworks (COBIT umfasstbeispielsweise 34 IT-Prozesse mit 318 Akti-vitäten und Kontrollzielen!).

– Es ist ein umfangreiches Tailoring der Frame-works notwendig.

– Eine hohe Formalisierung der Arbeitsab-läufe kann zu verzögerter Leistungser-bringung führen.

– Der tatsächliche Wertbeitrag der Frame-works im konkreten Anwendungsfall istunbekannt oder gar negativ.

– Die Qualität der Leistungserbringungwird auf niedrigem Niveau nivelliert.

– Mitarbeiter werden durch das Beschnei-den von Entscheidungsfreiräumen nega-tiv motiviert.

– Zur Durchsetzung der Frameworks wer-den explizite Stabsstellen geschaffen,und in der Folge wird die »Weiterentwick-

lung« dieser Frameworks zu einem Selbst-zweck.

4. Arbeitsteilung und Industrialisierung: Mit derIndustrialisierung der IT geht oftmals eineArbeitsteilung einher, die an der Fließband-arbeit der industriellen Warenproduktionorientiert ist (dies gilt insbesondere, wennOutsourcing in hohem Maße eingesetztwird). Eine solche tayloristische Arbeitsorga-nisation blendet oftmals aus, dass IT vor al-lem eine wissensbasierte Arbeitsform ist.Deshalb vervielfältigt eine extreme Arbeits-teilung die Zahl der notwendigen Schnitt-stellen und Kommunikationsbedarfe. JedeSchnittstelle kann Verzögerung und Infor-mationsverlust bedeuten, gleichzeitig wirdein ausgeprägtes Silodenken befördert, so-dass die Beteiligten nur noch Verantwortungfür sehr kleine Teile des Vorhabens überneh-men wollen (und können!).

5. Fehlende oder falsche Kommunikation: DiePunkte II-IV führen regelmäßig dazu, dassfunktionierende Kommunikation in IT-Vorhaben fehlt. Insbesondere wird zu oft dasVerfassen formaler Dokumente mit aktiver,zielführender Kommunikation verwechselt.

6. Methodische Unzulänglichkeiten: Fehlendeoder lückenhafte fachliche Exzellenz könnenzu erheblichen Risiken hinsichtlich aller Pro-jektziele führen. Dies gilt ebenso für die Pro-jektmanagementkompetenzen in wasser-fallartig strukturierten IT-Vorhaben.

7. Technische Probleme: IT-Vorhaben könnenaufgrund technischer Probleme (Inkompati-bilitäten, technische Stabilität usw.) schei-tern. Bezogen auf die Summe aller scheitern-den Projekte sind technische Gründe abernur eine absolute Minderheit. Allerdingswerden technische Gründe oft und gerne alsGrund vorgeschoben, um andere Problemezu verbergen.

Mit agilen Methoden wird die Erwartung ver-bunden, die unter den Punkten I-VI genanntenProbleme zu adressieren und idealerweise zu lö-sen.

Chancen agiler IT

8 HMD 290

2 Grundlagen der Agilität

2.1 Prinzipien und WerteDen agilen Methoden ist gemein, dass sie nichtlediglich eine Sammlung vermeintlicher BestPractices sein wollen, sondern den jeweiligenAnsatz mit Prinzipien und Werten unterfüttern,die exemplarisch im »agilen Manifest« [Becket al. 2001] dokumentiert sind.

Ein zentrales Motiv des agilen Wertesys-tems ist die explizite Kunden- bzw. Nutzenorien-tierung, d.h., die nachhaltige Befriedigung derKundenbedürfnisse – auch unter frühzeitigerEinbeziehung des Kunden in den Implementie-rungsprozess – genießt eine sehr hohe Priorität.

Damit einhergehend akzeptieren agile Vor-gehensweisen nicht nur, dass im Rahmen derWeiterentwicklung eines IT-Produkts neue An-forderungen durch den Bedarfsträger angemel-det werden oder bereits formulierte Änderun-gen modifiziert werden – vielmehr sind dieagilen Vorgehensweisen explizit sehr ände-rungsfreundlich ausgestaltet. Das impliziert un-ter anderem, dass bei der agilen Realisierungzur Erstellung oder Änderung des jeweiligenProdukts nicht auf die vollständige und ab-schließende Formulierung aller Anforderungengewartet wird, sondern schon auf der Basis vonEinzelanforderungen mit der Realisierung be-gonnen wird. Die Möglichkeit, jederzeit Anfor-derungsänderungen zu akzeptieren, wird vonden Vertretern der agilen Vorgehensweisen alsWettbewerbsvorteil interpretiert.

Ein weiteres zentrales Prinzip der agilenVorgehensweisen, das den Aspekt der Kunden-zufriedenheit flankiert, ist die Konzentrationauf die Erstellung und Auslieferung der Liefer-gegenstände – seien dies nun Softwareartefak-te, Dokumente usw. Diese Artefakte sollen demKunden kontinuierlich und in kurzen Abständenzur Verfügung gestellt werden, damit dieser dieArbeitsergebnisse prüfen und sein Feedback andas Team geben kann. Funktionierende Liefer-gegenstände haben eine deutlich höhere Priori-tät als prozessbegleitende Dokumentationen.

Das Wertesystem ist auch für die eigene Ar-beit im Team relevant. So wird in agilen Ansät-zen durchweg der Aspekt der Selbstorganisationdes Teams dem militärischen Command-and-Control-Ansatz entgegengestellt. Die Selbstor-ganisation des Teams impliziert neben dem Ab-bau von Hierarchien ein hohes Commitment (dieÜbernahme von Verantwortung), sowohl indi-viduell als auch als Team. Der Anspruch derSelbstorganisation wird auch als Herausforde-rung verstanden, da die Teammitglieder einehohe Professionalität und Selbstdisziplin sowiefachliche und technische Exzellenz an den Taglegen müssen.

Schließlich wird weiterhin regelmäßig dieBedeutung der Individuen und der sozialen In-teraktion betont, »Menschen und Interaktionensind wichtiger als Prozesse und Werkzeuge«[Beck et al. 2001]. Entsprechend ist direkte Kom-munikation – sowohl mit dem Kunden als auchim Team – essenziell für agile Ansätze.

2.2 Methodische AnsätzeUm in IT-Vorhaben die genannten Prinzipienund Werte realisieren zu können, haben sichverschiedene Methoden etabliert, die in ver-schiedenen Domänen zur Anwendung kom-men und tradierte Vorgehen ersetzen können.In herkömmlichen Managementprozessen wirdbeispielsweise der Abschluss einer Aktivitätüber die Zeitdauer definiert, die für die vollstän-dige Umsetzung einer Anforderung benötigtwird. In agilen Modellen wird hingegen Time-boxing angewendet, wodurch dieses Verhältnisumgekehrt wird: Es wird zuerst definiert, wieviel Zeit zur Verfügung steht, und anschließenddie Anforderungen bestimmt, die in diesemZeitraum definitiv umgesetzt werden können.Diese – in den agilen Verfahren oft als Sprint be-zeichnete – Zeitdauer definiert auch den zeitli-chen Rahmen, auf den sich Planung, Controllingund Berichtswesen beziehen.

Aus diesem Gedanken des Timeboxing las-sen sich weitere agile Methoden ableiten: Daagile Vorgehen darauf abzielen, sehr schnell

Chancen agiler IT

HMD 290 9

Feedback zu generieren, sind die Sprints in derRegel sehr kurz gehalten. Dies impliziert, dassnicht triviale Vorhaben unmöglich innerhalb ei-nes einzigen Sprints umgesetzt werden kön-nen. Es müssen vielmehr zahlreiche Sprints ite-rativ durchlaufen werden – gleichzeitig mussaber am Ende jedes Sprints ein »fertiges« Pro-dukt erzeugt worden sein, das dann unter qua-litativen Gesichtspunkten – zumindest poten-ziell – ausgeliefert werden kann.

Ein gemeinsamer Qualitätsanspruch wirderzielt, indem eine gemeinsame Vereinbarungder Definition of Done (DoD) erarbeitet wird. DieDoD ist oftmals eine generische Checkliste, diedie Aktivitäten beschreibt, die zur abschließen-den Bearbeitung einer Aufgabe innerhalb einesSprints gehören (bspw. im Falle der Erstellungvon Software: Code entwickeln, Code kommen-tieren, Unit Tests schreiben, Release Notes ver-fassen usw.). Ebenso gehören Vereinbarungenwie Metriken (Testfallabdeckung, Codequalitätusw.) zur DoD.

Die frühen und kontinuierlichen Ausliefe-rungen setzen voraus, dass zu Beginn desSprints das Ergebnis des Sprints transparentund nachvollziehbar definiert wird. Dies ge-schieht, indem die in dem Sprint umzusetzen-den Anforderungen ausgewählt werden. DieseAnforderungen werden üblicherweise dem so-genannten Backlog entnommen. Das Backlogenthält die priorisierten Anforderungen, die andas Produkt gerichtet sind; die Priorisierung er-folgt dabei anhand von Kriterien wie wirt-schaftlichem Nutzen, Risiko und Abhängigkei-ten. Ein Backlog ist grundsätzlich nicht abge-schlossen, sondern kann jederzeit um neupriorisierte Anforderungen ergänzt werden.

In agilen Vorgehensweisen hat sich dieKommunikation von Angesicht zu Angesicht alswesentlich effektiver und effizienter als einedokumentengestützte Kommunikation heraus-gestellt. Dies geht einher mit einfacher, hierar-chiefreier Regelkommunikation sowie gerin-gem Reporting- und Dokumentationsover-head.

Zur Unterstützung des Selbstorganisations-ansatzes und zur Vermeidung von Silodenkenwerden agile Teams nicht nach funktionalenAspekten organisiert (z.B. Entwicklung/Test/Betrieb), sondern oftmals auf ihre Aufgaben-stellung bezogen zusammengestellt (CrossFunctional Teams), dies insbesondere unter Ein-beziehung von Experten der Fachdomäne.

3 Anwendungsgebiete

3.1 SoftwareentwicklungIn der Softwareentwicklung haben sich ver-schiedene Techniken und Vorgehensweisenetabliert, die im Kontext der agilen Entwicklungrelevant sind. Das Test Driven Development[Beck 2002] stützt sich beispielsweise auf dasUnit-Testen. Diese schon lange bekannte Tech-nik wird dahingehend operationalisiert, dassUnit Tests entwickelt werden, bevor der eigent-liche Testgegenstand implementiert wird. AlsVorteile des Vorgehens werden u.a. verbucht,dass sehr schnell Stabilität über die Schnittstel-len eines Moduls erlangt wird, dass das Soft-waredesign sich durch eine gute Testbarkeitauszeichnet und zudem eine hohe Testfallab-deckung auf Quellcodeebene dem Verfahrenimmanent ist.

Im Bereich der Testautomatisierung werdendiese Gedanken aufgegriffen und auf andereTeststufen im Softwareentwicklungsbereichausgeweitet. Durch modellbasierte Testauto-matisierung, Data Driven Tests oder Capture &Replay wird die automatisierte Ausführung undAuswertung von Tests im System- und System-integrationstest eingeführt und so ein hohesMaß an Reproduzierbarkeit und Vollständigkeitder Tests sichergestellt.

Mittels Continuous Integration [Duvall et al.2007] wird die frühzeitige und automatisierteIntegration von Softwareartefakten durchge-führt und mithilfe von Unit Tests, Testautomati-sierung und der Erstellung von Metriken dieQualität der Softwareprodukte bestimmt. Ne-ben der automatisierten Prüfung von Architek-

Chancen agiler IT

10 HMD 290

tur- und Designvorgaben auf Quellcodeebeneexistieren Clean-Code-Bewegungen [Martin2011], die sich um eine handwerklich saubereImplementierung von Anforderungen auf Quell-codebasis bemühen. Dieser Ansatz wird auchunterstützt durch ständiges Refactoring [Fowler1999], worunter die Möglichkeit (und Bereit-schaft) verstanden wird, das Design bestehen-den Codes beständig zu verbessern. Abge-sichert wird dieser Ansatz wiederum durch diebereits genannten Unit Tests, wodurch sich derKreis schließt.

Neben den Domänen Implementierungund Test haben sich auch im Bereich des Anfor-derungsmanagements agile Methoden heraus-gebildet. Als Alternative zu aufwendigenMethoden wie objektorientierter Analyse undDesign (OOA/OOD) oder textorientierten Pflich-tenheften bietet sich die Formulierung von UserStories an. Um teamorientiert die Aufwände zuschätzen, die aus den einzelnen User Storiesentstehen, haben sich die Story Points etabliert,die mit verschiedenen Schätzverfahren verge-ben werden können.

Analog und parallel zu den agilen Technikenhaben sich verschiedene Vorgehensmodelle he-rausgebildet. Diese zeichnen sich dadurch aus,dass sie auf wenigen formalen Regelungen be-ruhen, (vermeintlich) schnell erlern- und an-wendbar sind, aber in der Anwendung z.T. er-heblich von »traditionellen« Vorgehensmodel-len abweichen.

Aufgrund seines Top-down-Ansatzes nochrelativ stark mit traditionellen Vorgehensmo-dellen verwandt ist das Feature Driven Develop-ment (FDD) [Palmer 2002]. Hierbei bilden die

– von einem Gesamtplan ausgehende – funk-tionale Dekomposition eines Entwicklungsvor-habens und die iterative Umsetzung das Rückgratder Umsetzung. Im FDD existieren letztlich fünfProzesse, von denen die letzten beiden jeweilsje Feature iterativ durchlaufen werden (vgl.Abb. 1).

Dieses Prozessmodell wird durch ein diffe-renziertes Rollenmodell (Projektleiter, Entwick-ler, Business-Architekt etc.) angereichert.

Verglichen mit dem FDD ist der Formalisie-rungsgrad des Extreme Programming (XP) [Beck2004] nochmals deutlich reduziert. XP ist einesder ersten agilen Vorgehensmodelle und wurdein Softwareentwicklungsprojekten von Ent-wicklern selbst ausgearbeitet, um ihre spezifi-schen Bedürfnisse zu befriedigen. XP fokussiertWerte und Praktiken, daher stehen das Selbst-verständnis der Softwareentwickler als Hand-werker und davon abgeleitete Tugenden undTechniken (»Craftsmanship«) im Zentrum desWertesystems. Für XP relevante Werte sind bei-spielsweise »Respekt«, »Mut« und »Kommuni-kation«, aus denen dann die zugehörigen Prak-tiken abgeleitet werden. Einige dieser Praktikengehören mittlerweile zum Common Sense derguten Softwareentwicklung (»laufendes Refac-toring«, »Kundeneinbeziehung«), andere füh-ren zu einer hohen Polarisierung in der Rezeptionvon XP bzw. zu einer deutlichen Ablehnung vonXP – nicht zuletzt auf Managementebene:So stoßen Konzepte wie »Pair Programming«,»keine Überstunden« usw. regelmäßig auf Un-verständnis und/oder Ablehnung.

Viele Ideen des XP werden von Scrum [Rubin2012] aufgegriffen. Scrum ist aktuell das be-

Erstelle ein Gesamtmodell

Erstelle eine Featureliste

Plane je Feature Entwerfe je

Feature

Konstruiere je Feature

Abb. 1: Prozessschritte im FDD

Chancen agiler IT

HMD 290 11

kannteste und am häufigsten angewendeteagile Vorgehensmodell und hat wie XP seinenFokus auf dem Softwareentwicklungsprozess.Scrum treibt in gewisser Weise XP auf die Spit-ze, indem ein streng iteratives, an Timeboxesausgerichtetes Prozessmodell formalisiert wird.Hierbei wird jede Iteration (Sprint) von planen-den, berichtenden und retrospektiven Aktionenbegleitet. Regelaktivitäten in den Scrum-Itera-tionen sind

! das Sprint Planning Meeting, in dem dasSprint Backlog aufgebaut wird,

! das namensgebende Daily Scrum, in dem derStatus der Sprint-Aktivitäten nachverfolgtwird (die Visualisierung erfolgt mit einem so-genannten Burndown-Chart),

! das Sprint-Review, das zur Präsentation derErgebnisse der Sprints dient, sowie

! die Retrospektive, in denen die Lessons Lear-ned des vorangegangenen Sprints erarbeitetwerden sollen.

An dem skizzierten Prozess sind nur drei Rollenaktiv beteiligt: Scrum Master, Product Ownerund das Team. Andere Rollen wie beispielsweisedas Management oder die User haben keine ak-tiven Parts.

Eine ähnliche Ausrichtung wie die bishergenannten Vorgehensmodelle besitzt dieCrystal-Prozessfamilie [Cockburn 2004]. BeiCrystal stehen die Themen der Skalierung (be-zogen auf die Zahl der Projektmitarbeiter) unddie risikoadäquate Projektdurchführung im Vor-dergrund. Allerdings spielt Crystal aktuell in derPraxis nur eine sehr untergeordnete Rolle.

Einen anderen genealogischen Ursprungbesitzt das mittlerweile weitverbreitete Kanban[Anderson 2011]. Dieses Vorgehen ist aus derAutomobilfertigung abgeleitet und richtet denFokus auf eine möglichst kontinuierliche Aus-lastung der Ressourcen. Dies wird erreicht, in-dem die Menge der gleichzeitig stattfindendenArbeit (Work in Progress/WIP) der zu Verfügungstehenden Ressourcen limitiert wird. Ein Werk-zeug ist hierfür das Kanban-Board, auf dem die

Aufgabenpakete geplant werden und dann ver-schiedene »Fertigungsschritte«/Queues durch-laufen (vgl. Abb. 2). Dabei werden die Arbeitspa-kete von den freien Ressourcen nach dem Pull-Prinzip zugeordnet sowie bearbeitet und danndem nächsten Schritt zur Bearbeitung angebo-ten. In Kanban existieren weder Iterationennoch Timeboxes; anders als die bisher genann-ten Vorgehensmodelle ist Kanban nicht auf dieSoftwareentwicklung begrenzt [Anderson 2011].

3.2 Betrieb und InfrastrukturIm traditionellen Projektvorgehen sind die The-men Infrastruktur und Betrieb oft zeitlich nach-gelagert und/oder von der Softwareentwick-lung getrennt. Dies führt in der Praxis dazu,dass sich bei Betriebsübergabe und Problem-management regelmäßig Konflikte und gegen-seitige Schuldzuweisungen zwischen Entwick-lung und Betrieb ergeben (»Blame Game«) –agile Vorgehen verhalten sich hier per se ersteinmal nicht anders als traditionelle Projektvor-gehen.

Diesem Missstand soll bei dem sogenann-ten DevOps-Ansatz mit einer engen Kooperationzwischen Entwicklung und Betrieb begegnetwerden. Dies ist schon deshalb notwendig, weilagile Entwicklung beispielsweise auf eine hoheReleasehäufigkeit setzt. Gleichzeitig eröffnetder hohe Automatisierungsgrad (und die damitverbundene hohe prozessuale Stabilität) auchdem Betrieb neue Möglichkeiten, aber auch He-rausforderungen.

Im Betriebsbereich ist nun nicht der Konso-lenheld gefordert, der aufgrund hoher individu-eller Kompetenz (und nächtelanger Arbeit) dieLösung der Entwickler auf der Infrastruktur»zum Fliegen« bekommt. Gefragt ist vielmehrein ingenieurmäßiger, reproduzierbarer Ansatz,der mit hoch spezialisierten Werkzeugen in ei-nem standarisierten Prozessmodell in der Lageist, Deployments in hoher Frequenz mitkonstanter Qualität durchzuführen – derContinuous-Integration-Ansatz der Entwick-lung wird konsequenterweise um Continuous

Chancen agiler IT

12 HMD 290

Delivery bzw. Continuous Deployment ergänzt[Humble & Farley 2010]. Komplettiert wird diesdurch den »Infrastructure as Code«-Ansatz: Ana-log zur Softwareentwicklung werden Software-infrastruktur und Konfigurationen als Codedargestellt und verwaltet und entsprechendkönnen die agilen Methoden der Softwareent-wicklung angewandt werden.

3.3 IT-ServicemanagementWährend in vielen Bereichen agile Vorgehen zu-nehmend zum kanonischen Methodenreper-toire zählen, sind solche Ansätze im IT-Service-management (ITSM) noch nicht sehr verbreitet.Dies kann insbesondere darauf zurückgeführtwerden, dass die agilen Methoden aus dem Be-reich der Softwareentwicklung nur schwer aufdiese Bereiche übertragbar sind und oft zu Fehl-interpretationen führen [Wauch & Meyer 2012].

Wird demgegenüber von dem dargestelltenWertesystem ausgegangen und die spezifischeAnforderung des Prozessmanagements akzep-tiert (nämlich maximale Stabilität mit größter

Flexibilität zu verbinden), können folgende An-sätze das tradierte ITSM befruchten:

! Organisation der Anforderungen in Backlogs! Selbstorganisierte Teams statt Hierarchie ! Offenheit für Änderungen und kontinuier-

liche Selbstverbesserung! Prioritäten anhand des höchsten Kundennut-

zens setzen

Abbildung 3 zeigt auf, wie diese Prinzipien zu ei-ner funktionierenden Einheit organisiert wer-den können.

3.4 Enterprise Architecture ManagementEnterprise Architecture Management (EAM) hatsich in vielen Unternehmen als erfolgreichesWerkzeug etabliert, um widerspruchsfreie, leis-tungsfähige und weiterentwicklungsfähige IT-Architekturen auf Enterprise-Ebene zu ent-wickeln, die das viel zitierte Business-IT-Align-ment nachhaltig absichern können. Gleichzei-tig haben andere Unternehmen durchaus nega-tive Erfahrungen mit EAM gemacht:

#240 #239 #180#280

#281

#283

#179#182

#186

#190

#183

#191

#182#170

#199

#210

#211

#220

#221 #195

#284

#285

#286

Backlog Req. Analysis Development Test

In Progress Done In Progress DoneIn Progress Done

Staging Production

Abb. 2: Beispiel eines Kanban-Boards. Farben und Symbole können weitere Informationen wie Priorität, Komplexität, Business Value usw. symbolisieren. Die Pfeile zeigen illustrativ, wie einzelne Ticketsdie Queues durchwandern.