Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter

Größe: px

Ab Seite anzeigen:

Download "Referat Extreme Programming. Von Irina Gimpeliovskaja und Susanne Richter"

Johannes Buchholz
vor 8 Jahren
Abrufe

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 Kent Beck und Ward Cunningham dachten über bessere Entwicklungsstrategien nach Beck arbeitet beim Chrysler Projekt C3, heraus kam XP von Chrysler als gescheitert erklärt, aber von Beck übernommen

1996 - Beck arbeitet beim Chrysler Projekt C3, heraus kam XP

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

ständiges Testen sorgt für erstklassigen Zustand des

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

entwickeln kurze Releaszyklen beibehalten, damit

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

speziell zur Entdeckung und Beseitigung von

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

Lösen von zwanghaftem Vorausdenken Devise: lieber heute

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

Funktion Feedback des Kunden durch frühe Releases Feedback desjenigen,

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

durchzusetzten Änderungen an Programmen, die man nicht

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!

Ähnliche Dokumente

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann

Extreme Programming. Referat von Viktoria Schwarzhaupt und Andrea Schuhmann Extreme Programming Referat von Viktoria Schwarzhaupt und Andrea Schuhmann 1. Was ist XP - Prozessmodell für die objektorientierte Softwareentwicklung - leichter Softwareentwicklungsprozess Analyse Design