Aber da Viper is mit solchen Aussagen scho öfter aufgefallen. Bei dem sind alle Projekte perfekt geplant, da wird nie auch nur eine Überstunde geschoben
URL: https://www.overclockers.at/applications/softwareentwicklung-am-beispiel-von-cp2077_257235/page_2 - zur Vollversion wechseln!
Zitat aus einem Post von nfin1teEs ging hier um die Verantwortlichkeit für das Disaster und die Aussage, dass es an den Devs gelegen ist. Vorallem ist anscheinend eine unrealistische Zeitvorgabe auch Schuld der Devs.
In 8 Jahren kann man sehr wohl ein tolles Haus bauen, aber auch nur wenn Organisation passt und nicht von oben dauernd Dinge geändert werden.
Wenn du zuerst ein Hochhaus planst, dann zwischenzeitlich einen Palast willst und am Ende dann ein Bungalow rauskommt, dann reichen auch 8 Jahre nicht.
Ist das dann die Schuld des Bauarbeiters?
Zitat aus einem Post von nfin1teEs ging hier um die Verantwortlichkeit für das Disaster und die Aussage, dass es an den Devs gelegen ist. Vorallem ist anscheinend eine unrealistische Zeitvorgabe auch Schuld der Devs.
In 8 Jahren kann man sehr wohl ein tolles Haus bauen, aber auch nur wenn Organisation passt und nicht von oben dauernd Dinge geändert werden.
Wenn du zuerst ein Hochhaus planst, dann zwischenzeitlich einen Palast willst und am Ende dann ein Bungalow rauskommt, dann reichen auch 8 Jahre nicht.
Ist das dann die Schuld des Bauarbeiters?
Zitatich versteh das hinbeissen auf die devs absolut nicht.
Wer hier die Schuld bei den Devs sucht, hat keine Ahnung von Softwareenwicklung. Punktum.
Aber da Viper is mit solchen Aussagen scho öfter aufgefallen. Bei dem sind alle Projekte perfekt geplant, da wird nie auch nur eine Überstunde geschoben
wir ham uns alle lieb 
Meine persönliche Meinung dazu: Wenn ein Projekt mit dauerhaftem 13 H crunch pro Tag umgesetzt werden muss isses einfach Fehlplanung. Es sind sicher nicht alle Devs absichtlich langsam beim Arbeiten. Muss am Management liegen.
ich würd jetzt ned nur das management in der schuld sehen
oft genug sind auch die jeweiligen teamleader mit dran schuld weil sie keine eier haben um auch im management dann klipp und klar unterzubringen dass das verlangte mit den zur verfügung gestellten ressourcen nicht erreicht werden kann
umgekehrt aber genau so gewissen mitarbeitern dann auch grenzen zu setzen um z.b. das genannte gold plating abzudrehen
und nur all zu oft sind diese wichtigen stellen mit speichelleckern absolut falsch besetzt
Zitat aus einem Post von userohnenamenich würd jetzt ned nur das management in der schuld sehen
oft genug sind auch die jeweiligen teamleader mit dran schuld weil sie keine eier haben um auch im management dann klipp und klar unterzubringen dass das verlangte mit den zur verfügung gestellten ressourcen nicht erreicht werden kann
umgekehrt aber genau so gewissen mitarbeitern dann auch grenzen zu setzen um z.b. das genannte gold plating abzudrehen
und nur all zu oft sind diese wichtigen stellen mit speichelleckern absolut falsch besetzt
Zitat aus einem Post von 3mindteamleads gehören zum management.
ansonsten stimme ich dir aber zu.
ja, grundsätzlich habts natürlich recht aber das mittlere management hat halt nur indirekt einfluss auf das was oben ausgegeben wird (ziele, ressourcen, etc.)
und wenn genau der indirekte einfluss quasi inexistent ist oder auch von oben ignoriert wird passiert halt genau sowas (imho)
edit: wobei ich persönlich noch immer happy bin mit dem spiel (wenn ich dann mal wieder zeit hab zum spielen)
Zitat aus einem Post von bloodalso doch ganz einfach, das ganzeich hoffe du hast irgendwo als top manager angeheuert.
Zitat aus einem Post von InfiXich hoffe auf mehr customization... autos, waffen, farben mehr outfits etc.
ansonsten wenn einfach mehr sidequests kommen mit der gleichen qualität wie die im spiel bin ich auch schon happy.
wer weiss vielleicht wird die karte ja auch noch bissl erweitert.
Zitat aus einem Post von Viper780Eher typisch Developer.
Es gibt eine Timeline und die gilt es zu halten. Gold Plating ist in vielen Fällen unnötig und lieber ein stabiles, nicht so hübsches Produkt bringen.
D.h. back to Wasserfall oder wie?^^
Ja.
Außerdem noch anzumerken ist: Nein, 40 JIRA-Epics sind kein Ersatz für ein Pflichtenheft.
Wir fahren eine Zerobug Policy (so gut es geht) - Stabilität hat immer Vorrang und kann im Prozess verankert werden.
Ich red da von Funktionen und den neuesten Techniken/Technologien die noch wer schnell einbauen will.
Wir haben einen Entwickelter der schreibt jetzt zum dritten mal die User Verwaltung um weil es ihm so besser gefällt. Der Code wird nicht besser, da kommen keine neuen Funktionen rein und die Testbarkeit steigt auch nicht.
Macht er natürlich geheim und versteckt. Plötzlich ist da wieder ein riesiger merge request. Kommt natürlich mit seiner Arbeit hint und vorn ned zam.
Von so Dingen rede ich. 1/3 der Arbeit kann man mit ordentlicher Anforderungsanalyse (auch das geht Agil, wenn man eine passende Architektur hat) immer einsparen.
Ein weiteres Drittel wenn man am Anfang viel in Automatisation (und Monitoring) steckt.
Für verbuggte Software die offensichtlich ist gibt's keine Entschuldigung.
Genau sowas sollte Agil (Scrum ist ja nur eins von vielen Frameworks) nicht passieren.
Die Idee ist dass man sehr früh eine Architektur und einen herzeigbaren Prototypen hat, den man Schrittweise um Funktionen und optische Spielereien erweitert und irgendwann ein "Minimal Loveable Produkt" (MVP also viable halte ich für den falschen Ansatz) hat. Das kann dann als Beta zu den ersten Kunden die man befragt was sie sich wünschen. Dann noch eine polishing Runde mit einigen der Funktionen und man hat ein Produkt welches man langjährig vermarkten und erweitern kann.
Edit:
Ich hab einige Pflichtenhefte geschrieben. Wenn das Lastenheft für die Tonne ist und sich keiner über die Wünsche im klaren ist kannst das vergessen.
Üblicherweise wirft man dann 80% wieder weg und baut in der Version 3 dann erst das was dem Kunden wirklich hilft.
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025