Planen vs. Drauflosprogrammieren

[Jester]

Im Planungsspiel wird hauptsächlich ermittelt was in das nächste Release bzw. in die nächste Iteration rein soll. Die Ziele werden in Tasks aufgeteilt und an einen Verantwortlichen gegeben. Eine wirkliche Planung im Sinne der Softwarearchitektur findet höchstens im Rahmen eines stand-up-meetings für die Dauer einer halben Stunde statt oder so. Mehr wird für gewöhnlich nicht geplant. Dafür muß man sich aber an einen Haufen anderer Dinge halten, weil sonst das Refactoring nicht funktioniert.

MfG Jester

[Shade Of Mine]

Jester schrieb:

eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen.

Nein. Du planst nur so wenig wie möglich.
In XP legst du dir keinen großen Plan an, sondern machst nur immer kurze Planungen - um flexibel zu bleiben.

Drauflosprogrammieren widerspricht dem XP Prinzip "Tue das was nötig ist jetzt, aber nicht mehr. Tue alles andere später.". Wie willst du soetwas ohne Planung schaffen?

[Jester]

Shade Of Mine schrieb:

Jester schrieb:

eXtreme Programming basiert genau darauf einfach direkt drauflos zu programmieren, ohne einen genauen Plan zu machen.

Nein.

Nein?

Wieso nein? Man macht keinen genauen Plan. Genau das hab ich geschrieben und Du sagst nein, man macht halt nur keinen genauen Plan.

Man plant die Flexibilität bei XP nicht, sondern vertraut darauf, daß sie sich dadurch ergibt, daß jederzeit Änderungen möglich sind (Refactoring unterstützt durch unit-tests). Dadurch entsteht die Flexibilität an den Stellen, wo sie gebraucht wird und nicht überall. Eben nur dort, wo sie nötig ist.

MfG Jester

[Gregor]

Jester schrieb:

Nein?

Wieso nein? Man macht keinen genauen Plan. Genau das hab ich geschrieben und Du sagst nein, man macht halt nur keinen genauen Plan.

Es wird hier vor allem der erste Teil deiner Aussage "man programmiert direkt drauflos" kritisiert. Die ist nicht richtig. Der zweite Teil mit dem genauen Plan ist Definitionssache und kann durchaus so gesehen werden.

[Jester]

Dann erklät mal, was man Deiner Meinung nach tut. Abgesehen davon geht es hier, wie der Titel sagt um Planen vs. drauflos programmieren. Und XP ist ganz eindeutig bei letzterem einzuordnen. Ich habe das Beispiel auch mehr aus dem Grund gebracht, weil es hier so aussah, als wäre es ohne eine ausführliche Planungsphase garnichts produzieren.

Hast Du schonmal ein Projekt mit XP durchgeführt?

[Gregor]

Shade Of Mine schrieb:

Drauflosprogrammieren widerspricht dem XP Prinzip "Tue das was nötig ist jetzt, aber nicht mehr. Tue alles andere später.". Wie willst du soetwas ohne Planung schaffen?

Vor allem würde mich interessieren, wie man "Write tests first" ohne Plan realisiert.

[Jester]

Das ist ganz einfach. Du überlegst Dir: okay, was muß meine Komponente können, wie soll sie auf was reagieren. Dann schreibst Du dafür einen Test. Anschließend schreibst Du genau ausreichend viel Code, daß sich der Test übersetzen läßt. Dann stellst Du sicher, daß er auch schiefgeht (sonst haste den Test vielleicht vergessen in die Suite reinzuhängen), anschließend arbeitest implementierst Du das ganze so, daß es funktioniert. Dann machste ein Refactoring, weil der Code so unschön geworden ist. Anschließend den nächsten Test etc.
Sollte sich mal etwas nicht gescheit implementieren lassen und ein anderes Design wäre besser gewesen, dann änderst Du das Design einfach (Unit-Tests sei dank einfach möglich) und baust das Feature dann ein. So sieht typische XP-Arbeit aus.

Achja, was Deine Komponente letztlich können muß weißt Du meist aus einer Story die Dir der Kunde geschrieben hat.

MfG Jester

[Gregor]

Jester schrieb:

Das ist ganz einfach. Du überlegst Dir: okay, was muß meine Komponente können, wie soll sie auf was reagieren.

