"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

Softwareentwicklung am Beispiel von CP2077

blood 11.01.2013 - 15:06 1688 43
Posts

WONDERMIKE

Administrator
Overglocker
Avatar
Registered: Jul 2001
Location: im Airflow
Posts: 8354
Zitat aus einem Post von UnleashThebeast
Ich weiß, dass du als scrum-Habschi das so sehen musst, aber genau das ist der Grund, warum Software-Entwicklung mittlerweile einfach nur ultra-Krebs ist. Agile Softwareentwicklung ist Dreck. Punkt. Man hat gefälligst ein ordentliches Produkt zu releasen, und nicht die nächsten 3 Jahre dran herumzudoktern, damits irgendwie läuft.

https://www.youtube.com/watch?v=5p8wTOr8AbU

UnleashThebeast

APES TOGETHER STRONK
Avatar
Registered: Dec 2005
Location: 127.0.0.1
Posts: 2624
Zitat aus einem Post von Viper780
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.

Und wieso ist der noch nicht beim AMS?

Ob ein Lastenheft für die Tonne oder nicht ist, ist mir als Ausführender aber Blunzen. X war die Anforderung, die beschrieben wurde, X wurde umgesetzt. Rüber mitm Süber. Ah, es hätt doch Y sein sollen statt X? Kein Problem, da is das Geld einzuwerfen.

Grad der MVP Ansatz ist eine der Sachen, die mich so grantig machen. Du baust ja auch ka Haus, bei demst amal nur die Aussenwände hinstellst und die Dachflächenfenster, hast aber ka Dach, keine Tür, keinen Innenausbau und verkaufst das dem Kunden als das "gekaufte Produkt", Teppich und Keller kommen halt erst mit einem der nächsten Releases. u wot m8?

EndOfDayz

Little Overclocker
Registered: Oct 2004
Location: Austria
Posts: 50
Als Ex-Spieleentwickler kann ich sagen, dass wir eigentlich immer zu früh released haben um Publisher-Termine zu halten und diesen glücklich zu machen.

Dabei hat dann halt wie UTB so schön sagt der ganze Innenausbau vom "Haus" gefehlt und das war dann meistens der Grund wieso das Produkt beim Kunden schlecht ankam.

Das wiederum hat den Publisher dann wiederum bewogen den Geldhahn zuzudrehen und es wurde nie ein gutes Produkt aus der ganzen Sache.

Im Endeffekt hat der Publisher dann hunderttausende Euros versenkt ohne die wiederzusehen. Die Erfahrungen sind aber aus der Zeit wo Casual-Games gerade gehyped wurden und jeder hoffte das nächste Candy Crush zu produzieren.

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 42322
Zitat aus einem Post von UnleashThebeast
Und wieso ist der noch nicht beim AMS?
Cheffe hat mit ihm demnächst ein Gespräch - auf meine drei Versuche ihm das beizubringen hat er wohl nicht als Anweisung verstanden.

Zitat aus einem Post von UnleashThebeast
Ob ein Lastenheft für die Tonne oder nicht ist, ist mir als Ausführender aber Blunzen. X war die Anforderung, die beschrieben wurde, X wurde umgesetzt. Rüber mitm Süber. Ah, es hätt doch Y sein sollen statt X? Kein Problem, da is das Geld einzuwerfen.
Problem ist dann ist keiner Zufrieden und du hast einen Rechtsstreit, den man zwar locker gewinnt - aber auch keinen Kunden mehr.
Jeder will was abliefern so dass der Großteil zufrieden ist.

Zitat aus einem Post von UnleashThebeast
Grad der MVP Ansatz ist eine der Sachen, die mich so grantig machen. Du baust ja auch ka Haus, bei demst amal nur die Aussenwände hinstellst und die Dachflächenfenster, hast aber ka Dach, keine Tür, keinen Innenausbau und verkaufst das dem Kunden als das "gekaufte Produkt", Teppich und Keller kommen halt erst mit einem der nächsten Releases. u wot m8?

Das ist aber auch nicht die Idee des MVP.
Aber im Grunde beschreibt die Vorgehensweise schön was Agil meint. Man bindet den Kunden früh/bei jedem Schritt ein um festzustellen ob man nach wie vor vom selben redet.

Wenn die Wände schon stehen aber noch ka Decke drauf ist kostet das versetzen einer Mauer oder eines Fensters einen Bruchteil als ein Jahr später wenn man das Haus fix eingerichtet übergibt.
Es heißt aber nicht dass man dann ohne Probleme aus einer Berghütte eine Lagerhalle machen kann oder unterm Haus dann doch noch den Keller einziehe.

MVP soll das mindeste beschreiben womit man das Ding auch Produkt nennen kann (also ca. die Hälfte der Umsetzung) Das ist aber eine sehr technische Sicht weshalb ich davon nichts halte. Und lieber ein loveable Produkt habe. Was ist das mindeste was den Kunden wirklich glücklich macht.

