Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Referat „Extreme Programming“

Ähnliche Präsentationen


Präsentation zum Thema: "Referat „Extreme Programming“"—  Präsentation transkript:

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

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 Viel Spaß beim Einsatz von XP!
Vielen Dank! Viel Spaß beim Einsatz von XP!


Herunterladen ppt "Referat „Extreme Programming“"

Ähnliche Präsentationen


Google-Anzeigen