Grin logo
de en es fr
Shop
GRIN Website
Publish your texts - enjoy our full service for authors
Go to shop › Computer Science - Programming

eXtreme Programming in der Praxis

Title: eXtreme Programming in der Praxis

Research Paper (undergraduate) , 2003 , 29 Pages , Grade: 1,3

Autor:in: Bastian Helfert (Author)

Computer Science - Programming
Excerpt & Details   Look inside the ebook
Summary Excerpt Details

Stellen Sie sich vor, Sie sind der Leiter einer neuen Lebensmittel-Handelskette. Ihre qualitativ
hochwertigen Produkte finden bei der Kundschaft so reißenden Absatz, dass Sie seit mehreren
Monaten stark expandieren. Dabei hat natürlich auch die Anzahl Ihrer Mitarbeiter beträchtlich
zugenommen. Doch mit Ihrem eingesetzten Gehaltsabrechnungssystem (GAS) stoßen Sie
langsam an Grenzen. Um Ihre weitere Planung einhalten zu können, benötigen Sie bis zum
Jahresende ein für Sie adäquates GAS, das sich durch genauso hohe Qualität wie Ihre Produkte
auszeichnet. Unter hoher Qualität verstehen Sie in diesem Kontext Software, die sowohl (nahezu)
intuitiv bedienbar und (möglichst) fehlerfrei ist, als auch funktional das bietet, auf was Sie
wirklich angewiesen sind. Auf überflüssige Funktionalität verzichten Sie gerne, denn Sie erhöht
nur das Risiko einer Terminverzögerung und damit nicht nur die Gefahr eines Budgetüberzugs...
Weiterhin würde es Ihnen sehr entgegenkommen, wenn Sie in regelmäßigen Zeitabständen eine
funktionierende (Vorab-)Version des GASs erhielten. Schließlich könnten Sie auf diese Weise
sehen, was aus Ihrem investierten Kapital geworden ist und Sie könnten die Software teilweise
schon einsetzen und dabei gleich auch noch testen! Gäbe es eine Software-Schmiede, die Ihre
Wünsche und Vorstellungen bezüglich des GASs umsetzen würde, dann wären Sie auch dazu
bereit, den Entwicklern Ihre Mitarbeiter über die gesamte Projektdauer vor Ort zur Verfügung
zu stellen.
Ein u.a. für diese Ansprüche geeigneter Ansatz zur Softwareentwicklung entstand, als Kent
Beck, Ward Cunningham und Ron Jeffries im Jahre 1996 mit der Entwicklung von Extreme
Programming (XP) begannen [11]. Nach der Vollendung von XP beschrieb Beck dessen Prinzipien
in seinem Manifest [1]. Da ein Manifest jedoch eine Erklärung von Grundsätzen darstellt,
befasst es sich nicht mit einer Umsetzung dieser. Der folgende Text zeigt deshalb Möglichkeiten
auf, wie XP in der Praxis realisiert werden kann. Zuvor soll sich aber noch eine Erläuterung
von XP im nächsten Kapitel anschließen.

Excerpt


Inhaltsverzeichnis

1 Motivation

2 eXtreme Programming

3 Der XP-Entwicklungsprozess

4 Der Kunde vor Ort

5 User Stories

6 Akzeptanz-Tests

7 Release- und Iterations-Planung

7.1 Release-Planung

7.2 Iterations-Planung

8 Programmierung

9 Programmieren in Paaren

10 Testen, Testen, Testen

11 Fortlaufende Integration

12 Abschließende Betrachtung

Zielsetzung und Themen