Im Hausbauthread liest man ja auch das man 10-30% mehr Kapital einplanen muss und sich die Zeit immer (drastisch) verlängert. Ist bei Software nichts anders. Wir müssen uns halt aufhören anzulügen und den "Spielraum" gleich mit einplanen.

und zu weiter oben ein Epic (also eine größere Userstory) kann nie ein Pflichtenheft sein. Aber es ist der Krenpunkt eines Lastenheftes. Also genau das niedergeschrieben was der Kunde haben will.

@EndOfDayz
Ja das kennt man eh - da hat man mit einem sturen Kunden zu tun den man nur bekommen hat weil man billiger Angeboten hat und schnellere Time to Market versprochen hat als die Mitbewerber.
Der will den Status während der Umsetzung eh nicht wissen und ist dann überrascht weil nichts passt.
Auf der anderen Seite der Projektmanager hat seinen Job nur so lange wie er verspricht dass eh alles in Ordnung ist und es das geilste Spiel ever wird...

P.S. vielen Dank fürs ausgliedern!
Top Moderation wie immer

clauskadrnoschka

still oc.at-addicted
Avatar
Registered: Mar 2001
Location: Austria, Waldvie..
Posts: 1301
Zitat aus einem Post von Viper780
Wir müssen uns halt aufhören anzulügen und den "Spielraum" gleich mit einplanen.

Ist halt leider ein Riesen-Dilemma; oft wird seitens des Projektmanagements der Zeitaufwand eklatant unterschätzt (übrigens auch von Seiten der „Arbeiter“; ich nehm mich hier garnicht aus...) bzw. den befragten Spezialisten wenig Gehör geschenkt...sobald der Spielraum eingeplant ist, ist die Kalkulation und der Zeitplan dahin...

Wie so oft; Kommunikation ist unabdingbar. Sonst ist der Interpretationsspielraum für Mißverständnisse (noch) größer...

„Gezwungen“ durch meine Arbeit als Lehrer für Projektmanagement (hier gehts allerdings nur um die Grundzüge...), lass ich immer wieder meine Arbeit beim vorigen Arbeitgeber Revue passieren. Und komm immer wieder drauf, welche Anfänger wir in jeder! Hinsicht waren

Bei CDPR wirds net anders zugehen...

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 42322
Ja klar Komplexität wird immer unterschätzt.

Das macht dann die Erfahrung aus. Das ist auch wieder die Stärke von agilen Methoden und natürlich muss man genau auf die hören welche die Arbeit auch machen.

Meine Erfahrung ist hier eher Komplexität zu schätzen und dann mit der Velocity zu multiplizieren. Dabei in jedem Schritt großzügig aufrunden und nachher noch einen Puffer drauf rechnen.

COLOSSUS

# pkill -9 .
Avatar
Registered: Dec 2000
Location: Wien || Stmk
Posts: 11005
Zitat aus einem Post von Viper780
Meine Erfahrung ist hier eher Komplexität zu schätzen und dann mit der Velocity zu multiplizieren. Dabei in jedem Schritt großzügig aufrunden und nachher noch einen Puffer drauf rechnen.

Meine Erfarhung ist, dass die ganze Schaetzerei und das Zeremoniell rundherum zum Owereibm is. Aber taugt super zum Empire Building, wenn man jedem Team auch noch einen Scrum Master dazustellen kann.

DKCH

aha?
Avatar
Registered: Aug 2002
Location: #
Posts: 3087
und es bringt imho noch weniger, wenns um produktentwicklung mit releasedatum geht und nicht die in-house entwicklung der webhostingbude...

Smut

takeover & ether
Avatar
Registered: Feb 2003
Location: VIE
Posts: 15599
was ist eine bessere methode?
einfach arbeiten lassen bis tag x und schauen wie weit man ist und das selbe dann noch mal bis tag y?

Obermotz

Fünfzylindernazi
Avatar
Registered: Nov 2002
Location: OÖ/RI
Posts: 5101
Wir haben keine Scrum-Master im Projekt, es wird aber in allen Teams meines Projekts einmal am Beginn jedes Sprints estimated - weniger damit wir genau wissen wie lange was dauert, sondern eher damit die Devs die Features kennen lernen, die sie in den kommenden zwei Wochen implementieren werden.
Wir haben die Estimations ein paar Monate ausgesetzt (Tickets nur im Schnelldurchgang von den Teamleaders geschätzt), aber ich hatte das Gefühl, dass sie was bringen, deshalb auch wieder aktiv momentan.
Weiters schätzen wir nicht in Zeit, sondern in complexity, sodass sich die Arbeit leichter zwischen den Juniors und den Seniors aufteilt.

