Teamarbeit koordinieren, Konzept erstellen

[JVTH]

Hi Leute,
ich möchte, zusammen mit meinem Bruder ein Spiel entwickeln. Da wir beide Erfahrung in der Spieleentwicklung mit Java haben, würden wir uns gerne an etwas größeres heranwagen, ein 3D-Raumschiff Spiel. Es gibt Stationen und Systeme, welche durch Wurmlöcher verbunden sind. Um jedoch nicht einfach blöd drauflos zu programmieren müssen wir uns irgendtwie absprechen. Ich vermute, dass hierzu ein Konzept am besten wäre, um die Verteilung zu regeln, oder wie geht die Koordinierung?
Danke JVTH

[Niki]

Da beissen sich Theorie und Praxis. Die Theorie sagt, dass man erstmal ein Pflichtenheft schreibt welches dann abgenommen wird. Danach schreibt man dann ein ausführliches Konzept und "bereitet die Entwicklung vor". Laut Theorie bist Du da erstmal 2/3 der Entwicklungszeit mit Papierkram beschäftigt. Gelehrt wird einem diese Theorie an Schulen. Ein Hoch auf die Schulen, denn die Praxis sieht da, mit Ausnahmen, ganz anders aus. Da sagt keiner "Ich bezahle dir jetzt mal ein halbes Jahr Papierkram und dann fängst du gemütlich mit der Programmierung an". Stattdessen wird man Dich fragen: "Wann können wir die ersten Resultate sehen? Wir benötigen dringend eine Version für ein wichtiges Meeting mit unseren Investoren!". Bei 99% der Projeke die ich beruflich erledige programmiere ich schon bevor überhaupt ein Konzept fertig ist, oder die ersten Assets vorhanden sind. Alles was da ist, sind ein oder zwei Vorbereitungsmeetings.

Wie geht das? Mit Erfahrung! Zum Beispiel macht man Erfahrungen damit, welche Programmierer für welche Tasks am besten geeignet sind, und dementsprechend verteilt man die Aufgaben. Und die Programmierer lernen mit der Zeit welche Techniken sie noch nie im Stich gelassen haben. Und das geht, denn irgendwie scheinen dieselben Aufgaben immer wiederzukehren.

Was icht damit sagen will ist... Ja, ihr braucht einen Plan. Ja, ihr müsst die Aufgaben sinnvoll verteilen. Ja, Ihr müsst Euch regelmässig absprechen und akuelle Probleme diskutieren. Ja, ein grobes Konzept ist eine gute Sache, aber ich würde da nicht zu viel Zeit reinstecken. Schreibt das auf was wesentlich ist, wie Dinge die auf keinen Fall schiefgehen dürfen um das angepeilte Ziel erreichen zu können. Aber ein hochdetailiertes Konzept zu schreiben ist, aus meiner Sicht, oft reine Zeitverschwendung, denn Konzepte ändern sich während der Entwicklung. Dieses ist besonders bei kreativen Programmen, wie Spielen der Fall. Da muss man ganz einfach flexibel genug sein um Konzeptänderungen umsetzen zu können.

Anders sieht das natürlich aus, wenn Du beispielsweise SDK's schreiben musst die hinterher von ewig vielen Programmierern genutzt werden, wie z.B. das .NET Framework oder das DirectX SDK. In solchen Fällen braucht man natürlich einen sehr viel ausgeklügelteren Plan. Aber das ist ja hier nicht der Fall. Ihr wollt Spiele machen, und das bedeutet kreativ und flexibel zu sein.

[MadMax]

Da beissen sich Theorie und Praxis. Die Theorie sagt, dass man erstmal ein Pflichtenheft schreibt welches dann abgenommen wird. Danach schreibt man dann ein ausführliches Konzept und "bereitet die Entwicklung vor". Laut Theorie bist Du da erstmal 2/3 der Entwicklungszeit mit Papierkram beschäftigt. Gelehrt wird einem diese Theorie an Schulen. Ein Hoch auf die Schulen, denn die Praxis sieht da, mit Ausnahmen, ganz anders aus. Da sagt keiner "Ich bezahle dir jetzt mal ein halbes Jahr Papierkram und dann fängst du gemütlich mit der Programmierung an". Stattdessen wird man Dich fragen: "Wann können wir die ersten Resultate sehen? Wir benötigen dringend eine Version für ein wichtiges Meeting mit unseren Investoren!". Bei 99% der Projeke die ich beruflich erledige programmiere ich schon bevor überhaupt ein Konzept fertig ist, oder die ersten Assets vorhanden sind. Alles was da ist, sind ein oder zwei Vorbereitungsmeetings.

Wie geht das? Mit Erfahrung! Zum Beispiel macht man Erfahrungen damit, welche Programmierer für welche Tasks am besten geeignet sind, und dementsprechend verteilt man die Aufgaben. Und die Programmierer lernen mit der Zeit welche Techniken sie noch nie im Stich gelassen haben. Und das geht, denn irgendwie scheinen dieselben Aufgaben immer wiederzukehren.

Das ist Unsinn. Das mag vieleicht für kleine ein zwei man Projekte funktionieren aber größere Projekte schießt du dir so ins Bein.

[Schrompf]

