On-site Customer

Agile Methoden zur Softwareentwicklung
� Ausgangssituation
� Sinn und Zweck von Vorgehensmodellen
� Alte Vorgehensmodelle – Grenzen
� Agile Softwareentwicklung, agile Werte, agile Prinzipien agile
Methoden, agile Prozesse
� Scrum
� XP ( eXtreme Programming)

Vorgehensmodelle - Ausgangssituation
� Anwendungsentwicklung benötigt unter
industriellen Bedingungen einen organisatorischen
Rahmen
---> ein Vorgehensmodell bzw. Prozessmodell
� Markt bietet generische Modelle an, die als Schablonen
oder Baukästen zur Erstellung eigener, an
das jeweilige Projekt angepasster, Prozessleitfäden
dient
� Einsatz zur Absicherung des Projektmanagements

Sinn und Zweck von Vorgehensmodellen
� Rahmen der Systementwicklung
� Definiert Rollen und Aktivitäten
� Reihenfolge der Bearbeitung
� Artefakte
� Ziel ist die Sicherstellung des Systems durch gut durchdachte
Systementwicklung
� beschreibt durchzuführende Aktivitäten (Tätigkeiten) und zu
erstellende Produkte (Ergebnisse)
� Methodenzuordnung:
Wie Methoden die Aktivitäten des Vorgehensmodells durchführen und
welche Darstellungsmittel in den Ergebnissen zu verwenden sind
� Werkzeuganforderungen:
Welche funktionalen Eigenschaften die Software-Tools aufweisen
müssen?

Alte und neue Vorgehensmodelle
� Wasserfallmodell
� ...
� V-Modell
� Iterative Prozesse (RUP = Rational Unfied Process -
Vorgehensmodell von IBM)
� Agile Prozesse (Scrum )
� XP ( eXtreme Programming)

Wasserfallmodell – Iterative Modelle (RUP) - XP

V-Modell

Iteratives Modell - Phasen des RUP ( Rational
Unified Process)
Unified Prozess umfasst vier Phasen, die die Zeitachse eines
Projektes bilden:
� Konzeptphase (inception): Use Case identifizieren,
einfacher Prototyp, Projektkalkulation Projektsetup
� Spezifikationsphase (elaboration): Ausarbeitung,
komplettes Use Case-Modell
� Konstruktionsphase (construction): Implementierung,
Anforderungen an Basis-Architektur erweitert
� Einführungsphase (transition): Inbetriebnahme, erstellte
Software an künftige Nutzer übergeben (Beta-Release)

� Softwareentwicklung galt als vorhersagbarer Prozess mit
festem Ablauf und detaillierter Protokollierung aller Phasen
� Allgemeine Annahme, das Kunden einmalig und eindeutig ihre
Wünsche erklären
� Aufwendiges Verfahren der Anforderungserhebung im Vorfeld
von Analyse, Design, Codierung
� Massenproduktion von Dokumenten
� Massive Probleme bei Änderung der Anforderungen

Agil: behend, flink beweglich, rege, aufgeweckt
Agiler Prozess:
� Im Kern geht es bei agiler Softwareentwicklung um möglichst
häufige Rückkopplungsprozesse und zyklisches (iteratives)
Vorgehen auf allen Ebenen: bei der Programmierung, im Team
und beim Management
� Kurze Planungs- und Entwicklungsphasen wechseln sich ab
� Teilbereiche der Softwareentwicklung ( Modeling)
� SE-Prozess ( XP)
� Arbeit mit geringem bürokratischen Aufwand und wenig Regeln

Ziele
� Gegenbewegung zu schwergewichtigen
Prozessmodellen
� Schnell verfügbare Ergebnisse (“time-to-market”)
� Reaktion auf stark variierende Anforderungen
Softwareentwicklungsprozess flexibler und schlanker zu
machen, als das bei den klassischen
Vorgehensmodellen der Fall war

