Bullshitbingo Teammeeting Scrum

Jetzt gehts richtig rund. Ab jetzt schießt der Formalismus völlig durch 
die Decke. Nun muss jeder Task aus dem Sprint in 5 Stufen abgearbeitet 
werden und für alles, egal wie klein der Task ist müssen Dokumentation, 
automatisierte Tests geschrieben, eigene Tests durchgeführt und an einen 
Kollegen zum Test übergeben werden. Zusätzlich muss es ein Review mit 
zwei Kollegen der freien Wahl geben und es gibt am Ende eine 
Gesamtabnahme in der alles nochmal durchgekaut wird. Besprechung am 
ersten und letzten Tag dauert zusammen fast einen ganzen Tag. 
Abweichungen von diesen Vorgaben dürfen nicht erfolgen, auch wenn es 
sich um 10 Zeien Code oder eine Bugfix handelt.

Und das bei einem 6 Mann starken Team ..... Irrenhaus³. Und die fahren 
da alle voll drauf ab. Ich hätte die Software mit einem vernünftigen 
Lastenheft schon längst alleine fertig geschrieben.

Unglaublich ....

Unglaublich schrieb:
> Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu
> managen....

PS: Ein Kollege ist inzwischen sogar wirklich der Scrummaster. Die 
Hälfte seiner Vollzeit ist der nur mit diesem Unsinn beschäftigt........

Unglaublich schrieb:
> Irrenhaus³. Und die fahren da alle voll drauf ab. Ich hätte die Software
> mit einem vernünftigen Lastenheft schon längst alleine fertig
> geschrieben.
> Unglaublich ....

Change it, love it or leave it.

Morgen fängt ein siebter Kollege in Vollzeit an, der wird sich noch 
wundern..

Beim "Daily Standup" liege ich meistens noch im Bett

Unglaublich schrieb:
> Abweichungen von diesen Vorgaben dürfen nicht erfolgen, auch wenn es
> sich um 10 Zeien Code oder eine Bugfix handelt.

Ohne jetzt ein großer Fan von Scrum oder ASPICE zu sein, aber die Bugs 
gibt es häufig nur deswegen, weil viele Programmierer einfach etwas 
nicht ausreichend geprüftes einchecken. Wenn man immer 2 andere drüber 
schauen lässt und gleich automatisierte Tests erstellen muss, dann 
landen viele Bugs erst gar nicht im Feld. Ja, ich weiß, die meisten 
Programmierer kennen den Sinn und haben trotzdem keinen Bock. Beim 
Kunden sind Fehler viel teurer, als wenn sich 3 coding monkeys öfter mal 
gegenseitig prüfen.

M. W. schrieb:
> Wühlhase schrieb:
>> Was durchaus funktioniert, ist, daß jemand, der NICHT im Designprozess
>> drinsteckt, wertvolle Denkanstöße liefern kann.
>> Ich jedenfalls finde prinzipiell nichts Schlechtes daran, anderen meine
>> Designentscheidungen zu erklären oder "Warum hast du das so
>> gemacht"-Fragen zu beantworten.
>
> Das erfordert aber, dass der Tippgeber etwas davon versteht. Aber wie
> soll ein Elektroniker in der grossen Runde ein Programm hinterfragen?

Da hast du mich falsch verstanden. Ich schrieb und meinte "Jemand, der 
NICHT im Designprozess drinsteckt".
Ich meinte ausdrücklich NICHT "Jemand der zwar nicht im Designprozess 
drinsteckt, aber soviel Erfahrung hat daß er das ganze Projekt auch 
alleine wuppen könnte".

Der Elektroniker, der sonst nur in C programmiert, fragt z.B. garantiert 
und zu Recht, warum da jetzt ein Linux mit Pythoninterpreter und 
JavaScript laufen muß wenn man das Problem auch mit einem einzelnen 
Programm und kleinerem Controller erschlagen kann.

Wenn man derart Außenstehenden seine Vorgehensweise klar und vertändlich 
darlegen kann ist das ein gutes Zeichen, daß man auf dem richtigen Weg 
ist.