Zum Inhalt springen

Extreme Programming

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 21. Juni 2004 um 10:51 Uhr durch Jpp (Diskussion | Beiträge) (→XP Prinzipien). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Extreme Programming (XP) ist eine relativ neue Vorgehensweise in der Softwaretechnik. Dabei wird auf einen strikten Anforderungskatalog des Kunden verzichtet, dafür werden auch Kundenwünsche berücksichtigt, die sich noch während der Softwareentwicklung ergeben. Statt des klassischen Wasserfallmodells durchläuft der Entwicklungsprozess immer wieder in kurzen Zyklen (typ. eine Woche) sämtliche Diziplinen der klassischen Softwareentwicklung (Anforderungsanalyse, Test, Design, Implementierung). Nur die im aktuellen Iterationsschritt benötigten Features werden implementiert.

Die Methode hat die Erfahrung zum Hintergrund, dass der Kunde die wirklichen Anforderungen zum Projektbeginn meist noch nicht komplett kennt. Er fordert Features, die er nicht braucht und vergisst solche, die benötigt werden.

Duch ein Konglomerat aus verschiedenen Maßnahmen soll die Qualität und Flexibilität der Software soweit gesteigert werden, dass der Zusammenhang zwischen dem Zeitpunkt, wann eine Anforderung gestellt wird, und den damit entstehenden Kosten weitgehend linear ist.

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.

XP-Prinzipien

  • Pair-Programming (Zwei Programmierer teilen sich eine Tastatur und Monitor - einer codiert, einer denkt mit)
  • Integration der einzelnen Komponenten zu einem lauffähigen Gesamtsystem in kurzen Zeitabständen
  • Es werden erst die Unit-Tests geschrieben, bevor die eigentliche Funktionalität programmiert wird. Die Tests werden nach jedem Programmierschritt ausgeführt und liefern Rückmeldung über den Entwicklungsstand.
  • Enge Einbeziehung des Kunden, d.h. der Kunde gibt das Iterationsziel vor und hat sofort die Möglichkeit Akzeptanztests durchzuführen.
  • Laufende Refaktorisierung, ständige Architektur-Verbesserung
  • 40-Stunden-Woche, denn Überstunden mindern die Freude an der Arbeit und somit auch die Qualität des Produkts.

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


Abgerufen von „https://de.wikipedia.org/w/index.php?title=Extreme_Programming&oldid=1743049“