Mit anderen Worten: Du machst dir einen kleinen Plan. Bevor du anfängst zu programmieren, ist die Struktur des Codes klar.

[Shade Of Mine]

Jester schrieb:

Dann erklät mal, was man Deiner Meinung nach tut.

wie würdest du unit tests machen, ohne planung?
abgesehen davon: wenn ein Projekt ein XP Projekt werden soll - ist das bereits eine Planung der vorgehensweise...

[Gregor]

Jester schrieb:

Hast Du schonmal ein Projekt mit XP durchgeführt?

Ja, ein ganz kleines im Rahmen eines Praktikums im Informatik-Grundstudium. Dort wurde, wenn ich mich richtig erinnere am Anfang ein kleines Klassendiagramm erstellt, in dem die Grundstruktur des Programms zu erkennen war. Dieses Klassendiagramm wurde dann später erweitert verfeinert und verändert.

[Jester]

Nein.

Kann es sein, daß Du Dich nicht mit XP beschäftigt hast? Ist wirklich nicht bös gemeint.

Du hast nur die Funktionalität, die Du erfüllen mußt. Damit setzt Du Dich an den Rechner. Den Plan, wie Du das jetzt implementierst machst Du vielleicht im Kopf, aber Du schreibst nichts auf, Du diskutierst nicht lange in einer Gruppe darüber, sondern Du überlegst Dir (ganz kurz aus dem Bauch raus), welche Dienste muß meine Komponente anbieten um das zu leisten was sie soll. Dann suchst Du Dir einen davon raus und schreibst nen Test dafür. Und dann weiter wie oben. Das ganz immer wieder, bis Du fertig bist.

[Gregor]

Ok. Wie stellst du dir das vor? Du willst ein Projekt mit XP realisieren und hast 10 Leute im Team. Wie fängst du an? Mit einem "Dann fangt mal an zu programmieren!"?

[Jester]

Gregor schrieb:

Ok. Wie stellst du dir das vor? Du willst ein Projekt mit XP realisieren und hast 10 Leute im Team. Wie fängst du an? Mit einem "Dann fangt mal an zu programmieren!"?

Tatsächlich habe ich nur 6 Leute im Team. Dafür mache ich das auch wirklich. :p

Natürlich sagt man nicht: "Fang mal an zu programmieren".
Es wird vielleicht überlegt welche Komponenten für den Anfang wohl benötigt werden. Wenn Du natürlich das herausfinden, daß wir eine Fensterklasse brauchen, damit wir die Ergebnisse unserer Anwendung visualisieren können und wir brauchen eine Schnittstelle für den Datenbankzugriff als Planung ansiehst, dann muß ich Dir recht geben.
Die Interfaces der Komponenten werden dann zwischen den Teams, die sie implementieren bzw. Nutzen einfach ausgemacht. Ist ja auch alles kein Problem, man kann's ja anchher schwups wieder ändern.

Es stimmt, daß der Planungsanteil solange noch garnichts da ist höher ist, sobald aber mal irgendwas steht (zum Beispiel zweite Iteration), also schon eine gewisse Codebasis da ist, läuft alles wie oben beschrieben.

MfG Jester

[Gregor]

Jester schrieb:

Natürlich sagt man nicht: "Fang mal an zu programmieren".
Es wird vielleicht überlegt welche Komponenten für den Anfang wohl benötigt werden. Wenn Du natürlich das herausfinden, daß wir eine Fensterklasse brauchen, damit wir die Ergebnisse unserer Anwendung visualisieren können und wir brauchen eine Schnittstelle für den Datenbankzugriff als Planung ansiehst, dann muß ich Dir recht geben.
Die Interfaces der Komponenten werden dann zwischen den Teams, die sie implementieren bzw. Nutzen einfach ausgemacht. Ist ja auch alles kein Problem, man kann's ja anchher schwups wieder ändern.

Ja, das sehe ich als Planung an.

Du hast nur die Funktionalität, die Du erfüllen mußt. Damit setzt Du Dich an den Rechner. Den Plan, wie Du das jetzt implementierst machst Du vielleicht im Kopf, aber Du schreibst nichts auf,

Und was siehst du als Planung an? Nach dieser Äußerung von dir hört sich das ja fast so an, als ob die "Wahl des Algorithmus", "Benennung der Variablen" usw. in den Plan gehören sollte.

