EXtreme Programmierung Sebastian Galenski BA Lörrach – WWI 00 B

eXtreme ProgrammierungeXtreme Programmierung

Sebastian GalenskiBA Lörrach – WWI 00 B

GliederungGliederung

14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 3

GliederungGliederung1 Was ist extremes Programmieren ?

1.1 Definition 1.2 Ursprung

2 Praktiken der extremen Programmierung

2.1 Kleine Releases 2.2 Planungsspiel

2.3 Tests 2.4 Systemmetapher

2.5 Einfacher Entwurf 2.6 Refaktorisierung

2.7 Pair Programming 2.8 Gemeinsames Code-Eigentum

2.9 Fortlaufende Code-Integration 2.10 40-Stunden-Woche

2.11 Kundenvertreter im Team 2.12 Programmierrichtlinien

3 Voraussetzungen für XP

4 Vergleich

4.1 Traditionelle Modelle 4.2 XP

4.3 Folgen und Konsequenzen

5 Anwendungsbereich

6 Bewertung und Ausblicke von XP

1 Was ist XP ?1 Was ist XP ?


1 Was ist XP ?1 Was ist XP ? Herkömmliche Prozessmodelle sind schwergewichtig:

Träge Reaktion auf Kundenwünsche Anwachsender Projektfortschritt wird teuer

Fehlende Flexibilität: Kundenberührung mit dem System zu spät „Nein, bitte doch anders !“ „Das habe ich mir aber leichter vorgestellt“

Erster Ansatz nach dem Wasserfall war der Unified Process: Noch nicht die maximale Freiheit für Kunden und

Entwickler

eXtreme Programmierung: Leichtgewichtig und flexibel, da es die Kundenwünsche

und Entwicklermöglichkeiten berücksichtigt Hoher Stellenwert der Änderungswünsche

1 Was ist XP ?

1.1 Definition

1.2 Ursprung

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich

6 Bewertung und Ausblicke


1.1 Definition1.1 Definition

Code-zentriertes Prozessmodell

Bestimmte Techniken werden in extremem Maße ausgeübt

Als hochgradig iterativer Entwicklungsprozess ist XP prädestiniert für Projekte mit unklaren oder sich ändernden Anforderungen

1 Was ist XP ?

1.1 Definition

1.2 Ursprung

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



1.2 Ursprung1.2 Ursprung Wer hat´s erfunden ?

Kent Beck, Ward Cunningham, Ron Jeffries

Durch Erprobung in Projekten weiterentwickelt

Der Ansatz ?

kleine Projekte mit unklaren und sich immer wieder ändernden Anforderungen

Kunde hat hohe Ansprüche an die Qualität

Die Motivation ?

Develop for today – nur auf die heutigen Probleme konzentrieren

Do the simplest thing that could possibly work – einfachstes Design zur Problemlösung

1 Was ist XP ?

1.1 Definition

1.2 Ursprung

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich


2 Praktiken2 Praktiken


2 Praktiken2 Praktiken XP zeichnet sich durch 12 Praktiken aus1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher

2.5 Einfacher Entwurf

2.6 Refaktorisierung

2.7 Pair Programming

2.8 Gemeinsames Code-Eigentum

2.9 Fortlaufende Code-Integration

2.10 40-Stunden-Woche

2.11 Kundenvertreter im Team

2.12 Programmier-richtlinien

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2 Praktiken2 Praktiken


2 Praktiken2 Praktiken XP zeichnet sich durch 12 Praktiken aus

Stützen sich gegenseitig => nur in ihrer Gesamtheit sinnvoll

Sonst kann der XP Ansatz scheitern

Praktiken selbst sind nicht neu, jedoch die Kombination und der „extreme Grad“

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.1 Kleine Releases2.1 Kleine Releases Oder auch kleine Projektteile oder Version

Ein Release-Zyklus dauert i.d.R. zwischen ein und drei Monaten Besteht aus mehreren Iterationen (Dauer etwa ein bis vier Wochen) Eine Iteration zerfällt in mehrere Tasks/Arbeitspakete (Dauer etwa ein bis drei

Tage) Nach jeder Iteration kann der Kunde Abweichungen feststellen und korrigieren

Das erste Release sollte bereits ein funktionierendes Kernsystem bilden Es wird dann inkrementell in weiteren Releases ausgebaut

Vorteile: Kunde bekommt frühzeitig wichtige Funktionalitäten Entwickler bekommen schnelles Feedback

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.2 Planungsspiel2.2 Planungsspiel

Iterationen planen Entwicklerressourcen und Kundenwünsche in Einklang

bringen

Aufgabe des Kunden Anforderungen als User Stories (ähnlich der Use Cases) Prioritäten vergeben Worst Case:

Falls der Aufwand die verfügbaren Ressourcen übersteigt, muss der Kunde User Stories verschieben.

Aufgabe der Entwickler Aufwandsabschätzung Load-factor als Puffer einbauen Worst-Case:

Falls der Entwickler mit seiner Abschätzung daneben lag, kann nachverhandelt werden.

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.3 Tests2.3 Tests Zentrale Rolle, ohne sie geht´s nicht

