spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Hallo,
hab dir da mal was rausgesucht(hat mir persönlich auch geholfen):
http://blog.slickedit.com/2007/05/how-to…esign-document/

(Ich selbst habs aber auch nur googlet)

Scrum und Pair Programming sind 2 Stichworte die ihr euch mal in google anschauen solltet

Anderes Stichwort: Versionsverwaltung.
Aber bitte nicht SVN oder gar CVS! Lieber mercurial , git oder bazaar !

Xardias sagt es: mit Scrum hast du eine sehr agile projektmanagementmethode, die supereinfach und flexibel ist. das prinzip ist dabei einfach: ihr legt euch "grobe" beschreibungen an, was getan werden muss. diese nennt man stories. das sollten aufgaben sein wie "Statemanagement" "MainMenu" usw. Diese "Stories" verfeinert man zu "Tasks". Je story kannst du 1-n tasks haben, je nach dem wie aufwendig die story ist. dann plant ihr einfach entsprechend stories in einen so genannten "sprint" ein. in der regel geht der zwei wochen, bei heimproduktionen würde ich die länge nicht sooo genau nehmen. aber: je genauer; desto besser. in der regel nimmt man 2- bis 4-wochensprints. in dieser zeit sollten alle Stories abgearbeitet werden, in dem ihr alle dazugehörigen Tasks löst. Derjenige, der den Task bearbeitet, stellt in auf in zu prüfen und der andere schaut sich das ganze an und weist zurück, falls nicht ok usw. bis die task erledigt ist.
es ist laut scrum erlaubt, zwischendurch änderungen am sprint mit stories und tasks zu machen, da es sich um agiles management handelt.
wenn du fragen hast: frag gern wir nutzen es auf arbeit

ansonsten software kann ich dir in-step scrum edition empfehlen: in-step download

Zu VersionsverwaltungVN ist für 2 mehr als ausreichend und hatte da nie probleme und mit tortoise svn ist das ganze sehr einfach zu bedienen.

Ich arbeite derzeit alleine an meinen Projekte, da fange ich immer mit einem Blatt Papier und einem Stift an. Ich schreibe mir die Sachen auf, die ich glaube zu brauchen. Dann packe ich diese Ideen sortiert in eine Wiki und ToDo Listen. Dadurch bekomme ich eine ungefähre Übersicht über den Projektumfang.
Die Punkte beschreiben meisten das Projekt: eingesetzte Techniken, Features, Nice-to-have Sachen, Aufbau und Struktur, etc.
Dann picke ich mir einzelne Punkte raus die ich nach und nach abarbeite. Je nachdem wieviel Zeit mir zur Verfügung steht nehme ich große oder kleine Aufgaben. Habe ich sehr wenig Zeit, dann fixe ich in der Regel nur ein paar Bugs.
Ich setze auch eine Versionsverwaltung ein, SVN mit TortoiseSVN. Damit bin ich sehr zufrieden.

@ Oberon: Warum sollte man denn SVN meiden?

Zitat von »MCP«

@ Oberon: Warum sollte man denn SVN meiden?

Ich gebe einfach mal meinen Senf dazu.
Für ein zwei-man-Projekt hat z.B. Git gegenüber SVN den vorteil, das man keinen zentralen server braucht, sondern jeder lokal seine history hat, und fortschritte aus dieser in form von patches herausgezogen werden, die dann der jeweils andere übernimmt.
Für ein größeres projekt, wo man ohnehin einen zentralen server braucht, weil es sonst chaos gibt, sollte man imo wiederrum ein zentrales system wie SVN bevorzugen, damit niemand in Versuch kommt, am zentralen repositry vorbeizuarbeiten.

Warum man besser ein verteiltes Versionskontrollsystem nimmt erklärt glaube ich dieser Podcast ganz gut: CRE130 Verteilte Versionskontrollsysteme.

@TrommlBomml: Das in-step sieht ganz gut aus. An der Hochschule müssen wir trac für das Projektmanagement benutzen, was absolut nicht funktioniert. Man hat nur doppelte und dreifache Arbeit, um die Scrum Artefakte zu erstellen. Nach einer Beschwerde haben die Dozenten dann was daran geändert und Agilo eingeführt. Ganz tolle Idee, weil dadurch die ganzen Tickets von trac zerschossen wurden und wir ca 400 Tickets neu eintragen durften ... und besser ist es dadurch auch nicht geworden. Da wäre in-step schon ne gute Alternative, aber nur mit dem Web-Client. Gibt es die Scrum Edition auch als Webclient?

Zu Scrum: Im 2 Mann Team fallen dann ja die Rollen, wie Product Owner und Scum Master weg. Eigentlich bleibt nur noch das Team über. Wodurch man dann ja nicht wirklich Scrum benutzt, sondern einfach einen agilen Prozess.
Gut bei agilen Prozessen ist, finde ich, dass man sich immer kurzfristige Ziele setzt und dadurch nach kurzer Zeit schon was vorzeigbares hat. Von Scrum finde ich die Meetings gut. Daily scrum zeigt schnell, wie weit man ist und wo aktuell Probleme sind, Review Meeting ist super fürs Feedback von den anderen und im Retrospective Meeting kann man gut analysieren, was in dem letzten Sprint gut bzw. schlecht gelaufen ist und sich dann das dann im nächsten Sprint verbessern.

Pair programming kann auch gut funktionieren. Das würde ich aber eher bei kniffligen Stellen einsetzen. Wenn man das zu häufig macht, kann das schnell zu Streit führen, weil der Programmierer sich schnell auf den Schlips getreten fühlen kann (kenn ich aus eigener Erfahrung). Stattdessen kann man auch Code- Reviews machen. Der Unterschied ist, dass der Reviewer nicht neben einem sitzt und einem auf die Finger schaut. Aber eins von beiden würde ich auf jeden Fall machen, da das zu besserer Software führt.