Wie werden (grössere) Projekte geplant?
-
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.
-
nachtfeuer schrieb:
eine fast perfekte parodie...
Und leider doch zu häufig Realität.
nachtfeuer schrieb:
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...
Nur wird dieser Programmierer häufig erst einmal als der "bessere" angesehen, weil er vermutlich auch deutlich schneller "fertig" war. In meiner ersten Firma hing mir bei meinen zweiten Projektleiter der Ruf nach, das ich sehr langsam wäre (und wenn man das häufiger hört, beginnt man langsam selbst daran zu glauben). Irgendwann musste er ohne direkte Vorkenntnisse den Code dieses Projektes übernehmen, und den Restsupport leisten. Ein halbes Jahr verging, das ich dann überraschend eine Gehaltserhöhung bekam - Einer der Hauptgründe war die Empfehlung eben jenes Projektleiters...
Oder in meiner letzten Firma: auch hier wurde ich als langam verschrien, nur änderte sich die Meinung des Hauptchefs nach 2 Jahren... Er stellte fest das ich zwar langsamer zum Erstergebnis kam, mit der Fehlerbehandlung aber insgesamt schneller war (da weniger Fehler, und nachträgliche Anpassungen nötig waren).
nachtfeuer schrieb:
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...
Kenn ich. Ich wurde schon einmal von einem Projekt abgezogen, als ich eine schriftliche Bestätigung der Anweisung bekommen wollte (Konkret ging es mir darum das ich nicht für Entscheidnungen der Fimenleitung die Haftung übernehmen wollte - und ja, es gibt Fälle in dem man als Programmierer haftbar gemacht werden kann).
nachtfeuer schrieb:
Für große Projekte ist Open Source sehr wichtig...
Die Aussage kann ich nicht unterschreiben. Ja, für einige Projekte kann OS wichtig sein, aber für viele andere Spielt dies keine Rolle.
nachtfeuer schrieb:
...Aufgabenverteilung, Ersatzbesetzungen, und ein guter Plan braucht Kontrollmöglichkeiten...
Dem gebe ich weitgehend Recht, wobei Firmenleitungen gerne an diesen Punkten sparen, ohne die Folgekosten dieser Entscheidung wahrzunehmen. Oder sie streichen es, weil der Kunde einen Abgabetermin ausmacht, der ansonsten nicht haltbar wäre (wobei im Endeffekt der Kunde dann deutlich länger mit einer "problematischen" Software zu kämpfen hätte, als wenn er den Zeitdruck nicht ganz so hoch setzt).