//Außerdem hatten wir in der kurzen Zeit ohne Schätzung genau gar keinen Überblick über die Velocity, deshalb bin ich jetzt froh, dass die Charts wieder funktionieren.
Das ist ja das schöne an den agilen bzw. am Scrum-Prozess. Du kannst und sollst ihn dir richten wie er am besten passt.

// Schon interessant in welchen Superlativen manche hier schreiben..
Agil ist "Dreck", wir brauchen wieder Wasserfall.. Hallo?? könnts ihr euch nimma erinnern warum Wasserfall durch agil verdrängt wurde? Genau, weil (iirc) 70% der Projekte gescheitert sind :rolleyes:
Bearbeitet von Obermotz am 17.01.2021, 20:47

clauskadrnoschka

still oc.at-addicted
Avatar
Registered: Mar 2001
Location: Austria, Waldvie..
Posts: 1301
Oft haperts extrem an der gegenseitigen Erfahrungslosigkeit; wir hatten schon heftige Streitereien (bis zum Rausschmiss eines Engineers meinerseits), weil div. Egos keinerlei Einfühlungsvermögen für die „Gegenseite“ hatte...und fälschlicherweise auch oft vom gegenseitigen „unendlichen“ Erfahrungsschatz ausgegangen wurde.
Und das Tagesgeschäft sich nicht nur immer ums neueste Projekt gedreht hat; und eigene Unzulänglichkeiten eingestehen...da bin ich jetzt (hoffentlich) schon 1-2 Schritte weiter ;)

Zum Ende des Tages haben 90% der MA entsprechend Einsatz gezeigt; und die Alpha-Tiere gibts leider endlos...

Viper780

Er ist tot, Jim!
Avatar
Registered: Mar 2001
Location: Wien
Posts: 42322
Zitat aus einem Post von COLOSSUS
Meine Erfarhung ist, dass die ganze Schaetzerei und das Zeremoniell rundherum zum Owereibm is. Aber taugt super zum Empire Building, wenn man jedem Team auch noch einen Scrum Master dazustellen kann.

Es gibt da die No estimate Bewegung die nicht Unrecht hat. Bei sehr Betriebsnahen Teams lass ich auch nicht schätzen (bringt nix).

Zerimoniell gibt's eigentlich keins, das kann jedes Team sich selbst zurecht legen. Mir persönlich ist wichtig das alle im Team was zu jeder einzelnen Story sagen.

Für Schätzungen sollt ma nicht zu viel Zeit aufwenden. Sondern so wie Obermotz sagt drüber reden was gewünscht ist und wie man es umsetzen kann.
Oft wird den meisten die Komplexität erst klar - manchmal kommt man drauf das es sowas aber auch schon gibt und man quasi nur "Doku" und vorallem Tests schreiben muss.

Beim (Komplexität) Schätzen muss halt jedem klar sein dass die einzelnen Schätzungen grob schwanken können und mit viel Pech auch den Sprint kosten kann. Aber im Mittel sollte es sich ausgleichen.
Die Velocity nur über die letzten 2-4 Sprint rechnen, dann wird schneller klar das es wo hapern könnte.


"Ein guter Scrum Master kann 2-3 Teams behilflich sein, ein sehr guter einem Team"


@clauskadrnoschka
Das ist die persönliche Komponente die immer dabei ist. Aber jedes Team braucht seine Alpha, Beta und Omega Leute

smashIt

master of disaster
Avatar
Registered: Feb 2004
Location: OÖ
Posts: 4127
Zitat aus einem Post von Obermotz
// Schon interessant in welchen Superlativen manche hier schreiben..
Agil ist "Dreck", wir brauchen wieder Wasserfall.. Hallo?? könnts ihr euch nimma erinnern warum Wasserfall durch agil verdrängt wurde? Genau, weil (iirc) 70% der Projekte gescheitert sind :rolleyes:

und das ist heute besser?
oder wird heute "gescheitert" auf "gold master" umgelabelt?

gerade bei spielen hab ich das gefühl, dass heute alles was das logo des publishers erfolgreich anzeigt, als minimum viable product durchgeht...

JDK

Oberwortwart
Avatar
Registered: Feb 2007
Location: /etc/graz
Posts: 1966
Zitat aus einem Post von UnleashThebeast
baust ja auch ka Haus, bei demst amal nur die Aussenwände hinstellst und die Dachflächenfenster, hast aber ka Dach, keine Tür, keinen Innenausbau und verkaufst das dem Kunden als das "gekaufte Produkt", Teppich und Keller kommen halt erst mit einem der nächsten Releases. u wot m8?

Wo ist denn das Problem? Ein Haus im Nachhinein zu unterkellern ist doch kein Problem. ;)

Leider haben viele Non-Devs die Denkweise, dass dann eh, sobald man was zum Herzeigen hat, gleich mal ein fertiges Produkt raus schaut. Genau so entstehen dann unhaltbare Deadlines und Vorstellungen. Aber hey, wenigstens kommen hier ein paar PMs zum Developer Bashen. ;)
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz