Referat „Extreme Programming“
Von Irina Gimpeliovskaja
und Susanne Richter
1.) Was ist XP?



Überlegte Annäherung an
Softwareentwicklung
Prozessmodell für objektorientierte
Softwareentwicklung
erfordert gute Teamarbeit zwischen
Manager, Kunde und Entwickler
2.) Geschichtliches, Entstehung



1990 - Kent Beck und Ward
Cunningham dachten über bessere
Entwicklungsstrategien nach
1996 - Beck arbeitet beim Chrysler
Projekt C3, heraus kam XP
von Chrysler als gescheitert erklärt,
aber von Beck übernommen


XP-Methodik wurde erfolgreich
abgeschlossen
damals eingesetzt bei Projekten, bei
denen es nichts mehr zu retten gab
3.) Grundprobleme und Lösungen in XP

Terminverzögerungen:
– bei XP werden zuerst die wichtigsten
Funktionen programmiert, so dass
fehlende Funktionen weniger wichtig sind
3.) Grundprobleme und Lösungen in XP

Projektabbruch:
– es wird eine kleinstmögliche Version
ausgewählt, die den erwünschten Vorteil
bringt
– so kommt es nicht zu einer untragbaren
Verzögerung (hohe Kosten)
3.) Grundprobleme und Lösungen in XP

System wird unrentabel
(Kosten/Nutzen-Faktor stimmt nicht):
– ständiges Testen sorgt für erstklassigen
Zustand des Systems
– Einfachheit des Systems minimiert Kosten
bei Änderung
3.) Grundprobleme und Lösungen in XP

Hohe Fehlerrate (unbrauchbare SW):
– ständige Tests durch Kunden und
Entwickler
3.) Grundprobleme und Lösungen in XP

falsch verstandenes Geschäftsziel:
– der Kunde wird zu starkes Teil des Teams
3.) Grundprobleme und Lösungen in XP

Geschäftsziel ändert sich:
– kein Problem durch die kurzen
Releasezeiten
3.) Grundprobleme und Lösungen in XP

Falsche Funktionen (zu viele):
– Funktionen nach Priorität entwickeln
– kurze Releaszyklen beibehalten, damit der
Kunde entscheiden kann, welche
Funktionen wichtig sind
3.) Grundprobleme und Lösungen in XP

Personalwechsel:
– ständige Tests und eine geringe Fehlerrate
verursachen weniger Frustration bei den
Programmierern
– weniger Personalwechsel als bei anderen
Methoden
4.) Vier essentielle Eigenschaften


diese sollen die Probleme der
herkömmlichen Softwareentwicklung
zuerst auf relativ abstrakte Weise
angehen
später werden gezielte Strategien
entwickelt
4.) Vier essentielle Eigenschaften

a) Kommunikation
– betrifft sämtliche Bereiche der Entwicklung
– XP setzt Coach ein, der speziell zur
Entdeckung und Beseitigung von
Kommunikationslücken zuständig ist (er
fördert und unterstützt den
Kommunikationsfluß)
4.) Vier essentielle Eigenschaften

b) Einfachheit
– wie sind die Probleme am einfachsten zu
lösen?
– Lösen von zwanghaftem Vorausdenken
– Devise: lieber heute etwas Einfaches
herstellen, kompliziert kann man es immer
noch morgen machen
4.) Vier essentielle Eigenschaften

c) Feedback
– zur realisitischen Einschätzung des Projektstatus
– wird erreicht durch Komponententests jeder
Funktion
– Feedback des Kunden durch frühe Releases
– Feedback desjenigen, der die Arbeit überwacht
– je mehr, desto einfacher und ehrlicher ist die
Kommunikation
4.) Vier essentielle Eigenschaften

d) Mut
– sich gegen altbewährte Methoden der
Softwareentwicklung durchzusetzten
– Änderungen an Programmen, die man
nicht geschrieben hat
– lang erarbeiteten Code wegwerfen und
neuen Lösungsansatz bringen
5.) Grundprinzipien


den Eigenschaften werden Prinzipien
zugeordnet
es ist immer die Alternative zu wählen,
die am ehesten einem oder mehrerer
Prinzipien folgt
5.) Grundprinzipien

a)unmittelbares Feedback
– vom Kunden
– kurze Releasezeiten (< 1 Monat)
– vom System durch Komponententests
5.) Grundprinzipien

b) Einfachheit anstreben
– Heute aktuelle Arbeit erledigen und das so
einfach wie möglich
– komplexere Module kann man später in
der vorher gesparten Zeit hinzufügen
5.) Grundprinzipien

c) inkrementelle Veränderungen
– jedes Problem in viele kleine Problemchen
zerlegen
– vereinfacht Programmierung und Testen
– schnelleres Fehlerfinden
5.) Grundprinzipien

d) Veränderungen wollen
– Veränderungen wollen, da sie eine
positiven Effekt haben können
– die beste Alternative einer Entscheidung ist
die mit den meisten Optionen
5.) Grundprinzipien

