Hallo,
ich bin seit 5 Jahren leidenschaftlicher PureBasic Programmierer, und studiere Telematik an der TU Graz.
Bis jetzt habe ich meine PureBasic Projekte immer alleine durchgeführt.
Seit einigen Wochen schwebt mir die Idee von einem umfangreichem Gemeinschaftsprojekt vor.
Natürlich weis ich, dass man bei so einem Projekt nicht einfach loslegen kann, sondern dass eine genaue Planung wichtiger als alles andere ist.
Für mich stellt sich die Frage, ob und wie man Gemeinschaftsprojekte ohne persönlichen Kontakt erfolgreich kann durchführen kann.
Eure Erfahrungen, Meinungen und Tipps würden mich sehr interessieren.
Erfahrungen über Gemeinschaftprojekte
Aus meiner Erfahrung heraus kann ich nur ein paar Tipps geben:
1. Wenn es geht, auf lokal erreichbare Mithelfer bauen, so kann zur Not auch mal ein "Machtwort" gesprochen werden, falls jemand zu sehr aus dem Rahmen fällt. Zudem sind die Bindungen so höher (jemanden den man kennt, lässt man nicht so schnell im Stich wie jemanden, den ich im ICQ auf die Ignore schieben kann). Aus diesem Grund ist es auch immer gut mit Leuten zu werkeln, die man vllt einfach schon länger kennt.
2. Einen ausgeklügelten Plan haben. Leider bin ich bisher immer zu der Erkenntnis gekommen, dass ein Projekt nicht vollständig vorhersehbar ist. Immer wieder stoße ich auf Probleme, die ich vorher nicht bedacht habe. Trotzdem den anderen zeigen, dass man weiss, wo es lang gehen soll.
3. Einen gewissen Termindruck erzeugen. Wenn alles lau vor sich her laufen kann, ist die Leistung der Einzelnen nicht allzu hoch. Wenn man immer etwas (!!!) Druck ausgesetzt ist, ist man mehr bei der Sache.
Ist zwar alles sehr allgemein, aber was soll man sagen
Hoffe hilft dir weiter
1. Wenn es geht, auf lokal erreichbare Mithelfer bauen, so kann zur Not auch mal ein "Machtwort" gesprochen werden, falls jemand zu sehr aus dem Rahmen fällt. Zudem sind die Bindungen so höher (jemanden den man kennt, lässt man nicht so schnell im Stich wie jemanden, den ich im ICQ auf die Ignore schieben kann). Aus diesem Grund ist es auch immer gut mit Leuten zu werkeln, die man vllt einfach schon länger kennt.
2. Einen ausgeklügelten Plan haben. Leider bin ich bisher immer zu der Erkenntnis gekommen, dass ein Projekt nicht vollständig vorhersehbar ist. Immer wieder stoße ich auf Probleme, die ich vorher nicht bedacht habe. Trotzdem den anderen zeigen, dass man weiss, wo es lang gehen soll.
3. Einen gewissen Termindruck erzeugen. Wenn alles lau vor sich her laufen kann, ist die Leistung der Einzelnen nicht allzu hoch. Wenn man immer etwas (!!!) Druck ausgesetzt ist, ist man mehr bei der Sache.
Ist zwar alles sehr allgemein, aber was soll man sagen
Hoffe hilft dir weiter
Ich finde eine Aufteilung auf die Personen sehr wichtig.
Das jeder weiß was seine Aufgabe ist. Wobei aber auch jeder zugang zum "Gesammten" hat um beraten zu können oder mal nen tip loswerden kann oder einfach mal ne Idee durchspielt.
Keine Geheime Aktionen oder Codes für sich behalten.
Regelmäßig sitzungen abhalten.
Teilnehmer müßen die möglichkeit haben sich auszuklinken. Weil es gibt auch wichtigeres.
Tolles Thema. bin mal gespannt was die Profis dazu schreiben.
Das jeder weiß was seine Aufgabe ist. Wobei aber auch jeder zugang zum "Gesammten" hat um beraten zu können oder mal nen tip loswerden kann oder einfach mal ne Idee durchspielt.
Keine Geheime Aktionen oder Codes für sich behalten.
Regelmäßig sitzungen abhalten.
Teilnehmer müßen die möglichkeit haben sich auszuklinken. Weil es gibt auch wichtigeres.
Tolles Thema. bin mal gespannt was die Profis dazu schreiben.
Ich progge PureBasic weil Jägermeister nen dicken Kopf macht.
Eine Roadmap wäre nicht schlecht, also ein Terminplaner bis wann was fertig sein soll.
also
Konzeptphase (Idee, Zeichnungen, usw.)
Prototyping
Graphic, Audio
Coding
Bugfixing
Präsentation (Webseite, im Forum vorstellen)
Da ists eben wichtig den beteiligten Membern klarzumachen, dass sie schreien sollen, wenn sie z.B. einen Urlaub geplant haben usw. usf.
Wenn man mal einen Terminrahmen hat, ist die Chance gleich höher, dass auch alle was tun. Ansonst lässt mans vielleicht schleifen, ala "Hey, mein Kram wird eh fertig. Irgenwann halt
"
also
Konzeptphase (Idee, Zeichnungen, usw.)
Prototyping
Graphic, Audio
Coding
Bugfixing
Präsentation (Webseite, im Forum vorstellen)
Da ists eben wichtig den beteiligten Membern klarzumachen, dass sie schreien sollen, wenn sie z.B. einen Urlaub geplant haben usw. usf.
Wenn man mal einen Terminrahmen hat, ist die Chance gleich höher, dass auch alle was tun. Ansonst lässt mans vielleicht schleifen, ala "Hey, mein Kram wird eh fertig. Irgenwann halt
"Das sind ja schon einige sehr gute Ansätze.
Die Zeitpläne finde ich auch sehr wichtig für das Projekt.
Ein Problem ist meiner Meinung nach die Motivation der Beteiligten. Ich zum Beispiel bin sehr motiviert, wenn ich die Früchte meiner Arbeit schnell sehe, oder ich ein Projekt durchführe, dass ich schon immer machen wollte.
Darin liegt meiner Meinung nach ein Problem, da sicher jeder Mitarbeiter möglichst viele seiner eigenen Ideen einbringen möchte.
Außerdem ist es sicher frustierend, die ganze Zeit am Backend (zb. Verarbeitung der internen Scriptsprache) zu arbeiten, wärend andere an der Grafikausgabe arbeiten.
Meine Idee wäre es, als Initiator einen Stamm an Leuten aufzutreiben, mit diesem dann in einigen (virtuellen) Treffen ein Gesamtkonzept zu erarbeiten. Es hat jeder viel Einfluss auf das Projekt, was aber auch eine Kompromissbereitschaft vorraussetzt.
Ein Mitarbeiter, der ständig den Überblick über das gesamte Projekt haben muss, erarbeitet die Architektur und teilt das Projekt in immer kleinere Teile und Aufgaben auf. Beim Formulieren der Aufgaben braucht er die Hilfe von den anderen Mitarbeitern. Am besten wäre hier eine Aufgabenhierachie.
Jetzt müssen die Aufgaben an die Programmierer vergeben werden.
Jeder Teil muss eine genaue Spezifikation haben. Am Wichtigsten ist, dass jede Aufgabe genauestens dokumentiert ist, und keine Fehler enthält.
Der Mitarbeiter, der für die Softwarearchitektur verantwortlich ist, fügt die Aufgaben zusammen und testet laufend.
Mich würde interessieren, was ihr von meinem Konzept haltet.
Vieles ist sicher heise Luft, aber ich finde es durchaus sinnvoll, wenn ein Projekt eigentlich schon "funktioniert", ohne das eine Zeile Code geschrieben wurde.
Die Zeitpläne finde ich auch sehr wichtig für das Projekt.
Ein Problem ist meiner Meinung nach die Motivation der Beteiligten. Ich zum Beispiel bin sehr motiviert, wenn ich die Früchte meiner Arbeit schnell sehe, oder ich ein Projekt durchführe, dass ich schon immer machen wollte.
Darin liegt meiner Meinung nach ein Problem, da sicher jeder Mitarbeiter möglichst viele seiner eigenen Ideen einbringen möchte.
Außerdem ist es sicher frustierend, die ganze Zeit am Backend (zb. Verarbeitung der internen Scriptsprache) zu arbeiten, wärend andere an der Grafikausgabe arbeiten.
Meine Idee wäre es, als Initiator einen Stamm an Leuten aufzutreiben, mit diesem dann in einigen (virtuellen) Treffen ein Gesamtkonzept zu erarbeiten. Es hat jeder viel Einfluss auf das Projekt, was aber auch eine Kompromissbereitschaft vorraussetzt.
Ein Mitarbeiter, der ständig den Überblick über das gesamte Projekt haben muss, erarbeitet die Architektur und teilt das Projekt in immer kleinere Teile und Aufgaben auf. Beim Formulieren der Aufgaben braucht er die Hilfe von den anderen Mitarbeitern. Am besten wäre hier eine Aufgabenhierachie.
Jetzt müssen die Aufgaben an die Programmierer vergeben werden.
Jeder Teil muss eine genaue Spezifikation haben. Am Wichtigsten ist, dass jede Aufgabe genauestens dokumentiert ist, und keine Fehler enthält.
Der Mitarbeiter, der für die Softwarearchitektur verantwortlich ist, fügt die Aufgaben zusammen und testet laufend.
Mich würde interessieren, was ihr von meinem Konzept haltet.
Vieles ist sicher heise Luft, aber ich finde es durchaus sinnvoll, wenn ein Projekt eigentlich schon "funktioniert", ohne das eine Zeile Code geschrieben wurde.
Bezüglich der Motivation:
Dafür eignen sich Prototypen am besten!
Und dann würde ich mir inkrementelles Arbeiten mit einem schnellen Releasezyklus angewöhnen.
So sieht man stetig einen Fortschritt, was ja eigentlich genut Motivation sein sollte.
Wenn man 4 Wochen an einem 3D Model bastelt, weils ja dann auch gleich perfekt sein soll dann werden die anderen ungeduldig werden, und den Spaß dran verlieren.
Hier ist es besser mal Dummys zu verwenden, und wenns nur doofe Blockmalz-Würfel-Models sind, voll egal, Hauptsache es tut sich was!
Man kann später ja immer noch immer wieder ein bissl ein besseres Model dann einbauen.
Und inkrementell mit schnellem Releasezyklus würde hier dann bedeuten, dass man sobald mal bissl was an dem Model getan wird das Ding gleich eingepflegt und getestet wird.
In diesem Sinne ists also vorteilhaft, wenn man:
1. bissl was coded / bastelt
2. das Ding gleich im Programmkonglomerat einfügt
3. testet
4. das ganze von vorne macht
und irgendwann ists dann mal "done"
Damit man sich nicht daran verzettelt (sowas könnte eine never ending story werden) sollte man auch ein Pflichtheft anlegen, in dem festgehalten ist was das Ding denn MINIMAL leisten muss. Sobald dieser Status dann erreicht ist kann man das Zeug ja mal auf die Leute loslassen, die das Ding dann auf Bugs testen (das sollten dann Leute sein, die nicht in der Programmierung und in der Erstellung vom Content verwickelt sind). Manchmal übersieht man halt doch was, obwohls einem dauernd vor den Augen steht.
Also man iteriert diese Prozesse immer und immer wieder. Diesbezüglich sollte man sich gleich Testmethoden überlegen (am besten automatisiert). So kann man relativ einfach die Software stabil halten, in dem man die Teilbereich immer und immer wieder testet. In vielen Programmiersprachen existieren für diese Prozesse sogar eigene Utilities, die verwendet werden. Oft sind es objektorientierte Spachen, weil sich hier die Klassen relativ leicht durch Tester überprüfen lassen, ob sie korrekt arbeiten.
Falls du diesbezüglich mehr wissen willst lese dich auf Wikipedia oder sonstwo in Agile Development oder Extreme Programming ein, ist auf alle Fälle für ein Projekt, wo mehrere dran arbeiten einen Blick wert.
Dafür eignen sich Prototypen am besten!
Und dann würde ich mir inkrementelles Arbeiten mit einem schnellen Releasezyklus angewöhnen.
So sieht man stetig einen Fortschritt, was ja eigentlich genut Motivation sein sollte.
Wenn man 4 Wochen an einem 3D Model bastelt, weils ja dann auch gleich perfekt sein soll dann werden die anderen ungeduldig werden, und den Spaß dran verlieren.
Hier ist es besser mal Dummys zu verwenden, und wenns nur doofe Blockmalz-Würfel-Models sind, voll egal, Hauptsache es tut sich was!
Man kann später ja immer noch immer wieder ein bissl ein besseres Model dann einbauen.
Und inkrementell mit schnellem Releasezyklus würde hier dann bedeuten, dass man sobald mal bissl was an dem Model getan wird das Ding gleich eingepflegt und getestet wird.
In diesem Sinne ists also vorteilhaft, wenn man:
1. bissl was coded / bastelt
2. das Ding gleich im Programmkonglomerat einfügt
3. testet
4. das ganze von vorne macht
und irgendwann ists dann mal "done"
Damit man sich nicht daran verzettelt (sowas könnte eine never ending story werden) sollte man auch ein Pflichtheft anlegen, in dem festgehalten ist was das Ding denn MINIMAL leisten muss. Sobald dieser Status dann erreicht ist kann man das Zeug ja mal auf die Leute loslassen, die das Ding dann auf Bugs testen (das sollten dann Leute sein, die nicht in der Programmierung und in der Erstellung vom Content verwickelt sind). Manchmal übersieht man halt doch was, obwohls einem dauernd vor den Augen steht.
Also man iteriert diese Prozesse immer und immer wieder. Diesbezüglich sollte man sich gleich Testmethoden überlegen (am besten automatisiert). So kann man relativ einfach die Software stabil halten, in dem man die Teilbereich immer und immer wieder testet. In vielen Programmiersprachen existieren für diese Prozesse sogar eigene Utilities, die verwendet werden. Oft sind es objektorientierte Spachen, weil sich hier die Klassen relativ leicht durch Tester überprüfen lassen, ob sie korrekt arbeiten.
Falls du diesbezüglich mehr wissen willst lese dich auf Wikipedia oder sonstwo in Agile Development oder Extreme Programming ein, ist auf alle Fälle für ein Projekt, wo mehrere dran arbeiten einen Blick wert.
Danke für die ausführliche Antwort.
Extreme Programming finde ich interessant.
Ich habe mich jetzt etwas darin vertieft, und bin zum Schluss gekommen, dass der einzige nennenswerte Nachteil in den Aufgabenstellungen liegt.
Meiner Meinung nach muss viel mehr Zeit investiert werden, die Aufgaben festzulegen, da sie sich ja ständig ändern und angepasst werden müssen. Zudem muss man sicher aufpassen, dass der Weg über eine Dummy Routine nicht schwieriger wird, als der direkte Weg.
Hat jemand Ansätze um dieses Problem zu kompensieren, bzw. hat jemand schon Erfahrungen mit XP gemacht?
Extreme Programming finde ich interessant.
Ich habe mich jetzt etwas darin vertieft, und bin zum Schluss gekommen, dass der einzige nennenswerte Nachteil in den Aufgabenstellungen liegt.
Meiner Meinung nach muss viel mehr Zeit investiert werden, die Aufgaben festzulegen, da sie sich ja ständig ändern und angepasst werden müssen. Zudem muss man sicher aufpassen, dass der Weg über eine Dummy Routine nicht schwieriger wird, als der direkte Weg.
Hat jemand Ansätze um dieses Problem zu kompensieren, bzw. hat jemand schon Erfahrungen mit XP gemacht?
Ich würde auf jeden Fall den Einsatz eines Tasktrackers empfehlen. Habe gute Erfahrungen mit Streber PM gemacht. Damit behält man immer den Überblick über den Projektstatus und die Aufgaben können übersichtlich verteilt und verwaltet werden.
Zu mir kommen behinderte Delphine um mit mir zu schwimmen.
Wir fordern mehr Aufmerksamkeit für umfallende Reissäcke!
Wir fordern mehr Aufmerksamkeit für umfallende Reissäcke!