Referat „Extreme Programming“

1. Referat „Extreme Programming“ Von Irina Gimpeliovskaja und Susanne Richter

2. 1.) Was ist XP? • Überlegte Annäherung an Softwareentwicklung • Prozessmodell für objektorientierte Softwareentwicklung • erfordert gute Teamarbeit zwischen Manager, Kunde und Entwickler

3. 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

4. XP-Methodik wurde erfolgreich abgeschlossen • damals eingesetzt bei Projekten, bei denen es nichts mehr zu retten gab

5. 3.) Grundprobleme und Lösungen in XP • Terminverzögerungen: • bei XP werden zuerst die wichtigsten Funktionen programmiert, so dass fehlende Funktionen weniger wichtig sind

6. 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)

7. 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

8. 3.) Grundprobleme und Lösungen in XP • Hohe Fehlerrate (unbrauchbare SW): • ständige Tests durch Kunden und Entwickler

9. 3.) Grundprobleme und Lösungen in XP • falsch verstandenes Geschäftsziel: • der Kunde wird zu starkes Teil des Teams

10. 3.) Grundprobleme und Lösungen in XP • Geschäftsziel ändert sich: • kein Problem durch die kurzen Releasezeiten

11. 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

12. 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

13. 4.) Vier essentielle Eigenschaften • diese sollen die Probleme der herkömmlichen Softwareentwicklung zuerst auf relativ abstrakte Weise angehen • später werden gezielte Strategien entwickelt

14. 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ß)

15. 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

16. 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

17. 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

18. 5.) Grundprinzipien • den Eigenschaften werden Prinzipien zugeordnet • es ist immer die Alternative zu wählen, die am ehesten einem oder mehrerer Prinzipien folgt

19. 5.) Grundprinzipien • a)unmittelbares Feedback • vom Kunden • kurze Releasezeiten (< 1 Monat) • vom System durch Komponententests

20. 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

21. 5.) Grundprinzipien • c) inkrementelle Veränderungen • jedes Problem in viele kleine Problemchen zerlegen • vereinfacht Programmierung und Testen • schnelleres Fehlerfinden

22. 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

23. 5.) Grundprinzipien • e) Qualitätsarbeit • ist wichtig für den Erfolg und die Motivation des Teams • also: qualitativ hochwertige Arbeit anstreben

24. 6.) Die 12 Praktiken bei XP

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 6.) Die 12 Praktiken bei XP • 8) gemeinsame Verantwortung • Code ist kein Privateigentum • jeder darf jeden Code jederzeit ändern

32. 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)

33. 6.) Die 12 Praktiken bei XP • 10) 40-Stunden-Woche • geregelte Arbeitszeiten sorgen für ausgeglichene Programmierer :o) und somit für bessere Arbeitsergebnisse

34. 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

35. 6.) Die 12 Praktiken bei XP • 12) Programmierstandards • gemeinsamer Programmierstandard sollte selbstverständlich sein (Coding standards) • vereinfacht die gemeinsame Verantwortung für den Code

36. 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

37. 7.) Vorteile, Nachteile • Vorteile: • dadurch: robuster, wartungsfreundlicher Code • Einhaltung der Qualitätsanforderung durch Refactoring • leichte Integration von Anfängern durch Pair-Programming

38. 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)

39. 7.) Vorteile, Nachteile • Nachteile: • konkurrierende Änderungen an gemeinsamen Klassen • XP bis jetzt unzureichend dokumentiert • bisher nicht nachgewiesen, daß XP anderen Strategien überlegen ist

40. 8.) Zielgruppe • kleine Projekte mit unklaren, sich immer wieder verändernden Anforderungen • kleine Gruppen von Mitarbeitern (10-15)

41. 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

42. Vielen Dank! • Viel Spaß beim Einsatz von XP!