Praktiken des Extreme Programming (XP)

· Paarprogrammierung

· Testgetriebene Entwicklung

· Inkrementeller Entwurf durch Umstrukturierungen

· Iterative Planung in kurzen Zyklen (Planungsspiel)

· Aktive Beteiligung des Kunden

· Fortlaufende Integration

· Programmierrichtlinien

· Gemeinsamer Quelltextbesitz

· Textuelle Beschreibung der Anwendungsfälle auf Karteikarten

· 40-Stunden-Woche

 

Paarprogrammierung

· Jede Programmiertätigkeit wird im Paar ausgeführt

· Arbeit an einer Tastatur, einer Maus und einem Bildschirm

· Rollenverteilung: Fahrer und Beifahrer

o Fahrer denkt an Implementierung

o Beifahrer denkt strategisch, führt ständige Durchsicht durch

· Führt zu nachweisbarer höherer Qualität des Programmtextes

· Paarprogrammierung kompensiert für fehlende Inspektionen/Reviews.

· Strittig:

o Vorteil gegenüber Einzelprogrammierung plus Inspektionen ist nicht nachweisbar

o Kosten verdoppeln sich nahezu

o Nützt eher unerfahrenen Entwicklern

Effizientes Testen

· Möglichst zeitnah zur Programmierung

· Automatisiert und damit wiederholbar

· Soll Spaß machen

· Testen so oft und so einfach wie Übersetzen

· Fehler finden, nicht Fehlerfreiheit beweisen

Testen bei XP

· „any programm feature without an automated test simply doesn´t exist”

· Programmierer schreiben automatische Komponententests

· Kunde spezifiziert Akzeptanztests, die das Team implementiert

· Andere Testarten auch möglich, z.B. Stresstest

· Testausführung häufig und automatisch

Komponententests

· Werden vom Entwickler selbst geschrieben

· Geben konkretes Feedback und Sicherheit

· Ermöglichen sichere Änderungen

· Sichern Erhalt der vorhandenen Funktionalität

· Müssen bei jeder Code-Integration zu 100% laufen

Akzeptanztests

· Werden von Kunden spezifiziert

· In seltenen Fällen auch vom Kunden selbst geschrieben

· Testrahmenwerke helfen dabei wie FIT oder das Robot Framework

· Müssen spätestens bei Auslieferung laufen

· Erhöhen zusammen mit Komponententests das Vertrauen des Kunden in das Produkt

Testgetriebene Entwicklung

· Test/Implementierung/Umstrukturierung: Motiviere jede Verhaltensänderung am Quelltext durch einen automatisierten Test

· Umstrukturierung und einfacher Entwurf: Bringe den Code immer in eine einfache Form

· Häufige Integration: Integriere den Code so häufig, wie möglich

· Paarprogrammierung: Soll helfen die Regeln der testgetriebenen Entwicklung einzuhalten

· Testcode vor Anwendungscode schreiben

· Kleine Schritte (nicht mehr als eine Methode pro Zyklus)

· Inkrementeller Entwurf (nur so viel, wie gebraucht wird; kein vorausschauender Entwurf)

Rolle der Komponententests

· Tests zur Qualitätssicherung: Die Tests sichern die vorhandene Funktionalität

· Test-Zuerst-Entwicklung führt zu „Evolutionärem Entwurf“: Der Entwurf entsteht Stück für Stück

· Test zur Schnittstellendefinition: Test verwendet schon Klassen und Methoden bevor sie überhaupt ausprogrammiert sind (Stummel nötig)

· Tests zur Modularisierung: Testbarkeit erfordert Entkopplung der Programmteile

· Tests als ausführbare Spezifikation und Dokumentation (kompensieren für fehlende Entwurfsphase)

 

Umstrukturierung (Refactoring)

· A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior

· Voraussetzungen:

o Automatische Tests: sie stellen lauffähiges Produkt nach Umstrukturierung sicher

o Kollektiver Code-Besitz: Änderungen am ganzen Produkt für jeden möglich

· Ziel: Stets eine möglichst einfache Form, die für die bisher implementierten Anforderungen ausreicht (kein änderungsfreundlicher, vorausschauender Entwurf nötig)

