Extreme Programmierung – Wikipedia

Softwareentwicklungsmethode

Extremes Programmieren ((XP) ist eine Softwareentwicklungsmethode, die die Softwarequalität und die Reaktionsfähigkeit auf sich ändernde Kundenanforderungen verbessern soll. Als eine Art agile Softwareentwicklung,^[1][2][3] Es befürwortet häufige “Releases” in kurzen Entwicklungszyklen, um die Produktivität zu verbessern und Checkpoints einzuführen, an denen neue Kundenanforderungen übernommen werden können.

Weitere Elemente der extremen Programmierung sind: Paarweise Programmierung oder umfassende Codeüberprüfung, Unit-Test des gesamten Codes, Programmierfunktionen erst dann, wenn sie tatsächlich benötigt werden, eine flache Verwaltungsstruktur, Einfachheit und Klarheit des Codes, Erwartung von Änderungen der Kundenanforderungen im Laufe der Zeit und das Problem wird besser verstanden und häufige Kommunikation mit dem Kunden und unter Programmierern.^[2][3][4] Die Methodik hat ihren Namen von der Idee, dass die nützlichen Elemente traditioneller Software-Engineering-Praktiken auf “extreme” Ebenen gebracht werden. Beispielsweise werden Codeüberprüfungen als vorteilhafte Praxis angesehen. Im Extremfall kann der Code überprüft werden ständigdh die Praxis der Paarprogrammierung.

Geschichte[edit]

Kent Beck entwickelte während seiner Arbeit am Lohn- und Gehaltsabrechnungsprojekt Chrysler Comprehensive Compensation System (C3) extreme Programmierkenntnisse.^[5] Beck wurde im März 1996 C3-Projektleiter. Er begann die im Projekt verwendete Entwicklungsmethodik zu verfeinern und schrieb ein Buch über die Methodik (Extreme Programmierung erklärt, veröffentlicht im Oktober 1999).^[5]Chrysler stornierte das C3-Projekt im Februar 2000 nach sieben Jahren, als Daimler-Benz das Unternehmen übernahm.^[6]

Viele extreme Programmierpraktiken gibt es schon seit einiger Zeit; Die Methodik bringt “Best Practices” auf ein extremes Niveau. Zum Beispiel wurde die “Praxis der Test-First-Entwicklung, Planung und des Schreibens von Tests vor jedem Mikroinkrement” bereits in den frühen 1960er Jahren im NASA-Projekt Mercury angewendet. Um die Gesamtentwicklungszeit zu verkürzen, wurden einige formale Testdokumente (z. B. für Abnahmetests) parallel (oder kurz zuvor) zur Testbereitschaft der Software entwickelt. Eine unabhängige Testgruppe der NASA kann die Testverfahren basierend auf formalen Anforderungen und logischen Grenzen schreiben, bevor Programmierer die Software schreiben und in die Hardware integrieren. XP bringt dieses Konzept auf ein extremes Niveau und schreibt automatisierte Tests (manchmal innerhalb von Softwaremodulen), die den Betrieb selbst kleiner Abschnitte der Softwarecodierung validieren, anstatt nur die größeren Funktionen zu testen.

Ursprünge[edit]

Zwei wichtige Einflüsse prägten die Softwareentwicklung in den neunziger Jahren:

Sich schnell ändernde Anforderungen erforderten kürzere Produktlebenszyklen und stießen häufig auf herkömmliche Methoden der Softwareentwicklung.

Das Chrysler Comprehensive Compensation System (C3) wurde gestartet, um den besten Weg für den Einsatz von Objekttechnologien zu ermitteln. Dabei wurden die Lohn- und Gehaltsabrechnungssysteme von Chrysler als Forschungsobjekt verwendet, wobei Smalltalk als Sprache und GemStone als Datenzugriffsschicht verwendet wurden. Chrysler brachte Kent Beck,^[5] Er war ein bekannter Smalltalk-Praktiker, der die Leistung des Systems optimierte. Seine Rolle wurde jedoch erweitert, als er mehrere Probleme mit dem Entwicklungsprozess feststellte. Er nutzte diese Gelegenheit, um einige Änderungen in den Entwicklungspraktiken vorzuschlagen und umzusetzen – basierend auf seiner Arbeit mit seinem häufigen Mitarbeiter Ward Cunningham. Beck beschreibt die frühe Konzeption der Methoden:^[8]

Als ich zum ersten Mal gebeten wurde, ein Team zu leiten, bat ich sie, ein wenig von den Dingen zu tun, die ich für sinnvoll hielt, wie Tests und Bewertungen. Das zweite Mal war viel mehr auf der Linie. Ich dachte: “Verdammt die Torpedos, zumindest wird dies einen guten Artikel ergeben.” [and] bat das Team, alle Knöpfe für die Dinge, die ich für wesentlich hielt, auf 10 zu stellen und alles andere wegzulassen.

Beck lud Ron Jeffries zu dem Projekt ein, um diese Methoden zu entwickeln und zu verfeinern. Jeffries fungierte danach als Trainer, um die Praktiken als Gewohnheiten in das C3-Team zu vermitteln.

Informationen über die Prinzipien und Praktiken hinter XP wurden durch Diskussionen im Original-Wiki, Cunninghams WikiWikiWeb, in der ganzen Welt verbreitet. Verschiedene Autoren diskutierten und erweiterten die Ideen, und es ergaben sich einige Ausgründungsmethoden (siehe agile Softwareentwicklung). Außerdem wurden XP-Konzepte erläutert^{[by whom?]}Verwenden Sie mehrere Jahre lang eine Hypertext-Systemkarte auf der XP-Website unter http://www.extremeprogramming.org circa 1999.

Beck hat eine Reihe von Büchern über XP herausgegeben, beginnend mit seinen eigenen Extreme Programmierung erklärt (1999, ISBN 0-201-61641-6) und verbreitete seine Ideen an ein viel größeres Publikum. Die Autoren der Reihe haben verschiedene Aspekte der Teilnahme an XP und seinen Praktiken durchlaufen. Die Reihe enthielt ein Buch, das die Praktiken kritisierte.

Aktuellen Zustand[edit]

XP stieß in den späten 1990er und frühen 2000er Jahren bei Software-Communities auf großes Interesse und wurde in einer Reihe von Umgebungen eingeführt, die sich grundlegend von ihren Ursprüngen unterschieden.

Die hohe Disziplin, die von den ursprünglichen Praktiken gefordert wurde, blieb oft auf der Strecke, was dazu führte, dass einige dieser Praktiken, wie jene, die für zu starr gehalten wurden, an einzelnen Standorten veraltet oder reduziert oder sogar unvollendet blieben. Beispielsweise könnte die Praxis von Integrationstests am Tagesende für ein bestimmtes Projekt in einen Wochenendplan geändert oder einfach auf Tests zu einvernehmlich festgelegten Terminen reduziert werden. Solch ein entspannterer Zeitplan könnte verhindern, dass Menschen sich gehetzt fühlen, künstliche Stummel zu erzeugen, um die Tests am Ende des Tages zu bestehen. Ein weniger strenger Zeitplan ermöglicht stattdessen die Entwicklung komplexer Funktionen über einen Zeitraum von mehreren Tagen.

In der Zwischenzeit sind andere agile Entwicklungspraktiken nicht zum Stillstand gekommen, und zwar ab 2019^[update] XP entwickelt sich weiter und nimmt mehr Lehren aus den Erfahrungen auf diesem Gebiet auf, um andere Praktiken anzuwenden. In der zweiten Ausgabe von Extreme Programmierung erklärt (November 2004), fünf Jahre nach der ersten Ausgabe, fügte Beck weitere Werte und Praktiken hinzu und unterschied zwischen primären und Folgerungspraktiken.

Die Theorie der nachhaltigen Softwareentwicklung erklärt, warum extreme Programmierteams trotz Teamstörungen gedeihen können.^{[9][non-primary source needed]}

Konzept[edit]

Tore[edit]

Extreme Programmierung erklärt beschreibt extreme Programmierung als eine Softwareentwicklungsdisziplin, die Menschen organisiert, um qualitativ hochwertigere Software produktiver zu produzieren.

XP versucht, die Kosten für Änderungen der Anforderungen zu senken, indem mehrere kurze und keine langen Entwicklungszyklen durchgeführt werden. In dieser Doktrin sind Änderungen ein natürlicher, unausweichlicher und wünschenswerter Aspekt von Softwareentwicklungsprojekten und sollten geplant werden, anstatt zu versuchen, einen stabilen Satz von Anforderungen zu definieren.

Extreme Programming führt neben dem agilen Programmier-Framework auch eine Reihe grundlegender Werte, Prinzipien und Praktiken ein.

Aktivitäten[edit]

XP beschreibt vier grundlegende Aktivitäten, die im Rahmen des Softwareentwicklungsprozesses ausgeführt werden: Codieren, Testen, Abhören und Entwerfen. Jede dieser Aktivitäten wird unten beschrieben.

Codierung[edit]

Die Befürworter von XP argumentieren, dass das einzige wirklich wichtige Produkt des Systementwicklungsprozesses Code-Software-Anweisungen sind, die ein Computer interpretieren kann. Ohne Code gibt es kein funktionierendes Produkt.

Die Codierung kann verwendet werden, um die am besten geeignete Lösung herauszufinden. Das Codieren kann auch dazu beitragen, Gedanken über Programmierprobleme zu kommunizieren. Ein Programmierer, der sich mit einem komplexen Programmierproblem befasst oder es schwierig findet, anderen Programmierern die Lösung zu erklären, könnte es auf vereinfachte Weise codieren und den Code verwenden, um zu demonstrieren, was sie bedeuten. Code, sagen die Befürworter dieser Position, ist immer klar und prägnant und kann nicht auf mehr als eine Weise interpretiert werden. Andere Programmierer können Feedback zu diesem Code geben, indem sie auch ihre Gedanken codieren.

Testen[edit]

Das Testen ist für die extreme Programmierung von zentraler Bedeutung.^[10] Der Ansatz der extremen Programmierung besteht darin, dass, wenn ein wenig Testen einige Fehler beseitigen kann, viele Tests viel mehr Fehler beseitigen können.

• Unit-Tests bestimmen, ob eine bestimmte Funktion wie beabsichtigt funktioniert. Programmierer schreiben so viele automatisierte Tests, wie sie sich vorstellen können, die den Code “brechen” könnten. Wenn alle Tests erfolgreich ausgeführt wurden, ist die Codierung abgeschlossen. Jeder geschriebene Code wird getestet, bevor mit der nächsten Funktion fortgefahren wird.
• Abnahmetests bestätigen, dass die von den Programmierern verstandenen Anforderungen den tatsächlichen Anforderungen des Kunden entsprechen.

Systemweite Integrationstests wurden zunächst als tägliche Aktivität am Tagesende zur Früherkennung inkompatibler Schnittstellen empfohlen, um die Verbindung wiederherzustellen, bevor die einzelnen Abschnitte stark von der kohärenten Funktionalität abweichen. Die systemweiten Integrationstests wurden jedoch abhängig von der Stabilität der gesamten Schnittstellen im System auf wöchentlich oder seltener reduziert.^{[citation needed]}

Hören[edit]

Programmierer müssen hören, was die Kunden vom System erwarten, welche “Geschäftslogik” benötigt wird. Sie müssen diese Anforderungen gut genug verstehen, um dem Kunden Feedback zu den technischen Aspekten zu geben, wie das Problem möglicherweise gelöst werden kann oder nicht. Die Kommunikation zwischen Kunde und Programmierer wird im weiter unten behandelt Planungsspiel.

Entwerfen[edit]

Unter dem Gesichtspunkt der Einfachheit könnte man natürlich sagen, dass die Systementwicklung nicht mehr als Codieren, Testen und Abhören erfordert. Wenn diese Aktivitäten gut ausgeführt werden, sollte das Ergebnis immer ein funktionierendes System sein. In der Praxis wird dies nicht funktionieren. Man kann einen langen Weg ohne Design zurücklegen, aber zu einem bestimmten Zeitpunkt wird man stecken bleiben. Das System wird zu komplex und die Abhängigkeiten innerhalb des Systems sind nicht mehr klar. Dies kann vermieden werden, indem eine Entwurfsstruktur erstellt wird, die die Logik im System organisiert. Durch gutes Design werden viele Abhängigkeiten innerhalb eines Systems vermieden. Dies bedeutet, dass das Ändern eines Teils des Systems keine Auswirkungen auf andere Teile des Systems hat.^{[citation needed]}

Werte[edit]

Extreme Programming erkannte 1999 zunächst vier Werte: Kommunikation, Einfachheit, Feedback und Mut. Ein neuer Wert, Respekt, wurde in der zweiten Ausgabe von hinzugefügt Extreme Programmierung erklärt. Diese fünf Werte werden unten beschrieben.

Kommunikation[edit]

Zum Erstellen von Softwaresystemen müssen die Systemanforderungen den Entwicklern des Systems mitgeteilt werden. In formalen Softwareentwicklungsmethoden wird diese Aufgabe durch Dokumentation erfüllt. Extreme Programmiertechniken können als Methoden zum schnellen Aufbau und zur Verbreitung von institutionellem Wissen unter Mitgliedern eines Entwicklungsteams angesehen werden. Ziel ist es, allen Entwicklern eine gemeinsame Ansicht des Systems zu geben, die der Ansicht der Benutzer des Systems entspricht. Zu diesem Zweck bevorzugt extreme Programmierung einfache Designs, gemeinsame Metaphern, die Zusammenarbeit von Benutzern und Programmierern, häufige verbale Kommunikation und Feedback.

Einfachheit[edit]

Extreme Programmierung empfiehlt, mit der einfachsten Lösung zu beginnen. Zusätzliche Funktionen können später hinzugefügt werden. Der Unterschied zwischen diesem Ansatz und konventionelleren Systementwicklungsmethoden besteht darin, dass der Fokus auf das Entwerfen und Codieren für die Anforderungen von heute anstatt für die von morgen, nächster Woche oder nächsten Monat gelegt wird. Dies wird manchmal als der Ansatz “Du wirst es nicht brauchen” (YAGNI) zusammengefasst.^[11] Befürworter von XP erkennen den Nachteil an, dass dies morgen manchmal mehr Aufwand bedeuten kann, um das System zu ändern. Ihre Behauptung ist, dass dies durch den Vorteil mehr als kompensiert wird, nicht in mögliche zukünftige Anforderungen zu investieren, die sich ändern könnten, bevor sie relevant werden. Das Codieren und Entwerfen für ungewisse zukünftige Anforderungen birgt das Risiko, Ressourcen für etwas auszugeben, das möglicherweise nicht benötigt wird, und möglicherweise wichtige Funktionen zu verzögern. In Bezug auf den Wert “Kommunikation” sollte eine einfache Gestaltung und Codierung die Qualität der Kommunikation verbessern. Ein einfaches Design mit sehr einfachem Code könnte von den meisten Programmierern im Team leicht verstanden werden.

Feedback[edit]

Bei extremer Programmierung bezieht sich Feedback auf verschiedene Dimensionen der Systementwicklung:

• Rückmeldung vom System: durch Schreiben von Unit-Tests,^[5] Bei regelmäßigen Integrationstests erhalten die Programmierer nach der Implementierung von Änderungen eine direkte Rückmeldung über den Status des Systems.
• Feedback des Kunden: Die Funktionstests (auch Akzeptanztests genannt) werden vom Kunden und den Testern geschrieben. Sie erhalten konkrete Rückmeldungen zum aktuellen Stand ihres Systems. Diese Überprüfung ist alle zwei oder drei Wochen geplant, damit der Kunde die Entwicklung problemlos steuern kann.
• Feedback des Teams: Wenn Kunden im Planungsspiel neue Anforderungen stellen, gibt das Team direkt eine Schätzung der Zeit, die für die Implementierung benötigt wird.

Feedback ist eng mit Kommunikation und Einfachheit verbunden. Fehler im System können leicht kommuniziert werden, indem ein Komponententest geschrieben wird, der beweist, dass ein bestimmter Code beschädigt wird. Die direkte Rückmeldung vom System weist die Programmierer an, diesen Teil neu zu codieren. Ein Kunde kann das System regelmäßig gemäß den funktionalen Anforderungen testen, die als bekannt sind benutzergeschichten.^[5] Um Kent Beck zu zitieren: “Optimismus ist eine berufliche Gefahr der Programmierung. Feedback ist die Behandlung.”^[12]

Mut[edit]

Mehrere Praktiken verkörpern Mut. Eines ist das Gebot, immer für heute und nicht für morgen zu entwerfen und zu codieren. Dies ist ein Versuch, um zu vermeiden, dass das Design ins Stocken gerät und viel Aufwand erforderlich ist, um etwas anderes zu implementieren. Mit Courage können Entwickler ihren Code bei Bedarf umgestalten.^[5] Dies bedeutet, das vorhandene System zu überprüfen und zu ändern, damit zukünftige Änderungen einfacher implementiert werden können. Ein weiteres Beispiel für Mut ist das Wissen, wann Code weggeworfen werden muss: Mut, veralteten Quellcode zu entfernen, unabhängig davon, wie viel Aufwand für die Erstellung dieses Quellcodes aufgewendet wurde. Mut bedeutet auch Beharrlichkeit: Ein Programmierer kann einen ganzen Tag lang an einem komplexen Problem festhalten und das Problem dann am nächsten Tag schnell lösen, aber nur, wenn er hartnäckig ist.

Respekt[edit]

Der Respektwert beinhaltet Respekt vor anderen sowie Selbstachtung. Programmierer sollten niemals Änderungen vornehmen, die die Kompilierung unterbrechen, vorhandene Komponententests zum Scheitern bringen oder die Arbeit ihrer Kollegen auf andere Weise verzögern. Die Mitglieder respektieren ihre eigene Arbeit, indem sie stets nach hoher Qualität streben und durch Refactoring nach dem besten Design für die jeweilige Lösung suchen.

Die Übernahme der vier früheren Werte führt zu Respekt gegenüber anderen im Team. Niemand im Team sollte sich unbeachtet oder ignoriert fühlen. Dies sorgt für ein hohes Maß an Motivation und fördert die Loyalität gegenüber dem Team und dem Ziel des Projekts. Dieser Wert hängt von den anderen Werten ab und ist auf Teamarbeit ausgerichtet.

Regeln[edit]

Die erste Version der Regeln für XP wurde 1999 von Don Wells veröffentlicht^[13] auf der XP-Website. 29 Regeln sind in den Kategorien Planen, Verwalten, Entwerfen, Codieren und Testen angegeben. Planen, Verwalten und Entwerfen werden ausdrücklich aufgerufen, um Behauptungen entgegenzuwirken, dass XP diese Aktivitäten nicht unterstützt.

Eine andere Version der XP-Regeln wurde von Ken Auer vorgeschlagen^[14] in XP / Agile Universe 2003. Er war der Ansicht, dass XP durch seine Regeln definiert wurde, nicht durch seine Praktiken (die mehr Variationen und Mehrdeutigkeiten unterliegen). Er definierte zwei Kategorien: “Regeln des Engagements”, die die Umgebung bestimmen, in der Softwareentwicklung effektiv stattfinden kann, und “Spielregeln”, die die minutengenauen Aktivitäten und Regeln im Rahmen der Regeln des Engagements definieren.

Hier sind einige der Regeln (unvollständig):

Codierung

Testen

• Alle Codes müssen Unit-Tests haben
• Der gesamte Code muss alle Komponententests bestehen, bevor er freigegeben werden kann.
• Wenn ein Fehler gefunden wird, werden Tests erstellt, bevor der Fehler behoben wird (ein Fehler ist kein logischer Fehler; es ist ein Test, der nicht geschrieben wurde).
• Abnahmetests werden häufig durchgeführt und die Ergebnisse veröffentlicht

Prinzipien[edit]

Die Prinzipien, die die Grundlage von XP bilden, basieren auf den gerade beschriebenen Werten und sollen Entscheidungen in einem Systementwicklungsprojekt fördern. Die Grundsätze sollen konkreter als die Werte sein und in einer praktischen Situation leichter in Leitlinien umgesetzt werden können.

Feedback[edit]

Extreme Programmierung sieht Feedback als am nützlichsten an, wenn es häufig und schnell durchgeführt wird. Es wird betont, dass eine minimale Verzögerung zwischen einer Aktion und ihrem Feedback entscheidend für das Lernen und Vornehmen von Änderungen ist. Im Gegensatz zu herkömmlichen Systementwicklungsmethoden erfolgt der Kontakt mit dem Kunden häufiger. Der Kunde hat einen klaren Einblick in das System, das entwickelt wird, und kann Feedback geben und die Entwicklung nach Bedarf steuern. Bei häufigem Feedback des Kunden wird eine vom Entwickler getroffene fehlerhafte Entwurfsentscheidung schnell bemerkt und korrigiert, bevor der Entwickler viel Zeit mit der Implementierung verbringt.

Unit-Tests tragen zum Prinzip der schnellen Rückmeldung bei. Wenn Sie beim Schreiben von Code den Komponententest ausführen, erhalten Sie eine direkte Rückmeldung darüber, wie das System auf die vorgenommenen Änderungen reagiert. Dazu gehört, dass nicht nur die Komponententests ausgeführt werden, die den Entwicklercode testen, sondern auch alle Komponententests für die gesamte Software mithilfe eines automatisierten Prozesses ausgeführt werden, der mit einem einzigen Befehl initiiert werden kann. Auf diese Weise zeigt die automatisierte All-Unit-Test-Suite den Fehler sofort an, wenn die Änderungen des Entwicklers einen Fehler in einem anderen Teil des Systems verursachen, von dem der Entwickler wenig oder gar nichts weiß, und macht den Entwickler auf die Inkompatibilität ihrer Änderung mit aufmerksam andere Teile des Systems und die Notwendigkeit, ihre Änderungen zu entfernen oder zu ändern. Unter den traditionellen Entwicklungspraktiken bedeutete das Fehlen einer automatisierten, umfassenden Unit-Test-Suite, dass eine solche Codeänderung, die vom Entwickler als harmlos angenommen wurde, an Ort und Stelle belassen worden wäre und nur während der Integrationstests – oder schlimmer noch – nur in der Produktion aufgetreten wäre. Es war eine gewaltige Aufgabe, festzustellen, welche Codeänderung das Problem verursachte, und zwar unter allen Änderungen, die alle Entwickler in den Wochen oder sogar Monaten vor dem Integrationstest vorgenommen hatten.

Einfachheit vorausgesetzt[edit]

Hier geht es darum, jedes Problem so zu behandeln, als wäre seine Lösung “extrem einfach”. Traditionelle Systementwicklungsmethoden sagen, dass sie für die Zukunft planen und für die Wiederverwendbarkeit codieren sollen. Extreme Programmierung lehnt diese Ideen ab.

Die Befürworter extremer Programmierung sagen, dass es nicht funktioniert, große Änderungen auf einmal vorzunehmen. Bei extremer Programmierung werden inkrementelle Änderungen vorgenommen: Beispielsweise kann ein System alle drei Wochen kleine Releases haben. Wenn viele kleine Schritte unternommen werden, hat der Kunde mehr Kontrolle über den Entwicklungsprozess und das System, das entwickelt wird.

Veränderung annehmen[edit]

Das Prinzip, Veränderungen anzunehmen, besteht darin, nicht gegen Veränderungen zu arbeiten, sondern sie anzunehmen. Wenn sich beispielsweise bei einem der iterativen Meetings herausstellt, dass sich die Anforderungen des Kunden dramatisch geändert haben, müssen Programmierer dies berücksichtigen und die neuen Anforderungen für die nächste Iteration planen.

Praktiken Methoden Ausübungen[edit]

Es wurde beschrieben, dass extreme Programmierung 12 Übungen umfasst, die in vier Bereiche unterteilt sind:

Feinskaliges Feedback[edit]

Kontinuierlicher Prozess[edit]

Gemeinsames Verständnis[edit]

Programmierer Wohlfahrt[edit]

Kontroverse Aspekte[edit]

Die Praktiken in XP wurden heftig diskutiert.^[5] Befürworter extremer Programmierung behaupten, dass sie den Kunden vor Ort haben^[5] Informelle Änderungen anfordern, der Prozess wird flexibel und spart die Kosten für formalen Overhead. Kritiker von XP behaupten, dies könne zu kostspieligen Nacharbeiten führen und den Projektumfang über das zuvor vereinbarte oder finanzierte Maß hinausschleichen.^{[citation needed]}

Change-Control-Boards sind ein Zeichen dafür, dass es potenzielle Konflikte bei den Projektzielen und Einschränkungen zwischen mehreren Benutzern gibt. Die beschleunigten Methoden von XP hängen in gewisser Weise davon ab, dass Programmierer einen einheitlichen Client-Standpunkt einnehmen können, damit sich der Programmierer auf die Codierung konzentrieren kann, anstatt Kompromissziele und -beschränkungen zu dokumentieren.^[15] Dies gilt auch, wenn mehrere Programmierorganisationen beteiligt sind, insbesondere Organisationen, die um Projektanteile konkurrieren.^{[citation needed]}

Andere potenziell kontroverse Aspekte extremer Programmierung sind:

• Anforderungen werden eher als automatisierte Abnahmetests als als Spezifikationsdokumente ausgedrückt.
• Anforderungen werden inkrementell definiert, anstatt zu versuchen, sie alle im Voraus zu erhalten.
• Softwareentwickler müssen normalerweise paarweise arbeiten.
• Es gibt kein großes Design vorne. Der größte Teil der Entwurfsaktivität findet im laufenden Betrieb und schrittweise statt, beginnend mit “das Einfachste, was möglicherweise funktionieren könnte” und Komplexität nur dann hinzuzufügen, wenn dies durch fehlgeschlagene Tests erforderlich ist. Kritiker vergleichen dies mit dem “Debuggen eines Systems in Erscheinung” und befürchten, dass dies zu mehr Umgestaltungsaufwand führt als nur zu einer Neugestaltung, wenn sich die Anforderungen ändern.
• Ein Kundenvertreter ist dem Projekt beigefügt. Diese Rolle kann zu einer zentralen Fehlerquelle für das Projekt werden, und einige Leute haben festgestellt, dass sie eine Quelle von Stress darstellt. Es besteht auch die Gefahr eines Mikromanagements durch einen nichttechnischen Vertreter, der versucht, die Verwendung technischer Softwarefunktionen und -architekturen zu diktieren.

Kritiker haben mehrere mögliche Nachteile festgestellt,^[5] Dazu gehören Probleme mit instabilen Anforderungen, keine dokumentierten Kompromisse bei Benutzerkonflikten und das Fehlen einer allgemeinen Entwurfsspezifikation oder eines Dokuments.

Skalierbarkeit[edit]

ThoughtWorks hat bei verteilten XP-Projekten mit bis zu 60 Mitarbeitern einen angemessenen Erfolg erzielt.^{[citation needed]}

Im Jahr 2004 industrielle Extremprogrammierung (IXP)^[16] wurde als Weiterentwicklung von XP eingeführt. Es soll die Möglichkeit bieten, in großen und verteilten Teams zu arbeiten. Es hat jetzt 23 Praktiken und flexible Werte.

Salvatorische Klausel und Antworten[edit]

Im Jahr 2003 veröffentlichten Matt Stephens und Doug Rosenberg Extreme Programmierung überarbeitet: Der Fall gegen XP, der den Wert des XP-Prozesses in Frage stellte und Möglichkeiten vorschlug, ihn zu verbessern.^[6] Dies löste eine lange Debatte in Artikeln, Internet-Newsgroups und Website-Chat-Bereichen aus. Das Hauptargument des Buches ist, dass die Praktiken von XP voneinander abhängig sind, dass jedoch nur wenige praktische Organisationen bereit / in der Lage sind, alle Praktiken zu übernehmen. Daher schlägt der gesamte Prozess fehl. Das Buch macht auch andere Kritikpunkte und zeigt in negativer Weise eine Ähnlichkeit des XP-Modells “kollektives Eigentum” mit dem Sozialismus.

Bestimmte Aspekte von XP haben sich seit der Veröffentlichung von geändert Extreme Programmierung überarbeitet;; Insbesondere nimmt XP jetzt Änderungen an den Praktiken vor, solange die erforderlichen Ziele noch erreicht werden. XP verwendet auch zunehmend allgemeine Begriffe für Prozesse. Einige argumentieren, dass diese Änderungen frühere Kritikpunkte ungültig machen; andere behaupten, dass dies den Prozess einfach verwässert.

Andere Autoren haben versucht, XP mit den älteren Methoden in Einklang zu bringen, um eine einheitliche Methodik zu bilden. Einige dieser XP wollten ersetzt werden, beispielsweise die Wasserfallmethode. Beispiel: Projektlebenszyklen: Wasserfall, Rapid Application Development (RAD) und all das. JPMorgan Chase & Co. hat versucht, XP mit den Computerprogrammiermethoden der CMMI (Capability Maturity Model Integration) und Six Sigma zu kombinieren. Sie fanden heraus, dass sich die drei Systeme gut verstärkten, was zu einer besseren Entwicklung führte und sich nicht widersprachen.^[17]

Kritik[edit]

Die anfängliche Begeisterung für extreme Programme und kontroverse Grundsätze wie Paarprogrammierung und kontinuierliches Design haben besondere Kritik hervorgerufen, beispielsweise die von McBreen^[18] und Boehm und Turner,^[19] Matt Stephens und Doug Rosenberg.^[20] Viele der Kritikpunkte werden jedoch von agilen Praktikern als Missverständnisse der agilen Entwicklung angesehen.^[21]

Insbesondere die extreme Programmierung wurde von Matt Stephens und Doug Rosenberg überprüft und kritisiert Extreme Programmierung überarbeitet.^[6]

Kritikpunkte sind:

• Eine Methodik ist nur so effektiv wie die beteiligten Personen, Agile löst dies nicht^{[citation needed]}
• Wird häufig als Mittel verwendet, um Kunden Geld zu entlüften, da kein lieferbares Produkt definiert wurde^{[citation needed]}
• Mangel an Struktur und notwendiger Dokumentation^{[citation needed]}
• funktioniert nur mit hochrangigen Entwicklern^{[citation needed]}
• beinhaltet unzureichendes Software-Design^{[citation needed]}
• erfordert Besprechungen in regelmäßigen Abständen mit enormen Kosten für die Kunden^{[citation needed]}
• erfordert zu viel kulturellen Wandel, um angenommen zu werden^{[citation needed]}
• kann zu schwierigeren Vertragsverhandlungen führen^{[citation needed]}
• kann sehr ineffizient sein; Wenn sich die Anforderungen für einen Codebereich durch verschiedene Iterationen ändern, muss dieselbe Programmierung möglicherweise mehrmals durchgeführt werden. Wenn ein Plan befolgt werden soll, wird erwartet, dass ein einzelner Codebereich einmal geschrieben wird.^{[citation needed]}
• Es ist unmöglich, realistische Schätzungen des Arbeitsaufwands zu erstellen, der für die Erstellung eines Angebots erforderlich ist, da zu Beginn des Projekts niemand den gesamten Umfang / die Anforderungen kennt^{[citation needed]}
• kann das Risiko eines Scope Creep aufgrund des Fehlens einer detaillierten Anforderungsdokumentation erhöhen^{[citation needed]}
• Agile ist funktionsgesteuert. Nicht funktionale Qualitätsattribute sind schwer als User Stories darzustellen.^{[citation needed]}

Siehe auch[edit]

Verweise[edit]

Weiterführende Literatur[edit]

• Ken Auer und Roy Miller. Extreme Programmierung angewendet: Spielen um zu gewinnen, Addison-Wesley.
• Ken Auer; Ron Jeffries; Jeff Canna; Glen B. Alleman; Lisa Crispin; Janet Gregory (2002). “Sind Tester eXtinct? Wie können Tester zu XP-Teams beitragen?” Extreme Programmierung und agile Methoden – XP / Agile Universe 2002. Vorlesungsunterlagen in Informatik. 2418. Springer-Verlag. p. 287. doi:10.1007 / 3-540-45672-4_50. ISBN 978-3-540-44024-6.
• Kent Beck: Extreme Programmierung erklärt: Umfassen Sie Veränderungen, Addison-Wesley.
• Kent Beck und Martin Fowler: Extreme Programmierung planen, Addison-Wesley.
• Kent Beck und Cynthia Andres. Extreme Programmierung erklärt: Umarmung Veränderung, zweite Ausgabe, Addison-Wesley.
• Alistair Cockburn: Agile Software Entwicklung, Addison-Wesley.
• Martin Fowler: Refactoring: Verbesserung des Designs vorhandenen Codes, Addison-Wesley.
• Harvey Herela (2005). Fallstudie: Das Chrysler Comprehensive Compensation System. Galen Lab, UC Irvine.
• Jim Highsmith. Agile Softwareentwicklungs-Ökosysteme, Addison-Wesley.
• Ron Jeffries, Ann Anderson und Chet Hendrickson (2000), Extreme Programmierung installiert, Addison-Wesley.
• Craig Larman & V. Basili (2003). “Iterative und inkrementelle Entwicklung: Eine kurze Geschichte”, Computer (IEEE Computer Society) 36 (6): 47–56.
• Matt Stephens und Doug Rosenberg (2003). Extreme Programmierung überarbeitet: Der Fall gegen XP, Apress.
• Waldner, JB. (2008). “Nanocomputer und Schwarmintelligenz”. In: ISTE, 225–256.

Externe Links[edit]