Die vorliegende Arbeit untersucht die praktische Anwendung von Extreme Programming (XP) als agilen Softwareentwicklungsprozess. Ziel ist es, aufzuzeigen, wie die theoretischen Grundsätze und Hauptverfahren von XP in realen Projekten umgesetzt werden können, um eine effiziente und qualitativ hochwertige Softwareentwicklung zu gewährleisten.

  • Grundlagen des XP-Entwicklungsprozesses und der vier Kernwerte.
  • Die zentrale Rolle des Kunden und die Arbeit mit User Stories.
  • Methodiken der Release- und Iterationsplanung sowie Aufwandsschätzung.
  • Praktiken der Programmierung, einschließlich Pair Programming und Refactoring.
  • Qualitätssicherung durch Testgetriebene Entwicklung und kontinuierliche Integration.

Auszug aus dem Buch

Programmieren in Paaren

Einer der Hauptgründe für den Erfolg von XP rechnen seine Erfinder dem Programmieren in Paaren zu [11]: Zwei Programmierer arbeiten gemeinsam an demselben Algorithmus, demselben Design oder derselben Implementierungsaufgabe, während sie Seite an Seite an einem Rechner sitzen. Ist das nicht eine Verschwendung personeller Ressourcen, wenn „zwei die Arbeit von einem“ erledigen? Ein Blick auf eine Studie [2] von Alistair Cockburn und Laurie Williams mit statistisch signifikanten Ergebnissen genügt, um vom Gegenteil überzeugt zu sein.

Beiden Autoren haben herausgefunden, dass Programmieren in Paaren die Qualität des Designs verbessert, die Fehleranzahl reduziert, die Entwickler leichter ersetzbar macht, die technischen Fähigkeiten der Programmierer erweitert, die Kommunikation im Team und dessen Effizienz verbessert und im Vergleich zur konventionellen Programmierung von den Entwicklern als angenehmer betrachtet wird - und das alles durch eine zusätzliche Entwicklungszeit von 15%! Diese 15% werden u.a. mit einer über 15% geringeren Fehleranzahl wieder ausgeglichen.

Doch welche Gründe gibt es für die anfangs erwähnten positiven Effekte? Die Beantwortung der Frage wird einfacher, wenn die Arbeitsweise eines Programmier-Paars beleuchtet wird. Jeder Entwickler schlüpft entweder in die Rolle des Fahrers (engl. Driver) oder in die des Beifahrers (engl. Partner). Der Fahrer „steuert“ Stift, Tastatur und Maus, schreibt demzufolge den Code, der Beifahrer überwacht kontinuierlich und aktiv das Vorgehen seines Fahrers, hält Ausschau nach Fehlern, überlegt sich Alternativen, unterstützt ihn bei der Verwendung von Objekte, Attributen und Methoden, achtet auf die Einhaltung der Programmierstandards und behält strategische Auswirkungen im Hinterkopf, verhindert also, dass sich sein Fahrer „verfährt“ [11].

Zusammenfassung der Kapitel

1 Motivation: Einführung in die Problematik klassischer Softwareentwicklung und Vorstellung von XP als Lösungsansatz für expandierende Unternehmen.

2 eXtreme Programming: Definition der vier XP-Werte und des agilen Prozessmodells zur Bewältigung sich ändernder Anforderungen.

3 Der XP-Entwicklungsprozess: Erläuterung der agilen Vorgehensweise ohne klassische Phasenstruktur und Integration von Planungs- und Testaktivitäten.

4 Der Kunde vor Ort: Analyse der Notwendigkeit und Umsetzung der engen Einbindung des Kunden für effizientere Kommunikation und Anforderungsdefinition.

5 User Stories: Beschreibung der Methode zur Dokumentation von Systemanforderungen aus Benutzersicht zur Spezifikation und Priorisierung.

6 Akzeptanz-Tests: Erläuterung der automatisierten Validierung von User Stories zur Sicherstellung der korrekten Implementierung.

7 Release- und Iterations-Planung: Detaillierte Darstellung des Planungsspiels, der Aufwandsschätzung und der Iterationsplanung zur Steuerung des Projekterfolgs.

8 Programmierung: Überblick über die Kernpraktiken der Programmierung wie Code-Standards und 40-Stunden-Woche.

