Äußerste Programmierung (XP) ist eine Softwareentwicklungsmethodik, die beabsichtigt ist, um Softwarequalität und Ansprechbarkeit zu sich ändernden Kundenanforderungen zu verbessern. Als ein Typ der flinken Softwareentwicklung,

es verteidigt häufige "Ausgaben" in kurzen Entwicklungszyklen (timeboxing), der beabsichtigt ist, um Produktivität zu verbessern und Kontrollpunkte einzuführen, wo neue Kundenanforderungen angenommen werden können.

Andere Elemente der äußersten Programmierung schließen ein: In Paaren oder dem Tun umfassender Coderezension, der Einheitsprüfung des ganzen Codes programmierend, Programmierung von Eigenschaften vermeidend, bis sie wirklich, eine flache Verwaltungsstruktur, Einfachheit und Klarheit im Code erforderlich sind, Änderungen in den Voraussetzungen des Kunden erwartend, weil geht Zeit, und das Problem, wird und häufige Kommunikation mit dem Kunden und unter Programmierern besser verstanden. Die Methodik nimmt seinen Namen von der Idee, dass die vorteilhaften Elemente von traditionellen Softwaretechnikmethoden in "äußerste" Niveaus auf der Theorie gebracht werden, dass, wenn etwas gut ist, mehr besser ist.

Kritiker haben mehrere potenzielle Nachteile, einschließlich Probleme mit nicht stabilen Voraussetzungen, keinen dokumentierten Kompromissen von Benutzerkonflikten und einem Mangel an einer gesamten Designspezifizierung oder Dokument bemerkt.

Geschichte

Äußerste Programmierung wurde von Kent Beck während seiner Arbeit am Chrysler Umfassenden Entschädigungssystem (C3) Lohnliste-Projekt geschaffen. Beck ist der C3-Projektführer im März 1996 geworden und hat begonnen, die Entwicklungsmethode zu raffinieren, die im Projekt verwendet ist, und hat ein Buch auf der Methode geschrieben (im Oktober 1999, Äußerste Erklärte Programmierung wurde veröffentlicht).

Chrysler hat das C3-Projekt im Februar 2000 annulliert, nachdem die Gesellschaft durch Daimler-Benz erworben wurde.

Obwohl äußerste Programmierung von sich relativ neu ist, sind viele seiner Methoden ringsherum für einige Zeit gewesen; die Methodik bringt schließlich "beste Methoden" in äußerste Niveaus. Zum Beispiel wurde die "Praxis des Tests die erste Entwicklung, planend und Tests vor jeder Mikrozunahme schreibend", schon im Projektquecksilber der NASA am Anfang der 1960er Jahre verwendet. Um die Gesamtentwicklungsdauer zu verkürzen, sind einige formelle Testdokumente (solcher bezüglich der Annahmeprüfung) in der Parallele entwickelt worden (oder kurz vorher) die Software ist zur Prüfung bereit. Eine NASA, die unabhängige Testgruppe den Testverfahren schreiben kann, die auf Formvorschriften und logischen Grenzen vor der Software gestützt sind, ist geschrieben und mit der Hardware integriert worden. In XP wird dieses Konzept ins äußerste Niveau durch das Schreiben von automatisierten Tests gebracht (vielleicht innerhalb von Softwaremodulen), die die Operation sogar kleiner Abteilungen des Softwarecodierens, aber nicht nur der Prüfung der größeren Eigenschaften gültig machen. Einige andere XP Methoden, wie Wiederfactoring, Modularität, von unten nach oben Design und zusätzliches Design wurden von Leo Brodie in seinem 1984 veröffentlichten Buch beschrieben.

Ursprünge

Softwareentwicklung wurde in den 1990er Jahren durch zwei Haupteinflüsse gestaltet: Innerlich hat objektorientierte Programmierung Verfahrensprogrammierung als das Programmierparadigma ersetzt, das von einigen in der Industrie bevorzugt ist; äußerlich steigt der Anstieg des Internets und des Punkt-Com betonte Geschwindigkeit zum Markt und Firmenwachstum als Wettbewerbsgeschäftsfaktoren. Sich schnell ändernde Voraussetzungen haben kürzere Produktlebenszyklen gefordert, und waren häufig mit traditionellen Methoden der Softwareentwicklung unvereinbar.

