Extreme Programming XP beinhaltet alle Aspekte des Abschnitt 7, bietet den Teams darüber hinaus aber weiter differenzierte Methoden für die vier sich bis zur endgültigen Fertigstellung der Software ständig wiederholenden Entwicklungs-Zyklen (Interationen) an:
1. Planung, 2. Design, 3. Programmierung, 4. Test, 1. Planung, 2. Design ....
Siehe auch www.extremeprogramming.org. Dieses etwas merkwürdige, scheinbar uneffektive und aufwändige Prozedere begründet sich aus der Praxiserfahrung heraus: Ein Programmierer trägt täglich nur wenige, dauerhaft und korrekt geschriebene Codezeilen bei. Nicht selten beträgt die Produktivität eines Programmierers gemittelt nur ganz 5! Codezeilen je Arbeitstag. Nichts ist beständiger, als die Veränderung - XP ist ein bewußter Prozess von bewußtem Experimentieren und ständiger Verbesserung des Codes, wobei XP bewährte Methoden liefert, daß automatisch gute Software automatisch entsteht. Während in vielen Programmierer - Teams der innige Wunsch nach fehlerfreier, perfekter Software gepflegt wird, oder wie ein Damokles-Schwert über den Köpfen der Programmierer hängt, so berücksichtigt XP direkt von Anfang an, daß nichts und niemand perfekt ist, und Perfektion nur durch einen kontinuierlichen Verbesserungsprozess (KVP) entstehen kann. Diese neue Denke, bzw. das Bewußtsein in ein Team hinein zu tragen, ist ebenfalls ein Prozess, der nicht von heute auf morgen passiert. Übrigends ist XP exakt die Implementierung / Umsetzung von KAIZEN, einem bei in Japan erfundenem "KVP" (Kontinuierlicher Verbesserungs - Prozess), der zur Sicherung der Qualität im Fertigungsprozess und zur Optimierung der Fertigungs und Managementkosten ( lean production, lean management, lean thinking ) in der japanischen Autoindustrie, aber auch bei Boeing und bei Porsche angewendet wird. Mehr hierzu siehe http://www.little-idiot.de/teambuilding/kaizen.pdf Der Begriff TQM (Total Quality Management, Total=Allumfassend), in Japan geprägt, ist ein umfassendes Konzept, welches sich z.B. auch in der DIN/ISO Norm 8402 wiederfindet.
XP ist ein sehr raffiniertes Kaizen - Konzept, wobei jeder Punkt in den 4 verschiedenen Phasen, die zyklisch immer wieder durchlaufen werden, einen tieferen Hintersinn hat, also implizite Logiken enthält, die nicht direkt durchschaubar sind, weil die Effekte erst in der Dynamik sichtbar werden. Es ist für einen Teammitglied nur schwer zu verstehen, daß Prozesse, bei welchen jedes Teammitglied individuelle Nachteile hat, diese für das Team insgesamt jedoch von Vorteil sind:
1. Planungsphase:
User - Stories: Der Anwender beschreibt, basierend auf dem aktuellsten Zwischenrelease die Dinge, die er weiterhin benötigt, skizziert (anfangs laienhaft) ggf. weitere Arbeitsabläufe, ein verändertes Benutzer - Interface und sonstige Ideen frei auf Papier. Diese dienen immer wieder der weiteren Abschätzung des Projekt - Umfanges, und der Festsetzung der weiteren Entwicklungs-Zyklen.
Die Entwicklungs-Zyklen sind stets so kurz wie möglich zu halten. Software - Releases werden mit ihren Eigenschaften immer wieder aufs Neue beschrieben und dies wird auch schriftlich festgelegt.
Die Geschwindigkeit der Projektentwicklung wird in jedem Entwicklungs-Zyklus erneut abgeschätzt.
Die Entwicklungszyklen werden alle 1-3 Wochen, aufgrund der sich ständig ändernden Anforderungen und Kundenwünsche, wieder und wieder erneut definiert.
Die Planung der Entwicklungs-Zyklen findet immer wieder erneut statt. Hierbei werden ca. 15-20% der Gesamtzeit der Zyklen auf deren Planung verwendet. "Unit testing" und "Refactoring" werden ebenfalls mit eingeplant.
Programmierer werden ständig getauscht (Rotationsprinzip). Dies verhindert einen häufig auftretenden Effekt, daß aufgrund des Ausfalles einer Person im Team die gesamte Entwicklung zum Stillstand kommt. Dies trifft insbesondere auf Projekte mit hoher Komplexität und starker Koppelung der Module zu. Jeder kennt sich dann mit jedem Teil der Software aus und kann ggf. einspringen. Ggf. sollte Pair - Programming, siehe Abschnitt 9, eingesetzt werden, womit dann keine Verzögerungen bei Ausfällen mehr auftreten. Programmierer können flexibel dann dort eingesetzt werden, wo es am meisten brennt. Höchste Priorität hat daher immer die Vermeidung von Wissens-Inseln im Team. Gerade an diesem Punkt gibt es die größten Widerstände, weil - jeder möchte sich unentbehrlich machen - aus Angst vor Jobverlust. Das Gegenteil jedoch ist der Fall: Wer die Denkweise von XP verinnerlicht hat, passt in jedes neue Programmierer-Team ... findet also immer einen Job. Auf flexible und erfahrene Programmierer mag und kann eh niemand verzichten.
Tägliche, kurze Meetings zum Arbeitsbeginn vermeiden längere Teamsitzungen bei Problemen. Die täglichen Aufgaben werden zugeordnet, Arbeitskapazitäten neu aufgeteilt.
XP - Regeln dürfen bei Auftreten von Problemen gebrochen werden. XP ist kein festgelegtes Prozedere, sondern darf, den Anforderungen und den Umständen entsprechend wohl begründet, abgeändert werden.
Einfachheit, KISS - Prinzip (Keep It Simple, Stupid!). Alles und jedes muß einfach durchschaubar sein, gut dokumentiert, dort, wo nötig. Der Hauptaspekt liegt stets auf der Austauschbarkeit des Programmierers. Jeder Programmierer muß sich sofort in der Arbeit eines anderen zurechtfinden können, und nach kurzer Einarbeitungszeit produktiv mitwirken können.
Namen - das Schaffen von Bezeichnern für Code - Abschnitte oder Programmen/Unterprogrammen erleichtert die Kommunikation im Team, siehe auch Abschnitt 12.
CRC - Karten (Class, Responsibilities, Collaboration) dienen dem Design des Systems als Team. Hier sitzen alle Programmierer in einer Runde und halten Karten in der Hand (einer bedient die Mindmap Software am Beamer, siehe Data Beckers MindManager, 49 Euro!, DoxyGen geht aber auch). Jede Karte repräsentiert ein Objekt mit Abhängigkeiten, zu anderen Klassen. Hierbei beginnt jemand in der Gruppe von Programmierern über seine Klassen und Abhängigkeiten zu reden, welches Objekt welche Nachrichten wohin sendet, u.s.w. Je mehr Personen bei diesem Prozess anwesend sind, umso besser. Hierbei werden in kurzer Zeit durch das gemeinschaftliche Denken Schwächen im Design entdeckt und korrigiert. Existieren zuviele Karten und Klassen, so wird die Zahl auf wenige je Person begrenzt.
Bei technischen oder Design - Problemen programmiere ein einfaches Programm, welches das Problem unter Nichtberücksichtigung aller anderen Probleme löst. Da es nur Testzwecken dient, wird es später eh weggeworfen. Das Ziel dieses Vorgehens ist es, das Risiko eines Fehldesigns zu reduzieren, und die Zuverlässigkeit der User - Story zu erhöhen. Wenn das Problem evtl. die Gesamtentwicklung verlangsamen könnte, so sollte Pair Programming eingesetzt werden, wobei zwei separate Entwickler sich eine oder zwei Wochen nur dieses Problems annehmen.
Füge niemals unnötig Funktionalität hinzu. Wir kennen alle das Problem, der Versuchung zu widerstehen, Dinge hinzuzufügen, weil sie das System verbessern würden. Wir müssen uns hierbei dauernd daran erinnern, bzw. selber disziplinieren, nichts zu programmieren, was nicht unbedingt benötigt wird. Wenn nur ca. 10% allen Codes bei XP tatsächlich überlebt, so verschwendet man 90% der Arbeitszeit. Man spart umso mehr Entwicklungszeit ein, je weniger Code für die Lösung der Aufgabe benötigt wird. Das höchste Prinzip, welches hier gilt, sind die "Number of Lines Not Written". Im Design jedoch berücksichtige stets die Möglichkeit, diese Funktionalitäten später hinzufügen zu *können*. Konzentriere Dich auf die morgendlichen Besprechungen und dein Tagespensum.
Refactoring, also der Prozess der dauernden Verbesserung der Code-Struktur muß immer höchste Priorität haben. Code muß einfach in seiner Struktur sein, leicht zu verstehen, zu modifizieren, und zu erweitern. Redundanzen sind aufzulösen, überflüssige Funktionen zu eliminieren, evtl. verworfene Designs können wieder verwendet werden. Jede Funktionalität darf nur einmal im Code vorkommen, doppelte oder ähnliche Funktionalitäten in ähnlichem Code werden zusammengefasst, siehe Abschnitt 6. Der Abschied von seinem eigenen, bevorzugten Design zugunsten des aus Gründen der Praktikabilität durch Refactoring entstandenen, gemeinschaftlich entwickelten Designs fällt immer schwer. Manchmal muß man halt einsehen, daß das Ursprungsdesign ein guter Beginn war, aber nun obsolet ist.
Der Kunde ist immer anwesend - elementarer Bestandteil des XP ist - er ist für die User - Stories verantwortlich, mit welcher die GUI ständig angepasst und verbessert wird - Er allein bestimmt das Aussehen und die Funktionalität der Software. Aufgrund der User Stories wird auch in jedem Entwicklungs-Zyklus immer wieder der Zeit-und Kostenrahmen erneut abgeschätzt. Dies ist insbesondere wichtig, wenn der Kunde neue Funktionalitäten einführen will, dereren Notwendigkeit sich erst im Laufe des Projektes ergeben. Er bestimmt, wie das nächste, funktionierende Release aussehen soll. Er ist auch der einzige, der über Details Auskunft geben kann, die vergessen oder übersehen wurden. Desweiteren wird der Kunde immer bei Funktionalitätstests und Unit-Tests benötigt. Interessant hierbei ist auch, daß direkt erkennbar ist, was Sonderwünsche kosten, und ob hierbei evtl. ein scheinbar "winziges" Feature so aufwändig ist, daß der Etat gesprengt wird.
Es gibt für jede Programmiersprache im Internet sog. "Styleguides", die festlegen, was wie bezeichnet wird, z.B. Pointer..., wie Code formatiert wird, sodaß die Lesbarkeit im Team erleichtert wird. Ziel ist es ja, daß jeder leicht den Code aller im Team lesen und verstehen kann, die Einarbeitungszeit gering wird. Refactoring muß erleichtert werden. Unter dem Stichwort "best practice patterns" finden sich sog. bewährte "Design Patterns", siehe Abschnitt 12.
Unit Tests - Bevor auch nur eine einzige Zeile Code geschrieben wird, ist es unter XP Pflicht, zuerst eine Testroutine zu schreiben, die genau die Erwartung an ein Programm überprüft. Unit Tests für einfache Funktionen, Prozeduren oder Klassen zu schreiben, ist recht einfach. Schwieriger ist dies schon für Datenbankanwendungen, da Testdatensätze definiert werden müssen, noch schwieriger für GUIs mit Ein-und Ausgabe sowie Benutzerinteraktion. Die Ursprungsidee einer Qualitätssicherung hat jedoch noch mehrere positive Nebeneffekte. Sie hilft dem Programmierer, sich bei dem Schreiben des Codes für die Unit sich nur auf das Wesentliche zu konzentrieren, sodaß nur so wenig Code geschrieben wird, wie benötigt wird, damit der Test erfüllt ist. Andererseits zeigt es anderen Teammitgliedern, wie eine Funktion, Prozedur oder Klasse verwendet wird, bzw. wofür diese da ist, ähnlich einem kleinen Programmierbeispiel oder Tutorial, wie man es aus dem Internet kennt. Mehr hierzu siehe Abschnitt 10.
Pair Programming - Jeder Code, der in ein Zwischenrelease oder endgültiges Release (production release) einfließt, wird von zwei Programmierern programmiert, die gemeinsam vor einem Computer sitzen und wechselweise programmieren. Dies ist zu Beginn sehr gewöhnungsbedürftig, jedoch ist das Programmieren überhaupt ein schöpferischer Prozess, in welchem jeder stets seine Ruhepausen zum Nachdenken benötigt. Die Zeit des Nachdenkens darüber, wie nun etwas kodiert wird, sind oft viel länger, als die eigentliche Eingabe. So ähnlich, wie man während eines Gespräches Wortfindungsprobleme hat, hat jeder während des Programmierens auch mal ein "Brett vor dem Kopf". Derjenige, der dem anderen zuschaut, ist erst einmal aus der Verantwortung, kann dem Partner entspannt zuschauen, und sich dabei stressfrei auf den Code konzentrieren, der gerade geschrieben wird. Das Resultat ist, daß die Codequalität sehr viel besser wird, und im Endeffekt viel weniger Refactoring stattfinden muß. Es hat sich herausgestellt, daß Pair - Programming im Endeffekt die Kosten nicht erhöht.
Integration von Code - der Reihe nach, niemals parallel. Das unter sequential integration bekannte Einflechten von Code-Fragmenten in den entgültigen Code (production code) sollte nur wenigen Mitgliedern im Team der Programmierer vorbehalten sein. Gerade dann, wenn von mehreren Entwicklern Code integriert werden soll, stellt man gewöhnlich fest, daß Code - Abhängigkeiten zu veralteten oder überflüssigen Codefragmenten existieren. Die Ursache liegt darin, daß alle Entwickler ja stets nie die neueste Codebasis kennen können, für welche sie Routinen entwickeln. Die hohe Abhängigkeit von Code untereinander, gerade in der frühen Phase der Entwicklung, macht die Sache sehr aufwändig. Je besser die Planung von Anfang an ist, je weniger Änderungen in der Struktur des Codes später stattfinden müssen, umso geringer ist die Wahrscheinlichkeit, daß Code verworfen werden muß, und mit ihm der davon abhängige Code. Schlechte Planung, Organisation und vor allem schlechtes Software - Design führen dazu, daß oft, obwohl die Zahl der Programmierer vergrößert wird, die Entwickung noch mehr stagniert. Änderungen an Klassen, von denen viele andere Klassen abhängig sind, sind z.B. sehr aufwändig. Dies kann die Programmierleistung des Teams insgesamt dramatisch verschlechtern. Häufige Integration und schnelle Veröffentlichung im Team sind daher enorm wichtig. Definitionen von Schnittstellen zwischen Klassen und Reduktion der Codeabhängigkeit durch Schaffung von möglichst vielen, unabhängigen Modulen hat ebenfalls höchste Priorität. Das gesamte Konzept von J2EE / JBOSS basiert auf dieser Erkenntnis.
Gemeinsame Eignerschaft am Code (collective code ownership) bedeutet, daß jeder Programmierer zu jeder Zeit Code anderer Team-Mitglieder korrigieren, verändern, erweitern oder bereinigen darf. Nur so wird verhindert, daß eine Einzelperson zu einer Art Nadelöhr für Veränderungen wird. Oft ist es so, daß eine kleine Verbesserung am Code eines anderen Team-Mitgliedes aufwändige Programmierung eines "Workarounds" im eigenen Code einspart. Es gibt daher bei XP keinen Chef-Designer. Kein Mensch kann bei hochkomplexen Projekten alle Details im Kopf behalten. Außerdem, wenn das Team insgesamt für das Gesamtdesign des Codes verantwortlich ist, sollte jedes Mitglied auch das Recht haben, an jeder Stelle im Code Veränderungen oder Verbesserungen vorzunehmen. Höchste Instanz sind eh die Unit - Tests. Code, der diese Tests nicht erfolgreich durchläuft, darf eh nicht im production code eingeflochten werden. Umfangreiche Änderungen am Design erfordern automatisch Änderungen in den Test - Units, und man kann recht schnell entdecken, welche anderen Codefragmente plötzlich Test - Units nicht mehr bestehen. Da jeder im Team sich im Code anderer Team - Mitglieder auskennt, fällt auch das Ausscheiden eines Teammitgliedes kaum negativ auf. Daß jemand anderes in dem eigenen Code "herumpfuschen" darf, ist zunächst jedem Programmierer höchst zuwieder. Einerseits macht es auch Spaß, einem Kollegen "mal eben" zu zeigen, wie es einfacher oder effektiver geht, und andererseits lernt man selber ja sehr viel dazu. Gerade junge Kollegen sollten diese Art von "Belehrungen" als freundliche Geste auffassen, und sich für die Mühe ihres Kollegen bedanken - "nobody is perfect!". Es wird die Zeit kommen, wo man auch einem "alten Hasen" mal neue Dinge zeigen kann ;-) So kommt auch Spaß am Lernen und somit viel Dynamik in die Bude.
Oft wird auf große Unterschiede bei der Fachkenntnis oder im Niveau der Programmierer im Team hingewiesen. Diese Wahrnehmung mag ja durchaus korrekt sein, jedoch ist hierbei zu bedenken, daß nicht jeder Mensch das große Glück hatte, gute Lehrer gehabt zu haben. Das, was wir sind, unsere Persönlichkeit, unsere Fähigkeiten haben wir nicht schon von Geburt an, sondern wir sind die Summe aller Einflüsse der Eltern, Familie und auch, ab dem Kindesalter beginnend, fremder Menschen in unserem Leben. Unsere Identität ist die Summe aller Erfahrungen im Leben. Leider leben wir in einem Land, in welchem in preußischer Tradition Streitkultur und Demütigungskultur gepflegt wurde. In China hingegen herrscht z.B. eine "Konsenskultur", mehr hierzu siehe auch http://www.little-idiot.de/teambuilding/VonChinaLernen.pdf. Durch die Anwendung von Pair-Programming und ständig neue Paarungen im Team lernen alle in sehr kurzer Zeit noch sehr viel hinzu, sodaß bald ein einheitliches Niveau im Team erreicht ist, wovon alle im Team profitieren, nicht nur fachlich, sondern insbesondere auch emotional. Unerfahrene Programmierer lernen dabei hauptsächlich Fachkenntnisse, die erfahrenen Programmierer lernen, wie man komplizierte Dinge mit einfachen Worten erkärt. Dies ist eine sehr hohe Kunst und stets eine Herausforderung auch für absolute Cracks. Die menschliche Biochemie ist so gestaltet, daß sowohl neue Erkenntnisse im Verstehen einer Tatsache, als auch das erfolgreiche Vermitteln mit Endorphin - Ausschüttung, also Glücksgefühlen "belohnt" wird. Die Arbeit macht dann allen im Team sehr viel mehr Spaß, neue Potentiale werden entdeckt und freigesetzt. Hierbei kann jeder an sich selber beobachten, wie er an seinen Aufgaben im Team nicht nur fachlich, sondern auch von seinen persönlichen, menschlichen Qualitäten wächst. Dies gibt Freude im Leben, schafft Begeisterung, die ansteckend ist.
Optimiere niemals während der Entwicklungsphase. Erst muß Code funktionsfähig sein, später dann können Nadelöhre beseitigt werden. Versuche niemals, zu erraten, wie groß die Verbesserung der Performance sein könnte, sondern messe sie.
Überstunden zerstören den Mannschaftsgeist und die Motivation im Team. Kann ein Termin nicht gehalten werden, so helfen auch keine Überstunden, oder die Vergrößerung des Teams. Die Ursache liegt darin, daß Programmiertätigkeit ein schöpferischer Akt ist, und ein Programmierer sehr viel mehr nachdenkt, als tatsächlich am Computer Code eingibt. Das Gehirn arbeitet hochgradig parallel, es denkt sogar im Schlaf weiter über Probleme nach. Nicht selten kennen wir Menschen die Lösung erst, nachdem wir eine Nacht drüber geschlafen haben. "Operative Hektik ersetzt geistige Windstille" - dieser Spruch besagt, daß man durch Verbreitung von Unruhe im Team die Entwicklung insgesamt nicht beschleunigt, weil die Zahl der Fehler sich stark erhöht. Fehlersuche ist aber sehr viel aufwändiger und anstrengender, als wenn man Zeit und Ruhe hat, vorher genauer nachzudenken, und dann fehlerfrei codiert. Jeder Fehler potenziert sich aufgrund der hohen Abhängigkeiten im Code, gerade in großen Teams. Stattdessen korrigiert man bei den release planning meetings die Zielvorgaben, indem man sehr aufwändige Teile vereinfacht oder wegfallen läßt. XP ist so konzipiert, daß ständig Planung, Design, Codieren und Testen in kleinen Entwicklungs-Zyklen interativ im Wechsel stattfindet. Hierdurch werden frühzeitig unrealistische Ziele erkannt und korrigiert, oder es werden andere Wege gefunden. Oft nämlich ist es einfacher, Arbeitsabläufe zu verändern, als umfangreich Software anzupassen.
Jede Implementierung von Code wird durch Unit Tests geprüft. (Eigentlich ist Unit Testing eine Untermenge des "Test Driven Development = TDD). XP ist extrem abhängig von Unit - Tests. Es gibt für verschiedenste Programmiersprachen ein sog. "unit test framework", mit welchem man automatisierte Test Suites generieren kann. Code, der die Tests nicht erfolgreich durchlaufen hat, darf grundsätzlich nicht verwendet werden. Fehlt ein Test, so ist dieser unverzüglich zu erstellen. Der größte Widerstand gegen saubere Erstellung von Unit Tests ist stets gegen Ende der Entwicklung, kurz vor der Fertigstellung. Hier zu schlampen, wäre ein elementarer Fehler. Ohne vollständige Unit Tests dauert die Fehlersuche oft 100x so lange, wie sie eigentlich müßte, und außerdem muß die Software nach fertigstellung des ersten Release ja auch weiter gewartet werden. UT zahlen sich immer aus, und zwar vielfach gegenüber dem Mehraufwand der Erstellung. Debugger finden nur einfache Programmierfehler, aber keine Logikfehler in den Abläufen bzw. dem Zusammenspiel der Klassen/Objekte. Unit Tests aber prüfen genau dieses Zusammenspiel. Je härter es ist, einen Unit Test zu schreiben, umso mehr wird er auch tatsächlich benötigt, und umso größer wird die Zeitersparnis bei evtl. Fehlersuche sein.. Unit Tests sind noch wichtiger beim Refactoring. Nur so kann sichergestellt werden, daß Änderungen in der Code - Struktur zwecks Lesbarkeit und Wiederverwendbarkeit keine Änderungen in der Funktionalität bewirkt haben. Das frühzeitige Korrigieren von kleinen Fehlern in kurzen Intervallen spart viel mehr Zeit ein, als die Korrektur vieler Fehler kurz vor der Fertigstellung. Fehler potenzieren sich im Code, ebenso, wie der Aufwand ihrer Korrektur.
Wird ein Fehler entdeckt, so muß ein Test sicherstellen, daß dieser nicht noch einmal passiert. Der Unit Test muß dementsprechend angepasst werden.
Akzeptanz - Tests (AT, früher Funktionalitäts - Tests genannt) sind das zweite Standbein von XP. Dies werden aus den user stories heraus geschaffen. Der Kunde beschreibt Szenarios, wie getestet werden soll, damit sichergestellt ist, daß die Funktionalität und Bedienbarkeit genau so ist, wie gewünscht. Jeder AT repräsentiert ein erwartetes Verhalten vom System. Der Kunde ist verantwortlich für Erstellung, Überprüfung und Einhaltung der Anforderungen an das System. Sobald mehrere Akzeptanz - Tests nicht erfolgreich beendet wurden, muß entschieden werden, welcher Tests hohe, und welche niedrige Priorität haben. Eine user story filt als nicht vollständig, wenn diese nicht alle Akzeptanz - Tests bestanden hat. das bedeutet, daß neue Akzeptanz - Tests geschrieben werden müssen, sobald bei einem Entwicklungs - Zyklus kein Fortschritt erzielt wurde. Qualitätssicherung (QA) ist ein wesentlicher Teil des XP Prozesses. Dieser kann durch eine unabhängige Gruppe durchgeführt werden, kann aber auch durch Mitglieder des Entwicklungsteams durchgeführt werden. Die zweite Lösung reduziert natürlich stark den Kommunikationsaufwand, weil Fehler nicht erst analysiert, dann niedergeschrieben und vermittelt werden müssen, sondern direkter Eingriff im Code das Problem dann egalisieren kann. Die Ergebnisse der Akzeptanz - Tests werden allen Team - Mitgliedern regelmäßig bekannt gemacht. Mehr zu Akzeptanz - Tests siehe Abschnitt 11.
Software - Entwicklung im OpenSource - Bereich, also der Linux Kernel, die GNU Toolkits, allen voran der GCC C-Compilier, die grafischen Benutzeroberflächen, der Apache Webserver, tausende von Anwendungswerkzeugen werden allesamt nach den Kriterien von XP entwickelt. Ein kleiner Unterschied jedoch besteht. Die Unit - Tests werden nicht von Programmen durchgeführt, sondern die gigantische Anwendergemeinde von vielen Millionen Usern, darunter viele hunderttausende Neugierige, die sich gerne eine Beta - Version von Linux (Mandrake Cooker, Debian Testing, ...) herunterladen, führen die Tests durch und melden, ob und wann ein Modul nicht funktioniert. Das "Release early" Prinzip der OpenSouce Gemeinde sorgt dafür, daß frühzeitig Fehler bekannt werden. ZopeX3, z.B. verwendet Unit - Testing, siehe Abschnitt 10.
| Zurück | Inhaltsangabe | Weiter |
| Agile Programming | Pair Programming |