Kontrast - Idee des eXtreme Programming
XP (Extreme Programming) beschreibt eine agile
iterative Vorgehensweise beim
Softwareentwicklungsprozess mit leichtgewichtiger
Methodologie und wenig Dokumentation und
Overhead
4 wichtige Grundwerte
� Kommunikation
� Einfachheit
� Feedback
� Mut
Grundwerte müssen von den Mitarbeitern konsequent gelebt
werden

� Mündliche Kommunikation zwischen allen Projektbeteiligten
� Anwender und Auftraggeber sind eingeschlossen
� Aufgaben: Erstellen, Mitteilen, Validieren, Priorisieren und
immer wieder neu Priorisieren der Anforderungen
� Räumliche und zeitliche Einheit des gesamten Projektteams,
Teamgrößen von max. 10 Personen

� Planung beschränkt sich auf vorläufige Zuordnung von
Anforderungspaketen zu Lieferterminen
� Kurze Lieferzeiten für lauffähige Software: von 4 Wochen
bis 3 Monaten
� Anhand lauffähiger Software über weitere Anforderungen
und Priorisierung der verbleibenden entscheiden
� Kurze Lieferzeiten - relevanter Mehrwert für Kunden
� Feedback bedeutet: Kunde steuert das Projekt

� Bedeutet: NICHT DIE BESTE, sondern die einfachste bzw.
kostengünstigste zu realisieren
� Keine zu starke Abstraktion von Softwarekomponenten für
spätere Wiederverwendung, da künftige Anforderungen nicht
bekannt sind
� Leitspruch agiler Prozesse:
YOU ARE NOT GOING TO NEED IT!
� Abschätzung von Risiko und Mehrwert ist gemeinsame
Aufgabe von Kunde und Entwickler
� Agile Prozesse geben Instrumentarium, um das Risiko von
Veränderungen zu begrenzen

Das Agile Manifest (2001)- agile Prinzipien
- Basis agiler Softwareentwicklung
� Individuen und Interaktionen sind wichtiger als
Prozesse und Werkzeuge.
� Lauffähige Software ist wichtiger als umfangreiche
Dokumentation.
� Zusammenarbeit mit dem Kunden ist wichtiger als
Vertragsverhandlungen.
� Auf Änderungen reagieren ist wichtiger als einem
Plan zu folgen.

� Einsatz agiler Methoden
� Flexible Reaktion auf wechselnde Anforderungen,
änderungsfreundlich
� Iterativ-inkrementeller Ansatz
� Kurze Entwicklungszyklen, Time-Boxing ( „Magisches
Dreieck“ � weg von der Zeit hin zur Qualität)
Kosten und Zeit fix gesetzt!

� Adaptive Software Development (ASD)
� Crystal ( Familie agiler SE-Methoden )
� Dynamic System Development Method (DSDM)
� Pragmatic Programming
� Usability Driven Development (UDD)
� Scrum
� Extreme Programming (XP)

� agiles Prozessmodell mit starrer Organisationsschicht
� 1996 erste Definition von Scrum durch Schwaber und
Sutherland
� 2003 Zertifizierungsprogramm für Scrum Master
� System von Meetings, Artefakten, Rollen, Werten und
Grundüberzeugungen
� enge Zusammenarbeit zwischen Kunden, Team und
Management
� starke Selbstorganisation des Teams in Teilphasen (Sprints)
� Wichtung am Kosten-/Nutzenverhältnis orientiert

� Product Owner
� Stellt fachliche Anforderungen und priorisiert diese
� Legt Ziel und Budget fest
� Wichtigste Feature sondieren: Auswahl für nächsten Sprints
� Team
� Schätzt technischen Aufwand für die Umsetzung
� Zuständig für Implementierung
� Selbstorganisierend und –verwaltend
� Scrum Master
� Steuert den Prozess und beseitigt Hindernisse
� Sorgt für produktive Arbeitsbedingungen
t

Sprint (Iteration)
� Zentrales Element von Scrum
� Aufgabe in Teilaufgaben zerlegen
� Nur soviel Aufgaben, wie das Team verkraften kann
� Iterationsdauer ca. 30 Tage
� Vor jedem Sprint Anforderungen im Product Backlog
sammeln und priorisieren
� Detaillierung in Aufgaben (max. 16 h)
� Sprint Backlog aufstellen

