Hi,Leutz....
überlege gerade wie man am besten ein Projekt organisiert und managed wenn
man mal ein paar Leute gefunden hat die damit mitarbeiten würden!

Wenn man z.B im hier im Forum ein Projekt anbietet und Interesse besteht
wie gehts dann weiter... weitere Diskusionen,Daten austausch etc. kann man doch schlecht im Forum austragen...also eigene HP(dann bräuchte man schon wieder jemmanden der sich ja nur darum Kümmert)...stell mir eh die ganze Komunikation sehr schwer vor!
Muss die Person die das Project vorgeschalgen hat automatisch Projektleiter/manager sein?

Wie sind da so eure Erfahrungen, wie sollte man das ganze angehen...

mfg Hulk

Der der sie Idee hatte muss nicht zwangsläufig der Projektleiter werden er ist nur meist im vorteil weil er weiß was er sich gedacht hat als er die Projektidee online gestellt hat.

Die Organissation wenn die Leute weit vertreut sind ist meist recht einfach über ein Forum zu regeln (Blos ein Forum mit ein paar membern braucht ja auch fast keine Betreuung)

meine erfarungen mit spontanen projekten sind eher gemischt bei non Provit projekten eigendlich zu 80% negativ

Zitat

Original von S.H.-Teichhof meine erfarungen mit spontanen projekten sind eher gemischt bei non Provit projekten eigendlich zu 80% negativ

Die Erfahrung habe ich leider auch gemacht. Die Motivation ist am Anfang noch sehr, sehr hoch, schwindet aber dann sehr schnell.

Eigentlich schade, denn ich hätte große Lust mal an einem größeren Projekt mitzuwirken.

Allein oder zu zweit klappt sowas immernoch am besten. Man kann so allerdings nicht unbedingt die größten Brötchen backen. Wenns mehr Leute sind scheitert es oft an verschiedenen Vorstellungen. Auf jeden Fall sollte sich das Team möglichst gut kennen, bevor man Projekte macht. Mit lauter wildfremden Leuten, von denen man nicht mehr weiß, als ihren Forums-Nickname, kann das eigentlich nur in die Hose gehen.

Auf jeden Fall einzelne, möglichst autonome, Komponenten entwickeln und keine großen Anwendungen. Wenn man zu lange auf sichtbare Ergebnisse warten muss, ist der anfängliche Eifer gleich dahin.

Was ich als extrem hilfreich ansehe, wenn man im Team entwickelt:

- Contract First Design, sprich, zu Beginn werden nur Interfaces besprochen und festgelegt, danach entwickelt jeder für sich abgeschottete Komponenten. Das Zusammenspiel funktioniert nachher, da alles über Interfaces verbunden wird.

- Eine Versionsverwaltung. Anders geht die Entwicklung im Team letztlich nicht sinnvoll.

- Ein Buildserver, der unter Umständen Werkzeuge wie Unittesting, Code Coverage, ... einbindet, ist ebenfalls extrem hilfreich.

Ansonsten, was die Planung angeht - wenn sich das Team kennt, häufige, aber kurze Statusmeetings (Stichwort SCRUD), ansonsten regelmäßig Chats. Was sich bei uns in der Firma auch als sehr hilfreich erwiesen hat, sind häufige Code Reviews, wobei es da natürlich egal ist, ob sich das Team kennt oder nicht.

Ach ja, und von vornherein Code Guidelines festlegen ...

Danke schon mal für eure Beiträge, finds schade das es "nur" negative Erfahrungen mit freien Projekten gibt, wie könnte man den dem Vorbeugen?
- Direktes Ziel mit Zeitplan?
- Nur Leute nehmen die wirklich interesse haben(nur wie findet man die?)
- nur "kleine Projekte"

Würde gern ein Projekt hier vorstellen, denke aber das es gerade an der Kommunikation
happern wird!Wie schauts denn aus wenn ein Projekt schon zum Teil geschrieben wurde,oder zumindest rudimäntäre Ansätze da sind ist das hilfreich oder störend?
Sollte man auch drauf achten das die Programmier ungefähr die selbe Erfahrung haben?

mfg Hulk

für das Projekt posiv wäre auf jeden fall wenn versucht würde immer eine Motivation zum arbeiten zu schaffen. also z.B "fester" zeitplan oder regelmäsiege veröffentlcihungen

Anmerkungen:
Nach meinen Erfahrungen sollten Interfaces nicht im gesamten Team besprochen werden(jedenfalls nicht im Sinn von Festlegung)
Beim Mittel des Codereviews ist es auch besser wenn sich sich Reviewer und Programmierer nicht sogut kennen.
Bei derartigen Projekten ist die Zeitplanung auch etwas schwierig da Leute unverhofft abspringen/pausieren und es an gleichwertigen Ersatz mangelt.
Wichtig ist daher Flexibilität in Planung und Controlling. Je nach Skills müssen dann die Aufgaben schnell umverteilt werden können.
Motivation ist wichtig, ob regelmässige Veröffentlichung dazugehört wage ich zu bezweifeln(Die Regelmässigkeit sollte der Angemessenheit unterworfen sein).

Zitat

Wie schauts denn aus wenn ein Projekt schon zum Teil geschrieben wurde,oder zumindest rudimäntäre Ansätze da sind ist das hilfreich oder störend?

Je nachdem, es sollte dich aber nicht stören wenn der Code verworfen oder im Lauf des Projekts völlig verändert wird wenn er nicht passt. Hilfreich ist es allemal wenn die "Mittäter" dadurch schneller begreifen können was es mal werden soll, bzw. wohin es geht.

Mit Fremden zu entwickeln kann sehr anstrengend werden. Deswegen erstmal kleine Brötchen backen bis man sich etwas kennt.

Zeitplan ist gut, man muss nur auch berücksichtigen, dass es ein Freizeitprojekt ist. Also die Schätzungen schonmal pauschal verdoppeln Wenn was eher fertig ist, ist es einfacher den Zeitplan vor zu verlegen, als sich den Stress anzutun jemandem hinterherzulaufen und sich gegenseitig auf die Nüsse zu gehen.

Ich persönlich hab über Erweiterungen von existierendem Code ja das Programmieren angefangen. Ich kann mich ganz gut in was Bestehendes einarbeiten. Keine Ahnung wie es da anderen geht.

Zitat

Original von Traumzauberbaum Zeitplan ist gut, man muss nur auch berücksichtigen, dass es ein Freizeitprojekt ist. Also die Schätzungen schonmal pauschal verdoppeln

Ist das nicht schon die Faustregel bei "normalen" Projekten?

Zitat

Ist das nicht schon die Faustregel bei "normalen" Projekten?

Nur aus Entwicklersicht.

Nur wenn die Tür zum Chef zu ist