Waren

Was ist Extreme Programming (XP)? Auf welchen Werten, Prinzipien und Praktiken basiert es

Programmieren ist Ihnen vertraut, aber Extreme Programming (kurz XP) ist Ihnen noch ein Rätsel.

Lassen Sie sich nicht vom Namen abschrecken, Sie riskieren, nützliche Informationen zu verpassen.

In diesem Artikel behandeln wir alles, was Sie über Extreme Programming wissen müssen, damit Sie es zu Ihrem Vorteil nutzen können.

Was ist Extreme Programming (XP)?

Extreme Programming ist eine Softwareentwicklungsmethodik, die Teil der sogenannten agilen Methoden ist. XP basiert auf Werten, Prinzipien und Praktiken und sein Ziel ist es, kleinen und mittleren Teams zu ermöglichen, qualitativ hochwertige Software zu produzieren und sich an sich ständig ändernde und sich entwickelnde Anforderungen anzupassen.

Was XP von anderen agilen Methoden unterscheidet, ist, dass XP die technischen Aspekte der Softwareentwicklung betont. Extreme Programming beschreibt genau, wie Ingenieure arbeiten, da das Befolgen von Engineering-Praktiken es Teams ermöglicht, qualitativ hochwertigen Code in einem nachhaltigen Tempo zu liefern.

Extreme Programming ist, kurz gesagt, auf die Spitze getriebene bewährte Praktiken. Da Pair Programming gut ist, machen wir es die ganze Zeit. Da das Testen im Voraus gut ist, testen wir, bevor der Produktionscode überhaupt geschrieben wird.

Wie funktioniert Extreme Programming (XP)?

XP basiert im Gegensatz zu anderen Methoden auf Werten und Prinzipien, die in Bezug auf die Ingenieurspraxis wichtig und relevant sind.

Werte geben Teams einen Sinn. Sie fungieren als "Nordstern", um Ihre Entscheidungen auf hohem Niveau zu leiten. Allerdings sind die Werte abstrakt und zu unscharf für eine konkrete Orientierung. Zum Beispiel: Zu sagen, dass Sie Kommunikation schätzen, kann zu vielen verschiedenen Ergebnissen führen.

Praktiken sind gewissermaßen das Gegenteil von Werten. Sie sind konkret und bodenständig, defiFestlegung der Einzelheiten dessen, was zu tun ist. Praktiken helfen Teams, Verantwortung für ihre Werte zu übernehmen. Beispielsweise fördert die Praxis von Informationsarbeitsplätzen eine transparente und einfache Kommunikation.

Prinzipien sind bereichsspezifische Richtlinien, die die Lücke zwischen Praktiken und Werten schließen.

Die Werte von Extreme Programming XP

XP-Werte: Kommunikation, Einfachheit, Feedback, Mut und Respekt. Schauen wir uns jeden von ihnen genauer an.

Werte und Prinzipien des Extreme Programming

Abfassung BlogInnovazione.es des Bildes alexsoft.com

Kommunikation: Mangelnde Kommunikation verhindert, dass Wissen innerhalb eines Teams fließt. Wenn es ein Problem gibt, weiß oft schon jemand, wie man es löst. Mangelnde Kommunikation hindert sie jedoch daran, etwas über das Problem zu erfahren oder zu seiner Lösung beizutragen. Somit wird das Problem am Ende zweimal gelöst, wodurch Abfall entsteht.

Einfachheit: Einfachheit besagt, dass Sie immer danach streben, das Einfachste zu tun, das funktioniert. Es wird oft missverstanden und als die einfachste Sache angesehen, Punkt, wobei der Teil „das funktioniert“ ignoriert wird.

Es ist auch wichtig, sich daran zu erinnern, dass Einfachheit stark kontextabhängig ist. Was für das eine Team einfach ist, ist für das andere komplex und hängt ganz von den Fähigkeiten, Erfahrungen und Kenntnissen jedes Teams ab.

Feedback: Feedback in traditionelleren, kaskadierenden Softwareentwicklungsmethoden ist oft „zu wenig, zu spät“.