Aus meiner Sicht gehört gerade die Spezifizierung der Schnittstellen und die damit einhergehende Grundstruktur des Projekts in die Planung.

[Jester]

Eine Planung beinhaltet meist mehr als das was nötig ist um die aktuelle Aufgabe zu erledigen. Es werden Design-Patterns aufgefahren und Assoziationen zwischen Klassen definiert. etc.
Wer wohl was alles kennen müßte, wie man das Feature, was später vielleicht mal reinmüßte schonmal vorsehen kann und so weiter. Wenn ich ein Bankkonto implementieren will und ich weiß, es wird später mal Juniorkonten geben, dann sehe ich das in meinem Plan vor. In XP nicht, wenn es nicht die aktuelle Aufgabe ist Juniorkonten zu bauen. Dann implementiere ich, als gäbe es die garnicht und füge sie erst später hinzu, indem ich die eine Klasse zur Basis mache und zwei neue erstelle die davon erben.
Hier wird einfach das getan, was nötig ist und sonst nichts. Wird mehr nötig, so ist man nicht traurig, weil's nicht im Plan stand, sondern ändert das einfach. Da es keine Planungsdokumente gibt können sie auch nicht veralten, so einfach ist das.

Die Spezifizierung der Schnittstellen wird nur so weit nötig gemacht. Nicht weiter. Da man zumeist eh weit genug unten im System anfängt können auch leicht mehrere Sachen unabhängig voneinander entwickelt werden, sodaß keinerlei Schnittstellenspezifikation nötig ist.

MfG Jester

[macpogo]

habt ihr vielleicht ein paar Links oder Buchtips zu XP?
würde mich nämlich auch interessieren

[google extreme]

Suchen kannst du auch selbst.

[fischauge]

macpogo schrieb:

habt ihr vielleicht ein paar Links oder Buchtips zu XP?
würde mich nämlich auch interessieren

Xtreme Programming (Addison Wesley) Naja,...

Allgemeines zu: Project/Risiko-Management...
DeMarco/Lister : Bärentango (kann ich dir nur wärmstens ans Herz legen)

Die anderen Bücher von denen sind auch gut....

[Jester]

Shade Of Mine schrieb:

wie würdest du unit tests machen, ohne planung?

Indem ich sie einfach Test für Test niederschreibe?

Shade Of Mine schrieb:

abgesehen davon: wenn ein Projekt ein XP Projekt werden soll - ist das bereits eine Planung der vorgehensweise...

Richtig, aber das ist wohl eher organisatorische Planung.
Wenn ich mir überlege, ob ich morgen mit dem Auto oder mit der Bahn zur Arbeit fahre ist das auch Planung, aber deswegen heißt das noch lange nicht, daß ich mein Projekt plane.

XP heißt ja nicht, wir verzichten einfach auf jegliche Planung, sondern man verzichtet sozusagen auf die Entwurfsphase. Um das zu kompensieren wird ein ganzer Satz von Techniken aufgefahren um das Design nachher noch gerade biegen zu können.

@Gregor:
Möglicherweise gibt es da auch unterschiedliche Vorgehensweisen?
Bei uns gibt es keinerlei Vorplanungsphase in dem Sinne, das UML-Diagramme gezeichnet werden. Das passiert dann halt an der Stelle, wo man noch nicht einfach losprogrammieren kann. Wo man anfangen kann fängt man einfach an.

[Helium]

XP fordert aber keinesweges eine Testdriven-Design. Ich kann auch wunderbar erst implementieren und erst dann Tests entwickeln. Sie sollten nur möglichst vor der nächsten Iteration fertig sein.

Was Jester über die Planung sagen will: Sie ist deutlich abstrakter, als sonst üblich. Du hast keine Ahnung, was existieren wird. Dein "Plan" entsteht ganz grob in der Besprechung und etwas genauer kurz vor dem Umsetzen, zum Großen Teil aber erst werden des Umsetzens.

Natürlich laufen Iterationen auch nicht geplant ab. Das hört sich möglicherweise so an, als ob immer in regelmäßigen Abständen eine Überarbeitung durchgeführt wird. Das ist natürlich nicht so.

Alles, was beim letzten Projekt vorhanden war, war ein Bild des Datenbankmodells.