Wissen über gewünschte Funktion steckt in den Testfällen und den User Stories

Testarten: Entwicklertests für Klassen (unit tests) – technische

Sicht, Dokumentationscharackter, Sicherheit bei Änderungen

Kundentests für User Stories (functional tests) – funktionale Fehler abdecken, Nachweis über bereitstellung der Funktion

Müssen automatisch ausgeführt werden

Müssen schnell ausführbar sein

!! Erst die Tests, dann die Implementierung !! Zwingt Entwickler zu Fallbeispielen

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.4 Systemmetapher2.4 Systemmetapher

Steht für die grundsätzliche Idee hinter der Architektur des Systems

Sie soll für den Entwickler und den Kunden verständlich sein

Sie soll den Architekturentwurf ersetzen

in puncto neue Programmteile soll sie folgendes vermitteln:

Welche Form angenommen werden soll An welche Stelle ins System integriert werden soll

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.5 Einfacher Entwurf2.5 Einfacher Entwurf

Es soll immer nach einer einfachen Lösung gesucht werden Do the simplest thing that could possibly work

Nur die momentan anstehenden Anforderungen sollen abgedeckt werden develop for today Sollten später Änderungen notwendig sein, so wird der

Entwurf refaktorisiert

Aspekte des einfachen Entwurfs: Erfüllung der Anforderungen – der Entwurf muss der

Aufgabe gerecht werden Redundanzfreiheit – jede Information darf nur einmal

gehalten werden Refaktorisierung – geringst mögliche Anzahl von

Klassen, Attributen und Methoden

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.6 Refaktorisierung2.6 Refaktorisierung

Dient der Vereinfachung des Entwurfs unter Beibehaltung der Semantik/Funktionalität

Verbesserung der Verständlichkeit und Änderbarkeit des Codes

Selbsterklärungsfähigkeit da sich die Dokumentation wegen der häufigen

Anpassungen auf den Code beschränkt, sollten beim Refaktorisieren Struktur und Namensgebungen selbsterklärend sein

Wenn also Code existiert, welcher eines Kommentares bedarf, so sollte der Code angepasst/vereinfacht werden

Nach der Refaktorisierung sollten immer die Tests durchlaufen werden sollten der Code wieder die geringst mögliche Anzahl

Klassen, Attribute und Methoden aufweisen

Ständiger Fluss im Design => kontinuierliche Refaktorisierung

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.7 Pair Programming2.7 Pair Programming

Entwurf, Codierung und Tests von zwei Entwicklern gemeinsam Eine Tastatur, eine Maus, ein Rechner Rollenverteilung: Implementierer-Rolle, Reviewer-Rolle Bei Bedarf kann getauscht werden

Paarbildung ist nicht fest, sondern geeigneten Partner suchen Positiver Nebeneffekt: Wissen über alle Aspekte des System

breitet sich über alle Entwickler aus (Ausfallsicherheit)

Einer programmiert, der andere prüft Der Reviewer hat andere Ziele im Auge:

Fehler (logische und syntaktische) Passt der Code zum Entwurf Kann der Entwurf verbessert werden Fehlen noch Tests zum Code

=> Kontinuierliche Begutachtung

Williams und Cookburn: Entwicklungsaufwand im Vergleich zu allein arbeitenden

Entwicklern nimmt ca. 15% zu Code ist hingegen leichter verständlich und hat weniger Fehler

(ca. 60%)

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.8 Gemeinsames Code-Eigentum2.8 Gemeinsames Code-Eigentum

Der Code gehört nicht einem sondern allen Entwicklern

Jedes Entwicklerpaar darf zu jeder Zeit am gesamten Code Änderungen vornehmen. Um z.B. die Verständlichkeit zu verbessern.

Änderungen können aber fehlerhaft sein

Deshalb müssen nach jeder Änderung alle Tests durchlaufen werden

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.9 Fortlaufende Code-Integration2.9 Fortlaufende Code-Integration

Neuer oder geänderter Code wird alle paar Stunden integriert

Auf einen dedizierten Integrationsrechner

Alle Tests nach Integration durchlaufen Bei Fehlern muss der Code vom Paar zurückgenommen

werden Fehler müssen von dem Paar beseitigt werden

So besteht immer ein lauffähiges System

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.10 40-Stunden-Woche2.10 40-Stunden-Woche

Pair Programming stellt hohe Ansprüche an die Entwickler

Im Paar müssen beide hoch konzentriert sein

Das können sie aber nicht, wenn sie erschöpft sind

Deshalb: geregelte Arbeitszeiten

40 ist nur ein Richtwert

Überstunden nur als Ausnahmefall => unfreiwillige Mehrarbeit

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher








2.12 Programmier- richtlinien

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.11 Kundenvertreter im Team2.11 Kundenvertreter im Team

Da keine echte Spezifikation (User Stories sind nicht detailliert genug) => viele Rückfragen an den Kunden

Deshalb sollte ein Kundenvertreter für die Entwickler ständig im Zugriff sein (on-site customer)

Zukünftiger Anwender