e) Qualitätsarbeit
– ist wichtig für den Erfolg und die Motivation
des Teams
– also: qualitativ hochwertige Arbeit
anstreben
6.) Die 12 Praktiken bei XP

6.) Die 12 Praktiken bei XP

1) Planungsspiel
– Kunde schreibt mehrere User Stories (keine
Details) des Problems
– Abschätzen der Kosten pro Story (Zeit: 1-3
Wochen)
– nach Priorität bis zum nächsten Release
abarbeiten
– insgesamt 80 +/- 20 gute Anzahl für Release Plan
6.) Die 12 Praktiken bei XP

2) kurze Releasezeiten
– erstes Release nach 1-2 Monaten, danach alle 2-4
Wochen
– nach jedem Release neues Planungsspiel
– Nutzen: häufiges Feedback des Kunden,
sichtbarer Projektfortschritt
– selbst bei vorzeitigem Abbruch ist etwas
Brauchbares verfügbar
6.) Die 12 Praktiken bei XP

3) System Metaphern
– gute Namen für Komponenten des
Projektes finden
– Team soll das große Ganze nicht aus den
Augen verlieren
6.) Die 12 Praktiken bei XP

4) Einfaches Design
– keine Redundanz, Klassen -und
Methodenanzahl so klein wie möglich,
Bestehen aller Tests
– Code und Testfälle sollten Projekt
verständlich machen
6.) Die 12 Praktiken bei XP

5) Testen (!!!)
– Tests werden vom Programmierer und Kunden
durchgeführt
– erst Tests schreiben, dann Funktion
implementieren
– erst nach erfolgreichem Test, weiter entwickeln
– nach Refactoring alle Testfälle nochmal
durchlaufen
6.) Die 12 Praktiken bei XP

7) Pair Programming
– jedes Programmierpaar arbeitet an einer
User Story
– einer macht sich Gedanken über
Implementierung, der andere über Testfälle
– häufiges Abwechseln der Rollen, auch
Paarkombinationen ändern sich
6.) Die 12 Praktiken bei XP

8) gemeinsame Verantwortung
– Code ist kein Privateigentum
– jeder darf jeden Code jederzeit ändern
6.) Die 12 Praktiken bei XP

9) Fortlaufende Integration (!!!)
– es existiert ein eigener Integrationsrechner
– neuen Code nur an diesem Rechner
einpflegen
– wenn Tests funktionieren, Code drin
lassen, sonst alles zurücksetzen
– (siehe CVS)
6.) Die 12 Praktiken bei XP

10) 40-Stunden-Woche
– geregelte Arbeitszeiten sorgen für
ausgeglichene Programmierer :o) und
somit für bessere Arbeitsergebnisse
6.) Die 12 Praktiken bei XP

11) Kunde vor Ort
– Mitarbeiter des Kunden ist für die
Projektzeit vor Ort, um mögliche
Unklarheiten der Funktionen zu klären und
User Storys mitzuschreiben
6.) Die 12 Praktiken bei XP

12) Programmierstandards
– gemeinsamer Programmierstandard sollte
selbstverständlich sein (Coding standards)
– vereinfacht die gemeinsame
Verantwortung für den Code
7.) Vorteile, Nachteile

Vorteile:
– Motivation und Freude bei der Arbeit durch
Gleichstellung im Team und gemeinsamen
Code
– erstes lauffähiges Programm schnell
verfügbar
– hohe Qualität durch Pair-Programming,
Reviews, regelmäßiges Refactoring
7.) Vorteile, Nachteile

Vorteile:
– dadurch: robuster, wartungsfreundlicher
Code
– Einhaltung der Qualitätsanforderung durch
Refactoring
– leichte Integration von Anfängern durch
Pair-Programming
7.) Vorteile, Nachteile

Nachteile:
– häufig fehlt Dokumentation (nur von
Testfällen und Code), für spätere
Änderungen problematisch
– dadurch müssen die Entwickler das Design
quasi auswendig kennen (aber dieses wird
oft verändert)
7.) Vorteile, Nachteile

Nachteile:
– konkurrierende Änderungen an
gemeinsamen Klassen
– XP bis jetzt unzureichend dokumentiert
– bisher nicht nachgewiesen, daß XP
anderen Strategien überlegen ist
8.) Zielgruppe


kleine Projekte mit unklaren, sich immer
wieder verändernden Anforderungen
kleine Gruppen von Mitarbeitern (10-15)
9.) Voraussetzungen



alle Beteiligten müssen sich auf die
genannten Praktiken einlassen
alle Programmierer sollten am selben
Ort und zur selben Zeit arbeiten
(bessere Kommunikation!)
Testläufe sollten nicht zu lange dauern


Vielen Dank!
Viel Spaß beim Einsatz von XP!

extreme - susigottwald.de