DseWiki: ExtremeProgramming/Erfahrungsbericht

Veränderung (letzte Korrektur) (Änderung, Normalansicht)

Verändert: 128c128

:::Allerdings ist es auch ein Erfolgserlebnis, wenn neue Teammitglider ein Konzept verstanden haben und eigene Vorstellungen dazu produktiv umsetzen können. Das geht bei uns z.Zt. so etwa 3-4 Tage. Daher kommt die Woche, ist allerdings kein festes Gesetz. -- mj

:::Allerdings ist es auch ein Erfolgserlebnis, wenn neue Teammitglider ein Konzept verstanden haben und eigene Vorstellungen dazu produktiv umsetzen können. Das geht bei uns z. Zt. so etwa 3 - 4 Tage. Daher kommt die Woche, ist allerdings kein festes Gesetz. -- mj

XP hat mich begeistert, und noch viel mehr seit wir es einsetzen ... Wir verwenden XP zum Entwickeln eines Frameworks für MobileComputing? (UI und Persistenz) mit folgenden Merkmalen:

Die Teamstärke liegt bei c.a. 15 Mann.
die Entwicklung ist nicht als Projekt sondern als stehende Abteilung organisiert.
Extreme Skillverteilung - 7 Mitarbeiter sind erst seit kurzem mit dabei.
Viele Kunden sind vor Ort (Kunde ist in-house).

Da ich XP nicht kritiklos ( siehe ExtremeProgramming/Kritik ) sehe, setzen wir ein modifiziertes XP ein. Folgende Merkmale sind dabei XP konform:

PlanungsSpiel - Unsere Planung stimmt mit XP bis auf die Kärtchen überein.
KurzeReleaseZyklen - mit 2 - 4 wöchigem Zyklus, grosse Releases ca. 3 monatelich.
Simple Implementierung - Das Design skaliert bis zur jeweils maximalen sinnvollen Komplexitätstufe. Die Implementierung wird möglichst einfach gehalten. Der Overhead für das komplexere Design ist in der Implementierung (bis jetzt) minimal.
Komponententest & Akzeptanztest - da sind wir noch in der Einführungsphase, soll aber XP kompatibel werden.
CodeRefactoring - mit Toolunterstützung (IDEA, geplant auch Eclipse).
ProgrammierenInPaaren
FortlaufendeIntegration - nur intern.
NachhaltigesTempo
KundeVorOrt - mit dem Problem dass viele Kunden vor Ort nicht immer das gleiche fordern. Aber direktes Feedback ist vorhanden.
ProgrammierStandards

In folgenden Details sind wir nicht XP konform:

GemeinsameVerantwortlichkeit - Bei uns ist ein Mitarbeiter (oder auch ein Team) Koordinator eines Moduls. Jeder soll und kann alles anfassen, wenn es nötig ist. Aber bei fremden Modulen muss der entsprechende Koordinator vorher benachrichtigt werden. Dieses Vorgehen hat folgende Vorteile:

So können die Moduldetails dezentraler geplant werden (von den jeweiligen Koordinatoren).
Kommunikationsaufwand sinkt
Es kommt nicht vor, dass sich Änderungen an einem Modul wechselseitig wiedersprechen.

Festpreis Fähigkeit ist angestrebt.

Dazu gehört ein verbindlicher Zeitplan (der solange gilt, bis sich die Ziele ändern).
Projektdokumentation nach PM Grundsätzen.
Im Gegensatz zu herkömmlichem PM aber eine flexiblere Lazy-Feinplanung.
Dazu gehört aber auch ein ausgeprägtes Risikomanagement.

Dokumentation ist wichtig - Der Code ist bei uns nicht selbstdokumentierend genug. Zusätzliche (knappe) Dokumentation ist bei uns Pflicht. Dokumentiert wird als JavaDoc und die jeweiligen Konzepte.

Rotation / Teamzusammensetzung ist bei uns von oben gesteuert - Meiner Meinung nach ist selbstorganisierte Teambildung bis jetzt zu konfliktträchtig ... hmmm vielleicht wird das mit dem selbstorganisierten Rotieren ja noch besser, wenn's sich alles erst mal eingespielt hat.

Zusammenfassend bin ich von unserem XP Prozess begeistert.

Die Motivation ist durch Pair-Programming schlagartig gestiegen.
Der KnowHow? Transfer und die Codequalität sind merklich gestiegen.
Erstaunlicherweise ist die Codierleistung durch Pairprogramming zu keinem Zeitpunkt merklich zurrückgegangen. Der ReturnOfValue? findet also nicht erst beim Testen statt :-)
Die Flexibilität der Abteilung ist durch den gehobenen Team- Skill markant gestiegen.
Und noch was, wir Projektleiter haben XP eingeführt um den Planungsaufwand zu reduzieren, damit wir endlich selber wieder zum Codieren kommen :-) Wir sind inzwischen so etwa 50%- 70% unserer Zeit wieder an der Code-Front :-))