XP begrüßt jedoch Veränderungen und XP-Teams streben nach zeitnahem und konstantem Feedback. Wenn eine Kurskorrektur erforderlich ist, möchten XPer dies so schnell wie möglich wissen.

Zyklus der extremen Programmierung

Abfassung BlogInnovazione.es des Bildes alexsoft.com

Feedback gibt es in vielen Formen und Größen. Wenn Sie mit Partnern programmieren, sind Kommentare von Ihrem Kollegen ein wichtiges Feedback. Ebenso die Meinung anderer Teammitglieder zu einer Idee, einschließlich des Kunden, der idealerweise Mitglied des Teams ist.

Tests sind eine weitere Quelle für wertvolles Feedback, das über die Testergebnisse hinausgeht. Ob das Schreiben von Tests einfach oder schwierig ist, Feedback ist es auch. Wenn Sie Probleme beim Schreiben von Tests haben, ist Ihr Projekt wahrscheinlich zu komplex. Hören Sie sich Feedback an und optimieren Sie Ihr Design.

Was nach einer großartigen Idee klingt, funktioniert in der Praxis möglicherweise nicht so gut. Fertiger Code ist also ebenso eine Quelle für Feedback wie ein verteiltes Produkt.

Denken Sie schließlich daran, dass es zu viel Feedback gibt. Wenn ein Team mehr Feedback generiert, als es verarbeiten kann, könnte wichtiges Feedback vom Radar verschwinden. Daher ist es wichtig, langsamer zu werden und herauszufinden, was das übermäßige Feedback verursacht, und es zu beheben.

aufheitern: Kent Beck defiMut erweist sich als „wirksames Handeln angesichts der Angst“. Als Softwareentwickler hat man viel zu befürchten und daher viele Möglichkeiten, Mut zu zeigen.

Es braucht Mut, die Wahrheit zu sagen, besonders die unangenehmen, wie ehrliche Schätzungen. Feedback zu geben und zu erhalten erfordert auch Mut. Und es braucht Mut, um nicht in den Fehlschluss versunkener Kosten zu verfallen und eine fehlgeschlagene Lösung zu verwerfen, in die erhebliche Investitionen investiert wurden.

Respekt: Eine grundlegende Prämisse von XP ist, dass sich jeder um seine Arbeit kümmert. Keine technische Exzellenz kann ein Projekt retten, wenn Sorgfalt und Respekt fehlen.

Jeder Mensch verdient Würde und Respekt, und dazu gehören natürlich auch die Menschen, die an einem Softwareentwicklungsprojekt beteiligt sind. Wenn Sie und Ihre Teammitglieder einander, den Kunden, das Projekt und seine zukünftigen Nutzer respektieren und sich um sie kümmern, profitieren alle davon

Die Prinzipien des Extreme Programming XP

Prinzipien geben konkretere Orientierung als Werte. Sie sind Richtlinien, die die Werte beleuchten und sie expliziter und weniger zweideutig machen.

Abfassung BlogInnovazione.es des Bildes alexsoft.com

Zum Beispiel könntest du allein aufgrund des Wertes von Mut zu dem Schluss kommen, dass es ratsam ist, sofort eine große Änderung in deinem Zeitplan vorzunehmen. Das Baby-Steps-Prinzip sagt uns jedoch, dass große Veränderungen riskant sind. Also lieber die Kleinen.

Menschheit: Menschen erstellen Software für Menschen, eine oft übersehene Tatsache. Aber unter Berücksichtigung menschlicher Grundbedürfnisse, Stärken und Schwächen entstehen Produkte, die Menschen nutzen wollen. Und ein Arbeitsumfeld, das Ihnen die Möglichkeit zu Erfüllung und Wachstum, Zugehörigkeitsgefühl und grundlegender Sicherheit bietet, ist ein Ort, an dem Sie leichter auf die Bedürfnisse anderer eingehen.

Wirtschaft: In XP achten die Teams immer auf die wirtschaftlichen Realitäten der Softwareentwicklung, bewerten ständig wirtschaftliche Risiken und Projektanforderungen.

Beispielsweise würden sie User Stories basierend auf ihrem Geschäftswert und nicht auf technischen Bedenken implementieren.

