Klassisch oder agil – das ist hier die Frage!
Laut einschlägiger Studien sind agile Vorgehensweisen bei Software-Entwicklungsprojekten unaufhaltbar auf dem Vormarsch. In der Masterarbeit wird erläutert, was es mit agilen und klassischen Vorgehen auf sich hat und wann das eine dem vorgezogen werden sollte.
Zur Klärung der Frage, ob ein Software-Entwicklungsprojekt agil oder klassisch abgewickelt werden sollte, werden die beiden Ansätze erläutert. In der Folge werden zentrale Herausforderungen bei der Durchführung von Softwareprojekten aufgezeigt. Schliesslich wird ein umfassendes Modell vorgestellt, welches bei der Entscheidung für ein agiles oder klassisches Vorgehen unterstützt.
Im Rahmen der Arbeit werden eine Umfrage sowie eine Reihe Interviews mit verschiedenen Anspruchsträgern durchgeführt sowie zentrale Fragen zum Verständnis der Vor- und Nachteile klassischer und agiler Vorgehensweisen ermittelt und ausführlich ausgewertet. Zusätzlich werden mehrere gängige Studien zur Agilität analysiert, Schlussfolgerungen gezogen und in die Arbeit eingearbeitet.
Aus der Arbeit resultieren wertvolle Erkenntnisse, insbesondere auch im Bereich der kritischen Erfolgsfaktoren beim situativen Einsatz agiler Ansätze - welche Rolle spielt dabei bspw. das Commitment seitens Management und Kunden, wie sieht es mit dem Verständnis bzgl. Agilität aus. Ausserdem wird der Frage nachgegangen, warum es nach einigen Jahren gelebter Agilität immer noch keine allgemein anerkannte Definition für den Begriff Agilität existiert. Angebote und Verträge im agilen Umfeld stellen immer wieder eine Herausforderung dar - in der Arbeit wird ein adäquates Vertragsmodell vorgestellt, welches den agilen Anforderungen gerecht wird.
Ausserdem wird eine Gegenüberstellung agiler Ansätze mit dem Rational Unified Process (RUP) angestellt - das Ergebnis ist äusserst interessant.
Interessant ist auch die erstaunliche Erkenntnis einer viel beachteten internationalen Studie bzgl. Agilität, wenn die Projekterfolgsquote unter dem Aspekt der Projektgrösse genauer betrachtet wird - das muss man gelesen haben!
Abschliessend wird ein Aktionsplan erarbeitet um Agilität in das eigene Unternehmen hineinzutragen.
Inhaltsverzeichnis
Management Summary
Allgemeines
Darstellungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Ausgangslage
1.2 Problem- und Fragestellungen
1.3 Zielsetzungen und Abgrenzung
1.4 Aufbau der Arbeit
2 Theoretische Grundlagen
2.1 Evolution der Softwareentwicklung
2.1.1 Historischer Abriss
2.1.2 Herausforderungen
2.1.3 Agilität – ein potenzieller Lösungsansatz
2.2 Projektmanagement
2.3 Wasserfallmodell
2.4 Agile Softwareentwicklung
2.4.1 Agilität
2.4.2 Das Agile Manifest
2.5 Agile Vorgehensmodelle
2.5.1 Scrum
2.5.2 eXtreme Programming
2.6 Verträge für Softwareentwicklungsprojekte
2.7 Kontextmodell als Entscheidungsgrundlage für agil vs. klassisch
3 Informationserhebung
3.1 Methodisches Vorgehen zur Umfrage und den Interviews
3.1.1 Umfrage
3.1.2 Interviews
3.2 Umfrage
3.2.1 Erkenntnisse aus der XIT-Umfrage
3.3 Interviews
3.3.1 Interview Leiter Engineering
3.3.2 Interview Projektleiter
3.3.3 Interview Sales/Key Account Manager
3.3.4 Erkenntnisse aus den Interviews
4 Möglichkeiten und Grenzen von Agilität bei XIT
4.1 Reflexion zur Agilität
4.1.1 Überlegungen zum Agilen Manifest, dem agilen Gedankengut
4.1.2 Überlegungen zu den Unterschieden agiler und klassischer Vorgehen
4.1.3 Überlegungen zu den agilen Praktiken
4.1.4 Überlegungen zum Kontextmodell
4.2 XIT Kontext
4.3 Anwendung des Kontextmodells auf XIT
4.4 Abgleich XRUP mit agilen Konzepten
5 Schluss
5.1 Konklusion
5.1.1 Zielerreichung
5.1.2 Erkenntnisse
5.2 Empfehlungen und Massnahmen
5.2.1 Empfehlungen
5.2.2 Massnahmen
5.3 Weiteres Vorgehen
6 Erklärung
7 Quellen
7.1 Literatur
7.2 Studien
7.3 Interne Dokumente
8 Anhänge
8.1 Glossar
8.2 XIT Dokumente
8.2.1 (Lean) XRUP
8.3 Umfrage
8.3.1 Ergebnisse
8.4 Interviews
8.4.1 Interviewleitfaden
8.4.2 Zusammenfassung Interview Leiter Engineering
8.4.3 Zusammenfassung Interview Projektleiter
8.4.4 Zusammenfassung Interview Sales / Key Account Manager
8.5 Studien
8.5.1 CHAOS Manifesto 2013: Think Big, act Small – The Standish Group
8.5.2 7th Annual State of Agile Development Survey (Dev Survey) - VersionOne
8.5.3 Swiss Agile Study 2012 – FHNW und ZHAW
8.5.4 Agile 2013 – SwissQ
8.5.1 Kritische Würdigung
8.5.2 Einige interessante Erkenntnisse aus den Studien
Darstellungsverzeichnis
Abbildung 1: Organigramm mit strategischen Geschäftseinheiten und Sekundärstruktur
Abbildung 2: Stacey-Diagramm
Abbildung 3: Relative Fehlerkerkorrekturkosten
Abbildung 4: Trendwave agiler Lebenszyklus
Abbildung 5: Scrum in Aktion
Abbildung 6: Kontext Modell von Boehm und Turner
Abbildung 7: Übersichtsgrafik XRUP
Abbildung 8: Projekterfolgsquote 2004 bis 2012
Abbildung 9: Projekterfolgsquote Klein- und Grossprojekte 2012
Abbildung 10: Erfolgsquote Agil und Wasserfall
Abbildung 11: Projekterfolgsquote 2011 bis 2013
Abbildung 12: Vergleich Anwendung agiler vs. Wasserfall
Abbildung 13: Verwendung agiler Engineering Praktiken
Tabellenverzeichnis
Tabelle 1: Wichtige plangetriebene Konzepte
Tabelle 2: Wichtige agile Konzepte
Tabelle 3: Agile und plangetriebene Differenzierungsmerkmale
Tabelle 4: Kritische agil/plangetriebene Dimensionen
Tabelle 5: Mitarbeiter Fähigkeits- und Verständnis-Stufen nach Cockburn
Tabelle 6: Risikobasierte Entscheidungsfindung für agil oder plangetrieben
Tabelle 7: Übersicht der Umfrage mit den Fragen und deren Zweck
Tabelle 8: Interviews und Sichten
Tabelle 9: Gegenüberstellung Merkmale agiler und klassischer Vorgehensweisen
Tabelle 10: Nutzen und Grenzen agiler Praktiken
Tabelle 11: Anwendung Kontextmodell auf XIT
Tabelle 12: Abgleich XRUP mit agilen Konzepten
Tabelle 13: Umfrage-Ergebnisse zu Frage 1
Tabelle 14: Umfrage-Ergebnisse zu Frage 2
Tabelle 15: Umfrage-Ergebnisse zu Frage 3
Tabelle 16: Umfrage-Ergebnisse zu Frage 4
Tabelle 17: Umfrage-Ergebnisse zu Frage 5
Tabelle 18: Umfrage-Ergebnisse zu Frage 6
Tabelle 19: Umfrage-Ergebnisse zu Frage 7
Tabelle 20: Umfrage-Ergebnisse zu Frage 8
Tabelle 21: Umfrage-Ergebnisse zu Frage 9
Tabelle 22: Umfrage-Ergebnisse zu Frage 10
Tabelle 23: Umfrage-Ergebnisse zu Frage11
Tabelle 24: Erfolgsquote Klein- und Grossprojekte
Tabelle 25: Erfolgsfaktoren von Kleinprojekten nach Wichtigkeit gewichtet
Tabelle 26: Erfolgsquote von Kleinprojekten – Agil vs. Wasserfall
Tabelle 27: Nutzung agiler Techniken – Dev Survey
Tabelle 28: Hürden bei Einführung agiler Entwicklung – Dev Survey
Tabelle 29: Nutzung agiler Entwicklungspraktiken – Swiss Agile Study
Tabelle 30: Nutzung agiler Managementpraktiken / Erfolgsfaktoren – Swiss Agile Study
Tabelle 31: Hürden bei Einführung agiler Entwicklung – Swiss Agile Study
Tabelle 32: Hürden bei Einführung agiler Entwicklung – Agile 2013
Tabelle 33: Nutzung agiler Entwicklungspraktiken – Agile 2013
Tabelle 34: Nutzung agiler Managementpraktiken – Agile 2013
Management Summary
XIT ist ein seit 1983 im Espace Mittelland tätiges IT-Dienstleistungs-KMU mit der Kernkompetenz Software Engineering. Die Projekterfolgsrate bei Software-Entwicklungsprojekten bei XIT wird als hoch eingeschätzt – trotzdem belasten die Folgekosten misslungener Projekte die Gewinnmarge bis zu einem Viertel. In der Softwarebranche gilt Agilität als praktikabler Lösungsansatz zur Steigerung der Projekterfolgsquote und damit gleichzeitig als Mittel zur Senkung der Folgekosten. Bei XIT fehlt bislang das offizielle Commitment zur Agilität seitens Managements. Das Ziel der vorliegenden Masterarbeit besteht darin, die Entscheidungsgrundlagen dafür bereitzustellen. Weitere Teilziele hinsichtlich Agilität sind das Schaffen eines einheitlichen Verständnisses aller Mitarbeitenden, das Ausloten der Möglichkeiten und der Grenzen sowie die Ermittlung des Wissens und der Bereitschaft bei XIT und den Kunden.
Das Vorgehen in dieser Arbeit, sowie die Erkenntnisse und die Massnahmen beruhen auf Recherche, Analyse und Dokumentation einschlägiger Literatur und Studien. Eine Umfrage bei allen Mitarbeitenden, Interviews mit dem Leiter Engineering und einem Sales sowie ein Gruppeninterview mit drei Projektleitern von XIT, wurden durchgeführt und ausgewertet. Das Modell von Boehm und Turner zum Entscheid, ob in einem Projekt agil oder klassisch vorgegangen werden soll, wurde auf den Kontext von XIT angewandt. Die ermittelten Tendenzen sprechen dafür, Softwareprojekte agil abzuwickeln. Der Grad der Anwendung agiler Praktiken muss für jedes Projekt spezifisch festgelegt werden. Grundsätzlich ist festzuhalten, dass agile Entwicklungspraktiken nahezu situationsunabhängig in Softwareprojekten verwendet werden können. Die identifizierten Grenzen liegen vor allem bei den Kunden bzgl. Bereitschaft und Wissen um Agilität. Dieser Umstand beeinträchtigt den Einsatz agiler Managementpraktiken – hier sind Sensibilisierung und Wissensvermittlung notwendig.
Softwareentwicklungsprojekte unterliegen naturgemäss einer hohen Änderungsdynamik. Agile Vorgehensweisen tragen diesem Umstand Rechnung. Die Zusammenarbeit zwischen Kunden und Lieferanten sowie die regelmässige Bereitstellung lauffähiger Software mit hohem Wert, werden in den Vordergrund gestellt. Dies führt zu hoher Transparenz und steigert die Wahrscheinlichkeit, ein Projekt zum erfolgreichen Abschluss zu führen.
Aus den gewonnenen Erkenntnissen resultieren folgende Massnahmen (vgl. Kapitel 5.2):
- Managemententscheid für das Commitment zur Agilität und ggf. eine Change Initiative.
- Flächendeckender Aufbau des agilen Know-hows über alle Funktionsstufen bei XIT.
- Abstimmung der Angebots- und Vertragsgestaltung mit der Projektabwicklung.
Mit der Umsetzung der Massnahmen, wird Agilität zu einem echten Wettbewerbsvorteil für XIT und leistet einen wichtigen Beitrag zum nachhaltigen Erfolg.
Allgemeines
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
1 Einleitung
Schwaber und Shuterland (2014, S. 5) verkünden, dass agil geführte Projekte mit einer Projekterfolgsquote von 42% dreimal so erfolgreiche sind wie diejenigen, welche mittels Wasserfall abgewickelt werden. Dabei berufen sie sich auf den CHAOS-Report der Standish Group.
Aufgrund des fehlenden offiziellen Commitments zur Agilität bei XIT, liegt das Potenzial agiler Vorgehensweisen teilweise brach.
Die vorliegende Masterarbeit hat zum Ziel, einen fundierten Blick hinter die Kulissen von Agilität zu werfen. Dabei werden die Möglichkeiten und Grenzen in der Projektabwicklung ausgelotet. Die Grundlagen werden geschaffen, damit das Management von XIT die Entscheidung zum offiziellen Commitment zur Agilität fällen kann.
Die Problem- und Fragestellungen konkretisieren die Motivation für die Arbeit, wovon schliesslich die Zielsetzungen und die Abgrenzung abgeleitet werden. Der Aufbau der Arbeit schliesst die Einleitung ab.
1.1 Ausgangslage
XIT Informatik AG, in der Folge XIT genannt, ist ein seit 1983 im Espace Mitteland tätiges IT-Dienstleistungs-KMU. XIT beschäftigt heute 43 Mitarbeitende/Mitaktionäre und umfasst die Geschäftsbereiche Engineering und Consulting.
Abbildung 1: Organigramm mit strategischen Geschäftseinheiten und Sekundärstruktur
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene, erweiterte Darstellung des XIT-Organigramms
Die Ausführung von Individual-Softwareentwicklungsprojekten ist die zentrale Kernkompetenz von XIT. XIT verfügt über ein QM-System (ISO 9001) in welchem im Prozess «Kunden-Projekte» die Abwicklung von Kundenprojekten dokumentiert ist.
Seit einiger Zeit wird allgemein wie auch bei XIT der Ruf nach Agilität immer lauter. So belegen diverse Studien (Kapitel 8.5), dass Agilität offenbar ungebrochen auf dem Vormarsch ist. Selbstverständlich sind diese Studien mit Vorsicht zu geniessen – die Tendenzen sprechen jedoch für sich. Selbst PMI hat mit der ACP-Zertifizierung (Agile Certified Practitioner) die Zeichen der Zeit erkannt. Mit Hermes 5 (Agiler Leitfaden) hat die Agilität auch vor der Bundesverwaltung nicht Halt gemacht.
So ist es nicht weiter verwunderlich, dass es einem Softwareherstellungs-Unternehmen zum Wettbewerbsnachteil gereichen kann, wenn man sich nicht zur Agilität bekennt.
Anlässlich des Strategie-Workshops im Herbst 2013 wurden der CIO von Emmi und der Geschäftsführer von bmpartner eingeladen, die Erwartungen und Ziele an IT-Dienstleister zu erläutern. Beide Präsentationen führten insbesondere Agilität als kritischen Erfolgsfaktor an.
Die Ausgangslage wird zum Anlass genommen, mit der vorliegenden Arbeit einen konstruktiv-kritischen Blick hinter die Kulissen der Agilität zu werfen, um den nahezu inflationär verwendeten Begriff richtig einordnen zu können und ein gemeinsames Verständnis dafür zu schaffen. Weiter soll aufgezeigt werden, unter welchen Bedingungen Agilität situativ in Projekten bei XIT nutzendstiftend angewandt werden kann. Dazu ist eine genauere Betrachtung des Kontexts bei XIT erforderlich, welcher im Kapitel 4.1 dokumentiert ist. Schon an dieser Stelle ist absehbar, dass Agilität eine ganzheitliche Betrachtung erfordert und zur Entfaltung ihres Potenzials entsprechende Massnahmen getroffen werden müssen.
1.2 Problem- und Fragestellungen
Es ist gemeinhin bekannt, dass nach wie vor viele IT-Projekte nicht zu einem erfolgreichen Abschluss gebracht werden. Für einen IT-Dienstleister in der Softwareentwicklung ist es ausserordentlich wichtig, dass der Kunde darauf vertrauen kann, dass sein Projekt ein Erfolg wird. Die Gründe weshalb Projekte scheitern sind vielfältig, zu diesem Thema gibt es eine Reihe von Studien, die teilweise seit Jahren durchgeführt werden. Protagonisten agiler Vorgehensweisen sehen in der Agilität den Lichtblick zur Steigerung der Projekterfolgsquote, was durch die erwähnten Studien belegt wird. Wie eingangs erwähnt erhöht Agilität die Projekterfolgsquote, dieses Potenzial gilt es zu nutzen.
XIT verfügt über ein institutionalisiertes Vorgehensmodell, den XRUP (XIT RUP), einer massgeschneiderte Variante des RUP® (Rational Unified Process, von IBM). Im Rahmen der Arbeit ist es erforderlich, den XRUP mit den agilen Konzepten abzugleichen und allfällige Inkompatibilitäten sowie Lücken aufzuzeigen.
Weiter muss beachtet werden, dass jedes Projekt internen wie externen spezifischen Gegebenheiten unterliegt – dabei sind unter anderem die durch die Kunden vorgegeben Rahmenbedingungen als limitierende Faktoren zu berücksichtigen. In diesem Zusammenhang stellen die Bereitschaft sowie die Reife bzgl. Agilität massgebende Faktoren dar.
Das Ausloten der Möglichkeiten und Grenzen der Nutzung von Agilität ist von strategischem Interesse für XIT und soll helfen, den nachhaltigen Erfolg sicherzustellen.
Die Problemstellung setzt sich aus folgenden Punkten zusammen:
- Aktuell besteht bei XIT kein offizielles Commitment zur Agilität.
- Die Erfolgsquote von IT-Projekten ist nach wie vor verhältnismässig tief.
- In der Softwareentwicklungsbranche nicht agil zu sein ist ein Wettbewerbsnachteil.
- Die aktuelle Vorgehensmethodik bei XIT hat wahrscheinlich Optimierungspotenzial.
- Der Wissensstand und die Bereitschaft bzgl. Agilität bei XIT/Kunden sind unbekannt.
Die zentrale Frage welche der Masterarbeit zugrunde liegt lautet: Was steckt hinter dem «Hype» Agilität – wie kann deren Potenzial situativ in der Projektabwicklung bei XIT genutzt werden und welche Empfehlungen und Massnahmen resultieren daraus?
Die Masterarbeit soll, basierend auf der Problemstellung und der zentralen Frage, Antworten auf folgende Fragestellungen geben:
1. Was steckt im Kontext von Softwareentwicklungsprojekten konkret hinter Agilität?
2. Welche Möglichkeiten ergeben sich aus der Agilität, wo sind die Grenzen?
3. Wie steht es um die Projekterfolgsquote bei XIT?
4. Wie steht es um das Wissen und die Bereitschaft bzgl. Agilität bei XIT/Kunden?
5. Welche Empfehlungen und Massnahmen resultieren aus den Erkenntnissen?
1.3 Zielsetzungen und Abgrenzung
Nachdem die Ausgangslage bekannt ist sowie die Problem- und Fragegestellung dargelegt sind, lassen sich davon die zu erreichenden Ziele ableiten.
Das primäre Ziel der Arbeit besteht, wie der Titel der Arbeit erahnen lässt, im Ausloten der Möglichkeiten und Grenzen der Agilität in der Projektabwicklung, um das Potenzial welches Agilität in sich birgt zum nachhaltigen Erfolg von XIT zu erschliessen.
Die folgenden Ziele dienen der vorliegenden Arbeit zur Orientierung und setzen damit gleichzeitig deren Rahmen.
Die Ziele der Masterarbeit sind:
- Der Begriff Agilität zur Förderung des gemeinsamen Verständnisses ist dokumentiert.
- Agile Konzepte zur Optimierung der Projektabwicklung sind identifiziert,
- Möglichkeiten bzw. Chancen und Nutzen für XIT sind festgehalten,
- den Grenzen, bzw. limitierenden Gegebenheiten bei XIT gegenübergestellt,
- Kriterien zur situativen Anwendung in Projekten sind dokumentiert,
- mit dem XRUP abgeglichen.
- Der Reifegrad und die Bereitschaft bzgl. Agilität bei XIT sind ermittelt.
- Tendenz der Kunden-Bereitschaft bzgl. Agilität in der Projektabwicklung ist bekannt.
- Empfehlungen und Massnahmen sind definiert.
Die aus den aufgeführten Zielen resultierenden Erkenntnisse stellen die Grundlage zum Entscheid für das offizielle Commitment zur Agilität sowie deren Förderung bei XIT dar.
Agilität muss grundsätzlich die ganze Unternehmung durchdringen um das volle Potenzial, bzw. den vollen Nutzen entfalten zu können. Diese Arbeit fokussiert auf die Aspekte, welche in der Projektabwicklung zum Tragen kommen – weiterführende Punkte werden daher von der Arbeit abgegrenzt. Nicht Gegenstand der Masterarbeit sind ferner die Planung sowie die Umsetzung der Empfehlungen und der Massnahmen.
1.4 Aufbau der Arbeit
Bei der vorliegenden Masterarbeit handelt es sich um eine Praxisarbeit, die für die Arbeitgeberin des Verfassers erstellt wird. Diese gründet zum einen auf der Recherche in der einschlägigen Literatur und zum anderen auf der Analyse von Studien und Firmendokumenten sowie auf einer Umfrage und Interviews.
Im aktuellen Kapitel werden die Ausgangslage, die Problem- und Fragestellungen, die Zielsetzungen und Abgrenzungen aufgezeigt. Im Kapitel 4.2 wird die Ausgangslage mit dem betrieblichen XIT Kontext erweitert, da dieser für die Arbeit von zentraler Bedeutung ist.
Der Theorieteil (Kapitel 2.1 und 8.1) gibt einen historischen Abriss zur Softwareentwicklung, klärt den Begriff der Agilität und soll diesen greifbarer machen und zum gemeinsamen Verständnis beitragen. Zudem werden die agilen Konzepte für die Abwicklung von Softwareprojekten identifiziert und ein Kontextmodell vorgestellt, welches später als Instrument zur Entscheidungsfindung des Einsatzgrads agiler Konzepte Verwendung findet.
Die Datenerhebung umfasst eine Umfrage (Kapitel 3.1.1) und drei Interviews (Kapitel 3.1.2), welche verschiedene Sichten beleuchten. Diese dienen einerseits zur Konkretisierung des betrieblichen Kontexts von XIT und andererseits werden damit Informationen erhoben um die Möglichkeiten und Grenzen agiler Konzepte zu eruieren. Dazu werden einige interne Dokumente (Kapitel 8.2) verwendet. Es gibt eine Reihe von Studien (Kapitel 8.5) zum Thema Agilität; diese werden an den entsprechend Stellen in die Überlegungen miteinbezogen.
Die Informationen aus den Datenerhebungen werden im Rahmen der Anwendung der theoretischen Grundlagen analysiert und fliessen in die Betrachtung der Möglichkeiten und Grenzen von Agilität bei XIT (Kapitel 4) ein. Bei der Reflexion zur Agilität werden Schlussfolgerungen zum Agilen Manifest, zu den Unterschieden agiler und klassischer Vorgehen, zu den agilen Praktiken sowie dem Kontextmodell gezogen und dabei die Möglichkeiten und Grenzen der Agilität ausgelotet. Inwiefern für XIT eher eine agile oder eine klassische Vorgehensweise zu empfehlen ist, wird mit der Anwendung des Kontextmodells eruiert. Schliesslich werden die agilen Werte und Prinzipien dem institutionalisierten Vorgehensmodell bei XIT – dem XRUP – gegenübergestellt und allfällige Inkompatibilitäten aufgezeigt.
Im Schluss-Kapitel (5) werden aus den Konklusionen und den Erkenntnissen aus der Arbeit Empfehlungen und Massnahmen vorgeschlagen.
2 Theoretische Grundlagen
« Wenn über das Grundsätzliche keine Einigkeit besteht, ist es sinnlos, miteinander Pläne zu schmieden. » Konfuzius
Die Theorie beginnt mit der Evolution der Softwareentwicklung und setzt damit den Kontext für die Herausforderungen bei der Durchführung von Softwareentwicklungsprojekten mit klassischen Vorgehensweisen. Da Softwareentwicklung im Rahmen von Projektmanagement stattfindet, wird dieses kurz umrissen. In der Folge wird das Wasserfallmodell vorgestellt, da Agilität sozusagen die Antwort auf dessen Unzulänglichkeiten darstellt. In der Arbeit geht es um die agile Softwareentwicklung, dazu ist es naheliegend, den Begriff der Agilität zu klären und aufzuzeigen, wie dieser mit dem Agilen Manifest geprägt worden ist. Im Anschluss werden XP und Scrum – zwei populäre agile Vorgehensmodelle – vorgestellt. Einige wesentliche Begriffe werden im Glossar (Anhang 8.1) erläutert.
Das Kapitel schliesst mit dem Kontextmodell von Boehm und Turner. Dieses kann zur Evaluation des Einsatzes agiler oder traditioneller Methoden bei Softwareentwicklungsprojekten herangezogen werden.
Welche Schlüsse einschlägige Studien bzgl. Agilität ziehen, wurde im Anhang 8.5 analysiert und die wichtigsten Erkenntnisse im Kapitel 8.5.2 festgehalten.
2.1 Evolution der Softwareentwicklung
Softwareentwicklung ist eine vergleichsweise junge Domäne welche sich anfänglich an bewährten Techniken aus dem Ingenieur-Bereich orientiert hat. Diese Vorgehensweisen haben sich leider zur Erstellung von Software als eher ungeeignet herausgestellt. Für die vorliegende Arbeit ist es wichtig, die Evolution der Softwareentwicklung aufzuzeigen und die Hintergründe und den Stellenwert agiler Praktiken zu verstehen.
2.1.1 Historischer Abriss
Als in den sechziger Jahren das erste Mal die Kosten der Software höher waren als diejenigen für die Hardware und zudem eine ganze Reihe grosser Projekte scheiterten, nahm die Softwarekrise ihren Anfang. Dieses Problem wurde 1968 anlässlich einer NATO-Tagung in Garmisch-Partenkirchen in einem Gremium von Wissenschaftlern und Praktikern eingehend diskutiert und dabei der Begriff «Software Engineering» geprägt. Die zentrale Ursache für die Krise wurde damit begründet, dass die bisherigen Techniken mit der gestiegenen Komplexität der Software nicht Schritt halten konnten. Der Auftrag bestand darin – als Antwort auf die Softwarekrise – ein ingenieurmässiges Vorgehen zur System-, bzw. Softwareentwicklung zu definieren. Selbstverständlich gibt es neben der schwierigen Bewältigung der Komplexität noch weitere Ursachen für die Softwarekrise wie bspw. der oft ungenügende Einbezug der Benutzer (vgl. http://de.wikipedia.org/wiki/Softwarekrise).
In der Folge wurden einige Vorgehensweisen und Methoden entwickelt, welche die Problematik lösen sollte – mit mehr oder weniger grossem Erfolg. Die Entwicklung in den nächsten Jahren war einfach zusammengefasst wie folgt: Ein noch heute weitverbreitetes Modell wurde von Royce (1970) veröffentlicht. Es wurde bekannt als das berühmt-berüchtigte Wasserfallmodell[1]. Ein von Royce als unzulänglich bezeichnetes einfaches Modell wurde, ungeachtet der Warnungen, vom US-Militär als Basis für den Standard DoD-STD-2167 verwendet. Hier wurde auch der Begriff Wasserfallmodell geprägt. Der STD-2167 wurde zur Basis für andere Vorgehensmodelle wie das V-Modell, welches wiederum als Grundlage für das primär in der Bundesverwaltung verwendete Vorgehensmodell Hermes Verwendung fand. Das Wasserfallmodell verbreitete sich in den 1980er- bis 1990er-Jahren wie ein Lauffeuer und wurde in der IT zum Quasistandard. Neben dem breit angewandten Wasserfallmodell hatte Royce allerdings auch ein iteratives Modell vorgeschlagen. Dieses wurde bspw. von IBM von 1977 bis 1980 für die Erstellung der Software für das NASA Space-Shuttle eingesetzt. Die Software wurde über 31 Monate in 17 Iterationen erfolgreich entwickelt. Dieser iterative Ansatz bekundete jedoch Mühe sich durchzusetzen. Barry Boehm publizierte 1985 das iterativ/inkrementelle Spiralmodell – dieses fand zwar weithin Beachtung – allerdings war damit auch nicht gegen das Wasserfallmodell anzukommen. Seit den 1990er-Jahren wurden eine ganze Reihe von Varianten iterativer Vorgehensmodelle entwickelt – unter den bekanntesten finden sich zum Beispiel Extreme Programming (XP) oder das heute sehr populäre Scrum (vgl. Oestereich und Weiss 2008, S. 12, f.).
Mit dem Agilen Manifest (vgl. Kapitel 2.4.2), welches 2001 formuliert worden ist, brach schliesslich die agile Ära an.
2.1.2 Herausforderungen
Einige der wesentlichen Herausforderungen im Rahmen von Softwareentwicklungsprojekten können mit folgenden Gesetzen und Lemmas, die von DeGrace und Hulet Stahl (1990) gesammelt und publiziert worden sind, zusammengefasst werden:
- Humphrey’s Law [2]: Benutzer wissen nicht was sie wollen bis sie die Software in Aktion sehen.
- Ziv’s Law: Softwareentwicklung ist unvorhersehbar und Anforderungen und Spezifikationen werden nie vollständig verstanden – je neuartiger das zu entwickelnde System, desto mehr trifft dies zu.
- Conway’s Law: Software reflektiert die Kommunikationsstruktur des Entwicklungsteams. Für die Definition der Schnittstellen zwischen getrennten Softwaremodulen ist zwischenmenschliche Kommunikation notwendig.
- Wegner’s Lemma: Ein (komplexes) interaktives System kann weder komplett spezifiziert noch vollständig getestet werden.
- Langdon’s Lemma: Je chaotischer, bzw. dynamischer das Umfeld, desto schneller entwickelt, bzw. verändert sich Software.
Schwaber und Shuterland (2014, S. 9 ff.) sehen die Ursache für fehlgeschlagene Softwareprojekte in der Verwendung klassischer, vorhersagender Softwareentwicklungsprozesse bzw. dem Wasserfallmodell. Vorhersagende Prozesse hängen von der Genauigkeit des Projektplans und seiner Einhaltung ab, diese werden oft auch als plangetriebene Vorgehen bezeichnet.
Der Erfolg eines plangetriebenen Vorgehens hängt mitunter von folgenden Faktoren ab:
- Anforderungen dürfen sich nicht ändern. In der Realität ändern sich über 35% der Anforderungen in einem typischen Softwareentwicklungsprojekt. Diese Änderungen resultieren bspw. aus Gründen der Marktdynamik, des Unverständnisses des wirklich Benötigten, sowie der Illusion, künftige System vollständig antizipieren und beschreiben zu können.
- Technologie, die beherrscht wird, welche die Anforderungen unterstützt und stabil ist.
- Mitarbeiter, welche die notwendigen Skills mitbringen und mit genug Kapazität zum richtigen Zeitpunkt verfügbar sind sowie zuverlässige, konstant gute Leistungen erbringen.
Vorhersagende, plangetriebene Vorgehensmodelle sind demnach gut geeignet für Vorhaben. Diese weisen klare, sich kaum ändernde Anforderungen auf, setzen bekannte und bewährte Technologien und Fachleute stehen in ausreichender Kapazität zur Verfügung. Sie sind eher schlecht geeignet für Projekte die mit Unbekanntem und Unerwartetem konfrontiert werden, was auf die Mehrzahl von Softwareentwicklungsprojekten zutrifft.
Lange wurde versucht den Unzulänglichkeiten der klassischen Vorgehensweise mit optimierter Planung entgegenzuwirken. Es wurde sehr viel Zeit in die Anforderungsanalyse und Spezifikation investiert, bevor die Umsetzung startete. Das würde wohl den erwarteten Erfolg bringen, wäre da nicht der Umstand, dass sich die Dinge fortwährend ändern. Diesen Problemen ist mit voraussagenden Prozessen kaum beizukommen. Aus dem Stacey-Diagramm lässt sich ableiten, dass man es bei Softwareentwicklungsprojekten mit Komplexität zu tun hat. Die Anforderungen sind häufig unklar und unterliegen analog zu den verwendeten Technologien in der Softwareindustrie, einer grossen Dynamik.
Abbildung 2: Stacey-Diagramm
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Schwaber und Shuterland (2014, S. 11)
Der Faktor Mensch kann, vorausgesetzt es handelt sich um ein überschaubares eingespieltes Team, bekannt und zuverlässig stabil sein. Mit zunehmender Teamgrösse wird auch dieser Faktor unsicherer und unterliegt zudem vielfältigen anderen Gesetzmässigkeiten, welche schwer steuerbar, bzw. beeinflussbar sind. Dabei ist an dieser Stelle die Fachkompetenz im Gegensatz zur Sozialkompetenz verhältnismässig einfach in den Griff zu bekommen.
Huber et al. (2011, S. 28 f.) identifizieren ebenfalls eine stetig zunehmende Komplexität der Projekte als Ursache für die nach wie vor tiefe Projekterfolgsquote. Hier wird der Zusammenhang mit dem Faktor Mensch und damit die künftig zunehmende Bedeutung der «Soft Factors» zur Steigerung der Erfolgsquote augenscheinlich. Demnach sind Kommunikation, personelle Kontinuität, Erfahrung, Wissen und Können, Konfliktmanagement, Kreativität, Motivation und partnerschaftliche Zusammenarbeit von zentraler Wichtigkeit.
2.1.3 Agilität – ein potenzieller Lösungsansatz
In den vorgängigen Abschnitten wurden einige Aspekte der Problematik bei der Durchführung von Softwareentwicklungsprojekten dargelegt. Eine potenzielle Antwort darauf besteht in der Anwendung agiler Praktiken. Diese basieren im Gegensatz zu einem vorhersagenden, plangetriebenen Vorgehen auf einem empirischen Prozess.
Schwaber und Shuterland (2014, S. 17 ff.) erläutern, wie bei Scrum die Anwendung eines empirischen Prozesses eingesetzt wird: Informationen werden durch Beobachtung statt durch Vorhersagen gewonnen. Diese sind insbesondere bei komplexen Problemen geeignet, bei denen man es zumindest am Anfang mit unknown unkowns (unbekannten Unbekannten – Dingen, von denen man (noch) nicht weiss, dass man sie nicht weiss) zu tun hat. Folgende Vorbedingungen sind für einen empirischen Prozess unabdingbar:
- Inspektion und Adaption – die spezifische Situation muss immer wieder analysiert werden – basierend auf den gewonnenen Erkenntnissen kann eine Anpassung erfolgen. Je grösser die Unsicherheit, desto häufiger sollte dies gemacht werden – je früher bemerkt wird, dass vom optimalen Pfad abgewichen wird, desto einfacher und günstiger ist es, auf den richtigen Pfad zurückzufinden.
- Transparenz – basierend auf einer Vision werden Eigenschaften und Funktionalitäten zu deren Erreichung beschrieben. Diese werden nach ihrem Wert für das Unternehmen bewertet, in absteigender Reihenfolge umgesetzt und regelmässig inspiziert. Dieses iterative Vorgehen sorgt durch die Inspektion der umgesetzten Funktionalität für Transparenz und ermöglicht die laufende Adaption basierend auf den gewonnen Erkenntnissen.
Agilität ist selbstverständlich nicht der alleinige allheilbringende Lösungsansatz. Von zentraler Bedeutung sind, wie bereits oben erwähnt die Soft Factors, das gemeinsame Verständnis der Anforderungen sowie die passende Kommunikation als Grundvoraussetzung. Die agile Denkweise hilft in erster Linie bzgl. der erwähnten Problematik im Bereich sich ändernder Anforderungen. Betrachtet man die Voraussetzungen für empirische Prozesse fällt auf, dass der Ansatz Inspektion und Adaption auf dem seit langem bekannten Deming-Kreis (auch bekannt als PDCA-Cyle, vgl. http://de.wikipedia.org/wiki/Demingkreis) basiert, welcher unter anderem auch im PMBOK® Guide (PMI 2013 A) Verwendung findet.
2.2 Projektmanagement
Der Begriff «Projektmanagement» wird häufig unbewusst mit der vollumfänglichen Durchführung eines Projekts gleichgesetzt. Projektmanagement ist allerdings lediglich ein Teil der Projektdurchführung. Aus diesem Grund wurde im Titel der Masterarbeit bewusst der Begriff «Projektabwicklung» gewählt.
PMI (2013a, S. 3) definiert ein Projekt folgendermassen: «A project is temporary endeavour undertaken to create a unique product, service or result.» Demnach ist ein Projekt ein temporäres Unterfangen um ein einmaliges Produkt, eine Dienstleistung oder ein Resultat zu erstellen. Weiter wird zwischen Projektmanagement Prozessen und Produkt-orientierten Prozessen unterschieden. Erstere stellen den effektiven Ablauf des Projekts während des Lebenszyklus sicher. Letztere gewährleisten die Spezifikation und die Erstellung des einmaligen Produkts, bzw. der Dienstleistung oder des Ergebnisses (PMI, 2013a, S. 47).
Huber et al. (2011, S. 31 f.) machen die Differenzierung ebenfalls. Sie gehen jedoch noch einen Schritt weiter und fügen dem Projektmanagement und der Produktentwicklung den sozialen Prozess hinzu. Dieser soziale Prozess ist zur Steigerung der Erfolgsrate komplexer Projekte von zentraler Bedeutung und widerspiegelt sich in den Soft Factors. Es geht insbesondere darum, dass alle Projektbeteiligten ihr Handeln an den Projektzielen orientieren. Dabei spielt die Kommunikation – und damit die Zusammenarbeit – eine wesentliche Rolle, um die richtigen Entscheidungen zu fällen. Zur erfolgsversprechenden Projektführung steht die integrale Steuerung der Produktentwicklung mit der inhaltlichen Projektarbeit im Zentrum und wird durch das Projektmanagement und den sozialen Prozess unterstützt.
2.3 Wasserfallmodell
Agilität kann als Antwort auf die vermeintlichen Unzulänglichkeiten des Wasserfallmodells (vgl. Ausführungen Kapitel 2.1.1 Historischer Abriss) verstanden werden. Je nach Anwendungsgebiet passt dass Wasserfallmodell sehr gut. Allerdings – und da ist sich die Softwareentwicklungsgemeinde mittlerweile nahezu ausnahmslos einig – nicht zwingend für die Softwareentwicklung. Je innovativer, komplexer und umfangreicher ein Softwareprojekt ist, desto weniger eignet sich das Vorgehen nach Wasserfall.
Boehm und Turner (2004, S. 9 f., 12 f.) beschreiben die traditionelle Art (Wasserfallmodell) um Software zu entwickeln, als plangetrieben. Diese klassische Herangehensweise wurde von den Ingenieursdisziplinen und dem Qualitätsmanagement, z. B. von der Entwicklung umfangreicher Weltraumfahrtprojekte, übernommen. Dies war zu dieser Zeit naheliegend. Sie haben folgende plangetriebenen Konzepte identifiziert:
Tabelle 1: Wichtige plangetriebene Konzepte
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Boehm und Turner (2004, S. 12 f.)
Larman (2005, S. 58 ff.) beschreibt das Wasserfallvorgehen treffen. Bei dem sequentiellen Lebenszyklus wird versucht, vor der Programmierung alle oder zumindest die meisten Anforderungen detailliert festzuhalten und in einem gründlichen Entwurf zu dokumentieren. Weiter besteht der Anspruch, dass bereits zu Beginn des Projekts eine zuverlässige Ablauf- und Zeitplanung erstellt wird. Dies führte in der Vergangenheit zu hohen Projektmisserfolgs- und Fehlerraten sowie geringer Produktivität. Zudem wichen die Schätzungen und die Planung bis zu 400% von den Ist-Daten ab. Wichtig ist auch die Erkenntnis, dass bei der Anwendung eines solchen vorhersagenden Vorgehens über 45% der realisierten Funktionalität überhaupt nicht verwendet wird. Damit jedoch nicht genug – es ist ein grosser Irrtum bei der Softwareentwicklung zu glauben, dass Spezifikationen, welche auf anfänglich erhobenen Anforderungen basieren, unverändert bleiben. Gemäss Studien von Boehm und Papaccio[3] aus dem Jahr 1988 und von Jones (1997) resultiert, dass sich je nach Projektumfang die Anforderungsänderungsrate von 25% bis zu 50% erstreckt. Anders ausgedrückt muss mit einer durchschnittlichen monatlichen Änderungsrate von ca. 2% gerechnet werden. Damit wird klar, dass Softwareentwicklungsprojekte einem starken Wandel und grosser Instabilität unterworfen sind. Dies macht wiederum nachvollziehbar, dass es wenig sinnvoll ist, Anforderungen für Softwareprojekte vollständig und detailliert am Anfang zu definieren.
Im Zusammenhang mit sich ändernden Anforderungen ist die Betrachtung der Fehler- bzw. Defektbehebungskosten interessant. Es lässt erahnen, dass sich ändernde Anforderungen bei späterer Korrektur entsprechende Kostenfolgen nach sich ziehen.
Abbildung 3: Relative Fehlerkerkorrekturkosten
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Pressmann (2001, S. 198)
Die Grafik[4] von Pressman (2001, S. 198) zeigt auf, zu welchem Zeitpunkt die Behebung eines Fehlers wie viele Kosten verursacht. Wird der Fehler während der Erhebung der Anforderungen entdeckt, kommt dessen Behebung am günstigsten zu stehen. Am teuersten wird es, wenn die Software bereits im Betrieb ist. Legt man das auf die Kosten um, so kostet die Behebung eines bestimmten Fehlers am Anfang z. B. CHF 100.- – bei Entdeckung während der Entwicklungstests kommt die Korrektur bereits zwischen CHF 1‘500.- und 4‘000.- zu stehen. Die Grafik zeigt eindrücklich auf, dass je später ein Fehler aufgedeckt wird, desto teurer dessen Behebung wird. Es wird deutlich, dass hier nicht die Rede von Programmierfehlern sondern von konzeptionellen Fehlern aufgrund vorhersagender Anforderungen und Planung ist.
Erstaunlicherweise konstatiert das CHAOS Manifesto (The Standish Group, 2013, vgl. Kapitel 8.5.1), dass – undifferenziert nach agiler Vorgehensweise oder Wasserfall – lediglich 20% der Funktionen oft, 50% selten bis nie und der Graubereich von 30% gelegentlich genutzt werden. Hier wäre es interessant zu sehen, wie die Funktions-Nutzung zwischen den beiden konkurrierenden Vorgehen aussieht. Bei den 30% muss gesagt werden, dass es immer gewisse Funktionen gibt, die nur selten verwendet werden aber trotzdem zur Verfügung stehen müssen. In einem Buchhaltungssystem wird bspw. der Jahresabschluss in der Regel einmal im Jahr gemacht, was aber nicht bedeutet, dass man auf diese Funktionalität hätte verzichten sollen. Bei selten genutzten Funktionen kann man sich allerdings über die Umsetzung Gedanken machen – man kann diese ggf. weniger aufwändig gestalten und auf Luxus verzichten. Bei Betrachtung der Funktionalitätsnutzung sind primär die gar nicht verwendeten Funktionalitäten relevant.
Die Gegebenheiten sind zu komplex, um im Vornherein die Anforderungen an eine Software vollständig und widerspruchsfrei zu definieren. Dies impliziert, dass eine voraussagende, detaillierte Planung mit genauen Kostenprognosen ein schwieriges Unterfangen darstellt. Eine andere Herangehensweise erscheint notwendig. Die sich in den letzten Jahren herauskristallisierende Antwort scheint, zumindest teilweise in der Anwendung agiler Methoden, gefunden. Insbesondere das iterativ/inkrementelle Vorgehen sowie das zeitnah Feedback zur bereitgestellten Funktionalität, stellen Schlüsselerfolgsfaktoren dar.
2.4 Agile Softwareentwicklung
Der Begriff Agilität ist relativ schwer greifbar, so ist es nicht weiter verwunderlich, dass im Kontext der Softwareentwicklung keine allseits akzeptierte Definition existiert. Agilität wird einerseits anhand des Agilen Manifests (vgl. Kapitel 2.4.2) und andererseits mit agiler Softwareentwicklung umschrieben. Boehm und Turner (2004, S. 18 f.) haben folgende wichtigen agile Konzepte identifiziert:
Tabelle 2: Wichtige agile Konzepte
Abbildung in dieser Leseprobe nicht enthalten[5]
Quelle: Boehm und Turner (2004, S. 18 f.)
In der Folge wird aufgezeigt, wie der Begriff der Agilität entstanden ist. Das Agile Manifest erläutert, was das Wesen von Agilität ausmacht.
2.4.1 Agilität
Agilität[6] ist der Kern bei der agilen Softwareentwicklung, agil, lat. agilis: flink, beweglich. Das Ziel besteht darin, den Softwareentwicklungsprozess flexibler und schlanker zu gestalten, als dies bei klassischen, schwergewichtigen Vorgehensmodellen üblich ist.
Agilität wird von Schwaber und Shuterland (2014, S. 32) folgendermassen beschrieben: «Agilität ist die Fähigkeit, Vorteile aus Chancen zu ziehen oder Herausforderungen mit beherrschbarem Risiko zu meistern.» Diese Definition ist etwas abstrakt und lässt relativ schwer erkennen, was sich hinter Agilität verbirgt.
Etwas mehr Licht ins Dunkel bringt Cockburn[7] (2003, S. 281). Er erzählt, dass der Begriff agil im Rahmen eines Treffens von siebzehn Befürwortern leichtgewichtiger Entwicklungsprozesse im Februar 2001 in Snowbird, Utah, im gemeinsamen Konsens gewählt wurde. Die Teilnehmer einigten sich bei der Formulierung des Agilen Manifests darauf, anstelle des Begriffs «leichtgewichtig» auf den Begriff «agil». Dafür sprach einerseits, dass leichtgewichtig eher eine Abneigung gegen etwas als Vertrauen in etwas vermittle. Andererseits solle der Begriff agil zum Ausdruck bringen, dass in Softwareentwicklungsprojekten das Reagieren auf sich ändernder Anforderungen essentiell ist.
Cockburn (2003, S. 233 ff.) beschreibt agil als die Fähigkeit effektiv und manövrierbar zu sein und dass ein agiles Verfahren sowohl leicht als ausreichend sein soll. Mit seinem Vergleich mit «sweet spot» (idealer Punkt beim Schlagen eines Golfballs), dem Streben nach dem Erreichen der optimalen Konstellation zur Durchführung eines Softwareentwicklungsprojekts, führt er folgende fünf Aspekte ins Feld:
- Zwei bis acht Leute in einem Raum – dient der einfachen und schnellen Kommunikation.
- Anwendungsexperten vor Ort – gewährleistet kürzesten Weg zur Klärung von Fragen.
- Einmonatige Inkremente – eignen sich perfekt für ein schnelles Feedback zum Produkt und für den Entwicklungsprozess sowie für deren Reparatur bzw. Verbesserung.
- Vollautomatische Regressionstests – bieten den Vorteil, dass Code revidiert und per Knopfdruck erneut getestet werden kann, was schliesslich zu besserer Qualität führt.
- Erfahrene Entwickler – hat naheliegender Weise bessere Ergebnisse zur Folge, insbesondere sind solche Teams zwei- bis zehnmal effektiver als Teams mit gemischt erfahrenen Entwicklern; damit lassen sich die Kosten sowie die Teamgrösse reduzieren.
Agilität ist, wie die obigen Ausführungen zeigen, schwer greifbar und es gibt keine ultimative Definition dafür. Das hat Jeff Shuterland in seinem Scrum Log[8] im Januar 2014 ebenfalls konstatiert. Aus diesem Grund hat er kurzerhand die Community aufgerufen eine Definition für Agilität mittels Twitter vorzuschlagen, worauf er die beste davon eine Woche später prämiert hat. Sehr gut gefallen hat ihm die Definition von Martin Fowler: «(People-first > process-first) + (Adaptive planning > predictive planning)». Am besten hat ihm diejenige in Form des Akronyms «AGILE»[9] gefallen: « A ctively G ain I mprovements L earning E veryday».
In der einschlägigen Literatur wird Agilität in der Regel anhand des Agilen Manifests erläutert – das soll hier nicht anders sein.
2.4.2 Das Agile Manifest
«Erkannte und eingestandene Irrtümer waren schon immer die beste Grundlage für neue Einsichten.» Günter Grass
Mit dem Agilen Manifest[10] wurde der Grundstein für die agile Bewegung gelegt. In der Folge werden die Werte und die Prinzipien basierend auf den Erläuterungen von Cockburn (2003, S. 283 ff.) aufgezeigt.
Die erklärte Absicht des Manifests besteht darin durch die eigene Entwicklung von Software anderen dabei zu helfen, bessere Wege für die Softwareentwicklung zu erschliessen. Dies wird erreicht, indem vier zentrale Wertepaare gegeneinander abgewogen und zwölf Prinzipien formuliert wurden. Die Werte und Prinzipien sollen den Beteiligten an Softwareentwicklungsprojekten zur Orientierung dienen – in diesem Sinn sind die Werte als Leitsätze und die Prinzipien als unterstützende Aussagen zu verstehen.
Bei der Interpretation der Kernwerte ist wichtig zu erwähnen, dass die kursiven Punkte rechts geschätzt, jedoch die fetten Punkte links als wichtiger eingestuft werden.
Das Agile Manifest basiert auf den nachfolgend beschriebenen vier Wertepaaren.
- « Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.»
Grundsätzlich braucht es eine Verfahrensbeschreibung und Werkzeuge, allerdings sind die richtigen Mitarbeitenden (Lieferant und Auftraggeber) und deren Austausch untereinander durch nichts zu ersetzten. So wird ein undokumentiertes Verfahren mit guten Interaktionen einem dokumentierten Verfahren mit schlechten Interaktionen vorgezogen.
- « Funktionierende Software ist wichtiger als umfassende Dokumentation.»
Nur anhand eines funktionierenden Systems kann festgestellt und aufgezeigt werden, was das Team erarbeitet hat und was aus den gemeinsamen Anstrengungen entstanden ist. Dokumente sind durchaus nützlich, sollten jedoch beim Stand gerade ausreichend belassen werden.
- « Zusammenarbeit mit Kunden ist wichtiger als Vertragsverhandlungen.»
In der agilen Entwicklung sollte es kein «wir» und «ihr» sondern nur ein «uns» geben. Dabei geht es um Freundlichkeit, gemeinsame Entscheidungen, Schnelligkeit der Kommunikation und deren Verbindungen zu den Interaktionen des Individuums. Die Wichtigkeit von Verträgen darf nicht unterschätzt werden – diese kommen spätestens dann zum Tragen, wenn Unstimmigkeiten zwischen den Parteien hervortreten.
- « Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen.»
Es ist sinnvoll einen Plan zu haben – der Plan sollte jedoch nicht im Detail am Anfang ausgearbeitet und dann ohne weiter nachzudenken befolgt werden. Der Plan soll regelmässig revidiert und neu priorisiert werden – sich an einem überholten Plan zu orientieren ergibt keinen Sinn, bzw. ist kontraproduktiv.
Die nachfolgenden zwölf agilen Prinzipien haben zum Ziel, die vier vorgängig vorgestellten Werte zu präzisieren.
1. «Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.» Frühe, regelmässige, in kurzen Zyklen erfolgende Lieferungen bringen Geschäftsnutzen und frühes Feedback zum entstehenden System, zum Team und zum Verfahren.
2. «Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.» Das iterativ/inkrementelle Vorgehen erlaubt Anforderungsänderungen zum richtigen Zeitpunkt zu entdecken und in die Software einfliessen zu lassen.
3. «Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monaten und bevorzuge dabei die kürzere Zeitspanne.» Die Erfahrungen der letzten Jahre zeigen, dass eine optimale Iterationslänge zwei bis vier Wochen beträgt.
4. «Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.» Studien belegen, dass es eine starke Korrelation zwischen guter Zusammenarbeit der Fachexperten mit dem Entwicklungsteam und dem Projeterfolg bzw. -misserfolg gibt.
5. «Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.» Die einzelnen Mitarbeitenden machen das Projekt erst möglich – ihre Motivation hängt von ihrem Stolz auf die eigene Arbeit und der Gemeinschaft im Projekt ab.
6. «Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.»
Der gut funktionierenden Kommunikation wird immer ein höherer Stellenwert beigemessen – Kommunikation ist das A und O – ohne diese kann kein Projekt funktionieren.
7. «Funktionierende Software ist das wichtigste Fortschrittsmass.»
Auf funktionierender Software kann man sich, im Gegensatz zu Dokumentation, zur Beurteilung des Fortschritts verlassen.
8. «Agile Prozesse fördern nachhaltige Entwicklung. Auftraggeber, Entwickler und Benutzer sollten ein gleichmässiges Tempo auf unbegrenzte Zeit halten können.»
Hier geht es um Effektivität – das Projektteam sollte keine Überstunden machen, ansonsten leiden, ausser den Mitarbeitenden, auch die Qualität und der Projektfortschritt darunter.
9. «Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.»
Ein gut gekapseltes Design kann relativ einfach geändert werden, was ein Gewinn an Agilität für das Projekt ergibt. Wird das Design nicht regelmässig reflektiert und verbessert, entstehen mit der Zeit sogenannte technische Schulden. Diese äussern sich in Mehraufwand – je später diese in Angriff genommen werden, desto teurer kommt deren Behebung zu stehen.
10. «Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.»
Einfachheit erhöht die Verständlichkeit und war bereits eine Prämisse von Einstein. Wenn etwas einfach realisiert wurde, kann eine Änderung in der Regel einfacher umgesetzt werden – allerdings ist es zunächst schwieriger etwas einfach zu gestalten als kompliziert.
11. «Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.»
Selbstorganisation ist ein zentraler Aspekt der Agilität – damit werden Entscheidungen gemeinsam gefällt und die Verantwortung und der Erfolg auf alle Schultern verteilt. Die Architektur darf sich im Übrigen, ähnlich wie Anforderungen, verändern.
12. «In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.»
Bei der Reflexion werden regelmässig verschiedene Aspekte im Team beleuchtet damit es sich verbessern kann. Dazu gehören insbesondere die Effektivität und Effizienz des Vorgehens sowie die Überprüfung des Wissensstands, um allfällige Lücken aufzudecken und Massnahmen zur Optimierung festzulegen.
2.5 Agile Vorgehensmodelle
Seit der Entstehung des Agilen Manifest 2001 wird eine ganze Reihe von Vorgehensmodellen, welche grösstenteils bereits vorher existierten, als agil bezeichnet. Die folgende Trendwelle gibt Aufschluss darüber, welche in der Praxis eingesetzten Vorgehensmodelle im Lebenszyklus wo stehen:
Abbildung 4: Trendwave agiler Lebenszyklus
Abbildung in dieser Leseprobe nicht enthaltenQuelle: Agile 2013
Unter «Introduction» sind die Vorgehen zu verstehen, bei welchen noch nicht feststeht, ob sich diese durchsetzen werden. Im «Growth» sind die aufkommenden Themen zu finden. In der «Maturity» sind Vorgehen enthalten, welche definitiv in den Unternehmen angekommen sind und im «Decline» werden die Vorgehen aufgeführt, welche bereits umgesetzt wurden und im Begriff sind obsolet zu werden.
In diesem Kapitel werden zwei populäre agile Vorgehensmodelle mit Fokus auf ihre agilen Elemente vorgestellt.
2.5.1 Scrum
Scrum ist aktuell mit 85.7% (gemäss Agile 2013) die am häufigsten eingesetzte agile Vorgehensweise. Im Scrum Log[11] von Jeff Shuterland kann die Entstehungsgeschichte von Scrum nachgelesen werden: Scrum wurde 1993 von Jeff Shuterland und Ken Schwaber entwickelt und 1995 an der OOPSLA[12] vorgestellt. Die Entstehung von Scrum wurde vom Artikel «The New Product Development Game»[13] von Takeuchi und Nonaka inspiriert, in welchem für die Produktentwicklung Bezug auf Rugby genommen wurde.
Die Komponenten und der Prozess von Scrum sind in Abbildung 5 übersichtlich visualisiert.
Abbildung 5: Scrum in Aktion
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Schwaber und Shuterland (2014, S. 61)
[...]
[1] Das Modell zeigt die Phasen kaskadierend, was an einen Wasserfall erinnert – daher der Name
[2] Auch bekannt als IKIWISI – I’ll Know It When I See It
[3] 1988, Understanding and controlling software cost. IEEE Transactions on Software Engineering
[4] Basisdaten für die Grafik stammen von Barry Boehm et al.
[5] «You Aren’t Going to Need It», bzw. «You Ain’t Gonna Need It»
[6] Vgl. http://de.wikipedia.org/wiki/Agile_Softwareentwicklung - aufgerufen am 29.01.2014
[7] Alistair Cockburn war an der Entstehung des Agilen Manifests 2001 beteiligt
[8] http://scrum.jeffsutherland.com/ - aufgerufen am 01.02.2014
[9] von Francesco Attanasio aus Italien
[10] http://agilemanifesto.org/iso/de/ - aufgerufen am 31.01.2014
[11] http://scrum.jeffsutherland.com/2005/03/scrum-godfathers-takeuchi-and-nonaka.html - aufgerufen am 01.02.2014
[12] OOPSLA: Object-Oriented Programming, Systems, Languages & Applications (1995: Austin, Texas)
[13] http://hbr.org/1986/01/the-new-new-product-development-game/ar/1 - aufgerufen am 01.02.2014
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.