First page Back Continue Last page Overview Graphics

Extreme Programming


Notes:

In den letzten Jahren wurde immer wieder Extreme Programming [Beck99] als Vorgehensweise vorgeschlagen und zum Teil euphorisch aufgenommen. Es handelt sich um ein stark auf die Aktivitäten der Implementierung konzentriertes Vorgehen, das mit einigen Prinzipien des klassischen Software Engineering bricht.
Im Grunde ist XP ein evolutives Vorgehen, denn Anforderungsermittlung und Entwurf entfallen im wesentlichen. Die daraus resultierenden Nachteile sollen durch Vorantreiben in sehr kleinen Schritten vermieden werden, deren Ergebnisse jeweils lauffähige Versionen der Software sind, die sich nur wenig von einander unterscheiden und immer vom Kunden abgenommen werden.
XP basiert auf bestimmten Techniken, genannt Praktiken. Wichtig ist, sie in ihrer Gesamtheit einzusetzen, da sie einander gegenseitig unterstützen und das Projekt sonst massiv bedroht ist:
Kleine Releases stellen die Grundidee des XP dar: Jedes Release wird geplant, implementiert und abgenommen, typischerweise ca. alle 3 Monate. Releases unterscheiden sich wenig und bestehen ihrerseits aus ca. 1 bis 3-wöchigen Iterationen, die sich aus 1 bis 3-tägigen Arbeitspaketen zusammensetzen. Arbeitspakete werden ebenso wie Iterationen vom Kunden abgenommen: Abweichungen & Fehler werden früh gefunden
Planspiel bezeichnet den Versuch, Benutzeranforderungen (sog. User Stories) auf kommende Releases aufzuteilen, bis ein Gleichgewicht zwischen Benutzerwünschen und Ressourcen gegeben ist.
Tests spielen in XP eine zentrale Rolle, zumal sie neben den User Stories die einzige Spezifikation darstellen. Sie müssen gemeinsam mit den User Stories definiert werden, sodass schlussendlich kein ungetesteter Teil der Software existiert.
Systemmetaphern sollen bei allen ein Verständnis der Materie durch Auswahl geeigneter Begriffe hervorrufen (z.B. „Fließband“, nicht „Pipelineing“). (Absichtlich?) verschwommen!
Der Einfache Entwurf ist die wichtigste Technik beim XP: „do the simplest thing that could possibly work“. Die Einfachheit der Lösung gilt als Voraussetzung für die Schnelligkeit der Lösung. Die technisch perfekte, allgemein wiederverwendbare, zukünftige Erweiterungen vorweg nehmende Lösung wird als sinnlos angesehen, weil sich die Anforderungen bis dahin ohnehin wieder verändert haben („lieber 80% morgen, als 100 nächste Woche“).
Refaktorisierung bezeichnet Maßnahmen zur Erhöhung der Software~ und insbesondere Entwurfsqualität ohne die Systemfunktionalität zu ändern. Z.B. kann durch Zusammenziehen von Funktionen in einer neuen Klasse die Kohäsion verbessert werden. Wichtig! Keine Erweiterung der Funktionalität ist zulässig! Natürlich muss sofort wieder intensiv getestet werden.
Zweierteams werden für alle Codiervorgänge gebildet, und zwar mit klarer Rollenverteilung: Einer coded, die andere liest gegen und sucht Fehler. Dadurch ergibt sich eine kontinuierliche Qualtitätssicherung. In regelmäßigen Abständen werden Rollen getauscht und Teams neu zusammengestellt.