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 Software Engineering SS 2009

XP – eXtreme Programming Was ist „extrem“? – alles, was sich bewährt hat wird „extrem“ betrieben Software Engineering SS 2009

XP – eXtreme Programming Hoffnungen: Kostenreduktion bei Änderungen Software Engineering SS 2009

XP – eXtreme Programming Bedeutung der Planung Software Engineering SS 2009

XP – eXtreme Programming 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 Software Engineering SS 2009

Software Engineering SS 2009 XP – Theorie die vier Variablen in XP-Projekten Kosten Qualität Zeit Umfang  „magisches Quadrat“ Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 XP – Theorie die vier (sieben) Werte von XP (Respekt) vor den anderen Projektmitgliedern (Interesse) am Lernen (Qualitätsbewußtsein) Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

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 Software Engineering SS 2009

XP – Projekteinteilung Vergleich verschiedener Methoden Software Engineering SS 2009

XP – Projekteinteilung 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. Software Engineering SS 2009

XP – Projekteinteilung 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 Software Engineering SS 2009

Software Engineering SS 2009 XP – Entwicklung Überblick Software Engineering SS 2009

Software Engineering SS 2009 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 Designwenig Aufwand bei Test und Refactoring Refactoring Verbesserung des Codes und des Designs keine neuen Funktionen, nur Verbesserung Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 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 Software Engineering SS 2009

Software Engineering SS 2009 XP – Grenzen Nachteile fehlendes Risikomanagement keine Dokumentationspflicht, die aber oft vom Gesetzgeber gefordert wird es kann schnell Chaos entstehen Software Engineering SS 2009