Gegenseitiger Nutzen: Nach XP vermeiden Sie Lösungen, von denen eine Partei auf Kosten einer anderen profitiert. Beispielsweise können erweiterte Spezifikationen jemand anderem helfen, sie zu verstehen, aber sie lenken Sie von der Implementierung ab und verzögern sie für Ihre Benutzer.

Eine für beide Seiten vorteilhafte Lösung ist die Verwendung automatisierter Akzeptanztests. Erhalten Sie sofortiges Feedback zu Ihrer Implementierung, Ihre Kollegen erhalten genaue Spezifikationen im Code und Benutzer erhalten ihre Funktionen zuerst. Außerdem haben Sie alle ein Sicherheitsnetz gegen Regressionen.

Nutzen (Gegenseitiger Nutzen): Wenn eine bestimmte Lösung auf einer Ebene funktioniert, kann sie auch auf einer höheren oder niedrigeren Ebene funktionieren. Beispielsweise steht bei XP in unterschiedlichem Maße das Einholen von frühzeitigem und konstantem Feedback auf dem Spiel.

  • Auf der Entwicklerebene erhalten Programmierer Feedback zu ihrer Arbeit, indem sie den Test-First-Ansatz verwenden.
  • Auf Teamebene integriert, erstellt und testet die Continuous-Integration-Pipeline mehrmals täglich Code;
  • Organisatorisch ermöglichen die wöchentlichen und vierteljährlichen Zyklen den Teams, Feedback zu erhalten und ihre Arbeit nach Bedarf zu verbessern.

Verbesserung: Nach dem Prinzip der Verbesserung streben Teams nicht nach Perfektion in einer ersten Implementierung, sondern nach einer Implementierung, die gut genug ist, und lernen und verbessern sie dann kontinuierlich mit dem Feedback von echten Benutzern.

Vielfalt: Sie und Ihre Kollegen profitieren von einer Vielfalt an Perspektiven, Fähigkeiten und Einstellungen. Eine solche Vielfalt führt oft zu Konflikten, aber das ist in Ordnung.

Konflikte und Meinungsverschiedenheiten sind Chancen für bessere Ideen, wenn alle nach den Werten Mut und Respekt spielen. Mut, gegensätzliche Standpunkte zu äußern, Respekt, sie zivilisiert und empathisch zu äußern. Und all dies ist eine effektive Kommunikationsübung.

Reflexion: Großartige Teams reflektieren ihre Arbeit und analysieren, wie sie besser werden können. XP bietet dafür viele Möglichkeiten. Nicht nur in seinen wöchentlichen und vierteljährlichen Zyklen, sondern in jeder Praxis, die es fördert.

Gefühle sind neben der logischen Analyse wichtig zu berücksichtigen. Ihr Bauch kann Sie informieren, bevor Sie über irgendetwas nachdenken können. Und so kann er mit Laien sprechen, sie können Fragen stellen, die ganz neue Möglichkeiten eröffnen.

Fließen: Herkömmliche Softwareentwicklungsmethoden haben ausgeprägte Phasen, die lange dauern und wenig Gelegenheit für Feedback und Kurskorrekturen bieten. Stattdessen findet die Softwareentwicklung in XP in Aktivitäten statt, die kontinuierlich stattfinden, in einem beständigen „Wertstrom“.

Gelegenheit: Probleme sind in der Softwareentwicklung unvermeidlich. Allerdings ist jedes Problem eine Chance zur Verbesserung. Lernen Sie, sie so zu betrachten, und Sie kommen viel eher auf kreative und zielgerichtete Lösungen, die auch dazu dienen, sie zu verhindern.

Redundanz: Das Prinzip der Redundanz besagt, dass Sie viele Taktiken anwenden müssen, um dem Problem entgegenzuwirken, wenn es kritisch ist.

Nehmen Sie die Mängel. Es gibt keine einzige Taktik, die verhindern kann, dass alle Fehler der Produktion entgehen.

