Extreme Programming

Gliederung des Vortrags


Der Themenkomplex wurde in folgende drei Teil-Themen aufgeteilt.

Community

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

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

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

 
Zu dieser Seite gibt es keine Dateien. [Zeige Dateien/Upload]
Kein Kommentar. [Zeige Kommentare]