Totplanen?

[barbier]

tag,

mir kommt es vor, dass es in Mode gekommen ist, it-projekte mit möglichst viel dokumentation&administration aufzublähen (milestones/pflichtenheft/xyz-plan/abc-analyse/blah/blah). natürlich ist planung sinnvoll, aber die ausmaße, die heutzutage üblich zu sein scheint, erscheint mir als einigermaßen übertrieben. ist es denn zielführen, JEDEN EINZELNEN CODESCHRITT in irgendwelchen struktogrammen zu planen? in einem IT-kurs taten es andere auf diese weise (programm in struktogramm planen, danach coden). ich machte einen SEHR groben plan, und codete gleich. die einzelheiten überlegte ich mir on-the-fly im kopf, siehe da: ich war nicht nur als erster fertig, mein code war auch bei weitem der effizienteste.

es kann natürlich auch sein, dass projektleiter es gerne aufgebläht haben, um beim chef eindruck zu schinden (und kompetenz vorzutäuschen ).

was meint ihr?

[Polli]

Will mich ja nicht in die Nesseln setzen aber das gibt es tatsächlich.

Das passiert einem vor allem mit Projektleitern die zwar über eine sehr gute Methoden- und Sozialkompetenz verfügen jedoch absolut keine Fachkompetenz haben.

Da wird dann solange im "meeting" gesessen und "gebrainstormt" bis es wieder ganz viele Teilprojekte gibt die andere erledigen müssen.

Plan hier, Plan da....hier noch ein Ablaufdiagramm....Milestones und wie der ganze Mist noch so heisst.

Aber das schönste ist doch wenn diese sogenannten Fach- und Führungskräfte(Ohne Fachwissen in den Ruin führen ) von Prioritäten setzen sprechen.

Alle 10 min. werden diese Prios wieder umgeändert, quasi konstante Variablen

Chakaaaa bis zum totalen Realitätsverlust!

Und wenn der Betrieb erst mal kurz vor dem Aus ist, dann kommen die alten Hasen, mit Bleistift und Papier und bringen mit Taten den Laden meist wieder ans laufen.

Leider sterben die langsam aus

Aber bitte nicht falsch verstehen, diese Pfeifen gibts wahrscheinlich in jedem grösseren Betrieb aber Gott sei Dank nicht überall.

[Beagol]

Originally posted by barbier

ich machte einen SEHR groben plan, und codete gleich. die einzelheiten überlegte ich mir on-the-fly im kopf, siehe da: ich war nicht nur als erster fertig, mein code war auch bei weitem der effizienteste.

Gut!

*in die Hände klatsch*

jetzt mal kurz auf die Realität bezogen:

"Ich machte einen sehr groben Plan, codetet 2 Monate on the fly und fuhr dann gegen eine Baum"

Und wie gehts weiter für die Firma, die Dich 2 Monate bezahlt hat? Die ist wohl in Schwierigkeiten.

Nein! Es geht nichts über einen vernünftigen Plan. Von Anfang an. Und eine richtige Dokumentation. Nur so ist zu garantieren, dass das Projekt funktioniert.

Ich habe schon Firmen über den Bach gehen sehen, dessen Haus- und Hofprogrammierer sich nach Kuba abgesetzt hat.

Bei Erstellung einer Musikdatenbank über die 50 CD im Wohnzimmer mag das alles nicht sinvoll zu sein. Doch sobald Programmierstunden ins Spiel kommen, die irgendwer bezahlen muss ist es unabdingbar.

Gruss

Dietmar

[bimei]

Originally posted by barbier

was meint ihr?

Das ist pauschal wohl kaum zu beantworten.

Wenn Du etwas verkaufen willst, muss es nachvollziehbar und dokumentiert sein, dazu gehört eben auch bis zu einen gewissen Punkt eine Planung.

[Jaraz]

Originally posted by barbier

in einem IT-kurs taten es andere auf diese weise (programm in struktogramm planen, danach coden).

Ich schätze mal du hast den Sinn des Kurses nicht verstanden.

Originally posted by barbier

ich machte einen SEHR groben plan, und codete gleich. die einzelheiten überlegte ich mir on-the-fly im kopf, siehe da: ich war nicht nur als erster fertig.

Du willst doch nicht wirklich dein "Projektchen" mit Projekten vergeichen, die in den Bereich Mannjahre mit mehreren Mitarbeitern gehen.

Sobald mehrere Entwickler zusammenarbeiten, ist gute Planung unersetzbar. Module, Schnittstellen, GUI, Datenmodel, Aktionen und Persistence, werden alle von unterschiedlichen Personen bearbeitet.

Die müssen koordiniert werden, sonst verläuft das ganze im Chaos.

