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..
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.