*
Agilität Teil 5: Extreme Programming

Agilität Teil 5: Extreme Programming

6. März 2018Tags: Keine Kommentare Daniel Gutjahr

Extreme Programming, kurz XP, wurde Mitte der 90er Jahre von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

XP folgt einem strukturierten Vorgehen und stellt Teamarbeit, Offenheit und stete Kommunikation zwischen allen Beteiligten in den Vordergrund.

Die Methode geht, wie die meisten agilen Methoden, davon aus, dass der Kunde die Anforderungen an die zu erstellende Software zu Projektbeginn noch nicht komplett kennt und nicht hinreichend strukturieren kann. Weiterhin liegen zu Projektbeginn oft nicht alle, für die endgültige Realisierung aber notwendigen, Informationen vor.

Außerdem ändern sich im Laufe eines Projekts häufig Prioritäten und Anforderungen. Zu Beginn geforderte Funktionen der Software werden möglicherweise in einer anderen Form benötigt oder fallen im Laufe der Zeit weg.

Bei einer konsequenten Ausrichtung an XP soll die zu erstellende Software schneller bereitgestellt werden sowie eine höhere Softwarequalität und Zufriedenheit des Kunden gewährleistet werden. Ziel ist es, dass der Kunde ein einsatzbereites Produkt erhält, an dessen Herstellung er durch Feedback aktiv mitgearbeitet hat.

Neue Funktionalitäten werden permanent entwickelt, integriert und getestet. Für die zu entwickelnden Funktionalitäten werden jeweils die Schritte Risikoanalyse, Nutzenanalyse, die Bereitstellung einer ersten ausführbaren Version (Prototyping) und ein Akzeptanztest durchgeführt.

Der XP-Lebenszyklus

Wie bereits im Verlauf unserer Reihe beschrieben, folgt XP dabei dem klassischen Aufbau von agilem Management und besteht aus verschiedenen Werten, Prinzipien, Techniken und Rollen.

Die Werte des XP bilden dabei das Fundament, auf dem die Prinzipien und Techniken aufbauen und sind die Handlungsgrundlagen für die beteiligten Personen.

Die Werte des XP:

  • Kommunikation: Die Kommunikation der Entwickler untereinander sowie mit den Kunden soll dabei helfen, schnellstmögliches Feedback sicherzustellen und entstehende Probleme so schnell wie möglich zu lösen.
  • Einfachheit: Die Software soll so einfach wie möglich gestaltet werden. Das bedeutet keine Vorbereitung möglicher zukünftiger Erweiterungen, keine redundante oder unnötige Funktionalität und keine redundanten Strukturen. Der Grundgedanke dahinter besteht darin, dass es effizienter ist etwas Einfaches zu entwickeln und bei Bedarf etwas mehr Aufwand zu investieren, um Änderungen einzubauen, als von Beginn an etwas Komplexes zu entwickeln, das am Ende nicht oder nicht in der angedachten Form verwendet wird.
  • Mut: Es soll die ungeschminkte Wahrheit über den Projektfortschritt und Aufwände kommuniziert werden. Weiterhin soll nicht nach Entschuldigungen für Fehler gesucht und Änderungen sollen angenommen werden, wann immer sie auftreten.
  • Feedback: Die evolutionäre Entwicklung des Systems in möglichst kleinen Releases ermöglicht schnelles Feedback und dadurch eine flexible Projektsteuerung. Weiterhin sollen umfangreiche Test-Szenarien sicherstellen, dass die realisierte Funktionalität den Anforderungen entspricht und die festgelegten Funktionalitätskriterien erfüllt werden.
  • Respekt: Jeder gibt und empfängt Respekt und jeder liefert seinen Beitrag zum gemeinsamen Erfolg.

Darauf aufbauend bilden Prinzipien die Brücke zwischen Werten und konkret anwendbaren Techniken. XP beschreibt folgende 13 Prinzipien:

  • Menschlichkeit
  • Wirtschaftlichkeit
  • Beidseitiger Vorteil
  • Verbesserungen
  • Vielfältigkeit
  • Reflexion
  • Fluss
  • Fehlschläge hinnehmen
  • Gelegenheiten wahrnehmen
  • Qualität
  • Redundanzen vermeiden
  • Kleine Schritte
  • Akzeptierte Verantwortung