9 Programmieren in Paaren: Untersuchung der Vorteile des Pair-Programming hinsichtlich Designqualität, Wissensaustausch und Fehlerminimierung.

10 Testen, Testen, Testen: Fokus auf Unit Tests und die Strategie zur Absicherung der Softwarequalität durch kontinuierliches Testen.

11 Fortlaufende Integration: Beschreibung des Prozesses zur Zusammenführung des Codes in drei Phasen zur Vermeidung von Versionskonflikten.

12 Abschließende Betrachtung: Zusammenfassende Bewertung der Potenziale und Herausforderungen von XP im Unternehmensumfeld.

Schlüsselwörter

Extreme Programming, XP, Agile Softwareentwicklung, User Stories, Pair Programming, Testen, Refactoring, Release-Planung, Iterations-Planung, Softwarequalität, Kundenorientierung, Programmierung, Integrationsrechner, Geschäftswert, Entwickler.

Häufig gestellte Fragen

Worum geht es in dieser Arbeit grundsätzlich?

Die Arbeit behandelt den agilen Softwareentwicklungsprozess eXtreme Programming (XP) und dessen praktische Umsetzung in Softwareprojekten.

Was sind die zentralen Themenfelder?

Im Fokus stehen die vier XP-Werte, die Einbindung des Kunden, iterative Planungsmethoden, Paarprogrammierung, testgetriebene Entwicklung und fortlaufende Integration.

Was ist das primäre Ziel der Arbeit?

Das Ziel ist es, aufzuzeigen, wie XP-Praktiken eingesetzt werden können, um qualitativ hochwertige Software termingerecht und unter Berücksichtigung tatsächlicher Kundenanforderungen zu entwickeln.

Welche wissenschaftliche Methode wird verwendet?

Der Autor führt eine literaturbasierte Analyse und strukturierte Darstellung der XP-Methodik durch, angereichert durch praxisnahe Beispiele und Studien.

Was wird im Hauptteil behandelt?

Der Hauptteil gliedert sich in die detaillierte Beschreibung der zwölf XP-Hauptverfahren, angefangen bei der Anforderungsanalyse durch User Stories bis hin zur technischen Umsetzung und Qualitätssicherung.

Welche Schlüsselwörter charakterisieren die Arbeit?

Die Arbeit lässt sich durch Begriffe wie Extreme Programming, Agilität, Pair Programming, User Stories, Test-Driven Development und kontinuierliche Integration charakterisieren.

Wie unterscheidet sich die Planung in XP von klassischen Vorgehensmodellen?

Im Gegensatz zu phasenorientierten Modellen basiert die Planung bei XP auf zwei ständigen Zyklen (Release- und Iterationsplanung), die auf Schätzungen der Team-Geschwindigkeit und dem Geschäftswert der User Stories beruhen.

Welche Bedeutung hat das Pair Programming für die Fehlerquote?

Durch die permanente gegenseitige Überprüfung zwischen Fahrer und Beifahrer sinkt die Fehleranzahl laut angeführten Studien um über 15%, was den zusätzlichen Zeitaufwand von 15% ausgleicht.

Excerpt out of 29 pages  - scroll top

Details

Title
eXtreme Programming in der Praxis
College
University of Cooperative Education Mosbach  (Wirtschaftsinformatik)
Grade
1,3
Author
Bastian Helfert (Author)
Publication Year
2003
Pages
29
Catalog Number
V13378
ISBN (eBook)
9783638190510
Language
German
Tags
Extreme Programming XP Software Engineering Praxis Umsetzung Kent Beck
Product Safety
GRIN Publishing GmbH
Quote paper
Bastian Helfert (Author), 2003, eXtreme Programming in der Praxis, Munich, GRIN Verlag, https://www.grin.com/document/13378
Look inside the ebook
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
  • Depending on your browser, you might see this message in place of the failed image.
Excerpt from  29  pages
Grin logo
  • Grin.com
  • Shipping
  • Contact
  • Privacy
  • Terms
  • Imprint