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!