Planung eines Projekts

Übersicht

Sonstiges

Projekte

	Krumu1201 Betreff: Planung eines Projekts	Di, Jun 16, 2015 10:15 Antworten mit Zitat
Hallo Liebe Community, ich wollte mal fragen wie ihr eure Programme/Projekte so plant oder ob ihr einfach losprogrammiert, wenn ihr eine Idee habt. Ich mache ja eher Letzteres. Fange viele Projekte an, bekomme aber nichts richtig Fertig. Könnt ihr mir Ratschläge geben wie ich ein Projekt besser plane und die Motivation nicht verliere. Wenn diese Diskussion hier nicht reinpasst, bitte ich, sie zu verschieben. Gruß Krumu1201

Krumu1201

Betreff: Planung eines Projekts

Di, Jun 16, 2015 10:15
Antworten mit Zitat

Hallo Liebe Community,

ich wollte mal fragen wie ihr eure Programme/Projekte so plant oder ob ihr einfach losprogrammiert, wenn ihr eine Idee habt. Ich mache ja eher Letzteres. Fange viele Projekte an, bekomme aber nichts richtig Fertig. Könnt ihr mir Ratschläge geben wie ich ein Projekt besser plane und die Motivation nicht verliere. Wenn diese Diskussion hier nicht reinpasst, bitte ich, sie zu verschieben.

Gruß Krumu1201

	DAK	Di, Jun 16, 2015 10:32 Antworten mit Zitat
Gleich drauf los geht, wenn du für das ganze Projekt weniger als 10 Stunden Gesamtarbeitszeit eingeplant hast. Wenn es danach nicht fertig ist, dann ist es dann meistens tot. Für einen BCC-Beitrag oder so passt das also grad noch. Ansonsten ist die Planung sehr wichtig. Dabei arbeite ich gerne von oben nach unten, das heißt, ich fange an mit "Was soll das Projekt überhaupt tun?" und gehe dann immer mehr in Details runter. Dabei sollte jede einzelne User Interaction auf Papier ausgearbeitet sein (möglichst mit Skizzen) bevor sie implementiert wird. Das heißt allerdings nicht, dass das ganze Projekt komplett fertig ausgeplant sein muss, bevor man programmieren darf. In meinem aktuellen Projekt in der Arbeit läuft das so: Zuerst schauen wir, was der aktuell wichtigste unimplementierte Usecase ist. Den konzipieren wir, dann implementieren wir ihn, testen und debuggen ihn. Dann geht der Live. Das wird wiederholt, solange bis das Projekt steht. Zukünftige Usecases sind nur sehr grob ausgeplant, gerade so, dass wir wissen, was noch zu tun ist, so das wir uns davon aussuchen können, was wir als Nächstes machen.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Di, Jun 16, 2015 10:32
Antworten mit Zitat

Gleich drauf los geht, wenn du für das ganze Projekt weniger als 10 Stunden Gesamtarbeitszeit eingeplant hast. Wenn es danach nicht fertig ist, dann ist es dann meistens tot. Für einen BCC-Beitrag oder so passt das also grad noch.

Ansonsten ist die Planung sehr wichtig. Dabei arbeite ich gerne von oben nach unten, das heißt, ich fange an mit "Was soll das Projekt überhaupt tun?" und gehe dann immer mehr in Details runter. Dabei sollte jede einzelne User Interaction auf Papier ausgearbeitet sein (möglichst mit Skizzen) bevor sie implementiert wird.
Das heißt allerdings nicht, dass das ganze Projekt komplett fertig ausgeplant sein muss, bevor man programmieren darf.

In meinem aktuellen Projekt in der Arbeit läuft das so: Zuerst schauen wir, was der aktuell wichtigste unimplementierte Usecase ist. Den konzipieren wir, dann implementieren wir ihn, testen und debuggen ihn. Dann geht der Live. Das wird wiederholt, solange bis das Projekt steht. Zukünftige Usecases sind nur sehr grob ausgeplant, gerade so, dass wir wissen, was noch zu tun ist, so das wir uns davon aussuchen können, was wir als Nächstes machen.

Gewinner der 6. und der 68. BlitzCodeCompo

	Xeres Moderator	Di, Jun 16, 2015 19:39 Antworten mit Zitat
Vermutlich gilt alles in diesem Thread nicht nur für BlitzBasic im Besonderen sondern für Softwareentwicklung im Allgemeinen. ~VERSCHOBEN~ Ohne einen Plan - zumindest einen groben - kann man kein Projektfortschritt feststellen. Ideen können sich toll anfühlen, bis man anfängt, sie um zu setzen. Besser man macht sich die Lücken und Schwächen bewusst, bevor man den ersten Code in die IDE tippt. Erlaube dir nur minimale Änderungen am Plan. Ohne Zeitdruck zu haben, ist es sehr einfach zu dem Schluss zu kommen "Ich habe so viel gelernt und möchte alles neu und besser machen!". Man kann immer etwas besser machen. Man lernt immer dazu. Wenn man immer bei 25% abbricht und das Projekt neu designed, hat man nie etwas Fertig. Bei Spielen: Sorge dafür, dass man verlieren kann. Kein Spiel ist so langweilig wie eines, dass man nie verlieren kann (gilt für die meisten Genres).
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

