mmofacts.com

Im Team entwickeln.

gepostet vor 15 Jahre, 4 Monate von Jackflash

Hi,

ich habe bis jetzt meine Arbeiten von A bis Z alleine auf die Beine gestellt. Jetzt möchte ich allerdings anfangen mein Projekt mit hilfe eines kleinen Teams (bis jetzt 3) neu auf die Beine zu stellen.

Leider habe ich keine wirkliche Erfahrung, wie ich das organisatorisch am besten umsetze. Wenn ihr im Team entwickelt, welches Setup habt ihr da am Start, gibt es da evtl. Open Source Software die hilfreich sein kann? z.B. so was wie Online <-> Localhost Synchronisation der Versionen. Hat jemand Stichworte für die Suchmaschine, die mich schlauer machen?

Vielen Dank schon mal.

gepostet vor 15 Jahre, 4 Monate von tector

Versionsverwaltung (Subversion) und Projektverwaltung (z.b. TRAC)

gepostet vor 15 Jahre, 4 Monate von D4rk5in

Wir haben mal im Team eine Software benutzt, die sich "projectplace" nennt.

War auf jeden Fall eine gute Wahl.

gepostet vor 15 Jahre, 4 Monate von Apocalyptica

Wir benutzen Perforce (Softwaremanagementsystem) bis zu 2 Clients kann man das umsonst benutzen, danach kostenpflichtig. Wir finden es das Beste was es überhaupt gibt. Super schnelle und super viele Funktionen. Ist jeden Cent wert :)

gepostet vor 15 Jahre, 4 Monate von dreaddy

Versionsverwaltung(CVS, SVN oder wasauchimmer) brauchst du auf jeden Fall, der Rest wird bei einem kleinen Team eher überbewertet meiner Meinung nach und wird erst ab einer Größe von ca 5 dauerhaften aktiven Leuten interessant.
Was bringen die tollsten Groupwarefunktionen, Chat, Foren, Rundmails, Kontaktdaten, servergesteuerte Dateiverwaltung und Rechteverwaltung, wenn man das auch schneller und übersichtlicher per Skype, Openoffice und Outlook erledigen kann.

Oder zusammengefasst: wichtig ist Versionsverwaltung und ein guter Informationsaustausch der Mitglieder, damit jeder weiß was er zu tun hat und nichts falsches tut, alles Andere hängt vom Team und der Teamleitung ab, jeder Mensch ist unterschiedlich und kann unterschiedlich gut mit gewissen Medien umgehen.
Kenne auch viele Leute, die nichtmal online arbeiten könnten ;).

gepostet vor 15 Jahre, 4 Monate von Dunedan

Ich finde auch in kleinen Teams gehört neben einer Versionsverwaltung noch ein Ticketsystem und ein Wiki dazu. Sind beides einfach essenzielle Anwendungen die vieles vereinfachen.

gepostet vor 15 Jahre, 3 Monate von rash

Wir (5 aktive Programmierer) arbeiten mit SVN und einem Internen Board.

Bisher hatten wir damit nie Probleme und haben gute Resultate erzielt.

gepostet vor 15 Jahre, 3 Monate von Spiriter1982

wir (1 Programmierer und ich) arbeiten mit SVN, Forum und ICQ. funzt perfekt. bei einem größeren team welches rein übers Inet operiert würde ich wie Dunedan schon sagte zusätzlich mit einem Ticketsystem arbeiten, ansonsten können telefonate über skype auch sehr hilfreich sein.

gepostet vor 15 Jahre, 3 Monate von DrakeL

Ich arbeite derzeit alleine an einem neuen privaten Projekt mit Bazaar/TortoiseBzr (benötigt im Gegensatz zu SVN keinen Server, sondern kann auch per FTP auf einem normalen Webspace bereitgestellt werden) und Mantis Bugtracker. Bugtracker finde ich in kleinen Teams nicht unbedingt notwendig, aber ich finde es für die Übersicht gut, da ich genau sehe was noch zu tun ist und keine Aufgaben oder Ideen verloren gehen.

gepostet vor 15 Jahre, 2 Monate von zakx

Ich empfehle git. git ist vor allem schnell und kompatibel, außerdem wirklich verteilt, im Gegensatz zu anderen VCS. Gleichzeitig ist git GPL und somit uneingeschränkt umsonst nutzbar. Die Einarbeitungszeit ist geringer als bei SVN oder CVS.
Mehr Vorteile hier: http://en.wikipedia.org/wiki/Git_(software)#Characteristics

gepostet vor 15 Jahre, 2 Monate von TheUndeadable

> Gleichzeitig ist git GPL und somit uneingeschränkt umsonst nutzbar.

Der Nachteil ist:

Es läuft unter Windows mehr als beschissen. Aus diesem Grund habe ich mich mittlerweile für Mercurial entschieden.

gepostet vor 15 Jahre, 2 Monate von knalli

