Wie werden (grössere) Projekte geplant?
-
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.
-
Ich habe vor kurzem fogendes Buch geschenkt bekommen und kann es, nachdem ich die ersten Seiten durch habe, wärmstens empfehlen:
Der Termin. Ein Roman über Projektmanagement
Amazon.de schrieb:
Todlangweilig, wenig motivierend, so waren bisher die meisten Lehrbücher zum Thema Projektmanagement. Für den notwendigen frischen Wind sorgt nun Tom DeMarco mit seinem neuen Buch Der Termin. Seine dabei umgesetzte Idee: anstelle eines trockenen Sachbuchs einen Roman über Projektmanagement zu schreiben. Man nehme Mr. Tompkins, einen soeben freigesetzten Telekommunikations-Manager, kidnappt ihn durch eine geheimnisvolle Schönheit und beauftragt den Entführten anschließend, im kommunistischen Phantasieland Morovien eine konkurrenzfähige Softwareindustrie hochzuziehen. Aus diesen Zutaten entsteht ein spritziger Cocktail voller Überraschungen.
Anfangs werden viele noch Mr. Tompkins um die paradiesischen Arbeitsbedingungen beneiden. Aus einer überdimensionierten Entwicklungsmannschaft bildet er 18 Teams, die sechs verschiedene Softwareprodukte entwickeln sollen und miteinander im Wettbewerb stehen. Die Besonderheit dabei: Die Teams sind unterschiedlich groß und setzen zur Zielerfüllung jeweils andere Methoden ein. Plötzlich auftretende bürokratische Hemmnisse und immer utopischere Terminvorgaben verleihen dem gesamten ehrgeizigen Entwicklungsprojekt einen atemberaubenden Bezug zur Realität.
Ein weiterer Höhepunkt neben der erfrischenden Sprache, die den in dieser Branche so weitverbreiteten Sarkasmus auf treffende Art und Weise widerspiegelt, sind die Tagebucheinträge von Mr. Tompkin. Nach jedem Kapitel faßt er die jeweiligen Ereignisse in verblüffend einfachen Managementgrundsätzen zusammen.
Klares Fazit: Tom DeMarcos neues Werk ist in höchstem Maße lehrreich und unterhaltsam zugleich.
-
@Marc++us:
Da hast du recht, aber manche bekommen grad mal 3 Sätze auf den Tisch geknallt und sollen dann ein Photoshop in 3 Wochen realisieren und das bitte zum Mindestlohn und ständiger Erreichbarkeit. Das ist zwar etwas überspitzt dargestellt aber ist, wie ich hier lesen, in den meisten kleinen Firmen gang und gebe.Das ist so wie Baumhaus bauen, kurz besprechen und dann los.
Von den Begriffe die du genannt hast kann ein Arbeitnehmer in der Branche nur träumen. In so einer Firma würde ich gerne arbeiten, aber das klingt ein wenig nach Utopia.
@roger wilco: von dem Buch habe ich nur gutes gehört, ich persönlich kann noch Projekmanagment kompakt empfehlen für den Einstieg.
http://www.amazon.de/Projektmanagement-kompakt-Kompakt-Pascal-Mangold/dp/3827419379/ref=sr_1_1?ie=UTF8&s=books&qid=1280928004&sr=8-1
-
Marc++us schrieb:
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.
Das liegt aber eher daran, dass vielen nicht klar ist, was das Wort Projekt bedeutet. Wahrscheinlich, weil der Begriff in jeder IDE vorkommt, und dort das gerade entwickelte Programm (System, Bibliothek, ...) bezeichnet. Wikpedia sagt:
Ein Projekt ist ein einmaliger Prozess, der aus einem Satz von abgestimmten, gelenkten Tätigkeiten mit Anfangs- und Endtermin besteht und durchgeführt wird, um unter Berücksichtigung von Zwängen bezüglich Zeit, Kosten und Ressourcen ein Ziel zu erreichen.
Also z.B. "Entwicklung von Programm X".
Der OP kennt diese Unterscheidung aber auch nicht so genau, Zitat:
wie werden programme/projekte geplant ?
[...]
wie weit plant man, plant man nur den aufbau, die abhängigkeiten von klassen, die member und methoden oder sogar auch den (genauen) inhalt/ablauf von methoden und funktionen?Deshalb ist es IMO angebracht, auch etwas zur Programmplanung, d.h. zum Entwurf, zu sagen.
-
Na, dann eskaliere ich mal...
-
Dieser Thread wurde von Moderator/in volkard aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Bashar schrieb:
Marc++us schrieb:
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.
Das liegt aber eher daran, dass vielen nicht klar ist, was das Wort Projekt bedeutet.
Das liegt wohl eher an der Frage und dem Kenntnisstand des Threadstarters. Der wollte glaub nix von Resource-Eskalations-Prozess(TM) hören.
-
Skym0sh0 schrieb:
*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)Sammel erst mal ne ganze Menge Erfahrung. Schau dir Design Patterns, Frameworks (Directx, ogl..), Gameengines, Datenbanken usw. an und verwende sie. Und lern mindestens noch eine Sprache ohne Header Dateien.
Wenn du weißt, wie andere ihre Sachen gemacht haben, kannst du deine auch besser planen.
-
räusper schrieb:
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) Sammel erst mal ne ganze Menge Erfahrung. Schau dir Design Patterns, Frameworks (Directx, ogl..), Gameengines, Datenbanken usw. an und verwende sie. Und lern mindestens noch eine Sprache ohne Header Dateien.Wenn du weißt, wie andere ihre Sachen gemacht haben, kannst du deine auch besser planen.
Da liegst du falsch. Analysieren und Planen muss man stets erst die Aufgabe, und dann danach über den Weg zur Lösung nachdenken!
Anders kriegt man im täglichen Leben nicht einmal ein Essen auf den Tisch, ausser Fertiggerichte, die nicht schmecken und dazu noch sehr teuer sind. Der Schnellkochtopf (Directx, Gameeingines, Datenbanken, etc.) bringen das nicht ohne deine geplanten Zugaben!
So kriegst du nicht einmal einen Kartoffelsalat oder ein Omelett hin!
-
berniebutt schrieb:
räusper schrieb:
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) Sammel erst mal ne ganze Menge Erfahrung. Schau dir Design Patterns, Frameworks (Directx, ogl..), Gameengines, Datenbanken usw. an und verwende sie. Und lern mindestens noch eine Sprache ohne Header Dateien.Wenn du weißt, wie andere ihre Sachen gemacht haben, kannst du deine auch besser planen.
Da liegst du falsch. Analysieren und Planen muss man stets erst die Aufgabe, und dann danach über den Weg zur Lösung nachdenken!
Anders kriegt man im täglichen Leben nicht einmal ein Essen auf den Tisch, ausser Fertiggerichte, die nicht schmecken und dazu noch sehr teuer sind. Der Schnellkochtopf (Directx, Gameeingines, Datenbanken, etc.) bringen das nicht ohne deine geplanten Zugaben!
So kriegst du nicht einmal einen Kartoffelsalat oder ein Omelett hin!
Die Hälfte von dem was du zitiert hast, habe ich nicht geschrieben. Der Teil, den ich geschrieben hab, ist wie immer richtig, auch wenn du es nicht verstanden hast. Deine komische Omelett Geschicht passt mal nicht.
-
Analysieren und Planen muss man stets erst die Aufgabe
Haeh? Also ich habe Hunger und brauche was zu essen. Und wenn ich noch nie selbst Essen gemacht habe? Wo ist die Aufgabe, was soll ich jetzt analysieren und planen?
-
knivil schrieb:
Analysieren und Planen muss man stets erst die Aufgabe
Haeh? Also ich habe Hunger und brauche was zu essen. Und wenn ich noch nie selbst Essen gemacht habe? Wo ist die Aufgabe, was soll ich jetzt analysieren und planen?
Na, zuerstmal die Planung planen. Und ohne mindestens eine gescheite Evaluationsstrategie1, Eskalationsstrategie2, Risikomanagement3, Gewürztaxonomie4, Ressourcenmanagement5 und Kommunikationsplanung6 solltest Du gar nicht erst mit dem Planen der Planung anfangen.
1 Wie prüfst Du, ohne es einfach auszuprobieren, ob der Kochplan dann auch funktionieren wird?
2 Unter welchen Bedingungen fragst Du dann doch Frau/Mutti/Entwicklerforum?
3 Was kann schlimmstenfalls passieren? Was tun bei einer abgebrochenen Bleistiftspitze?
4 Wie heißt nochmal "das rote Pulver im großen Glas"?
5 Sind die zur Planung notwenigen Mittel da? Habe ich ausreichend Zeit, ist genügend Luft im Zimmer?
6 Mit wem willst Du dabei über was plaudern?
-
volkard schrieb:
2 Unter welchen Bedingungen fragst Du dann doch Frau/Mutti/Entwicklerforum?
6 Mit wem willst Du dabei über was plaudern?Hier hat wohl die Planung der Planung versagt. Die Kommunikationsplanung hätte vor der Eskalationsstrategie geplanplant0815 werden müssen.
0815Wie war nochmal die korrekte grammatikalische From von Ereignissen die in der Zukunft gewesen sein werden sind, wenn man in das Restaurant am Ende des Universums zum essen geht?
-
War wohl nix schrieb:
Die Kommunikationsplanung hätte vor der Eskalationsstrategie geplanplant0815 werden müssen.
Da war keine zeitliche Reihenfolge vorgegeben.
Außerdem bestehe ich nicht darauf, daß man das wirklich so macht. Das war eine, wie ich dachte, leicht zu durchschauende Parodie auf Marc++us&Prof84.
-
volkard schrieb:
War wohl nix schrieb:
Die Kommunikationsplanung hätte vor der Eskalationsstrategie geplanplant0815 werden müssen.
Da war keine zeitliche Reihenfolge vorgegeben.
Außerdem bestehe ich nicht darauf, daß man das wirklich so macht. Das war eine, wie ich dachte, leicht zu durchschauende Parodie auf Marc++us&Prof84.Na, die Kommunikationsplanung hätte doch festgelegt, wer überhaupt wen eskalieren darf. Damit nicht solche Projekt gefährdenden Unklarheiten wie "Frau/Mutti/Entwicklerforum?" entstehen.
PS: Meine Aussage war natürlich töter als Ernst gemeint und kein Buchtipp.
-
volkard schrieb:
Das war eine, wie ich dachte, leicht zu durchschauende Parodie auf Marc++us&Prof84.
Ich dachte es wäre eine schwerer zu durchschauende Selbstparodie
-
Diese Beiträge hier erinnern mich stark an Online Multiplayer im Diablo2 Spiel: Hektik statt Spielspaß, von (grabbenden!)Bots umgeben, von schnell-hochlevelern(auch bots dabei) umgeben, schnell mit Items überladen, die noch gar nicht zum aktuellen Charakterlevel passen. Und Lv 90 Typen fragen Levl 20 Chars nach Tauschobjekten für Lvl 90...und Lvl 4 Typen, können kaum selber spielen, versuchen Lvl 90 Items, die sie geschenkt bekamen, an lvl 10er zu verticken, was sollen sie auch sonst damit anfangen...eine fast perfekte parodie...
dann fällt mir noch ein Programmierer ein, der gerne halbgare "ware" abgelieferte....Folge: viele Anrufe und Beschwerden. Folge: keine vernünftige Besprechung mehr möglich. Folge: wenig Plan und außerdem wenig Zeit, Folge: schludrige Programme, jump Ausgangsposition...
Hier stehen Idealvorstellungen und Realvorgänge etwas nebeneinander...
Ein typisches Finanzguruproblem: Chaoskalkulation...
dann fällt mir noch ein Programmierer ein, der mit sehr viel Freude und Engagement entwickelt, auf Weisung des Managements aber fehlerhafte Programme abliefern muss, (weil Management nicht versteht), und der Programmierer lustig planen lassen muss, entwickeln lassen muss, nachpatchen muss...auch eine von vielen möglichen Arbeitsweisen
Für große Projekte ist Open Source sehr wichtig, Aufgabenverteilung, Ersatzbesetzungen, und ein guter Plan braucht Kontrollmöglichkeiten, ob denn auch alles wirklich nach plan läuft, und wenn nicht, warum nicht usw.
Module kann könnte man sich auch als Zeit/Ablauftyp-Module denken, wie Info sammeln, Resourcen überprüfen, Strategieauswahl usw usw.Wenn du selbst ein Projekt mit mehreren machen willst, ...mach doch einfach mal so ein Projekt mit mehreren. Planungs/Prüfkriterien wie Kosten oder Zeitaufwand kannst du vielleicht schon sehr genau angeben.
-
Der Hinweis mit dem Planen zum Kochen war von mir durchaus ernst gemeint und hat gewisse Gemeinsamkeiten für die Software-Entwicklung. Wenn ich keine Ahnung von nichts habe, dann nützen mir auch keine noch so guten Hilfsmittel. In der eigenen Küche ist das nicht viel anders mit solchen Dingen wie Schnellkochtopf, Iduktionsherd, Microwelle, etc.. Wenn der Kühlschrank leer ist und ich beim Einkaufen keinen Plan habe, was ich essen will, dann kann ich selbst nichts machen!
Den Pizzadienst und die Currywurstbude nebenan gibt es in der Software-Entwicklung nicht. Und die vielen xxxTheorien und yyyStrategien bleiben unwirksam, wenn ich diese nicht anwenden kann.