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

Viel Spaß beim Einsatz von XP! Vielen Dank! Viel Spaß beim Einsatz von XP!