Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 XP – eXtreme Programming Phänomene der Softwarekrise –Terminverzögerungen

Software Engineering SS 2009 Folie 1Prof. Dr. Gerhard Schmidtpres. by H.-J. Steffens

XP – eXtreme Programming

• Phänomene der „Softwarekrise“– Terminverzögerungen

– Projektabbruch

– Fehlerrate

– System wird unrentabel

– Geschäftsprozesse werden falsch verstanden

– Geschäftsprozesse ändern sich

– Falsche Funktionsfülle

– Personalwechsel

• Gegenmaßnahme: XP

• Ursprung: Daimler Chrysler



• 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


XP – Theorie

• 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 – Projekteinteilung

• 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



• 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


XP – Entwicklung

• Ü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 – Grenzen

• 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

Documents

Prof. Dr. Gerhard Schmidt pres. by H.-J. Steffens Software Engineering SS 2009Folie 1 XP – eXtreme Programming Phänomene der Softwarekrise –Terminverzögerungen