Extreme Programming - eine Einführung
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Dieser zweite Teil stellt nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen im dritten Teil diese Einführung ab.
Extreme Programming - eine Einführung
Warum ist Software zu teuer, kommt zu spät, tut nicht genug oder ist einfach schlecht? Extreme Programming (XP) zeigt Wege, ein Projekt auch unter klassisch schwierigen Bedingungen auf Qualität und Effizienz zu optimieren. Diese ausführliche Einführung umfasst drei Teile. Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Dieser zweite Teil stellt nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen im dritten Teil diese Einführung ab.
Extreme Programming (Beck, 1999a) ist ein leichtgewichtiger, durch Risikomanagement und Software-Struktur gesteuerter Prozess zur Softwareentwicklung. Extreme Programming (XP) verzichtet auf Analogien zu anderen Ingenieurdisziplinen und bezieht sich ausschließlich auf Software. Dabei setzt XP bekannte Prinzipien und Verfahren, die einzeln erprobt sind, in neuer Sichtweise zu einem Ganzen zusammen. Alles Gute wird betont, alles Unnötige weggelassen. Kent Beck, einer der Erfinder, versieht XP mit den Attributen "leicht, effizient, risikoarm, flexibel, vorhersagbar, menschlich und spaßig".
Im ersten Teil standen die Grundlagen und die Motivation von Extreme Programming sowie die wichtigsten Prinzipien im Vordergrund. Dieser zweite Teil stellt nach einem Blick auf Entstehungsgeschichte die Einsatzgebiete und Ziele vor. Abschließend werden die Verfahren, die XP zur Projektplanung einsetzt, erläutert. Die Verfahren zur "Extremen" Softwareentwicklung sowie die bisherigen Erfahrungen mit XP schließen im dritten Teil diese Einführung ab.
Wie ist Extreme Programming entstanden?
Menschen machen Projekte. Oft kann eine Handvoll gut eingespielter hocheffizienter Entwickler mehr erreichen als eine Hundertschaft in einem starren formalen Rahmen. Diese Erfahrung hat viele Entwickler und Forscher schon lange zu der Frage getrieben, was derart effiziente Teams unterscheidet von ineffizienten. Neben herausragenden Einzelleistungen und neben Umgebungs- und Teameffekten (De Marco, 2010) sind bestimmte Techniken und Verfahren aufgefallen, die nicht dem Standardvorgehen in der Industrie entsprechen.
Auf diesem Nährboden ist XP entstanden. Das prominenteste Beispiel ist wohl das "Chrysler Comprehensive Compensation" Projekt (Beck, 1999b). 1995 wurde es als Festpreisprojekt mit Co-Entwicklung interner und externer Mitarbeiter aufgesetzt, nach gut einem Jahr Laufzeit waren letztlich keine sicheren Aussagen über den tatsächlich erreichten Stand möglich. Kent Beck bekam die Verantwortung für das Projekt und den Entwicklungsprozess und die Chance zu einem kompletten Neuanfang. Er legte den Fokus auf das letztlich relevante Ergebnis, den Code, und drehte dazu alle "Verfahrens-Knöpfe auf Anschlag" (siehe Kasten). Der so entstandene und weiter verfeinerte Prozess bekam entsprechend den Namen "Extreme Programming".
Verfahrens-Knöpfe auf Anschlag: Zwei Beispiele
Code Reviews sind ein anerkannter Weg zur Qualitätssteigerung in der Software. Es hat sich als effizient herausgestellt, die Ergebnisse während des Reviews direkt einzuarbeiten. Was kann also besser sein, als sämtlichen Code direkt bei der Entstehung zu reviewen? Also wird in XP der gesamte relevante Code von zwei Entwicklern gleichzeitig an einem Computer entwickelt ("Programmieren in Paaren", siehe Teil 3).
Ein anderes Beispiel betrifft die Phasen Analyse, Design, Implementierung und Test. Um die richtige Software in guter Qualität zu entwickeln, sind ständige Rückkopplungen und Korrekturen erforderlich. Die strenge Trennung der Phasen ist ineffizient, Phasenprodukte für das Endergebnis unerheblich. Lange Zyklen in jeder Phase erhöhen das Risiko, Kapazität und Zeit zu vergeuden. Also wird in XP in kleinen Schritten gearbeitet ("Kurze Releasezyklen"), zu jedem Zeitpunkt nur das Wichtigste gemacht ("Planungsspiel"), allerdings mit hohem Qualitätsanspruch ("Einfaches Design" und "Bedingungsloses Refactoring", siehe Teil 3), laufend getestet ("Zuerst testen", siehe Teil 3) und integriert ("Ständige Integration", siehe Teil 3).
Diese Überlegungen ziehen weitere Verfahren mit sich, damit eine in sich schlüssige Methode entsteht. Der Kanon von Extreme Programming ist allerdings bewußt minimal gehalten. Jedes Verfahren, das nicht unbedingt in jedem Projekt notwendig ist, um die anderen Verfahren zu stützen, wird nicht zum Bestandteil von XP. Jeder Anwender von XP muss die Verfahren in seinem Kontext prüfen und gegebenenfalls abwandeln oder ergänzen.
Für die Ausformulierung von Extreme Programming war auch das WikiWikiWeb wichtig. Wiki ist eine Sammlung vielfach verknüpfter Web-Pages, die jeder Besucher lesen, durchsuchen und insbesondere ergänzen und ändern kann. (Ein möglicher Einstieg für Neugierige ist (http://www.c2.com/cgi/wiki?RecentChanges). Auf diese Weise ist Wiki zu einem lebendigen Diskussionsforum geworden, in dem auch XP vorgestellt, formuliert und diskutiert wurde. Hier wurde und wird XP ständig mit aktuellen Erfahrungen konfrontiert und weiter entwickelt oder präzisiert.
Einsatzgebiete und Ziele
XP tritt mit dem Anspruch an, das Scheitern von Projekten zu verhindern und sowohl Auftraggebern als auch Entwicklern die damit verbundenen Kosten und Frustrationen zu ersparen. Dazu nimmt XP eine klare Gewaltenteilung vor: Kunden treffen Produkt-Entscheidungen, und Techniker treffen technische Entscheidungen. XP gibt den Kunden viel Information und Steuerungsmöglichkeiten, erwartet im Gegenzug aber eine kompetente, explizite und rein nicht-technische Steuerung. Entwickler erhalten freie Hand in ihrem Bereich und sind verantwortlich für Aufwände und die Qualität ihrer Arbeit.
XP teilt das Projekt in Inkremente auf, die einzeln geplant und implementiert werden. Diese Inkremente sind nur wenige Wochen lang. Der Kunde bekommt mit jedem Inkrement wie in einem Abonnement eine neue Version mit den vereinbarten Eigenschaften, und definiert die Aufgaben für das folgende Inkrement. Damit steht jederzeit eine Version zur Verfügung, die eingesetzt und getestet werden kann.
…