Richtige Planung für ein Projekt

[PaddyVII]

Hallöchen alle zusammen,

Ich hab da mal ne frage und sie einfach hier gestellt, weil ich nicht sicher war, wo sonst:

Wie geht ihr an die Richtige Planung von einem Projekt ran? Ich mach immer schnell-schnell und programmier drauf los und später steck ich fest und weiß nicht weiter was häufig echt deprimierend ist, weil einfach Planung fehlt. Jedoch weiß ich überhaupt nicht, wie soo eine ordentliche Vorbereitung/Plaung aussieht. Ich bin noch (relativ) am Anfang und wollte einfach mal fragen ob jemand Tipps für mich hat, wie ich denn eine Genaue Struktur/ Plan bekomme bzw. ein Programm richtig plane (Strunktogramme inbegriffen)


An die erfahrenen Programmierer - wie bereitet ihr euch auf ein Projekt vor??


und die Anfänger - habt ihr die selben Probleme wie ich?? Wie plant ihr??


Über Rückmeldung (gerne auch per pn) würde ich mich wirklich sehr freuen

LG und schönen nachmittag noch

Paddy_VII

[generic]

In vielen meiner Projekte wird Scrum genutzt.
http://de.wikipedia.org/wiki/Scrum

[jobo]

Die Frage ist recht pauschal und liefert kaum einen Hintergrund oder etwas zu Deinem Arbeitsumfeld.
Bist Du Angestellter im Team, Einzelkämpfer, Student?
Was programmierst Du?
Scrum bspw. nutze ich auch, allerdings eben im Team. (Auch wenn man das sicher für sich allein eindampfen kann)

Papier und Bleistift wird hier schon mal gern empfohlen.
Eine Form von Analyse sollte sicher irgendwie am Anfang stehen.
Man könnte auch unterscheiden, ob etwas total neues entwickelt wird oder der 7. Aufguß eines bekannten Vorgehens durchgenudelt werden soll/kann/muss.

Ich meine, zu solchen Fragen müsste auch die Suche hier im Portal einige brauchbare Antworten liefern.

[Namenloser]

Zitat von PaddyVII:

Wie geht ihr an die Richtige Planung von einem Projekt ran? Ich mach immer schnell-schnell und programmier drauf los

Das ist letztendlich das, was bei mir auch immer noch am besten funktioniert (natürlich nicht ganz ohne System). Ich hatte mal vor vielen Jahren mal so eine Phase, wo ich versucht hatte, meine Programme zu Anfang komplett top-down durchzuplanen. Hat überhaupt nicht funktioniert. Erstens kommt man überhaupt nicht voran, zweitens stellt sich der Entwurf im Nachhinein meistens als verkorkst heraus, und dann ist es schon zu spät.

Inzwischen ist es mein Ziel, so zu entwickeln, dass ich immer möglichst schnell etwas lauffähiges habe. Wenn das Programm z.B. 10 Dinge können soll, dann schreibe ich es erst mal so, dass es nur eins davon kann. Und das wird auf dem einfachstmöglichen Wege umgesetzt (KISS). Die anderen 9 Dinge berücksichtige ich dabei noch gar nicht. Wenn das erste Ding dann läuft, schaue ich, wie ich von dort so einfach wie möglich zum zweiten Ding komme. So geht es immer weiter. Wenn ich zwischendurch das Gefühl habe, dass der Code zu hässlich wird, wird er refaktorisiert. Wann das angebracht ist, dafür muss man mit der Zeit halt ein Gefühl entwickeln.

Ein Fehler, den ich am Anfang immer gemacht habe, war, dass ich versucht habe, Code von Anfang an so allgemeingültig und flexibel wie möglich zu halten. Der Gedanke war natürlich, dass ich so später leicht Funktionen nachrüsten oder ändern könnte. Was ich dabei aber übersehen habe, ist, dass Flexibilität nicht unbedingt darin besteht, dass man durch Indirektion und Abstraktion so viele Stellschrauben wie möglich hat, sondern dass es in der Praxis oft flexibler ist, Code ohne Stellschrauben zu haben, den man bei Bedarf dafür leicht umschreiben kann.

Das ist nun der Maßstab geworden, nach dem ich meinen Code entwickle: Ich denke mir beim Schreiben schon, dass keine der Zeilen, die ich schreibe, endgültig sein wird. Ich versuche daher meinen Code so aufzubauen, dass er später möglichst leicht verändert werden kann.

Außerdem bin ich ein Freund von testgetriebener Entwicklung. Die führt eigentlich automatisch zu dieser Vorgehensweise, und ist zudem recht motivierend, weil man durch bestandene Tests recht schnell Fortschritte sieht, selbst wenn man noch kein lauffähiges Programm hat. Außerdem ist man gezwungen, Unit-Tests zu schreiben, wozu einem sonst im Nachhinein oft die Motivation fehlt. Die Unit-Tests helfen nicht nur dabei, Fehler überhaupt erst mal zu bemerken, sondern auch dabei, die Ursache zu finden. Beim Debugging ist es sehr hilfreich, einen immer gleichen, deterministischen Ablauf mit wenig Seiteneffekten zu haben.