Vielen Dank für den sehr interessanten Bericht! -- ip

Diskusion

PlanungsSpiel - Unsere Planung stimmt mit XP bis auf die Kärtchen überein.

: Interessant - warum keine KarteiKarten?
: :-) Weil die Schnittstelle zum Magaement keine Karteikarten beinnhaltet. Das Management bekommt einen Netzplan (Ein Netzplan, der nur 2 Wochen im vorraus konkret geplant ist, entspricht IMHO den Karterikarten noch genug ...).
: Ich frage mich, ob KarteiKarten durch ihre Flexibilität nicht für den Planungsprozess besser geeignet sind und der resultierende Plan dann für das Management in einem NetzPlan? dokumentiert werden könnte. Durch Kombination von Userstories mit "Pfeil-Kärtchen" und einer entsprechenden Unterlage könnte man vielleicht sogar einen sehr dynamischen Netzplan implementieren. Nur so eine Idee - ich weiß jar gar nicht, wie Ihr den NetzPlan? während des PlanungsSpiels momentan realisiert habt. :-)
: Im Augenblick Planen wir mit Tafel und Rechner (Excel Tabelle, MS Projekt, Kärtchen), mit Kärtchen adequatem Inhalt. Bei der Arbeitsmethode bin ich noch etwas unentschlossen, Am liebsten arbeite ich mit Stift und Papier. Aber dann isses halt doppelte Arbeit (zweimal abschreiben) ... Deshalb irgendwie mit dem Rechner - aber da passt die Software nicht. Ich hab gerade angefangen mir dafür was passendes zu stricken. -- mj

Eclipse

: siehe EclipseEntwicklungsUmgebung

KundeVorOrt - mit dem Problem dass viele Kunden vor Ort nicht immer das gleiche fordern. Aber direktes Feedback ist vorhanden.

: Sprechen die Kunden MitEinerStimme?
: Nein, eben nicht ... wenn man gleichzeitig mehrere Kunden hat, ist das ja auch nicht wirklich möglich, oder ?
: Ich bin mir nicht sicher, ob ich mich klar genug ausgedrückt habe - wichtig ist, dass das EntwicklungsTeam? von den Kunden keine widersprüchlichen Informationen bekommt, damit die AufteilungDerVerantwortlichkeiten? gewart bleibt. Falls es in dieser Hinsicht Probleme gibt, gibt es schon ein paar Techniken, um das zu forcieren...
: Ich glaube nicht dass ein Kunde jemals nur eine Stimme haben kann, geschweige denn viele Kunden. Das ist einer meiner grundsätzlicher Kritikpunkte für XP. Aber lass mal deine Techniken höhren, vielleicht hab ich ja unrecht (schön wärs) :-) -- mj

Es kommt nicht vor, dass sich Änderungen an einem Modul wechselseitig wiedersprechen.

: Nach meiner Erfahrung ergibt sich eine ähnliche Organisation in einem XP-Team von ganz alleine, so dass ich keine große Notwendigkeit für eine formelle Regelung sehen würde. Habt Ihr es vorher ohne probiert?
: Wenn es sich sowiso ergibt, warum adressiert XP dann einen so natürlichen Vorgang nicht ?
: Wenn es sich sowieso natürlich ergibt, warum dann noch formal adressieren? :-) Ich stimme Dir allerdings zu, dass es zumindest nicht schaden könnte, das in der XP-Literatur ab und zu zu erwähnen.
: ... egal, wir haben denke ich diese natürliche Ordnung nur explizit anerkannt. Aber du hast recht, ich werd mir überlegen, wie verhindert werden kann, daß diese Reglung zu formell wird.
: Mir persönlich gefällt die Idee von IterationsRetrospektiven, in denen genau solche Dinge - die Erfahrung des Teams mit dem Prozess und die weitere Entwicklung desselbigen - besprochen werden. Siehe http://www.frankwestphal.de/ExtremeProgramming.html
: Die gesamte Beschreibung passt in weiten Teilen verblueffend gut auf unsere Situation, nur Metrik ... na zumindest ist das mein Unwort ... --mj

Projektdokumentation nach PM Grundsätzen.

: Wie kam es zu dieser Entscheidung? was für Art von Dokumentation ist das?
: Das war eine natürliche Entscheidung und wurde bewusst von uns drei XP-Einführern so gewählt ... XP ist ein SW Entwicklungsprozess und adressiert naturgemäss das Management nicht. PM umfasst die ganze Politik aussen rum und dazu braucht man Dokumentation (z.B. Archiv für Zeit-, Personal- und Bugetplanung). Für die Politik benötigt man auch die Planung. Detailiert ausgearbeite Planung ist absolut notwendug um die Projektumgebung (Vorstände, Lenkungs- und Beratungsauschuesse) zu steuern . Zum Glück ist unser Umfeld nicht so politisch und wir können auf einen Grossteil dieser detailierten Planung verzichten :-)