Entwickelt die Testfälle (funktionale Tests)

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher








2.12 Programmier- richtlinien

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



2.12 Programmierrichtlinien2.12 Programmierrichtlinien

Um das Arbeiten in Paaren und das gemeinsame Code-Eigentum zu erleichtern

Werden von den Entwicklern untereinander vereinbart und eingehalten

Hat zur Folge, dass:– der Code einheitlich ist– ihn alle verstehen– ihn alle ändern können

1 Was ist XP ?

2 Praktiken

2.1 Kleine Releases

2.2 Planungsspiel

2.3 Tests

2.4 Systemmetapher









3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich


3 Voraussetzungen3 Voraussetzungen


3 Voraussetzungen3 Voraussetzungen

Alle müssen sich auf die XP Praktiken einlassen

Kunde muss qualifizierten Mitarbeiter abstellen

Keine großen Entwicklerteams: max. 10-15 Entwickler

Entwickler an einem Ort konzentriert zwecks Kommunikation und Paarbildung

Tests müssen automatisch und in kurzer Zeit ausführbar sein

Beck´s Empfehlung: Schrittweise Einführung von XP

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich


4 Vergleich4 Vergleich


4.1 Traditionelle Modelle4.1 Traditionelle Modelle Wasserfall oder Unified Process sind schwergewichtig Keine bis wenig Flexibilittät und Freiheit Änderungswünsche sind teure und schwer realisierbar Kosten beim Wasserfall (exponentiell) oder UP (linear)

Ausgangspunkt für diese Annahmen

Was kostet eine Änderung in der: Analysephase Designphase Implementierungsphase

Im Gegensatz zu XP: größerer Planungsaufwand (Analysephase) Späte Implementierung/Codierung

(Implementierungsphase)

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich

4.1 Traditionelle Modelle

4.2 XP


5 Anwendungsbereich



4.2 XP4.2 XP Leichtgewichtig

Geringer Planungsaufwand Frühe Codierung Änderungswünsche der Kunden werden berücksichtig Möglichkeiten der Entwickler werden berücksichtigt

Nur ein einfaches Design erlaubt: Späteres Auftreten von Anforderungen

Kosten steigen nicht linearoder exponentiell

Die geringen Kostensind zu erklären durch den Einsatz von objektorientierten Sprachen einfaches Design automatisierte Tests Erfahrungen im Ändern

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich


4.2 XP


5 Anwendungsbereich



4.3 Folgen und Konsequenzen4.3 Folgen und Konsequenzen1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich


4.2 XP


5 Anwendungsbereich


Traditionelle Modelle

(z.B. Unified Process)

XP Modell

Änderungen Antizipieren Erst bedenken wenn gefordert

Änderungsmöglichkeiten

Einbauen Nicht einbauen, nur das

notwendigste implementieren

Umfang der Software Komplex Einfach

Anfangskosten Hoch Gering

Gesamtkosten Gering Gering

Projektfortschritt Anfangs langsamer Schneller

Gesamtzeit gering Gering

5 Anwendungsbereich5 Anwendungsbereich


5 Anwendungsbereich5 Anwendungsbereich

Einsatz von XP ist nur möglich, wenn die Voraussetzungen erfüllt sind

Es empfiehlt sich, XP nur bei kleineren Projekten mit unklaren oder sich ständig ändernden Anforderungen einzusetzen Meist bei individueller Software der Fall

Aus Mangel an Erfahrungen wird noch kontrovers über die Skalierbarkeit die möglichen Projektgrößen

diskutiert

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich


6 Bewertung und Ausblicke6 Bewertung und Ausblicke


6 Bewertung und Ausblicke6 Bewertung und AusblickeContra – XP

Explizite Spezifikation und Entwurfsdokumentation fehlen Zwar ist Doku im Test und im Sourcecode, jedoch

kennen diese nur die Teammitglieder

Gemeinsames Code-Eigentum wird zum Problem, da kein Übersichtsdokument vorhanden ist

Änderungen am Entwurf ziehen Änderungen an den Tests nachsich Sorgfältige Arbeit ist nötig Reicht die Begutachtung des Pair Programmings aus ? QS wird in Frage gestellt

XP selbst ist nur unzureichend dokumentiert Die Systemmetapher wird z.B. nur kurz und knapp

erwähnt Keine Nachweise über die Überlegenheit von der

Vorgehensweise von XP

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich



6 Bewertung und Ausblicke6 Bewertung und AusblickePro – XP

C3 Projekt bei DaimlerChrysler

Berichte über andere Projekte bei Beck

Alle beteiligten Gruppen waren mit XP zufrieden Hohe Motivation und Freude am Programmieren bei den

Entwicklern Gute Termineinhaltung im Management Frühe Verfügbarkeit und hohe Qualität eines laufenden

Systems beim Kunden

1 Was ist XP ?

2 Praktiken

3 Voraussetzungen

4 Vergleich

5 Anwendungsbereich


Vielen DankVielen Dank

für Ihre Aufmerksamkeit !

Documents

EXtreme Programmierung Sebastian Galenski BA Lörrach – WWI 00 B