Das Chrysler Umfassende Entschädigungssystem wurde angefangen, um die beste Weise zu bestimmen, Gegenstand-Technologien, mit den Lohnliste-Systemen an Chrysler als der Gegenstand der Forschung, mit dem Plausch als die Sprache und GemStone als die Datenzugriffsschicht zu verwenden. Sie haben in Kent Beck, einem prominenten Plausch-Praktiker gebracht, um Leistungsoptimierung auf dem System zu tun, aber seine Rolle hat sich ausgebreitet, weil er mehrere Probleme bemerkt hat, die sie mit ihrem Entwicklungsprozess hatten. Er hat diese Gelegenheit ergriffen, einige Änderungen in ihren Methoden vorzuschlagen und durchzuführen, die auf seiner Arbeit mit seinem häufigen Mitarbeiter, Ward Cunningham gestützt sind. Beck beschreibt die frühe Vorstellung der Methoden:

Beck hat Ron Jeffries zum Projekt eingeladen zu helfen, diese Methoden zu entwickeln und zu raffinieren. Jeffries hat danach als ein Trainer gehandelt, um die Methoden als Gewohnheiten in der C3 Mannschaft einzuträufeln.

Die Information über die Grundsätze und Methoden hinter XP wurde zur breiteren Welt durch Diskussionen über ursprünglichen Wiki, WikiWikiWeb von Cunningham verbreitet. Verschiedene Mitwirkende haben besprochen und haben sich auf die Ideen ausgebreitet, und einige Nebenprodukt-Methodiken haben resultiert (sieh flinke Softwareentwicklung). Außerdem sind XP Konzepte, seit mehreren Jahren, mit einer Hypertext-Karte auf der XP Website an "http://www.extremeprogramming.org" um 1999 erklärt worden.

Beck hat eine Reihe von Büchern auf XP editiert, mit seiner eigenen Äußersten Programmierung Erklärt (1999, internationale Standardbuchnummer 0-201-61641-6) beginnend, seine Ideen zu einem viel größeren, noch sehr empfänglich, Publikum ausbreitend. Autoren in der Reihe sind verschiedene Aspekte durchgegangen, XP und seinen Methoden beiwohnend. Die Reihe hat ein Buch eingeschlossen, das gegenüber den Methoden kritisch war.

Aktueller Staat

XP hat ein echtes Summen gegen Ende der 1990er Jahre und Anfang der 2000er Jahre geschaffen, Adoption in mehreren von seinen Ursprüngen radikal verschiedenen Umgebungen sehend.

Die hohe Disziplin, die durch die ursprünglichen Methoden häufig erforderlich ist, ist durch den Wegrand gegangen, einige dieser Methoden, wie diejenigen verursachend, die gedacht sind, zu starr, um missbilligt oder reduziert, oder sogar unfertig auf individuellen Seiten verlassen zu werden. Zum Beispiel konnte die Praxis von Integrationstests des Endes-tägig, für ein besonderes Projekt, zu einer Liste des Endes-wöchig geändert, oder einfach auf gegenseitig abgestimmte Daten reduziert werden. Solch eine mehr entspannte Liste konnte vermeiden, dass Menschengefühl hingeeilt ist, um künstliche Stummel zu erzeugen, um gerade das Ende-tägig zu passieren, prüfend. Eine weniger starre Liste erlaubt statt dessen für einige komplizierte im Laufe mehrerer tägiger Periode mehr völlig zu entwickelnde Eigenschaften. Jedoch kann ein Niveau der periodischen Integrationsprüfung Gruppen von Leuten entdecken, die im nichtvereinbaren, Tangente-Anstrengungen arbeiten, bevor zu viel Arbeit in auseinander gehenden, falschen Richtungen investiert wird.

Inzwischen haben andere flinke Entwicklungsmethoden nicht stillgestanden, und XP entwickelt sich noch, mehr Lehren von Erfahrungen im Feld assimilierend, um andere Methoden zu verwenden. In der zweiten Ausgabe der Äußersten Erklärten Programmierung hat Beck mehr Werte und Methoden hinzugefügt und hat zwischen dem primären und den Folgeerscheinungsmethoden differenziert.

Konzept

Absichten

Äußerste Erklärte Programmierung beschreibt Äußerste Programmierung als eine Softwareentwicklungsdisziplin, die Leute organisiert, um höhere Qualitätssoftware produktiver zu erzeugen.

XP versucht, die Kosten von Änderungen in Voraussetzungen zu reduzieren, indem er vielfache kurze Entwicklungszyklen, aber nicht einen langen gehabt wird.

