Bildquelle: pixabay.com

Extremes Programmieren

Stellen Sie sich Folgendes vor: Ein Softwareentwicklungsprojekt für ein neues Produkt, das auf dem ersten Marktvorteil basiert, wurde soeben auf dem Radar Ihres Unternehmens entdeckt. Herkömmliche Methoden der Extremprogrammierung, bei denen der Kunde „genau“ weiß, was er will, gibt es nicht. Ihr Team ist klein und besteht aus jungen Fachleuten, die wahrscheinlich gut auf ein radikales Projektmanagementmodell reagieren. Welche Möglichkeiten haben Sie?

Sie werden wahrscheinlich sagen, Agiles Projektmanagement natürlich! Aber welche Methode möchten Sie anwenden? Es gibt mehrere Optionen: Zum einen gibt es das äußerst beliebte Scrum: Dabei werden kurze „Sprints“ basierend auf dem Auftragsbestand der Kunden erstellt. Und dann gibt es noch Kanban, mit dem die Pipeline der Arbeit optimiert wird. Es gibt auch Extreme Programming, oft als XP abgekürzt, das sich darauf konzentriert, die positiven Aspekte traditioneller Programmiermodelle zu verstärken, damit sie ihr maximales Potenzial entfalten.

Extreme Programming ist eine äußerst beliebte (wenn auch nicht so beliebte wie Scrum) Methode, die sich auf die Erfüllung sich ändernder Kundenanforderungen konzentriert. Das erste Extreme Programming-Projekt wurde im März 1996 von Kent Beck bei Chrysler gestartet. In seinem Buch Extreme Programming Explained: Embrace Change aus dem Jahr 1999 ging er auf die Aspekte der Softwareentwicklung ein.

Kent Beck war auch der Pionier der testgetriebenen Entwicklung, bei der Use-Case-Tests als Verbesserung der damaligen Vorgehensweise auf dem Radar eingesetzt wurden: Schreiben und Testen von Codezeilen. Er war auch einer der ursprünglichen Unterzeichner des Agilen Manifests und half dabei, das Manifest so zu gestalten, dass die Art und Weise, wie extreme Programmiersoftware geschrieben wurde, geändert wurde.

Die fünf Werte von Extreme Programming basieren auf Explained sind:

Kommunikation

Extreme Programming ist nicht von einer umfangreichen Dokumentation abhängig. Tatsächlich wird extreme Programmierdokumentation nur dann empfohlen, wenn dies erforderlich ist. Die Methodik stützt sich daher stark auf die Kommunikation zwischen den Teammitgliedern und auch mit den Benutzern.

Einfachheit

Dies ist der Kern von Extreme Programming. Die Methodik bevorzugt einfache Designs, die nicht zu weit in die Zukunft denken, sondern sich auf die Anforderungen von heute konzentrieren, während das Programm selbst robust genug ist, um die Anforderungen zu berücksichtigen, die die Zukunft stellt.

Feedback

Diese wesentliche Hin- und Her-Schleife unterscheidet Agile Systeme im Allgemeinen und Extreme Programming im Besonderen von anderen Methoden für das Software-Projektmanagement. Das kontinuierliche Feedback kann auf verschiedene Arten funktionieren, aber alle tragen dazu bei, das System stärker und zuverlässiger zu machen.

Feedback kann in verschiedenen Varianten erfolgen:

  • Aus dem Programm selbst: Code wird während des gesamten Projektentwicklungszyklus intensiv getestet, sodass Änderungen von den Entwicklern implementiert werden können.
  • Vom Kunden: Dies ist ein wesentlicher Bestandteil der meisten agilen Systeme. Kunden schreiben die Abnahmetests, auf denen die Entwicklung basiert, und dies bildet das Rückgrat des Entwicklungsprozesses. Alle Iterationen werden auch an den Kunden gesendet, um eine regelmäßige Rückmeldung zu erhalten.
  • Vom Team: Sobald ein neuer Anwendungsfall / eine neue Anwendungsgeschichte erstellt wurde, kehrt das Team sofort mit einer Kosten- und Zeitschätzung zurück und verschärft die Anforderungen, sobald sie auftreten. In der extremen Programmierung „besitzt“ niemand einen Code, und daher wird in extremen Programmierteams Feedback zum Code des anderen ermutigt.

