Wie werden (grössere) Projekte geplant?
-
hibbes, du sprichst mir aus der Seele - habe gerade auch mehrere Projekte dieser Art...
-
Hey Th69, gut zu wissen dass es nicht nur mir so ging.
Was zu dem ganzen Planungsvakuum noch hinzukommen kann sind Mitarbeiter die sooo groß den Mund aufmachen, aber selbst kaum Ahnung von ihrer Arbeit haben und auch nicht bereit sind mal selbst was auszuprobieren. Oder noch schlimmer Leute in Anzügen die irgendwann mal studiert haben, dann aber abgebrochen haben um das große Geld zu machen(ja ne is klar, sagt doch gleich ich war zu blöd zum Rechnen) aber meinen ihre gesammelten Fachausdrücke aus irgendwelchen Buzzwordlexikas wie aus einem Maschinengewehr auf den Kunden abschießen zu müssen und DU musst dass dann alles so umsetzen. Natürlich verdienen sie das dreifache und haben aber nicht halb soviel Ahnung wie du. Damit meine ich nicht deinen Fachbereich, sondern die Sachen die einen Berater und/oder Projektleiter ausmachen sollten. Sozialkompetenz wird anscheinend auch recht zufällig und sparsam auf die Menschen verteilt die dann mal Führungspositionen ausüben wollen.
Naja egal, ausbaden musst du das dann und das für ein Drittel des Gehaltes und mit einem minimum an Freizeit ohne Handy vibrieren. Habe ich erwähnt das ich BlackBerry mit Exchangeanbindung hasse?
Ok ich hör jetzt auf hier. Das ist für mich erstmal History und mein Tinnitus wird auch langsam ertragbarer und ich habe gelernt mehr an mich zu denken. Ich habe zwar weniger Geld jetzt, aber mehr als ein Rechner ein paar Fachbücher und das Netz brauche ich nicht an Luxus und meine Familie sieht mich auch wieder entspannter.
Nichts ist so wertvoll wie die Zeit die wir mit unseren Lieben verbringen können, dass ist der wahre Luxus im Leben.
-
*räusper*
wir schweifen ab
ihr beschreibt mir da eure arbeit bei irgendwelchen firmen und nicht die vorgehensweise beim software designjungs (und mädels), passt auf, ich bin grad aus der schule raus, bald wartet die FH auf mich, ich programmiere zum spass, aber ich möchte mehr können...
directx, opengl, winapi usw. kann man sich anhand von ein paar büchern und paar websites gut selber aneignen, aber WIE PLANT MAN?wie fängt man ein projekt an?
was sind module?
schnittstellen sind für mich header dateien, oder liege ich da falsch (bzw in adneren sprachen sowas ähnliches wie header dateien)
-
Also ich habe zwar bei größeren Projekten noch keine Erfahrung, aber unser Informatiklehrer wollte uns dazu verdonnern, vor jedem Programm ein UML Diagramm anzulegen. Das mussten wir dann machen, doch zum Schluss habe ich einfach das Programm geschrieben und danach mein UML aus dem Code gewonnen, weil ich sowieso wieder alles anders mache. UML fordert, dass man bereits vor dem Programmieren weiß, welche private Member man haben wird. Das weiß ich nie!
lg, freakC++
-
freakC++ schrieb:
UML fordert, dass man bereits vor dem Programmieren weiß, welche private Member man haben wird. Das weiß ich nie!
UML fordert gar nichts, UML ist nur eine Notation, mit der man (u.a.) objektorientierte Designs aufzeichnet. Wenn in dem Entwurf keine privaten Member vorkommen (was die Regel sein dürfte!) dann schreibt man halt keine hin, aus die Maus.
-
Skym0sh0 schrieb:
wir schweifen ab
ihr beschreibt mir da eure arbeit bei irgendwelchen firmen und nicht die vorgehensweise beim software designDas muß man sich erstmal geben. Sie beschreiben, wie sie Projekte angehen, aber Du willst stattdessen wissen, wie man Projekte angeht?
Was genau willst Du?
Brauchst Du Gegfängnisse? Nimm UML und Nassi-Shneiderman-Diagramme. Kauf Dir Bücher von und um Shlaer-Mellor. Nimm nicht C++, es gibt da bessere Sprachen. Entwirf ausschließlich Top-Down. Nimm UN, kommentiere auf englisch, kommentiere jede Funktion. Benutze niemals goto, mehrfache Erblichkeit oder continue. Plane ausführlich und halte Dich dann unter allen Umständen an den Plan. Plane Sprachneutral. Plane vorher die Planung.
-
Wie plant man?
Man setzt sich am besten mit Stift und Papier an einen gemütlichen, ruhigen, inspirierenden, ... Ort. Dann kommt das große Brainstorming. WAS genau will ich eigentlich? Man umreißt ganz grob, was die Software können soll.
Hat man diese grobe Struktur, kann man sich die Details überlegen. Hier kann man schon langsam anfangen, grob in "Software" zu denken: welche Klassen wären hierfür denkbar? wie sollen die zusammenspielen? welche klassen gehören zusammen (->Module/namespaces/...). WIE du dann diese Notizen angehst (UML, einfache Listen, Beschreibungen in ganzen Sätzen, ...) ist doch egal, hauptsache du kommst damit zurecht...Wenn du jetzt ans Programmieren gehst, gibts auch mehrere Möglichkeiten. Entweder wild drauf los kreuz und quer, oder von einem bestimmten Punkt aus detailliert die Klassen ausprogrammieren, oder erst die Interfaces Programmieren und danach Stück für Stück verfeinernd ausprogrammieren. Gibt noch mehr Modelle...
Das ist aber alles eine eigene Wissenschaft, drum gibt es auch gaaaanz viel Literatur dazu.
Und was du für dich selber wählst liegt bei dir, was dir liegt. Hast du von Anfang an einen detaillierten Plan, kannst du gleich alles wie wild fein säuberlich ausprogrammieren. Würde ich mit wenig Erfahrung aber nicht so machen, da wäre eine durchdachte, planbare Herangehensweise sinnvoller.
-
durchwachsen schrieb:
Garnicht planen macht sicher keiner, auch wenn es alle behaupten...
Leider ist dies durchaus die Regel, gerade bei kleinereren Firmen. Ich war insgesamt in 4 Firmen beschäftigt, und nur in zweien davon konnte man zumindest von einer grundlegenden Planung ausgehen.
Ich sehe 3 Sätze um ein komplexes Projekt zu beschreiben nicht als Planung an. Und wenn man zudem keine Kundenkontakte hat, muss man mit diesen auskommen...
durchwachsen schrieb:
Erst mal sollte man sich klar sein, was man eigentlich will, das klingt einfach, ist aber oft das schwierigste.
Man wird in manchen Firmen bereits schief angesehen, wenn man noch tiefgreifendere Fragen stellt, die über die oben beschriebenen 3 Sätze hinaus gehen.
"Das musst du doch alles wissen, du bist der Programmierer." "Ist doch alles [in den drei Sätzen] beschrieben." - und wenn man dann vor sich her werkelt und Notizen (eine grobe Planung) macht, wird man angemacht, warum man nicht programmiert. Alles schon erlebt.
Am besten ist natürlich am Schluß wenn man (weil man abgeblockt wurde) am Schluß gesagt bekommt, das man alles neu machen soll, weil es nie so geplant war, aber bei den Punkten die dann kritisiert wurden, stand nichts in den drei Sätzen. Aber das der Chef sich vielleicht zumindest mal Zwischenstände anschaut, wenn er schon keine Informationen preis gibt, ist ja im Zweifel Zeitaufwand.
Ohne Übertreibung war eine Beschreibung mal: "Programmiere für unseres Programm eine Projektverwaltung, du hast drei Wochen Zeit" (Hinweis: Nach mehrfachen nachharkens, war bekannt das es durchaus in die Größenordung eines MS Projects heranreichen sollte). Auf die Aussage das dies niemals auch nur annährend in der Zeit möglich sei, möchtest du garnicht die Reaktion wissen.
durchwachsen schrieb:
Dann überlegt man sich, wie die SW-Architektur grob aussehen soll. Danach teilt man das ganze in kleinere Module auf und dann geht es rund im Kopf mit allen möglichen Klassen, Algorithmen usw...
Vergiss es einfach. Du hast vielleicht das Glück in solchen Firmen zu arbeiten, ich kenne auch die Gegenbeispiele. Und jegliche Planung wird dann auch noch als pure Zeitverschwendung abgetan.
In meiner jetzigen Firma bekomme ich zwar auch nur wenige Informationen, aber wenigstens bekomme ich Antworten, und kann grob Planen. Manchmal bekomme ich auch eine grobe Skizze, oder mir wird freigestellt wie ein Modul umzusetzen ist - auch auf die Gefahr hin, das dies mal mit der Meinung meines Chefs kollidiert.
-
Skym0sh0 schrieb:
[...]directx, opengl, winapi usw. kann man sich anhand von ein paar büchern und paar websites gut selber aneignen, aber WIE PLANT MAN?[...]
Wie man theoretisch plant, wirst Du in der FH lernen. In der Arbeit, welche Du hoffentlich hinter finden wirst, wirst Du dann sehen, dass zwischen Theorie und Praxis der Grand-Canyon klafft. Es gibt Ausnahmen, aber i.d.R. gibt es leider kaum mehr als eine grobe Spezifikation.
-
Tachyon schrieb:
Es gibt Ausnahmen, aber i.d.R. gibt es leider kaum mehr als eine grobe Spezifikation.
Selbst eine grobe Spezifikation sehne ich mir häufig herbei.
-
asc schrieb:
Tachyon schrieb:
Es gibt Ausnahmen, aber i.d.R. gibt es leider kaum mehr als eine grobe Spezifikation.
Selbst eine grobe Spezifikation sehne ich mir häufig herbei.
Naja, ein Lastenheft sollte es schon geben. Sonst läuft irgendwas gewaltig schief.
-
be careful what you wish for
In manchen Firmen wird Planung großgeschrieben, aber gemeint ist damit Bürokratie. Da muss genauso alles "schnell schnell" gemacht werden, mit dem Unterschied, dass dazu ein Haufen Dokumente produziert werden, die nachher keiner mehr liest.
-
Sorry wenn ich da ein wenig emotional geworden bin und sehr ausgiebig berichtet habe.
Ich habe damals so angefangen dass ich mir aufgezeichnet habe welche Aufgaben zu lösen sind und wie diese in Verbindung miteinander stehen. Ich habe mich also nicht an Standard wie UML oder FLußdiagramme gehalten sondern mein eigenes Ding gemacht, da ich von Anfang an alleine verantwortlich war und als Quereinsteiger aus der Elektronikbranche nur einen Plan von Funktionsbeschreibungen, Stücklisten und Komponententests hatte, da unser Ausbilder da damals sehr viel Wert drauf gelegt hatte. Ich könnte heute noch mich in damalige Schaltungen reinarbeiten und alles nachvollziehen.
Wie schon hier beschrieben, lese viel über Software Architektur, Projektmanagement etc. also alles das was mit dem eigentlichen Implementieren von Lösungen nicht viel zu tun hast. Dann lege dir ein ganz dickes Fell zu und geh den Beruf an, so bissle Planung lernste dann durch die Praxis wenn du das Glück hast in eine guten Firma zu kommen die darauf Wert legt. Ich habe es in 10 Jahren nicht geschafft, kann bei dir ja aber anders sein.
Anfangen tuts du Projekte immer in dem du dir über die Anforderungen im klaren wirst und sie aufschreibst. Dann versuchst du das in einzelne Einheiten zu unterteilen, bis du möglicht kleine und überschaubare Module hast. Versuche durch Entwurfsmuster ein wenig flexibel zu bleiben, denn ich habe kein Projekt erlebt in dem sich nicht die Anforderungen mit der Zeit geändert haben. Natürlich bekommst du nicht viel Zeit um auf die neuen Anforderungen zu reagieren, also muss dein Design schon darauf vorbereitet sein.
Ich kann nur soviel sagen. Als Hobby zu programmieren und das als Beruf aus zu üben ist was völlig verschiedenes. Wo viel Geld, viele Menschen mit unterschiedlichen Meinungen und Emotionen dabei sind kann der Spaß auch schon mal auf der Strecke bleiben. Ich habe auch seit dem C64 gerne programmiert und die Computertechnik war das einzige was mich immer in meinem Leben interessiert hat. 25 Jahren nach meinem ersten Kontakt mit Computern und 10 Jahre als Punchingball in der IT bin ich zu der Erkenntnis gekommen, dass ich beruflich dafür nicht geeignet bin.
Aber als Hobby macht es wieder einen riesen Spaß, vorallem weg von Web und mal was richtig Systemnahes lernen
G hibbes
Edit:
@asc: Danke, so langsam glaube ich nicht mehr dass ich nur Pech mit meinen Firmen gehabt habe. Das ist doch aber kein Zustand wenn man nicht richitg planen darf/kann. Das kann nur alles in die Hose gehen und man selbst wird an den Pranger gestellt. Ich musste mich auch schonmal 2 Stunden gegen 3 Leute der Geschäftführung verteidigen, warum das Projekt nicht fertig ist. Mann war ich angefressen danach.
Ich darf nicht lange planen aber muss den Kopf hinhalten wenn die Qualität nicht stimmt. *grrrr
-
Bashar schrieb:
be careful what you wish for
In manchen Firmen wird Planung großgeschrieben, aber gemeint ist damit Bürokratie. Da muss genauso alles "schnell schnell" gemacht werden, mit dem Unterschied, dass dazu ein Haufen Dokumente produziert werden, die nachher keiner mehr liest.
Das ist bei uns so. Wr haben so ne beknackte Dokustruktur welches mal in den 70ern vom US-MoD entwickelt wurde (oder die Entwickling wurde vom MoD beauftragt). SSS, CSS, SUS, SSDD, SRS, SDD, IDD und was ich, was noch alles (ich habe nur mit den genannten zu tun). Jede Menge Schwachsinn ohne Inhalt (es wird also auch nur grob geplant). Wirkliche Inhalte stehen nur in der SSS (Lastenheft) und der SSDD (Grobe Architektur). In der 80ern wurde das bei denen wieder abgeschafft, weil es nicht praktikabel war. Keine Ahnung, weshalb wir überhaupt was benutzen, was vom MoD kommt.
-
Tachyon schrieb:
Naja, ein Lastenheft sollte es schon geben. Sonst läuft irgendwas gewaltig schief.
Wäre froh, wenn ich mal eines sehen würde. Wenn es so eins gibt, dann sicher aus der Anfangszeit der Projekte (Das jetzige ist 10, das vorherige 15 Jahre am Laufen) - wo mit Sicherheit effektiv nichts mehr stimmt.
-
Da stimmen Lehre, Theorie und Praxis nicht überein - und können es auch nicht.
Lehre und Theorie gehen davon aus, dass ein SW-Entwickler die volle Information hat, was er machen soll und die Anforderungen in allen Details versteht und damit ein Projekt planen kann. Die Praxis ist dagegen anders: Machen Sie mir eine Lösung - nennen Sie mir einen festen Preis dafür - fangen Sie gleich an - ich brauche das sofort. Ein Pflichtenheft ist da selten drin!
Das ganze reduziert sich auf die simplen Fragen, was kostet ein Stück Programm und wann ist das fertig?
-
Und jeder der sich mit Planung beschäftigt, sollte auch mal diesen Wiki-Artikel gelesen haben: http://de.wikipedia.org/wiki/Anti-Pattern
(um zu wissen, wie man es NICHT machen sollte - es jedoch in der Realität trotzdem immer wieder vorkommt...)Eigentlich ist das ganze Thema ja eigentlich zu frustrierend (wie hibbes und asc ja auch schon geschrieben haben -), daß man für Planung (in der Firma) auch noch bestraft wird.
-
asc schrieb:
durchwachsen schrieb:
Garnicht planen macht sicher keiner, auch wenn es alle behaupten...
Leider ist dies durchaus die Regel, gerade bei kleinereren Firmen. Ich war insgesamt in 4 Firmen beschäftigt, und nur in zweien davon konnte man zumindest von einer grundlegenden Planung ausgehen.
Ich sehe 3 Sätze um ein komplexes Projekt zu beschreiben nicht als Planung an. Und wenn man zudem keine Kundenkontakte hat, muss man mit diesen auskommen...
durchwachsen schrieb:
Erst mal sollte man sich klar sein, was man eigentlich will, das klingt einfach, ist aber oft das schwierigste.
Man wird in manchen Firmen bereits schief angesehen, wenn man noch tiefgreifendere Fragen stellt, die über die oben beschriebenen 3 Sätze hinaus gehen.
"Das musst du doch alles wissen, du bist der Programmierer." "Ist doch alles [in den drei Sätzen] beschrieben." - und wenn man dann vor sich her werkelt und Notizen (eine grobe Planung) macht, wird man angemacht, warum man nicht programmiert. Alles schon erlebt.
Am besten ist natürlich am Schluß wenn man (weil man abgeblockt wurde) am Schluß gesagt bekommt, das man alles neu machen soll, weil es nie so geplant war, aber bei den Punkten die dann kritisiert wurden, stand nichts in den drei Sätzen. Aber das der Chef sich vielleicht zumindest mal Zwischenstände anschaut, wenn er schon keine Informationen preis gibt, ist ja im Zweifel Zeitaufwand.
Ohne Übertreibung war eine Beschreibung mal: "Programmiere für unseres Programm eine Projektverwaltung, du hast drei Wochen Zeit" (Hinweis: Nach mehrfachen nachharkens, war bekannt das es durchaus in die Größenordung eines MS Projects heranreichen sollte). Auf die Aussage das dies niemals auch nur annährend in der Zeit möglich sei, möchtest du garnicht die Reaktion wissen.
durchwachsen schrieb:
Dann überlegt man sich, wie die SW-Architektur grob aussehen soll. Danach teilt man das ganze in kleinere Module auf und dann geht es rund im Kopf mit allen möglichen Klassen, Algorithmen usw...
Vergiss es einfach. Du hast vielleicht das Glück in solchen Firmen zu arbeiten, ich kenne auch die Gegenbeispiele. Und jegliche Planung wird dann auch noch als pure Zeitverschwendung abgetan.
In meiner jetzigen Firma bekomme ich zwar auch nur wenige Informationen, aber wenigstens bekomme ich Antworten, und kann grob Planen. Manchmal bekomme ich auch eine grobe Skizze, oder mir wird freigestellt wie ein Modul umzusetzen ist - auch auf die Gefahr hin, das dies mal mit der Meinung meines Chefs kollidiert.
Dass in der Firma in der ich jetzt arbeite etwas mehr geplant wird, liegt wohl daran, dass wir unsere SW über Jahre entwickeln und immer wieder neue Versionen ausliefern, die auf den alten aufbauen. Da ist es ziemlich schlecht, wenn schlecht, wenn man schnell irgendwo was reinhackt, wie wir immer mal wieder sehen können.
-
durchwachsen schrieb:
Dass in der Firma in der ich jetzt arbeite etwas mehr geplant wird, liegt wohl daran, dass wir unsere SW über Jahre entwickeln und immer wieder neue Versionen ausliefern, die auf den alten aufbauen.
In den Firmen ohne Planug war dies auch so. Das eine Projekt läuft wie schon geschrieben nunmehr seit 10, das andere 15 Jahre. Bei dem 15er Projekt war aber auch schon alles verpöhnt das nicht mit einhacken von Code zu tun hatte. In dem 10er Projekt wird zwar auch nichts geplant, aber man kann wenigstens sich Gedanken machen.
-
Mir fällt vor allem auf, daß beim Thema Planung hier im Thread viel über UML und Entwürfe gesprochen ist - aber das ist schon technisches Design des Produkts.
Projektplanung umfasst aber bereits vor Zielstellungen, Schnittstellen zu Personen, Festlegung von Personalien, Eskalationsstrategie, Risikobewertungen, etc. Wer kommuniziert wann mit wem? Change Prozess. Usw.
