http://www.frankwestphal.de/ExtremeProgramming.html)By the way, Ilja: Ich glaube, wir sollten langsam doch damit anfangen, einige der Diskussionen vom XpForum ins persistentere DseWiki zu verschieben. Wie fangen wir damit am besten an?
:Gute Frage. Eine Möglichkeit wäre, Inhalte aus Listen-Mails, die persistenzwürdig erscheinen, in das Wiki zu übertragen und gleichzeitig eine weitere Diskussion auf der entsprechenden Seite anzuregen. Weiß nicht, ob das klappt - wenn nicht, wüsste ich allerdings auch nicht, was besser klappen sollte...
Können wir diese Seite und ExtremeProgramming zusammenbringen, oder ist das zuviel Arbeit? Warum zwei Seiten für die gleiche Sache haben? Und ich kenne wirklichen niemanden, der von der XpMethodologie spricht...
:Mache ich mir auch schon eine ganze Weile Gedanken drüber. Mir ist diese Seite eigentlich auch bereits zu 'schwergewichtig', so dass ich unter ExtremeProgramming gerne einen schlankeren Überblick geben würde. Unter Umständen wäre dann diese Seite - gewissermaßen als ganzheitlichere Betrachtungsweise - durchaus immer noch brauchbar, vielleicht einfach unter anderem Namen.
Es gibt in Deutschland wie in Amerika eine sehr lebendige XP-Gemeinde, und ich hoffe dass Mitglieder dieser Gruppen sich dieser Seiten annehmen und sie entsprechend mit Leben erfüllen. Bis dahin werde ich - um die Inhalte des WikiWikiWeb zu vermitteln - versuchen, einen Überblick über diese interessante SoftwareMethodologie? zu geben. Ich ersuche um entsprechende Korrekturen der Fachleute, wenn ich Unsinn schreibe. -- HelmutLeitner
Die XpMethodologie oder ExtremeProgramming verzichtet auf jede Form von Bürokratie und wird allein dadurch schon dem Entwickler sympathisch. Zwölf Einzelelemente sollen aber auch die Qualität und die Produktivität entscheidend verbessern und damit auch Eigentümer und Kunden glücklich machen:
[[Tabelle][Ausrichtung=zz]
Englisch,Deutsch
PlanningGame,PlanungsSpiel
FrequentReleases,KurzeReleaseZyklen
SystemMetaphor,SystemMetapher
SimpleDesign,EinfachesDesign
RelentlessTesting,KomponentenTests und AkzeptanzTests
RefactorMercilessly,CodeRefactoring
PairProgramming,ProgrammierenInPaaren
CollectiveCodeOwnership,GemeinsameVerantwortlichkeit
ContinuousIntegration,FortlaufendeIntegration
FortyHourWeek,VierzigStundenWoche
OnsiteCustomer,KundeVorOrt
CodingStandards,ProgrammierStandards
]
(siehe auch:
WardsWiki:GermanXpTerminology)Eine Problem bei der Beschreibung von XP hier ist, dass die Amerikaner sehr markante Schlagworte für ihre Praktiken gefunden haben, die sich aber nicht alle leicht übersetzen lassen (bzw. überzeugen mich die teilweise vorhandenen Übersetzungen nicht). Was tun? Nicht übersetzen? Eine XpTerminologieDiskussion führen?
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. 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.]
Vorteile von Extreme Programming:
XP löst das Problem zusätzliche sich ändernder Anforderungen elegant. Der Kunde hat jederzeit das Recht zu Änderungen und Erweiterungen. Er muss nicht schon vorher wissen was er am Ende genau will! Allerdings ist auch institutionalisiert, dass eine Änderung nicht einfach irgendwo "eingeschmuggelt" wird; Sie muss explizit als AnforderungsGeschichte geschrieben werden, unterliegt einer Kostenschätzung und verteuert das Projekt (es sei denn der Kunde verzichtet auf andere Features). Also, wenn das nicht revolutionär ist!
Bei XP wird ständig Aufwand geschätzt, wobei alle Mitarbeiter einbezogen sind. Der Planende schätzt im Konflikt mit dem Kunden und im Konflikt mit dem Programmierer. Der Programmierer ist gezwungen seine Realzeit zu schätzen und einzuhalten. Es gibt ständige Rückkopplungen für alle Beteiligten und zunehmende Erfahrungswerte. Außerdem ergibt sich für jeden Einzelnen die Möglichkeit des messbaren Wettbewerbs innerhalb des Teams, sowohl bei der Schätzung als auch bei der Implementierung.
:Kunde und Programmierer erarbeiten in gemeinsamer Diskussion den Entwicklungsplan, indem der Kunde Anforderungen definiert, die Programmierer deren Realisierungsaufwand schätzen und der Kunde schließlich die Prioritisierung festlegt. Einen außenstehenden 'Planer' gibt es in diesem Sinne dabei nicht.
:Die Programmierer schätzen nicht Realzeit, sondern Idealzeit. Das Verhältnis zwischen Idealzeit und Realzeit wird ständig gemessen und der Entwicklungsplan bezüglich der daraus gewonnenen Erkenntnisse korrigiert. Jedem muss klar sein, dass Schätzungen eben nur Schätzungen sind; die Programmierer gehen lediglich die Verpflichtung ein, den Kunden sofort zu informieren, sollte sich eine Schätzung als falsch herausstellen, damit dieser seine Prioritisierungen anpassen kann.
Die kleinen Arbeitseinheiten und die Rotation lösen das Problem ungerechter Arbeitsverteilung im Projekt. Kein Programmierer kann sich irgendwo als Spezialist auf seinen (ruhigeren) Bereich zurückziehen. Kein Einzelner kann daran Schuld sein, dass sich ein Projekt verzögert. Natürlich gibt es Leistungsunterschiede, die auch im Faktor Realzeit/Idealzeit sichtbar und messbar werden können, aber das beeinträchtigt das Projekt als Ganzes nicht.
:Der Realzeit:Idealzeit-Faktor ist kaum ein sinnvoller Indikator zur Leistungsbewertung, da Idealzeit ein sehr subjektiver Wert ist. Die reine 'Programmierleistung' ist jedoch sowieso kein angemessenes Bewertungskriterium für ein Mitglied eines Projektteams.
:Ein zusätzlicher Anreiz könnte sein, dass der Kunde die Entwicklung zu jedem Zeitpunkt abbrechen kann, und dann ein funktionierendes System bekommt, in dem die von ihm als am wertvollsten eingestuften Features realisiert sind.
XP beinhaltet verschiedene Mechanismen um die Teamperformance zu optimieren. Dazu gehören die verschiedenen Feedbackzyklen von Minuten (Unit Tests, Pair Programming) über Stunden (Continuous Integration) bis zu Wochen und Monaten (Short Releases, Planning Game). Des weiteren zwingen die Praktiken zu intensiver Kommunikation zwischen den Entwicklern (Pair Programming, Collective Ownership), und auch zwischen Entwicklern und Kunden (Planning Game, Functional Testing, Short Releases, On-Site Customer). Und es gibt Praktiken, die die Qualität des Systems und des Codes prioritär einstufen und frühzeitig fördern und unterstützen (Unit Testing, Functional Testing, Coding Standards, Simple Design, Refactoring). Mit dem Planning Game und Short Releases sind sehr effektive Risikomanagement-Strategien implementiert, welche die Chancen eines Scheiterns weiter minimieren helfen. --PeterGassmann
Mögliche Probleme:
* XP ist nur für ein relativ kleines Segment an Softwareprojekten tauglich.
** ProgrammierenInPaaren in Verbindung mit der erforderlichen Rotation führt zu sinnvollen Teamgrößen von ca. 4-10 Personen. Auch die XP Leute selbst halten größere Projekte für nicht sinnvoll.
*** Das C3Projekt hatte ein 15-Mann-Team (richtig?). Bei wesentlich größeren Teams müssen zwangsweise Formalien eingeführt werden, da nicht mehr sinnvoll jeder mit jedem kommunizieren kann.
*** ProgrammierenInPaaren erlaubt durchaus, dass sich lose 'Splittergruppen' bilden, die sich auf ein gewisses Teilgebiet spezialisieren.
** Der Kunde muss bereit sein, eine Person ins Team zu entsenden (relativ hoher Aufwand), d. h. er muss viel Vertauen in XP haben.
::Das ist nicht ganz korrekt. Der Kundenvertreter muss nur seinen Arbeitsplatz beim Team haben, er muss nicht full-time für das Team zur Verfügung stehen. Der Aufwand sollte nicht grösser sein als sonst. Der Vorteil für die Entwickler ist, dass sie sich nur umdrehen müssen um auch auf eine "kleine" Frage eine Antwort zu kriegen. Wenn kein Kundenvertreter vor Ort sitzt (in Rufweite!), fallen viele dieser kleinen Fragen unter den Tisch, da man nicht unbedingt eine Mail schreiben möchte oder gar das Telefon zur Hand nehmen will. Das führt zu einer Häufung von kleinen Fehlern in der Implementation, die dann erst viel später (wenn überhaupt) entdeckt und korrigiert werden.--PeterGassmann
::Es wäre allerdings interessant zu erfahren, wie gut es Kunden gelingt, diese Entscheidungs- und Auskunftskompetenz in einer Person zu konzentrieren. Das ist keine Problem von XP, sondern ein grundsätzliches Problem auf der Kundenseite. --hl
::Häufig geht es weniger um Entscheidungen, sondern mehr um fehlendes Detailwissen. Zum Beispiel in welchem Range ein Wert typischerweise sein kann, wie viele verschiedene Arten es maximal geben kann, etc. Das Problem der Entscheidungskompetenz ist tatsächlich vorhanden, XP hat aber den Vorteil dass das Problem früher explizit sichtbar wird (spätestens beim ersten CommittmentMeeting?)! Damit wird eher eine Lösung dafür gesucht, als wenn es lange unterschwellig bleibt. --PeterGassmann
*** Ein KundeVorOrt verschafft dem Kunden die seltene Möglichkeit, die Entwicklung aus erster Hand zu erfahren und jederzeit einzugreifen. Die durch die äußerst direkte Kommunikation gesparrte Zeit schlägt sich in bares gesparrtes Geld nieder.
** Der Kunde muss mehr daran interessiert sein, eine Software um jeden Preis zu erzeugen, als eine fixierte Leistung um einen Pauschalpreis zu bekommen. D. h. XP eignet sich am besten für (1) Startups (2) "In-House-Corporate-Software".
*** Und für Kunden, denen klar ist, dass bei einem Festpreis zwangsweise die Qualität auf der Strecke bleibt. Und für Kunden, die gerne bekommen möchten, was sie brauchen, nicht das, was die Entwickler denken, verstanden zu haben.
**** Was ich vermutlich sagen wollte ist: in vielen Situationen muss man dem Kunden zusätzlich zur Problemlösung auch noch die Philosophie von XP verkaufen. Dies ist eine mögliche Schwierigkeit im Marketingbereich. Offenbar ist man sich dessen auch bewusst und arbeitet heftig an entsprechendem "hype", um vielleicht aus diesem Nachteil sogar einen Vorteil zu machen.
* XP ist vermutlich nur dort geeignet, wo Personen komplett einem Projekt zugeordnet werden. Eine Aufteilung von Spezialisten, die gleichzeitig für mehrere Projekte tätig sind, scheint nicht praktikabel (wäre für den Kunden nicht transparent).
** Unter welchen Umständen erscheint solche Arbeitsweise denn als praktikabel??? Und inwiefern ist eine Aufteilung bei XP weniger transparent, als ohne???
XP macht Probleme in der Softwareentwicklung deutlich sichtbar, und nennt die Probleme häufig beim Namen. Zum Beispiel die Geschichte mit der Mitarbeit in 5 Projekten gleichzeitig (je 20%) siehe oben. Oder die Geschichte mit verteilter Software-Entwicklung, wo XP ziemlich deutlich sagt dass es keine sehr gute Idee ist. Oder das der Kunde das perfekte Resultat haben möchte, ohne sagen zu müssen wie es aussehen soll... (siehe auch oben).--PeterGassmann
Was ich noch vermisse: XpCoach. --DierkKoenig
siehe auch: XpKritik
Resourcen für diese Seite:
*
WardsWiki:ExtremeProgramming WardsWiki:XpGlossary WardsWiki:XpFaq WardsWiki:XpQuestions*
WardsWiki:GermanXpCommunity WardsWiki:GermanXpTerminologyXpGlossary *
WardsWiki:WhyXpIsPopular*
http://www.jera.com/techinfo/xpfaq.html*
http://www.xprogramming.com/*
http://www.frankwestphal.de/ExtremeProgramming.html*
http://www.extremeprogramming.org*
WardsWiki:WikiPagesAboutTransitioningToExtremeProgramming*
WardsWiki:WikiPagesAboutContinualImprovementBücherlisten:
*
WardsWiki:WhosWritingAboutXpSiehe zum Thema
* Testen:
WardsWiki:CodeUnitTestFirst WardsWiki:TestDrivenProgramming WardsWiki:TestFirstDesign WardsWiki:TestingPatterns* Refactoring:
WardsWiki:WikiPagesAboutRefactoring WardsWiki:XpAndEncapsulation* Psychologie:
WardsWiki:WhenXpIsUnpopular WardsWiki:WhyDoPeopleHateXp WardsWiki:XpAndVisibility* Kritik:
WardsWiki:XpCritiqueHistorisches:
* Ward Cunningham, 1995,
http://c2.com/ppr/episodes.htmlKategorieXp---