XP – eXtreme Programming
• Phänomene der „Softwarekrise“
–
–
–
–
–
–
–
–
Terminverzögerungen
Projektabbruch
Fehlerrate
System wird unrentabel
Geschäftsprozesse werden falsch verstanden
Geschäftsprozesse ändern sich
Falsche Funktionsfülle
Personalwechsel
• Gegenmaßnahme: XP
• Ursprung: Daimler Chrysler
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 1
XP – eXtreme Programming
• Was ist „extrem“? – alles, was sich bewährt hat wird „extrem“ betrieben
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 2
XP – eXtreme Programming
• Hoffnungen: Kostenreduktion bei Änderungen
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 3
XP – eXtreme Programming
• Bedeutung der Planung
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 4
XP – eXtreme Programming
• Vorteile der XP-Anwendung:
–
–
–
–
Projektrichtung kann einfacher an Umfeld angepasst werden
unklare Punkte können aufgeschoben werden (keine unsichere Investitionen)
Projekt kann mit Marktwachstum wachsen
Bei Einstellung des Projektes besteht trotzdem ein funktionstüchtiges
Zwischenrelease
– Der Kunde bekommt den Featureumfang mit der von ihm gewollten Priorität
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 5
XP – Theorie
• die vier Variablen in XP-Projekten
–
–
–
–
Kosten
Qualität
Zeit
Umfang
•  „magisches Quadrat“
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 6
XP – Theorie
• die vier (sieben) Werte von XP
– Kommunikation:
• mangelnde Kommunikation ist häufige Ursache für Scheitern eines Projektes 
• Förderung von Kommunikation (z.B. Pairprogramming, tägl. Meetings (im Stehen),
Kommunikation mit dem Kunden)
– Einfachheit:
• es wird die einfachste Möglichkeit gewählt, ein Problem zu lösen und nur das wird
realisiert.
• Einfachheit reduziert Kommunikationsbedarf
• erhöhte Kommunikation liefert „einfachere“ Lösungen
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 7
XP – Theorie
• die vier (sieben) Werte von XP
– Feedback:
• z. B. durch Partner beim Pairprogramming
• durch automatische Modultests am Ende des Tages
• der Kunde durch häufige Releases
– Mut:
• jeder soll erkannte Probleme angehen, um den Erfolg des Projektes zu sichern
• es werden nur die Probleme angegangen, die momentan wirklich vorliegen
• Eliminierung von überflüssigem Code
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 8
XP – Theorie
• die vier (sieben) Werte von XP
– (Respekt)
• vor den anderen Projektmitgliedern
– (Interesse)
• am Lernen
– (Qualitätsbewußtsein)
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 9
XP – Theorie
• XP-Prinzipien
– Umsetzung der Werte in konkrete Anwendungsvorschläge
– Unterscheidung in primäre und sekundäre Prinzipien
– Primär:
•
•
•
•
•
unmittelbares Feedback
Streben nach Einfachheit
inkrementelle Veränderungen
Änderungen willkommen heißen
Qualitätsarbeit leisten
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 10
XP – Theorie
• XP-Prinzipien
– Sekundär:
•
•
•
•
•
•
•
•
Lernen lehren
kleine Anfangsinvestitionen
Spielen, um zu gewinnen (keine Sanktionen bei schlechten Nachrichten)
gezielte Experimente
offene, ehrliche Kommunikation
Verantwortung übernehmen
an örtliche Gegebenheiten anpassen
ehrliches Messen
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 11
XP – Theorie
• Rollen
– Kunde
•
•
•
•
aktive Mitarbeit
Vorgabe der Ziele (User-Stories auf Storycards)
Formulierung von Akzeptanztests
Kritikfähigkeit (Einfluss, aber keine Kontrolle)
– Entwickler, Programmierer
• Teamfähigkeit: Teamerfolg steht über Einzelerfolg
• Kommunikationsfähig und –bereitschaft
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 12
XP – Theorie
• Rollen
– Coach
• zuständig für Disziplin
• Führen ohne zu bevormunden
• zu starke Führung steht im Gegensatz zu den XP Prinzipien
– Terminmanager
•
•
•
•
verfolgt Projektstatus
sammelt Aufwand der einzelnen Personen
Reaktion und Einleitung von Gegenmaßnahmen bei Abweichungen vom Plan
Messen und Kontrollieren von Prozessleistungen
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 13
XP – Theorie
• Rollen
– Projektmanager (untergeordnete Bedeutung)
• präsentieren von Projektergebnissen
– Tester
• Unterstützung des Kunden
• eigentliche Aufgabe wird vom Programmierer erledigt
– Berater
• Nebenrolle: ist Ansprechpartner bei technischen Problemen, die das Wissen der
einzelnen Entwickler übersteigt
• gefordert sind Generalisten, wenige Spezialisten
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 14
XP – Projekteinteilung
• Release:
–
–
–
–
Iterative Vorgehensweise
Projektdauer wird in kurze Releasezyklen (einige Monate) unterteilt
Kunde und Entwickler legen in Planungsspiel die Funktionen fest (Releaseplan)
Änderungen durch den Kunden sind explizit vorgesehen
• Iteration:
–
–
–
–
Release wird in Iterationen unterteilt (1- 3 Wochen)
->Iterationsplanung
sehr viele lauffähige Zwischenreleases
Software „reift“ unter Beobachtung des Kunden
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 15
XP – Projekteinteilung
• Vergleich verschiedener Methoden
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 16
XP – Projekteinteilung
• Planung
–
–
–
–
Planung wichtig, aber nicht nur am Anfang
Flexibilität im Umgang mit Kundenanforderungen haben Priorität
Planung erfolgen iterationsbezogen
Planung erfolgt im Planungsspiel
• Kunde formuliert seine Anforderungen auf User Cards
• Entwickler schätzt Aufwand ab.
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 17
XP – Projekteinteilung
– Langzeitplanung nur in groben Zügen
– Stand up meeting
•
•
•
•
jeden Tag
5 Minuten
wer hat was gemacht, welche Probleme, nächste Schritte
keine Lösungen
– Planungsfehler  Reduktion der Anforderungen
– Terminprobleme  Reduktion des Umfanges
– nur 40 h –Woche, keine Überstunden  Erhalt der Kreativität
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 18
XP – Entwicklung
• Überblick
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 19
XP – Entwicklung
• Design:
– konsequentes Refactoring gegen sich ändernde Kundenanforderungen
– Wegen häufiger Änderungen „einfaches Design“ nach 4 Regeln
• einfaches Design muss alle Testanforderungen bestehen, die die Kundenanforderungen
validieren
• das Design muss jede Idee ausdrücken, die der Entwickler zum Ausdruck bringen muss
• kein Programmcode darf doppelt vorhanden sein
• das einfachste Design besitzt am wenigsten Klassen und Methoden
– einfaches Designwenig Aufwand bei Test und Refactoring
• Refactoring
– Verbesserung des Codes und des Designs
– keine neuen Funktionen, nur Verbesserung
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 20
XP – Entwicklung
• Programmierung
– Pairprogramming:
• ein Entwickler codiert, der andere kontrolliert
• Rollen werden gewechselt Erfahrungsaustausch
• trotz Pairprogramming Kostenreduktion um 12 – 15%
– Programmierstandards
• einheitliches Aussehen von Quellcodes
• Testen
– Unit Tests
• Entwickler verfassen Testspezifikation
• Codierung bis alle Tests erfolgreich sind
– Akzeptanztest
• Validierung der Kundenanforderungen
• Verantwortlich: der Kunde
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 21
XP – Grenzen
• Voraussetzungen
– Unternehmenskultur
– keine risikobehaftete Projekte, da aus Sicherheitsgründen ständige Releases nicht
möglich
– kleine Teams (-12 Entwickler), sonst Kommunikations- und
Koordinationsprobleme
– Gewaltentrennung: geschäftliche Entscheidungen fällt der Kunde, technische der
Entwickler
– Persönlichkeitsprofil der Entwickler (hohe Sozialkompetenz, Selbstdisziplin)
– erfahrenes Team
– automatisierte Tests
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 22
XP – Grenzen
• Nachteile
– fehlendes Risikomanagement
– keine Dokumentationspflicht, die aber oft vom Gesetzgeber gefordert wird
– es kann schnell Chaos entstehen
Prof. Dr. Gerhard Schmidt
pres. by H.-J. Steffens
Software Engineering SS 2009
Folie 23

SE_SS2009