In dieser Doktrin sind Änderungen ein natürlicher, unvermeidlicher und wünschenswerter Aspekt von Softwareentwicklungsprojekten und sollten geplant werden für anstatt zu versuchen, einen stabilen Satz von Voraussetzungen zu definieren.

Äußerste Programmierung führt auch mehrere grundlegende Werte, Grundsätze und Methoden oben auf dem flinken Programmierfachwerk ein.

Tätigkeiten

XP beschreibt vier grundlegende Tätigkeiten, die innerhalb des Softwareentwicklungsprozesses durchgeführt werden: das Codieren, die Prüfung, das Hören und das Entwerfen. Jede jener Tätigkeiten wird unten beschrieben.

Das Codieren

Die Verfechter von XP behaupten, dass das einzige aufrichtig wichtige Produkt des Systementwicklungsprozesses Code - Softwareinstruktionen ist, die ein Computer interpretieren kann. Ohne Code gibt es kein Arbeitsprodukt.

Das Codieren kann auch verwendet werden, um die passendste Lösung auszurechnen. Das Codieren kann auch helfen, Gedanken über die Programmierung von Problemen mitzuteilen. Ein Programmierer, der sich mit einem komplizierten Programmierproblem und Entdeckung davon hart befasst, um die Lösung von Mitprogrammierern zu erklären, könnte es codieren und den Code verwenden, um zu demonstrieren, was er oder sie vorhat. Codieren Sie, sagen Sie die Befürworter dieser Position, ist immer klar und kurz und kann auf mehr als eine Weise nicht interpretiert werden. Andere Programmierer können Feed-Back auf diesem Code geben, indem sie auch ihre Gedanken codieren.

Prüfung

Die Annäherung der äußersten Programmierung besteht darin, dass, wenn ein bisschen Prüfung einige Fehler beseitigen kann, viel Prüfung noch viele Fehler beseitigen kann.

• Einheitstests bestimmen, ob eine gegebene Eigenschaft, wie beabsichtigt, arbeitet. Ein Programmierer schreibt so viele automatisierte Tests, wie sie denken können, der den Code "brechen" könnte; wenn alle Tests erfolgreich laufen, dann ist das Codieren abgeschlossen. Jedes Stück des Codes, der geschrieben wird, wird vor dem Weitergehen zur folgenden Eigenschaft geprüft.
• Abnahmeprüfungen prüfen nach, dass die Voraussetzungen, wie verstanden, durch die Programmierer die wirklichen Voraussetzungen des Kunden befriedigen. Diese kommen in der Erforschungsphase der Ausgabe-Planung vor.

Ein "testathon" ist ein Ereignis, wenn sich Programmierer treffen, um das zusammenarbeitende Testschreiben, eine Art Geistesstörung hinsichtlich der Softwareprüfung zu tun.

Das Hören

Programmierer müssen zuhören, was die Kunden das System brauchen, um zu tun, was "Geschäftslogik" erforderlich ist. Sie müssen diese Bedürfnisse ganz gut verstehen, um die Kundenreaktionen über die technischen Aspekte dessen zu geben, wie das Problem behoben werden könnte oder nicht gelöst werden kann. Die Kommunikation zwischen dem Kunden und Programmierer wird weiter im Planungsspiel gerichtet.

Das Entwerfen

Aus dem Gesichtswinkel von der Einfachheit natürlich konnte man sagen, dass Systementwicklung mehr nicht braucht als das Codieren, die Prüfung und das Hören. Wenn jene Tätigkeiten eine gute Leistung gebracht werden, sollte das Ergebnis immer ein System sein, das arbeitet. In der Praxis wird das nicht arbeiten. Man kann ein langer Weg kommen ohne zu entwickeln, aber zu einem festgelegten Zeitpunkt wird man stecken bleiben. Das System wird zu kompliziert, und die Abhängigkeiten innerhalb des Systems hören auf, klar zu sein. Man kann das vermeiden, indem man eine Designstruktur schafft, die die Logik im System organisiert. Gutes Design wird viele Abhängigkeiten innerhalb eines Systems vermeiden; das bedeutet, dass das Ändern eines Teils des Systems andere Teile des Systems nicht betreffen wird.

Werte

Äußerste Programmierung hat am Anfang vier Werte 1999 anerkannt. Ein neuer Wert wurde in der zweiten Ausgabe der Äußersten Erklärten Programmierung hinzugefügt. Die fünf Werte sind:

Kommunikation