Artefakte
� Product Backlog ( Produkt-Anforderungen gesammelt,
muss nicht vollständig sein, wird laufend fortgeführt)
� Sprint Backlog ( Anforderungen übernommen, die
während eines Sprints umgesetzt werden sollen)
� Burndown Chart ( grafische, pro Tag zu erbringende
Darstellung des Restaufwandes pro Sprints)
� Impediment List ( Hindernisse des Projektes, Scrum
Master und Team sorgen für Beseitigung)

Daily Scrum
� Täglich 15 minütiges Meeting
� Team stellt sich Fragen:
„Bist du gestern mit dem fertig geworden, was du dir
vorgenommen hast?“
„Welche Aufgaben wirst du bis zum nächsten Meeting
bearbeiten?“
„Gibt es ein Problem, das dich blockiert?“
Sitzung dient dem Informationsaustausch – alle erfahren alles
und lösen Probleme gemeinsam!

Review
� Nach Sprint wird Ergebnis einem informellen Review
durch Team und Kunden unterzogen
� Ergebnis wird Kunden vorgeführt, technische
Eigenschaften werden präsentiert
� Kunde prüft, ob das Ergebnis den Anforderungen
entspricht, eventuelle Änderungen werden im Product
Backlog dokumentiert

Scrum - Prozess

� Entwickelt 1995 von Kent Beck, Ward Cunningham
und Ron Jeffries während ihrer Arbeit im Projekt
„Comprehensive Compensation System“ bei Chrysler
� Gekennzeichnet durch fortlaufende Iterationen und
den Einsatz mehrerer Einzelmethoden
� XP folgt einem strukturierten Vorgehen und stellt die
Teamarbeit, Offenheit und stete Kommunikation
zwischen allen Beteiligten in den Vordergrund

XP - Features
User Stories: Die Anforderungen an die zu erstellende
Software werden nicht wie beim RUP in Use Cases, sondern in
User Stories erfasst
User Stories beschreiben GUIs, Funktionalitäten und
Testszenarien
On-site Customer: Ein kompetenter Vertreter des Kunden ist
während der gesamten Entwicklungszeit bei den Entwicklern
anwesend (dürfte nur selten realisierbar sein)
Pair Programming: An den Entwicklungsrechnern sitzen
jeweils zwei Entwickler und entwickeln gemeinsam.
Testing: Vor der Entwicklung eines Moduls werden
automatisierbare Testfälle (Unit Tests) programmiert.

Werte von XP

Kommunikation
Werte von XP
� Permanente und intensive Kommunikation zwischen
Entwicklern, Management und Kunden
Einfachheit
� Einfachste Softwaregestaltung
� keine redundante und überflüssige Funktionalität
� KISS-Prinzip
„Keep it simple and stupid“
„Halte es einfach und leicht verständlich“

Feedback
Werte von XP
� Kleine Releases ermöglichen dem Kunden kontinuierliche
Verfügbarkeit - schnelle Rückmeldung möglich
� Feedback durch Test - Überprüfung der umgesetzten
Funktionalitäten auf Korrektheit
Mut
� Mut zu kleinen und großen Veränderungen im System
� Refactoring ( Strukturverbesserung des Quellcodes ohne
Änderung des Programmverhaltens)
� „design and code for today not tomorrow“
Respekt
� respektvoller Umgang, sowohl im Team untereinander als
auch mit dem Kunden
� Unterschiedliche Meinungen werden akzeptiert

Programmieren
� Inkrementelle Entwicklung
� Veränderungen des Quellcodes mittels Refactoring
Testen
Grundlegende Aktivitäten von XP
� Automatisierte Test für alle Programmkomponenten
� Kunde prüft Umsetzung der Geschäftslogik mittels
funktionaler Tests

Zuhören
� Kommunikation zwischen den Entwicklern sowie mit
dem Kunden
Design
� Organisation der Systemlogik
� Komplexität verringern für ein gutes Design
� Keine unnötigen Dokumente zum Entwurf
t

Bewährte Softwarepraktiken extrem umgesetzt