Dokumentation ist Pflicht - Der Code ist bei uns nicht selbstdokumentierend. Zusätzliche (knappe) Dokumentation ist bei uns Pflicht. Dokumentiert wird als JavaDoc und die jeweiligen Konzepte.

: Gilt das für den gesamten Code, oder nur für die veröffentlichte API?
: Das gilt für den gesamten Code. Die Dokument muss so gut (gut heisst nicht zu viel und nicht zuwenig) sein, dass "ich" mich nach 6 Wochen Pause noch problemlos reinfinden kann.
: Mhh, solange das Projekt läuft würde ich die Anforderung insofern abschwächen, dass es möglich sein muss, sich mit Hilfe eines erfahrenen Partners problemlos reinzufinden. Keine Frage, dass es zum Ende eines Projektes sinnvoll sein kann, zusätzliche Energie in Wartungsdokumentation zu stecken.
: Insgesamt scheint es ein häufiges Missverständnis zu sein, dass XPler annähmen, selbstdokumentierender Code würde grundsätzlich für jedes Projekt ausreichen. Die Aussage ist vielmehr, dass im Allgemeinen die wichtigsten Artefakte guter Code, Tests und eine Systemmetapher sind und dass in einem eng zusammenarbeitenden Team vieles direkt kommuniziert werden kann. Jedes Team ist dazu angehalten, zusätzliche Dokumentation zu erstellen, wenn es sie als notwendig erachtet oder der Kunde selbige anfordert.
: Ein Kollege von mir hat mal gesagt "JavaDoc ist so gut, dass sich schon alleine dafuer Java lohnt", so seh ich's auch. Javadoc hilft einfach zur Codenavigation. Unser Projekt ist so gross, ohne Doku kommt da keiner durch. -- mj

Rotation / Teamzusammensetzung ist bei uns von oben gesteuert - Meiner Meinung nach ist selbstorganisierte Teambildung zu konfliktträchtig.

Wissen die Entwickler nicht selber viel besser, mit wem sie gut zusammenarbeiten können oder wen sie gerade brauchen?

Ich hoffe mal wir sind noch nahe genug an der Basis, um diese Wünsche noch mitzukriegen :-) Kurzfristiges umsetzen ist auch diskusionslos möglich, wir geben nur den Defaultfall vor. Bei Selbstorganisation ist die Gefahr gross, dass nicht so beliebte Mitglider ausgegrenzt werden (war ansatzweise schon erkennbar). Durch die von oben bestimmte Teamzusammensetzung ist die Teamauswahl mit weniger persönlicher Tragik verbunden. Im übrigen sind der Prozess und alle zugehörigen Regeln nicht fest, d.h. jederzeit durch Argumente änderbar.

Es wäre bestimmt interessant, zu beobachten ob die Notwendigkeit für eine "Partner-Verordnung" mit der Zeit abnimmt.

Das ist etwas, was ich mir sehr gut vorstellen könnte. -- mj

Wie oft werden bei Eurem Konzept Partner gewechselt?

Default einmal die Woche, kurzfristige Änderungen passieren auch.

Autsch, das wäre nichts für mich... :-)

Ich ziehe es vor, mindestens täglich den Programmier-Partner zu wechseln, wenn möglich häufiger. Nach meiner Erfahrung wirkt sich bereits zweitägiges Wechseln in einem Vierer-Team negativ auf die Kommunikation (und das Team-Gefühl) aus...

Da kann ich jetzt mal nichts dazu sagen, das haben wir noch nie versucht. Aus dem Bauch raus will ich das aber eher nicht machen. Wir haben noch eine sehr inhomogene KnowHow? Verteilung, deshalb ist eine gewisse Einarbeitungszeit nötig. Wir brauchen das Erfolgserlebnis am Ende einer Woche :-) --mj

Das mit dem Erfolgserlebnis sollte kein Problem sein, wenn Ihr Euch an das Schreiben von KomponentenTests gewöhnt habt. Ich bin inzwischen so süchtig danach, dass ich den "grünen Balken" mindestens alle zehn Minuten brauche... ;-)

Dem kann ich nicht widersprechen (... ist JUnit am Ende ein Produktivitätskiller, da die Balkensüchtigen nur noch auf [run] drücken ;-) ?).

Der grüne Balken alleine würde sehr schnell langweilig werden. Das Bewusstsein, dass ich gerade einen wichtigen Test hinzugefügt, die Funktionalität erweitert oder den Code durch Refactoring vereinfacht habe und der Balken immer noch (oder wieder) grün ist - das gibt den ultimativen Kick! :-)

: Wenn das so ist geb ich mich voll und ganz geschlagen ... schliesslich bin ich inzwischen auch infiziert :-))

Allerdings ist es auch ein Erfolgserlebnis, wenn neue Teammitglider ein Konzept verstanden haben und eigene Vorstellungen dazu produktiv umsetzen können. Das geht bei uns z. Zt. so etwa 3 - 4 Tage. Daher kommt die Woche, ist allerdings kein festes Gesetz. -- mj

KategorieXp