Extreme Programming

Gliederung des Vortrags

Der Themenkomplex wurde in folgende drei Teil-Themen aufgeteilt.

Community

• Daniel Zimmermann

Gliederung

1. Einleitung: Was ist XP? – Grundlagen.
2. Entwicklungsabriss – Vordenker, Prinzipien und Geschichlticher Ablauf
3. Massgebliche Beteiligung verschiedener Unternehmungen, Konsortien und Personen
4. Konferenzen & Stammtische
5. wichtige Bücher, Schriften und Web Links
6. Für- und Widersprecher und deren Argumente und Hintergründe

Vorgehensmodell

• Michael Martin

Gliederung

1. Einleitung: XP als iteratives, evolutionäres und agiles Vorgehensmodell
2. Warum XP, Vorteile, Phasenverlauf klassischer Modelle im Gegensatz zu XP
3. Vorstellung beteiligter Rollen am Entwicklungsprozess
4. Vorgehensmodellbestandteile respektive dessen Phasen
   Planung (und deren beteiligte Rollen)

   Planspiel: Erforschungsphase, Verpflichtungsphase, Steuerungsphase
   Iteration: Erforschungsphase, Verpflichtungsphase, Steuerungsphase
   

   Design (und deren beteiligte Rollen)

   Metapher
   kurze Releasezyklen
   Refactoring
   

   Test

   Unit-Tests
   Funktionstests
   

   Implementierung
   
5. Kritische Auseinandersetzung mit XP (Vorteile, Nachteile, Auftretende Probleme)
6. abstrakte und projektspezifische XP-Modelle sowie Tools zur Unterstützung im Softwareentwicklungsprozess im Einsatz

Focus auf einzelne Prinzipien

• Joachim Bachmann

Gliederung

1. Was ist XP?
2. Nennen der Prinzipien
   • Mut – ändere den Quellcode, wenn du denkst es muss so sein
   • Respekt vor allen Mitgliedern im Team
   • Kommunikation – sprich mit anderen im Team, um Informationen auszutauschen
   • Kritik und andere Meinungen zulassen
   • Kollektives Eigentum – jeder darf jederzeit jeden Quellcode verändern
   • Pair-Programming – zwei Programmierer teilen sich Computer, Monitor, Tastatur und Maus – einer codiert, einer denkt mit (regelmäßig die Rollen tauschen, Vier-Augen-Prinzip).
   • Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen (z. B. durch Cruise Control).
   • Testgetriebene Entwicklung – es werden erst die Unit-Tests geschrieben, bevor die eigentliche Funktionalität programmiert wird. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht auch von Grey-Box-Tests.
   • Enge Einbeziehung des Kunden, d. h. der Kunde gibt das Iterationsziel mit Hilfe sogenannter Story-Cards vor und hat sofort die Möglichkeit Akzeptanztests durchzuführen. “Story-Cards” beschreiben Anwendungsfälle exemplarisch in Form kurzer Geschichten. Der Kunde muss allerdings sehr oft anwesend oder zumindest greifbar sein.
   • Laufende Refaktorisierung, ständige Architekturverbesserung
   • 40-Stunden-Woche, d. h. Überstunden sind zu vermeiden, weil darunter die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produkts leidet.
   • Kurze Release-Zyklen, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern.
3. kurze Erklärung dieser
4. Bewertung / Nutzen der Prinzipien / Probleme
5. Zusammenfassung