Gebäude von Softwaresystemen verlangt kommunizierende Systemanforderungen den Entwicklern des Systems. In formellen Softwareentwicklungsmethodiken wird diese Aufgabe durch die Dokumentation vollbracht. Äußerste Programmiertechniken können als Methoden angesehen werden, um Institutionskenntnisse unter Mitgliedern einer Entwicklungsmannschaft schnell zu bauen und zu verbreiten. Die Absicht ist, allen Entwicklern eine geteilte Ansicht vom System zu geben, das die von den Benutzern des Systems gehabte Ansicht vergleicht. Zu diesem Zweck bevorzugt äußerste Programmierung einfache Designs, allgemeine Metaphern, Kollaboration von Benutzern und Programmierern, häufiger wörtlicher Kommunikation und Feed-Back.

Einfachheit

Äußerste Programmierung ermuntert dazu, mit der einfachsten Lösung anzufangen. Extrafunktionalität kann dann später hinzugefügt werden. Der Unterschied zwischen dieser Annäherung und herkömmlicheren Systementwicklungsmethoden ist der Fokus auf dem Entwerfen und Codieren für die Bedürfnisse nach heute statt derjenigen Morgen, nächste Woche, oder im nächsten Monat. Das wird manchmal summiert, wie "Sie nicht ist, wird es" (YAGNI) Annäherung brauchen. Befürworter von XP erkennen den Nachteil an, dass das manchmal mehr Anstrengung Morgen zur Folge haben kann, um das System zu ändern; ihr Anspruch besteht darin, dass das mehr als für durch den Vorteil der nicht Investierung in mögliche zukünftige Voraussetzungen ersetzt wird, die sich ändern könnten, bevor sie wichtig werden. Das Codieren und das Entwerfen für unsichere zukünftige Voraussetzungen beziehen die Gefahr ein, Mittel für etwas auszugeben, was nicht erforderlich sein könnte. Verbunden mit dem "Nachrichten"-Wert sollte die Einfachheit im Design und Codieren die Qualität der Kommunikation verbessern. Ein einfaches Design mit dem sehr einfachen Code konnte von den meisten Programmierern in der Mannschaft leicht verstanden werden.

Feed-Back

Innerhalb der äußersten Programmierung bezieht sich Feed-Back auf verschiedene Dimensionen der Systementwicklung:

• Feed-Back vom System: Indem sie Einheitstests schreiben, oder periodische Integrationstests durchführen, haben die Programmierer direktes Feed-Back vom Staat des Systems nach dem Einführen von Änderungen.
• Feed-Back vom Kunden: Die Funktionsprüfungen (auch bekannt als Abnahmeprüfungen) werden vom Kunden und den Prüfern geschrieben. Sie werden konkretes Feed-Back über den aktuellen Staat ihres Systems bekommen. Diese Rezension wird einmal in allen zwei oder drei Wochen geplant, so kann der Kunde die Entwicklung leicht steuern.
• Feed-Back von der Mannschaft: Wenn Kunden neue Voraussetzungen im Planungsspiel präsentieren, gibt die Mannschaft direkt eine Bewertung der Zeit, dass es ins Werkzeug bringen wird.

Feed-Back ist nah mit der Kommunikation und Einfachheit verbunden. Fehler im System werden durch das Schreiben eines Einheitstests leicht mitgeteilt, der beweist, dass ein bestimmtes Stück des Codes brechen wird. Das direkte Feed-Back vom System sagt Programmierern, diesen Teil wiederzucodieren. Ein Kunde ist im Stande, das System regelmäßig gemäß den funktionellen Voraussetzungen zu prüfen, die als Benutzergeschichten bekannt sind. Kent Beck zu zitieren, "Ist Optimismus eine berufliche Gefahr der Programmierung. Feed-Back ist die Behandlung."

Mut

Mehrere Methoden nehmen Mut auf. Man ist das Gebot zu immer dem Design und Code für heute und nicht für Morgen. Das ist eine Anstrengung zu vermeiden, sich ins Design zu verlieren und viel Anstrengung zu verlangen, irgend etwas anderes durchzuführen. Mut ermöglicht Entwicklern, sich bequem mit dem Wiederfactoring ihr Code, wenn notwendig, zu fühlen. Das bedeutet, das vorhandene System nachzuprüfen und es zu modifizieren, so dass zukünftige Änderungen leichter durchgeführt werden können. Ein anderes Beispiel des Mutes weiß, wenn man Code wegwirft: Mut, Quellcode zu entfernen, der veraltet ist, egal wie viel Anstrengung verwendet wurde, um diesen Quellcode zu schaffen. Außerdem bedeutet Mut Fortsetzung: Ein Programmierer könnte auf einem komplizierten Problem seit einem kompletten Tag durchstochen werden, dann das Problem schnell am nächsten Tag beheben, wenn nur sie beharrlich sind.

