Post on 05-Apr-2015
transcript
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 ?
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 5
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
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 6
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 7
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
6 Bewertung und Ausblicke
2 Praktiken2 Praktiken
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 9
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 10
2 Praktiken2 Praktiken
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 11
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 12
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 13
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 14
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 15
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 16
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 17
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 18
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 19
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 20
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
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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 21
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.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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 22
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.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
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 23
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
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
6 Bewertung und Ausblicke
3 Voraussetzungen3 Voraussetzungen
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 25
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
6 Bewertung und Ausblicke
4 Vergleich4 Vergleich
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 27
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
4.3 Folgen und Konsequenzen
5 Anwendungsbereich
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 28
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.1 Traditionelle Modelle
4.2 XP
4.3 Folgen und Konsequenzen
5 Anwendungsbereich
6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 29
4.3 Folgen und Konsequenzen4.3 Folgen und Konsequenzen1 Was ist XP ?
2 Praktiken
3 Voraussetzungen
4 Vergleich
4.1 Traditionelle Modelle
4.2 XP
4.3 Folgen und Konsequenzen
5 Anwendungsbereich
6 Bewertung und Ausblicke
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
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 31
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 Ausblicke
6 Bewertung und Ausblicke6 Bewertung und Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 33
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 Ausblicke
14. Juli 2002 eXtreme Programmierung - Sebastian Galenski 34
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
6 Bewertung und Ausblicke
Vielen DankVielen Dank
für Ihre Aufmerksamkeit !