Original von zakx

Ich empfehle git. git ist vor allem schnell und kompatibel, außerdem wirklich verteilt, im Gegensatz zu anderen VCS. Gleichzeitig ist git GPL und somit uneingeschränkt umsonst nutzbar. Die Einarbeitungszeit ist geringer als bei SVN oder CVS.
Mehr Vorteile hier: http://en.wikipedia.org/wiki/Git_(software)#Characteristics

Wow, 'ne eierlegene Wollmilchsau: schnell, kompatibel, verteilt (buzz), vcs, gpl (!!), uneingeschränkt, umsonst.. Mannometer, nobelpreisverdächtig.

Jetzt mal Klartext: Welche Gründe sprechen für dich jetzt für git? Ich will nicht die Daseinsberechtigung von distributierten Versionskontrollsystem absprechen, aber deine genannten Gründe sprechen auch für SVN und sogar CVS. Abgesehen davon, dass es eben "verteilt" ist - und das ist keine reguläre Eigenschaft eines "normalen" Versionskontrollsystemes. Auch die Einarbeitungszeit ist wohl ähnlich, und lässt sich in beiden Fällen sinnvoll durch den Einsatz von Werkzeugen effizienter durchführen.

Selbstverständlich ist git durch den Einsatz des lokalen Repository schneller; aber man kann auch SVNs lokal anlegen. Benötigt natürlich mehr Speicherplatz, aber das benötigen git/mercurial eh :)

Bitte nicht falsch verstehen: Ich will hier nicht git schlecht reden, aber anstatt irgendwelche Pseudo-Vorteile statt echten Vorteilen in die Welt zu posten, wäre eine differenzierte Ansicht nicht verkehrt. Die Arbeitsvorgänge zum "Syncen" der lokalen und entfernten Version ist natürlich einfacher, sowie das Arbeiten in Branches auf einer Art und Weise, wie die es ein SVN nicht kennt. Aber für jemanden, der wahrscheinlich das erste Versionskontrollsystem benötigt, ist dies einfach irrelevant. Und es soll  tatsächlich Leute (Firmen) geben, die die Zentralität schätzen. 

Google Code setzt übrigens auf Mercurial, falls wer also dort bereits hostet (oder hosten will) und sich distributed version control mal angucken möchte.

gepostet vor 15 Jahre, 2 Monate von TheUndeadable

Schön ist auch, dass Mercurial experimentell Subrepositories unterstützt [1], was die Funktionalität von svn:externals abbilden soll.

Leider erst ab Version 1.3. Dies läuft zwar bei mir auf dem Desktop wunderbar, aber auf meinem VServer für Quellcodeverwaltung werde ich wohl noch zwei Jahre warten, bis Debian sich entschließt die Version freizugeben.

Den Sourcecode für Version 1.3 habe ich nicht auf einem Pinguin-System zum Laufen bekommen. Da lob ich mir doch Installer. Aber egal, sollte nicht Thema des Threads sein, hauptsache es läuft teilweise.

http://mercurial.selenic.com/wiki/subrepos

gepostet vor 15 Jahre, 2 Monate von FlashingPumpkin

Original von TheUndeadable

Leider erst ab Version 1.3. Dies läuft zwar bei mir auf dem Desktop wunderbar, aber auf meinem VServer für Quellcodeverwaltung werde ich wohl noch zwei Jahre warten, bis Debian sich entschließt die Version freizugeben.

Den Sourcecode für Version 1.3 habe ich nicht auf einem Pinguin-System zum Laufen bekommen. Da lob ich mir doch Installer. Aber egal, sollte nicht Thema des Threads sein, hauptsache es läuft teilweise.

http://mercurial.selenic.com/wiki/subrepos

http://packages.debian.org/squeeze/mercurial

gepostet vor 15 Jahre, 2 Monate von TheUndeadable

Original von FlashingPumpkin

Original von TheUndeadable

Leider erst ab Version 1.3. Dies läuft zwar bei mir auf dem Desktop wunderbar, aber auf meinem VServer für Quellcodeverwaltung werde ich wohl noch zwei Jahre warten, bis Debian sich entschließt die Version freizugeben.

Den Sourcecode für Version 1.3 habe ich nicht auf einem Pinguin-System zum Laufen bekommen. Da lob ich mir doch Installer. Aber egal, sollte nicht Thema des Threads sein, hauptsache es läuft teilweise.

http://mercurial.selenic.com/wiki/subrepos

http://packages.debian.org/squeeze/mercurial

Danke, das ist doch mal eine Perspektive.

Dann kann ich ja langsam anfangen meine Projekte umzustellen.

gepostet vor 15 Jahre, 2 Monate von knalli

Dazu: Google hat vor wenigen Tagen Subrepos ebenfalls freigeschaltet. Im konkreten Fall werden per Default das Wiki und der Code getrennt, aber man kann das selbständig managen.

Auf diese Diskussion antworten