Projektablauf XP

Iterationen

Entwicklung

� Vorgehensverfahren für agile Softwareentwicklung
� Unterstützen agile Prozesse
� Leitsatz für agile Methoden
„Je mehr Du nach Plan arbeitest, um so mehr
bekommst Du das, was Du geplant hast, aber
nicht das, was Du brauchst.“

� Planungsspiel und kurze Release-Zyklen
� Programmieren in Paaren
� Fortlaufende Integration
� 40 Stunden Woche
� Kunde häufig vor Ort
Praktiken von XP
t

Kritik – XP
� Beschränkte Team- und damit Projektgröße
� Fehlende Eignung für Festpreisprojekte
� Kein Architektur-Masterplan, mehr Redesign
� Kundenvertreter ist “single-point-of-failure”, Gefahr
von Mikromanagement

� Beide gehen iterativ bei der Entwicklung vor
� Beide sehen tägliche Treffen vor
� XP bezieht konkrete agile Methoden mit ein
� Scrum ist eher Rahmen und fordert mehr
Dokumentation
Scrum erscheint auf den ersten Blick nicht so
“extrem”, einfacher zu vermarkten

� Testgetriebene Entwicklung
� Paarprogrammierung
� Refactoring
� Story-Cards
� schnelle Code-Reviews
t

� Entwicklung der Tests vor der eigentlichen Software
� Unit-Tests und System-Tests
� Zyklisches Vorgehen beim Testen
� Testgetriebene Entwicklungsumgebung erforderlich,
z.B. im Java-Umfeld Ant und Maven
� Geeignete und unterstützende Testwerkzeuge, z.B.
JUnit, FIT
t

� 2 Entwickler - 1 Rechner
� Zwei Rollen
� Entwickler an der Tastatur („Driver“), erledigt die
aktuelle Aufgabe
� Entwickler daneben („Observer“), denkt nach und
vor, kontrolliert, korrigiert und „sieht durch“
� Wechselnde Aufgabenverteilung
� Keine festen Paarungen

Vorteil
� Verbesserte Qualität des Entwurfs
� Reduzieren von Programmierfehlern
� Lerneffekte und Kommunikation erhöhen
Nachteil
� Ca. 15% erhöhte Entwicklungszeit

� Strukturverbesserung des Quellcodes ohne Änderung
des Programmverhaltens
� Software ist besser wartbar, verwendbar und
erweiterbar
� Grundvoraussetzung für jeden evolutionären
Entwicklungsprozess
� Hilft Fehler zu finden und Redundanzen zu verringern
� Setzt automatisierte Testumgebung voraus

� Ausführen auf funktionierendem Code
� Überwachung durch Unit-Tests
� Beispiele fürs Refactoring:
� Auslagern gemeinsamer abstrakter Logik
� Verschieben von Attributen und Methoden
zwischen Klassen
� Duplizierten Code zusammenführen

� Kleine Projekte bis 10 Personen
� Systeme geringer -mittlerer Kritikalität ( Höhe der
Risiken)
� Hoch dynamisch (>30% geänderte Anforderungen /
Monat)
� Mindestens 30% hoch qualifizierte Mitarbeiter, wenig
niedrig qualifizierte Kräfte
� Organische Unternehmenskultur mit vielen Freiräumen
Nach: Boehm/Turner; Balancing Agility and
Discipline(2004)

� Große Projekte mit mehr als 100 Personen
� Systeme hoher –sehr hoher Kritikalität
� Stabil (

� Festpreisprojekte
� Systeme mit hoher Kritikalität
� Aufwandsschätzung
� Kulturwandel im Kundenverhältnis
� Organisation großer Teams (50 Entwickler und mehr)
� Selbstorganisation stellt hohe Anforderungen

� http://www.it-agile.de
� http://www.infforum.de/themen/
anwendungsentwicklung/thema_SE_agile_softwareentwicklung.htm
� http://www.wikipedia.de
� http://www.iti-software.de
� Balancing Agility and Discipline (2004) Boehm/Turner
� Agile Software Entwicklung (2007) Cockburn