[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/wiki11\/2020\/12\/25\/extreme-programmierung-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/wiki11\/2020\/12\/25\/extreme-programmierung-wikipedia\/","headline":"Extreme Programmierung – Wikipedia","name":"Extreme Programmierung – Wikipedia","description":"before-content-x4 Softwareentwicklungsmethode Planungs- und R\u00fcckkopplungsschleifen bei extremer Programmierung Extremes Programmieren ((XP) ist eine Softwareentwicklungsmethode, die die Softwarequalit\u00e4t und die Reaktionsf\u00e4higkeit","datePublished":"2020-12-25","dateModified":"2020-12-25","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/wiki11\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/wiki11\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/8\/84\/Extreme_Programming.svg\/220px-Extreme_Programming.svg.png","url":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/8\/84\/Extreme_Programming.svg\/220px-Extreme_Programming.svg.png","height":"202","width":"220"},"url":"https:\/\/wiki.edu.vn\/wiki11\/2020\/12\/25\/extreme-programmierung-wikipedia\/","wordCount":8216,"articleBody":"     (adsbygoogle = window.adsbygoogle || []).push({});before-content-x4Softwareentwicklungsmethode  Planungs- und R\u00fcckkopplungsschleifen bei extremer Programmierung  Extremes Programmieren ((XP) ist eine Softwareentwicklungsmethode, die die Softwarequalit\u00e4t und die Reaktionsf\u00e4higkeit auf sich \u00e4ndernde Kundenanforderungen verbessern soll.  Als eine Art agile Softwareentwicklung,[1][2][3]  Es bef\u00fcrwortet h\u00e4ufige “Releases” in kurzen Entwicklungszyklen, um die Produktivit\u00e4t zu verbessern und Checkpoints einzuf\u00fchren, an denen neue Kundenanforderungen \u00fcbernommen werden k\u00f6nnen.Weitere Elemente der extremen Programmierung sind: Paarweise Programmierung oder umfassende Code\u00fcberpr\u00fcfung, Unit-Test des gesamten Codes, Programmierfunktionen erst dann, wenn sie tats\u00e4chlich ben\u00f6tigt werden, eine flache Verwaltungsstruktur, Einfachheit und Klarheit des Codes, Erwartung von \u00c4nderungen der Kundenanforderungen im Laufe der Zeit und das Problem wird besser verstanden und h\u00e4ufige Kommunikation mit dem Kunden und unter Programmierern.[2][3][4]  Die Methodik hat ihren Namen von der Idee, dass die n\u00fctzlichen Elemente traditioneller Software-Engineering-Praktiken auf “extreme” Ebenen gebracht werden.  Beispielsweise werden Code\u00fcberpr\u00fcfungen als vorteilhafte Praxis angesehen.  Im Extremfall kann der Code \u00fcberpr\u00fcft werden st\u00e4ndigdh die Praxis der Paarprogrammierung.  Table of ContentsGeschichte[edit]Urspr\u00fcnge[edit]Aktuellen Zustand[edit]Konzept[edit]Tore[edit]Aktivit\u00e4ten[edit]Codierung[edit]Testen[edit]H\u00f6ren[edit]Entwerfen[edit]Werte[edit]Kommunikation[edit]Einfachheit[edit]Feedback[edit]Mut[edit]Respekt[edit]Regeln[edit]Prinzipien[edit]Feedback[edit]Einfachheit vorausgesetzt[edit]Ver\u00e4nderung annehmen[edit]Praktiken Methoden Aus\u00fcbungen[edit]Feinskaliges Feedback[edit]Kontinuierlicher Prozess[edit]Gemeinsames Verst\u00e4ndnis[edit]Programmierer Wohlfahrt[edit]Kontroverse Aspekte[edit]Skalierbarkeit[edit]Salvatorische Klausel und Antworten[edit]Kritik[edit]Siehe auch[edit]Verweise[edit]Weiterf\u00fchrende Literatur[edit]Externe Links[edit]Geschichte[edit]Kent Beck entwickelte w\u00e4hrend seiner Arbeit am Lohn- und Gehaltsabrechnungsprojekt Chrysler Comprehensive Compensation System (C3) extreme Programmierkenntnisse.[5]  Beck wurde im M\u00e4rz 1996 C3-Projektleiter. Er begann die im Projekt verwendete Entwicklungsmethodik zu verfeinern und schrieb ein Buch \u00fcber die Methodik (Extreme Programmierung erkl\u00e4rt, ver\u00f6ffentlicht im Oktober 1999).[5]Chrysler stornierte das C3-Projekt im Februar 2000 nach sieben Jahren, als Daimler-Benz das Unternehmen \u00fcbernahm.[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\u00fchen 1960er Jahren im NASA-Projekt Mercury angewendet.  Um die Gesamtentwicklungszeit zu verk\u00fcrzen, wurden einige formale Testdokumente (z. B. f\u00fcr Abnahmetests) parallel (oder kurz zuvor) zur Testbereitschaft der Software entwickelt.  Eine unabh\u00e4ngige 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\u00f6\u00dferen Funktionen zu testen.Urspr\u00fcnge[edit]Zwei wichtige Einfl\u00fcsse pr\u00e4gten die Softwareentwicklung in den neunziger Jahren:  Sich schnell \u00e4ndernde Anforderungen erforderten k\u00fcrzere Produktlebenszyklen und stie\u00dfen h\u00e4ufig auf herk\u00f6mmliche Methoden der Softwareentwicklung.Das Chrysler Comprehensive Compensation System (C3) wurde gestartet, um den besten Weg f\u00fcr 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 \u00c4nderungen in den Entwicklungspraktiken vorzuschlagen und umzusetzen – basierend auf seiner Arbeit mit seinem h\u00e4ufigen Mitarbeiter Ward Cunningham.  Beck beschreibt die fr\u00fche 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\u00fcr 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\u00f6pfe f\u00fcr die Dinge, die ich f\u00fcr 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 \u00fcber 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\u00fcndungsmethoden (siehe agile Softwareentwicklung).  Au\u00dferdem wurden XP-Konzepte erl\u00e4utert[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\u00fcchern \u00fcber XP herausgegeben, beginnend mit seinen eigenen Extreme Programmierung erkl\u00e4rt (1999, ISBN 0-201-61641-6) und verbreitete seine Ideen an ein viel gr\u00f6\u00dferes 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\u00df in den sp\u00e4ten 1990er und fr\u00fchen 2000er Jahren bei Software-Communities auf gro\u00dfes Interesse und wurde in einer Reihe von Umgebungen eingef\u00fchrt, die sich grundlegend von ihren Urspr\u00fcngen unterschieden.Die hohe Disziplin, die von den urspr\u00fcnglichen Praktiken gefordert wurde, blieb oft auf der Strecke, was dazu f\u00fchrte, dass einige dieser Praktiken, wie jene, die f\u00fcr zu starr gehalten wurden, an einzelnen Standorten veraltet oder reduziert oder sogar unvollendet blieben.  Beispielsweise k\u00f6nnte die Praxis von Integrationstests am Tagesende f\u00fcr ein bestimmtes Projekt in einen Wochenendplan ge\u00e4ndert oder einfach auf Tests zu einvernehmlich festgelegten Terminen reduziert werden.  Solch ein entspannterer Zeitplan k\u00f6nnte verhindern, dass Menschen sich gehetzt f\u00fchlen, k\u00fcnstliche Stummel zu erzeugen, um die Tests am Ende des Tages zu bestehen.  Ein weniger strenger Zeitplan erm\u00f6glicht stattdessen die Entwicklung komplexer Funktionen \u00fcber 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\u00e4rt (November 2004), f\u00fcnf Jahre nach der ersten Ausgabe, f\u00fcgte Beck weitere Werte und Praktiken hinzu und unterschied zwischen prim\u00e4ren und Folgerungspraktiken.Die Theorie der nachhaltigen Softwareentwicklung erkl\u00e4rt, warum extreme Programmierteams trotz Teamst\u00f6rungen gedeihen k\u00f6nnen.[9][non-primary source needed]Konzept[edit]Tore[edit]Extreme Programmierung erkl\u00e4rt beschreibt extreme Programmierung als eine Softwareentwicklungsdisziplin, die Menschen organisiert, um qualitativ hochwertigere Software produktiver zu produzieren.XP versucht, die Kosten f\u00fcr \u00c4nderungen der Anforderungen zu senken, indem mehrere kurze und keine langen Entwicklungszyklen durchgef\u00fchrt werden.  In dieser Doktrin sind \u00c4nderungen ein nat\u00fcrlicher, unausweichlicher und w\u00fcnschenswerter Aspekt von Softwareentwicklungsprojekten und sollten geplant werden, anstatt zu versuchen, einen stabilen Satz von Anforderungen zu definieren.Extreme Programming f\u00fchrt neben dem agilen Programmier-Framework auch eine Reihe grundlegender Werte, Prinzipien und Praktiken ein.Aktivit\u00e4ten[edit]XP beschreibt vier grundlegende Aktivit\u00e4ten, die im Rahmen des Softwareentwicklungsprozesses ausgef\u00fchrt werden: Codieren, Testen, Abh\u00f6ren und Entwerfen.  Jede dieser Aktivit\u00e4ten wird unten beschrieben.Codierung[edit]Die Bef\u00fcrworter 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\u00f6sung herauszufinden.  Das Codieren kann auch dazu beitragen, Gedanken \u00fcber Programmierprobleme zu kommunizieren.  Ein Programmierer, der sich mit einem komplexen Programmierproblem befasst oder es schwierig findet, anderen Programmierern die L\u00f6sung zu erkl\u00e4ren, k\u00f6nnte es auf vereinfachte Weise codieren und den Code verwenden, um zu demonstrieren, was sie bedeuten.  Code, sagen die Bef\u00fcrworter dieser Position, ist immer klar und pr\u00e4gnant und kann nicht auf mehr als eine Weise interpretiert werden.  Andere Programmierer k\u00f6nnen Feedback zu diesem Code geben, indem sie auch ihre Gedanken codieren.Testen[edit]Das Testen ist f\u00fcr 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\u00f6nnen.Unit-Tests bestimmen, ob eine bestimmte Funktion wie beabsichtigt funktioniert.  Programmierer schreiben so viele automatisierte Tests, wie sie sich vorstellen k\u00f6nnen, die den Code “brechen” k\u00f6nnten.  Wenn alle Tests erfolgreich ausgef\u00fchrt wurden, ist die Codierung abgeschlossen.  Jeder geschriebene Code wird getestet, bevor mit der n\u00e4chsten Funktion fortgefahren wird.Abnahmetests best\u00e4tigen, dass die von den Programmierern verstandenen Anforderungen den tats\u00e4chlichen Anforderungen des Kunden entsprechen.Systemweite Integrationstests wurden zun\u00e4chst als t\u00e4gliche Aktivit\u00e4t am Tagesende zur Fr\u00fcherkennung inkompatibler Schnittstellen empfohlen, um die Verbindung wiederherzustellen, bevor die einzelnen Abschnitte stark von der koh\u00e4renten Funktionalit\u00e4t abweichen.  Die systemweiten Integrationstests wurden jedoch abh\u00e4ngig von der Stabilit\u00e4t der gesamten Schnittstellen im System auf w\u00f6chentlich oder seltener reduziert.[citation needed]H\u00f6ren[edit]Programmierer m\u00fcssen h\u00f6ren, was die Kunden vom System erwarten, welche “Gesch\u00e4ftslogik” ben\u00f6tigt wird.  Sie m\u00fcssen diese Anforderungen gut genug verstehen, um dem Kunden Feedback zu den technischen Aspekten zu geben, wie das Problem m\u00f6glicherweise gel\u00f6st werden kann oder nicht.  Die Kommunikation zwischen Kunde und Programmierer wird im weiter unten behandelt Planungsspiel.Entwerfen[edit]Unter dem Gesichtspunkt der Einfachheit k\u00f6nnte man nat\u00fcrlich sagen, dass die Systementwicklung nicht mehr als Codieren, Testen und Abh\u00f6ren erfordert.  Wenn diese Aktivit\u00e4ten gut ausgef\u00fchrt werden, sollte das Ergebnis immer ein funktionierendes System sein.  In der Praxis wird dies nicht funktionieren.  Man kann einen langen Weg ohne Design zur\u00fccklegen, aber zu einem bestimmten Zeitpunkt wird man stecken bleiben.  Das System wird zu komplex und die Abh\u00e4ngigkeiten 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\u00e4ngigkeiten innerhalb eines Systems vermieden.  Dies bedeutet, dass das \u00c4ndern eines Teils des Systems keine Auswirkungen auf andere Teile des Systems hat.[citation needed]Werte[edit]Extreme Programming erkannte 1999 zun\u00e4chst vier Werte: Kommunikation, Einfachheit, Feedback und Mut.  Ein neuer Wert, Respekt, wurde in der zweiten Ausgabe von hinzugef\u00fcgt Extreme Programmierung erkl\u00e4rt.  Diese f\u00fcnf Werte werden unten beschrieben.Kommunikation[edit]Zum Erstellen von Softwaresystemen m\u00fcssen die Systemanforderungen den Entwicklern des Systems mitgeteilt werden.  In formalen Softwareentwicklungsmethoden wird diese Aufgabe durch Dokumentation erf\u00fcllt.  Extreme Programmiertechniken k\u00f6nnen 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\u00e4ufige verbale Kommunikation und Feedback.Einfachheit[edit]Extreme Programmierung empfiehlt, mit der einfachsten L\u00f6sung zu beginnen.  Zus\u00e4tzliche Funktionen k\u00f6nnen sp\u00e4ter hinzugef\u00fcgt werden.  Der Unterschied zwischen diesem Ansatz und konventionelleren Systementwicklungsmethoden besteht darin, dass der Fokus auf das Entwerfen und Codieren f\u00fcr die Anforderungen von heute anstatt f\u00fcr die von morgen, n\u00e4chster Woche oder n\u00e4chsten Monat gelegt wird.  Dies wird manchmal als der Ansatz “Du wirst es nicht brauchen” (YAGNI) zusammengefasst.[11]  Bef\u00fcrworter von XP erkennen den Nachteil an, dass dies morgen manchmal mehr Aufwand bedeuten kann, um das System zu \u00e4ndern.  Ihre Behauptung ist, dass dies durch den Vorteil mehr als kompensiert wird, nicht in m\u00f6gliche zuk\u00fcnftige Anforderungen zu investieren, die sich \u00e4ndern k\u00f6nnten, bevor sie relevant werden.  Das Codieren und Entwerfen f\u00fcr ungewisse zuk\u00fcnftige Anforderungen birgt das Risiko, Ressourcen f\u00fcr etwas auszugeben, das m\u00f6glicherweise nicht ben\u00f6tigt wird, und m\u00f6glicherweise wichtige Funktionen zu verz\u00f6gern.  In Bezug auf den Wert “Kommunikation” sollte eine einfache Gestaltung und Codierung die Qualit\u00e4t der Kommunikation verbessern.  Ein einfaches Design mit sehr einfachem Code k\u00f6nnte von den meisten Programmierern im Team leicht verstanden werden.Feedback[edit]Bei extremer Programmierung bezieht sich Feedback auf verschiedene Dimensionen der Systementwicklung:R\u00fcckmeldung vom System: durch Schreiben von Unit-Tests,[5]  Bei regelm\u00e4\u00dfigen Integrationstests erhalten die Programmierer nach der Implementierung von \u00c4nderungen eine direkte R\u00fcckmeldung \u00fcber den Status des Systems.Feedback des Kunden: Die Funktionstests (auch Akzeptanztests genannt) werden vom Kunden und den Testern geschrieben.  Sie erhalten konkrete R\u00fcckmeldungen zum aktuellen Stand ihres Systems.  Diese \u00dcberpr\u00fcfung 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\u00e4tzung der Zeit, die f\u00fcr die Implementierung ben\u00f6tigt wird.Feedback ist eng mit Kommunikation und Einfachheit verbunden.  Fehler im System k\u00f6nnen leicht kommuniziert werden, indem ein Komponententest geschrieben wird, der beweist, dass ein bestimmter Code besch\u00e4digt wird.  Die direkte R\u00fcckmeldung vom System weist die Programmierer an, diesen Teil neu zu codieren.  Ein Kunde kann das System regelm\u00e4\u00dfig gem\u00e4\u00df 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\u00f6rpern Mut.  Eines ist das Gebot, immer f\u00fcr heute und nicht f\u00fcr morgen zu entwerfen und zu codieren.  Dies ist ein Versuch, um zu vermeiden, dass das Design ins Stocken ger\u00e4t und viel Aufwand erforderlich ist, um etwas anderes zu implementieren.  Mit Courage k\u00f6nnen Entwickler ihren Code bei Bedarf umgestalten.[5]  Dies bedeutet, das vorhandene System zu \u00fcberpr\u00fcfen und zu \u00e4ndern, damit zuk\u00fcnftige \u00c4nderungen einfacher implementiert werden k\u00f6nnen.  Ein weiteres Beispiel f\u00fcr Mut ist das Wissen, wann Code weggeworfen werden muss: Mut, veralteten Quellcode zu entfernen, unabh\u00e4ngig davon, wie viel Aufwand f\u00fcr 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\u00e4chsten Tag schnell l\u00f6sen, aber nur, wenn er hartn\u00e4ckig ist.Respekt[edit]Der Respektwert beinhaltet Respekt vor anderen sowie Selbstachtung.  Programmierer sollten niemals \u00c4nderungen vornehmen, die die Kompilierung unterbrechen, vorhandene Komponententests zum Scheitern bringen oder die Arbeit ihrer Kollegen auf andere Weise verz\u00f6gern.  Die Mitglieder respektieren ihre eigene Arbeit, indem sie stets nach hoher Qualit\u00e4t streben und durch Refactoring nach dem besten Design f\u00fcr die jeweilige L\u00f6sung suchen.Die \u00dcbernahme der vier fr\u00fcheren Werte f\u00fchrt zu Respekt gegen\u00fcber anderen im Team.  Niemand im Team sollte sich unbeachtet oder ignoriert f\u00fchlen.  Dies sorgt f\u00fcr ein hohes Ma\u00df an Motivation und f\u00f6rdert die Loyalit\u00e4t gegen\u00fcber dem Team und dem Ziel des Projekts.  Dieser Wert h\u00e4ngt von den anderen Werten ab und ist auf Teamarbeit ausgerichtet.Regeln[edit]Die erste Version der Regeln f\u00fcr XP wurde 1999 von Don Wells ver\u00f6ffentlicht[13]  auf der XP-Website.  29 Regeln sind in den Kategorien Planen, Verwalten, Entwerfen, Codieren und Testen angegeben.  Planen, Verwalten und Entwerfen werden ausdr\u00fccklich aufgerufen, um Behauptungen entgegenzuwirken, dass XP diese Aktivit\u00e4ten nicht unterst\u00fctzt.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\u00e4ten und Regeln im Rahmen der Regeln des Engagements definieren.Hier sind einige der Regeln (unvollst\u00e4ndig):CodierungTestenAlle Codes m\u00fcssen Unit-Tests habenDer 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\u00e4ufig durchgef\u00fchrt und die Ergebnisse ver\u00f6ffentlichtPrinzipien[edit]Die Prinzipien, die die Grundlage von XP bilden, basieren auf den gerade beschriebenen Werten und sollen Entscheidungen in einem Systementwicklungsprojekt f\u00f6rdern.  Die Grunds\u00e4tze sollen konkreter als die Werte sein und in einer praktischen Situation leichter in Leitlinien umgesetzt werden k\u00f6nnen.Feedback[edit]Extreme Programmierung sieht Feedback als am n\u00fctzlichsten an, wenn es h\u00e4ufig und schnell durchgef\u00fchrt wird.  Es wird betont, dass eine minimale Verz\u00f6gerung zwischen einer Aktion und ihrem Feedback entscheidend f\u00fcr das Lernen und Vornehmen von \u00c4nderungen ist.  Im Gegensatz zu herk\u00f6mmlichen Systementwicklungsmethoden erfolgt der Kontakt mit dem Kunden h\u00e4ufiger.  Der Kunde hat einen klaren Einblick in das System, das entwickelt wird, und kann Feedback geben und die Entwicklung nach Bedarf steuern.  Bei h\u00e4ufigem 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\u00fcckmeldung bei.  Wenn Sie beim Schreiben von Code den Komponententest ausf\u00fchren, erhalten Sie eine direkte R\u00fcckmeldung dar\u00fcber, wie das System auf die vorgenommenen \u00c4nderungen reagiert.  Dazu geh\u00f6rt, dass nicht nur die Komponententests ausgef\u00fchrt werden, die den Entwicklercode testen, sondern auch alle Komponententests f\u00fcr die gesamte Software mithilfe eines automatisierten Prozesses ausgef\u00fchrt 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 \u00c4nderungen des Entwicklers einen Fehler in einem anderen Teil des Systems verursachen, von dem der Entwickler wenig oder gar nichts wei\u00df, und macht den Entwickler auf die Inkompatibilit\u00e4t ihrer \u00c4nderung mit aufmerksam andere Teile des Systems und die Notwendigkeit, ihre \u00c4nderungen zu entfernen oder zu \u00e4ndern.  Unter den traditionellen Entwicklungspraktiken bedeutete das Fehlen einer automatisierten, umfassenden Unit-Test-Suite, dass eine solche Code\u00e4nderung, die vom Entwickler als harmlos angenommen wurde, an Ort und Stelle belassen worden w\u00e4re und nur w\u00e4hrend der Integrationstests – oder schlimmer noch – nur in der Produktion aufgetreten w\u00e4re.  Es war eine gewaltige Aufgabe, festzustellen, welche Code\u00e4nderung das Problem verursachte, und zwar unter allen \u00c4nderungen, 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\u00e4re seine L\u00f6sung “extrem einfach”.  Traditionelle Systementwicklungsmethoden sagen, dass sie f\u00fcr die Zukunft planen und f\u00fcr die Wiederverwendbarkeit codieren sollen.  Extreme Programmierung lehnt diese Ideen ab.Die Bef\u00fcrworter extremer Programmierung sagen, dass es nicht funktioniert, gro\u00dfe \u00c4nderungen auf einmal vorzunehmen.  Bei extremer Programmierung werden inkrementelle \u00c4nderungen vorgenommen: Beispielsweise kann ein System alle drei Wochen kleine Releases haben.  Wenn viele kleine Schritte unternommen werden, hat der Kunde mehr Kontrolle \u00fcber den Entwicklungsprozess und das System, das entwickelt wird.Ver\u00e4nderung annehmen[edit]Das Prinzip, Ver\u00e4nderungen anzunehmen, besteht darin, nicht gegen Ver\u00e4nderungen zu arbeiten, sondern sie anzunehmen.  Wenn sich beispielsweise bei einem der iterativen Meetings herausstellt, dass sich die Anforderungen des Kunden dramatisch ge\u00e4ndert haben, m\u00fcssen Programmierer dies ber\u00fccksichtigen und die neuen Anforderungen f\u00fcr die n\u00e4chste Iteration planen.Praktiken Methoden Aus\u00fcbungen[edit]Es wurde beschrieben, dass extreme Programmierung 12 \u00dcbungen umfasst, die in vier Bereiche unterteilt sind:Feinskaliges Feedback[edit]Kontinuierlicher Prozess[edit]Gemeinsames Verst\u00e4ndnis[edit]Programmierer Wohlfahrt[edit]Kontroverse Aspekte[edit]Die Praktiken in XP wurden heftig diskutiert.[5]  Bef\u00fcrworter extremer Programmierung behaupten, dass sie den Kunden vor Ort haben[5]  Informelle \u00c4nderungen anfordern, der Prozess wird flexibel und spart die Kosten f\u00fcr formalen Overhead.  Kritiker von XP behaupten, dies k\u00f6nne zu kostspieligen Nacharbeiten f\u00fchren und den Projektumfang \u00fcber das zuvor vereinbarte oder finanzierte Ma\u00df hinausschleichen.[citation needed]Change-Control-Boards sind ein Zeichen daf\u00fcr, dass es potenzielle Konflikte bei den Projektzielen und Einschr\u00e4nkungen zwischen mehreren Benutzern gibt.  Die beschleunigten Methoden von XP h\u00e4ngen in gewisser Weise davon ab, dass Programmierer einen einheitlichen Client-Standpunkt einnehmen k\u00f6nnen, damit sich der Programmierer auf die Codierung konzentrieren kann, anstatt Kompromissziele und -beschr\u00e4nkungen 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\u00fcckt.Anforderungen werden inkrementell definiert, anstatt zu versuchen, sie alle im Voraus zu erhalten.Softwareentwickler m\u00fcssen normalerweise paarweise arbeiten.Es gibt kein gro\u00dfes Design vorne.  Der gr\u00f6\u00dfte Teil der Entwurfsaktivit\u00e4t findet im laufenden Betrieb und schrittweise statt, beginnend mit “das Einfachste, was m\u00f6glicherweise funktionieren k\u00f6nnte” und Komplexit\u00e4t nur dann hinzuzuf\u00fcgen, wenn dies durch fehlgeschlagene Tests erforderlich ist.  Kritiker vergleichen dies mit dem “Debuggen eines Systems in Erscheinung” und bef\u00fcrchten, dass dies zu mehr Umgestaltungsaufwand f\u00fchrt als nur zu einer Neugestaltung, wenn sich die Anforderungen \u00e4ndern.Ein Kundenvertreter ist dem Projekt beigef\u00fcgt.  Diese Rolle kann zu einer zentralen Fehlerquelle f\u00fcr 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\u00f6gliche Nachteile festgestellt,[5]  Dazu geh\u00f6ren 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\u00fchrt.  Es soll die M\u00f6glichkeit bieten, in gro\u00dfen und verteilten Teams zu arbeiten.  Es hat jetzt 23 Praktiken und flexible Werte.Salvatorische Klausel und Antworten[edit]Im Jahr 2003 ver\u00f6ffentlichten Matt Stephens und Doug Rosenberg Extreme Programmierung \u00fcberarbeitet: Der Fall gegen XP, der den Wert des XP-Prozesses in Frage stellte und M\u00f6glichkeiten vorschlug, ihn zu verbessern.[6]  Dies l\u00f6ste eine lange Debatte in Artikeln, Internet-Newsgroups und Website-Chat-Bereichen aus.  Das Hauptargument des Buches ist, dass die Praktiken von XP voneinander abh\u00e4ngig sind, dass jedoch nur wenige praktische Organisationen bereit \/ in der Lage sind, alle Praktiken zu \u00fcbernehmen.  Daher schl\u00e4gt der gesamte Prozess fehl.  Das Buch macht auch andere Kritikpunkte und zeigt in negativer Weise eine \u00c4hnlichkeit des XP-Modells “kollektives Eigentum” mit dem Sozialismus.Bestimmte Aspekte von XP haben sich seit der Ver\u00f6ffentlichung von ge\u00e4ndert Extreme Programmierung \u00fcberarbeitet;;  Insbesondere nimmt XP jetzt \u00c4nderungen an den Praktiken vor, solange die erforderlichen Ziele noch erreicht werden.  XP verwendet auch zunehmend allgemeine Begriffe f\u00fcr Prozesse.  Einige argumentieren, dass diese \u00c4nderungen fr\u00fchere Kritikpunkte ung\u00fcltig machen;  andere behaupten, dass dies den Prozess einfach verw\u00e4ssert.Andere Autoren haben versucht, XP mit den \u00e4lteren 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\u00e4rkten, was zu einer besseren Entwicklung f\u00fchrte und sich nicht widersprachen.[17]Kritik[edit]Die anf\u00e4ngliche Begeisterung f\u00fcr extreme Programme und kontroverse Grunds\u00e4tze 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\u00e4ndnisse der agilen Entwicklung angesehen.[21]Insbesondere die extreme Programmierung wurde von Matt Stephens und Doug Rosenberg \u00fcberpr\u00fcft und kritisiert Extreme Programmierung \u00fcberarbeitet.[6]Kritikpunkte sind:Eine Methodik ist nur so effektiv wie die beteiligten Personen, Agile l\u00f6st dies nicht[citation needed]Wird h\u00e4ufig als Mittel verwendet, um Kunden Geld zu entl\u00fcften, 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\u00e4\u00dfigen Abst\u00e4nden mit enormen Kosten f\u00fcr die Kunden[citation needed]erfordert zu viel kulturellen Wandel, um angenommen zu werden[citation needed]kann zu schwierigeren Vertragsverhandlungen f\u00fchren[citation needed]kann sehr ineffizient sein;  Wenn sich die Anforderungen f\u00fcr einen Codebereich durch verschiedene Iterationen \u00e4ndern, muss dieselbe Programmierung m\u00f6glicherweise mehrmals durchgef\u00fchrt werden.  Wenn ein Plan befolgt werden soll, wird erwartet, dass ein einzelner Codebereich einmal geschrieben wird.[citation needed]Es ist unm\u00f6glich, realistische Sch\u00e4tzungen des Arbeitsaufwands zu erstellen, der f\u00fcr 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\u00f6hen[citation needed]Agile ist funktionsgesteuert.  Nicht funktionale Qualit\u00e4tsattribute sind schwer als User Stories darzustellen.[citation needed]Siehe auch[edit]Verweise[edit]^ “Human Centered Technology Workshop 2006”, 2006, PDF, Human Centered Technology Workshop 2006 ^ ein b UPenn-Lectures-Design-Patterns “Design Patterns and Refactoring”, Universit\u00e4t von Pennsylvania, 2003.^ ein b USFCA-edu-601-Vorlesung Extreme Programming.^ “Manifest f\u00fcr agile Softwareentwicklung”.  Agilemanifesto.org.  2001.  Abgerufen 26. M\u00e4rz, 2019.^ ein b c d e f G h ich j k l m Computerworld-appdev-92 “Extreme Programming”, Computerwelt (online), Dezember 2001.^ ein b c Rosenberg, Doug;  Stephens, Matt (2003). Extreme Programmierung \u00fcberarbeitet: Der Fall gegen XP.  Apress.  ISBN 978-1-59059-096-6.^ Interview mit Kent Beck und Martin Fowler. informit.com.  23. M\u00e4rz 2001.^ Sedano, Todd;  Ralph, Paul;  P\u00e9raire, C\u00e9cile (2016). Vortr\u00e4ge des 10. Internationalen ACM \/ IEEE-Symposiums f\u00fcr empirisches Software-Engineering und -Messung – ESEM ’16.  S. 1\u201310.  doi:10.1145 \/ 2961111.2962590.  ISBN 9781450344272.  S2CID 18984951.^ Lisa Crispin;  Tip House (2003). Testen der extremen Programmierung.  ISBN 9780321113559.^ “Jeder ist ein Programmierer” von Clair Tristram.  Technologie\u00fcberpr\u00fcfung, November 2003. p.  39.^ Beck, K. (1999). Extreme Programmierung erkl\u00e4rt: Umfassen Sie Ver\u00e4nderungen.  Addison-Wesley.  ISBN 978-0-321-27865-4.^ “Extreme Programmierregeln”. extremeprogramming.org.^ Ken Auer Archiviert 20. September 2008 an der Wayback-Maschine^ John Carroll;  David Morris (29. Juli 2015). Agiles Projektmanagement in einfachen Schritten, 2. Auflage.  In einfachen Schritten.  p.  162. ISBN 978-1-84078-703-0.^ Cutter-Konsortium. “Industrial XP: XP in gro\u00dfen Organisationen zum Laufen bringen – Cutter Consortium”. cutter.com.^ Extreme Programmierung (XP) Six Sigma CMMI.^ McBreen, P. (2003). Extreme Programmierung in Frage stellen.  Boston, MA: Addison-Wesley.  ISBN 978-0-201-84457-3.^ Boehm, B.;  R. Turner (2004). Balance zwischen Beweglichkeit und Disziplin: Ein Leitfaden f\u00fcr Verbl\u00fcffte.  Boston, MA: Addison-Wesley.  ISBN 978-0-321-18612-6.^ Stephens, Matt;  Doug Rosenberg (2004). Die Ironie extremer Programmierung.  MA: Dr. Dobbs Tagebuch.^ sdmagazine   Archiviert 16. M\u00e4rz 2006 an der Wayback-MaschineWeiterf\u00fchrende 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\u00f6nnen 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\u00e4rt: Umfassen Sie Ver\u00e4nderungen, Addison-Wesley.Kent Beck und Martin Fowler: Extreme Programmierung planen, Addison-Wesley.Kent Beck und Cynthia Andres. Extreme Programmierung erkl\u00e4rt: Umarmung Ver\u00e4nderung, 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-\u00d6kosysteme, 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\u201356.Matt Stephens und Doug Rosenberg (2003). Extreme Programmierung \u00fcberarbeitet: Der Fall gegen XP, Apress.Waldner, JB.  (2008).  “Nanocomputer und Schwarmintelligenz”.  In: ISTE, 225\u2013256.Externe Links[edit]     (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki11\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki11\/2020\/12\/25\/extreme-programmierung-wikipedia\/#breadcrumbitem","name":"Extreme Programmierung – Wikipedia"}}]}]