xp – extreme programmingteam.fh-kl.de/uploads/media/vorlesung7ng.pdfprof. dr. hans-jürgen...
TRANSCRIPT
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 2
Was ist „extrem“? – alles, was sich bewährt hat wird „extrem“ betrieben
XP – eXtreme Programming
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 3
Hoffnungen: Kostenreduktion bei Änderungen
XP – eXtreme Programming
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 4
Bedeutung der Planung
XP – eXtreme Programming
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 5
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 – eXtreme Programming
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 6
die vier Variablen in XP-Projekten Kosten Qualität Zeit Umfang „magisches Quadrat“
XP – Theorie
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 7
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 8
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 9
die vier (sieben) Werte von XP (Respekt)
vor den anderen Projektmitgliedern
(Interesse) am Lernen
(Qualitätsbewußtsein)
XP – Theorie
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 10
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 11
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 12
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 13
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 14
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 15
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 16
Vergleich verschiedener Methoden
XP – Projekteinteilung
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 17
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.
XP – Projekteinteilung
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 18
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 – Projekteinteilung
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 19
Überblick
XP – Entwicklung
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 20
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 21
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 22
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
20.04.10Prof. Dr. Hans-Jürgen Steffens Software-Engineering SS 2010 23
Nachteile fehlendes Risikomanagement keine Dokumentationspflicht, die aber oft vom Gesetzgeber
gefordert wird es kann schnell Chaos entstehen
XP – Grenzen