Mut

Dies scheint ein seltsamer Wert für extreme Programmieraufgaben in der Softwareentwicklung zu sein, der eher für die Armee oder die Marines geeignet ist! Denken Sie jedoch darüber nach: Softwareprojekte sind seit langem durch traditionelle extreme Programmiermethoden des Managements festgefahren. Sicher im Komfort einer umfassenden Dokumentation und Hierarchie, die keine Innovation zulässt. Dieser Wert ist ein Beispiel für den Kern der extremen Programmierung: Seien Sie bereit zu springen, ohne einen Fallschirm, wenn es darum geht! Schauen Sie sich diesen anderen Stil des Projektmanagements an und seien Sie bereit, verantwortlich zu sein, auf Hierarchie zu verzichten und verantwortlich zu sein und zu arbeiten, ohne alles am Anfang selbst zu wissen.

Respekt

Respekt, der fünfte Wert, wurde später hinzugefügt und bedeutet Respekt für andere und das Selbst. Dies impliziert auch Respekt für den Code, der geschrieben wird, und für die Erwartungen und Bedürfnisse des Kunden. Dieser Wert liegt auch der Kommunikation zwischen verschiedenen Stakeholdern zugrunde.

Aktivitäten eines Extreme Programming Projekts

Extreme Programming unterscheidet vier einfache Aktivitäten eines Projekts. Sie sind:

  • Codierung : Extreme Programming betrachtet dies als die wichtigste Aktivität. „Ohne Code gibt es nichts“, sagt Kent Beck, der Begründer von Extreme Programming.
  • Testen : Code ist genau das, sofern er nicht getestet wird. Extreme Programming ist vom Testen besessen, indem Unit-Tests verwendet werden, um zu bestätigen, dass der Code funktioniert, und vom Client generierte Akzeptanztests, um zu bestätigen, dass der Code testet, was getestet werden muss.
  • Zuhören: Zuhören ist eine Aktivität, bei der die Entwickler nicht nur die Kunden hören, sondern auch wirklich zuhören müssen, was sie wollen. Entwicklung und Geschäft sind zwei verschiedene Dinge und oft verstehen Entwickler den Geschäftsfall einer bestimmten Entscheidung nicht. Die Bedürfnisse des Kunden sowie der Entwickler bilden die Grundlage für das Zuhören.
  • Entwerfen : Es könnte Sie überraschen, dass in einem Softwareentwicklungsprojekt die häufig so wichtige und vorrangige Entwurfsaktivität am Ende steht. Dies liegt daran, dass Extreme Programming bewusst Menschen aus der Denkweise herausholen will, die die Branche seit vielen Jahren gepflegt hat. Dies soll die Bedeutung des Entwerfens nicht einschränken. Gutes und minimalistisches Design ist vielmehr eines der Kennzeichen eines Projekts.

Aus den Werten und Aktivitäten ergeben sich die 12 Prinzipien des Extreme Programming, wie sie vom Gründer in seinem Buch Extreme Programming Explained entwickelt wurden.

  • Planungsspiel
  • Paar-Programmierung
  • Testgetriebene Entwicklung
  • Ganzes Team
  • Kontinuierliche Integration
  • Designverbesserung
  • Kleine Veröffentlichungen
  • Kodierungsstandards
  • Kollektiver Code-Besitz
  • Einfaches Design
  • System-Metapher
  • Ein einhaltbares Schritttempo

Einige dieser extremen Programmierpraktiken, die alle den Best Practices des Software-Engineerings entsprechen, unterscheiden sich von den allgemeinen Agile-Methoden. Einige der Praktiken der extremen Programmierung werden nachfolgend erläutert:

  1. Planungsspiel

Dies ist der Planungsteil des Projekts, der als "Planungsspiel" bezeichnet wird. Es umfasst die Planung der nächsten Iteration und Freigabe in Absprache mit dem Benutzer / Client sowie eine interne Planung der Teams hinsichtlich der Aufgaben, an denen sie arbeiten werden.

  1. Paar-Programmierung