Die Lösung von XP besteht also darin, eine Reihe von Qualitätsmaßstäben zu stapeln. Paarprogrammierung, Testen, kontinuierliche Integration. Jeder eine einzige Verteidigungslinie, zusammen eine praktisch undurchdringliche Mauer.

Scheitern: Scheitern ist keine Verschwendung, wenn es sich in Wissen umsetzt. Handeln und schnell lernen, was nicht funktioniert, ist viel produktiver als Untätigkeit aufgrund von Unentschlossenheit bei der Auswahl zwischen vielen Optionen.

Qualität: Die Leute denken oft, dass es ein Dilemma zwischen Qualität und Geschwindigkeit gibt.

Es ist umgekehrt: Wenn Sie auf eine Verbesserung der Qualität drängen, werden Sie schneller.

Innovations-Newsletter
Verpassen Sie nicht die wichtigsten Neuigkeiten zum Thema Innovation. Melden Sie sich an, um sie per E-Mail zu erhalten.

Beispielsweise ist Refactoring – das Ändern der Codestruktur, ohne sein Verhalten zu ändern – eine Praxis, die Code leichter verständlich und änderbar macht. Infolgedessen ist es weniger wahrscheinlich, dass Sie Codefehler einführen, wodurch Sie zunächst mehr Wert liefern können, indem Sie keine Fehler beheben müssen.

Kleine Schritte: Große Veränderungen sind riskant. XP mindert dieses Risiko, indem es auf allen Ebenen Änderungen in kleinen Schritten vornimmt.

Programmierer schreiben Code in kleinen Schritten mit testgetriebener Entwicklung. Sie integrieren ihren Code mehrmals täglich in die Mainline, anstatt nur alle paar Wochen oder sogar Monate. Das Projekt selbst vollzieht sich eher in kurzen Zyklen als in lang andauernden Phasen.

Verantwortung übernommen: In XP sollte Verantwortung akzeptiert, niemals zugewiesen werden.

Rechenschaftspflicht sollte mit der Befugnis einhergehen, Entscheidungen darüber zu treffen, wofür Sie verantwortlich sind. Das Gegenteil ist auch wahr. Sie wollen nicht, dass Menschen Entscheidungen treffen, wenn sie nicht mit deren Konsequenzen leben müssen.

Gemeinsamkeiten und Unterschiede zu traditionellen und nicht agilen Methoden

Extreme Programming als agile Methodik kann akzeptiert und begonnen werden, sie zu übernehmen, ohne starren Plänen zu folgen. Dies ist eher ein iteratives Design als ein großes Anfangsprojekt.

XP unterscheidet sich deutlich von traditionellen Methoden, d. h. Kaskadierung, Vermeidung lang andauernder Phasen.

  • Anstelle einer Planungsphase planen Sie in XP zu Beginn jedes Entwicklungszyklus, der normalerweise nur eine Woche dauert.
  • Anstatt Episoden zu testen, testen Sie Ihre Anwendung so früh wie möglich, also bevor der eigentliche Code implementiert wird.
  • Anstatt Features in langen Implementierungsphasen isoliert auszurollen und sich dann mühsam mit der Zusammenführung Ihrer Beiträge zur Mainline zu quälen, arbeiten Sie in kleinen Stücken und integrieren diese so oft wie möglich

Wie unterscheidet sich XP von anderen agilen Methoden?

Extreme Programming hat von Natur aus viel mit anderen agilen Methoden gemeinsam, ist aber auch einzigartig unter ihnen.

Die meisten anderen Entwicklungsmethoden sagen, wenn überhaupt, nicht viel darüber aus, wie man die Arbeit erledigt. XP hingegen ist diesbezüglich sehr eigensinnig und legt großen Wert auf Software-Engineering-Praktiken.

Extreme Programming versus Scrum

Scrum ist ein Framework, das Teams dabei unterstützt, komplexe Projekte auf adaptive Weise zu entwickeln. Scrum schreibt nicht vor, wie Entwickler ihre Arbeit erledigen. Wie bereits erwähnt, legt XP großen Wert auf gute Programmierpraktiken.

Scrum-Framework

Abfassung BlogInnovazione.de Bild Netto-Lösungen

