WikiDer > Extremes Programmieren

Extreme programming

Extremes Programmieren (ebenfalls XP genannt) ist eine Form von Agile Software Entwicklung, ein Softwareentwicklungsmethodik.

Geschichte

Die Hauptbegründer der extremen Programmierung sind Kent Beck, Ken Auer, Gemeinde Cunningham, Martin Fowler und Ron Jeffries. Sie entwickelten XP während des Chrysler Comprehensive Compensation System (C3)-Projekts im Jahr 1996. Sie beschreiben XP als "eine humanistische Disziplin der Softwareentwicklung, basierend auf den Prinzipien der Einfachheit, Kommunikation, Feedback und Mut". Softwareentwicklung basierend auf den Prinzipien der Einfachheit , Kommunikation, Feedback und Mut"). XP ist eine Methode, die sich besonders für Projekte eignet, bei denen die genauen Anwendungsanforderungen nicht im Voraus festgelegt sind.

Entwicklungsprinzipien, Best Practices

Extreme Programming verdankt seinen Namen der Tatsache, dass eine Reihe bewährter Entwicklungsprinzipien (sogenannte Best Practices) auf die Spitze getrieben werden. Die optimale Leistung von XP ergibt sich aus der Anwendung von zwölf empfohlene Vorgehensweise der Softwareentwicklung. Die Best Practices sind in vier Gruppen eingeteilt.[1] (Feedback, kontinuierlicher Prozess, geteiltes Wissen und das Wohlbefinden der Entwickler).

Feedback

Paar-Programmierung

XP sagt, dass es am Ende nur um Code geht, wenn man Software erstellt. Wenn es für Entwickler in Ordnung ist, Code gemeinsam zu überprüfen, tun Sie dies kontinuierlich: Entwickeln Sie die gesamte Software in Batches. Mit anderen Worten, zwei Personen hinter einem Computer; Paar-Programmierung erwähnt. Dies ist auch einer der extremsten und umstrittensten Aspekte von XP, da angenommen wird, dass er es verlangsamt. Aber die Forschung hat das gezeigt Peer-Review und Code-Inspektion sind die mächtigsten Waffen gegen Bugs, sogar viel mächtiger als systematisches Testen. Diese Techniken werden jedoch noch spärlich eingesetzt und stoßen oft auf großen Widerstand bei den Programmierern selbst und bei Managern, die Angst vor immer mehr Arbeitszeiten haben.

Das Erzwingen, dass die gesamte Softwareentwicklung in Paaren erfolgt, die auch die Zusammensetzung regelmäßig ändern, schafft ein kollektives „Eigentumsgefühl“, und Peer-Review und Code-Inspektion werden zu einem natürlichen Bestandteil des normalen Softwareprozesses. Das Ergebnis ist, dass das letztendlich ausgelieferte System nicht mehr aus einer Sammlung von Codestücken besteht, die mit „Strings“ verbunden sind, die schwer zu warten sind.

Darüber hinaus hat diese Arbeitsweise noch einen weiteren Vorteil: Es gibt immer mindestens zwei Personen, die jeden Code vollständig verstehen. Das Onboarding neuer Leute ist selbstverständlich. Es gibt eine fortlaufende "on-the-job"-Ausbildung. RSI Bei dieser Entwicklungsmethode wird es weniger Chancen geben, Mitarbeiter zu fällen, da ein Wechsel möglich ist.

Zeitplan