Di, Jun 16, 2015 19:39
Antworten mit Zitat

Vermutlich gilt alles in diesem Thread nicht nur für BlitzBasic im Besonderen sondern für Softwareentwicklung im Allgemeinen.
~VERSCHOBEN~

Ohne einen Plan - zumindest einen groben - kann man kein Projektfortschritt feststellen. Ideen können sich toll anfühlen, bis man anfängt, sie um zu setzen. Besser man macht sich die Lücken und Schwächen bewusst, bevor man den ersten Code in die IDE tippt.

Erlaube dir nur minimale Änderungen am Plan. Ohne Zeitdruck zu haben, ist es sehr einfach zu dem Schluss zu kommen "Ich habe so viel gelernt und möchte alles neu und besser machen!". Man kann immer etwas besser machen. Man lernt immer dazu. Wenn man immer bei 25% abbricht und das Projekt neu designed, hat man nie etwas Fertig.

Bei Spielen: Sorge dafür, dass man verlieren kann. Kein Spiel ist so langweilig wie eines, dass man nie verlieren kann (gilt für die meisten Genres).

Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus
THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

	Chester	Mi, Jun 17, 2015 13:48 Antworten mit Zitat
Xeres hat Folgendes geschrieben: Bei Spielen: Sorge dafür, dass man verlieren kann. Kein Spiel ist so langweilig wie eines, dass man nie verlieren kann (gilt für die meisten Genres). Ein bisschen Trivia: Ich weiß zwar gerade nicht mehr welches, aber es gab ein Assassin's Creed, wo die Ruhezeit zwischen zwei Gegnerangriffe so lange war, dass man ausreichend regeneriert wurde, um einen weiteren Angriff zu überleben. Sprich: Man konnte sich in mitten in eine Soldatenmenge stellen, und trotz Nichtstun ist man nie gestorben. Spaß hat es trotzdem gemacht Das Problem ist, dass die ausführliche Planung und das darauffolgende planmäßige Abarbeiten ziemlich wenig Spaß macht - erst recht, wenn man alleine arbeitet. Und die interessanten Dinge, die Spaß machen zu entwickeln, sind dabei oft nur ein kleiner Teil der Gesamtarbeit ein, der Rest ist oft langweilige Routine. Ich arbeite jetzt schon fast ein Jahr an einem Audioprogramm, allerdings vllt alle zwei Wochen mal 1-2h. Dafür sind diese dann aber auch wirklich produktiv und das ist der große Vorteil gegenüber der Trial&Error-Methode, wo man oft merkt, dass man mehrere Stunden in den Sand gesetzt hat. Und das man bei einer Ruhezeit von zwei Wochen auch mal gerne seinen ungeordneten Code nicht mehr durchblickt.

Chester

Mi, Jun 17, 2015 13:48
Antworten mit Zitat

Xeres hat Folgendes geschrieben:

Bei Spielen: Sorge dafür, dass man verlieren kann. Kein Spiel ist so langweilig wie eines, dass man nie verlieren kann (gilt für die meisten Genres).

Ein bisschen Trivia: Ich weiß zwar gerade nicht mehr welches, aber es gab ein Assassin's Creed, wo die Ruhezeit zwischen zwei Gegnerangriffe so lange war, dass man ausreichend regeneriert wurde, um einen weiteren Angriff zu überleben. Sprich: Man konnte sich in mitten in eine Soldatenmenge stellen, und trotz Nichtstun ist man nie gestorben. Spaß hat es trotzdem gemacht Very Happy

Das Problem ist, dass die ausführliche Planung und das darauffolgende planmäßige Abarbeiten ziemlich wenig Spaß macht - erst recht, wenn man alleine arbeitet. Und die interessanten Dinge, die Spaß machen zu entwickeln, sind dabei oft nur ein kleiner Teil der Gesamtarbeit ein, der Rest ist oft langweilige Routine.

Ich arbeite jetzt schon fast ein Jahr an einem Audioprogramm, allerdings vllt alle zwei Wochen mal 1-2h. Dafür sind diese dann aber auch wirklich produktiv und das ist der große Vorteil gegenüber der Trial&Error-Methode, wo man oft merkt, dass man mehrere Stunden in den Sand gesetzt hat. Und das man bei einer Ruhezeit von zwei Wochen auch mal gerne seinen ungeordneten Code nicht mehr durchblickt.

	Cykid	Mi, Jun 17, 2015 16:33 Antworten mit Zitat