Außerdem geht es bei XP offensichtlich ums Programmieren. Scrum hingegen kann auf jedes Projekt angewendet werden, das von einem iterativen Ansatz profitiert.

XP akzeptiert Änderungen an seinen Komponenten. Teams werden befähigt und sogar ermutigt, Praktiken basierend auf ihren spezifischen Bedürfnissen zu ändern. Der Scrum Guide hingegen beharrt darauf, dass „obwohl nur Teile von Scrum implementiert werden können, das Ergebnis nicht Scrum ist“.

Außerdem ist Scrum ein Framework, das durch Methoden und Praktiken ergänzt werden muss, um die Arbeit zu erledigen.

Das bedeutet, dass die Arbeit in extremer Programmierung und Scrum dringend empfohlen wird.

Rollen und Verantwortlichkeiten

Laut Kent Beck sollte ein ausgereiftes XP-Team keine starren Rollen zuweisen, sondern erkennen, dass Rollen für junge Teams nützlich sein können, bis sie anfangen, langsamer zu werden oder die Zusammenarbeit zu erschweren.

Schauen wir uns einige Schlüsselrollen an:

  • Kunde: Idealerweise sollte der Kunde vor Ort sein, um Fragen zu beantworten, Benutzeranforderungen zu priorisieren oder bei Abnahmetests zu helfen. Wenn dies nicht möglich ist, kann diese Rolle von einem Kundenvertreter ausgefüllt werden.
  • Programmierer: In einem XP-Team schätzen Programmierer den Aufwand, der erforderlich ist, um Aufgaben abzuschließen, automatisierte Tests zu schreiben und Geschichten zu implementieren.
  • Coach: Es ist nicht notwendig, einen Trainer zu haben, und es ist möglich, das Ziel zu erreichen, ohne einen zu haben. Wenn Sie jedoch jemanden mit XP-Erfahrung zum Coachen eines Teams einsetzen, können Sie sicherstellen, dass die Teammitglieder Praktiken befolgen, sie in Gewohnheiten umwandeln und nicht zu alten Gewohnheiten zurückkehren.
  • Tracker- Ein Tracker verfolgt die Fortschrittsmetriken des Teams und spricht mit jedem Teammitglied, um Probleme zu identifizieren und Lösungen zu finden. Der Tracker berechnet Metriken, die anzeigen, wie gut das Team arbeitet, wie z. B. Geschwindigkeits- und Burndown-Diagramme, oder das Team verwendet ein digitales Scrum- oder Kanban-Board, das sie automatisch berechnet.

Methoden und Techniken

Dies sind die in XP übernommenen Praktiken. Sie sind in drei Hauptgruppen unterteilt: Software Engineering, Arbeitsplatz- und Projektmanagement.

Softwareentwicklung

Paar-Programmierung: In XP schreiben Sie Code paarweise auf einer Maschine sitzend. Sie und Ihr Paar sprechen miteinander, während Sie die Funktion, an der Sie arbeiten, analysieren, implementieren und testen. Pair Programming eignet sich besonders gut zum Produzieren von Code mit weniger Fehlern, während es dennoch fesselnd, unterhaltsam und ermüdend ist.

Zehn-Minuten-Limit: Erforderlich Ermöglicht 10 Minuten zum Erstellen des gesamten Projekts, einschließlich der Ausführung aller automatisierten Tests, in maximal zehn Minuten. Diese Grenze dient dazu, das Testen rationell und effektiv zu halten.

Tests vor dem Programmieren: Implementieren Sie Features mit dem Test-First-Ansatz, auch genannt Testgetriebene Entwicklung (TDD). TDD besteht aus der Entwicklung mit einem einfachen iterativen Verfahren:

  • Code schreiben, nachdem ein Test fehlschlägt;
  • schreiben Sie dann Produktionscode, um den Test zu bestehen;
  • Wenn nötig, refaktorisieren Sie Ihren Produktionscode, um ihn sauberer und leichter verständlich zu machen.

TDD bringt mehrere Vorteile mit sich.

