Planen vs. Drauflosprogrammieren

[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.

[volkard]

[quote="Anfänger04"]Hallo!
welches der oberen Methoden ist eurer Meinung nach besser und wieso?

keine von beiden varianten gibts in reinkultur. den plan kann man nie bis ins letzte detail ausarbeiten. würde man das, wäre es ja letztendlich doch programmieren, doch wie häte man das geplant?!

und drauflosprogrammieren ganz ohne plan geht auch nicht. bereits beim lesen der aufgabe (oder beim analysieren des problems) macht man sich im kopf ja schon vorstellunen, wie das programm aussehen würde.

[quote]Ich bin eher der Fan von Drauflosprogrammieren. Zwar stoße ich teilweise auf Designfehler die dann nur durch komplettes Neuschreiben rausbekomme aber während des Programmieren kommen mir immer die besten Ideen. [quote]
jo. damit haste den wichtigsten grund gegen zu feines planen. es kann eh nicht klappen. man steigt erst während des programmierens wirklich tief ins problem ein. erst, wenn man tief eingestiegen ist, kann man den perfekten plan machen. für sehr gute ergebnisse muß man einfach bereit sein, alles mal komplett neuzuschreiben.

Ich habe auch schon versucht Projekte im voraus zu Planen und per UML zu visualisiern aber irgentwie komme ich da nie soweit als wenn ich einfach drauflosprogrammiere.

jo. insbesondere uml halte ich als planungsmittel oft für hinderlich. leber "lockerer" planen (und ja nix mit nem programm oder nem lineal veranstalten).

es ist einfach ein zielkonflikt. zu weit planen macht ärger, weil es eh nicht klappen kann. und zu kurz planen macht auch ärger, weil man dann zu viel wegschmeißen muss.
optimalerweise geht der erste plan doch bereits über das ganze projekt, mit so viel weitsicht, wie möglich. aber da kann es langen, zu großen teilprojekten zu sagen "klar, die gui wird schon klappen" und details erstmal zu vertagen. hier liegt ein feiner nervenkitzel drin, genau zu erkennen, was klappen wird und was kritisch werden wird. die kritischen teile muß man dann so früh wie möglich glaubhaft machen. da die kritischen teile typischerweise auch ein wenig komplex sind, heißt das, es muß recht detaillierter plan her. code? kann sein. oder wenigsten ne glaubhafte schnittstelle, wozu alle beteiligten coder sagen "jo, mit der kann ich arbeiten" oder "jo, das kann ich implementieren".
hier wird man leider bereit sein müssen, es auf ein oder zwei versuche ankommen zu lassen. wohlgemerkt, je genauer die kritischen teile rausgefischt wurden, desto weniger muß reimplementiert werden. so 10 oder 20 klassen im kern bereitzustellen, kann hier nötig sein, bevor der große plan glaubhaft ist.
(ich nenne die kritischen sachen mak "kern", da se oft ganz zentrale klassen sind, aber dabei können auch ruhig ein paar gui- oder socket-klassen oder so sein, die ober das wohl des projekts entscheiden. zum beispiel ist sofort festzustelen, ob der zielrechner wirklich 10000 threads für den char-server aufmachen kann, oder ob ganz anders designed werden muss.)
schlimmstenfalls mit zwei anderen, die auch was auf der pfanne haben und mit übernachten im büro. damit sollte eigentlich alles in zwei wochen knackbar sein. es ist leider nicht so, daß man mit 30 leuten hier zehnmal so schnell wäre. ist der große plan dann glaubwürdig, kann man die tore öffnen und beliebg viele leute dran lassen. dann kann man den plan auch umlifizieren, damit die kommunikation reibungsloser ist.
der große plan ist dann korrekt, wenn der kern einfach nicht mehr umgeschmissen werden kann, wenn er einfach klasse ist. die peripherie darf ruhig wackeln, das macht nix. man hat ein stadium erreicht, wo nicht mehr ein detail das projekt kippen kann. und üblicherweise geht sogar die peripherie auf einen rutsch durch.

bei kleinen projekten, wo man nicht horden von mitarbeitern zu verfügung hat, wird man den großen plan alleine machen und das wird für jeden außenstehenden so aussehen, als würde man sofort draufloscoden. ja, man coded ja auch sofort drauf los. daß dieses erste coden sehr zielgerichtet ist, zu garantieren, daß später alles in einem rutsch durchgeht, sieht ja keiner. (und man selber auch nicht, neulich verfocht ich die meinung, man solle ja nicht zu früh planen. hab seither beobachtet und muß die sache differenzierter betrachten. beobachte weiter.) und beobachter sehen auch keinen klaren bruch zwischen der planung und dem ausfüllen, höchstens wundert er sich, warum man auf einmal mittags um 3 sich freut, wie ein schneekönig und ne stunde pause macht, bevor es dann an's ausfüllen geht. statt der pause könnte man auch die paar glaubwürdigen klassen in uml gießen. hat natürlich für wenige leute keinen sinn.
bei großen projekten wird es evtl für außenstehende so aussehen, als würde man einfach nur ne zeit lang planen. sagen wir mal die sklaven können nicht gucken, was man macht. wenn die wichtigsten klassen glaubwürdig sind, gießt man sie in uml und verteilt sie.

üblich ist der versuch, sofort uml rauszubringen. das ist meiner meinung nach ein irrweg. ein paar tage verzug am anfang, um wirklich den besten anfang zu finden, hat man in ein paar doppeltagen wieder drin, weil auch der rest flüssiger läuft. und umkippsicherer wird's allemal, was der hauptgrund für solcherart herangehen ist. irgenwie ist es gar nicht "keine planung und sofort losmachen, sondern ne art auf die spitze getriebener extrem gründlicher planung". irgendiw ist es ne verbindung aus beidem aber liegt nicht "dazwischen". seltsamer gedanke.

mal angenommen, es würde ähnlich leicht fallen, uml zu bauen oder code zu bauen, dann könnte man doch den code hie und da mit details füllen, testläufe machen, gucken, wie lesbar er wird, abschätzen, wie lesbar abhängiger code wird und vieles mehr. das halte ich für wichtigen input, zu wichtig, um darauf verzichten zu können.

[eta]

Wird XP auch noch auf Windows Longhorn funktionieren?

[Artchi]

Wir haben ein Projekt gehabt in dem wir XP angewendet haben. Auch wenn es uns ehrlich gesagt nicht bewusst war, das es sich um XP handelt. Das ganze ging so zwei Jahre und wir haben zu Spitzenzeiten 15 Leute gehabt.

Planung gab es im klassischen Sinne nicht. Wir haben auf Zuruf programmiert. Soll heißen, wenn was benötigt wurde, wurde es implementiert. Das ganze lief so ab: fast täglich ein Meeting. Es wurde gefragt wer was gerade fertig hat. Und dann wurde die nächste Aufgabe (Componente) für diesen einen Tag bestimmt. WIr haben kein Lastenheft oder sowas gehabt, wir haben einfach die nötigen Funktionen auf Zuruf implementiert. Von einem auf den anderen Tag ist jemandem aufgefallen: "Hey, das brauchen wir aber noch!"

natürlich hat man zum Projektstart gewusst, was man haben will... soll heißen, welche Userguppe das Programm benutzen wird. Auch wurden die Benutzer monatlich involviert: was braucht ihr? was gefällt euch besser? Könnt ihr damit leben? Im Grunde war unser Lasten- und Pflichtenheft die Keyuser, die uns einfach angerufen haben und meinten: "Hey, ich brauch da noch ein Eingabefeld, damit ich das eingeben kann. Und dann fehlt noch das." Das ging zwei Jahre so, wir haben nie Klassendiagramme oder sowas gehabt.

Und was soll man sagen? Es hat alles wunderbar funktioniert! Ich war selbst erstaunt, das diese Software läuft, obwohl alle Entwickler zusammen gewürfelt waren und wir nie wussten was uns am nächsten Tag erwartet.

[Gast]

Das mag sicherlich funktionieren, wenn du kooperative User hast. Ich kann mir aber nicht vorstellen, dass du keinen Ärger kriegst, wenn du für einen Endkunden im Auftrag was entwickelst.
Wenn du da kein Pflichtenheft hast, wo drin steht, was du (nicht) tun musst, kann der dir die Hölle heiß machen.

[Artchi]

Selbstverständlich muß da der Kunde mitspielen. Wenn ein Kunde ein Pflichtenheft verlangt, muß man dieses natürlich abliefern. Aber geht es hier um diesen Punkt, was der Kunde will? Nein! Es geht doch hier darum, mit welcher Methode man schon Erfahrung gemacht hat. Und ich habe hier nur gesagt, wie es bei uns ablief. Wohl gemerkt, war das der Kunde, der uns dazu animiert hat, so und nicht anders vorzugehen. Er hat nur gesagt (sinngemäß): "Scheiß auf Papier, ich will morgen erste Ergebnisse sehen! Papier ist unproduktiv!" Yo, und so lief das ab. Natürlich hat der Kunde dann auch wirklich fast täglich was neues sehen wollen! Das ist dann natürlich die andere Seite der Medalie.

Letztendlich ist das entwickelte Software-System ein Vorzeigeprojekt (was die Leistungsfähigkeit angeht) in dem Konzern geworden. Auch wenn viele Leute aus anderen Konzernprojekten immer noch mit dem Kopf schütteln, wie man denn so arbeiten kann. Meiner Meinung nach sind das aber immer nur die, die (nur) Papier produzieren und somit "rausfallen" würden, wenn man in allen Konzernprojekten so arbeiten würde. Diese Situation habe ich in meinem aktuellen Projekt, wo sich (leider) die Papierverfechter einmischen und für unruhe sorgen, weil wir XP wie im oben genannten Projekt betreiben wollen.

[peterchen]

Planen heißt doch nicht, 500g UML/Coder produzieren.

Das erste und beste Planugstool ist dein Kopf (und darauf verlassen sich "losprogrammierer" und XP) -und dort muß der Plan im Endeffekt wieder ankommen.

Nur reicht der Kopf halt nicht immer aus - weil das Projekt zu komplex ist, weil man für drei Projekte gleichzeitig verantworlich ist, oder weil nicht alle Mitarbeiter Überflieger sind.

Das nächste ist Element ist Papier, Bleistift, Radiergummi (Tip: wichtige Zwischenstände kopieren/scannen und archivieren - einige Zettel sehen nach ein paar Monaten oft schrecklich aus)

UML, ERD usw. sind Kommunikationsmittel - Möglichkeiten, die Gedanken in seinem Kopf so auszudrücken, daß sie der andere versteht - genauso wie nicht jeder Arzt einen eigenen Namen für jede Krankheit hat (haben sollte), gibt es einen gängigen Weg, Vererbung auszudrücken.

Wieviel Planung notwendig und sinnvoll ist, hängt vom Team, dem Projekt selbst, der Kundenintegration u.a. ab. Ich würde niemanden losmetern lassen, für den ich verantworlich bin, wenn er mich nicht davon überzeugt, daß er die Aufgabe verstanden und durchdacht hat, und nicht nach zwei Monaten kommt "hier - das geht gar nicht!" (passiert immer noch oft genug). Und wenn jemand eine Aufgabe nicht in 4h-Blöcke runterbrechen kann, hat er garantiert was übersehen.
Andererseits ist es praktisch unmöglich, alle zukünftigen Anforderungen vorauszusehen. An irgendeienr Stelle muß man sich dann doch durchwursteln - verzeihung, extremen. Aber ein guter Plan verträgt das.

Vor kurzen haben wir zu zweit eine Woche fast nur Implementation geplant - was bitter nötig war. Ich möchte keine der Entscheidungen zwischen Tür und Angel treffen müssen, während ich meinen Kopf wo ganz anders hab.

Ein großer Vorteil von XP ist sicher die Flexibilität. Viele Techniken sind auch für ein "klassisch geplantes" Projekt sinnvoll. Mein Gefühl ist aber, daß Projekt von allen Beteiligten vollständig verstanden wird und XP nur mit einem relativ homogenen (bzw. einem zwangshomogenisierten) Team funktionieren kann (Erfahrungen?).

Gegen die "Statik" eines Plans gibt es aber billigere Mittel: den Grund für Design-Entscheidungen aufschreiben. Design-Entscheidungen sind ja nur deshalb unumstößlich, weil sie aufwendig waren, der Guru das so gesagt hat, und niemand diese Diskussionen schon wieder haben will. Wenn dort aber steht "Gonkulator ist final, weil Johannes sonst wieder Scheiß baut" - und Johannes arbeitet gar nicht mehr hier....