News Cities Skylines 2: Müssen und können besser werden, sagt Publisher

[bligg]

Finde ich gut das die Bewertungen auf Steam jeden tag ein wenig sinken bevor sie DLC verkaufen können das sollten die Online Magazine die das spiel so supidupi hoch bewertet haben auch machen! Sie tragen auch eine Mitschuld!

 

[MajoPCGH]

@AyC @Bl4ckR4v3n
Natürlich muss die Flexibilität und das Verständnis dafür welches Produkt da wie produziert wird beim Management vorhanden sein. Und im Zweifel muss man Dinge auch Mal verschieben.
Die Kritik an einem rigidem Management dass am Anfang stur einen Plan festlegt und komme was wolle versucht einzuhalten ist absolut berechtigt, aber das agile Manifest ist aus meiner Sicht das Pendel ins andere extrem auszuschlagen. Das bringt imho beides herzlich wenig - die Wahrheit liegt in der Mitte. Und so halte ich das auch in den Projekten. Selbst arbeite ich nach Prince2, das kann man gut mit agilen Methoden kombinieren.
In manchen Firmen leben beide Seiten jetzt ein wenig in einer Parallelwelt und arbeiten gegeneinander. Kann als PM dann aber schwer bis unmöglich sein das zu verbinden. Keine Ahnung ob das in dem Fall so ist. War ja auch nur eine These die mir in den Sinn kam warum unfertige Software auf den Markt geworfen wird.

 

[Bl4ckR4v3n]

@AyC @Bl4ckR4v3n
Natürlich muss die Flexibilität und das Verständnis dafür welches Produkt da wie produziert wird beim Management vorhanden sein. Und im Zweifel muss man Dinge auch Mal verschieben.
Die Kritik an einem rigidem Management dass am Anfang stur einen Plan festlegt und komme was wolle versucht einzuhalten ist absolut berechtigt, aber das agile Manifest ist aus meiner Sicht das Pendel ins andere extrem auszuschlagen. Das bringt imho beides herzlich wenig - die Wahrheit liegt in der Mitte. Und so halte ich das auch in den Projekten. Selbst arbeite ich nach Prince2, das kann man gut mit agilen Methoden kombinieren.
In manchen Firmen leben beide Seiten jetzt ein wenig in einer Parallelwelt und arbeiten gegeneinander. Kann als PM dann aber schwer bis unmöglich sein das zu verbinden. Keine Ahnung ob das in dem Fall so ist. War ja auch nur eine These die mir in den Sinn kam warum unfertige Software auf den Markt geworfen wird.

Ich glaube du unterliegst hier einem Irrglauben beim agilen Manifest. Es wird am Ende ja nur gesagt dass man gewisse Dinge höher priorisieren soll. Wie viel höher ist ja bewusst schwammig gehalten. Manche Projekte und organisationen werden Fluider besser fahren andere brauchen mehr Struktur.
Mit der Parallelwelt hast du aber recht. Agile Prozesse einzuführen ist recht disruptiv und ich habe es auch immer wieder erlebt das einige Abteilungen denen wir zugearbeitet haben nicht so ganz verstanden haben dass man den Sprint nicht unterbricht und deren Feature reinwirft nur weil die ihren Meilenstein reißen. Wobei man auch hier sagen muss dass mit der Zeit auch deren Planung auf diese Anforderung angepasst wurden.
Aber um den Bogen zurück auf Paradox und Colossal Order zu spannen:
Gamingentwicklung ist ein recht kreativer Prozess bei dem vieles auch mal Probiert wird. Dadurch hast du recht viel Wandel innerhalb der Entwicklung und wirst von Haus aus schon deutlich mehr Iterationen haben. Sowas kann auch sehr viel Zeit kosten egal ob man das Ganze agil oder klassisch angeht. Dieses Risiko besteht immer und man muss mit diesem umgehen. Häufig wird dass dann mit Crunch gelöst was aber auch nur bedingt den Zeitplan rettet. Reicht das nicht wird leider zu selten der Release verschoben und stattdessen einfach das Spiel auf den Markt geworfen und das Ganze später gepatcht. Ganz nach dem Motto: "Erstmal kassieren dann liefern"

 

[MajoPCGH]