Zuerst Feedback. Wenn es schwierig ist, einen Test zu schreiben, ist das Design, nach dem Sie suchen oder das Sie geerbt haben, wahrscheinlich zu komplex und Sie müssen es vereinfachen.

Zweitens ermöglicht TDD Programmierern, dem von ihnen geschriebenen Code zu vertrauen, und erzeugt einen schönen Schleifenrhythmus, bei dem der nächste Schritt immer klar ist.

Last but not least gewährleistet die Verwendung von TDD von Anfang an eine 100-prozentige Codeabdeckung. Die Testsuite wird dann wirklich zu einem Sicherheitsnetz für zukünftige Änderungen, fördert das Code-Refactoring und schafft einen positiven Kreislauf der Qualität.

Inkrementelles Design: Die Praxis des inkrementellen Designs bedeutet, dass Sie jeden Tag in Ihr Anwendungsdesign investieren und nach Möglichkeiten suchen müssen, Doppelungen zu beseitigen und kleine Verbesserungen vorzunehmen, um das bestmögliche Design für die heutigen Anforderungen Ihres Systems zu erreichen.

Kontinuierliche Integration: In XP integrieren Sie Ihre Arbeit mehrmals täglich in das gemeinsam genutzte Haupt-Repository, wodurch ein automatischer Build des gesamten Systems ausgelöst wird. Eine möglichst frühe und häufige Integration reduziert die Integrationskosten drastisch, da Zusammenführungen und logische Konflikte unwahrscheinlicher werden. Es deckt auch Umwelt- und Suchtprobleme auf.

Geteilter Code (kollektives Eigentum): XP fördert gemeinsam genutzten Code oder kollektives Eigentum: Jeder Entwickler ist für den gesamten Code verantwortlich. Es fördert den Informationsaustausch, reduziert den Teambus-Faktor und erhöht die Gesamtqualität jedes Moduls, wenn wir das Prinzip der Vielfalt berücksichtigen.

Einzelne CodeBase: Eine einzelne Codebasis wird auch als „Trunk-basierte Entwicklung“ bezeichnet. Es bedeutet, dass es nur eine Quelle der Wahrheit gibt. Anstatt also lange Zeit isoliert zu entwickeln, führen Sie Ihre Beiträge frühzeitig und häufig in einem einzigen Stream zusammen. Feature-Flags helfen dabei, die Verwendung von Features einzuschränken, bis sie vollständig sind.

Tägliche Verteilung: Der Einsatz in der Produktion mindestens einmal täglich ist eine logische Konsequenz der kontinuierlichen Integration:. Tatsächlich gehen viele Teams heute sogar noch weiter und praktizieren kontinuierliche Implementierung. Das heißt, wann immer jemand der Mainline beitritt, wird die Anwendung in der Produktion bereitgestellt.

Code und Tests: Diese Praxis bedeutet, dass Quellcode, einschließlich Tests, das einzige dauerhafte Artefakt eines Softwareprojekts ist. Die Beteiligung an der Generierung anderer Arten von Artefakten, einschließlich Dokumentation, ist oft verschwenderisch, da es keinen echten Mehrwert für den Kunden schafft.

Wenn Sie andere Artefakte oder Dokumente benötigen, bemühen Sie sich, diese aus Produktionscode und Tests zu generieren.

Ursachenanalyse: Immer wenn ein Fehler in die Produktion geht, beheben Sie den Fehler nicht einfach. Stellen Sie sicher, dass Sie herausfinden, was es überhaupt verursacht hat, warum Sie und Ihre Teamkollegen es nicht geschafft haben, das Schleudern zu verhindern. Ergreifen Sie dann Maßnahmen, um sicherzustellen, dass es nicht wieder vorkommt.

Arbeitsumgebung

Zusammen setzen: In XP arbeiten Teams lieber in einem offenen Raum zusammen. Diese Praxis fördert die Kommunikation und das Zugehörigkeitsgefühl zu einem Team.

Das ganze Team: Jeder, der für den Projekterfolg benötigt wird, ist Teil des XP-Teams. Dies ist sehr kontextabhängig – für jedes Team unterschiedlich – und dynamisch, es kann sich innerhalb eines Teams ändern.