Hierbei arbeiten zwei Personen an einem Code. Eine Person, genannt Tastatur, gibt den Code ein, während die andere, genannt Monitor, den Code überwacht, kommentiert und verfeinert, je nach Bedarf. Die beiden Personen tauschen oft ihre Rollen. Es wurde nachgewiesen, dass dies die Effizienz von Code erheblich verbessert. Dies ist möglicherweise nicht für alle Entwicklungsszenarien geeignet. Dies ist zu berücksichtigen, bevor Sie sich für Extreme Programming anmelden.

  1. Testgetriebene Entwicklung

Jeder geschriebene Code wird einheitlich überprüft, dh jeder Code, der etwas kann, wird zuerst getestet. Extreme Programming legt großen Wert auf das Testen. Dies hilft zu bestätigen, dass der Code funktioniert, und dass er dann für die Aufnahme in das extreme Programmierprojekt selbst in Betracht gezogen werden kann. Es ist analog zu Unit-Tests in der Schule: Kleine Informationen werden getestet, damit der Lehrer / Schüler Kurskorrekturen vornehmen kann und bei den jährlichen Prüfungen nicht aus dem Ruder läuft!

  1. Designverbesserung (Refactoring)

XP-Projekte zielen aufgrund ihrer Einfachheit darauf ab, den geschriebenen Code kontinuierlich zu verbessern. Dies bedeutet, dass der gesamte Code (und manchmal auch die Datenbank) immer verbessert wird. Beim Refactoring werden keine Funktionen hinzugefügt. es verbessert lediglich den vorhandenen Code. Macht es enger und klarer. Es ist vergleichbar damit, ein Stück zu bearbeiten, es zu polieren und es besser zu machen.

  1. Einfaches Design

In Extreme Programming werden Funktionen erst hinzugefügt, wenn sie speziell erforderlich sind. Auch wenn der Code, an dem derzeit gearbeitet wird, sehr ähnlich zu dem ist, was in Zukunft möglicherweise erforderlich sein wird, wird er nur dann verwendet, wenn dies als User Story vereinbart wurde.

  1. System-Metapher

Dazu gehört die Vereinheitlichung aller Namenskonventionen, damit Zweck und Funktion leicht zu entschlüsseln sind. Zum Beispiel können die Operationen oder jedem Programmierer helfen, ihre Funktionalität zu verstehen. Dies sollte über das gesamte extreme Programmierprojekt erfolgen, so dass es für jeden leicht ist, den Code zu betrachten und gegebenenfalls zu ändern oder zu verbessern.

Rollen innerhalb eines Extreme Programming Projekts:

Wie Scrum hat Extreme Programming in jedem Projekt einige festgelegte Rollen. Nun müssen die Rollen nicht immer von unterschiedlichen Personen ausgeführt werden, und eine Person kann mehr als eine Rolle übernehmen.

Die Extreme Programming Rollen sind:

  • Kunde : Selbsterklärend. Der Grund für das Projekt. Sie entscheidet, was das Projekt tun muss. Sie liefert die User Stories.
  • Programmierer : Dies ist die Person, die:
    • Nimmt die Geschichten auf, die sich der Kunde einfallen lässt
    • Erstellt Programmieraufgaben aus Geschichten
    • Implementiert die User Stories
    • Testet den Code nach Einheit
  • Coach : Der Coach stellt im Allgemeinen sicher, dass das Projekt auf dem richtigen Weg ist, und springt auch ein, um bei Bedarf zu helfen.
  • Tracker : Der Tracker stellt in festgelegten Intervallen spezifische Anfragen an Programmierer. In der Regel prüft er den Fortschritt der Programmierer und bietet Hilfe an, wenn dies erforderlich ist: Ärmel hochkrempeln und direkt mit dem Code helfen, den Coach informieren oder je nach Bedarf ein Meeting mit dem Kunden vereinbaren.
  • Tester : Führt Funktionstests durch. Der Tester führt keine Komponententests durch, die von den Programmierern selbst durchgeführt werden.
  • Doomsayer: Wie der Name schon sagt, ähnelt dies dem Black Hat in Edward De Bonos System des Gruppendenkens. Jeder könnte ein Weltuntergangsjäger sein, der normalerweise potenzielle Probleme aufzeigt und dabei hilft, Probleme in der richtigen Perspektive zu halten.
  • Manager : Der Manager in einem Extreme Programming-Projekt ähnelt eher einem Planer, der sicherstellt, dass die Besprechungen wie geplant stattfinden und dass die während der Besprechungen getroffenen Entscheidungen an die entsprechende Person weitergeleitet werden, meistens an den Tracker. Der Manager sagt den Leuten jedoch nicht, was zu tun ist und wann. Dies erfolgt durch den Kunden und / oder die User Stories selbst.
  • Goldbesitzer : Der Goldbesitzer ist die Person, die das Projekt finanziert. Dies könnte der Kunde sein, muss es aber nicht sein.

