Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Ohne Disziplin ist das Chaos absehbar

Extreme Programming heißt Teamarbeit

09.07.2004
Die Softwareentwicklung auf Basis des Extreme Programming (XP) eignet sich nur für einen bestimmten Typ von Anwendungen und setzt aufgrund ihrer Teamorientierung sehr viel Erfahrung und Disziplin voraus. Von Dieter Masak*

Die Verfechter einer bestimmten Softwareentwicklungsmethode und religiöse Fanatiker ähneln sich. Beide glauben, im Besitz des einzigen glückselig machenden Wissens zu sein. Vertreter anderer Richtungen bezeichnen sie entweder als Scharlatane oder als schon lange überholt. Dennoch lässt sich für jede Softwareentwicklungsmethode ein Gegenbeispiel finden, für das diese nicht angemessen ist: so auch für Extreme Programming.

Vorbild Rapid Prototyping

Extreme Programming geht zu- rück auf Kent Beck, einen der Smalltalk-Gurus, und ist die logische Konsequenz aus dem bekannteren Rapid Prototyping zusammen mit den Best Practices aus der Smalltalk-Welt. Salopp ausgedrückt ist Extreme Programming der Endausbau des Rapid Prototyping und hat naturgemäß auch dessen Probleme geerbt. Das typische Verhalten, bei dem alle Arbeiten in sich oft wiederholenden Zyklen getätigt werden, ist aus dem Rapid Prototyping entlehnt.

Bezeichnenderweise hat, obwohl der Vater von XP aus der Smalltalk-Community stammt, die Methode nichts mit Objektorientierung zu tun. Das Vorgehensmodell hinter Extreme Programming ist auf jede Implementierungssprache anwendbar.

Im Extreme Programming wird stets alles in Teamarbeit gelöst. Zum Team gehört auch der Auftraggeber, der als Teil der Gruppe permanentes Feedback gibt. Neben einer langfristigen Planung kennzeichnen sehr kurze Release-Zyklen zusammen mit kontinuierlichem Testen die Methode. Das wohl augenfälligste Merkmal ist das Pair Programming. Hierbei wird der Code stets von zwei Programmierern bearbeitet. Einer der beiden codiert das Programm am Rechner, der andere begutachtet es simultan auf derselben Maschine. Oft wird Extreme Programming als ein "Low Level Approach" dargestellt, wobei die Methode jedoch verlangt, dass zwölf Handlungsanweisungen ("Practices") eingehalten werden (siehe Kasten "Zwölf XP-Gebote"). Nur wenn das gelingt, also alle Beteiligten sehr diszipliniert arbeiten, handelt es sich um Extreme Programming.

Zu finden sind XP-Projekte häufig im Bereich von Frontend-Entwicklungen. Dies ist sinnvoll, da es sich hier oft um kleine Projektgrößen handelt, denn allein die hohe Wechselwirkungsdichte zwischen den Teammitgliedern macht Projekte mit mehr als zehn Personen sehr schwer steuerbar. Auch die hohe Release-Rate ist nur für den kleinen Inhouse-Gebrauch als sinnvoll zu erachten. Bei zentralen Applikationen in großen Unternehmen sind die aus den häufigen Releases entstehenden Aufwände für das Konfigurations- und Distributions-Management nicht mehr zu tragen.

Extreme Programming tendiert zu sehr opportunistischen Systemen, ohne allerdings die Zukunftsfähigkeit solcher Lösungen sicherzustellen. Innerhalb des Verfahrens ist das auch nicht nötig, da der Code ohnehin nicht stabil bleibt. Damit ist XP jedoch wenig für die Entwicklung von Systemen geeignet, die auf Zukunftsfähigkeit ausgelegt sind, so zum Beispiel Software im Infrastrukturbereich oder für zentrale Geschäftsfunktionen eines Unternehmens. Allein die Vorstellung, jeden Tag eine Datenmodelländerung zu implementieren, ist für Datenbankadministratoren ein Schreckensszenario. Dementsprechend ist XP auch für datenbanklastige Projekte nicht zu empfehlen. Was bleibt, sind Frontend-Anwendungen, bei denen die fachliche Funktionalität und das Datenmodell sehr stabil sind und die durch das XP-Projekt nur minimal tangiert werden.

