350 likes | 543 Views
eXtreme Programmierung. Sebastian Galenski BA Lörrach – WWI 00 B. Gliederung. Gliederung. 1 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
E N D
eXtreme Programmierung Sebastian Galenski BA Lörrach – WWI 00 B
Gliederung 1 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 eXtreme Programmierung - Sebastian Galenski
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 eXtreme Programmierung - Sebastian Galenski
1.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 eXtreme Programmierung - Sebastian Galenski
1.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 eXtreme Programmierung - Sebastian Galenski
2 Praktiken • XP zeichnet sich durch 12 Praktiken aus • 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 eXtreme Programmierung - Sebastian Galenski
2 Praktiken eXtreme Programmierung - Sebastian Galenski
2 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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
2.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 eXtreme Programmierung - Sebastian Galenski
3 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 eXtreme Programmierung - Sebastian Galenski
4.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 eXtreme Programmierung - Sebastian Galenski
4.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 linear oder exponentiell • Die geringen Kosten sind 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 eXtreme Programmierung - Sebastian Galenski
4.3 Folgen und Konsequenzen • 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 eXtreme Programmierung - Sebastian Galenski
5 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 eXtreme Programmierung - Sebastian Galenski
6 Bewertung und Ausblicke Contra – 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 eXtreme Programmierung - Sebastian Galenski
6 Bewertung und Ausblicke Pro – 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 eXtreme Programmierung - Sebastian Galenski
Vielen Dank für Ihre Aufmerksamkeit !