Extreme Programming: XP Revisited

Rollen

Wie die meisten agilen Ansätze definiert XP relativ wenige Rollen:

  • Programmierer: Der Programmierer ist (nicht überraschend) „im Herzen von XP“. Diese Rolle wird in XP universeller interpretiert als in anderen Vorgehensmodellen und umfasst die intensive Kommunikation mit dem Kunden, die Mitwirkung im Planning Game und das Testen.
  • Kunde: Der Kunde trägt bei XP mehr und andere Verantwortung als bei phasenorientierten Vorgehensweisen, weil er immer im engen Kontakt mit Entwicklungsteam und Projekt steht und es fortlaufend durch Priorisierung der Stories steuern muss; er kann sich nie darauf zurückziehen, dass er seine Wünsche einmal aufgeschrieben habe und jetzt in Ruhe gelassen werden wolle.
  • Tester: Der Tester hilft dem Kunden bei der Festlegung funktionaler Tests, führt Regressionstests durch, dokumentiert Testergebnisse und betreut Testwerkzeuge.
  • Tracker: Der Tracker misst die Teamgeschwindigkeit, die Bug-Raten und erstellt Prognosen über den Iterationsverlauf.
  • Coach: Der Coach spielt hauptsächlich eine Rolle bei der Einführung von XP. Er achtet darauf, dass der XP-Prozess geordnet und rund verläuft, hilft den Teammitgliedern bei der Erfüllung ihrer Rollen und berät sie.
  • Consultants: Consultants sind Spezialisten, die abschnittsweise mitarbeiten und neues Wissen in das Team tragen.
Rezeption von XP

Kent Beck formulierte XP in seinem Buch aus dem Jahr 1999 auf weniger als 200 Seiten, mit einfachen Worten und in radikaler Klarheit. Da Beck in Fachkreisen bereits eine bekannte Persönlichkeit war, erregte XP einiges Aufsehen. Die darin enthaltene Botschaft kam insbesondere bei vielen Entwicklern gut an. Der Grundton und auch die starke Wirkung beim Publikum müssen vor dem Hintergrund der damaligen Stimmungslage gesehen werden.

Nachdem Ende der 80er und zu Beginn der 90er Jahre die Objektorientierung und interaktive, fensterbasierte Anwendungssysteme an Bedeutung gewonnen hatten, stellte sich Softwareentwicklung mehr denn je als eine Gestaltungsaufgabe dar – mit entsprechendem Zugewinn an Einfluss und Freiheit für die Entwickler. Herkömmliche Vorgehensweisen und Modellierungsmethodiken aus der Welt der Host- und Terminalanwendungen waren zur Bewältigung dieser Gestaltungsaufgabe nicht gut geeignet. In diese Lücke drangen zu Anfang der 90er Jahre unter anderem die UML-Vorläufer OMT, Booch-Methode und OOSE. Mit der Verschmelzung zur UML 1997 erhielten die geschwächten Verfechter formaler Verfahrensweisen standardisierte Darstellungsmittel für Anforderungen (Use Cases in Verbindung mit Aktivitätsdiagrammen) sowie Design (Klassendiagramm, Sequenzdiagramm etc.). Obwohl die UML selbst eine flexibel anwendbare und nicht auf einen phasenorientierten Prozess fixierte Modellierungssprache ist, wurde sie doch als Vehikel genutzt, um wieder mehr Vorschriften in den Entwicklungsprozess zu etablieren.

Das Pendel schwang jedenfalls zurück in Richtung Bürokratie. Ich kenne den Fall eines Unternehmens, dessen Methoden- und Verfahrenabteilung nur deshalb einen UML-basierten Codegenerator im Entwicklungsprozess installieren wollte, um die Verwendung der festgelegten Tools und die Einhaltung der vorgesehenen Phasen (erst Design, dann Implementierung etc.) zu erzwingen! Zur gleichen Zeit deutete sich erneut eine Tendenz zur Taylorisierung im Entwicklungsprozess an, weg von der „Softwaremanufaktur“ und hin zur „Softwarefabrik“. Die Idee lautete wie immer: Man trenne fein säuberlich in Projektleiter, Businessanalyst, Entwickler und Tester; dem Entwickler verbiete man am besten jedes Gespräch mit Kunden.

Die Softwareentwicklung wurde in der Folge – trotz der durch technologischen Fortschritt entstandenen neuen Herausforderungen und Möglichkeiten bei der Konstruktion von Softwareanwendungen – vielfach wieder in ein starres, unflexibles Korsett gepresst. Das frustrierte viele Entwickler. Da half es nicht, dass der die UML begleitende Entwicklungsprozess Unified Process von den Entwicklungsorganisationen meist viel rigider interpretiert wurde als es nötig war. In dieser Situation erschien XP auf der Bildfläche, widersprach entschieden dem Trend zur Bürokratisierung in der Softwareentwicklung und stellte die Arbeit des Entwicklungsteams und das solide Programmierhandwerk in den Mittelpunkt. Das Bild des Softwareentwicklers ist bei XP ganzheitlich und nicht in einzelne Teilaspekte aufgespalten. Das Entwicklungsteam nämlich übernimmt gemeinsam Verantwortung für seine Arbeit: Jeder spricht mit dem Kunden, jeder entwickelt die Architektur mit kontinuierlichen Refactorings weiter, jeder testet.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.