Was ist unter eXtreme Programming zu verstehen? Springen dabei Entwickler mit hängenden Augenringen, ohne soziale Kontakte und einem Laptop vor den Bauch geschnallt Bungee? Oder handelt es sich beim XP um „hacking-as-usual“, ein fröhliches Cowboy-Hacking schick verpackt hinter einem provokanten, avantgardistisch anmutenden Terminus?
Die Antwort ist einfach – die Antwort ist: Nein. XP ist ein strenges, sehr viel Disziplin erforderndes Vorgehensmodell für die Softwareentwicklung, was durch aktuelle Probleme im Bereich der Softwareentwicklung motiviert frischen Wind in die Diskussion über den grundsätzlichen Ablauf eines Entwurfsprozesses bringen konnte.
Keine Frage – XP ist anders. Das X aber steht nicht etwa für eXtremes Verhalten oder eXtremes Loslassen vom Herkömmlichen. Es steht auch nicht für eXtremes Risiko oder eXtremen Erfolg. Das X steht für die eXtreme Intensität, die dieses Verfahren von seinen Partizipanten verlangt, eXtreme Identifikation mit den Werten und ein möglichst eXtremes Umsetzen der operativen, durch das XP geforderten Instrumente. EXtrem bezieht sich auf Disziplin und fordert Teamfähigkeit und Kompetenz – viel mehr als der Titel auf den ersten Blick zu suggerieren vermag.
Was genau man hinter XP zu verstehen hat und wo genau dessen Einflüsse auf die Qualität vom Endprodukt – der Software – vermutet werden können, das ist Aufgabe und primäres Ziel dieser Auseinandersetzung. Dem Leser soll bewusst werden, wo sowohl die Befürworter als auch die Widersacher des XPs argumentativ ansetzen, wenn es um die Verteidigung respektive dem Angriff von bzw. gegen XP geht. Es liegt hierbei sicherlich keine vollständige Abhandlung über XP vor; das meiner Meinung nach Wichtigste wird hier erörtert.
Um darüber hinaus das XP in die Welt der Softwarequalitätsbegriffe einordnen zu können, wird die Arbeit durch hinreichende Informationen zu diesem Thema mit einer strikten Hinführung zum XP begonnen.
Für wen leistet XP welchen Beitrag bezüglich der Qualität eines Softwareproduktes und wie verspricht es, dieses zu gewährleisten? Ziel der Abhandlung ist es, hierfür eine plausible Antwort zu finden.
Inhaltsverzeichnis
I) Einleitung
I.1) Problemstellung
I.2) Gang der Untersuchung
I.3) Anmerkungen zur Literatur
II) Software-Qualitätsbegriffe im Kontext der Arbeit
II.1) Qualität und Qualitätsmerkmale
II.2) Prozesse
II.2.1) Herkömmliche Verfahren
II.2.2) Agile Methoden
III) Extreme Programming
III.1) Grundlagen
III.1.1) Rollen in einem XP-Projekt
III.1.2) Werte
III.2) Überblick über die Techniken des XPs
III.2.1) Programmiertechniken
III.2.1.1) Einfaches Design
III.2.1.2) Refactoring
III.2.2) Interaktionstechniken
III.2.2.1) Testen
III.2.2.2) Programmieren in Paaren
III.2.2.3) Gemeinsame Verantwortung und Programmierstandards
III.2.2.3) Fortlaufende Integration
III.2.3) Integrations-Techniken
III.2.3.1) Kunde vor Ort
III.2.3.2) Planungsspiel
III.2.3.3) Metapher
III.2.3.4) 40-Stunden-Woche
III.2.3.5) Kurze Releasezyklen
IV) Kritische Auseinandersetzung mit XP
IV.1) Erfahrungen mit XP
IV.2) Kritik an XP
IV.3) Anwendbarkeit und Zukunft von XP
V) Schlussbemerkung
Zielsetzung & Themen
Die Arbeit untersucht, welchen Beitrag Extreme Programming (XP) zur Qualität eines Softwareproduktes leistet und wie dieser durch agile Vorgehensweisen gewährleistet wird. Ziel ist es, ein fundiertes Verständnis der XP-Methoden zu schaffen, um sowohl deren Potenziale zur Steigerung der Softwarequalität als auch die damit verbundene Kritik kritisch zu hinterfragen.
- Grundlagen der Software-Qualitätsbegriffe und deren Bedeutung in Entwicklungsprozessen.
- Detaillierte Analyse der XP-Werte und der zugehörigen operativen Techniken.
- Untersuchung des qualitativen Nutzens durch Programmieren in Paaren und Test-Driven Development.
- Kritische Reflexion der Anwendbarkeit von XP in verschiedenen Projektkontexten.
Auszug aus dem Buch
III.2.2.2) Programmieren in Paaren
Das Programmieren in Paaren stellt eine besondere Herausforderung des XPs dar, die bereits 1995 – also vor der Veröffentlichung des ersten Beitrages zum XP – diskutiert wurde. Kern dessen ist, dass zwei Entwickler sich einen Arbeitsplatz teilen und gemeinsam an einem Bildschirm, einer Tastatur und einer Maus an demselben Programmstück entwickeln. Dabei wird abwechselnd programmiert, wobei der unmittelbare Entwickler - der Driver – selbst nicht stumm vor sich hin kodiert, sondern seine Arbeit und seine Gedanken kommuniziert. Der jeweils andere, der Navigator, „[…] denkt über Vereinfachungen, neue Testfälle, alternative Lösungswege, Designalternativen etc. nach“ – er soll somit stärker strategische Aspekte berücksichtigen.
Wie Studien gezeigt haben, ist dieses Vorgehen, obwohl zwei Programmierer gemeinsam auf den ersten Blick deutlich langsamer sein mögen als bei der Einzelentwicklung, aus qualitativen Gesichtspunkten erheblich effektiver. Die Zeit, die für die Fehlerbehebung bei der Programmierung in Paaren durch das „Vier-Augen-Prinzip“ gespart wird, rechtfertigt den trügenden Schein des personellen Mehraufwandes. Dieser Angst ist zudem durch die Empirie mit hochinteressanten Erkenntnissen ebenfalls der Wind aus den Segeln genommen worden, so dass man heute zu der Meinung gelangt ist, dass zwei Programmierer auch mehr als das doppelte und qualitativ hochwertigere an Arbeit gegenüber der Einzelentwicklung schaffen.
Zusammenfassung der Kapitel
I) Einleitung: Definiert die Problemstellung und die Zielsetzung der Arbeit, die darin besteht, den Zusammenhang zwischen XP und der Qualität von Softwareprodukten zu klären.
II) Software-Qualitätsbegriffe im Kontext der Arbeit: Erläutert die Grundlagen der Softwarequalität und ordnet klassische sowie agile Vorgehensmodelle in den Entwicklungsprozess ein.
III) Extreme Programming: Detaillierte Darstellung des XP-Modells, seiner Rollen, Werte und der zwölf Techniken, unterteilt in Programmierung, Interaktion und Integration.
IV) Kritische Auseinandersetzung mit XP: Basiert auf Umfrageergebnissen zur Bewertung der XP-Techniken und analysiert die Vor- und Nachteile sowie die zukünftige Anwendbarkeit von XP.
V) Schlussbemerkung: Resümiert die Leitfrage und kommt zu dem Schluss, dass XP besonders bei unklaren Anforderungen und für die Gebrauchsfähigkeit einen hohen Mehrwert bietet, jedoch hohe Anforderungen an die Entwickler stellt.
Schlüsselwörter
Extreme Programming, Software-Qualität, Agile Methoden, Refactoring, Pair Programming, Test-Driven Development, Software-Entwicklung, Prozessmanagement, Kunden-Feedback, Iteratives Vorgehen, Programmierstandards, Qualitätssicherung, Software-Engineering, IT-Projektmanagement, Business Value
Häufig gestellte Fragen
Was ist das zentrale Ziel dieser Arbeit?
Das primäre Ziel ist es, den Beitrag von Extreme Programming zur Softwarequalität zu untersuchen und zu beantworten, für wen und unter welchen Bedingungen XP ein effektives Vorgehensmodell darstellt.
Welche wissenschaftliche Methode liegt der Arbeit zugrunde?
Die Arbeit basiert auf einer fundierten Literaturanalyse und einer kritischen Auseinandersetzung mit empirischen Studien, insbesondere einer globalen Befragung zu XP-Projekten von Rumpe und Schröder.
Welche Aspekte der Softwarequalität stehen bei XP im Vordergrund?
Im Fokus steht insbesondere die Gebrauchsfähigkeit, da durch die ständige Kundeninteraktion kurzfristige Anforderungen schnell umgesetzt und validiert werden können.
Warum wird Programmieren in Paaren empfohlen?
Das Programmieren in Paaren erhöht durch das Vier-Augen-Prinzip die Korrektheit und Wartbarkeit des Codes, fördert den Wissenstransfer im Team und reduziert die Fehleranfälligkeit.
Was ist die Rolle des Kunden in einem XP-Projekt?
Der Kunde ist ein aktives Teammitglied, das Prioritäten festlegt, Story-Cards mit definiert und durch kontinuierliches Feedback die Anforderungserfüllung sicherstellt.
Welche technologischen Voraussetzungen sind für XP typisch?
XP bevorzugt gut strukturierte, objektorientierte Umgebungen und erfordert eine hohe Disziplin der Entwickler sowie eine enge, ungehinderte Kommunikation.
Was ist das "Planungsspiel" innerhalb von XP?
Das Planungsspiel ist der Prozess, bei dem in informellen "Story-Cards" Systemanforderungen definiert und nach ihrem Geschäftswert (Business Value) durch den Kunden priorisiert werden.
Warum ist die "Metapher" bei XP oft schwierig umzusetzen?
Metaphern dienen dazu, komplexe technische Fachbegriffe greifbar zu machen. Da sie jedoch stark abstrakt sind und das Verständnis von allen Teammitgliedern erfordern, scheitern sie laut Studien oft an ihrer praktischen Anwendung.
Wie geht XP mit dem Risiko des "Big Upfront Design" um?
XP lehnt das Design auf Vorrat explizit ab und setzt stattdessen auf einfaches Design und die kontinuierliche Anpassung des Codes durch Refactoring.
- Quote paper
- Dipl.-Wirtsch.-Inf. (FH) Sven Sörensen (Author), 2004, Extreme Programming und Software-Qualität, Munich, GRIN Verlag, https://www.grin.com/document/39986