Der Planungsprozess ist der wichtigste Prozess. Die Planung findet einmal wöchentlich statt und besteht aus einer Releaseplanung und einer Iterationsplanung.

  • Releaseplanung: Hiermit wird festgelegt, welche Funktionalität in welchem ​​Release realisiert wird. Sowohl die Entwickler als auch die Benutzer sind anwesend. Die Releaseplanung besteht aus 3 Phasen:
    • Explorationsphase: Hier erstellen die Benutzer eine kurze Liste der wichtigsten Anforderungen an das neue System. Dies hat die Form von benutzergeschichten.
    • Konzeptentscheidung (Commitment Phase): Hier wird entschieden, welche User Stories in das nächste Release aufgenommen werden und wann dieses Release sein wird.
    • Änderungsphase (Steuerungsphase): Der Plan kann noch geändert und neue Geschichten hinzugefügt und andere entfernt werden.
  • Iterationsplanung: Hier werden die User Stories, die in die Releaseplanung für den kommenden Sprint einfließen, in Aufgaben für die Entwickler zerlegt. Es sind keine Benutzer beteiligt, nur Entwickler. Die Iterationsplanung besteht ebenfalls aus drei Phasen:
    • Recherchephase (Explorationsphase): Die Geschichten werden in Aufgaben übersetzt und diese Aufgaben auf Karten, sogenannte Aufgabenkarten, geschrieben.
    • Commitment-Phase: Bei diesen Aufgaben wird abgeschätzt, wie lange es dauert, sie zu erreichen, und die Aufgaben werden den Entwicklern (Paaren) zugewiesen.
    • Entwicklungsphase (Steering Phase): Die Aufgaben werden ausgeführt und das Ergebnis mit dem ursprünglichen Zeitplan der User Story abgeglichen.

Ziel der Planung ist es, die Lieferfähigkeit des Produkts sicherzustellen. Es geht weniger um die Bereitstellung genauer Daten als um die Lieferung des Produkts.[2]

Releaseplanung

Recherchephase (Explorationsphase)

Dies ist der Prozess, bei dem Anforderungen erfasst und der Zeitaufwand geschätzt wird, um diese zu erreichen. Teile sind:

  • Schreiben Sie eine Geschichte (User Story): Die Benutzer haben ein Problem oder einen Wunsch; Während einer Beratung werden die Entwickler versuchen, dieses Problem vollständig zu verstehen. Darauf basierend, a Benutzer Geschichte geschrieben. Dies geschieht durch die Benutzer, sie geben an, was sie von einem (Teil) des Systems erwarten. Wichtig ist, dass sich die Entwickler hier nicht einmischen.
  • Schätzen der User Story (Schätzen einer Story): Die Entwickler schätzen, wie lange es dauert, diese zu erstellen. Die Entwickler können nun auch kurze Untersuchungen, sogenannte „Spikes“, benennen, um Teile des Problems oder die Lösungsrichtung zu untersuchen. Diese Spitzen werden verwendet, um bessere Zeitschätzungen zu erhalten, und werden verworfen, sobald das Problem und/oder die Lösung für alle klar ist.
  • Splitting einer User Story: Eine Story muss vollständig klar sein, alle Unklarheiten müssen beseitigt werden, bevor mit der Iterationsplanung begonnen werden kann. Können die Entwickler aufgrund von Unklarheiten keine zeitliche Schätzung für die Story abgeben, muss die Story aufgeteilt werden.

Wenn die Nutzer alle ihre Wünsche beschrieben haben, können sie mit der Konzeptentscheidung (Commitment-Phase) fortfahren.

Konzeptentscheidung (Commitment-Phase)

In dieser Phase werden die Kosten, der Nutzen und die zeitlichen Folgen untersucht. Diese Phase besteht aus vier Teilen:

  • Nach Wert sortieren: Die Nutzer ordnen die User Stories nach dem, was sie für wichtig halten.
  • Nach Risiko sortieren: Die Entwickler schätzen die Risiken ein und sortieren die Story danach.
  • Bestimmen Sie die Entwicklungsgeschwindigkeit (Geschwindigkeit): Die Entwickler bestimmen die Geschwindigkeit, mit der sie dieses Projekt durchführen können.
  • Umfang: Es wird festgelegt, welche User Stories im kommenden Release realisiert werden. Auf dieser Grundlage wird das Release-Datum bestimmt.
Nach Wert für die Benutzer sortieren (Geschäftswert)

Die Nutzer geben die Priorität der User Stories an. Sie machen 3 Stapel:

  • Kritisch: Ohne diese Geschichten kann das System nicht funktionieren oder hat keinen Wert.
  • Wichtig: User Stories, die für das Unternehmen wichtig sind.
  • Nice to have: User Stories, die weniger wichtige Eigenschaften realisieren.
Nach Risiko sortieren

