[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/wiki10\/2020\/12\/26\/extreme-programmierpraktiken-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/wiki10\/2020\/12\/26\/extreme-programmierpraktiken-wikipedia\/","headline":"Extreme Programmierpraktiken – Wikipedia","name":"Extreme Programmierpraktiken – Wikipedia","description":"before-content-x4 Extremes Programmieren ((XP) ist eine agile Softwareentwicklungsmethode zur Implementierung von Softwareprojekten. Dieser Artikel beschreibt die in dieser Methodik verwendeten","datePublished":"2020-12-26","dateModified":"2020-12-26","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/wiki10\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/wiki10\/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:\/\/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":100,"height":100},"url":"https:\/\/wiki.edu.vn\/wiki10\/2020\/12\/26\/extreme-programmierpraktiken-wikipedia\/","wordCount":4293,"articleBody":"     (adsbygoogle = window.adsbygoogle || []).push({});before-content-x4Extremes Programmieren ((XP) ist eine agile Softwareentwicklungsmethode zur Implementierung von Softwareprojekten.  Dieser Artikel beschreibt die in dieser Methodik verwendeten Praktiken.  Extreme Programming umfasst 12 Methoden, die in vier Bereiche unterteilt sind und sich aus den Best Practices der Softwareentwicklung ableiten.[1]       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Table of ContentsFeinskaliges Feedback[edit]Paar-Programmierung[edit]Planungsspiel[edit]Release-Planung[edit]Explorationsphase[edit]Verpflichtungsphase[edit]Nach Wert sortieren[edit]Nach Risiko sortieren[edit]Lenkphase[edit]Iterationsplanung[edit]Explorationsphase[edit]Verpflichtungsphase[edit]Lenkphase[edit]Testgetriebene Entwicklung[edit]Ganzes Team[edit]Kontinuierlicher Prozess[edit]Kontinuierliche Integration[edit]Designverbesserung[edit]Kleine Ver\u00f6ffentlichungen[edit]Gemeinsames Verst\u00e4ndnis[edit]Codierungsstandard[edit]Kollektiver Codebesitz[edit]Einfaches Design[edit]Systemmetapher[edit]Programmierer Wohlfahrt[edit]Ein einhaltbares Schritttempo[edit]Siehe auch[edit]Verweise[edit]Externe Links[edit]Feinskaliges Feedback[edit]Paar-Programmierung[edit]Paarprogrammierung bedeutet, dass der gesamte Code von zwei Personen erstellt wird, die an einer Aufgabe auf einer Workstation programmieren.  Ein Programmierer hat die Kontrolle \u00fcber die Workstation und denkt haupts\u00e4chlich \u00fcber die Codierung im Detail nach.  Der andere Programmierer konzentriert sich mehr auf das Gesamtbild und \u00fcberpr\u00fcft kontinuierlich den Code, der vom ersten Programmierer erstellt wird.  Programmierer tauschen Rollen nach Minuten- bis Stundenperioden.Die Paare sind nicht festgelegt;  Programmierer wechseln h\u00e4ufig die Partner, sodass jeder wei\u00df, was jeder tut, und jeder mit dem gesamten System vertraut bleibt, auch mit den Teilen au\u00dferhalb seiner F\u00e4higkeiten.  Auf diese Weise kann die Paarprogrammierung auch die teamweite Kommunikation verbessern.  (Dies geht auch Hand in Hand mit dem Konzept des kollektiven Eigentums).       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Planungsspiel[edit]Der Hauptplanungsprozess innerhalb der extremen Programmierung wird als Planungsspiel bezeichnet.  Das Spiel ist eine Besprechung, die einmal pro Iteration stattfindet, normalerweise einmal pro Woche.  Der Planungsprozess gliedert sich in zwei Teile:Release-Planung: Hier geht es darum zu bestimmen, welche Anforderungen in welchen kurzfristigen Releases enthalten sind und wann sie geliefert werden sollten.  Die Kunden und Entwickler sind beide Teil davon.  Die Release-Planung besteht aus drei Phasen:Explorationsphase: In dieser Phase stellt der Kunde eine Auswahlliste mit hochwertigen Anforderungen an das System zur Verf\u00fcgung.  Diese werden auf User Story-Karten niedergeschrieben.Commitment-Phase: In der Commitment-Phase verpflichten sich Unternehmen und Entwickler zu den Funktionen, die enthalten sein werden, und zum Datum der n\u00e4chsten Version.Lenkphase: In der Lenkphase kann der Plan angepasst, neue Anforderungen hinzugef\u00fcgt und \/ oder bestehende Anforderungen ge\u00e4ndert oder entfernt werden.Iterationsplanung: Hier werden die Aktivit\u00e4ten und Aufgaben der Entwickler geplant.  An diesem Prozess ist der Kunde nicht beteiligt.  Die Iterationsplanung besteht ebenfalls aus drei Phasen:Explorationsphase: In dieser Phase wird die Anforderung in verschiedene Aufgaben \u00fcbersetzt.  Die Aufgaben werden auf Aufgabenkarten aufgezeichnet.Verpflichtungsphase: Die Aufgaben werden den Programmierern zugewiesen und die Zeit, die f\u00fcr die Ausf\u00fchrung ben\u00f6tigt wird, wird gesch\u00e4tzt.Lenkphase: Die Aufgaben werden ausgef\u00fchrt und das Endergebnis wird mit der urspr\u00fcnglichen User Story abgeglichen.Der Zweck des Planungsspiels besteht darin, das Produkt in die Lieferung zu f\u00fchren.  Anstatt die genauen Daten vorherzusagen, wann Liefergegenst\u00e4nde ben\u00f6tigt und produziert werden, was schwierig ist, zielt es darauf ab, das Projekt mit einem einfachen Ansatz in die Lieferung zu lenken.[2]  Der Planning-Game-Ansatz wurde auch von Nicht-Software-Projekten und -Teams im Kontext der gesch\u00e4ftlichen Agilit\u00e4t \u00fcbernommen.[3]Release-Planung[edit]Explorationsphase[edit]Dies ist ein iterativer Prozess zum Sammeln von Anforderungen und zum Sch\u00e4tzen der Arbeitsauswirkungen jeder dieser Anforderungen.Schreiben Sie eine Geschichte: Das Gesch\u00e4ft hat ein Problem.  W\u00e4hrend eines Meetings wird die Entwicklung versuchen, dieses Problem zu definieren und Anforderungen zu erhalten.  Basierend auf dem Gesch\u00e4ftsproblem muss eine Story (User Story) geschrieben werden.  Dies geschieht durch Unternehmen, in denen sie darauf hinweisen, was ein Teil des Systems tun soll.  Es ist wichtig, dass die Entwicklung keinen Einfluss auf diese Geschichte hat.  Die Geschichte wird auf eine User Story-Karte geschrieben.Eine Geschichte sch\u00e4tzen: Die Entwicklung sch\u00e4tzt, wie lange es dauern wird, bis die von der Story-Karte implizierte Arbeit umgesetzt ist.  Die Entwicklung kann auch Spitzenl\u00f6sungen erstellen, um das Problem zu analysieren oder zu l\u00f6sen.  Diese L\u00f6sungen werden zur Sch\u00e4tzung verwendet und verworfen, sobald alle eine klare Visualisierung des Problems erhalten.  Auch dies hat m\u00f6glicherweise keinen Einfluss auf die Gesch\u00e4ftsanforderungen.Eine Geschichte teilen: Jede designkritische Komplexit\u00e4t muss ber\u00fccksichtigt werden, bevor mit der Iterationsplanung begonnen wird.  Wenn die Entwicklung die Geschichte nicht einsch\u00e4tzen kann, muss sie aufgeteilt und erneut geschrieben werden.Wenn das Unternehmen keine weiteren Anforderungen stellen kann, geht man in die Verpflichtungsphase \u00fcber.       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Verpflichtungsphase[edit]In dieser Phase werden Kosten, Nutzen und Auswirkungen auf den Zeitplan ermittelt.  Es hat vier Komponenten:Nach Wert sortieren: Business sortiert die User Stories nach Business Value.Nach Risiko sortieren: Die Entwicklung sortiert die Geschichten nach Risiko.Geschwindigkeit einstellen: Die Entwicklung bestimmt, mit welcher Geschwindigkeit das Projekt ausgef\u00fchrt werden kann.Umfang ausw\u00e4hlen: Die User Stories, die in der n\u00e4chsten Version fertiggestellt werden, werden ausgew\u00e4hlt.  Basierend auf den User Stories wird das Ver\u00f6ffentlichungsdatum festgelegt.Nach Wert sortieren[edit]Die Gesch\u00e4ftsseite sortiert die User Stories nach Gesch\u00e4ftswert.  Sie werden sie in drei Stapel anordnen:Kritisch: Geschichten, ohne die das System nicht funktionieren kann oder keine Bedeutung hat.Signifikanter Gesch\u00e4ftswert: Unkritische User Stories mit signifikantem Gesch\u00e4ftswert.Sch\u00f6n zu haben: User Stories, die keinen signifikanten gesch\u00e4ftlichen Wert haben.Nach Risiko sortieren[edit]Die Entwickler sortieren die User Stories nach Risiko.  Sie lassen sich auch in drei Stapel einteilen: User Stories mit geringem, mittlerem und hohem Risiko.  Das Folgende ist ein Beispiel f\u00fcr einen Ansatz hierf\u00fcr:Risikoindex bestimmen: Geben Sie jeder User Story einen Index von 0 bis 2 f\u00fcr jeden der folgenden Faktoren:Vollst\u00e4ndigkeit (kennen wir alle Details der Geschichte?)Beende (0)Unvollst\u00e4ndig (1)Unbekannt (2)Volatilit\u00e4t (wird sich wahrscheinlich \u00e4ndern?)niedrig (0)mittel (1)hoch (2)Komplexit\u00e4t (wie schwer ist es zu bauen?)einfach (0)Standard (1)Komplex (2)Alle Indizes f\u00fcr eine User Story werden hinzugef\u00fcgt, wobei den User Stories ein Risikoindex von niedrig (0\u20131), mittel (2\u20134) oder hoch (5\u20136) zugewiesen wird.Lenkphase[edit]Innerhalb der Steuerungsphase k\u00f6nnen Programmierer und Gesch\u00e4ftsleute den Prozess “steuern”.  Das hei\u00dft, sie k\u00f6nnen \u00c4nderungen vornehmen.  Einzelne User Stories oder relative Priorit\u00e4ten verschiedener User Stories k\u00f6nnen sich \u00e4ndern.  Sch\u00e4tzungen k\u00f6nnten sich als falsch erweisen.  Dies ist die M\u00f6glichkeit, den Plan entsprechend anzupassen.Iterationsplanung[edit]Ber\u00fccksichtigung der zu planenden Storypoints f\u00fcr die Teamgeschwindigkeit.  Die Iterationsdauer kann 1 bis 3 Wochen betragen.Explorationsphase[edit]In der Explorationsphase der Iterationsplanung geht es darum, Aufgaben zu erstellen und deren Implementierungszeit abzusch\u00e4tzen.\u00dcbersetzen Sie die Anforderung in Aufgaben: Platzieren Sie sie auf Aufgabenkarten.Aufgabe kombinieren \/ teilen: Wenn der Programmierer die Aufgabe nicht sch\u00e4tzen kann, weil sie zu klein oder zu gro\u00df ist, muss der Programmierer die Aufgabe kombinieren oder teilen.Aufgabe sch\u00e4tzen: Sch\u00e4tzen Sie die Zeit, die zur Implementierung der Aufgabe ben\u00f6tigt wird.Verpflichtungsphase[edit]Innerhalb der Commitment-Phase der Iterationsplanung werden Programmierern Aufgaben zugewiesen, die auf die verschiedenen User Stories verweisen.Ein Programmierer nimmt eine Aufgabe an: Jeder Programmierer w\u00e4hlt eine Aufgabe aus, f\u00fcr die er die Verantwortung \u00fcbernimmt.Der Programmierer sch\u00e4tzt die Aufgabe: Da der Programmierer jetzt f\u00fcr die Aufgabe verantwortlich ist, sollte er die eventuelle Sch\u00e4tzung der Aufgabe abgeben.Lastfaktor einstellen: Der Lastfaktor repr\u00e4sentiert die ideale Menge an praktischer Entwicklungszeit pro Programmierer innerhalb einer Iteration.  In einer 40-Stunden-Woche mit 5 Stunden f\u00fcr Besprechungen w\u00e4ren dies beispielsweise nicht mehr als 35 Stunden.Balancing: Wenn allen Programmierern im Team Aufgaben zugewiesen wurden, wird ein Vergleich zwischen der gesch\u00e4tzten Zeit der Aufgaben und dem Auslastungsfaktor durchgef\u00fchrt.  Dann werden die Aufgaben unter den Programmierern ausgeglichen.  Wenn ein Programmierer \u00fcberlastet ist, m\u00fcssen andere Programmierer einige seiner Aufgaben \u00fcbernehmen und umgekehrt.Lenkphase[edit]Die Implementierung der Aufgaben erfolgt w\u00e4hrend der Lenkphase der Iteration.Aufgabenkarte erhalten: Der Programmierer erh\u00e4lt die Aufgabenkarte f\u00fcr eine der Aufgaben, f\u00fcr die er sich verpflichtet hat.Partner finden: Der Programmierer implementiert diese Aufgabe zusammen mit einem anderen Programmierer.  Dies wird in der Praxis der Paarprogrammierung weiter erl\u00e4utert.Entwerfen der Aufgabe: Bei Bedarf entwerfen die Programmierer die Funktionalit\u00e4t der Aufgabe.Implementieren Sie die Aufgabe mithilfe der testgetriebenen Entwicklung (TDD) (siehe unten).Funktionstest ausf\u00fchren: Funktionstests (basierend auf den Anforderungen in der zugeh\u00f6rigen User Story und Task Card) werden ausgef\u00fchrt.Testgetriebene Entwicklung[edit]Unit-Tests sind automatisierte Tests, die die Funktionalit\u00e4t von Codeteilen (z. B. Klassen, Methoden) testen.  Innerhalb von XP werden Komponententests geschrieben, bevor der eventuelle Code codiert wird.  Dieser Ansatz soll den Programmierer dazu anregen, \u00fcber Bedingungen nachzudenken, unter denen sein Code fehlschlagen k\u00f6nnte.  XP sagt, dass der Programmierer mit einem bestimmten Code fertig ist, wenn er keine weiteren Bedingungen finden kann, unter denen der Code m\u00f6glicherweise fehlschl\u00e4gt.Die testgetriebene Entwicklung erfolgt durch schnelles Durchlaufen der folgenden Schritte, wobei jeder Schritt h\u00f6chstens Minuten dauert, vorzugsweise viel weniger.  Da jede User Story normalerweise ein bis zwei Arbeitstage erfordert, ist pro Story eine sehr gro\u00dfe Anzahl solcher Zyklen erforderlich.Unit-Test schreiben: Die Programmierer schreiben einen minimalen Test, der fehlschlagen sollte, da die Funktionalit\u00e4t im Produktionscode nicht vollst\u00e4ndig implementiert wurde.Beobachten Sie, wie der neue Test fehlschl\u00e4gt: Die Programmierer \u00fcberpr\u00fcfen, ob der Test tats\u00e4chlich fehlschl\u00e4gt.  Obwohl dies wie Zeitverschwendung erscheint, ist dieser Schritt von entscheidender Bedeutung, da er best\u00e4tigt, dass Ihre \u00dcberzeugung vom Status des Produktionscodes korrekt ist.  Wenn der Test nicht fehlschl\u00e4gt, sollten die Programmierer feststellen, ob der Testcode einen Fehler enth\u00e4lt oder ob der Produktionscode die im neuen Test beschriebene Funktionalit\u00e4t unterst\u00fctzt.Code schreiben: Die Programmierer schreiben gerade genug Produktionscode, damit der neue Test bestanden wird.Test ausf\u00fchren: Die Komponententests werden ausgef\u00fchrt, um sicherzustellen, dass der neue Produktionscode den neuen Test besteht und keine anderen Tests fehlschlagen.Refactor: Entfernen Sie alle Codeger\u00fcche aus dem Produktions- und Testcode.Eine intensivere Version des obigen Prozesses finden Sie in den drei TDD-Regeln von Onkel Bob.[4]Ganzes Team[edit]Innerhalb von XP ist der “Kunde” nicht derjenige, der die Rechnung bezahlt, sondern derjenige, der das System wirklich nutzt.  XP sagt, dass der Kunde jederzeit zur Verf\u00fcgung stehen und f\u00fcr Fragen zur Verf\u00fcgung stehen sollte.  Zum Beispiel sollte das Team, das ein Finanzverwaltungssystem entwickelt, einen Finanzadministrator umfassen.Kontinuierlicher Prozess[edit]Kontinuierliche Integration[edit]Das Entwicklungsteam sollte immer an der neuesten Version der Software arbeiten.  Da verschiedene Teammitglieder m\u00f6glicherweise Versionen mit verschiedenen \u00c4nderungen und Verbesserungen lokal gespeichert haben, sollten sie versuchen, ihre aktuelle Version alle paar Stunden oder wenn sich eine erhebliche Unterbrechung ergibt, in das Code-Repository hochzuladen.  Durch die kontinuierliche Integration werden Verz\u00f6gerungen sp\u00e4ter im Projektzyklus vermieden, die durch Integrationsprobleme verursacht werden.Designverbesserung[edit]Da die XP-Doktrin bef\u00fcrwortet, nur das zu programmieren, was heute ben\u00f6tigt wird, und es so einfach wie m\u00f6glich zu implementieren, kann dies manchmal dazu f\u00fchren, dass ein System stecken bleibt.  Eines der Symptome hierf\u00fcr ist die Notwendigkeit einer doppelten (oder mehrfachen) Wartung: Funktions\u00e4nderungen erfordern \u00c4nderungen an mehreren Kopien desselben (oder \u00e4hnlichen) Codes.  Ein weiteres Symptom ist, dass \u00c4nderungen in einem Teil des Codes viele andere Teile betreffen.  Die XP-Doktrin besagt, dass das System Sie in diesem Fall auffordert, Ihren Code durch \u00c4ndern der Architektur umzugestalten, um ihn einfacher und allgemeiner zu gestalten.Kleine Ver\u00f6ffentlichungen[edit]Die Bereitstellung der Software erfolgt \u00fcber h\u00e4ufige Releases von Live-Funktionen, die einen konkreten Wert schaffen.  Die kleinen Releases helfen dem Kunden, Vertrauen in den Fortschritt des Projekts zu gewinnen.  Dies tr\u00e4gt dazu bei, das Konzept des gesamten Teams aufrechtzuerhalten, da der Kunde nun seine Vorschl\u00e4ge f\u00fcr das Projekt auf der Grundlage realer Erfahrungen einbringen kann.Gemeinsames Verst\u00e4ndnis[edit]Codierungsstandard[edit]Der Codierungsstandard ist ein vereinbartes Regelwerk, das das gesamte Entwicklungsteam w\u00e4hrend des gesamten Projekts einh\u00e4lt.  Der Standard legt einen einheitlichen Stil und ein einheitliches Format f\u00fcr den Quellcode innerhalb der gew\u00e4hlten Programmiersprache sowie verschiedene Programmierkonstrukte und -muster fest, die vermieden werden sollten, um die Wahrscheinlichkeit von Fehlern zu verringern.[5]    Der Codierungsstandard kann eine vom Sprachanbieter festgelegte Standardkonvention sein (z. B. die von Sun empfohlenen Codekonventionen f\u00fcr die Java-Programmiersprache) oder vom Entwicklungsteam benutzerdefiniert definiert werden.Unterst\u00fctzer von Extreme Programming bef\u00fcrworten Code, der sich so weit wie m\u00f6glich selbst dokumentiert.  Dies reduziert die Notwendigkeit von Codekommentaren, die m\u00f6glicherweise nicht mehr mit dem Code selbst synchronisiert sind.[6]Kollektiver Codebesitz[edit]Kollektiver Code-Besitz (auch als “Team-Code-Besitz” und “gemeinsamer Code” bezeichnet) bedeutet, dass jeder f\u00fcr den gesamten Code verantwortlich ist.  Daher darf jeder einen Teil des Codes \u00e4ndern.  Der Besitz von kollektivem Code ist nicht nur eine Organisationsrichtlinie, sondern auch ein Gef\u00fchl.  “Entwickler sp\u00fcren den Besitz von Teamcode mehr, wenn sie den Systemkontext verstehen, zum fraglichen Code beigetragen haben, die Codequalit\u00e4t als hoch empfinden, glauben, dass das Produkt die Benutzeranforderungen erf\u00fcllt, und einen hohen Teamzusammenhalt wahrnehmen.”[7]  Die Paarprogrammierung, insbesondere die \u00fcberlappende Paarrotation, tr\u00e4gt zu dieser Praxis bei: Durch die Arbeit in verschiedenen Paaren verstehen Programmierer den Systemkontext besser und tragen zu mehr Bereichen der Codebasis bei.Der Besitz von kollektivem Code kann die Entwicklung beschleunigen, da ein Entwickler, der einen Fehler entdeckt, diesen sofort beheben kann, wodurch Fehler insgesamt reduziert werden k\u00f6nnen.  Programmierer k\u00f6nnen jedoch auch Fehler einf\u00fchren, wenn sie Code \u00e4ndern, den sie nicht gut verstehen.  Ausreichend genau definierte Komponententests sollten dieses Problem mindern: Wenn unvorhergesehene Abh\u00e4ngigkeiten Fehler verursachen, werden beim Ausf\u00fchren von Komponententests Fehler angezeigt.Kollektiver Codebesitz kann zu einer besseren Sicherung der Mitglieder, einer besseren Verteilung von Wissen und Lernen, einer gemeinsamen Verantwortung f\u00fcr den Code, einer h\u00f6heren Codequalit\u00e4t und einer geringeren Nacharbeit f\u00fchren.  Es kann aber auch zu vermehrten Konflikten zwischen Mitgliedern, vermehrten Fehlern, \u00c4nderungen des mentalen Flusses der Entwickler und Unterbrechungen ihrer \u00dcberlegungen, einer l\u00e4ngeren Entwicklungszeit oder einem geringeren Verst\u00e4ndnis des Codes f\u00fchren.[8]Einfaches Design[edit]Programmierer sollten beim Software-Design einen “simple is best” -Ansatz w\u00e4hlen.  Wenn ein neuer Code geschrieben wird, sollte sich der Autor fragen: Gibt es eine einfachere M\u00f6glichkeit, dieselbe Funktionalit\u00e4t einzuf\u00fchren?  Wenn die Antwort ja ist, sollte der einfachere Kurs gew\u00e4hlt werden.  Refactoring sollte auch verwendet werden, um komplexen Code zu vereinfachen.Systemmetapher[edit]Die Systemmetapher ist eine Geschichte, die jeder – Kunden, Programmierer und Manager – \u00fcber die Funktionsweise des Systems erz\u00e4hlen kann.  Es ist ein Namenskonzept f\u00fcr Klassen und Methoden, das es einem Teammitglied erleichtern soll, die Funktionalit\u00e4t einer bestimmten Klasse \/ Methode nur anhand ihres Namens zu erraten.  Beispielsweise kann ein Bibliothekssystem erstellt werden loan_records(class) zum borrowers(class)und wenn das Element \u00fcberf\u00e4llig wird, kann es eine make_overdue-Operation f\u00fcr a ausf\u00fchren catalogue(class).  F\u00fcr jede Klasse oder Operation ist die Funktionalit\u00e4t f\u00fcr das gesamte Team offensichtlich.Programmierer Wohlfahrt[edit]Ein einhaltbares Schritttempo[edit]Das Konzept ist, dass Programmierer oder Softwareentwickler nicht mehr als 40 Stunden pro Woche arbeiten sollten, und wenn es eine Woche \u00dcberstunden gibt, sollte die n\u00e4chste Woche nicht mehr \u00dcberstunden beinhalten.  Da es sich bei den Entwicklungszyklen um kurze Zyklen kontinuierlicher Integration handelt und vollst\u00e4ndige Entwicklungszyklen (Release-Zyklen) h\u00e4ufiger sind, folgen die Projekte in XP nicht der typischen Crunch-Zeit, die andere Projekte ben\u00f6tigen (\u00dcberstunden erforderlich).In diesem Konzept ist auch enthalten, dass Menschen am besten und kreativsten arbeiten, wenn sie gut ausgeruht sind.Ein Schl\u00fcsselelement f\u00fcr ein nachhaltiges Tempo ist das h\u00e4ufige Zusammenf\u00fchren von Code und immer ausf\u00fchrbarer und testabgedeckter Code von hoher Qualit\u00e4t.  Die st\u00e4ndige Umgestaltung der Arbeitsweise erzwingt Teammitglieder mit frischen und aufmerksamen K\u00f6pfen.  Die intensive Zusammenarbeit im Team erfordert ein Aufladen \u00fcber die Wochenenden.Gut getesteter, kontinuierlich integrierter, h\u00e4ufig bereitgestellter Code und Umgebungen minimieren auch die H\u00e4ufigkeit unerwarteter Produktionsprobleme und -ausf\u00e4lle sowie die damit verbundenen erforderlichen Nacht- und Wochenendarbeiten au\u00dferhalb der Gesch\u00e4ftszeiten.Siehe auch[edit]Verweise[edit]^ Beck, K. Extreme Programmierung erkl\u00e4rt: Umfassen Sie Ver\u00e4nderungen 2 ..  ed.  Addison-Wesley, 2000, S. 54^ Melnik, Grigori;  Maurer, Frank (2004). Einf\u00fchrung agiler Methoden: Drei Jahre Erfahrung.  Tagungsband der 30. Euromicro-Konferenz.  IEEE.  S. 334\u2013341.  CiteSeerX 10.1.1.296.4732.  doi:10.1109 \/ EURMIC.2004.1333388.^ Leybourn, E. (2013).  F\u00fchrung der agilen Organisation: Ein schlanker Ansatz f\u00fcr die Unternehmensf\u00fchrung.  London: IT Governance Publishing: 146\u2013150.^ Martin, Robert. “Drei Regeln von TDD”.^ Kolawa, Adam;  Huizinga, Dorota (2007). Automatisierte Fehlervermeidung: Best Practices im Software-Management.  Wiley-IEEE Computer Society Press.  p.  75. ISBN 978-0-470-04212-0.^ http:\/\/guzdial.cc.gatech.edu\/squeakbook\/new-lecture-slides\/xp.ppt^ Sedano, Todd;  Ralph, Paul;  P\u00e9raire, C\u00e9cile. “Praxis und Wahrnehmung des Besitzes von Teamcodes”.  ACM.^ Ribeiro, Danilo und Silva, Fabio und Valen\u00e7a, Diana und Freitas, Elyda und Fran\u00e7a, C\u00e9sar.  (2016).  Vor- und Nachteile der Verwendung von Shared Code aus Entwicklersicht: Eine qualitative Studie.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\/wiki10\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki10\/2020\/12\/26\/extreme-programmierpraktiken-wikipedia\/#breadcrumbitem","name":"Extreme Programmierpraktiken – Wikipedia"}}]}]