Letztendlich geht es bei Extreme Programming um eine Reihe von Praktiken und Methoden, die zu einem verbesserten Geschäftswert führen. Das beste Beispiel dafür, das ich gefunden habe, ist von http://c2.com/cgi/wiki?ExtremeProgrammingEnablingChart
Alles in Blau ist Teil der Kerns von XP.
Es gibt Teile davon, die sich außerhalb befinden und dazu beitragen, Dinge innerhalb des blauen Bereichs zu ermöglichen. Sie sind Teil von XP als Ganzes, aber nicht kritisch dafür. Beachten Sie, dass ich persönlich kein XP-Praktiker bin und eine ganze Menge Kritik an Leuten "fast" nach XP gelesen habe, von denen verschiedene Leute gesagt haben, dass sie nicht XP sind. Lassen Sie uns diesen Aspekt des Dogmas von XP ein wenig beiseite legen und uns ansehen, was wir haben.
Erkennen Sie, dass eines der ersten und für die meisten Dinge darin besteht, sich vom Kunden für den Prozess zu engagieren. Eine Schlüsselkomponente von XP ist die Kundenbeteiligung. Dies zeigt sich in einer Reihe von Punkten wie Release-Planung, kleinen Releases und Kundenbewertung außerhalb des Unternehmens. Dies sind Dinge, die Ihre Kunden abonnieren müssen, wenn Sie als Einzelentwickler bei XP erfolgreich sein möchten. Wenn sie stattdessen nach einem Design und dann nach einer Entwicklungsphase und dann nach Tests und dergleichen fragen, haben Sie nicht die Verpflichtung von ihnen, weiter zu gehen.
XP bedeutet keine Planung. Es gibt mehrere Punkte, an denen die Planung Teil ist - Priorisierung, Schätzung der User Story, Iterationsplanung und Aufgabendefinition. Auch wenn Sie ein Entwickler in diesem Bereich sind, müssen Sie bei der Lieferung mit Ihrem Kunden zusammenarbeiten.
Punkte wie das kollektive Eigentum am Code und die Paarprogrammierung betreffen mehr als einen Punkt. Die Entscheidung für Dinge wie Codierungsstandards ist viel einfacher, aber das bedeutet nicht, dass Sie sie nicht befolgen müssen. Das kollektive Code-Eigentum gilt weiterhin - es ist nur so, dass das Eigentum auch der nächste Entwickler ist - schreiben Sie keinen Code, der nur für Sie und Sie bestimmt ist. Beachten Sie, dass dies in gewissem Maße im Widerspruch zum Code steht, der alle Absichten offenbart, die durch die Paarprogrammierung aktiviert werden. Sie müssen nicht überprüfen, ob Sie wartbaren Code schreiben. Daher ist auch die Dokumentation des Codes von entscheidender Bedeutung.
Abgesehen von diesen Einschränkungen gelten immer noch viele der XP-Designprinzipien. Dinge wie Test First Design, kontinuierliche Integration, Besprechungen mit dem Kunden, Refactoring, YAGNI, Spike-Lösungen - diese Anrufe können alleine getätigt werden.
Erkenne, dass Solo-XP genauso viel oder mehr Disziplin erfordern wie normale XP. XP wird oft als hochdisziplinäre Methode angesehen , da die Mitarbeiter die Best Practices, die es zu verkörpern versucht, strikt einhalten müssen. Wenn Sie keinen Trainer oder andere Leute haben, die diese Disziplin unterstützen, kann dies zu einer Ansammlung von Praktiken führen, die etwas Ähnlichkeit mit XP haben.
Verwandte Lektüre:
Ich möchte ein Zitat aus dem ersten der c2-Links herausziehen:
Damian Conway, ein bekannter Perl Language-Star und verrückter Wissenschaftler, glaubt, dass Extreme Programming tatsächlich eine Fehlbezeichnung ist. Da es viele der guten Programmierpraktiken verkörpert, die Programmierern beigebracht werden, aber mit ziemlicher Sicherheit ignorieren, glaubt er, dass es eigentlich Ultra Conservative Programming hätte heißen sollen