· Die einfache Form ist erreicht, wenn der Code

o Alle seine Tests erfüllt

o Vom Zielpublikum verstanden werden kann

o Jede Intention der Programmierer ausdrückt

o Keine duplizierte Logik enthält

o Möglichst wenig Klassen und Methoden umfasst

o Reihenfolge entscheidend

· Soll Produktivität erhöhen

· Durchgeführt an faulen Gerüchen des Programmtexts

o Duplizierter Programmtext

o Parallele Vererbungsbäume

o Schrotflintenchirurgie: eine neue Funktion erfordert Änderung an vielen Stellen

o Kommentare zu umfangreich (Variablen besser benennen, Codestücke herausziehen und in Methoden verpacken)

 

 

Inkrementelles Design

· Konventioneller Ansatz: “Implement for today, design for tomorrow.”

· XP Einsatz: “The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered”

· Kleine inkrementelle Entwurfsschritte statt großer –Entwurfsphase

Planungsspiel

· Ziel: Planung vom Umfang, Zeit und Kosten

o Der nächsten Iteration (wöchentlicher Zyklus)

o Des nächsten Auslieferung (vierteljährliches Zyklus)

· Ständige Korrektur des Planes

Kompetenz beim Planungsspiel

· Der Kunde trifft die geschäftsrelevanten Entscheidungen

o Umfang des Systems

o Prioritäten von Funktionalität

o Zusammensetzung einer Auslieferung

o Datum der Auslieferung

· Das Entwicklungsteam trifft die technischen Entscheidungen

o Schätzung von Kosten und Risiko

o Technische Konsequenzen

o Entwicklungsprozess

o Ablaufplanung

· Der Kunde kann seine Entscheidung jederzeit korrigieren

Auslieferungsplanung

· Ersetzt konventionelle Anforderungsanalyse

· Planungszeitraum: 1-4 Monate

· Ungefährer Projektplan wird vom Kunden und vom Entwicklungsteam gemeinsam erstellt

o Kunde äußert seine Wünsche

o Team schätzt die Kosten und Risiken

o Kunde priorisiert seine Wünsche

o Gesamtes Team stellt Zeitplan für die wichtigsten Kundenwünsche auf

Iterationsplanung

· Findet mehrmals zwischen Planung und Auslieferung statt

· Planungshorizont: 1-4 Wochen

· Alle Aufgaben werden auf Aufgabenkarten notiert:

o Aufteilung von Anwendungsfällen in kleineren Aufgaben

o Zusammenlegen zu kleineren Aufgaben

o Identifizierung zusätzlicher Aufgaben

§ Prototypen

§ Versionshaltung

§ Etc.

· Teammitglied übernimmt Aufgabe und schätzt Aufwand für diese Aufgabe

· Ausgleich zwischen Teammitgliedern

· Rückkopplung zum Kunden

Kunde vor Ort

· Echter Kunde ist jemand, der das Produkt später wirklich nutzen soll

· Kunde sollte ständig verfügbar sein

· Der Kunde sollte im selben Raum arbeiten wie Entwicklerteam

· Ist in der Praxis nicht ganz leicht zu erreichen, und Kunde ist unterausgelastet

Behauptung des Kent Becks

· Bei konventionellem Entwicklungsprozess steigen die Kosten für Änderungen exponentiell mit der Zeit.

· Für den XP verläuft die Kurve dagegen asymptotisch.

· FRAGWÜRDIG!

Kritik an XP

· Asymptotische Kostenkurve beruht auf der Erfahrung einzelner

· Fehlende Produktdokumentation

· Nicht reproduzierbarer ad-hoc Prozess

· Paarprogrammierung ist kostenintensiv, unklar ob dies durch den Zuwachs an Qualität kompensiert wird

 

 

Probleme bei der Einführung von XP

· Kunde muss mitarbeiten und dies auch wollen

· Softwareingenieure sind auf Vorausschau getrimmt. Folge kann sein:

o Zu komplexer Entwurf

o Zu umfangreicher Entwurf