Informationsarbeitsplätze: Ein Informationsarbeitsbereich nutzt den physischen Raum des Teams, um Informationen anzuzeigen, die es jedem ermöglichen, den Fortschritt des Projekts auf einen Blick zu erkennen. Wie dies geschieht, kann variieren, von physischen Notizen und Diagrammen bis hin zu Screenshots, die Kanban-Boards und Dashboards aus Projektmanagement-Software zeigen.

Energiegeladenes Arbeiten: In XP arbeitet man nur so lange, wie man energetisch arbeiten kann. Die Arbeitszeit ist auf maximal 40 Stunden pro Woche zu begrenzen.

Projektmanagement

Analyse- Schreiben Sie Benutzeranforderungen in einem Format, das als Benutzeranalyse bekannt ist. Eine Benutzeranalyse hat einen kurzen, aussagekräftigen Namen und auch eine kurze Beschreibung dessen, was umgesetzt werden soll.

Slack: Fügen Sie bei der Planung eines Zyklus kleinere Aufgaben hinzu, die das Team bei Bedarf aufgeben kann. Weitere Geschichten können immer hinzugefügt werden, wenn das Team zu viel liefert.

Zyklen (monatlich und wöchentlich): Die Entwicklung in XP erfolgt in zwei Hauptzyklen: dem Wochenzyklus und dem Monatszyklus.

Meetings, Zyklen, geplante Veröffentlichungen: Die Entwicklung in XP funktioniert in zwei Hauptzyklen: dem wöchentlichen Zyklus und dem vierteljährlichen Zyklus. Ursprünglich empfahl Kent Beck einen zweiwöchigen Zyklus, änderte dies jedoch in der zweiten Auflage seines Buches.

Wöchentlicher Zyklus: Der Wochenzyklus ist der „Puls“ eines XP-Projekts. Der Zyklus beginnt mit einem Treffen, bei dem der Kunde auswählt, welche Geschichten er während der Woche erstellen möchte. Darüber hinaus überprüft das Team seine Arbeit, einschließlich des Fortschritts der letzten Woche, und denkt über Möglichkeiten zur Verbesserung seines Prozesses nach.

Monatlicher Zyklus: Das Team reflektiert und identifiziert jeden Monat Verbesserungsmöglichkeiten in seinem Prozess. Der Kunde wählt ein oder mehrere Themen für diesen Monat aus, zusammen mit den Analysen in diesen Themen.

Wie fange ich an, mit extremer Programmierung zu arbeiten?
Technische Fähigkeiten und XP-Gewohnheiten können schwer zu erlernen sein. Einige der Praktiken mögen Programmierern, die nicht daran gewöhnt sind, fremd erscheinen.

Ercole Palmeri

Innovations-Newsletter
Verpassen Sie nicht die wichtigsten Neuigkeiten zum Thema Innovation. Melden Sie sich an, um sie per E-Mail zu erhalten.

Aktuelle Artikel

Die britische Kartellbehörde schlägt bei BigTech Alarm wegen GenAI

Die britische CMA hat eine Warnung zum Verhalten von Big Tech auf dem Markt für künstliche Intelligenz herausgegeben. Dort…

18. April 2024

Casa Green: Energierevolution für eine nachhaltige Zukunft in Italien

Das „Green Houses“-Dekret, das von der Europäischen Union zur Verbesserung der Energieeffizienz von Gebäuden erlassen wurde, hat seinen Gesetzgebungsprozess mit… abgeschlossen.

18. April 2024

Laut dem neuen Bericht von Casaleggio Associati steigt der E-Commerce in Italien um 27 %

Der Jahresbericht von Casaleggio Associati über E-Commerce in Italien wird vorgestellt. Bericht mit dem Titel „AI-Commerce: die Grenzen des E-Commerce mit künstlicher Intelligenz“.…

17. April 2024

Geniale Idee: Bandalux präsentiert Airpure®, den Vorhang, der die Luft reinigt

Ergebnis ständiger technologischer Innovation und Engagement für die Umwelt und das Wohlergehen der Menschen. Bandalux präsentiert Airpure®, ein Zelt…

12. April 2024