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

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:

Da ich XP nicht kritiklos ( siehe ExtremeProgramming/Kritik ) sehe, setzen wir ein modifiziertes XP ein. Folgende Merkmale sind dabei XP konform: In folgenden Details sind wir nicht XP konform: Zusammenfassend bin ich von unserem XP Prozess begeistert. Vielen Dank für den sehr interessanten Bericht! -- ip

Diskusion
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

siehe EclipseEntwicklungsUmgebung

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

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

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 :-)

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

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


StartSeite | ExtremeProgramming/ | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 14. Januar 2004 12:13 (diff))
Suchbegriff: gesucht wird
im Titel
im Text