· Testgetrieben Entwicklung erfordert umdenken und umlernen

· Gleiche Wellenlänge bei Paarprogrammierung

· Respekt vor fremdem Programmtext

Bewertung von XP

· XP = Programmieren durch Probieren?

· Nein,

o Planungsschritte

o Forderung nach erfolgreichen Tests

o Testgetriebene Entwicklung und Restrukturierung kompensieren für fehlende Entwurfsphase

o Paarprogrammierung kompensiert für fehlende Inspektionen

· Cowboy-Programmierer diszipliniert

· Spektrum des Planens

o XP: leichtgewichtige änderbare Planung

o Wasserfall: schwergewichtige, feste Planung

Zusammenfassung

· XP ist Softwareprozess

o Geeignet für vage und sich schnell ändernde Anforderungen

o Für kleines Entwicklerteam (10)

o Ohne Zeitraubenden Verwaltungsaufwand

· Softwareentwicklung mit leichtem Gepäck

· Bei großen Projekten sind zumindest eine Anforderungsphase und eine Entwurfsphase erforderlich, die die Gesamtaufgabe so aufteilt, dass XP-Teams unabhängig voneinander arbeiten können.

Empirische Studien zu XP

Paarprogrammierung versus…

· Partnerprogrammierung (PP)

· Einzelprogrammierung

· Einzelprogrammierung mit Durchsichten (ED)

Hypothesen

· Null-Hypothesen

o H0_Korrektheit: Die Korrektheit der mit Einzelprogrammierung und Durchsicht erstellten Programme ist höher als oder gleich derer, die mit Paarprogrammierung erstellt wurden.

o H0_Kosten:Die Kosten für PP sind geringer oder gleich als die Kosten für ED

· Forschungs-/Alternativhypothesen

o H1_Korrektheit: Die Korrektheit der mit ED erstellten Programme ist geringer als die, die mit PP erstellt wurden

o H1_Kosten:Die Kosten für PP sind höher als die Kosten für ED.

Übersicht

· Experiment durchgeführt SS 2002/03

· Gegenbalancierter Experimententwurf

· Teilnehmer: Studenten des XP Praktikums

· Java

· Vorstellung von Paarprogrammierung und Durchsichten

· Aufgaben

o Lösen eines Schiebepuzzles (SP)

o Berechnen der Nullstellen eines Polynoms 3. Grades (Pol)

Warum eine Qualitätssicherungphase?

· Programme vor Qualitätssicherungsphase durch Faktor „Sorgfalt beim Testen“ beeinflusst

· Schlechte Programme kann man schnell schreiben

· Die Qualitätssicherungsphase gleicht die Korrektheit der Programme an

· Damit ist der Vergleich von etwa gleich guten Programmen möglich

· Hilfsmittel: automatischer Akzeptanztest

Ergebnisse Kosten

· Gesamt: Paare sind etwa 7 Prozent teurer bei vergleichbarer Korrektheit

· Implementierung: Paare sind etwa 13 Prozent teurer, entwickeln aber Programme, die 29 Prozent mehr Testfälle bestehen

· Unterschiede statisch nicht signifikant

· Qualitätssicherungsphase erfüllt ihren Zweck: vergleichbare Korrektheit der Programme

· Programme der PP Gruppe nach Entwicklungsphase (ohne Qualitätssicherungsphase) tendenziell besser; 29% mehr Testfälle bestanden

Fazit

· Keine der Null-Hypothesen kann abgelehnt werden.

· Einzelprogrammierung mit Durchsichten scheinen etwas billiger zu sein

· Paarprogrammierung und Einzelprogrammierung mir Durchsichten sind austauschbar.

Weitere quantitative Ergebnisse zur Paarprogrammierung

· Arisholm 2007

o Teilnehmer: 295 Java Berater

o Aufwand für Paarprogrammierung ist 84% höher als für Einzelprogrammierung

o Unterschied zwischen Einzel- und Paarprogrammierung bzgl. Dauer, aufwand und Korrektheit der Programme hängt von der Komplexität ab

§ Beim komplexen Systemen liefern die Paare 48% mehr korrekte Lösungen