Rücksicht

Der Rücksicht-Wert schließt Rücksicht für andere sowie Selbstachtung ein. Programmierer sollten Änderungen nie begehen, die Kompilation brechen, die vorhandene Einheitstests scheitern lassen, oder die sonst die Arbeit ihrer Gleichen verzögern. Mitglieder respektieren ihre eigene Arbeit, indem sie immer um die hohe Qualität kämpfen und für das beste Design für die Lösung in der Nähe durch das Wiederfactoring suchen.

Das Übernehmen der vier früheren Werte führt, um gewonnen von anderen in der Mannschaft zu respektieren. Niemand auf der Mannschaft sollte sich nicht gebührend gewürdigt oder ignoriert fühlen. Das sichert ein hohes Niveau der Motivation und fördert Loyalität zur Mannschaft und zur Absicht des Projektes. Dieser Wert ist auf die anderen Werte sehr abhängig, und wird sehr an Leuten in einer Mannschaft orientiert.

Regeln

Die erste Version von Regeln für XP wurde 1999 von Don Wells an der XP Website veröffentlicht. 29 Regeln werden in den Kategorien von Planung, Handhaben, Entwerfen, Codieren und Prüfung gegeben. Die Planung, das Handhaben und das Entwerfen werden ausführlich herausgerufen, um Ansprüche zu entgegnen, dass XP jene Tätigkeiten nicht unterstützt.

Eine andere Version von XP-Regeln wurde von Ken Auer im XP/Agile Weltall 2003 vorgeschlagen. Er hat gefunden, dass XP durch seine Regeln, nicht seine Methoden definiert wurde (die mehr Schwankung und Zweideutigkeit unterworfen sind). Er hat zwei Kategorien definiert: "Regeln der Verpflichtung", die die Umgebung diktieren, in der Softwareentwicklung effektiv, und "Regeln des Spieles" stattfinden kann, die die kleinen-durch-minutig Tätigkeiten und Regeln innerhalb des Fachwerks der Regeln der Verpflichtung definieren.

Grundsätze

Die Grundsätze, die die Basis von XP bilden, basieren auf den Werten gerade beschrieben und sind beabsichtigt, um Entscheidungen in einem Systementwicklungsprojekt zu fördern. Die Grundsätze sind beabsichtigt, um konkreter zu sein, als die Werte und leichter zur Leitung in einer praktischen Situation übersetzt.

Feed-Back

Äußerste Programmierung sieht Feed-Back als am nützlichsten, wenn es schnell und Schnellzüge getan wird, dass die Zeit zwischen einer Handlung und seinem Feed-Back zum Lernen und Vornehmen von Änderungen kritisch ist. Verschieden von traditionellen Systementwicklungsmethoden kommt der Kontakt mit dem Kunden in häufigeren Wiederholungen vor. Der Kunde hat klare Scharfsinnigkeit ins System, das entwickelt wird. Er oder sie kann Feed-Back geben und die Entwicklung, wie erforderlich, steuern.

Einheitstests tragen auch zum schnellen Feed-Back-Grundsatz bei. Wenn er Code schreibt, stellt der Einheitstest direktes Feed-Back betreffs zur Verfügung, wie das System auf die Änderungen reagiert, die man vorgenommen hat. Wenn, zum Beispiel, die Änderungen einen Teil des Systems betreffen, das nicht im Rahmen des Programmierers ist, der sie gemacht hat, wird dieser Programmierer den Fehler nicht bemerken. Es gibt eine große Chance, dass dieser Programmfehler erscheinen wird, wenn das System serienmäßig hergestellt wird.

Das Annehmen der Einfachheit

Das ist über das Behandeln jedes Problems, als ob seine Lösung "äußerst einfach" war. Traditionelle Systementwicklungsmethoden sagen, für die Zukunft zu planen und für die Wiederverwendbarkeit zu codieren. Äußerste Programmierung weist diese Ideen zurück.

Die Verfechter der äußersten Programmierung sagen, dass das Vornehmen großer Änderungen plötzlich nicht arbeitet. Äußerste Programmierung wendet zusätzliche Änderungen an: Zum Beispiel könnte ein System kleine Ausgaben alle drei Wochen haben. Wenn viele kleine Schritte gemacht werden, hat der Kunde mehr Kontrolle über den Entwicklungsprozess und das System, das entwickelt wird.