Die Handlungsanweisung, nur das Nötigste zu tun, basiert auf der Annahme, dass sich die Software schnell verändert und eine zukünftige Funktion sowieso völlig anders sein wird als die zum Zeitpunkt der aktuellen Entwicklung geplante. Spätestens das Jahr-2000-Problem hat jedoch gezeigt, dass Software durchaus länger im Gebrauch sein kann, als ursprünglich erwartet wurde.

Doch selbst wenn das Implementierungsgebiet für ein XP-Projekt sorgfältig ausgewählt wurde, existieren noch jede Menge Fallstricke. Am häufigsten wird vernachlässigt, dass Extreme Programming nicht nur disziplinierte, sondern auch methodisch sehr kompetente Mitarbeiter braucht.

Die Versuchung

Die Forderung nach geringem Overhead und schneller Implementierung verleitet Unternehmen dazu, den XP-Pfad mit dem Argument zu betreten: "Das Fehlen der expliziten Design- und Spezifikationsphase spart Geld und Ressourcen." Das klingt zwar verlockend, führt aber in der Praxis zu einem chaotischen Implementierungsmuster, an dessen Ende die Entwickler in einem Morast aus mangelnder Spezifikation, falschen Benutzererwartungen und schlechter Planung versinken.

Trotzdem lässt sich dieses Vorgehen leider immer häufiger beobachten. Die Practice des Pair Programming verführt unerfahrene Projektleiter dazu, jeweils einen Domänenexperten aus dem Fachbereich mit einem Entwickler als Paar zusammenzubringen. Doch diese Kombination leidet an mangelnder Qualitätssicherung. Die Entwicklung verläuft nach dem Motto "Vom Gehirn ins Ohr ins Gerät". Dieses Vorgehen ist letztlich die Kapitulation der Unternehmen vor der Unfähigkeit, sinnvolle und handhabbare Spezifikationen zu erzeugen.

Der zweite große Fehler, den man beim Pair Programming häufig beobachten kann, ist, zwei Neulinge als Paar arbeiten zu lassen. Funktionstüchtig ist Pair Programming nur dann, wenn mindestens ein Partner über ein hohes Maß an Erfahrung und sozialer Kompetenz verfügt. In diesem Fall kann eine solche Kombination sehr produktiv sein. (ue)

*Dieter Masak ist zuständig für Technologie bei der Plenum AG in Wiesbaden.

Hier lesen Sie ...

- woher Extreme Programming (XP) kommt;

- die Merkmale von XP;

- für welche Art von Entwicklungsprojekten sich die Programmiermethode eignet;

- mit welchen Hürden und Gefahren in XP-Projekten gerechnet werden muss.

Die Zwölf XP-Gebote

1. On Site Customer:

Der Kunde ist stets Teil des Teams und in die Tests involviert.

2. Systemmetapher:

Es gibt eine Metapher, die hinter dem ganzen Projekt steht.

3. Planning Game:

Explizite Planung der nächsten Schritte.

4. Inkrementelle und kleine Releases:

Originär aus dem Rapid Prototyping wird hier ein Weg beschritten, der zu einem permanent lauffähigen System führt.

5. Kontinuierliche Integration:

Sämtlicher Code wird täglich ins Gesamtsystem integriert.

6. Kontinuierliches Testen:

Bei der Erstellung einer Funktion muss auch der entsprechende Testtreiber programmiert werden.

7. Refactoring:

Jeder redundante Code wird sofort entfernt und überarbeitet (Refactoring).

8. Coding-Standards:

Das Team folgt beim Codieren einem gemeinsamen Standard.

9. Kollektiver Code:

Der Code gehört stets allen.

10. Einfaches Design:

Es wird immer das einfachste Design gewählt, nur die notwendigsten Anforderungen werden erfüllt.

11. 40-Stunden-Woche:

Die Arbeitszeit wird eingehalten. Keine Überstunden!

12. Pair Programming:

Jeweils zwei Entwickler programmieren an einem Arbeitsplatz zusammen.