Ich hab unglaublich viel Spaß daran kleine "Engines" zu entwickeln. Dabei überleg ich mir immer ein Genre (In diesem Fall ein Top Down Shooter) und bastel mir dann alle spielmechaniken zusammen, so das ich im Finalen Projekt nur noch "Editor Mäßig" Meine Funktionen Platzieren muss^^ Also ich überlege immer, welche Spielmechaniken brauch ich und wie mache ich daraus ein Spiel. Schwer finde ich die Planung wenn man im Team arbeitet. Grafiker und Programmierer verstehen sich noch ganz gut, Programmierer und Programmierer hingegen.... Da ist es verdammt wichtig das man Modular plant damit man sich nicht ins gehäge fuscht. Im Aktuellen Fall entwickel ich ein "Co op Bosskampf irgendwas" Mein Mate schreibt dabei den Server in C++ und ich mit Blitz den Client. Einmal die Woche treffen und sich auf das Netzprotokoll einigen und schon kann man unabhängig von einander schreiben, was alles ein bisschen einfacher macht.

Cykid

Mi, Jun 17, 2015 16:33
Antworten mit Zitat

Ich hab unglaublich viel Spaß daran kleine "Engines" zu entwickeln. Dabei überleg ich mir immer ein Genre (In diesem Fall ein Top Down Shooter) und bastel mir dann alle spielmechaniken zusammen, so das ich im Finalen Projekt nur noch "Editor Mäßig" Meine Funktionen Platzieren muss^^
Also ich überlege immer, welche Spielmechaniken brauch ich und wie mache ich daraus ein Spiel.

Schwer finde ich die Planung wenn man im Team arbeitet. Grafiker und Programmierer verstehen sich noch ganz gut, Programmierer und Programmierer hingegen.... Very Happy

Da ist es verdammt wichtig das man Modular plant damit man sich nicht ins gehäge fuscht.

Im Aktuellen Fall entwickel ich ein "Co op Bosskampf irgendwas" Very Happy

Mein Mate schreibt dabei den Server in C++ und ich mit Blitz den Client. Einmal die Woche treffen und sich auf das Netzprotokoll einigen und schon kann man unabhängig von einander schreiben, was alles ein bisschen einfacher macht.

	Krumu1201 Betreff: Danke	Do, Jun 18, 2015 11:17 Antworten mit Zitat
für die Antworten. Ich sollte meine Projekte in Zukunft wohl mehr planen😁. @DAK Benutzt ihr UML für die Planung eurer Projekte bei deiner Arbeit? @Cykid Dürfte ich mal ein kleines Beispiel von einer deiner Engines sehen? Gruß Krumu1201

Krumu1201

Betreff: Danke

Do, Jun 18, 2015 11:17
Antworten mit Zitat

für die Antworten. Ich sollte meine Projekte in Zukunft wohl mehr planen😁.

@DAK Benutzt ihr UML für die Planung eurer Projekte bei deiner Arbeit?

@Cykid Dürfte ich mal ein kleines Beispiel von einer deiner Engines sehen?

Gruß Krumu1201

	DAK	Do, Jun 18, 2015 11:42 Antworten mit Zitat
Teilweise. Wir verwenden es nicht wirklich zum Planen im Großen, sondern hauptsächlich dann, wenn wir einen Punkt verstehen müssen, der ohne UML nicht so leicht verständlich ist. Also z.B. wenn es um eine Interaktion geht, die etwas komplexer ist, um sie zuerst quasi am Blatt zu sortieren, oder wenn einer von uns dem Anderen eine Idee vermitteln will, die sich ohne nicht so leicht vermitteln lässt. UML haben wir also nur für die Detailplanung und dann auch meistens nicht standardkonformes UML sondern eher UML-artige Skizzen. Also die ganzen speziellen UML-Symbole verwenden wir sehr selten.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Do, Jun 18, 2015 11:42
Antworten mit Zitat

Teilweise.

Wir verwenden es nicht wirklich zum Planen im Großen, sondern hauptsächlich dann, wenn wir einen Punkt verstehen müssen, der ohne UML nicht so leicht verständlich ist. Also z.B. wenn es um eine Interaktion geht, die etwas komplexer ist, um sie zuerst quasi am Blatt zu sortieren, oder wenn einer von uns dem Anderen eine Idee vermitteln will, die sich ohne nicht so leicht vermitteln lässt.
UML haben wir also nur für die Detailplanung und dann auch meistens nicht standardkonformes UML sondern eher UML-artige Skizzen. Also die ganzen speziellen UML-Symbole verwenden wir sehr selten.

Gewinner der 6. und der 68. BlitzCodeCompo

	Xeres Moderator	So, Jul 05, 2015 18:13 Antworten mit Zitat
~AUFSPALTUNG~ Hinweis zur Verlinkung von Bildern im Portal
Win10 Prof.(x64)/Ubuntu 16.04\|CPU 4x3Ghz (Intel i5-4590S)\|RAM 8 GB\|GeForce GTX 960 Wie man Fragen richtig stellt \|\| "Es geht nicht" \|\| Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld)

Xeres

Moderator

So, Jul 05, 2015 18:13
Antworten mit Zitat

~AUFSPALTUNG~

Hinweis zur Verlinkung von Bildern im Portal