Die Entwickler sortieren die User Stories nach Risiko. Sie bilden auch drei Stapel: kleines, mittleres und hohes Risiko. Im Folgenden ein Beispiel:

  • Bestimmen Sie den Risikoindex: Geben Sie jeder User Story einen Index von 0 bis 2 für jede der folgenden Variablen.
    • Vollständigkeit (haben wir alle Details auf der Tabelle?)
      • Voll (0)
      • Unvollständig (1)
      • unbekannt (2)
    • Sicherheitslücke (sind Änderungen wahrscheinlich?)
      • niedrig (0)
      • mittel (1)
      • Hoch (2)
    • Schwierigkeit (wie schwer ist es zu erreichen?)
      • Einfach (0)
      • Standard (1)
      • Schwierig (2)

Alle Werte für die User Story werden addiert, wodurch die User Story einen Risikowert von niedrig (0–1), mittel (2–4) oder hoch (5–6) erhält.

Wechselphase (Lenkphase)

In dieser Phase können die Entwickler gemeinsam mit den Nutzern den Prozess „steuern“. Mit anderen Worten, sie können noch etwas ändern. Individuelle User Stories oder können die Bedeutung verschiedener Stories ändern; Schätzungen können falsch sein. Diese Änderungen können vorgenommen werden.

Iterationsplanung

Abhängig von der Geschwindigkeit des Teams kann bestimmt werden, wie viele Story Points das Team pro Iteration schaffen kann. Iterationen können 1 bis 3 Wochen dauern.

Recherchephase (Explorationsphase)

Während der Recherchephase der Iterationsplanung werden die User Stories in Aufgaben unterteilt und die Dauer der Aufgaben abgeschätzt. Aktivitäten:

  • Übersetzen Sie die User Stories in Aufgaben und schreiben Sie sie auf Aufgabenkarten.
  • Aufgaben zusammenführen oder aufteilen: Wenn der Entwickler nicht abschätzen kann, wie lange die Aufgabe dauern wird, weil sie zu groß oder zu klein ist, muss etwas dagegen unternommen werden.
  • Schätzen Sie die Aufgabe: Machen Sie eine Zeitschätzung für die Ausführung der Aufgabe.
Zuordnungsphase (Verpflichtungsphase)

In der Zuordnungsphase der Iterationsplanung werden die Aufgaben auf die Entwickler verteilt.

  • Ein Entwickler (Programmierer) übernimmt eine Aufgabe: Jeder Entwickler übernimmt eine Aufgabe, für die er dann verantwortlich ist.
  • Der Entwickler gibt einen Zeitplan vor: Da der Entwickler jetzt verantwortlich ist, kann er jetzt am besten eine Zeitschätzung abgeben.
  • Bestimmen Sie die effektive Arbeitszeit (Set load factor): Die effektive Arbeitszeit bestimmt die Anzahl der Stunden, die der Entwickler/Programmierer während einer Iteration entwickeln kann. Bei einer 40-Stunden-Woche mit 5 Stunden Meetings beträgt die effektive Arbeitszeit beispielsweise 35 Stunden.
  • Balancing: Nach der Zuweisung aller Aufgaben wird geprüft, wie viele Stunden jeder Entwickler im Vergleich zu den tatsächlich verfügbaren Stunden erhalten hat (Auslastungsfaktor). Anschließend werden die Aufgaben bei Bedarf neu verteilt, um sicherzustellen, dass jeder Entwickler ungefähr gleich viel Arbeit hat. Hat ein Entwickler zu viel Arbeit, wird etwas verschoben.
Ausführungsphase (Lenkphase)

