Im letzten Beitrag hatte ich ja schon das “Extreme Programming Manifest” erwähnt. Ich habe das Buch jetzt seit ein paar Tagen durchgelesen und muss ganz ehrlich sagen das dieses Buch in weiten Teilen deckungsgleich mit meine Vorstellung von Softwareentwicklung ist. Softwareentwicklung ist keine statischer, planbarer Prozess bei dem man am Anfang sagen kann wie ein System am Ende funktionieren soll. Man kann sich eine grobe Vorstellung machen, ein paar Ziele setzen aber der Versuch auf Basis eine Pflichtenheftes komplexe Systeme zu konzipieren ist meiner Ansicht nach zum Scheitern verurteilt.
Kent Beck, erläutert in seinem “Manifest” die Grundsätze von Extreme Programming. Dabei geht er genauso intensiv auf den Iterativen Entwicklungs- und Konzeptionsprozess ein, wie auf das Zusammenspiel von Teammitgliedern. Detailiert werden die verschiedenen Rollen wie Manager, Coach, Kunde und Entwickler differenziert. Dabei wird im Grunde nichts neues erfunden, vielmehr vergleicht Kent Beck die bestehenden und bekannten Rollen mit denen die es in einem XP Projekt geben sollte. Auch wenn das Buch stellenweise fast schon schwärmerisch von den Vorteilen des Extreme Programmings erzählt bleibt der Autor nicht der Warnung schuldig, dass XP in manchen Bereichen auch nicht anwendbar sein wird. So beschreibt er Situationen und Probleme die bei der Umstellung von “klassischer” Entwicklung auf XP passieren können.
Insgesamt rückt der Autor das Entwicklungsteam in den Mittelpunkt der Arbeit. Das interessante an dem Konzept ist die feste Integration aller Beteiligten in das Team. So werden Kunden, Manager und Entwickler nicht mehr getrennt sondern als “gleichberechtigte” Partner betrachtet. Kommunikation und Selbstverantwortung werden groß geschrieben und der Kunde ist nicht mehr einfach nur der König. Hier liegt meiner Meinung nach auch eine der größten Schwachstellen von XP. In der Theorie ist es sicher leicht zu sagen, das der Kunde sich dem Team anschließt und mit dem Entwicklern zusammenarbeitet, aber dazu ist die Voraussetzung das der Kunde das auch will und versteht warum er von seiner absoluten Position des “Zieldiktators” ablassen sollte.
Auch wenn man nicht mit allen Fakten von XP arbeiten will lohnt es sich das Buch zu studieren und die Ansätze aufzugreifen. Pair-Programming, Arbeitsraumgestaltung, Automatisierte Tests und iterative Entwicklung sind nicht auf XP beschränkt sondern sollten auch in “klassischen” Teams beachtet werden.