Das ist Unsinn. Das mag vieleicht für kleine ein zwei man Projekte funktionieren aber größere Projekte schießt du dir so ins Bein.

Das solltest Du etwas weniger aufdringlich formulieren. Nach meiner Erfahrung passiert nämlich genau das, auch in wirklich großen Projekten. Und um dieses Vorgehen sinnvoll in spätere finale Ergebnisse einzubetten, wurde ja SCRUM, Agile Development und wasweißichnoch erfunden.

[Niki]

Na, ja, aufdringlich oder nicht, das soll mir egal sein. Ein wenig Kritik hat noch niemandem geschadet, auch wenn ich mir da ein wenig mehr Content zur Kritik gewünscht hätte.

Aber es sagt ja auch niemand, dass fast unveränderliche, hochdetaillierte Konzepte nirgendwo existieren. Wenn Du, MadMax, diese Erfahrung gesammelt hat, dann hast Du echtes Glück gehabt, und das gönne ich Dir auch. Da kommt sogar ein wenig der Neid in mir auf. Arbeitest Du zufällig für eine sehr bekannte und grosse Spieleschmiede mit hervorragenden Finanzen? Womöglich entscheidet Ihr sogar selbst, welche Art Spiel Ihr als nächstes angeht? (im Gegensatz zu Auftragsarbeit). Das würde so einiges erklären.

[Chromanoid]

Ohne detaillierte Feature/Todoliste und User Stories lässt sich Scrum nicht umsetzen. Alle größeren Spieleschmieden arbeiten mit Scrum. Das sagen jedenfalls viele Stellenausschreibungen und mir wurde das auch mehrfach auf einer Making Games Talents Veranstaltung mitgeteilt. Traditionelle Dienstleister müssen sowieso mit Pflichtenheft arbeiten, da die Erfüllung der Dienstleistung gar nicht anders einvernehmlich feststellbar ist. In der Spielebranche mag es da viel mehr Wildwuchs geben, aber für langfristig erfolgreiches Arbeiten sind definierte wiederholbare Prozesse unerlässlich. Das siehst Du doch sicher genauso?

[Niki]

Traditionelle Dienstleister müssen sowieso mit Pflichtenheft arbeiten, da die Erfüllung der Dienstleistung gar nicht anders einvernehmlich feststellbar ist.

Das will ich an dieser Stelle nochmal unterstreichen, weil sich meine Aussage in der Tat so liest als wäre das Pflichtenheft nicht wichtig. Bei Auftragsarbeiten ist das wichtig, da es Vertragsgegenstand ist.

@Alle: Mir scheint das ich hier für ein wenig Chaos und Misverständnis gesorgt habe, und das letzte was ich herbeiführen will ist Zank im Forum. Deshalb möchte ich im Bezug auf meine erste Post etwas deutlich machen:

A ist keine Teilmenge von B. Deshalb kann B auch keine Teilmenge von A sein. Falsch!
Ich habe keine 10 Euro. Deshalb habe ich gar kein Geld. Falsch!
Ich opfere nicht 2/3 der Gesamtentwicklungszeit eines Projektes dem Papierkram. Deshalb habe ich gar keinen Plan, schreibe gar kein Konzept, habe gar keine Todo-Liste, etc. Auch falsch!

Null Papierkram in der Hand zu haben ist noch schlimmer als dem Papierkram zu viel Zeit zu geben. Aus "zu viel Zeit" lässt sich nicht schliessen das dem Papierkram gar keine Zeit gegeben wird. Es gilt ein sinnvolles Mass zu finden, und dieses ändert sich in der Regel mit der Grössenordnung und Komplexität eines Projektes.

[JVTH]

Danke für die vielen Antworten. Wir haben jetzt ein grundlegendes Konzept erstellt. Also, was das Spiel alles können soll. Da das jedoch sehr umfangreich war, machen wir jetzt erstmal die Basics fertig(Welt) und werden uns dann an die anderen Sachen machen(Netzwerk, Gui, Ki). Wir programmieren also doch mal "drauflos".

[simbad]

Ihr solltet euch vielleicht ein paar kleine Meilensteine setzen und schauen das ihr die erreicht.
Was zu den Zeitpunkten fertig sein soll, kann man auch leicht definieren.
Damit bekommt ihr etwas in die Hand womit ihr eure Leistungsfähigkeit besser einschätzen lernt. Es geht mir bei diesem Vorschlag darum, nicht die Ziele aus dem Blick zu verlieren und eine Erfolgskontrolle zu bekommen.
Wenn man dann irgendwann mal doch einen findet, der das finanziert, dann kann man zeigen, das man seine Ziele auch erreicht.

[JVTH]

Meilensteine setzen, das klingt gut. Wir werden dann eine grundlegende Liste erstellen. Danke.

[simbad]

Zu den Meilensteinen solltet ihr immer Software fertig haben die ihr auch, so gut euch das möglich ist, getestet habt.
Dann könnt ihr mit jedem Erreichen, euch auf die Schulter klopfen und sagen "gut gemacht. Nächster Punkt".
Das verhindert ein bisschen den Wildwuchs und das entstehen von dutzenden von Enden, die alle nicht fertig sind und nicht so richtig zusammenpassen wollen.