Das Umfassen der Änderung

Der Grundsatz der sich umarmenden Änderung ist über das nicht Arbeiten gegen Änderungen, aber Umfassen von ihnen. Zum Beispiel, wenn auf einer der wiederholenden Sitzungen es scheint, dass sich die Voraussetzungen des Kunden drastisch geändert haben, sollen Programmierer das umarmen und die neuen Voraussetzungen für die folgende Wiederholung planen.

Methoden

Äußerste Programmierung ist beschrieben worden als, 12 Methoden zu haben, die in vier Gebiete gruppiert sind:

Feines Skala-Feed-Back

• Paar, das programmiert
• Planung des Spiels
• Probegefahrene Entwicklung
• Ganze Mannschaft

Dauernder Prozess

• Dauernde Integration
• Wiederfactoring oder Designverbesserung
• Kleine Ausgaben

Das geteilte Verstehen

• Das Codieren von Standards
• Gesammeltes Codeeigentumsrecht
• Einfaches Design
• Systemmetapher

Programmierer-Sozialfürsorge

• Nachhaltiger Schritt

Das Codieren

• Der Kunde ist immer verfügbarer
• Codieren Sie den Einheitstest der erste
• Nur ein Paar integriert Code auf einmal
• Erlaubnis-Optimierung bis zu letztem
• Keine Überstunden

Prüfung

• Der ganze Code muss Einheitstests haben
• Der ganze Code muss alle Einheitstests bestehen, bevor er veröffentlicht werden kann.
• Wenn ein Programmfehler gefunden wird, dass Tests geschaffen werden, bevor der Programmfehler angeredet wird (ein Programmfehler ist nicht ein Fehler in der Logik, es ist ein Test, den Sie vergessen haben zu schreiben)
• Abnahmeprüfungen werden häufig geführt, und die Ergebnisse werden veröffentlicht

Umstrittene Aspekte

Die Methoden in XP sind schwer diskutiert worden. Befürworter der äußersten Programmierung behaupten, dass, indem es die Vor-Ort-Kundenbitte gehabt wird, sich informell ändert, wird der Prozess flexibel, und spart die Kosten von formellen oben. Kritiker von XP behaupten, dass das kostspielig führen kann, arbeiten nach und planen, dass Spielraum außer kriecht, was vorher abgestimmt oder gefördert wurde.

Änderungsschalttafeln sind ein Zeichen, dass es potenzielle Konflikte in Projektzielen und Einschränkungen zwischen vielfachen Benutzern gibt. Die beschleunigte Methodik von XP ist von Programmierern etwas abhängig, die im Stande sind, einen vereinigten Kundengesichtspunkt anzunehmen, so kann sich der Programmierer auf das Codieren aber nicht die Dokumentation von Kompromiss-Zielen und Einschränkungen konzentrieren. Das gilt auch, wenn vielfache Programmierorganisationen, besonders Organisationen beteiligt werden, die sich um Anteile von Projekten bewerben.

Andere potenziell umstrittene Aspekte der äußersten Programmierung schließen ein:

• Voraussetzungen werden als automatisierte Abnahmeprüfungen aber nicht Spezifizierungsdokumente ausgedrückt.
• Voraussetzungen werden zusätzlich definiert, anstatt zu versuchen, sie alle im Voraus zu bekommen.
• Softwareentwickler sind gewöhnlich erforderlich, in Paaren zu arbeiten.
• Es gibt kein Großes Design Vorderseite. Der grösste Teil der Designtätigkeit findet im Fluge und zusätzlich statt, mit "dem einfachsten Ding anfangend, das vielleicht" und das Hinzufügen der Kompliziertheit nur arbeiten konnte, wenn es durch den Mangel Tests erforderlich ist. Kritiker vergleichen das mit dem "Beseitigen bei einem System ins Äußere" und fürchten, dass das auf mehr Umgestaltungsanstrengung hinauslaufen wird als nur das neu Entwerfen, wenn sich Voraussetzungen ändern.
• Ein Kundenvertreter wird dem Projekt beigefügt. Diese Rolle kann ein einzelner Punkt des Misserfolgs für das Projekt werden, und einige Menschen haben gefunden, dass es eine Quelle der Betonung ist. Außerdem gibt es die Gefahr des Mikromanagements durch einen nicht technischen Vertreter, der versucht, den Gebrauch von technischen Softwareeigenschaften und Architektur zu diktieren.
• Abhängigkeit auf alle anderen Aspekte von XP: "XP ist einem Ring von Giftschlangen, Gänseblümchen-verkettet zusammen ähnlich. Alles, was man braucht, ist für einen von ihnen, um sich lose zu winden, und Sie haben eine sehr böse, Giftschlange, die Ihren Weg anführt."

