Softwareentwicklung am Beispiel von CP2077

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?

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

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.

und es bringt imho noch weniger, wenns um produktentwicklung mit releasedatum geht und nicht die in-house entwicklung der webhostingbude...

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

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

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.