Extreme Programming / Gesamt Überblick
 
StartSeite | ExtremeProgramming/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern

Ein entscheidender Faktor bei ExtremeProgramming ist, dass es die übliche Arbeitsaufteilung nicht gibt. Jeder Programmierer arbeitet mal in einem, mal in einem anderen Bereich des Projekts und führt auch überall Erweiterungen und Änderungen durch. Damit das überhaupt funktionieren kann, muss man nach gemeinsamen ProgrammierStandards arbeiten. Wie diese Standards aussehen, ist nicht so wichtig; es sollen nur Reibungsverlusten durch unterschiedliche Stile vermieden werden. Die Folge dieser Rotation ist, dass jeder das Gesamtprojekt überblickt und dass niemand unersetzlich wird. Das bedeutet auch, dass das Team als ganzes die GemeinsameVerantwortlichkeit für den Code übernimmt. Mehr dazu später.

Der nächste wichtige Punkt ist, dass so rasch als möglich ein funktionierendes Gesamtsystem erstellt wird, auch wenn dieses System rudimentär ist. Es werden KurzeReleaseZyklen geplant (z. B. alle 3 Monate) und diese Termine werden in jedem Fall eingehalten. Das PlanungsSpiel garantiert nicht, dass in dem Release bestimmte Features enthalten sind, aber es garantiert, dass es ein termingerechtes Release mit den bestmöglichen Features gibt. KomponentenTests und AkzeptanzTests garantieren, dass jedes Release praktisch fehlerfrei ist und die Anforderungen des Kunden erfüllt. Ein KundeVorOrt garantiert, dass die "bestmöglichen" Features jene sind, die den meisten Kundennutzen bringen. Mehr dazu später.

Das Gesamtprojekt wird in relativ kleinen Entwicklungsaufgaben gegliedert. Der Arbeitsaufwand soll im Bereich von 3 Tagen bis maximal 3 Wochen liegen, ideal wäre eine Aufgabengröße von etwa einer Woche. Bei entsprechender Aufgabenverteilung garantiert das einerseits die Rotation, andererseits entsteht dadurch erst die Möglichkeit, zu regelmäßigen Releaseterminen jeweils ein abgeschlossenes, arbeitsfähiges Gesamtsystem zu haben, das den gesamten Entwicklungsaufwand enthält und auch zeigt. Mehr dazu später.

Noch nicht erwähnt habe ich, dass keine Überstunden gemacht werden. Ein Entwicklungsteam, das übermüdet am letzten Loch pfeift, kann keine Qualität erzeugen (siehe NachhaltigesTempo). XP garantiert einen kontrollierten Extwicklungsvorgang, bei dem Management und Kunde immer exakt den Projektfortschritt kennen. XP garantiert auch termingerecht ein arbeitsfähiges, fehlerfreies System. Ein Kunde oder Arbeitgeber, der damit nicht zufrieden ist, ist schlecht beraten (meine Umschreibung für "dumm"). Mehr dazu später.

[Ich hoffe ja noch immer, dass mir ein XP-Spezialist den Griffel aus der Hand reißt, mich als XP-Dilettant beschimpft (der ich bin) und mir die Arbeit abnimmt, XP weiter zu beschreiben]

Der erste jetzt wirklich spannende Punkt ist die Art der ZyklenPlanung?. Die Anforderungen werden in Form sogenannter "Geschichten" auf Karteikarten geschrieben. Es wird vom Kunden ein fiktiver Wert geschätzt und von den Entwicklern der Zeitaufwand geschätzt; beides wird auf der Karte eingetragen. Zu große AnforderungsGeschichten werden aufgetrennt, zu kleine AnforderungsGeschichten werden zusammengelegt. Die geschätzten Zeiten sind IdealeTage? (alles läuft wie geschmiert, keine Störungen, keine Meetings, etc.) aber man berücksichtigt über einen Faktor, dass die realen Entwicklungszeiten ca. 3-5 mal länger sind. Dieser Faktor wird am Anfang geschätzt, im Laufe des Projektes gemessen. Man kennt die Arbeitskapazität bis zum nächsten Releasetermin, ein KundeVorOrt bestimmt die Prioritäten, die Entwickler berücksichtigen eventuelle Abhängigkeiten und fertig ist der Arbeitsplan (das ist jetzt wirklich stark verkürzt). Klingt das kompliziert? Mehr dazu später.

Wie wird nun entwickelt? Die Entwickler ProgrammierenInPaaren und optieren für bestimmte AnforderungsGeschichten. Sie schätzen den realen Aufwand (hoffentlich nicht zu weit entfernt von Schätzung*Faktor) als Korrektiv zur Planung. Dann entwickeln sie in besonderer Weise: sie arbeiten gemeinsam wie Pilot und Kopilot, wechselweise an der Tastatur bzw. in "Denkposition". Jedes Implementierungsdetail entsteht *immer* zuerst als Test, der fehlschlagen muss, dann erst als Implementierung. Eine Testumgebung automatisiert die Durchführung dieser Tests, und jede einzelne Programmänderung muss gegen die Sammlung aller Tests (aller Entwickler, in Bezug auf alle bisher realisierten Anforderungsgeschichten) bestehen. EinfachesDesign bedeutet defacto: Man geht immer den einfachstmöglichen Weg. Wenn alle Details einer Anforderungsgeschichte realisert sind, dann kommt die NeuFormierung: Man verbessert die Struktur, solange man Sinn darin sieht. Die Tests sorgen dafür, dass dieser Vorgang risikolos ist. Mehr dazu später.

Ein KundeVorOrt redet ziemlich viel mit. Er schreibt AnforderungsGeschichten. Er setzt ihren fiktiven Wert fest. Er bestimmt wesentlich die Prioritäten. Er muss die Grundstruktur des Projektes verstehen. Damit er dazu eine Chance hat, muss es eine SystemMetapher geben, welche das Projekt so strukturiert, dass auch ein Kunde, der nicht Entwickler ist, damit zurecht kommt. Mehr dazu später.

[An diesem Punkt ist das Meiste, wenn auch nur bruchstückhaft und in Andeutungen gesagt. Was fehlt ist das Fleisch, die Quervernetzungen und die Psychologie dahinter. Der Schweiß tropft von meiner Stirn.]


StartSeite | ExtremeProgramming/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 9. Dezember 2001 18:23 (diff))
Suchbegriff: gesucht wird
im Titel
im Text