Die Schnappsidee von "Quaitätssicherung und Dokumentation ist zweitrangig"

[Urbautz]

ist das was Scrum so unsinnig macht.

Man umgeht das, indem in einer einer Userstory nicht nur "Story Formulieren" und "Entwickeln" Aufgaben sind, sondern auch "Codereview", "Blackbox-Test" "Integrationstest" und "Dokumentation" und "Datentransformtion / Migration". Und erst wenn all diese Aufgaben durchgeführt sind, gilt eine Userstory als erfüllt.

Das lässt sich mit einer modernen Rollout-Architektur auch gut erreichen: Der Entwickler entwickelt "lokal", dann geht die Änderung in ein "Review"-System für den Codereview und Blackblox im zweiten Sprint, im dritten dann entweder zurück an den Entwickler oder weiter zum I-Test, und im vierten ins "Pre-Prod", wo dann auch die Kundenabnahme erfolgt.

Irgendwann werd ich dafür wohl mal ein Buch schreiben und es Quality-Scrum oder so nennen.

[karazon]

Oder man hat und befolgt eine Definition of Done ;-)

[Urbautz]

Da wirds schwierig, weil eine Aufgabe ja immer von einem gemacht werden soll. Sonst verfällt man zu schnell in ein Kartenschubbsen. Und da tests ja aufwendiger sein können, würde jede Aufgabe die Sprintlänge überschreiten.

[JE]

karazon schrieb:
--------------------------------------------------------------------------------
> Oder man hat und befolgt eine Definition of Done ;-)

Jepp - jeder Task gehört gereviewet und jedes Story QSt und abgenommen.. und ja, dazu gehören Unittests, Integrationstests sowie manuelle Tests, Dokumentation sowie ordentliche Security (abgesicherte Endpunkte, minimale Datenhaltung und Transfer, ordentliches Privilegienhandling usw.) selbstverständlich dazu.

[karazon]

Urbautz schrieb:
--------------------------------------------------------------------------------
> Da wirds schwierig, weil eine Aufgabe ja immer von einem gemacht werden

Wer hat euch denn - mit Verlaub - den Schwachsinn erzählt?

> Und da tests ja
> aufwendiger sein können, würde jede Aufgabe die Sprintlänge überschreiten.

Dann müsst ihr kleiner schneiden. Ohne Tests/ohne ausreichende Tests ist Code per se als defekt anzusehen.

Bitte nicht falsch verstehen, ich kann den Frust vieler Entwickler:innen in kaputten agilen Vorgehensweisen gut nachvollziehen. Ich weiß aber auch aus persönlicher Erfahrung, dass das sowohl in kleinen, als auch skaliert in größeren Projekten (60+ Devs) sehr gut funktionieren kann...



1 mal bearbeitet, zuletzt am 24.05.22 18:34 durch karazon.

[JE]

karazon schrieb:
--------------------------------------------------------------------------------
> Urbautz schrieb:
> ---------------------------------------------------------------------------
> > Und da tests ja
> > aufwendiger sein können, würde jede Aufgabe die Sprintlänge
> überschreiten.
>
> Dann müsst ihr kleiner schneiden. Ohne Tests/ohne ausreichende Tests ist
> Code per se als defekt anzusehen.

Wo soll denn bitte das Problem sein, wenn ein paar Tasks nicht zum Sprintende fertig sind? Wir haben manchmal schon Stories, die über 2-3 Sprints gehen. Klar sollte das nicht der Normalfall sein, aber passieren kann es.
Wenn eine Story oder Task nachgezogen wurde, wird es nochmal wahrscheinlicher, daß zum Sprintende noch etwas offen ist - wir nehmen das dann einfach mit.

[karazon]

JE schrieb:
--------------------------------------------------------------------------------
> karazon schrieb:
> ---------------------------------------------------------------------------
> -----
> > Urbautz schrieb:
> >
> ---------------------------------------------------------------------------
>
> > > Und da tests ja
> > > aufwendiger sein können, würde jede Aufgabe die Sprintlänge
> > überschreiten.
> >
> > Dann müsst ihr kleiner schneiden. Ohne Tests/ohne ausreichende Tests ist
> > Code per se als defekt anzusehen.
>
> Wo soll denn bitte das Problem sein, wenn ein paar Tasks nicht zum
> Sprintende fertig sind? Wir haben manchmal schon Stories, die über 2-3
> Sprints gehen. Klar sollte das nicht der Normalfall sein, aber passieren
> kann es.
> Wenn eine Story oder Task nachgezogen wurde, wird es nochmal
> wahrscheinlicher, daß zum Sprintende noch etwas offen ist - wir nehmen das
> dann einfach mit.

Da hast du mich vermutlich falsch verstanden. Ich wollte ausdrücken, dass, wenn Stories regelmäßig zu groß sind, um sie innerhalb eines Sprints umzusetzen, eine Unterteilung in bewältigbare Aufgabenblöcke, die auch die DoD erfüllen, sinnvoll ist.
Gerade bei "Nachziehern" würde ich es auch immer in Kauf nehmen, dass es im nächsten Sprint fertiggestellt werden muss.

Ich glaube wir sind eigentlich einer Meinung.

Und hin und wieder nicht fertig zu werden, ist auch völlig normal. Ziel sollte es meines Erachtens aber sein, möglichst genau zum Sprintende fertig zu werden, um das Commitment des Teams auf die Inhalte des Plannings nicht mit der Zeit zu verwässern.