Extreme Programming - eine Einführung

Teil 3:
Entwicklungsverfahren, Rollen im Projekt und Erfahrungen

Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Der zweite Teil stellte nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen in diesem dritten Teil die Einführung ab.

Extreme Programming - eine Einführung

Teil 3:
Entwicklungsverfahren, Rollen im Projekt und Erfahrungen

Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Der zweite Teil stellte nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen in diesem dritten Teil die Einführung ab.

In den ersten beiden Teilen dieser Serie standen die Grundlagen und Prinzipien von Extreme Programming (XP) sowie die Historie und die Verfahren zur Projektplanung im Vordergrund. Der abschließende dritte Teil dieser Einführung erläutert die Verfahren, die XP zur Softwareentwicklung einsetzt, stellt die besondere Verteilung der Rollen im Projekt vor und berichtet über Erfahrungen und die Bedeutung von XP.

Entwicklungszyklus

Der Arbeitszyklus der Entwicklung in Extreme Programming besteht aus vier Phasen: Zuhören, Testen, Codieren, Design.

  • Zuhören findet während des gesamten Projekts statt, vor allem aber am Anfang beim Erstellen und Behandeln der Stories mit dem Kunden.
  • Testen kommt vor dem Code. XP fordert automatische Tests, die vor jedem Codieren erstellt und während jeder Integration ausgeführt werden.
  • Code wird nach dem Testcode, aber vor großen Designaktivitäten erstellt. Der Code wird so einfach wie irgend möglich erstellt und dann geändert, bis die Testfälle funktionieren.
  • Design findet überwiegend nach dem Codieren durch Refactoring statt, oder durch Refactoring anderer Systemteile als Vorbereitung des neuen Codes. Wenn eine Klasse funktioniert, wird sie und auch der Rest des Systems solange geändert, bis die gesamte Funktionalität durch das verständlichste und einfachste denkbare Design erzielt wird.

Dieser Entwicklungszyklus unterscheidet sich von anderen Prozessen und ist auf Risikovermeidung und Feedback getrimmt. Vor allem fallen der späte Zeitpunkt und die ungewöhnliche Methode des Designs auf. Durch diesen späten Zeitpunkt wird das Projekt nicht durch komplexe Strukturen gebremst, die später vielleicht doch nicht benötigt werden. Andererseits wird das Design nicht übergangen, sondern hat seinen festen Platz und findet unter hohen Qualitätsmaßstäben statt. Letztlich mindert dieser Designprozess das Projektrisiko, da Funktionalität früh sichtbar und immer erweitert wird.

Projekte, die Design hauptsächlich durch Refactoring betreiben, vermeiden effizient eine frühe Paralyse durch Überdesign, müssen allerdings der Versuchung widerstehen, mit Fertigstellung der Funktionalität auch den Code für fertig zu erklären. Vielmehr muss der Code jetzt noch einem Design unterzogen werden, damit im Sinne eines aufgeräumten Arbeitsplatzes die Software bereit ist, die nächste Funktionalität aufzunehmen. Besonders umfangreiche Refactoring-Maßnahmen fließen als eigene Entwicklungsaufgaben in die Planung ein.

Auch in Extremen Projekten findet ein grobes Design vor der Implementierung statt, zum Beispiel in Diskussionsrunden oder CRC-Kartensitzungen. Die so entwickelten Designideen können als Leitlinien zur Implementierung dienen, müssen aber als spekulativ angesehen werden, solange bis der Code über ihre Gültigkeit entscheidet.

Eine CRC-Karte ist eine Karteikarte, die für eine Klasse (Class) ihren Namen, ihre Zuständigkeiten (Responsibilities) und die benötigten Kooperationspartner (Collaborations) enthält. Diese Karten dienen als Medium für Designdiskussionen.

In einer CRC-Kartensitzung werden die Karten handschriftlich erstellt. Das Durchlaufen von Abläufen und Szenarien, z.B. in der Form eines Rollenspiels, führt zu einer schrittweisen Verfeinerung der Zuständigkeiten und Kooperationen.

Die Karten werden mit der Hand geschrieben, um das Ändern zu erleichtern und die Hemmschwelle zum Wegwerfen nicht ausgereifter Ideen herabzusetzen. Ein Tool würde mehr Zeit erfordern und die Diskussion behindern. Zudem werden die Karten später nicht als Dokumentation benötigt.

Entwicklungsverfahren

Im Gegensatz zu den Planungsverfahren von Extreme Programming, bei denen Kunden und Entwickler eng zusammenarbeiten, betreffen die Entwicklungsverfahren primär den täglichen Zyklus der Entwickler. Kunden können und müssen diesen allerdings an einigen Stellen unterstützen.

  • Kunde vor Ort
    Ein Schlüsselelement von XP ist die Kommunikation zwischen Kunden und Entwickler. Dazu muss ein Kunde mit dem Team zusammensitzen, arbeiten, in denselben Meetings sein und jederzeit Rede und Antwort stehen können.
  • Metapher
    Die Metapher ist eine kurze Beschreibung, was das System tun soll und wie. Sie wird als Schlagwort, Geschichte oder Sammlung der zentralen Klassen ausgedrückt, damit sie allen Teammitgliedern geläufig ist. Sie dient somit als stark zusammengefasste Systemarchitektur und prägt mittelbar jede Implementierungsentscheidung.
  • Programmieren in Paaren
    Der relevante Code wird in XP von zwei Programmierern entwickelt, die zusammen an einem Computer sitzen. Diese wechseln sich nach locker vorgegebenen Regeln am Steuer, also an der Tastatur, ab. Die Zusammensetzung der Paare erfolgt direkt von den Entwicklern. Die Paare werden immer wieder gewechselt und häufig aus Entwicklern unterschiedlicher Erfahrung zusammengesetzt. Die Zusammenarbeit und das Feedback ersetzt andere Maßnahmen wie zum Beispiel formale Code-Reviews.
  • Zuerst testen
    Das Testen ist Voraussetzung für die Qualität des Codes und das Vertrauen der Entwickler wie des Kunden darin. Ein fehlschlagender Test hilft auch bei der Fokussierung auf die anstehende Aufgabe. Daher setzt XP den Test zeitlich noch vor den Code. Tests sind auch nötig für das Refactoring-Verfahren.
    Extreme Programming unterscheidet Funktionstests oder Akzeptanztests, die auf Basis der User Stories entstehen und parametrierbar sein sollten, und Unittests, die sich auf Klassen und Entwicklungsaufgaben beziehen. Alle Tests sind selbstprüfend, das heißt, dass nach Ablauf des Tests keine Ausgabelisten oder GUI-Reaktionen manuell mit einem Sollwert verglichen werden müssen. Die Tests prüfen selbst während ihres Ablaufs das tatsächliche gegen das erwartete Ergebnis und geben ein eindeutiges,…

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 0

Fortsetzungen des Fachartikels

Teil 1:
Grundlagen und Prinzipien von Extreme Programming
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche …
Teil 2:
Einsatzgebiete und Ziele
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche …
Alle anzeigen