Extreme Programming
Wikipedia
http://de.wikipedia.org/wiki/Hauptseite
MediaWiki 1.7alpha
first-letter
Media
Spezial
Diskussion
Benutzer
Benutzer Diskussion
Wikipedia
Wikipedia Diskussion
Bild
Bild Diskussion
MediaWiki
MediaWiki Diskussion
Vorlage
Vorlage Diskussion
Hilfe
Hilfe Diskussion
Kategorie
Kategorie Diskussion
Portal
Portal Diskussion
Extreme Programming
52075
15599352
2006-04-12T16:19:17Z
Haeber
17333
Typo; Tippo
{{Überarbeiten}}
'''Extreme Programming''' ('''XP''') ist ein [[Vorgehensmodell (Software)|Vorgehensmodell]] in der [[Softwaretechnik]]. Sie wurde von [[Kent Beck]], [[Ward Cunningham]] und [[Ron Jeffries]] während ihrer Arbeit am [[Comprehensive Compensation System (C3)]] bei [[Chrysler]] entwickelt. Extreme Programming ist ein [[Iteration|iteratives]], evolutionäres und [[agiler Prozess|agiles]] Vorgehensmodell.
Die Methode berücksichtigt, dass der [[Kunde]] die wirklichen Anforderungen zum Projektbeginn meist noch nicht komplett kennt. Er fordert Features, die er nicht braucht, und vergisst solche, die er benötigt. In XP wird auf ein [[Pflichtenheft]] verzichtet. Der Entwickler berücksichtigt vielmehr Kundenwünsche, die sich während der [[Softwareentwicklung]] ergeben. Statt des klassischen [[Wasserfallmodell]]s durchläuft der [[Entwicklungsprozess]] immer wieder in kurzen Zyklen (typ. eine Woche) sämtliche Disziplinen der klassischen Softwareentwicklung (Anforderungsanalyse, Design, Implementierung, Test). Nur die im aktuellen Iterationsschritt benötigten [[Merkmal]]e werden implementiert.
Durch ein Mischung verschiedener Maßnahmen soll die Qualität und Flexibilität der Software gesteigert werden, so dass der Zusammenhang zwischen dem Zeitpunkt, wann eine Anforderung gestellt wird, und den damit entstehenden Kosten weitgehend linear ist.
[[Bild:Xpkurve.png|Kostenkurve]]
Bei einem weitgehend linearen Verlauf der Kostenkurve wird auf eine vollständige Erhebung aller Anforderungen zu Beginn des Projektes verzichtet. Stattdessen werden die sich erst im Laufe der Realisierung ergebenden Anforderungen mit berücksichtigt.
== Motivation ==
Software-Entwicklungsprojekte sind unterschiedlichen Gefahren ausgesetzt, für die Extreme Programming Lösungen anbietet.
* Unnutzbarkeit aufgrund von Programmierfehlern
*: Lösung: viele und frühe Tests
* Unnutzbarkeit aufgrund von Fehlentwicklung
*: Lösung: Kunde mit in den Entwicklungsprozess einbeziehen
* Unwartbarkeit
*: Lösung: viele und frühe Tests
* Zeitplan nicht einhaltbar
*: Lösung: nur Implementieren, was höchstes Nutzen/Aufwand-Verhältnis hat
* „Featuritis“ („''Vielleicht brauchen wir irgendwann einmal dieses oder jenes Feature …''“)
*: Lösung: Lass es! (vgl. auch [[YAGNI]])
== Grundlagen ==
Eine der theoretischen Grundlagen des Extreme Programming ist der Flexibilitätsgrad des zu entwickelnden Software-Systems. XP geht von einem mindestens proportionalen Zusammenhang zwischen dem Gegenteil der Flexibilität, der Steifheit, und den Pflege-Kosten zur Fehlerbehebung oder Erweiterung des Systems aus. Je flexibler ein Software-System, desto geringer sind die Pflege-Kosten, je steifer, desto höher.
Einige Steifigkeitskriterien:
* Zahl überflüssiger bzw. ungenutzter Features
* schlechte Dokumentation (fehlend, schwer verständlich, zu umfangreich)
* schwer verständlicher Entwurf
* steifer Entwurf
* fehlende Regressionstests
* schwerfälliges Gesamtsystem
Einige Flexibilitätskriterien:
* gute Dokumentation (vorhanden, leicht verständlich, vollständig aber nicht ausschweifend)
* leicht verständlicher Entwurf
* flexibler Entwurf
* Regressionstests
* leichtgewichtiges Gesamtsystem
Einige der als Bestandteil des ''Extreme Programming'' definierten Mechanismen dienen der ''Erhöhung der Flexibilität'':
* Die [[testgetriebene Entwicklung]] sorgt für ein ausreichendes Vorhandensein von [[Regressionstest]]s und eine verbesserte [[Testbarkeit]] der Software.
* Die ''ständige Refaktorisierung'' ([[Refactoring]]) sorgt für eine ''Entfernung überflüssiger Features'' und einen ''leicht verständlichen, flexiblen Entwurf'' und trägt zu ''guter Dokumentation'' bei.
* Die ''kontinuierliche Integration'' erfordert zwangsläufig ein ''leichtgewichtiges Gesamtsystem''.
== Nutzen ==
Dem ''Kunden'' bietet XP durch seine kurzen Iterationszyklen und durch die Release-Planung jederzeit die Möglichkeit, ''steuernd auf das Projekt einzuwirken''. Dieser Nutzen steigt für den Kunden noch mit der Projektgröße oder -dauer. Insbesondere soll dadurch erreicht werden, dass das Produkt sich aktuellen Anforderungen anpasst, statt nicht mehr aktuellen Anforderungen aus einer längst vergangenen Analysephase zu genügen und damit bereits bei Einführung veraltet zu sein. Zudem kann der Kunde bereits nach kurzer Zeit ein unvollständiges aber funktionstüchtiges Produkt einsetzen.
Dem ''Programmierer'' bietet XP durch seine ständig wechselnden Paare einen besseren Überblick über das Projekt und damit mehr Fachwissen sowohl über das Fachkonzept als auch die Technologien.
Der ''Projektleitung'' bietet XP durch die Einführung von Metriken bessere Steuerungsmöglichkeiten.
Sollte ein Projekt, z. B. aus Kostengründen, vorzeitig eingestellt werden, besteht durch die regelmäßigen Releases dennoch ein zumeist einsatzfähiges Produkt.
== Prinzipien ==
Extreme Programming ist charakterisiert durch folgende Prinzipien:
* Mut – ändere den Quellcode, wenn du denkst es muss so sein
* Respekt vor allen Mitgliedern im Team
* Kommunikation – sprich mit anderen im Team, um Informationen auszutauschen
* Kritik und andere Meinungen zulassen
* Kollektives Eigentum – jeder darf jederzeit jeden Quellcode verändern
* [[Pair-Programming]] – zwei [[Programmierer]] teilen sich Computer, Monitor, Tastatur und Maus – einer codiert, einer denkt mit (regelmäßig die Rollen tauschen, [[Vier-Augen-Prinzip]]).
* [[Integration]] der einzelnen [[Komponente]]n zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen (z. B. durch [[CruiseControl]]).
* [[Testgetriebene Entwicklung]] – es werden erst die [[Unit-Test]]s geschrieben, bevor die eigentliche Funktionalität programmiert wird. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand. Man spricht auch von [[Grey-Box-Test]]s.
* Enge Einbeziehung des Kunden, d. h. der Kunde gibt das [[Iteration|Iterationsziel]] mit Hilfe sogenannter [[Story-Card|''Story-Cards'']] vor und hat sofort die Möglichkeit [[Akzeptanztest]]s durchzuführen. "Story-Cards" beschreiben Anwendungsfälle exemplarisch in Form kurzer Geschichten. Der Kunde muss allerdings sehr oft anwesend oder zumindest greifbar sein.
* Laufende [[Refaktorisierung]], ständige [[Softwarearchitektur|Architekturverbesserung]]
* ''40-Stunden-Woche'', d. h. Überstunden sind zu vermeiden, weil darunter die Freude an der Arbeit, mittelfristig die Konzentrationsfähigkeit der Programmierer und somit auch die Qualität des Produkts leidet.
* Kurze [[Release]]-Zyklen, um dem Kunden in regelmäßigen Zeitabständen einen lauffähigen Zwischenstand des Produkts zu liefern.
== Kritik ==
XP erfordert ein [[Projektmanagement]], das in der Lage ist, Metriken auszuwerten und sorgfältig zu interpretieren sowie frühzeitig zu kommunizieren und frühzeitig Entscheidungen zu fällen, andernfalls können bei XP Aufwandsschätzungen und realer Aufwand auseinanderlaufen.
== Literatur ==
* Kent Beck: ''Extreme Programming – das [[Manifest]]. Die revolutionäre Methode für Softwareentwicklung in kleinen Teams'', Addison-Wesley, 2000; ISBN 3-8273-1709-6
* Alistair Cockburn: ''Agile Softwareentwicklung'', mitp, ISBN 3-8266-1346-5
* [[Martin Fowler]]: ''Refactoring'', Addison-Wesley, ISBN 3-8273-1630-8
* Stefan Richter: ''Feature-based Programming'', Addison-Wesley, ISBN 3-8273-2077-1
* Scott W. Ambler, Ronald E. Jeffries: ''Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process'', Wiley, John & Sons, ISBN 0471202827
== Siehe auch ==
* [[YAGNI]]
* [[Die Kathedrale und der Basar]]
== Weblinks ==
* [http://www.agilemanifesto.org/ Agiles Manifest] (englisch)
* [http://eeto.org/2005/10/japanische-wirtschaft/ict/softwaereentwicklung-und-senioritaet-warum-extreme-programming-in-japan-nicht-funktioniert/ Warum Extreme Programming in Japan nicht funktioniert]
* [http://www.xp-diary.de XP-Tagebuch], ein Tagebuch von Entwicklern, die Extreme Programming betreiben.
[[Kategorie:Vorgehensmodell (Software)]]
[[ca:Programació Extrema]]
[[cs:Extrémní programování]]
[[en:Extreme Programming]]
[[es:Programación Extrema]]
[[fr:Extreme programming]]
[[he:XP]]
[[it:Extreme Programming]]
[[ja:エクストリー ・プログラミング]]
[[lt:Ribinis programavimas]]
[[nl:Extreme Programming]]
[[no:Extreme Programming]]
[[pl:Programowanie ekstremalne]]
[[pt:Programação extrema]]
[[ru:Экстремальное программирование]]
[[sv:Extrem programmering]]
[[zh:极限编程]]
Diese Version des Artikels stammt vom 13.04.2006.
Der Inhalt dieser Seite basiert auf dem Artikel
„Extreme Programming“ aus der freien Enzyklop�die
Wikipedia und ist unter der
GNU-Lizenz f�r freie Dokumentation ver�ffentlicht. Auf der Wikipedia-Seite ist eine
Liste der Autoren einzusehen.