Die Ausführung der Aufgaben erfolgt während der Ausführungsphase (Steuerungsphase) der Iterationsplanung.

  • Nehmen Sie eine Aufgabenkarte: Der Entwickler erhält die Karte mit der Aufgabenbeschreibung einer der Aufgaben, für die er sich beworben hat.
  • Partner finden: Der Entwickler sucht einen Partner, um es gemeinsam zu entwickeln.
  • Aufgabe gestalten: ggf. wird ein (Kurz-)Entwurf erstellt.
  • Schreiben Sie die Gerätetest: Vor der Programmierung müssen alle Tests durchgeführt werden. Dies sind vorzugsweise automatische Tests, da sie oft (automatisch) durchgeführt werden müssen.
  • Schreiben Sie den Code: Der Programmierer/Entwickler erstellt das Programm.
  • Testen Sie das Programm: Die durchgeführten (Einheiten-)Tests werden durchgeführt.
  • Refactoring: Wenden Sie die Refactoring-Regeln an und stellen Sie sicher, dass der Code den Standards entspricht.
  • Führen Sie die Funktionstests/Integrationstests durch: Nach dem Unit-Test werden alle möglichen anderen Tests ausgeführt. Integrationstests, Regressionstests usw. Der Code muss geändert werden, bis er die Tests besteht.

Testgetriebene Entwicklung

Biene testgetriebene Entwicklung (TDD) wird zuerst getestet und erst dann programmiert. TDD sagt, wenn das Testen gut ist, schreibe zuerst die Testcode bevor Sie überhaupt eine Codezeile schreiben (Funktionalität).

Das Schreiben automatischer Unit-Tests nimmt einen wichtigen Platz in XP ein. Das Schreiben dieser Unit-Tests erfolgt vor dem Start des eigentlichen Programms. Bei der testgetriebenen Entwicklung (TDD) wird dies: Der Programmierer führt einen oder zwei Tests durch, schreibt ein Programmteil, erstellt einen zusätzlichen Testfall, überarbeitet das Programm, bis dieser neue Test erfolgreich ist, entwirft einen neuen Test usw.

Dies hat den Vorteil, dass der Programmierer gezwungen ist, über die Funktionalität und die Ausnahmen nachzudenken, die sein Programm berücksichtigen sollte. Denken Sie also zuerst darüber nach, was das Programm tun soll und dann, wie das Programm funktionieren wird. Die Tests stellen sozusagen die gewünschte Funktionalität fest. Es ist daher wichtig, dass jedes Programm gerade genug Funktionalität enthält, um den Test zu bestehen. Bestehen alle Tests, erfüllt das Programm exakt die zuvor definierten Anforderungen (schließlich werden diese in den schriftlichen und erfolgreichen Unit-Tests definiert).

Wenn sich ein Refactoring als notwendig erweist, sind die bereits geschriebenen Unit-Tests daher ein Garant dafür, dass Änderungen keine unerwünschten Nebeneffekte im Programmbetrieb verursachen.

Sollte es notwendig sein, das Programm um neue Funktionalitäten zu erweitern, müssen Sie zunächst mit dem Schreiben neuer Unit-Tests beginnen, die die neu zu schreibende Funktionalität definieren. Diese neue Funktionalität wird erst realisiert, wenn sowohl der neue als auch der alte Komponententest alle bestanden haben.

Sollte zu einem späteren Zeitpunkt während einer Funktionsprüfung ein 'Fehler' gefunden wird, müssen Sie zunächst einen Komponententest schreiben, der diesen Fehler aufdeckt. Ein 'Bug' ist also nicht wirklich ein Fehler im Programm, sondern das Fehlen eines entsprechenden Tests.

Ein Team

Der Kunde/Anwender ist Teil des (Entwicklungs-)Teams und muss daher ständig für Fragen zur Verfügung stehen; XP sagt, dass es am Ende nur um Code geht, wenn man Software erstellt. XP geht davon aus, dass dieser Code so kundenspezifisch ist, dass der Kunde möglichst nah am Entwicklungsprozess sein sollte. Bei XP basiert die Entwicklung auf Testfällen, die der Kunde zusammenstellt. Keine funktionalen Spezifikationen; Es wird nur das codiert, was der Kunde aus den Testfällen herausholen möchte. Nicht mehr und nicht weniger. Vorzugsweise sollte ein zukünftiger Benutzer jederzeit anwesend sein, damit sichergestellt werden kann, dass die Anwendung genau das wird, was der Kunde wünscht. Damit dieser Prozess möglichst reibungslos abläuft, arbeitet XP mit kurzen Entwicklungszyklen, bei denen immer eine Reihe ausgewählter Testfälle in ein funktionierendes System umgesetzt werden. Am Ende jedes Zyklus kann der Kunde das System bewerten und gegebenenfalls die Entwicklung anpassen.

