XP – eXtreme Programmingteam.fh-kl.de/uploads/media/Vorlesung7NG.pdfProf. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 20.04.10 1 Phänomene der „Softwarekrise“ Terminverzögerungen

20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 1

Phänomene der „Softwarekrise“TerminverzögerungenProjektabbruchFehlerrateSystem wird unrentabelGeschäftsprozesse werden falsch verstandenGeschäftsprozesse ändern sichFalsche FunktionsfüllePersonalwechsel

Gegenmaßnahme: XPUrsprung: Daimler Chrysler

XP – eXtreme Programming


Was ist „extrem“? – alles, was sich bewährt hat wird „extrem“ betrieben



Hoffnungen: Kostenreduktion bei Änderungen



Bedeutung der Planung



Vorteile der XP-Anwendung: Projektrichtung kann einfacher an Umfeld angepasst werden unklare Punkte können aufgeschoben werden (keine unsichere

Investitionen) Projekt kann mit Marktwachstum wachsen Bei Einstellung des Projektes besteht trotzdem ein funktionstüchtiges

Zwischenrelease Der Kunde bekommt den Featureumfang mit der von ihm gewollten

Priorität



die vier Variablen in XP-Projekten Kosten Qualität Zeit Umfang „magisches Quadrat“

XP – Theorie


die vier (sieben) Werte von XP Kommunikation:

mangelnde Kommunikation ist häufige Ursache für Scheitern eines Projektes

Förderung von Kommunikation (z.B. Pairprogramming, tägl. Meetings (im Stehen), Kommunikation mit dem Kunden)

Einfachheit: es wird die einfachste Möglichkeit gewählt, ein Problem zu lösen und nur

das wird realisiert.

Einfachheit reduziert Kommunikationsbedarf

erhöhte Kommunikation liefert „einfachere“ Lösungen

XP – Theorie


die vier (sieben) Werte von XP Feedback:

z. B. durch Partner beim Pairprogramming

durch automatische Modultests am Ende des Tages

der Kunde durch häufige Releases

Mut: jeder soll erkannte Probleme angehen, um den Erfolg des Projektes zu

sichern

es werden nur die Probleme angegangen, die momentan wirklich vorliegen

Eliminierung von überflüssigem Code

XP – Theorie


die vier (sieben) Werte von XP (Respekt)

vor den anderen Projektmitgliedern

(Interesse) am Lernen

(Qualitätsbewußtsein)

XP – Theorie


XP-Prinzipien Umsetzung der Werte in konkrete Anwendungsvorschläge Unterscheidung in primäre und sekundäre Prinzipien Primär:

unmittelbares Feedback

Streben nach Einfachheit

inkrementelle Veränderungen

Änderungen willkommen heißen

Qualitätsarbeit leisten

XP – Theorie


XP-Prinzipien Sekundär:

Lernen lehren

kleine Anfangsinvestitionen

Spielen, um zu gewinnen (keine Sanktionen bei schlechten Nachrichten)

gezielte Experimente

offene, ehrliche Kommunikation

Verantwortung übernehmen

an örtliche Gegebenheiten anpassen

ehrliches Messen

XP – Theorie


Rollen Kunde

aktive Mitarbeit

Vorgabe der Ziele (User-Stories auf Storycards)

Formulierung von Akzeptanztests

Kritikfähigkeit (Einfluss, aber keine Kontrolle) Entwickler, Programmierer

Teamfähigkeit: Teamerfolg steht über Einzelerfolg

Kommunikationsfähig und –bereitschaft

XP – Theorie


Rollen Coach

zuständig für Disziplin

Führen ohne zu bevormunden

zu starke Führung steht im Gegensatz zu den XP Prinzipien

Terminmanager verfolgt Projektstatus

sammelt Aufwand der einzelnen Personen

Reaktion und Einleitung von Gegenmaßnahmen bei Abweichungen vom Plan

Messen und Kontrollieren von Prozessleistungen

XP – Theorie


Rollen Projektmanager (untergeordnete Bedeutung)

präsentieren von Projektergebnissen Tester

Unterstützung des Kunden

eigentliche Aufgabe wird vom Programmierer erledigt Berater

Nebenrolle: ist Ansprechpartner bei technischen Problemen, die das Wissen der einzelnen Entwickler übersteigt

gefordert sind Generalisten, wenige Spezialisten

XP – Theorie


Release: Iterative Vorgehensweise Projektdauer wird in kurze Releasezyklen (einige Monate) unterteilt Kunde und Entwickler legen in Planungsspiel die Funktionen fest

(Releaseplan) Änderungen durch den Kunden sind explizit vorgesehen

Iteration: Release wird in Iterationen unterteilt (1- 3 Wochen) ->Iterationsplanung sehr viele lauffähige Zwischenreleases Software „reift“ unter Beobachtung des Kunden

XP – Projekteinteilung


Vergleich verschiedener Methoden



Planung Planung wichtig, aber nicht nur am Anfang Flexibilität im Umgang mit Kundenanforderungen haben Priorität Planung erfolgen iterationsbezogen Planung erfolgt im Planungsspiel

Kunde formuliert seine Anforderungen auf User Cards

Entwickler schätzt Aufwand ab.



Langzeitplanung nur in groben Zügen Stand up meeting

jeden Tag

5 Minuten

wer hat was gemacht, welche Probleme, nächste Schritte

keine Lösungen Planungsfehler Reduktion der Anforderungen Terminprobleme Reduktion des Umfanges nur 40 h –Woche, keine Überstunden Erhalt der Kreativität



Überblick

XP – Entwicklung


Design: konsequentes Refactoring gegen sich ändernde Kundenanforderungen Wegen häufiger Änderungen „einfaches Design“ nach 4 Regeln

einfaches Design muss alle Testanforderungen bestehen, die die Kundenanforderungen validieren

das Design muss jede Idee ausdrücken, die der Entwickler zum Ausdruck bringen muss

kein Programmcode darf doppelt vorhanden sein

das einfachste Design besitzt am wenigsten Klassen und Methoden einfaches Designwenig Aufwand bei Test und Refactoring

Refactoring Verbesserung des Codes und des Designs keine neuen Funktionen, nur Verbesserung

XP – Entwicklung


Programmierung Pairprogramming:

ein Entwickler codiert, der andere kontrolliert

Rollen werden gewechselt Erfahrungsaustausch

trotz Pairprogramming Kostenreduktion um 12 – 15%

Programmierstandards einheitliches Aussehen von Quellcodes

Testen Unit Tests

Entwickler verfassen Testspezifikation

Codierung bis alle Tests erfolgreich sind Akzeptanztest

Validierung der Kundenanforderungen

Verantwortlich: der Kunde

XP – Entwicklung


Voraussetzungen Unternehmenskultur keine risikobehaftete Projekte, da aus Sicherheitsgründen ständige

Releases nicht möglich kleine Teams (-12 Entwickler), sonst Kommunikations- und

Koordinationsprobleme Gewaltentrennung: geschäftliche Entscheidungen fällt der Kunde,

technische der Entwickler Persönlichkeitsprofil der Entwickler (hohe Sozialkompetenz,

Selbstdisziplin) erfahrenes Team automatisierte Tests

XP – Grenzen


Nachteile fehlendes Risikomanagement keine Dokumentationspflicht, die aber oft vom Gesetzgeber

gefordert wird es kann schnell Chaos entstehen

XP – Grenzen

Documents

XP – eXtreme Programmingteam.fh-kl.de/uploads/media/Vorlesung7NG.pdfProf. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 20.04.10 1 Phänomene der „Softwarekrise“ Terminverzögerungen