@Bl4ckR4v3n ne ich hab das Ding schon gelesen. Ich halte es vor allem für die trotzige Reaktion von Entwicklern die dem Management sagen "haltet euch aus unserem kram raus, ihr versteht nichts davon".
Da ist auch definitiv was dran, aber z.b. die Forderungen Kundenzusammenarbeit > Vertragsverhandlung klingt ganz toll, man wird sich aber gehörig in den Arsch beißen wenn man am Ende vertraglich gelinkt wurde und auf den Kosten sitzen bleibt weil man so schön nach dem agilen Manifest gearbeitet und so toll mit dem Kunden kommuniziert hat. Beim Geld hört bekanntlich die Freundschaft auf. Das zeigt dass die Urheber Entwickler waren die ihrerseits kein Plan vom Business haben, sich aber erdreisten dem Business reinzureden, obwohl sie ja gerade kritisiert dass das Management ihnen in ihre Arbeit rein redet. Ganz davon ab: mit Scrum, Sprints, Dailies, Retros etc. ist auch wieder so eine ganze Industrie um das agile entstanden, in der mantraartig vorgebetet wird dass diese genauso starren und oft überflüssigen Strukturen jetzt besser sein sollen als Wasserfall-PM vorher.
Naja - ich halte eben nicht viel von Religion. Und das Thema "agile" nimmt teilweise religiöse Züge an. Absolut ungerechtfertigt, denn nichts davon haben vernünftig denkende Menschen nicht sowieso schon vorher so gehandhabt. Vorausgesetzt im Management sitzen keine sturen, gierigen Idioten und in der Umsetzung keine bockigen Fabrikarbeiter kurz vorm Aufstand

 

[Krathak]

Ich kann dir einen Erklärungsversuch aus meiner Lebensrealität geben:
Ich habe schon mehrfach als Projektmanager u.a. mit Softwareentwicklern gearbeitet. Da besteht einfach ein riesen Problem zwischen dem Management, dass vor allem einen Business Case, Projektpläne, einen ROI und vor allem einen verbindlichen Releasezeitpunkt haben will und der Arbeitsweise der modernen Softwareentwicklung, die meint mit agilen Methoden wie Scrum & Co alle Anforderungen und Verantwortung für die Ziele ablehnen zu können und zu sagen "wir arbeiten agil, wir schaffen was wir schaffen und machen was wir eben machen". Da gibt's dann durchaus Konflikte, Softwareentwickler müssen sich Druck auch nicht gefallen lassen und können ganz gut mit den Füßen abstimmen, weshalb man sie wie zarte Elfen behandeln muss.

Ich will jetzt um Gottes Willen nicht sagen dass die Devs an allem Schuld sind. Ist ist das Management auch einfach lausig, aber meine Erfahrung ist eben dass die Verantwortung fürs Business abgelehnt wird und man dann da rumwurschtelt. Deine Projektpläne? Pfui! Wir sind agil! Mal sehen ob wir da Lust zu haben. Commitment auf verbindliche Ziele? Nee lieber nicht, da können wir ja nicht morgen plötzlich umentscheiden was wir machen wollen.
Das mag für Softwareentwickler in einem agilen Manifest alles ganz toll klingen und auch ganz toll in ihren Arbeitsalltag passen, aber so kann man kein Unternehmen führen.

Ich kann als Webentwickler dazu folgendes sagen: Je nachdem was für ein Umfang ein Projekt hat, kannst du auch als Entwickler kaum einschätzen, wie lange du konkret für etwas brauchst. Da gibt es zahllose Variablen von Vorbedingungen wie bisheriger Software, bisheriges Framework, die Grütze, die Generationen von anderen Entwicklern bereits "gehotfixed" haben etc. Dann weißt du nie 100%, wie dein Frontend oder Backend reagiert, wenn du selbst anfängst, Hand anzulegen. Einfache Dinge können dir auf einmal alles zerschießen und du recherchierst erstmal drei Tage auf Stackoverflow wo der Bug sitzen könnte. Bis sich irgendein Plugin oder eine Extension als inkompatibler Übeltäter herausstellt, aber nur wenn du XYZ verwendest, was mit ABC nicht kompatibel ist, aber schon seit DEF deprecated ist, jedoch in Browser GHI noch supportet wird, weil... weiß niemand. Und dann schaut der PM oder der Kunde mit nem Internet Explorer drauf und fragt sich, warum alles scheiße aussieht.

Finds immer lustig, wenn nicht-"Handwerker" meinen, das wäre alles simple Akkordarbeit wie in einer Nähfabrik und einzig eine Frage des Fleißes

 

[MajoPCGH]

@Krathak das ist auch immer eine typische Reaktion die ich gehört habe: du hast ja gar keine Ahnung von unserer Arbeit. Doch hab ich tatsächlich, ich hab Erfahrung in C# Entwicklung und hab auch an Projekten mitgearbeitet. Ich weiß auch dass es schwer es ist das zeitlich abzuschätzen. Dein geschilderter Fall mit Altlasten und vielen unbekannten umso mehr, das ändert aber nichts daran dass man zum wirtschaftlichen führen eines Betriebes Planbarkeit braucht, dass ein Kunde vorher wissen möchte wieviel etwas kostet und dass ich dazu den Aufwand abschätzen können muss. Von einem Vollzeitentwickler mit Erfahrung erwarte ich aber das dieser genau das kann, deswegen ist er Entwickler und nicht bloß Programmierer...