Extreme Programmierpraktiken – Wikipedia

Posted on by
before-content-x4

Extremes Programmieren ((XP) ist eine agile Softwareentwicklungsmethode zur Implementierung von Softwareprojekten. Dieser Artikel beschreibt die in dieser Methodik verwendeten Praktiken. Extreme Programming umfasst 12 Methoden, die in vier Bereiche unterteilt sind und sich aus den Best Practices der Softwareentwicklung ableiten.[1]

Feinskaliges Feedback[edit]

Paar-Programmierung[edit]

Paarprogrammierung bedeutet, dass der gesamte Code von zwei Personen erstellt wird, die an einer Aufgabe auf einer Workstation programmieren. Ein Programmierer hat die Kontrolle über die Workstation und denkt hauptsächlich über die Codierung im Detail nach. Der andere Programmierer konzentriert sich mehr auf das Gesamtbild und überprüft kontinuierlich den Code, der vom ersten Programmierer erstellt wird. Programmierer tauschen Rollen nach Minuten- bis Stundenperioden.

Die Paare sind nicht festgelegt; Programmierer wechseln häufig die Partner, sodass jeder weiß, was jeder tut, und jeder mit dem gesamten System vertraut bleibt, auch mit den Teilen außerhalb seiner Fähigkeiten. Auf diese Weise kann die Paarprogrammierung auch die teamweite Kommunikation verbessern. (Dies geht auch Hand in Hand mit dem Konzept des kollektiven Eigentums).

Planungsspiel[edit]

Der Hauptplanungsprozess innerhalb der extremen Programmierung wird als Planungsspiel bezeichnet. Das Spiel ist eine Besprechung, die einmal pro Iteration stattfindet, normalerweise einmal pro Woche. Der Planungsprozess gliedert sich in zwei Teile:

  • Release-Planung: Hier geht es darum zu bestimmen, welche Anforderungen in welchen kurzfristigen Releases enthalten sind und wann sie geliefert werden sollten. Die Kunden und Entwickler sind beide Teil davon. Die Release-Planung besteht aus drei Phasen:
    • Explorationsphase: In dieser Phase stellt der Kunde eine Auswahlliste mit hochwertigen Anforderungen an das System zur Verfügung. Diese werden auf User Story-Karten niedergeschrieben.
    • Commitment-Phase: In der Commitment-Phase verpflichten sich Unternehmen und Entwickler zu den Funktionen, die enthalten sein werden, und zum Datum der nächsten Version.
    • Lenkphase: In der Lenkphase kann der Plan angepasst, neue Anforderungen hinzugefügt und / oder bestehende Anforderungen geändert oder entfernt werden.
  • Iterationsplanung: Hier werden die Aktivitäten und Aufgaben der Entwickler geplant. An diesem Prozess ist der Kunde nicht beteiligt. Die Iterationsplanung besteht ebenfalls aus drei Phasen:
    • Explorationsphase: In dieser Phase wird die Anforderung in verschiedene Aufgaben übersetzt. Die Aufgaben werden auf Aufgabenkarten aufgezeichnet.
    • Verpflichtungsphase: Die Aufgaben werden den Programmierern zugewiesen und die Zeit, die für die Ausführung benötigt wird, wird geschätzt.
    • Lenkphase: Die Aufgaben werden ausgeführt und das Endergebnis wird mit der ursprünglichen User Story abgeglichen.

Der Zweck des Planungsspiels besteht darin, das Produkt in die Lieferung zu führen. Anstatt die genauen Daten vorherzusagen, wann Liefergegenstände benötigt und produziert werden, was schwierig ist, zielt es darauf ab, das Projekt mit einem einfachen Ansatz in die Lieferung zu lenken.[2] Der Planning-Game-Ansatz wurde auch von Nicht-Software-Projekten und -Teams im Kontext der geschäftlichen Agilität übernommen.[3]

Release-Planung[edit]

Explorationsphase[edit]

Dies ist ein iterativer Prozess zum Sammeln von Anforderungen und zum Schätzen der Arbeitsauswirkungen jeder dieser Anforderungen.

  • Schreiben Sie eine Geschichte: Das Geschäft hat ein Problem. Während eines Meetings wird die Entwicklung versuchen, dieses Problem zu definieren und Anforderungen zu erhalten. Basierend auf dem Geschäftsproblem muss eine Story (User Story) geschrieben werden. Dies geschieht durch Unternehmen, in denen sie darauf hinweisen, was ein Teil des Systems tun soll. Es ist wichtig, dass die Entwicklung keinen Einfluss auf diese Geschichte hat. Die Geschichte wird auf eine User Story-Karte geschrieben.
  • Eine Geschichte schätzen: Die Entwicklung schätzt, wie lange es dauern wird, bis die von der Story-Karte implizierte Arbeit umgesetzt ist. Die Entwicklung kann auch Spitzenlösungen erstellen, um das Problem zu analysieren oder zu lösen. Diese Lösungen werden zur Schätzung verwendet und verworfen, sobald alle eine klare Visualisierung des Problems erhalten. Auch dies hat möglicherweise keinen Einfluss auf die Geschäftsanforderungen.
  • Eine Geschichte teilen: Jede designkritische Komplexität muss berücksichtigt werden, bevor mit der Iterationsplanung begonnen wird. Wenn die Entwicklung die Geschichte nicht einschätzen kann, muss sie aufgeteilt und erneut geschrieben werden.

Wenn das Unternehmen keine weiteren Anforderungen stellen kann, geht man in die Verpflichtungsphase über.

after-content-x4
Verpflichtungsphase[edit]

In dieser Phase werden Kosten, Nutzen und Auswirkungen auf den Zeitplan ermittelt. Es hat vier Komponenten:

  • Nach Wert sortieren: Business sortiert die User Stories nach Business Value.
  • Nach Risiko sortieren: Die Entwicklung sortiert die Geschichten nach Risiko.
  • Geschwindigkeit einstellen: Die Entwicklung bestimmt, mit welcher Geschwindigkeit das Projekt ausgeführt werden kann.
  • Umfang auswählen: Die User Stories, die in der nächsten Version fertiggestellt werden, werden ausgewählt. Basierend auf den User Stories wird das Veröffentlichungsdatum festgelegt.
Nach Wert sortieren[edit]

Die Geschäftsseite sortiert die User Stories nach Geschäftswert. Sie werden sie in drei Stapel anordnen:

  • Kritisch: Geschichten, ohne die das System nicht funktionieren kann oder keine Bedeutung hat.
  • Signifikanter Geschäftswert: Unkritische User Stories mit signifikantem Geschäftswert.
  • Schön zu haben: User Stories, die keinen signifikanten geschäftlichen Wert haben.
Nach Risiko sortieren[edit]

Die Entwickler sortieren die User Stories nach Risiko. Sie lassen sich auch in drei Stapel einteilen: User Stories mit geringem, mittlerem und hohem Risiko. Das Folgende ist ein Beispiel für einen Ansatz hierfür:

  • Risikoindex bestimmen: Geben Sie jeder User Story einen Index von 0 bis 2 für jeden der folgenden Faktoren:
    • Vollständigkeit (kennen wir alle Details der Geschichte?)
      • Beende (0)
      • Unvollständig (1)
      • Unbekannt (2)
    • Volatilität (wird sich wahrscheinlich ändern?)
      • niedrig (0)
      • mittel (1)
      • hoch (2)
    • Komplexität (wie schwer ist es zu bauen?)
      • einfach (0)
      • Standard (1)
      • Komplex (2)

Alle Indizes für eine User Story werden hinzugefügt, wobei den User Stories ein Risikoindex von niedrig (0–1), mittel (2–4) oder hoch (5–6) zugewiesen wird.

Lenkphase[edit]

Innerhalb der Steuerungsphase können Programmierer und Geschäftsleute den Prozess “steuern”. Das heißt, sie können Änderungen vornehmen. Einzelne User Stories oder relative Prioritäten verschiedener User Stories können sich ändern. Schätzungen könnten sich als falsch erweisen. Dies ist die Möglichkeit, den Plan entsprechend anzupassen.

Iterationsplanung[edit]

Berücksichtigung der zu planenden Storypoints für die Teamgeschwindigkeit. Die Iterationsdauer kann 1 bis 3 Wochen betragen.

Explorationsphase[edit]

In der Explorationsphase der Iterationsplanung geht es darum, Aufgaben zu erstellen und deren Implementierungszeit abzuschätzen.

  • Übersetzen Sie die Anforderung in Aufgaben: Platzieren Sie sie auf Aufgabenkarten.
  • Aufgabe kombinieren / teilen: Wenn der Programmierer die Aufgabe nicht schätzen kann, weil sie zu klein oder zu groß ist, muss der Programmierer die Aufgabe kombinieren oder teilen.
  • Aufgabe schätzen: Schätzen Sie die Zeit, die zur Implementierung der Aufgabe benötigt wird.
Verpflichtungsphase[edit]

Innerhalb der Commitment-Phase der Iterationsplanung werden Programmierern Aufgaben zugewiesen, die auf die verschiedenen User Stories verweisen.

  • Ein Programmierer nimmt eine Aufgabe an: Jeder Programmierer wählt eine Aufgabe aus, für die er die Verantwortung übernimmt.
  • Der Programmierer schätzt die Aufgabe: Da der Programmierer jetzt für die Aufgabe verantwortlich ist, sollte er die eventuelle Schätzung der Aufgabe abgeben.
  • Lastfaktor einstellen: Der Lastfaktor repräsentiert die ideale Menge an praktischer Entwicklungszeit pro Programmierer innerhalb einer Iteration. In einer 40-Stunden-Woche mit 5 Stunden für Besprechungen wären dies beispielsweise nicht mehr als 35 Stunden.
  • Balancing: Wenn allen Programmierern im Team Aufgaben zugewiesen wurden, wird ein Vergleich zwischen der geschätzten Zeit der Aufgaben und dem Auslastungsfaktor durchgeführt. Dann werden die Aufgaben unter den Programmierern ausgeglichen. Wenn ein Programmierer überlastet ist, müssen andere Programmierer einige seiner Aufgaben übernehmen und umgekehrt.
Lenkphase[edit]

Die Implementierung der Aufgaben erfolgt während der Lenkphase der Iteration.

  • Aufgabenkarte erhalten: Der Programmierer erhält die Aufgabenkarte für eine der Aufgaben, für die er sich verpflichtet hat.
  • Partner finden: Der Programmierer implementiert diese Aufgabe zusammen mit einem anderen Programmierer. Dies wird in der Praxis der Paarprogrammierung weiter erläutert.
  • Entwerfen der Aufgabe: Bei Bedarf entwerfen die Programmierer die Funktionalität der Aufgabe.
  • Implementieren Sie die Aufgabe mithilfe der testgetriebenen Entwicklung (TDD) (siehe unten).
  • Funktionstest ausführen: Funktionstests (basierend auf den Anforderungen in der zugehörigen User Story und Task Card) werden ausgeführt.

Testgetriebene Entwicklung[edit]

Unit-Tests sind automatisierte Tests, die die Funktionalität von Codeteilen (z. B. Klassen, Methoden) testen. Innerhalb von XP werden Komponententests geschrieben, bevor der eventuelle Code codiert wird. Dieser Ansatz soll den Programmierer dazu anregen, über Bedingungen nachzudenken, unter denen sein Code fehlschlagen könnte. XP sagt, dass der Programmierer mit einem bestimmten Code fertig ist, wenn er keine weiteren Bedingungen finden kann, unter denen der Code möglicherweise fehlschlägt.

Die testgetriebene Entwicklung erfolgt durch schnelles Durchlaufen der folgenden Schritte, wobei jeder Schritt höchstens Minuten dauert, vorzugsweise viel weniger. Da jede User Story normalerweise ein bis zwei Arbeitstage erfordert, ist pro Story eine sehr große Anzahl solcher Zyklen erforderlich.

  • Unit-Test schreiben: Die Programmierer schreiben einen minimalen Test, der fehlschlagen sollte, da die Funktionalität im Produktionscode nicht vollständig implementiert wurde.
  • Beobachten Sie, wie der neue Test fehlschlägt: Die Programmierer überprüfen, ob der Test tatsächlich fehlschlägt. Obwohl dies wie Zeitverschwendung erscheint, ist dieser Schritt von entscheidender Bedeutung, da er bestätigt, dass Ihre Überzeugung vom Status des Produktionscodes korrekt ist. Wenn der Test nicht fehlschlägt, sollten die Programmierer feststellen, ob der Testcode einen Fehler enthält oder ob der Produktionscode die im neuen Test beschriebene Funktionalität unterstützt.
  • Code schreiben: Die Programmierer schreiben gerade genug Produktionscode, damit der neue Test bestanden wird.
  • Test ausführen: Die Komponententests werden ausgeführt, um sicherzustellen, dass der neue Produktionscode den neuen Test besteht und keine anderen Tests fehlschlagen.
  • Refactor: Entfernen Sie alle Codegerüche aus dem Produktions- und Testcode.

Eine intensivere Version des obigen Prozesses finden Sie in den drei TDD-Regeln von Onkel Bob.[4]

Ganzes Team[edit]

Innerhalb von XP ist der “Kunde” nicht derjenige, der die Rechnung bezahlt, sondern derjenige, der das System wirklich nutzt. XP sagt, dass der Kunde jederzeit zur Verfügung stehen und für Fragen zur Verfügung stehen sollte. Zum Beispiel sollte das Team, das ein Finanzverwaltungssystem entwickelt, einen Finanzadministrator umfassen.

Kontinuierlicher Prozess[edit]

Kontinuierliche Integration[edit]

Das Entwicklungsteam sollte immer an der neuesten Version der Software arbeiten. Da verschiedene Teammitglieder möglicherweise Versionen mit verschiedenen Änderungen und Verbesserungen lokal gespeichert haben, sollten sie versuchen, ihre aktuelle Version alle paar Stunden oder wenn sich eine erhebliche Unterbrechung ergibt, in das Code-Repository hochzuladen. Durch die kontinuierliche Integration werden Verzögerungen später im Projektzyklus vermieden, die durch Integrationsprobleme verursacht werden.

Designverbesserung[edit]

Da die XP-Doktrin befürwortet, nur das zu programmieren, was heute benötigt wird, und es so einfach wie möglich zu implementieren, kann dies manchmal dazu führen, dass ein System stecken bleibt. Eines der Symptome hierfür ist die Notwendigkeit einer doppelten (oder mehrfachen) Wartung: Funktionsänderungen erfordern Änderungen an mehreren Kopien desselben (oder ähnlichen) Codes. Ein weiteres Symptom ist, dass Änderungen in einem Teil des Codes viele andere Teile betreffen. Die XP-Doktrin besagt, dass das System Sie in diesem Fall auffordert, Ihren Code durch Ändern der Architektur umzugestalten, um ihn einfacher und allgemeiner zu gestalten.

Kleine Veröffentlichungen[edit]

Die Bereitstellung der Software erfolgt über häufige Releases von Live-Funktionen, die einen konkreten Wert schaffen. Die kleinen Releases helfen dem Kunden, Vertrauen in den Fortschritt des Projekts zu gewinnen. Dies trägt dazu bei, das Konzept des gesamten Teams aufrechtzuerhalten, da der Kunde nun seine Vorschläge für das Projekt auf der Grundlage realer Erfahrungen einbringen kann.

Gemeinsames Verständnis[edit]

Codierungsstandard[edit]

Der Codierungsstandard ist ein vereinbartes Regelwerk, das das gesamte Entwicklungsteam während des gesamten Projekts einhält. Der Standard legt einen einheitlichen Stil und ein einheitliches Format für den Quellcode innerhalb der gewählten Programmiersprache sowie verschiedene Programmierkonstrukte und -muster fest, die vermieden werden sollten, um die Wahrscheinlichkeit von Fehlern zu verringern.[5] Der Codierungsstandard kann eine vom Sprachanbieter festgelegte Standardkonvention sein (z. B. die von Sun empfohlenen Codekonventionen für die Java-Programmiersprache) oder vom Entwicklungsteam benutzerdefiniert definiert werden.

Unterstützer von Extreme Programming befürworten Code, der sich so weit wie möglich selbst dokumentiert. Dies reduziert die Notwendigkeit von Codekommentaren, die möglicherweise nicht mehr mit dem Code selbst synchronisiert sind.[6]

Kollektiver Codebesitz[edit]

Kollektiver Code-Besitz (auch als “Team-Code-Besitz” und “gemeinsamer Code” bezeichnet) bedeutet, dass jeder für den gesamten Code verantwortlich ist. Daher darf jeder einen Teil des Codes ändern. Der Besitz von kollektivem Code ist nicht nur eine Organisationsrichtlinie, sondern auch ein Gefühl. “Entwickler spüren den Besitz von Teamcode mehr, wenn sie den Systemkontext verstehen, zum fraglichen Code beigetragen haben, die Codequalität als hoch empfinden, glauben, dass das Produkt die Benutzeranforderungen erfüllt, und einen hohen Teamzusammenhalt wahrnehmen.”[7] Die Paarprogrammierung, insbesondere die überlappende Paarrotation, trägt zu dieser Praxis bei: Durch die Arbeit in verschiedenen Paaren verstehen Programmierer den Systemkontext besser und tragen zu mehr Bereichen der Codebasis bei.

Der Besitz von kollektivem Code kann die Entwicklung beschleunigen, da ein Entwickler, der einen Fehler entdeckt, diesen sofort beheben kann, wodurch Fehler insgesamt reduziert werden können. Programmierer können jedoch auch Fehler einführen, wenn sie Code ändern, den sie nicht gut verstehen. Ausreichend genau definierte Komponententests sollten dieses Problem mindern: Wenn unvorhergesehene Abhängigkeiten Fehler verursachen, werden beim Ausführen von Komponententests Fehler angezeigt.

Kollektiver Codebesitz kann zu einer besseren Sicherung der Mitglieder, einer besseren Verteilung von Wissen und Lernen, einer gemeinsamen Verantwortung für den Code, einer höheren Codequalität und einer geringeren Nacharbeit führen. Es kann aber auch zu vermehrten Konflikten zwischen Mitgliedern, vermehrten Fehlern, Änderungen des mentalen Flusses der Entwickler und Unterbrechungen ihrer Überlegungen, einer längeren Entwicklungszeit oder einem geringeren Verständnis des Codes führen.[8]

Einfaches Design[edit]

Programmierer sollten beim Software-Design einen “simple is best” -Ansatz wählen. Wenn ein neuer Code geschrieben wird, sollte sich der Autor fragen: Gibt es eine einfachere Möglichkeit, dieselbe Funktionalität einzuführen? Wenn die Antwort ja ist, sollte der einfachere Kurs gewählt werden. Refactoring sollte auch verwendet werden, um komplexen Code zu vereinfachen.

Systemmetapher[edit]

Die Systemmetapher ist eine Geschichte, die jeder – Kunden, Programmierer und Manager – über die Funktionsweise des Systems erzählen kann. Es ist ein Namenskonzept für Klassen und Methoden, das es einem Teammitglied erleichtern soll, die Funktionalität einer bestimmten Klasse / Methode nur anhand ihres Namens zu erraten. Beispielsweise kann ein Bibliothekssystem erstellt werden loan_records(class) zum borrowers(class)und wenn das Element überfällig wird, kann es eine make_overdue-Operation für a ausführen catalogue(class). Für jede Klasse oder Operation ist die Funktionalität für das gesamte Team offensichtlich.

Programmierer Wohlfahrt[edit]

Ein einhaltbares Schritttempo[edit]

Das Konzept ist, dass Programmierer oder Softwareentwickler nicht mehr als 40 Stunden pro Woche arbeiten sollten, und wenn es eine Woche Überstunden gibt, sollte die nächste Woche nicht mehr Überstunden beinhalten. Da es sich bei den Entwicklungszyklen um kurze Zyklen kontinuierlicher Integration handelt und vollständige Entwicklungszyklen (Release-Zyklen) häufiger sind, folgen die Projekte in XP nicht der typischen Crunch-Zeit, die andere Projekte benötigen (Überstunden erforderlich).

In diesem Konzept ist auch enthalten, dass Menschen am besten und kreativsten arbeiten, wenn sie gut ausgeruht sind.

Ein Schlüsselelement für ein nachhaltiges Tempo ist das häufige Zusammenführen von Code und immer ausführbarer und testabgedeckter Code von hoher Qualität. Die ständige Umgestaltung der Arbeitsweise erzwingt Teammitglieder mit frischen und aufmerksamen Köpfen. Die intensive Zusammenarbeit im Team erfordert ein Aufladen über die Wochenenden.

Gut getesteter, kontinuierlich integrierter, häufig bereitgestellter Code und Umgebungen minimieren auch die Häufigkeit unerwarteter Produktionsprobleme und -ausfälle sowie die damit verbundenen erforderlichen Nacht- und Wochenendarbeiten außerhalb der Geschäftszeiten.

Siehe auch[edit]

Verweise[edit]

  1. ^ Beck, K. Extreme Programmierung erklärt: Umfassen Sie Veränderungen 2 .. ed. Addison-Wesley, 2000, S. 54
  2. ^ Melnik, Grigori; Maurer, Frank (2004). Einführung agiler Methoden: Drei Jahre Erfahrung. Tagungsband der 30. Euromicro-Konferenz. IEEE. S. 334–341. CiteSeerX 10.1.1.296.4732. doi:10.1109 / EURMIC.2004.1333388.
  3. ^ Leybourn, E. (2013). Führung der agilen Organisation: Ein schlanker Ansatz für die Unternehmensführung. London: IT Governance Publishing: 146–150.
  4. ^ Martin, Robert. “Drei Regeln von TDD”.
  5. ^ Kolawa, Adam; Huizinga, Dorota (2007). Automatisierte Fehlervermeidung: Best Practices im Software-Management. Wiley-IEEE Computer Society Press. p. 75. ISBN 978-0-470-04212-0.
  6. ^ http://guzdial.cc.gatech.edu/squeakbook/new-lecture-slides/xp.ppt
  7. ^ Sedano, Todd; Ralph, Paul; Péraire, Cécile. “Praxis und Wahrnehmung des Besitzes von Teamcodes”. ACM.
  8. ^ Ribeiro, Danilo und Silva, Fabio und Valença, Diana und Freitas, Elyda und França, César. (2016). Vor- und Nachteile der Verwendung von Shared Code aus Entwicklersicht: Eine qualitative Studie.

Externe Links[edit]

after-content-x4