Wie werden (grössere) Projekte geplant?
-
Egal, ob ein Projekt klein oder gross ist und wieviele daran mitwirken, gilt:
1. Planung --> Überschaubare Teilaufgaben und daraus Module bilden.
2. Module offen halten für Änderungen und Erweiterungen --> dürfen sich nicht gegenseitig ins Gehege kommen.
3. Testmöglichkeiten sowohl für die Entwicklung als auch die Wartung in die Programmierung integrieren --> Debug reicht nicht, Testprotokoll (Datei) ist besser.
4. und und und ...Bedenke: Zum Start eines Projektes sind oft nicht alle Zielsetzungen bekannt oder Details noch ungekärt. Man muss aber dennoch das Projekt beginnen. Nicht selten sagt oder präzisiert ein (auftraggebender) Anwender seine konkreten Wünsche erst, wenn das Projekt schon mal im Ansatz läuft und was zu sehen ist.
Begreife: Ein gut geplantes Projekt ist ein Prozess über die Lebensdauer des Projektes.
Wie man das alles macht, ist Erfahrung oder Firmware. Für schlechtes Nachdenken gibt es kaum Unterstützung, auch wenn sowas angeboten wird
-
knivil schrieb:
Gar nicht.
Das wollte ich bei der Frage auch sofort als Antwort schreiben -)
Tja, die Realität sieht leider anders aus als es uns die Lehrbücher angeben...
-
Kommt doch auch darauf an, was man als Planung ansieht? "Gar nicht" kann ich mir gar nicht vorstellen.
Im ernst. Eine Planung gibt es immer! Selbst wenn diese lautet "Wir proggen jetzt eine Textverarbeitung in Sprache X, mit 2 Mann, für Windows und Mac OS X und wir wollen in 6 Monaten fertig werden.". Dann sind das doch schon mal Pläne. 
Wie gut und durchdacht sie sind, steht auf einem anderen Blatt.Manchmal muß man auch nicht jedes Projekt genau planen, wenn die meisten Mitwirkenden schon Erfahrung mitbringen. Ich muß nicht jede Klasse planen. Ich habe schon so viele Projekte hinter mir, da werde ich nicht noch ein UML-Diagramm für meinen Projektleiter vorher machen. Auch wenn er das gerne sehen will. Aber ich weigere mich!
Ich weiß aber aus Erfahrung, das ich gefälligst Unittests vorher schreiben muß. Dafür brauche ich auch keine Planung. Die Unittests veranlassen mich implizit dazu, zu planen und mir Gedanken zu machen.
-
Und was lernt uns das?
Zielgerichtet Denken und danach die Planung und die Realisierung von SW-Projekten auszurichten ist mehr als Proggen. Aber man muss auch den noch unerfahrenen Progger einbinden können und ihm Hilfestellung geben, seine Arbeit zu machen. Die Erfahrung der anderen muss er lernen.
-
Als ich noch beruflich Webzeugs entwickelt habe, in einer Zeit wo noch nicht sicher war ob aus PHP was wird ;), da hätte ich mir wenigsten ein wenig Planung gewünscht.
Es gab zwar Meetings und ein paar Notizen und auch mal ein kleines Pflichten-/Lastenheft, aber so wirkliche Planung so wie ich das mal in ein paar Projektmanagement Bücher mir angelesen hatte war da fehl am Platze. Es hieß immer "schnell schnell schnell", "dafür haben wir nicht viel Zeit", "Der Kunde zahlt das nicht".
Das habe ich in den letzten 10 Jahren bei 3 Arbeitgebern so erlebt und bin dann komplett aus der Branche ausgestiegen. Jetzt programmieren ich nur noch aus Spaß wie früher als Jugendlicher und bin dabei wieder in meinen ursprünglichen Beruf zurück zu gehen. Das Geld ist das gleiche nur habe ich nach Feierabend auch Feierabend
Gut das ist natürlich keine Lösung für alle die den Job lieben. Da hoffe ich dass das Bewusstsein für Planung, Umsetzung, Test, Abgabe weiter wächst, und ich bin mir auch sicher, dass ganz wenige einen Arbeitgeber hat der schon mal was von Projektmanagement gehört hat.
Ich habs aufgegeben, aber ich wünsche euch da mehr Glück.
G hibbes
-
hibbes schrieb:
..."schnell schnell schnell", "dafür haben wir nicht viel Zeit", "Der Kunde zahlt das nicht". ... Ich habs aufgegeben, aber ich wünsche euch da mehr Glück.
Ja, eine solide Planung zahlt der Kunde selten - soll doch gestern fertig sein!
"Sie sind doch der Fachmann" und müssen verstehen, was ich will und besonders schwer scheint das wohl auch nicht!" Dieses Problem eines SW-Entwicklers ist nicht lösbar.
-
Garnicht planen macht sicher keiner, auch wenn es alle behaupten. Keiner der was größeres machen will setzt sich hin und tippt mal lustig Code los. Die meisten werden auch keine großen UML Diagramme oder ähnliches zeichnen. Erst mal sollte man sich klar sein, was man eigentlich will, das klingt einfach, ist aber oft das schwierigste. 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...
-
Klar plant jeder mehr oder weniger, aber so wie man eine Programmiersprache oder Algorithmen lernt so sollte man auch das Management dahinter lernen. Aber das macht ja keinen Spaß und lässt sich dem Chef oder Kunden schwer verkaufen.
Wenn du denen erzählst dass das Programmieren vielleicht nur 30% der Zeit des Projektes ausmacht und der Rest für Gespräche, Planung, Tests und Dokumentation drauf geht wird dir nicht selten der Vogel gezeigt. Ich habe halt da große Probleme gehabt gleich loszulegen und vor allem konnte ich die Arbeitszeit nur ganz schwer einschätzen und das konnte ich bis zum Schluss auch schlecht. Nennt sich glaube ich Risikomanagement, wo man die ganzen Unbekannten versucht einzuplanen.
Auf jedenfall macht mir das Programmieren wieder Spaß, da ich es jetzt ohne Druck und Stress machen kann. Mal schauen vielleicht vereine ich ja irgendwann meine beiden Berufe und mache was in Richtung Mikrocontroller oder es bleibt halt ein Hobby, auch nicht schlimm. Oder ich finde mal einen Arbeitgeber wo alles Hand und Fuß hat und wo ich nicht nur eine Codemaschine bin die irgendwelche Schnittstellen zwischen Webseite und alten Applikationen schaffen soll, und das in so wenig Manntagen(Wie ich das Wort hasse) wie möglich.
-
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.