Skalierbarkeit

Historisch arbeitet XP nur an Mannschaften von zwölf oder weniger Menschen. Eine Weise, diese Beschränkung zu überlisten, soll das Projekt in kleinere Stücke und die Mannschaft in kleinere Gruppen zerbrechen. Es ist gefordert worden, dass XP erfolgreich auf Mannschaften von mehr als hundert Entwicklern verwendet worden ist. ThoughtWorks hat angemessenen Erfolg auf verteilten XP-Projekten mit bis zu sechzig Menschen gefordert.

2004 wurde Äußerste Industrieprogrammierung (IXP) als eine Evolution von XP eingeführt. Es ist beabsichtigt, um die Arbeitsfähigkeit in großen und verteilten Mannschaften zu bringen. Es hat jetzt 23 Methoden und flexible Werte. Da es ein neues Mitglied der Familie ist, gibt es nicht genug Daten, um seine Brauchbarkeit zu beweisen, jedoch behauptet es, eine Antwort darauf zu sein, was es als die Schönheitsfehler von XP sieht.

Severability und Antworten

2003 haben Matt Stephens und Doug Rosenberg Äußerste Programmierung Refactored veröffentlicht: Der Fall Gegen XP, der den Wert des XP-Prozesses infrage gestellt hat und Wege angedeutet hat, auf die es verbessert werden konnte. Das hat eine lange Debatte in Artikeln, Internet newsgroups und Website-Chat-Gebiete ausgelöst. Das Kernargument des Buches ist, dass die Methoden von XP voneinander abhängig sind, aber dass wenige praktische Organisationen bereit/fähig sind, alle Methoden anzunehmen; deshalb scheitert der komplette Prozess. Das Buch macht auch andere Kritiken, und es zieht eine Gleichheit des "gesammelten Eigentumsrechts von XP" Modell zum Sozialismus auf eine negative Weise.

Bestimmte Aspekte von XP haben sich geändert seit dem Buch Äußerste Programmierung wurde Refactored (2003) veröffentlicht; insbesondere XP passt jetzt Modifizierungen an die Methoden an, so lange die erforderlichen Ziele noch entsprochen werden. XP verwendet auch zunehmend Oberbegriffe für Prozesse. Einige behaupten, dass diese Änderungen vorherige Kritiken ungültig machen; andere behaupten, dass das einfach den Prozess unten bewässert.

RDP Praxis ist eine Technik, um äußerste Programmierung zu schneidern. Diese Praxis wurde als eine lange Forschungsarbeit in einer Werkstatt am Anfang vorgeschlagen, die von Philippe Kruchten und Steve Adolph organisiert ist (Sieh APSO Werkstatt in ICSE 2008), und noch ist es die einzige vorgeschlagene und anwendbare Methode, um XP kundengerecht anzufertigen. Die wertvollen Konzepte hinter der RDP Praxis, hat in Kürze das Grundprinzip für die Anwendbarkeit davon in Industrien zur Verfügung gestellt. RDP Praxis versucht, XP durch das Verlassen auf die Technik von XP Regeln kundengerecht anzufertigen.

Andere Autoren haben versucht, XP mit den älteren Methoden beizulegen, um eine vereinigte Methodik zu bilden. Einige dieser XP haben sich bemüht, wie die Wasserfall-Methode zu ersetzen; Beispiel: Projektlebenszyklen: Wasserfall, Schnelle Anwendungsentwicklung und Alles Das. JPMorgan Chase & Co. hat versucht, XP mit den Computerprogrammiermethodiken der Fähigkeitsreife-Musterintegration (CMMI) und Sechs Sigma zu verbinden. Sie haben gefunden, dass die drei Systeme einander verstärkt haben so, zu besserer Entwicklung führend, und nicht gegenseitig widersprochen haben.

Kritik

Das anfängliche Summen der äußersten Programmierung und umstrittene Doktrinen, wie Paar, das programmiert und dauerndes Design, haben besondere Kritiken, wie diejenigen angezogen, aus McBreen und Boehm und Turner kommend. Wie man glaubt, sind viele der Kritiken, jedoch, von Flinken Praktikern Missverständnisse der flinken Entwicklung.