Disclaimer: Mein Text bezieht sich mehr auf den Fall, dass man alleine arbeitet. Im Team sind die Bedingungen teilweise andere. Da ist es zum Beispiel nicht so gut möglich, mal eben Code komplett umzuschreiben. Habe da aber selber noch nicht so viele Erfahrungen gesammelt.

[Uwe Raabe]

Zitat von Namenloser:

Wenn das Programm z.B. 10 Dinge können soll, dann schreibe ich es erst mal so, dass es nur eins davon kann. Und das wird auf dem einfachstmöglichen Wege umgesetzt (KISS). Die anderen 9 Dinge berücksichtige ich dabei noch gar nicht.

Elephant Carpaccio

[swkevin08]

Wenn man sich mit Softwareentwicklung beschäftigt wird man, gerade als Anfänger, auf das Wasserfallmodell stoßen.
http://de.wikipedia.org/wiki/Wasserfallmodell

Um ein grobes Verständnis von Softwareentwicklung zu bekommen genügt das.

[mensch72]

Zitat von swkevin08:

Wenn man sich mit Softwareentwicklung beschäftigt wird man, gerade als Anfänger, auf das Wasserfallmodell stoßen.
http://de.wikipedia.org/wiki/Wasserfallmodell

Um ein grobes Verständnis von Softwareentwicklung zu bekommen genügt das.

Nun ja... das "Wasserfallmodell" kommt nach meiner praktischen Erfahrung real eher nur noch noch ganz unten bei Großprojekten zum Einsatz...

Für echte kleine Kundenprojekte wo es keinen Softwarearchitekten als Planer gibt, also der Kunde seine Anforderungen als Vorgabe gibt, da läuft es fast immer so:
http://de.wikipedia.org/wiki/Extreme_Programming

Wie ein Projekt läuft, hängt auch stark vom existierendem Hintergrund ab. Wenn Kunde B nur ein SubSet der Funktionalität einer lösung will, die man für Kunde A schon vor Jahren realisiert hat, dann kommt es durchaus vor, das man 60% des Codes ungenutzt lässt und nur die gewüschte Sollfunktion in per GUI/Schnittstelle realisiert.

Bei völligem Neuland und "10" Anforderungen, kann man schon Meilensteine definieren und diese einzeln realisieren. Wenn man sich selbst und erst recht im Team von Anfang an 100% gekapselte autonome Module/Schichten hält, kann man auch später mit vertretbarem Aufwand mal eine komplette Schicht austauschen oder neu schreiben. Da es eh keine perfekte Software gibt, realisiere ich lieber zeitnah funktionierende Software, deren sinnvolle strukturelle Grenzen ich kenne.

[swkevin08]

Zitat:

Nun ja... das "Wasserfallmodell" kommt nach meiner praktischen Erfahrung real eher nur noch noch ganz unten bei Großprojekten zum Einsatz...

Stimme ich Ihnen vollkommen zu! Aber für den Anfang kann und wird es nicht Schaden sich mit diesem auseinander zu setzen.
- Das ist wie wenn man einen Sortieralgorithmus lernt. Man starten fast immer mit Bubblesort -
Mir hat es viel gebracht, gerade was die Dokumentation angeht oder die Erkenntnis, dass sich der Entwurf und Anforderungen ständig ändern kann und somit viel Aufwand entsteht.

Zu Großprojekten habe ich keine Erfahrung, würde hier aber auch auf Scrum zurückgreifen.

[Bernhard Geyer]

Zitat von swkevin08:

Zitat:

Nun ja... das "Wasserfallmodell" kommt nach meiner praktischen Erfahrung real eher nur noch noch ganz unten bei Großprojekten zum Einsatz...

Stimme ich Ihnen vollkommen zu! Aber für den Anfang kann und wird es nicht Schaden sich mit diesem auseinander zu setzen.

Vor allem wenn man erklären will das viele SW-Probleme genau mit diesem Modell zu tun haben. Dann ist es gut wenn der lernende Praktische Erfahrungen mit diesem Modell hat.

Zitat von swkevin08:

Zu Großprojekten habe ich keine Erfahrung, würde hier aber auch auf Scrum zurückgreifen.

Wenns der (große) Auftraggeber mitmacht. Und man sollte die erhöhten Aufwendungen im Bereich Projektmanagement nicht unterschätzen.

[Thomas_K]

Ich werfe auch noch mal ein Wikipedia Link ein http://de.wikipedia.org/wiki/Softwaretechnik. Da kann man sich erstmal einen Überblick über alle Facetten der Software Entwicklung verschaffen.

Wirklich wichtig ist wie bei so vielen Dingen der erste Schritt und da sollte in wenigen Sätzen aufschreiben, was die Software denn erledigen soll. So dass man in ein, zwei Tagen, Wochen, Monaten noch weiß, auf was es denn Ankommt bzw. auf welches Ziel man steuern muss.