Extreme Programming

Extreme Programming (XP) ist ein iteratives Vorgehensmodell der Softwaretechnik, welches eine sehr flexible Arbeitsweise erlaubt. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

XP basiert auf 5 zentralen Werten:

  • Respekt
  • Kommunikation
  • Einfachheit
  • Feedback
  • Mut 

Auf diesen Werten basierende Praktiken bilden das Vorgehensmodell Extreme Programming. Kent Beck hat diese in Extreme Programming zusammengefasst:

  • Das Planungsspiel – Der Umfang einer Version wird festgelegt, indem Geschäftsprioritäten mit technischen Aufwandsschätzungen kombiniert werden. Der Plan muss ständig an die Realität angepasst werden.
  • Kurze Releasezyklen – Ein einfaches System soll so schnell wie möglich in Produktion gehen. Darauf folgend sollen in möglichst kurzen Iterationsschritten neue Versionen eingeführt werden.
  • Metapher – Sämtliche Entwicklungen werden an einer gemeinsamen, einfachen Metapher ausgerichtet. Diese Metapher soll für Geschäftsseite und Entwicklerseite gleichermassen verständlich sein. Dadurch soll die einfache Kommunikation zwischen Kunden und Entwicklern sichergestellt werden. 
  • Einfaches Design – Das System soll zu jedem Zeitpunkt so einfach wie möglich strukturiert sein.
  • Testen – Es werden für jeden Teil des System fortwähren Komponententests geschrieben, die fehlerfrei ausgeführt werden müssen.
  • Refactoring – Das System unterliegt einem ständigen Refactoring, um Redundanzen zu verhindern, den Programmcode zu vereinfachen oder flexibler zu gestalten.
  • Programmieren in Paaren – Der gesamte Produktionscode wird von 2 Programmieren geschrieben, die gemeinsam an einem Rechner sitzen.
  • Gemeinsame Verantwortlichkeit – Jeder kann jederzeit beliebigen Code im System ändern.
  • Fortlaufende Integration – Das System wird ständig integriert. Immer dann, wenn eine Aufgabe erledigt worden ist.
  • 40 – Stunden Woche – Man arbeitet prinzipiell nicht mehr als 40 Stunden in der Woche. Überstunden werden nie länger als eine Woche geleistet.
  • Kunde vor Ort – Dem Team soll ein echter, lebender Benutzer angehören, der während der gesamten Arbeitszeit zur Beantwortung von Fragen zur Verfügung steht.
  • Programmierstandards – Programmierer schreiben sämtlichen Code entsprechend Regeln, die die Kommunikation mithilfe des Codes erleichtern.

Diese Best Practices waren schon vorher bekannt und werden teilweise bereits lange genutzt. XP fasst diese Praktiken zu einem funktionierenden Gesamtkonzept zusammen, definiert diese jedoch nicht als Allheilmittel. Wo sie nicht den individuellen Anforderungen eines Projektes genügen sollen sie angepasst werden. 

5 Kommentare Extreme Programming

  1. jp

    Hallo Jens,
    praktizierst Du XP auch?

    Auf meinen Blog schreibe ich eine XP Series die auf Erfahrungsberichte basiert. Wenn man das genau liest, wird man bald feststellen, dass ich nicht wirklich XP mache, sondern ein Abwandung von Scrum und XP zum Einsatz kommt. Viele Begriffe wie Product Owner, User Stories, Story Points, Product Backlog z.B. gibts im XP nicht.

    Ein anderer wesentlicher Unterschied ist der eigentliche Arbeitstakt – Iteration oder Sprint. Wir gehen von jedem Sprint mit dem Team hin und schätzten den Aufwand, nicht nur am Anfang. Daraus ergibt sich in der folge eine neue Arbeitsweise.

    Ich bin gespannt auf einen guten Erfahrungsaustausch mit Dir.

    Werd‘ dann mal meine Serie weiterschreiben.

    Gruss, jp

    Antworten
  2. Jens

    Hey Jp,

    ja ich praktiziere XP. Allerdings auch in einer abgewandelten Form. Pair programming betreiben wir zum Beispiel nur in schwierigen Phasen eines Projektes. Ich werde dazu eventuell hier auf meinem Blog noch einige Details posten.

    Scrum habe ich bei meiner Betrachtung der agilen Methoden noch nicht genau angeschaut. Das werde ich wohl mal nachholen. Auf den ersten blick scheint XP und Scrum sehr ähnlich zu sein. Kannst du das bestätigen?

    Gruß Jens

    Antworten
  3. Pingback: Usability Driven Development - jensjaeger.com

  4. jp

    Hallo Jens,

    XP und Scrum haben zunächst nur wenig Gemeinsamkeiten. Scrum ist eine agile Management-Methode, während XP eine agile Engineering Methode ist. XP allein macht noch kein agiles Vorgehen, denn nach der Theorie von XP gibt es während der Realisierung keinen Einfluss mehr vom Kunden. Hier kommt Scrum ins Spiel. Bei Scrum ist der Kunde Teil des Teams – er ist Teammitglied. Nach jeder Interation kann er seine Wünsche einbringen und das Projekt steuern und lenken, ähnlich einem Steuermann bei einem 8ter Ruderboot.

    Scrum ist auf jeden Fall eine kurzes Studium wert. Ich arbeite schon seit mehreren Projekten nach Scrum und mit abgewandelter XP Methode. Der Erfolg spricht dafür 😉

    Gruss, jp

    Antworten
  5. Jens

    Hallo JP,
    ich hatte noch keine Zeit mich mit Scrum genauer zu befassen, werde das aber nachholen.

    XP fordert ausdrücklich das ein Kunde dem Team angehört. Das soll wie ich auch oben im Artikel geschrieben habe ein echter, lebender Benutzer der zu entwickelnden Software sein. Er hat folgende Aufgaben:

    • Schreiben von Storycards (Usecases)
    • Priorisierung der zu entwickelten Storycards bei jedem Planungsspiel (nach Aufwandsschätzung durch die Entwickler)
    • Zeitnahe Beantwortung der Fragen die bei der Entwicklung auftreten
    • Durchführen von Akzeptanztests

    Das ist ja soweit ich es verstanden habe auch bei Scrum so.

    Gruß Jens

    Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert. Infos zum Datenschutz.