Da gibts wohl kein Königsweg.
Was sind den Eure Probleme ?
Sobald man mit mehreren Leuten an einem Projekt arbeitet, wird man früher oder später an einem Punkt gelangen, wo es ohne Programme zur Versionsverwaltung nicht mehr geht (bzw. im Chaos endet).
Ein kleines Team ohne Überschneidungen in den Arbeitsbereichen (z.B. ein Coder, ein Artist, ein Musiker) werden da weniger Probleme haben, als wenn mehrere Artists oder Programmierer gleichzeitig an etwas arbeiten müssen.
Gute Versionierungs-Software fungiert auch gleichzeitig als Cloud-Backup und Zeitmaschine.
Die Änderungen dieser Woche führen zu schweren nicht lösbaren Problemen?
Kehren wir eben zurück zum Stand von letzter Woche wo noch alles ging und versuchen es in ne andere Richtung.
Es soll ne Alpha/Beta veröffentlicht werden und einige Features stehen noch ganz am Anfang, kein Prolem, wird eben ein Release Branch abgezweigt wo nur alles fertiggestellte enthalten ist.
Bei internen Tests dieses Release Builds wurden Bugs gefunden und gefixt, dann werden die Fixes eben zurück in das development Build migriert.
Dein PC hat nen Hardwareschaden z.B. die HDD ist Schrott.
Neue Festplatte rein, die Daten wieder runterladen und dort auf dem Stand deines letzten Commits weitermachen.
(Daten die nicht von der Versionierungssoftware erfasst sind, sollte man natürlich trotzdem regelmäßig als Backup sichern)
Gerade wenn du selbst auch an verschiedenen Rechnern Projekte bearbeitest, ist sowas von Vorteil.
Was sind den Eure Probleme ?
Endlich mal jemand der die richtige
Ansprache verwendet.
Nein, wir (also ich) haben keine
Probleme. 
Die Frage war ganz allgemein gestellt und bezog sich eher auf ein kleines Projekt bei dem 2-3 Personen herumwerkeln.
Nur aus reinem Interesse.
Kraid hat das schon sehr gut beschrieben und Branch ist ein gutes Stichwort.
Zuerst einmal sollten nicht alle im selben Unreal Projekt rumstochern, dass endet auch mit Versionierung im Chaos.
Es sollte einen Leader geben und nur der hat Zutritt zum Main Projekt. Alle anderen Entwickler ob nun Programmierer, Arist usw können sich eine Kopier dieses Main Projekts ziehen.
Dort entwickelt jeder unabhängig seinen Stuff. Ist irgend was fertig, wird dieser Inhalt vom Leader ins Hauptprojekt implementiert.
Im Prinzip Prinzip gibt es also ein Main Projekt und sehr viele kleine Projekte die alle im Main Projekt zusammen laufen.
Muss ich als Artist zb eine Kiste bauen, die auch Animiert werden soll wird dies in einem Task tool wie Trello merkt. Man weiß also wer gerade an was arbeitet. Brauch ich nun einen Programmier der mir das Blueprint für die Kiste baut, kann ich mir beim Leader einen Zuweisen lassen. Dieser bekommt dann meine Szene und arbeitet damit weiter.
Er finallisiert dann die Szene und läd diese in die Cloud und der Leader baut sie ein.
Das gesamte Projekt wird also in kleine Subprojekte zerlegt wo 1 - 3 Leute daran arbeiten.
Ich erinnere mich im Studium mit einem Schmunzeln daran, wie ein Artist verschiedene Schranken hätte Modellieren sollen. Dummweise hat er sich verlesen und hat unterschiedliche Schränke Modlliert die mal sowas von Gar nicht ins Konzept gepasst haben.
Ich hab manchmal das Gefühl das der Level designer eines Hobby Projekts wird, der am wenigsten Ahnung hat. Der weder Modellieren, Programmieren oder Ahnung von Licht hat. Wie soll jemand Assets plazieren der keine Ahnung hat wie die Assets aufgebaut sind.
Für ein Point of Interest eines Spiels werden normalerwiese sehr viele Referenzbilder gesucht.
zb
1.Probs (Wie sollen die Assets aussehen) hier fließen auch Zeichnungen des Conzept Arts mit ein.
2.Referenzen für das Licht. ( Wie soll das Licht später aussehen. Diese Referenz kann vom Prob komplett abweichen.
3, Referenzen: Diese Bilder spiegeln wieder wie fertige Szene aussehen könnte.
4. Architecture Hierbei geht es um die Definition des Styles hier werden zb Referenzen des 18. Jahrhunderts gesucht.
5.Funktionsweise Wie läuft die Animation ab.
All das Ergibt das die fertige Szene des Levels. Alle diese Punkte müssen sowohl in Programmierer beim erstellen der Modelle mit einlaufen als auch für die Programmier, Animator der nachher wissen muss wie die Modelle funktionieren sollen.
Man muss hierfür Komplexe Strukturen bauen so das jeder weiß was er zu tun hat und in welche Richtung alles Laufen soll.
In Großen Studios würde man so oftmals einen Mech in viele Unterkategorien zerlegen. Wo es theoretisch für jedes einzelne Bauteil (Schraube) ein Referenzbild) gibt. Aus all diesen Refrenzbilder entsteht dann der fertige Mech in Gedanken. Der Artist setzt dass Modell um, Der Animator sorgt dafür das er richtig funktioniert. Das Licht usw
Das größte Problem ist dass jeder der am Projekt mitmacht eine eigene Vorstellung hat wie das Ergebnis am Schluss aussehen soll. Diese Ideen vertragen sich fast immer nicht miteinander. Deswegen gibt es einen Lead Gamedesigner der dafür sorgt das die Idee in einer Line bleibt. Und die Taschenlampe eben aus dem 18. Jahrhundert und nicht aus dem 19. Jahrhundert ist.
Kraid hat das schon sehr gut beschrieben und Branch ist ein gutes Stichwort.
Zuerst einmal sollten nicht alle im selben Unreal Projekt rumstochern, dass endet auch mit Versionierung im Chaos.
Es sollte einen Leader geben und nur der hat Zutritt zum Main Projekt. Alle anderen Entwickler ob nun Programmierer, Arist usw können sich eine Kopier dieses Main Projekts ziehen.Dort entwickelt jeder unabhängig seinen Stuff. Ist irgend was fertig, wird dieser Inhalt vom Leader ins Hauptprojekt implementiert.
Im Prinzip Prinzip gibt es also ein Main Projekt und sehr viele kleine Projekte die alle im Main Projekt zusammen laufen.
Sorry, dass mit mehrere Projekten ist seit SourceControl Blödsinn. In praktisch jeder aktuellen Versionierung hast du die Möglichkeit "Branches" zu erstellen hast so die Möglichkeit mehrere Versionen eines Projekts parallel laufen zu lassen. Das hat den selben Effekt wie mehrere Projekte, braucht nur deutlich weniger Platz, geht schneller und man braucht keine Files hin und her zu ziehen. Allerdings stimmt es wiederum, dass es am besten funktioniert wenn nicht mehrere Personen die Branches am Ende zusammen führen.
Zurück zum Thema:
Das wonach du hier fragst nennt sich Projektmanagement und ist auch über Unreal hinaus eine Frage die sich in jedem Projekt stellt.
Bevor man sich für eine Projektmanagement Methode entscheidet stellt man sich die folgenden Fragen:
1. Existiert ein Endtermin?
2. Habe ich ein maximales Budget?
3. Habe ich begrenzte Ressourcen (klingt entmenschlichend aber in unserem Fall sind damit zum Grossteil Leute gemeint die dir helfen und Zeit investieren können)
In der Regel ist die sind die Antworten bei uns Hobbyisten:
1. Mal gucken wie langs dauert --> also Nein
2. Hmm am besten gar nix --> also Ja
3. Wir sind ein drei Mann/Frau Team was das nächste WoW raus bringt.
--> also Ja
In diesem Fall empfiehlt sich ein agiles Projektmanagement wie zum Beispiel Scrum:
Allerdings hat Sleepy damit recht:
Da gibts wohl kein Königsweg.
Je nach Situation wählt man andere Methodiken oder entwickelt sogar eigene. Projektmanagement kann neben zb Leveldesign, Coden oder Modellierung als eigene Disziplin angesehen werden.
Der Trick dabei ist möglichst viele Projektmanagement Methodiken zu kennen und für das Projekt die passende auszuwählen. (oder sich eine neue zu überlegen)
Ist man sich einmal über die Methodik im klaren, dann sucht man sich die Tools aus, die das Projektmanagement am besten unterstützen.
zB:
- GitHub für die Versionierung
- HacknPlan für Projektmanagement
- usw
Natürlich ist dieses Vorgehen kein muss. Das ist nur die gängige Projektmanagement Methodik, wie sie uns im Studium seit nun über 2 Semestern rein gedrückt wird.
Am Ende einfach darauf achten, dass sich der Aufwand fürs Projektmanagement Verhältnismässig zum Projekt verhält.
Ich hoffe ich konnte dir weiter helfen.
Gruss Veelos
Besten Dank für die Antwort.
Meine Frage zielte wirklich nur auf die Zusammenarbeit eines 2-3 Mann Teams ab.
Also wie sich der Zugriff auf das Projekt gestaltet.
Ich glaube wenn man zu zweit erst mit einem Scrum oder ähnlichen Methoden anfängt, hat man wirklich zufiel Zeit.
Ich muss dazu sagen das ich Management geschädigt bin. Ein Kerl baut eine Firma aus dem Nichts auf und hat nachher 2000 Angestellte. Er stirbt und immer mehr Manager übernehmen die Funktionen, ohne ein Verständnis für die Basis zu haben.
Ich habe mich schon maßlos darüber aufgeregt, wie unmöglich es ist, diesen Schlipsträgern zu erklären das manche Sachen so nicht funktionieren.
Ende vom Lied. Firma an die Wand gefahren.
Ich dachte wirklich in kleinen Dimensionen. Einer für das Design und die Assets und einer für den Bereich des programmierens.
Ich denke auch das ein größeres Projekt nur funktioniert, wenn es eine treibende Kraft gibt die eine sehr klare Vorstellung vom Endergebniss hat und trotzdem offen für Vorschläge ist.
(z.b. George Lucas )
Ich selbst würde ein Projekt ohnehin so klein (überschaubar) wie möglich halten, aber mit der Option das es erweiterbar ist. (Weitere Maps )
Vielleicht bin ich in dem Punkt zu
altmodisch. Zuviel Köche verderben den Brei und zu viel ist schon
tot »geführt« worden. Weniger labern sondern anpacken.
Ich muss dazu sagen das ich Managementgeschädigt bin. Ein Kerl baut eine Firma aus dem Nichts auf und hatnachher 2000 Angestellte. Er stirbt und immer mehr Manager übernehmendie Funktionen, ohne ein Verständnis für die Basis zu haben.
Das kenn ich auch.
Man macht einmal pro Woche ein Metting man nagelt irgend welche Abteilungsleiter auf Deadlines fest die Schätzen müssen. Und wenn eine Woche Später die Deadlines nicht eingehalten werden, verschiebt man die Deadline um eine Woche weiter. Macht man das in einem größeren Team werden irgend wann an den Mettings nur noch Mettings weiter verschoben. Im Prinzip verwaltet man in den Mettings dann nur noch die nächsten Metting. Aber immerhin gibt es kostenlose Butterbrezeln und man muss ne halbe Stunde lang nichts arbeiten. Ich glaube das ist dann noch die einzige Daseinsberechtigung der Mettings.
Man kann sich auch zu tote organisieren.
Vielleicht bin ich in dem Punkt zualtmodisch. Zuviel Köche verderben den Brei und zu viel ist schontot »geführt« worden. Weniger labern sondern anpacken.
Ganz genau.
Mir gehen diese künstlichen Mettings auch auf den Zeiger nur um ein Metting zu machen damit man im Trend liegt. In der Zeit kann man auch was arbeiten statt zu labern.
Sorry, dass mit mehrere Projekten ist seit SourceControl Blödsinn. In praktisch jeder aktuellen Versionierung hast du die Möglichkeit "Branches" zu erstellen hast so die Möglichkeit mehrere Versionen eines Projekts parallel laufen zu lassen. Das hat den selben Effekt wie mehrere Projekte, braucht nur deutlich weniger Platz, geht schneller und man braucht keine Files hin und her zu ziehen. Allerdings stimmt es wiederum, dass es am besten funktioniert wenn nicht mehrere Personen die Branches am Ende zusammen führen.
Das funktioniert meiner Meinung nach ganz gut bei projekten die nicht in einer Engine stattfinden. (zb Bei reines Quellcodes)
Da ist es auch einfach irgend was zu implementieren.
Ein Bench entsteht ja im Prinzip ja schon wenn man eine Kopie erstellt. Nur wie willst du in Unreal beide Benches wieder Mergen ? Das funktioniert wie gesagt bei reinem Quellcode wo einfach ein paar Dateien dazu kommen die man ins Main Projekt einpflegt.
Wie soll das den in der Praxis funktionieren ?
Ich kenne jedenfalls keine Möglichkeit zwei Unreal Projekte (Benches) wieder zusammenzufügen.
Mir wäre das auch zu Riskant.
Veelos
Besten Dank für die Antwort.
Meine Frage zielte wirklich nur auf dieZusammenarbeit eines 2-3 Mann Teams ab.
Also wie sich der Zugriff auf dasProjekt gestaltet.
Ich glaube wenn man zu zweit erst miteinem Scrum oder ähnlichen Methoden anfängt, hat man wirklichzufiel Zeit.
Naja, viele verwenden ähnlich Ansätze ohne sich dem eigentlich bewusst zu sein. Ein Beispiel wäre:
Drei Leute wollen zusammen ein Spiel machen und haben schon ein grobes Konzept im Kopf.
Erstmal setzt man sich zusammen und guckt was den überhaupt zu tun ist (Hoffe ich zumindest).
Man hat also sowas wie ne Todo List: (In Scrum nennt man das Backlog)
Als nächstes guckt man mal wer was als nächstes tut und verteilt ein paar der Aufgaben.
Jetzt braucht man sich nur noch regelmäßig zusammen setzen (zb alle zwei Wochen) wo man sich kurz abspricht, wer was geschafft hat und was als nächstes auf dem Plan steht.
Das ist Grundsätzlich eine Scrum Struktur (auch wenn aus Aufwands technischen Gründen einige Aspekte von Scrum weg fallen)
Und sie kostet das Team alle zwei Wochen ca eine Stunde (was denke ich nun Verkraftbar ist).
Das meinte ich mit verhältnismäßigem Projektmanagement.
Ich habe mich schon maßlos darüberaufgeregt, wie unmöglich es ist, diesen Schlipsträgern zu erklärendas manche Sachen so nicht funktionieren.
Ende vom Lied. Firma an die Wandgefahren.
Man macht einmal pro Woche ein Metting man nagelt irgend welche Abteilungsleiter auf Deadlines fest die Schätzen müssen. Und wenn eine Woche Später die Deadlines nicht eingehalten werden, verschiebt man die Deadline um eine Woche weiter. Macht man das in einem größeren Team werden irgend wann an den Mettings nur noch Mettings weiter verschoben. Im Prinzip verwaltet man in den Mettings dann nur noch die nächsten Metting.
Auf sowas wollte ich eigentlich nicht hinaus
. Aber ja, das kenn ich auch. Viele Firmen vertreten noch eine altmodische Generation von Projektmanagement ("Ich Chef du nix" oder "Zuckerbrot oder Peitsche"). Aus meiner Sicht sollte ein Projektmanager ein Dienstleister an das Projektteam sein, der sein möglichstes tut dem Team den Rücken frei zu halten. Aber ich bin ja keiner dieser alteingesessenen PMs, was weiss denn ich schon)
Ich kenne jedenfalls keine Möglichkeit zwei Unreal Projekte (Benches) wieder zusammenzufügen.
Mir wäre das auch zu Riskant.
Mach ich regelmäßig mit ca 4-5 Leuten die das selbe gleichzeitig tun ohne großartige Probleme.
Aber du hast recht, es gibt einen Hauptunterschied zwischen einer Engine und "normalen" Projekten. Unreal arbeitet mit Serialisierten Files (mal vom C++ Code abgesehen). Das bedeutet, das File ist nicht im Klartext.
Das Problem kannst du aber einfach umgehen.
zwei Personen dürfen nicht gleichzeitig am selben File arbeiten. (Funktioniert ja auch nicht wenn du in zwei Projekten gleichzeitig arbeitest).
Wenn diese einfache Regel eingehalten wird kannst du ohne Probleme unterschiedliche Branches zusammen mergen. Unreal kommt mit dem sehr gut klar (muss ja, sonst wäre sie unbrauchbar für jede grössere Firma).
Sollte es trotzdem vorkommen, dass mal zwei Leute am selben File gearbeitet haben, dann entsteht ein Merge Konflikt und man muss sich für eine der beiden File-Versionen entscheiden.
Ich kann dir das bei Gelegenheit auch gerne einmal Live zeigen.
Ich kann dir das bei Gelegenheit auch gerne einmal Live zeigen.
Gerne ja.
Also wir arbeiten Cloudbasierend (Office 356) jeder in seiner eigenen Domäne mit Firmen PC und fllexieblem Arbeitsplatz und Home Office.
Unreal lässt sich ohne Probleme in der Cloud öffnen und auch damit arbeiten. Unreal erstellt ja beim Start immer diesen Temp Ordner. Start noch einer die Engine dann kracht es.
Ich wüsste also nicht wie man von Unreal zu Laufzeiten einen Bench erstellen kann.
Man müsste meiner Meinung nach Unreal speichern, schließen und dann einen Bench erstellen damit der Mitarbeiter dem Ausschlafen wichtig ist später einsteigen kann.
Dazu kommt, das die Cloud Synchronisation immer etwas dauert.
Aus Datenschutz gründen, dürfen wir auch keine Daten aus der Hand geben. (Kein Freelance, keine USB Sticks und kein Arbeiten auf Privatrechnern.
Aus diesen gründen finde ich das Lokale Arbeiten bequemer.
Nun könnte man sich ja vielleicht auch Fragen: Warum dann eine Cloud Lösung ?
Das liegt daran weil wir Mitarbeiter Flexible Arbeitszeiten und Homeoffice ermöglichen wollen und dass darf eben nicht mit der ganze Datenschutz Geschichte Kollidieren.
Falls du da Lösungen kennst bin ich sehr interessiert.
sehrwitzig Hoffe wir verunstalten dir deinen Thread nicht aber vielleicht beantwortet ja gerade solch eine Diskussion deine Fragen.
Unreal lässt sich ohne Probleme in der Cloud öffnen und auch damit arbeiten.
Was genau verstehst du unter in der Cloud öffnen? Wir reden hier nicht ganz vom Selben.
Ein Source Control System funktioniert in der Regel so, dass du bei dir auf dem Rechner ein Lokales Repository hast auf das die Daten kopiert werden. Machst du nun Änderungen an deinem Lokalen Projekt, werden diese vom src erkannt und beim pushen dann auf das src selber geladen.
In deinem Fall ist das aber schonmal suboptimal, da Lokale Daten nicht erwünscht sind.
Wie arbeitet Ihr dann im Homeoffice? Firmenlaptop wo die Daten wiederum erlaubt sind?
Falls ja, dann kannst du trotzdem normal mit src arbeiten und eine Lokale des Projekts auf deinem Rechner machen.
Sollte dies nicht möglich sein, dann müsste für Homeoffice die komplette Infrastruktur auf iwelchen VMs liegen auf die Ihr euch mit VPNs verbindet (in diesem Fall installiert man SRC auf diesen VMs). In diesem Fall könnte ich mir vorstellen. dass wenn zwei Personen auf der selben VM arbeiten es zu Problemen kommen kann.
Ich wüsste also nicht wie man von Unreal zu Laufzeiten einen Bench erstellen kann.
1. Was zum Geier ist ein Bench?^^
geht nicht und ist auch nicht die Idee. Du kannst dir zum Beispiel einen Branch mit dem Namen Sleepy erstellen auf dem ausschließlich du arbeitest. Wenn du was erledigt hast pushst du deinen branch und synchronisierst ihn neu (bist so gesehen wieder auf dem neusten Stand)
Ich glaube hier ist ein kleines Missverständniss. Jeder Nutzer muss eine eigene Instanz von Unreal laufen lassen. Nur die Projektdaten werden synchronisiert.
Dazu kommt, das die Cloud Synchronisation immer etwas dauert.
Ich glaube wir reden nicht vom selben. Du wirst auch mit src keine Echtzeitänderungen in deiner Version der Engine sehen wenn jemand anderes parallel daran arbeitet, noch können zwei Personen gleichzeitig Beispielsweise im selben BP rumwerkeln.
Deshalb steh ich hier etwas auf dem Schlauch, weshalb die Cloud Synchronisation hier rein spielt. Die Synchronisation der Daten sollten über Src laufen. Ob das jetzt Github, AzureDevOps, Perforce oder was auch sonst ist.
Im Moment klingt das für mich mehr so als würdet ihr versuchen gleichzeitig im selben OneDrive Verzeichnis zu arbeiten.
Sorry bin grad etwas verwirrt aber vielleicht sollten wir das auf ne PN auslagern da wir hier am eigentlichen Thema vorbei schiessen.
Gruss Veelos
Veelos Mal eine Frage zu Scrum in kleinen teams (du sagst ja 3 Personen). Wie handhabt ihr die Rollen Product Owner und Scrum Master. Das wären ja 2 Leute die wenn man rein nach Scrum arbeitet wie es definiert ist, die "verschwendet" sind. Also was macht ihr für anpassungen an Scrum, dass es funktioniert? (Z.B. die Rollen tauschen, oder nimmt jemand mehrere Rollen ein?)
Was Git angeht. Wie doll haltet ihr euch da an konventionelle Git Prozess modelle (z.B. Git-Flow)?
Das größte Problem was ich eigentlich habe ist. Wie bringen ich Git einem Team vernünftig bei? Ich hab nämlich das Gefühl das Git für einige nicht sehr trivial ist, wegen seiner dezentralen Natur. War letztens auf nem größeren Workshop zu dem Thema, aber ich hatte das Gefühl, dass viele immer noch eine falsche Vorstellung davon hatten.
Ich stell grad irgendwie nur Fragen. Vielleicht trag ich mal am WE was bei, wobei ich zur Zeit eher am nachdenken bin, ob und wie ich für mein Shooter Projekt ein Team aufbaue. (Zur Zeit bin ich mehr beim "ob" und anderen Fragen)
Wie handhabt ihr die Rollen Product Owner und Scrum Master. Das wären ja 2 Leute die wenn man rein nach Scrum arbeitet wie es definiert ist, die "verschwendet" sind. Also was macht ihr für anpassungen an Scrum, dass es funktioniert? (Z.B. die Rollen tauschen, oder nimmt jemand mehrere Rollen ein?)
Ganz einfach. Gar nicht. Bei einem kleinen Team kann man ohne Probleme zusammen absprechen welche Tasks als nächstes gemacht werden. Es macht keinen Sinn irgendwelche Rollen zu verteilen, wenn es auch so funktioniert.
Wie oben bereits beschreiben. Todolist erstellen und sich regelmässig (2 Wochen Takt treffen um abzusprechen was als nächstes gemacht werden muss reicht.
Theoretisch hast du recht. Es ist nicht wirklich Scrum sondern eine Abgespeckter Version davon. (Aber wen interessiert das?)
Was das Projektmanagement in unserem Team angeht habe ich tatsächlich ein eigenes Projektmanagement dafür ausgearbeitet. Das hier zu erklären wäre aber viel zu Aufwändig.
Was Git angeht. Wie doll haltet ihr euch da an konventionelle Git Prozess modelle (z.B. Git-Flow)?
Sehr konsequent. Jedes Feature kriegt seinen eigenen Branch. Wenn die Implementierung durch ist wird gemerged und der Branch wieder gelöscht. Wobei entweder ich, oder der Projektleiter die merges übernimmt.
Das größte Problem was ich eigentlich habe ist. Wie bringen ich Git einem Team vernünftig bei? Ich hab nämlich das Gefühl das Git für einige nicht sehr trivial ist, wegen seiner dezentralen Natur. War letztens auf nem größeren Workshop zu dem Thema, aber ich hatte das Gefühl, dass viele immer noch eine falsche Vorstellung davon hatten.
Puh, das kommt auf die Leute an. Ich kenne einige die habens nach 30min erklären verstanden und andere die sind hoffnungslose Fälle. Allerdings gibts ja UI Unterstützung wie zb github Desktop. Ich bin bis jetzt damit am besten gefahren, dass ich den Leuten ihre Branches eingerichtet habe. ihnen Push & Pull per Anydesk gezeigt habe und am Ende das Mergen übernommen habe.
Aber wie gesagt, dass kommt aufs Team an.
Wenn ihr lust habt können wir uns am Wochenende auch gerne mal kurz ne Stunde im TS zusammen setzen und ich erzähl was zu Projektmanagement, Scrum und wie wir das bei uns handhaben. (und warum wir das so tun)
Der Beitrag von sehrwitzig hat mir hier sehr gut gefallen. Ja Scrum, Prince2, PMI, etc... Alles geile buzzwords und die Gedanken dahinter sind nicht total abwegig - aber ich will hier auch nochmal tief in die Kloaken der 80er greifen als es das noch gar nicht gab und da hat mir damals mein Chef eine einfache Gleichung an die Tafel geschrieben die ich ie vergessen habe:
"Der Wert eines Projektmitarbeiters ist exakt Qualifikation x Motivation"
Klingt erst mal doof weil man beides schwer in Zahlen abbilden kann aber es bewahrheitet sich bis heute. Was ist die Quintessenz daraus? Als project Manager kann ich die Qualifikation eines Mitareiters nicht ändern. Normal geht die im Laufe der Zeit recht linear nach oben. Hab ich von 3d modeling null Ahnung beginne ich bei Null und werde - mehr oder weniger linear - immer besser. Das kann der project manager nicht beeinflussen aber versuchen einzuschätzen. Ist verdammt wichtig zumindest in etwa einzuschätzen was jemand gut liegt und was nicht.
Motivation kann der Project manager aber wirklich beeinflussen - das ist dieser legendäre soft skill. Klar in einer grossen Firma macht das Gehalt einen Großteil der Motivation aus. Aber danaben ist das der allgemeine Umgang und die Wertschätzung so wie ob das Aufgabengebiet Spass macht.
Bin ich in einem 2-3 Mann team - am besten noch alle arbeiten erst mal umsonst - dann isses nur "aus Spaß". Hier kann ich Leute nur motivieren indem es ihnen Spaß macht. Dazu gehört die Wertschätzung und das übertragen von Aufgaben die jemand gerne macht. Man kann Leute mit Scrum meetings quälen aber wenn die da keinen Spaß dran haben würde ich es lassen. Gerade bei "Spass teams" ist es echt am wichtigsten daß die Leute den Eindruck haben daß sie etwas machen was sie können, daß andere ihnen auch mal auf die Schulter klopfen und Wertschätzung für diese Arbeit zeigen und daß sie stetig ein feedback bekommen wie z.B. neue Demos wo sie sehen daß ihre Arbeit eingeflossen ist und auch wichtig ist.
Motivation wird echt oft unterschätzt. Wertschätzung, klares zielgerichtete kommunikation, viele Prototypen wo ich meine Arbeit sehen kann und stolz drauf bin - das kann viel geld ersetzen...
Ich würde mal noch ein Fazit ziehen:
1.WIr nutzen ja wie bereits geschrieben Office 356 um unsere Daten extern zu sichern. (Wir vertrauen hier auf Microsoft)
2.Eine Externe Speicherung unserer Projekte wie zb auf Gitup (Extern) kommt für uns nicht in Frage.
3.Office 356 hat gerade bei kleinen Dateien (Unreal) große Probleme und ist auch keine richtige Versionierung dafür aber eine sichere Sicherungsgeschichte.
4.Wir haben jetzt einen Server auf dem Perforce Server installiert ist somit nutzen wir perforce intern über den Clint. Der Vorteil ist: Wir können direkt aus Unreal herraus synchronisieren Upload Cllint.
Gleichzeitigen sichern wir alles noch über Office356.
Somit sind wir flexibel im Datenschutz, die Daten liegen nicht auf irgend welchen Git Servern in buxdehude herum, die Daten sind nochmal überall Lokal und auf dem internen Server gespeichert.
Das einzige was nun noch schiefgehen könnte, wäre wohl ein Atomkrieg.
Ich möchte mal noch eins anmerken:
Versionierung ist ne tolle Sache aber sie ist auch überwiegend für Quellcode gedacht wo man im Quellecode jede Zeile vergleichen kann. Versioniert man Unreal Dateien miteinander, ist das schon keine richtige Versionierung mehr zumindest nicht wie von den Erfindern gedacht.
Es gehört ebenfalls viel Disziplin dazu und gerade in großen Teams braucht man eventuell einen Projektmanager der nur die Perfoce Streams überwacht und den Überblick behält.
Auch mir Perforce kann viel schiefgehen wenn man das Tool nicht beherrschaft.
1.WIr nutzen ja wie bereits geschrieben Office 356 um unsere Daten extern zu sichern. (Wir vertrauen hier auf Microsoft)
2.Eine Externe Speicherung unserer Projekte wie zb auf Gitup (Extern) kommt für uns nicht in Frage.
Hierzu zwei kurze Infos.
1. Github != Git. Es ist ohne weiteres möglich Git auch bei sich auf einem Server zu installieren und zu verwenden. (Damit will ich aber nicht sagen dass Git besser als Perforce ist. Ich wollte nur darauf hinweisen, dass man mit Git nicht dazu gezwungen wird seine Files irgendwo zu speichern)
2. Microsoft hat 2018 Github gekauft. Deshalb musste ich hier etwas schmunzeln. Extern bei Microsoft ein Backup ist gut aber extern auf Github versionieren nicht.
3.Office 356 hat gerade bei kleinen Dateien (Unreal) große Probleme und ist auch keine richtige Versionierung dafür aber eine sichere Sicherungsgeschichte.
Als reines Backupsystem für den Fall der Fälle ist immer eine gute Idee.
Versionierung ist ne tolle Sache aber sie ist auch überwiegend für Quellcode gedacht wo man im Quellecode jede Zeile vergleichen kann. Versioniert man Unreal Dateien miteinander, ist das schon keine richtige Versionierung mehr zumindest nicht wie von den Erfindern gedacht.
Es gehört ebenfalls viel Disziplin dazu und gerade in großen Teams braucht man eventuell einen Projektmanager der nur die Perfoce Streams überwacht und den Überblick behält.
Auch mir Perforce kann viel schiefgehen wenn man das Tool nicht beherrschaft.
Das ist leider nur teilweise korrekt. Du sprichst hier nur ein Feature an, was bei Klartext-Files erlaubt diese Files zu kombinieren. Das ist aber nicht die Hauptaufgabe von Versionierung. Bei der Versionierung geht es darum das jeder vergangene Zustand eines Files wiederhergestellt werden kann. Bei serialisierten Files fallen einige sehr nützlichen Features weg, trotzdem bleibt es eine "richtige Versionierung".
Beim zweiten Teil hast du absolut recht.
Gruss Veelos
Wir beispielsweise arbeiten ohne Probleme mit Google Drive. Hier haben wir das 2€ Abo abgeschlossen für 100 GB Speicher. Wir können gewisse emails auf gewisse Dateien zugreifen lassen. So könnte man als Beispiel ein eingeschränkten Zugang zum Projekt eröffnen
Google drive ist schön um sich einmalig komplett alle Project files runterzuladen aber für ne echte Versionierung brauchste schon sowas wie git oder svn. Schon allein damit deine Partner sehen welche Datei sich geändert hat und um die automatisch zu ziehen. Wenn du nur eine Datei geändert hast dann geht das vielleicht noch über google Drive, aber sagen wir mal du hast 150 geändert - das kann doch keiner mehr nachverfolgen und wenns ein 50GB project is dann will sich doch keiner einmal am Tag alles komplett neu runterladen (Und womöglich eigene Änderungen überschreiben). Collaboration braucht eine ordentliche Versionierung.
Da werde ich mich wohl auch noch mit auseinander setzen müssen. Aktuell ist es so daß er immer die Datei ändert/hochlädt die bearbeitet wurde. Hier müssen wir nur aufpassen nicht beide gleichzeitig das Mainlevel zu speichern^^