Wie du dann die einzelnen Funktionen codest, für die nur du zuständig bist und deren Schnittstellen du kennst, ist relativ egal.

Kommentieren und dokumentieren sollte man die trotzdem, da du sonst nach ein paar Wochen selber erst mal wieder schauen musst, wie du das denn nun gelöst hast.

Alles was übergreifend ist, muss vorher unbedingt definiert und modelliert werden.

Originally posted by barbier

mein code war auch bei weitem der effizienteste.

Modularer gut wartbarer Code ist immer deutlich umfangreicher.

Gruß Jaraz

[IJK]

100 Punkte und absolute Zustimmung an Jaraz,

ohne wenn und aber...

LiGrü

Der Prozessmanager

Michael

[Muadibb]

also, ich will auch mal meinen senf dazugeben:

leider redet ihr hier nur über coden

ich als FISI hab aber das gleiche problem gesehen. zum beispiel bei einer Migration von 10000 clients von NT auf 2000. Da kannste mir nicht erzählen, dass man ohne Planung vorankommt. Da kann man sich nich "on-the-fly" überlegen wer als nächster dran ist oder wie ich vorgehe, wenn man einen rechner umzustellen hat. Das muss man schon wissen. Dafür setzt man eben meilensteine. Ich halte sie für sehr wichtig, da man doch so den Ablauf des Projektes besser verfolgen kann. Wenn du ein Teilprojekt bekommst, setzt Du dir ja auch noch eigene Meilensteine: Bis dann und dann hab ich meine Funktion XY fertig. Bis dahin ist Testphase fertig usw.

Ich denke bei der zunehmenden Komplexität von Aufgaben (Projekte), kann man auf Projektmanagement nicht verzichten

[barbier]

Na, also ich sehe ich hab mich nicht ganz richtig ausgedrückt. Natürlich ist eine gewisse Planung notwendig, es wäre irrsinnig, große Projekte ohne Planung anzugehen. Aber ist es denn notwendig, jede einzelne Funktion (und sei sie auch noch so klein) ungeheuer ausführlich zu planen etc.? Wozu brauch ich UML-Diagramme bei einem Bubblesorter

Oder die Kommentarorgien, die mehr Schaden als nutzen. Beispiel:

// Variable i des Typs "int"

int i;


// Zählt den Wert der Variable i von 0 bis 19 in 1erschritten

for (i=0;i<20;++i)

{

  // Wenn Wert OK ist, true zurückgeben

  if (wertIstOk(i)) return true;

}


// Kein Wert OK, false zurückgeben

return false;

Ich meine, es sollte getrennt werden, zwischen gemeinsamen Code (z.B. Kernel, API) und einzelnen Modulen. Der gemeinsame Code muss natürlich ausführlichst geplant und dokumentiert werden. Aber was ist mit den Modulen? Ist das nicht Sache der jeweiligen Zuständigen?

[backdraft]

Hi barbier!

Sicherlich hast du Recht, wenn du sagst, dass dieser ganze Dokumentationskram uns von

dem eigentliche Coden abhält. Aber zur Softwareentwicklung gehört es nunmal genauso

dazu wie z.B. das eigentliche Coden.

Zu deinem Beispiel: Jede Zeile zu dokumentieren ist Schwachsinn! Das Beste ist es immer,

wenn man logische Blöcke wie z.B. Funktionenen und so ausgiebig kommentiert. Was

"ausgiebig" bedeutet kann man sich am besten überlegen, wenn man sich vorstellt, dass

jemand fremdes das Programm verstehen muss, der vorher noch nichts damit gemacht hat.

Es kann ja immer mal sein, dass du bei einem Projekt anfängst und dann aber ein anderes

weitermachst, oder die Frima wechselst. Wenn man dein Programm dann nicht verstehen

kann, da du einfach alles schnell gecodet hast, ist es nahezu unbrauchbar.

Und das kostet richtig Geld.

MfG backdraft

[lpd]

Originally posted by barbier

Aber was ist mit den Modulen? Ist das nicht Sache der jeweiligen Zuständigen?

Ja. Aber auch hier kommt es wieder auf den Umfang an. Das Argument habe ich hier schonmal gelesen; nämlich was ist, wenn der zuständige Entwickler ausfällt und kein Mensch weiß, was er da gemacht hat ? So etwas kann tatsächlich eine Menge Zeit (und damit Geld) kosten.

Deshalb ist eine gute Planung wichtig; nicht nur, um deine Arbeit zu dokumentieren, sondern auch, damit jemand anderes nachvollziehen kann, wie du dir das ganze vorgestellt hast; so dass er ohne großartige Zeitverluste dort weitermachen kann, wo du aufgehört hast.