o Einfluss der Kompetenz der Programmierer auf die Effizienz der Paarprogrammierung konnte nicht nachgewiesen werden

· Dyba 2007

o Meta-Studie (Studie über Studien)

o Fasst 15 Studien zusammen

o Enthält einige der zuvor genannten Studien

o PP +Qualität +Dauer -Aufwand

Stand Paarprogrammierung

· Programmierer im Paar müssen aufeinander abgestimmt sein

· Beste Arbeitsteilung unbekannt

· Vorteil bei Qualität und Dauer

· Nachteil beim Aufwand

· Einfache Fehler werden vom Paar schneller entdeckt als vom einzelnen. Schwierige nicht.

Erfahrungen mit testgetriebenen Entwicklung

· Ist ungewohnt und schwer zu erlernen, da neue Denkweise

· Gewöhnung dauert eventuell Monate

· Studenten: Automatisches Ausführen von Tests ist optimales verfahren

· Gefahr: Falsches Gefühl der Sicherheit

o Durch erfolgreiche Testfälle erzeugt

o Verhindert das Schreiben zusätzlicher Testfälle

Empirische Studien zur Effektivität von Softwaretechniken

· Es gibt zu viele Methoden und Werkzeuge in der Softwaretechnik, als dass jeder Entwickler oder jedes Softwarehaus sie alle ausprobieren könnten

· Selbst wenn, dann wären die Ergebnisse eher vom Zufall bestimmt

· Statt dessen benutzt man kontrollierte Experimente

o Kontrollgruppe benutzt alte Methode

o Experimentgruppe die neue Methode

o Statistische Vergleich der Ergebnisse auf Unterscheide in Produktivität oder Software-Qualität

Scrum – Artefakte

· Anforderungsliste

o Enthält die Produktanforderungen und eine Liste aller Projektarbeiten

o Die Anforderungen werden vor jedem Sprint durch den Auftraggeber priorisiert

· Aufgabenliste – enthält elle aufgaben, die zur Erfüllung des aktuellen Sprint-Ziels notwendig sind, inklusive einer kurzen Beschreibung

· Hindernisliste – enthält alle Hindernisse des Projektes, die der Scrum Master zusammen mit dem Team bespricht und versucht, diese auszuräumen.

 

 

Scrum Rollen

· Auftraggeber

o Legt die Anforderungen an das Produkt fest sowie dessen Auslieferungstermin

o Stellt das Budget zur Verfügung und akzeptiert bzw. lehnt Arbeitsergebnisse ab.

o Priorisiert Anforderungen und passt Anforderungen sowie deren Priorität für jeden Sprint an.

· Scrum Master

o Stellt die Einhaltung der Scrum-Werte und techniken sicher.

o Sorgt dafür, dass das Entwicklungsteam vollständig, funktional und produktiv ist und stützt das Entwicklungsteam vor äußeren Störungen

o Beseitigt Hindernisse und unterstützt die Zusammenarbeit zwischen allen Rollen

· Entwicklungsteam

o Besteht aus Personen mit unterschiedlichen Fachgebieten (Programmierer, UI designer…) und organisiert sich selbst.

o Zusammenstellung eines Teams ändert sich in einem Sprint nicht.

Scrum-Treffen

· Sprintplanung

o Das Entwicklungsteam wählt die Anforderungen aus den Produktanforderungen aus, die es in diesem Sprint erledigen kann und erstellt zusammen mit dem scrum Master die Aufgabenliste

· Tägliches Scrum-Treffen

o Jedes Mitglied des Entwicklungsteam beantwortet folgende Fragen:

§ Was hast du gestern getan?

§ Was wirst du heute tun?

§ Welche Hindernisse sind in deinem Weg?

· Review-Treffen am Ende eines Sprints

o Das Entwicklungsteam stellt Ergebnisse des Sprints vor, z.B. in Form einer Demonstration der neuen Features

o Keine Folien!

· Retrospektive

o Der zurückliegende Sprint wird analysiert

o Teilnehmer sind das Entwicklungsteam, der Scrum Master, der Auftraggeber sowie evtl. der Endkunde