Einige der oben beschriebenen extremen Programmierrollen können kombiniert werden, andere jedoch eindeutig nicht.

Der Kunde kann beispielsweise nicht auch der Programmierer sein. Ebenso können der Programmierer und der Verfolger nicht dieselbe Person sein.

Die extremen Programmierrollen sind klar genug definiert, damit keine Verwirrung entsteht, und sorgen für maximale Flexibilität und Effizienz.

Nachteile der extremen Programmierung:

Während die Befürworter von Extreme Programming ein rosiges Bild zeichnen, ist die Tatsache, dass Extreme Programming, wie der Name vermuten lässt, äußerst schwierig zu implementieren ist. Facetten der extremen Programmierung lassen sich erfolgreicher in Projekte einbinden als die vollständige Übernahme von XP.

Einige der negativen Aspekte der extremen Programmierung sind:

  • Extreme Programming hat sich in kleineren Gruppen als effektiver erwiesen . Die Effizienz in größeren Gruppen ist umstritten. Besser ist es, extreme Programmierteams so aufzuteilen, dass die Gruppen kleiner werden.
  • Eines der Hauptmerkmale von Extreme Programming ist, dass die Paarprogrammierung in vielen Fällen nicht gut funktioniert . Für eine komplexe Codierung sind möglicherweise zwei Köpfe erforderlich, aber nicht für alle Aufgaben sind möglicherweise zwei Personen erforderlich, wobei die zweite Person ein Eigengewicht darstellt. In der Tat ist die Paarprogrammierung, wenn eines der Mitglieder nicht mit dem anderen synchron ist, einer der Hauptgründe, warum Extreme Programming in vielen Fällen fehlschlägt.
  • Die Abhängigkeit vom Kunden, bis hin zu einer kundenseitigen Ressource vor Ort, kann zutiefst beunruhigend sein. Es kann auch zu realen und imaginären Interferenzen während der Entwicklung kommen.
  • Der Fokus von Extreme Programming auf Einfachheit kann es sehr schwierig machen , das aktuelle Projekt zu erweitern, was ein höheres Budget für selbst einfache Änderungen bedeutet, die nicht mehr einfach sind.
  • Die flache hierarchische Struktur bedeutet, dass das Team immer fokussiert sein sollte. Da es keinen Manager gibt, der unterschiedliche Typen von Leuten anspricht, ist ein Extreme Programming-Team vollständig von der emotionalen Reife aller Teammitglieder abhängig, ein Faktor, der nicht immer zuverlässig ist .

Trotz dieser Faktoren bleibt Extreme Programming ein leistungsstarkes Werkzeug für das richtige Projekt. Unternehmen verzeichnen nach Einführung des extremen Programmierprozesses eine deutliche Steigerung ihrer Effizienz. Ein entwicklergesteuertes System im Gegensatz zu Scrum, das eher ein prozessgesteuertes System ist, Extreme Programming oder zumindest Teile davon, kann zu einer Revolution in der Art und Weise führen, wie wir extreme Programmiersoftware entwickeln.