Kontinuierlicher Prozess

Kontinuierliche Integration

Wenn Integration und Integrationstests Wichtig ist, den Code so oft wie möglich einzubinden, am besten mehrmals täglich. Dadurch wird verhindert, dass lokal mit unterschiedlichen Kopien gearbeitet und aneinander vorbeigearbeitet wird. Eventuelle Integrationsprobleme sind sofort sichtbar.

Refactoring

Eine wichtige Technik, die XP weiter von herkömmlichen Entwicklungsmethoden unterscheidet, ist Refactoring: ständig umschreiben der Programmcode in kleinen, genau gemessenen Schritten, ohne die sichtbare Funktionalität zu beeinträchtigen. Kurz gesagt, Refactoring fügt der Funktionalität nichts hinzu, sondern vereinfacht das Design. Durch die regelmäßige Durchführung der Umschreibschritte ist der Gesamteffekt oft erstaunlich. Siebzig Rewrite-Regeln wurden inzwischen entdeckt und dokumentiert. Sie tragen Namen wie "Null-Objekt einführen", "Temp durch Abfrage ersetzen" und "Bedingungen durch Polymorphismus ersetzen". Voraussetzung für die erfolgreiche Anwendung des Refactorings ist, dass Unit-Tests zur Verfügung stehen, die nach jedem Rewrite-Schritt automatisch durchgeführt werden können, um sicherzustellen, dass sich die Funktionalität nicht geändert hat. Beispielsweise Smalltalk gibt es schon eine Browser-Refactoring Damit können Rewrite-Regeln automatisch angewendet werden, ohne dass sich der Benutzer zu viele Gedanken über die Richtigkeit machen muss. Refactoring wird häufig als Vorbereitung für die Implementierung einer Erweiterung oder Änderung der Funktionalität verwendet.

Kurze Iterationen

Die Software wird dem Kunden in regelmäßigen Releases von begrenzter Größe zur Überprüfung geliefert; wenn kurze Iterationen gut sind, machen Sie sie wirklich sehr kurz: Sekunden, Minuten, Stunden statt Wochen, Monate, Jahre. Eine durchschnittliche XP-Iteration dauert zwei Wochen, obwohl laut extremeprogramming.org kann zwischen einer und drei Wochen dauern.

Der XP-Zyklus besteht aus 6 Phasen: Exploration, Planung, Iterationen bis zur Veröffentlichung, Produktion, Wartung und Tod.

Geteiltes Wissen (gemeinsames Verständnis)

Metapher

Alle Teammitglieder (Entwickler und Benutzer/Kunden) teilen eine gemeinsame Sicht auf das System („Metapher“); Jeder sollte in der Lage sein, das System mit einfachen Worten zu beschreiben. Dazu soll auch die Verwendung von „Namenskonventionen“ beitragen.

Normen

Es gibt Codierungsstandards, die jedem bekannt sind und verwendet werden.

Der Code gehört allen

Jeder Entwickler hat gleiche Rechte über den gesamten Programmcode. Wenn Design gut ist, machen Sie es zu einem Teil der täglichen Arbeit: Verbessern Sie das Design Schritt für Schritt, je nach Bedarf. wenn die Architektur so wichtig ist, lassen Sie alle an der Entwicklung der Architektur arbeiten.

Einfachheit des Designs

Wenn der Code allen gehört und jeder alles ändern kann, sollte das auch möglich sein. Wenn Einfachheit gut ist, halten Sie das Design so einfach wie möglich. XP funktioniert viel damit KUSS (Keep It Short & Simple) Prinzip. Wenn ein System leicht zu ändern sein soll, sollte das Design so einfach wie möglich sein. Das ist leichter gesagt als getan. Traditionelle Entwicklungsmethoden haben gelernt, vorauszudenken und beim Design immer auch an Funktionalitäten zu denken, die in Zukunft eventuell realisiert werden müssen. Diese Methoden basieren jedoch auf der Annahme, dass die Kosten der Veränderung exponentiell steigen. Aus diesem Grund besteht XP darauf, immer das einfachste Design zu wählen, um die Funktionalität zu ermöglichen, die jetzt realisiert werden muss. Zukünftige Erweiterungen sind mit XP ohne die üblichen Zusatzkosten realisierbar. Es scheint auch, dass die Umsetzung eines durchdachten Designs allzu oft nicht (mehr) ausreicht. Dies kann einerseits passieren, weil bei der Analyse und Auslegung gewisse Details übersehen wurden, oder andererseits, weil die Anforderungen angepasst wurden. Bei XP ist das Design nicht führend, es folgt dem Code. Wenn Einfachheit gut ist, halten Sie das Design so einfach wie möglich.