Folgende Techniken, die auf den Werten und Prinzipien des XP aufbauen, finden im Rahmen von XP Anwendung. Zum besseren Verständnis werden ausgewählte Punkte beschrieben:

  • Planungsspiel: um die gewünschten Funktionen zu finden
  • Kleine Releases
  • Systemmetapher: die Entwickler haben immer das Gesamtsystem vor Augen
  • Einfaches Design
  • Pair-Programming: Zwei Entwickler arbeiten zusammen an einem Rechner. Dabei ist der eine der “Driver”, also derjenige, der entwickelt, und der andere der “Follower”, der seine Überlegungen mit einfließen lässt. Diese Rollen werden ständig getauscht, sodass beim Coden direkt ein Code-Review stattfindet.
  • Refactoring
  • Ständiges Testen
  • Collective Code-Ownership: Der Code gehört dem ganzen Team. Das bedeutet, jeder Entwickler sollte jederzeit jede Stelle des Codes bearbeiten können.
  • Vor-Ort-Kunde: Das Team arbeitet vor Ort beim Kunden, um dessen direktes Feedback in die Arbeit einfließen lassen zu können
  • Programmierrichtlinien
  • 40 Stunden Woche
  • Ständige Integration

Abschließend gibt es in einem XP Projekt folgende Rollen:

  • Kunde: entscheidet, was ihm einen Mehrwert bringt, priorisiert diese Punkte und wählt aus, was wie umgesetzt werden soll. Darüber hinaus definiert er die Tests, welche die Funktionalität des Systems prüfen (Akzeptanztests).
  • Entwickler: schätzt die Aufwände und die Komplexität der User Stories und steuert die Geschwindigkeit, mit der die Funktionalität entwickelt und ausgeliefert wird.
  • Manager: bringt Kunden und Entwickler zusammen und hilft ihnen, einander zu verstehen und zusammen zu arbeiten.

Dieser Artikel ist Teil einer Artikelreihe rund um den Themenkomplex Agilität, agiles Management und agile Methoden. Ziel ist es, Ihnen einen Einblick in diese äußerst spannende und aktuelle Thematik zu geben.

Quelle:

https://www.computerwoche.de/a/extreme-programming,2352505

Kommentare

Hinterlasse einen Kommentar

avatar
  Abonnieren  
Benachrichtige mich bei

Popular Posts

Aufgaben eines Project Management Office (PMO)
Aufgaben eines Project Management Office (PMO)
Trainee im Karrierepfad Project Management Office (PMO) – und nun? Welche Aufgabengebiete werden von einem PMO abgedeckt und welche Aufgaben stellen sich konkret unseren Trainees in diesem Karrierepfad? Die Erwartungen an ein PMO reichen von Einzelfunktionen wie bspw. dem Durchsetzen von Standards oder dem reinen Coaching bis hin zur Steuerung des gesamten Projektportfolios. In der […]
read more ←
Beraterinterview Artur Hefner
Beraterinterview Artur Hefner
Kannst Du das Projekt, an dem Du gerade arbeitest, und Deine spezifische Aufgabe darin kurz beschreiben? Das Projekt MERKUR (Meldewesen, Europäische Regulierung: Konzeption, Umsetzung, Reporting) stellt die Meldefähigkeit der Bank und ihrer Töchter sicher. Meine Aufgaben sind im Anforderungsmanagement angesiedelt. Ich fungiere als Schnittstelle zwischen den Fachprojekten und der IT-Umsetzung, damit gehen unter anderem Koordinationsaufgaben […]
read more ←
Mitarbeiterinterview: Chiara Väth
Mitarbeiterinterview: Chiara Väth
Seit wann arbeitest Du bei der Talentschmiede? Ich bin seit September 2017 bei der Talentschmiede tätig. Zunächst bin ich als Vollzeitkraft im Recruiting eingestiegen. Durch den Beginn meines Masterstudiums bin ich aktuell bei der Talentschmiede als Werkstudentin tätig und unterstütze weiterhin das Recruiting-Team. Wie bist Du zu uns gekommen und was hat Dich dazu bewogen, […]
read more ←

Pin It on Pinterest

Share This