Insbesondere äußerste Programmierung wird nachgeprüft und durch die Äußerste Programmierung von Matt Stephens und Doug Rosenbergs Refactored kritisiert.

Kritiken schließen ein:

• Eine Methodik ist nur so wirksam, wie die Leute eingeschlossen haben, Flink löst diesen nicht
• Häufig verwendet als ein Mittel, Geld von Kunden durch den Mangel daran abzuzapfen, einen lieferbaren zu definieren
• Fehlen Sie von der Struktur und notwendigen Dokumentation
• Nur Arbeiten mit Entwicklern des älteren Niveaus
• Vereinigt ungenügendes Softwaredesign
• Verlangt Sitzungen häufig auf enormen Kosten Kunden
• Verlangt, dass zu viel kulturelle Änderung annimmt
• Kann zu schwierigeren vertraglichen Verhandlungen führen
• Kann sehr ineffizient sein — wenn die Voraussetzungen für ein Gebiet der Codeänderung durch verschiedene Wiederholungen, dieselbe Programmierung eventuell mehrere Male getan werden muss. Wohingegen, wenn einem Plan dort gefolgt werden sollte, wie man erwartet, ein einzelnes Gebiet des Codes einmal geschrieben wird.
• Unmöglich, realistische Schätzungen der Arbeitsanstrengung zu entwickeln, musste ein Zitat zur Verfügung stellen, weil am Anfang des Projektes keiner das komplette Spielraum/Voraussetzungen weiß
• Kann zunehmen die Gefahr des Spielraums kriechen wegen des Mangels an der ausführlichen Voraussetzungsdokumentation
• Flink ist gesteuerte Eigenschaft; nichtfunktionelle Qualitätsattribute sind hart, als Benutzergeschichten gelegt zu werden

Siehe auch

• Softwaretechnik

Fachmännische

• Softwarearbeit
• Flinke Softwareentwicklung
• Äußerstes Projektmanagement
• Äußerste Programmiermethoden

Paar, das programmiert

• Kaizen
• Liste von Softwareentwicklungsphilosophien
• Gedränge (Entwicklung)
• Dauerndes Veralten

Weiterführende Literatur

• Ken Auer und Roy Miller. Äußerste angewandte Programmierung: Spielend, um, Addison-Wesley zu gewinnen.
• Kent Beck: Äußerste erklärte Programmierung: Umarmungsänderung, Addison-Wesley.
• Kent Beck und Martin Fowler: Äußerste Programmierung, Addison-Wesley planend.
• Kent Beck und Cynthia Andres. Äußerste erklärte Programmierung: Umarmungsänderung, die zweite Ausgabe, Addison-Wesley.
• Alistair Cockburn: Flinke Softwareentwicklung, Addison-Wesley.
• Martin Fowler: Wiederfactoring: Das Design des vorhandenen Codes, Addisons-Wesleys verbessernd.
• Harvey Herela (2005). Fallstudie: Das Chrysler umfassende Entschädigungssystem. Laboratorium von Galen, U.C. Irvine.
• Jim Highsmith. Flinke Softwareentwicklungsökosysteme, Addison-Wesley.
• Ron Jeffries, Ann Anderson und Chet Hendrickson (2000), äußerste Programmierung installiert, Addison-Wesley.
• Mehdi Mirakhorli (2008). RDP Technik: Eine Praxis, um xp, Internationale Konferenz für die Softwaretechnik, Verhandlungen von 2008 internationale Werkstatt beim Prüfen flinker Methoden oder Schießerei an der flinken Hürde, Leipzig, Deutschland 2008, Seiten 23-32 kundengerecht anzufertigen.
• Craig Larman & V. Basili (2003). "Wiederholende und Zusätzliche Entwicklung: Eine Kurze Geschichte", Computer (IEEE Computergesellschaft) 36 (6): 47-56.
• Matt Stephens und Doug Rosenberg (2003). Äußerste Programmierung Refactored: Der Fall gegen XP, Apress.
• Waldner, JB. (2008). "Nanocomputers und Swarm Intelligence". In: ISTE, 225-256.

Außenverbindungen

• Eine sanfte Einführung
• Äußerste Industrieprogrammierung
• Zeitschrift XP
• Probleme und Lösungen der XP Durchführung
• Das Verwenden eines Flinken Softwareprozesses mit der Auslandsentwicklung - die Erfahrungen von ThoughtWorks mit dem Einführen von XP in großen verteilten Projekten