Wohlbefinden des Entwicklers

Für das Wohl der Entwickler ist es wichtig, dass mit kontinuierlicher Geschwindigkeit gearbeitet wird, wobei im Laufe der Zeit ist eine Ausnahme. Menschen sind kreativer und arbeiten besser, wenn sie ausgeruht sind. Eine 40-Stunden-Woche sollte die Regel sein. Dies wird zum Teil durch kurze Iterationen, kontinuierliche Integrationen und gutes Feedback erreicht, damit die Leute nicht erst am Ende merken, dass sie es nicht schaffen und lange Überstunden machen müssen. Das Wohl der Entwickler ist eine (gute) Konsequenz dieser Methode und trägt maßgeblich zu ihrer Popularität bei.

Leistungen

  • Es ist bekannt, dass es einige sehr erfolgreiche Projekte gibt, aber es ist fraglich, ob diese Projekte aufgrund der Qualität der Personen, die daran teilgenommen haben, oder aufgrund der Qualität von XP erfolgreich waren.
  • XP behauptet, dass die Entwicklungskosten bei der Entwicklung großer Systeme nicht exponentiell steigen müssen.
  • flexibel.
  • Schnelle (teilen) Ergebnisse.

Nachteile

Aus der Praxis werden folgende Nachteile von XP genannt:

  • Es müssen enge Vereinbarungen zur Nutzerbeteiligung getroffen werden, um jegliche Unverbindlichkeit der Nutzer/Kunden im Keim zu ersticken. Das Schreiben von Unit-Tests sollte der Ausgangspunkt für die Softwareentwicklung sein und bleiben. Wenn Benutzer im Vorfeld keine Unit-Tests schreiben konnten, eventuell in Zusammenarbeit (Paaren) mit den Entwicklern und Entwicklern, trotzdem alleine weiter entwickeln und daher nicht wirklich nach den Best Practices arbeiten, dann entsteht ein System, das nicht erst spät umgesetzt, an die Benutzer gedacht, mit der Gefahr, dass vieles verworfen wird und neu gemacht werden muss.
  • Die Entwicklung von Code nur mit Blick auf die Wünsche der Benutzer kann auch Probleme bereiten, wenn ein Endziel (Zeitpunkt) im Auge behalten werden muss. Das Endziel kann von den temporären Zielen der zu realisierenden Iterationen überschattet werden. Dies führt leicht zu Verzögerungen bei der Auslieferung des endgültigen Systems. Man kann sich immer mehr vorstellen, was viel Zeit in Anspruch nimmt. Um diesen Nachteil von XP zu bewältigen, ist viel Aufmerksamkeit des Projektmanagers erforderlich.
  • Das oben Genannte hat auch Auswirkungen auf die Erwartungen des Kunden. Diese sollten ebenfalls Beachtung finden, solange XP noch keine bekannte Entwicklungsmethode ist.
  • Nicht jeder Entwickler ist ein Teamplayer. Pair-Programming ist nicht jedermanns Sache. Zwei junge Entwickler zusammen oder zwei hartnäckige Entwickler können eine schwierige Zeit haben.
  • Es werden Schwierigkeiten bei der Entwicklung erwartet Legacy-Code in Kombination mit Standardpakete.
  • Am wichtigsten ist vielleicht, dass es nicht einfach ist, XP zu implementieren, da die verschiedenen Elemente von XP miteinander interagieren. Ein gutes Ergebnis wird nur erwartet, wenn XP vollständig angewendet wird.

Externe Links