Forum: Ausbildung, Studium & Beruf Bullshitbingo Teammeeting Scrum


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Unglaublich (Gast)


Bewertung
13 lesenswert
nicht lesenswert
Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte ich 
das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden.

Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch 
einfach mal am Anfang einer Entwicklung einen Anforderungskatalog 
erstellen können - dann könnte man sich diesen modernen Unsinn sparen 
und jeder weiß, was realistisch zu tun ist.

Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu 
managen....

von René H. (Firma: anonymous) (hb9frh)


Bewertung
5 lesenswert
nicht lesenswert
Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur 
beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-)

https://www.scaledagileframework.com/

Grüsse,
René

von Nick M. (muellernick)


Bewertung
1 lesenswert
nicht lesenswert
Aber es funktioniert doch!
Bin mir sicher, dass Boing das komplett umgesetzt hat. Nicht nur bei der 
737 MAX, sondern auch beim Starliner:
https://www.msn.com/en-us/news/technology/nasa-faults-boeing-for-critical-software-defects-in-starliner/ar-BBZLxkm
Also zumindest konnte man einen Bug beheben, als der Starliner schon im 
Weltall war.
Gut, die Sache dass die Uhrzeit unerheblich (mehrere Stunden; 6?) 
daneben war ist immer noch so. Aber im Weltall gibt es ja auch keine 
Zeitzonen. Also unerheblich! Kommt dann im nächsten Release. Morgen.

von Kai (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte ich
> das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden.

René H. schrieb:
> Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur
> beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-)

Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben 
vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen 
intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und 
agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und 
soll.

Man hört aber immer die Entwickler heulen dass das alles so zäh und 
ineffizient sei. Dann kann man es doch Abteilungsintern wieder 
abschaffen.
Oder hört man wie meistens nur den geringen Teil der Entwickler schreien 
und der größere Teil ist damit erfolgreich?

von Edgar S. (Firma: keine) (heinbloed1)


Bewertung
5 lesenswert
nicht lesenswert
Kai schrieb:
> Bekommen das die Entwickler von oben
> vorgegeben

Genau so geht das, bei uns hatte sich der CEO mal ein Buch
darüber gekauft. Jetzt haben wir alle diesen Bockmist an der
Backe......

von Unglaublich (Gast)


Bewertung
8 lesenswert
nicht lesenswert
Kai schrieb:
> Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben
> vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen
> intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und
> agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und
> soll.

Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und 
viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten.

Die finden das alle total geil und leben das. Die wollen das und bringen 
das aktiv voran.

Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal 
den Rasen mähen muss.

Fehlt mir da ein Gen? Ich bin nicht älter als die. Das ist ja nicht nur 
die Arbeitsweise (Scrum etc.), sondern alles wird in höchst 
unübersichtlichen Tools verpackt, die auch noch mal mega viel Zeit 
fressen. Da ist man (mit einem kleinen Produkt) noch in der Entwicklung 
und verpackt das alles in Release und Sub Releases bla bla bla... wenn 
ich zusammenzähle werden hier ca. 10 verschiedene Tools nur zur 
Organisation verwendet, welche gar nichts mit der Entwicklung an sich zu 
tun haben.

Da wäre mir sogar eine Exceltabelle lieber, als das...

von Udo S. (urschmitt)


Bewertung
1 lesenswert
nicht lesenswert
Kai schrieb:
> wobei jeder selbstorganisiert und freier arbeiten kann

Selbstorganisierte Selbstausbeutung.

Kai schrieb:
> Oder hört man wie meistens nur den geringen Teil der Entwickler schreien
> und der größere Teil ist damit erfolgreich?

Wer nix besseres kennt ist zufrieden.

Kai schrieb:
> Wie wird Scrum eigentlich gelebt?

Klar, wenn ein idealisiertes Modell in der Realität nicht funktioniert 
ist nicht das Modell sondern die Realität schuld. Ergo: Die Realität 
abschaffen.

Wie sagte Einstein mal so treffend: "Man sollte Dinge so einfach wie 
möglich machen, aber nicht einfacher"

von arbeitsloserArbeitsloser (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Da wäre mir sogar eine Exceltabelle lieber, als das...

Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich 
Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert!

Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu 
drücken!

von Unglaublich (Gast)


Bewertung
1 lesenswert
nicht lesenswert
arbeitsloserArbeitsloser schrieb:
> Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich
> Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert!
>
> Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu
> drücken!

Ist schon in Ordnung mit professionellen Tools zu arbeiten. Aber dieser 
Zustand hier ist für mich nicht mehr lange tragbar.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
arbeitsloserArbeitsloser schrieb:
> Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich
> Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert!
>
> Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu
> drücken!

wurden wir nicht dazu erzogen mit GEM GUI usw.?
wer mag denn noch Befehlszeilen eintippen? ich jedenfalls nicht.

Ich bin auch froh das ich meine flachen Teller im Schrank immer blind an 
der selben Stelle finde, dumm halt wenn die bessere Hälfte meint mal 
umräumen zu müssen, dann landet die Pizza auf einem tiefen Teller.

Scrum liest sich im Wiki nicht schlecht, sowas hatte ich vor 25 Jahren 
schon in der Prüfentwicklung ohne diesen Fachbegriff, jeder entwickelte 
seine SW Module, am Freitag beim gemeinsamen Frühstück wurden die 
untereinander getauscht und so profitierten ALLE davon. Der Informatiker 
goß das noch in ein passendes Konzept und Doku.

Nur der "Chef" verstand nicht warum am Freitag unsere Pausen so lange 
dauerten, das waren die "Teammeetings". Die Zeit beim Frühstück wurde 
aber mehrfach wieder eingespart weil es keine parallel Entwicklungen 
gab.

von soso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Naja, wenns sich um ein Prj. mit ein paar Mannstunden handelt, ist der 
Overhead nicht gerechtfertigt.
Im Gesamtkontext sehr sinnvoll, weil meist gar nicht so wirklich klar 
ist, was entwickelt werden soll.

Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip.

Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel. 
Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft 
wird dann doch alles wieder umgeschmissen?

von SchonWiederGast (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und
> viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten.

Jung, dynamisch, erfolglos...

> Fehlt mir da ein Gen?
Nein, Du bist nur intelligenter, als die Lemmingmasse.

von Wolle (Gast)


Bewertung
1 lesenswert
nicht lesenswert
soso schrieb:
> Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip.
>
> Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel.
> Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft
> wird dann doch alles wieder umgeschmissen?

Das sehe ich überhaupt nicht so.

Ich bin jetzt seit ca. 20 Jahren in der Softwareentwicklung und fand es 
noch nie so unproduktiv und frustrierend wie seit der Einführung von 
SCRUM.

Für mich ist inzwischen klar, dass SCRUM bzw. die agile Arbeitsweise 
hauptsächlich einer gewissen Gruppe von Anforderern dient - nämlich 
denen, die es damals schon nicht drauf hatten, ihre Anforderungen klar 
zu definieren und immer schon dagegen waren, dass Projektbudget für 
Dokumentation und Analyse verbraucht wird.

Und die Entwickler, die heute neu dazukommen, haben Analyse und 
"Systementwicklung" ebenfalls absolut nicht drauf. Die können garnix 
anderes mehr, als aus dem Kopf in Konsole zu programmieren und im ewigen 
Hin- und Her mit dem Anforderer ultralangsam ans Ziel kommen.

Erfolgversprechender als ein Wasserfallmodell?
Ja klar - wenn man nix kann, auf jeden Fall. Denn sonst kommt man mit 
dem Wasserfallmodell erst gar nicht so weit, dass die Programmierer mal 
aktiv werden.

Das einzig tolle daran:
Ich kann jetzt ca. 1/3 meiner wöchentlichen Arbeitszeit in Meetings, 
Dailys, Telefonkonferenzen und JIRA-Pflege verbringen. Sitze also im 
Grunde nur rum und kassiere dafür genauso viel Geld, wie für eine 
vernünftige Systemanalyse.


Absolut lächerlich.

Meine persönliche Konsequenz:
Ich distanziere mich weiter von meiner Arbeit und schraube meinen 
eigenen Anspruch runter. Das Produkt hat hier eindeutig an Bedeutung 
verloren... wichtiger ist, dass alle vom PO an aufwärts ihre Häkchen 
machen können und bunte Bilder sehen.

"Guck mal - die neue Software!!!
Sie hilft uns zwar nicht weiter aber sie ist fertig."

von endwiggler (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Kai schrieb:
> Oder hört man wie meistens nur den geringen Teil der Entwickler schreien
> und der größere Teil ist damit erfolgreich?

Ich bin auch kein großer Fan davon, ich hätte auch lieber Requirements 
die ich abhaken kann und dann zufrieden bin.

Dennoch, wenn man einigermaßen weiß, was man tun muss, damit das Projekt 
ein Erfolg wird, ist es am Ende egal.

Dann präsentiere ich meine Fortschritte eben Scrum-kompatibel in 2 
Wochen großen Häppchen.

Dann sind die Scrummaster zufrieden, dass ich selbst einen 
längerfristigen Plan verfolge muss der nicht wissen.

von Unglaublich (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
endwiggler schrieb:
> Dann sind die Scrummaster zufrieden, dass ich selbst einen
> längerfristigen Plan verfolge muss der nicht wissen.

Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal 
häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in 
der Firma am Kicker fachsimpeln.

von Achim H. (anymouse)


Bewertung
1 lesenswert
nicht lesenswert
Wolle schrieb:
> Erfolgversprechender als ein Wasserfallmodell?

Dann stell mal bitte das Wasserfallmodell für Facebook auf. Oder e-Bay.
Oder allein einmal die vollständigen Requirements für Facebook -- und 
zwar alle bis .. sagen wir mal heute. Und zwar mit dem Wissen von 2004.

Wenn Du es etwas kleiner haben möchtest: Nimm als Gedankenexperiment 
einmal die vollständigen Requirements eines Forums (wie dieses hier), 
und die Umsetzung mittels Wasserfallmodell.

Beitrag #6141130 wurde von einem Moderator gelöscht.
von endwiggler (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Unglaublich schrieb:
> endwiggler schrieb:
>> Dann sind die Scrummaster zufrieden, dass ich selbst einen
>> längerfristigen Plan verfolge muss der nicht wissen.
>
> Uhuh, ganz ganz schlechte Teammoralbildung

Nö, mein (Entwickler-)Team ist ja eingeweiht. Der Scrummaster gehört nur 
nicht dazu, zu diesem Team.

von Michael Gugelhupf (Gast)


Bewertung
6 lesenswert
nicht lesenswert
Unglaublich schrieb:
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können

Ist doch durch Srum abgedeckt. Leider hat alles in Scrum beschissene, 
irreführende, "moderne" Bezeichnungen und es werden haufenweise 
Nebelkerzen geworfen. Bullshitbingo  ist schon das richtige Wort dafür. 
So findet sich der Anforderungskatalog in Form des "Backlogs" (zusammen 
mit ein paar anderen Dingen).

Noch beschissener ist die Terminologie wenn es darum geht die 
Anforderungen zu präzisieren und aktuelle Änderungen einzuarbeiten. 
Backlog Grooming und Refinement. Als ob es zum Hundefriseur geht :-(

Dass zum Backlog Grooming und Refinement gar nicht das ganze Team 
antreten muss wird gerne übersehen und so werden Teams Woche für Woche 
mit sinnlosen Monologen über Backlog-Items gequält. Erst dann fühlt sich 
der Product Owner groß, stark und mächtig. "Jetzt müssen sie mir alle 
mal zuhören, jetzt red i".

Product Owner ist noch so ein beschissener Scrum Term. Dem Product Owner 
gehört gar nicht das Produkt. Er ist nur Herr über den 
Anforderungskatalog, hat den gefälligst ranzubringen, aktuell zu halten, 
die Anforderungen zu priorisieren und dem Team Rede und Antwort zu 
stehen wenn Anforderungen unklar sind.

Statt dessen wird Product Owner gerne als Ehrentitel an einen Manager 
vergeben der von der Technik (und damit den Anforderungen) keine Ahnung 
hat und seinen Arsch nicht hoch bekommt.

> - dann könnte man sich diesen modernen Unsinn sparen
> und jeder weiß, was realistisch zu tun ist.

> Da braucht man wirklich bald einen Scrummaster,

Jedes Team "braucht" einen Scrummaster. Kleine Teams notfalls in 
Teilzeit oder als Doppelfunktion Entwickler / Scrummaster.

> um ein kleines Team zu
> managen....

Der Scrummaster managed nicht das Team. Vereinfacht gesagt, er schützt 
den Prozess. Er hat keine Vorgesetztenfunktion sondern steht im Dienst 
des Teams.

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
Michael Gugelhupf schrieb:
> Der Scrummaster managed nicht das Team. Vereinfacht gesagt, er schützt
> den Prozess.

Im übertragenen Sinn: Er stellt sicher dass die ISO-9000 bzgl. SCRUM 
eingehalten wird :-)

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können

Was meinst du, warum Software seit der Erfindung und zunehmenden 
Verbreitung von Scrum und anderen agilen Methoden so viel schlechter 
geworden ist.

Gestern durfte ich jemandem helfen, dessen Thunderbird nach dem Update 
vom 28.1. keinen 'Senden' Knopf mehr hat. Im 'Neue Nachricht erstellen' 
Fenster gibt es gar nichts mehr, kein Menü, keine Knöpfe, nur 
Adresszeile und Textfeld.

Immerhin ergab eine Suche im Web die Lösung: Alt drücken. Dummerweise 
gibt es das Problem schon mindestens seit 2013, immer wieder, aber man 
ist bei Mozilla zu blöd es zu beheben.

Daß bei dem Update die Knöpfe wie 'Antworten' auf der Nachrichtenliste 
vom Kopfbereich in die Vorschau gewechselt sind, muss auch an einem 
Entwiggler mit kleinem Hirn aber quadratmetergrossem Bildschirm liegen. 
Auf normalen Bildschirmen kann man sich gar keine Vorschu anzeigen 
lassen, so verschwenderisch geht Thunderbird mit dem Bildschirmplatz um. 
Dumm nur, daß auf die Art der Knopf beim Update auch verschwunden ist. 
Immerhin kann man ihn dort in die noch weiter oben liegende Button-Bar 
konfigurieren.

Es ist weitgehend egal wo du hinguckst: Überall wird Software 
schlechter. Selbst mein Auto hat Bugs, durch die es den Funkschlüssel 
'vergisst', was die Markenwerkstatt durch einen 1900 EUR teuren Wechsel 
de Funkempfängers beheben will, weil sie nicht weiss, wie man das 
Vergessen rückgängig macht, sondern glaubt die Hardware wäre defekt.

von soso (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Das ganze Leben ist umständlich und kompliziert. Vor allem eins - 
anstengend.

Meistens wird man mit Arbeit zugemüllt und hat keinen Einblick oder kein 
Interesse für die Tätigkeit des PL zB, der dafür sorgt, dass das Projekt 
zusammengehalten wird.

Noch ein zusätzlicher Prozess, na Danke. Dennoch. Würde sagen unter dem 
Strich ist dies eine Verbessserung, vor allem von der Kommunikation.

Die meisten, die sich hier auslassen über Scrum haben vor 10 Jahren 
darüber geschimpft, dass die Leute nicht miteinander reden und/oder die 
wichtigen Informationen nicht durchdringen.

Ein Backlog ersetzt im Übrigen nicht das Pflichtenheft und auch nicht 
die Dokumentation des  Projekts.

von Udo S. (urschmitt)


Bewertung
3 lesenswert
nicht lesenswert
soso schrieb:
> vor allem von der Kommunikation.

Leute die vorher nicht miteinander reden (und auch zuhören) tun das auch 
nicht wirklich in verordneten Meetings.

Planungs /Änderungszyklen, priorisierte ToDo oder Taskliste, regelmäßige 
Meetings (bis hin zu täglichen kurzen Statusmeetings wenns gerade mal 
brennt) usw. usf gabs/gibts auch alles schon vor und ohne SCRUM und 
agile development.

Es gab nur keine so hippen Namen dafür.

: Bearbeitet durch User
von Hinweisgeber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte
> ich das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden.
>
> Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können - dann könnte man sich diesen modernen Unsinn sparen
> und jeder weiß, was realistisch zu tun ist.
> Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu
> managen....

Ein Scrum meeting sollte < 15 min dauern

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
Hinweisgeber schrieb:
> Ein Scrum meeting sollte < 15 min dauern

Das ist das daily. Es gibt diverse verschiedene Arten von Meetings.

von Name: (Gast)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur
> beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-)
>
> https://www.scaledagileframework.com/
>
> Grüsse,
> René

Wow!
"Epic Owners"
"Learn-Agile Mindset"
"Agile-Release-Train"

Ich werde Epic owner!

von Rente mit 76 (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Niemand hat euch gezwungen, einen solchen Beruf auszuüben.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Wow!
> "Epic Owners"
> "Learn-Agile Mindset"
> "Agile-Release-Train"
>
> Ich werde Epic owner!

Ja, es ist ein "pain". Ich verbringe mindestens 20% meiner Arbeitszeit 
mit diesem Mist. Soviele Meetings hatte ich meinem ganzen Leben nie.

von Nick M. (muellernick)


Bewertung
2 lesenswert
nicht lesenswert
Name: schrieb:
> Ich werde Epic owner!

Ist das gleiche wie bei AISLER 
(Beitrag "Ask me anything, Fertigung bei AISLER"). Lauter 
buzzwords, bunt und hauptsächlich Luft.

Wenn es Klärungsbedarf gibt, frag ich halt einen Kollegen und zwar 
zeitnah und nicht erst Freitags. Und wenn es was zu erklären gibt, dann 
erklär ich es ihm und nicht denen die nichts damit zu tun haben und 
nichts damit anfangen können.
Und wenn es Alle was angeht, dann genügt ein "Setzen wir uns zusammen".

Wenn das jetzt in einem festen Zeitraster besser sein soll, dann ist mir 
klar, warum die Montagsbesprechnungen hier so völlig sinnlos waren und 
ich mich durch häufiges gähnen und Aufforderung zur Kürze selbst 
rausgekick hab. War ja eh nichts für mich dabei. Mir geht's einfach am 
Arsch vortbei wie die Buchhaltung SAP bedienen soll oder Netzwerkkabel 
beim Kunden X unbedingt grau sein müssen.

Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen 
umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue 
und unverständliche Begriffe für die.

Kindergarten!

von Matthias Döpke (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Hahaha,
da bin ich ja froh, dass mein langjähriger Kollege und ich nicht die 
Einzigen sind, die sich über Sinn und Unsinn dieser 'modernen' 
Prozesstools amüsieren.

Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich 
gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich 
dann morgen mache.
Ich bete meine Story also runter (wobei ich mir ziemlich sicher bin, 
dass - wenn sie denn noch zuhören - die meisten überhaupt nichts mit der 
Nummer und der Kurzbezeichnung anfangen können) und mache dann die Augen 
wieder zu .... ;)
Scrum wird wie üblich von Unwissenden oben aufgezwungen, Scrum Master 
ist bei uns einer aus dem 'Entwicklerteam'.
Technisch inhaltlich soll nichts besprochen werden, nur der Fortschritt 
des Projekts und die grünen Häckchen für die Vorgesetzten sind wichtig.
Aktuelle, technische Probleme hinterher in P2P-Gespräch geklärt ... nein 
besprochen werden.

Ich sehe das wie einer meiner Vorredner - wenn sich die Firma so einen 
Blödsinn leisten kann ... dann soll sie das.
Die Konsequenz ist, dass ich nicht mehr mitdenke, nur noch stumpfsinning 
meine Punkte abarbeite und danach nach Hause gehe und mich mit letzter 
Kraft jeden Tag neu auf die Arbeit schleppe.

Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder 
zu zweit die komplette Steuergeräte-SW entwickelt (incl. 
Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das 
eine nicht ohne das andere laufen kann und kannte die ganze 
Funktionalität aus dem Kopf, weil das unser 'Kind' war.
Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das 
verlangt und niemand fühlt sich verantwortlich.
30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein 
AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit 
gemacht haben.

Und welche Pfosten finden diesen 'modernen' Weg gut :
Die, die nach zig Jahren C-Programmierung Zeiger nicht benutzen, weil 
sie die nie richtig verstanden haben und auch privat nicht eine Minute 
programmieren oder gar mal irgendeine Hardware-Entwicklung gemacht 
haben.
Aber sagen wir müssen sofort alle Kraftwerke und den privaten 
Autoverkehr abschaffen und all solchen Schwachsinn ohne den Kopf vorher 
einzuschalten.

Noch Fragen ???
Schöne neue Welt (Aldous Huxley) lässt grüßen ... weiter so  X(

von Name: (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Nick M. schrieb:
> Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen
> umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue
> und unverständliche Begriffe für die.
>
> Kindergarten!

Zustimmung in den meisten Punkten.

Außer in einem:
Ich mach den Affenzirkus in den Firmen jetzt seit 25 Jahren mit, und 
gemeckert über die Jungen Leute wurde schon immer gleich viel. Wer 
behauptet, in seiner Firma wäre das besser, lügt. Dazu war ich schon in 
zu vielen Firmen, um das noch glauben zu können ;-)

Wir waren damals halt "die no future Generation", und "aus denen wird eh 
nie was".  Lieblingsspruch: "Nimm die Hände aus den Hosentaschen, sonst 
wachsen sie fest".

Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am 
Handy rumwischen.

Geändert hat sich tatsächlich fast gar nichts. Fakt ist, dass sich Leute 
kurz nach oder in der Pubertät für Arbeit nur selten begeistern können.

von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
Name: schrieb:
> Geändert hat sich tatsächlich fast gar nichts. Fakt ist, dass sich Leute
> kurz nach oder in der Pubertät für Arbeit nur selten begeistern können.

gibt zu jeder Zeit sone und solche, ich hatte schon mit 12 einen Compi 
zusammengebaut, Schaltpulte mit noch 220V gebaut wusste wo man den 
Lötkolben anfasst und nach dem Studium und nach der Arbeit am PC daheim 
auf dem ST die Prüfprogramme weitergeschrieben.

Wer sein Hobby zum Beruf macht muss nie wieder arbeiten.

: Bearbeitet durch User
von Nick M. (muellernick)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am
> Handy rumwischen.

Ja und nein. Ich versteh dich schon. Aber es gibt Leute die man mal 
schwach anreden kann ohne dass sie in Tränen ausbrechen. Sondern kurz 
nachdenken, lächeln und dann drauf reagieren. Zurücklächeln und damit 
ist das dann erledigt. Und das kenn ich auch so aus meiner "Jugend".

von Hugo H. (hugohurtig1)


Bewertung
2 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Wer sein Hobby zum Beruf macht muss nie wieder arbeiten

Entschuldige bitte - aber den Spruch kann ich nicht mehr hören. Arbeit 
ist für mich Arbeit (O.K. ich tue gerne, wofür ich bezahlt werde) - aber 
Hobby ist für mich anders. Damit verdiene ich nicht meine Brötchen mit 
den entsprechenden Zwängen dahinter - da mache ich etwas rein aus 
Interesse / Spaß an der Freude. Das sind 2 Paar Schuhe.

O.K, wenn Du ein reicher Erbe bist und/oder kein Geld verdienen musst 
mag das anders aussehen.

Ich vergaß die Künstler - aber nur wenige können sich mit ihrer "Kunst" 
den Lebensunterhalt verdienen oder gar reich werden. Wenn die zu 
Lebzeiten in den "Geldstrudel" kommen machen die auch nur noch das das, 
was gefragt ist. Oder sie sind dann so berühmt, dass auch eine Wanne - 
von ihnen halb mit Fett gefüllt - als Kunst angesehen wird :-).

: Bearbeitet durch User
von Achim H. (anymouse)


Bewertung
3 lesenswert
nicht lesenswert
Matthias Döpke schrieb:
> Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich
> gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich
> dann morgen mache.

Du arbeitest also in mindestens drei (großen) Teams gleichzeitig:

> Ein Daily Scrum Meeting sollte < 15 min dauern

Oder Euer Scrummaster -- oder Ihr selbst -- brecht nicht rechtzeitig ab.

von Matthias Döpke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achim H. schrieb:
> Du arbeitest also in mindestens drei (großen) Teams gleichzeitig:

Es ist ein Team an 2,5 Standorten ....
Eines der Scrums dauert alleine 30min ....

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am
> Handy rumwischen.

Scrum hat mit der Jugend nichts zu tun. Das ist eine Management Idee und 
im Grundsatz von der Idee nicht mal schlecht.

Hat sich nicht der Scrum „Erfinder“ davon distanziert weil daraus nur 
ein Management Werkzeug wurde und die Grundidee komplett weg gebügelt 
wurde?

SAFe ist aber eine Idee von findigen Wirtschaftler wie man sie Scrum 
Zitrone noch mehr auspressen kann.

Scrum of Scrum ist Schwachsinn in Potenz.

: Bearbeitet durch User
Beitrag #6141568 wurde von einem Moderator gelöscht.
Beitrag #6141570 wurde von einem Moderator gelöscht.
von Tilo R. (joey5337) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Matthias Döpke schrieb:
> Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich
> gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich
> dann morgen mache.
> Ich bete meine Story also runter (wobei ich mir ziemlich sicher bin,
> dass - wenn sie denn noch zuhören - die meisten überhaupt nichts mit der
> Nummer und der Kurzbezeichnung anfangen können) und mache dann die Augen
> wieder zu .... ;)

Wenn es niemanden interessiert, warum redet ihr dann so lange?

"Ich arbeite an $TICKETBEZEICHNUNG. Ich denke damit heute fertig zu 
werden und kümmere mich dann um $TICKETBEZEICHNUNG2."
Dauert 30 Sekunden. Nächster.

Alternativ:
"Ich arbeite an $TICKETBEZEICHNUNG. Meine Arbeit wird unerwartet 
behindert durch XY."
XY kann z.B. unerwartete Komplexität sein. Oder eine unklare 
Spezifikation. Oder Abhängigkeit zu einem Fremdsystem, das ständig 
zusammenbricht. Oder dass du alle 5 Minuten Besuch von irgendjemandem 
bekommst. Oder dass dein Rechner zu wenig RAM für die Simulation hat.

Das zu sagen sollte jetzt auch nicht ewig dauern, sondern in 2 Minuten 
erledigt sein. Jetzt kennen alle das Problem und das Team kann 
entscheiden, was man macht: Es trotzdem irgendwie durchziehen, irgendwas 
anderes probieren, das Ticket zurück ins Backlog. Was auch immer.

Euer Scrum-Master hat auch die Aufgabe, Probleme zu lösen. Ich kenne 
z.B. ein Team, dessen Scrum-Master Öffnungszeiten durchgesetzt hat. Klar 
wusste auch ohne Scrum jeder, dass die ständigen Störungen Kacke sind. 
Aber es war halt ein Mimimi-Problem einzelner Entwickler, die sich nicht 
gegenüber anderen Abteilungen durchsetzen konnten.


Das Problem an Scrum ist das selbe wie in allen Meetings: Die 
Laberblafasel-Attitüde. Klar fühlt es sich gut an, eloquent 5 Minuten 
oder auch länger über seine aktuelle Arbeit und was man nicht alles 
tolles macht zu reden. Und je länger andere schon gelabert haben, umso 
mehr Zeit hat man, sich seinen Auftritt und was man noch alles erzählen 
will, zurechtzulegen.

Dass es nicht hilft seht ihr. Warum ändert ihr es nicht?

Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern! Legt halt in 
der nächsten Retrospektive fest, das jeder im Daily zuerst diesen einen 
formelhaften Satz von oben sagen muss. Und wenn er dann weiterredet ohne 
was zu sagen: unterbrecht ihn.


> Scrum wird wie üblich von Unwissenden oben aufgezwungen, Scrum Master
> ist bei uns einer aus dem 'Entwicklerteam'.
Das könnte ein Problem sein. Oder sogar 3.

> Technisch inhaltlich soll nichts besprochen werden, nur der Fortschritt
> des Projekts und die grünen Häckchen für die Vorgesetzten sind wichtig.

Grüne Häkchen für Vorgesetzte muss es im Sprint nicht geben. Die helfen 
nicht bei der Entwicklung. Wenn ein Vorgesetzter während des Sprints 
quengelt - schickt ihn zum Scrum-Master oder PO. Wofür gibt es diesen 
Proxy?
Klar kann der Scrum-Master auch einen Burndown-Chart malen und grüne 
Häkchen reporten. Das ist aber keine Aufgabe fürs Daily, das kann er 
ganz allein machen.

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb im Beitrag #6141570:
> Wie dunkel? :-)

Erst Du :-)

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
Hugo H. schrieb:
> René H. schrieb:
>> Wie dunkel? :-)
>
> Erst Du :-)

Rapid Prototyping. Das Team organisiert sich selbst. Jeder im Team ist 
in der Lage jeden Task zu "erfüllen". Tägliche Lieferungen (bzw. jedes 
commit/push) stellt sicher das der Code kompilierbar ist. Die QA kann 
jedes neu implementiertes Feature sofort testen (wenn es den eine QA 
gibt).

Faktum ist aber leider, dass man den Bockmist auf alles versucht 
abzuwälzen.  Selbst in ein Maintenance Team von 8 Produkten. Das jeder 
alles kann ist ebenfalls Bullshit in der heutigen Technologie Welt ist 
das nicht realistisch.

Die Daylies ziehen sich in der Regel unnötig in die Länge, weil der 
Scrummuster eine Pfeife ist und kein Plan hat. Die Sprint Planning sind 
dann noch schlimmer. Unnötiges Geschwafel.

: Bearbeitet durch User
von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
Hugo H. schrieb:
> Erst Du :-)

Damit meinte ich:

Hugo H. schrieb im Beitrag #6141568:
> René H. schrieb:
>> die Grundidee

Die möchte ich gerne erklärt haben :-)

Was "rapid prototyping" ist weiß ich - lebe ich (sofern es um 
Dialog-orientierte Entwiclungen geht).

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
^Scrummuster^Scrummaster

von Scrum is a Meme (Gast)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal
> den Rasen mähen muss.
>
> Fehlt mir da ein Gen?

Nein, dir fehlt überhaupt nichts, geht mir genau so.

Ich wünschte Scrum würde bei uns "abgeschafft" werden. Ich weiß gar 
nicht warum man sich täglich 15min hinstellen muss und über das redet, 
was sowieso klar ist.

Ich mein wir sitzen alle im selben Raum und quatschen den ganzen Tag 
über die kack Software. Okay, ich gebe zu der PL weiß es nicht, aber 
muss der alles wissen?

Er steht trotzdem da und hört sich alles an. lol. Der PL!!! Man sieht 
deutlich welche Prioritäten er scheinbar hat. Egal. Ich stehe so da und 
erzähle meist mein JIRA-Ticket so, dass es ja keine Nachfragen gibt oder 
mir noch Hilfe angeboten wird.

"Ich bearbeite gerade JIRA-Ticket ABC, es geht um XYZ, ich werde 
voraussichtlich Freitag fertig und schnappe mir dann JIRA-Ticket DEF."

Schön unter dem Radar bleiben. Wie zu DDR-Zeiten Leute. ;-)

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
Hugo H. schrieb:
> Entwiclungen

Ich spendiere noch ein "k"

von BonusGekoppeltAnGewinn (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
Matthias Döpke schrieb:
> Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder
> zu zweit die komplette Steuergeräte-SW entwickelt (incl.
> Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das
> eine nicht ohne das andere laufen kann und kannte die ganze
> Funktionalität aus dem Kopf, weil das unser 'Kind' war.
> Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das
> verlangt und niemand fühlt sich verantwortlich.
> 30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein
> AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit
> gemacht haben.

Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder 
gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit 
so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder 
ohne Scrum.

PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger 
gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten 
und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer 
sich und laestern dann in Online Foren.

von Hugo H. (hugohurtig1)


Bewertung
2 lesenswert
nicht lesenswert
BonusGekoppeltAnGewinn schrieb:
> Nur armselige Wuerstchen

machen auf dicke Hose und pupsen nur heisse Luft :-)

Beitrag #6141669 wurde vom Autor gelöscht.
von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
BonusGekoppeltAnGewinn schrieb:
> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
> und Wissen weiterzugeben.

Wenn sie im JIRA einen Task oder Story erfassen und mir Assignen dann 
mache ich das sehr gerne.

Merkst Du was?

von Platzwart (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
BonusGekoppeltAnGewinn schrieb:
> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
> und Wissen weiterzugeben.
Nein feuert die Person die solche Honks eingestellt hat.

> Nur armselige Wuerstchen behalten alles fuer
> sich und laestern dann in Online Foren.
Das sind Grundlagen, man keine Zeit denen das Laufen beizubringen, das 
lernt man in der Ausbildung/Studium. Wer solche Pfeifen einstellt gehört 
sofort gefeuert.

von Jan H. (j_hansen)


Bewertung
4 lesenswert
nicht lesenswert
Also ich finde Scrum super. Bin selbst Certified Scrum Master und finde 
die Methodik toll - sofern sie zum Team und Projekt passt.

In der Realität konnte ich aber leider noch kein einziges echtes 
Scrum-Projekt beobachten. Denn die Methodik ist ja recht streng 
vorgegeben. Stattdessen werden meist die dysfunktionalen Prozesse 
umetikettiert:
* Kein Plan, ständige Änderungen... => "Agil"
* Schwachsinnige Meetings => "Daily"
Etc.


Scrum is a Meme schrieb:
> Er steht trotzdem da und hört sich alles an. lol. Der PL!!! Man sieht
> deutlich welche Prioritäten er scheinbar hat.

Typisch - bei Scrum gibt's keinen Projektleiter. Ist also nicht Scrum 
sondern eine Fassade um die eigene Unfähigkeit zu verschleiern.

Mein Teamkollege rührt beim Kunden auch immer die 
Selbstbeweihräucherungstrommel wie agil wir doch mit Scrum arbeiten. Die 
Kunden rollen heutzutage nur noch mit den Augen (wird wohl Zeit für eine 
neue Sau), aber amüsieren sich dann wenn ich dabei mitmache.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
René H. schrieb:
> BonusGekoppeltAnGewinn schrieb:
>> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
>> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
>> und Wissen weiterzugeben.
>
> Wenn sie im JIRA einen Task oder Story erfassen und mir Assignen dann
> mache ich das sehr gerne.
>
> Merkst Du was?

Natürlich brauche ich dann noch eine Nummer für die Zeiterfassung. Ich 
kann dann den Zeitaufwand des Kollegen Weiterbildung im Jira Schätzen 
(schätze das mal ;-)) und im nächsten Sprint einplanen. Und genau so 
läuft das, nicht anders. Für Team Kollegialität lässt Scrum keinen Raum. 
No Way!

Beitrag #6141724 wurde von einem Moderator gelöscht.
von Unfassbar (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Jira ist der Vorhof der Hölle!

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Unfassbar schrieb:
> Jira ist der Vorhof der Hölle!

Treffender lässt sich das wohl nicht ausdrücken.

+1

von Jan H. (j_hansen)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Natürlich brauche ich dann noch eine Nummer für die Zeiterfassung. Ich
> kann dann den Zeitaufwand des Kollegen Weiterbildung im Jira Schätzen
> (schätze das mal ;-)) und im nächsten Sprint einplanen. Und genau so
> läuft das, nicht anders. Für Team Kollegialität lässt Scrum keinen Raum.
> No Way!

"Du sollst 100% deiner Zeit auf eingeplante Tickets verbuchen" hört sich 
nicht nach Scrum sondern nach Erbsenzählermethodik an.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Jan H. schrieb:
> Erbsenzählermethodik

Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks 
nicht in der "Estimated Time" abhandle werden Fragen gestellt.

: Bearbeitet durch User
von Joachim B. (jar)


Bewertung
1 lesenswert
nicht lesenswert
Hugo H. schrieb:
> aber den Spruch kann ich nicht mehr hören

tut mir leid

Hugo H. schrieb:
> (O.K. ich tue gerne, wofür ich bezahlt werde)

ich habe ca. 99% meines Arbeitsleben gerne das gearbeitet was mir Spass 
macht, es nie als Bürde gesehen, nie beim Ende Klingeln das Werkzeug in 
die Ecke geworfen, Zeit Überstunden extra bezahlt, Sonntag, war mir 
egal. Das Geld musste nur etwas mehr als reichen, solange ich damit gut 
lebte war es für mich OK. Nachteil reich bin ich nicht geworden, aber 
macht reich glücklich?

Hugo H. schrieb:
> O.K, wenn Du ein reicher Erbe bist und/oder kein Geld verdienen musst
> mag das anders aussehen.

nö, musste immer arbeiten! auch als Student.

: Bearbeitet durch User
von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Hugo H. schrieb:
> Hugo H. schrieb:
>> Erst Du :-)
>
> Damit meinte ich:
>
> Hugo H. schrieb:
>> René H. schrieb:
>>> die Grundidee
>
> Die möchte ich gerne erklärt haben :-)
>
> Was "rapid prototyping" ist weiß ich - lebe ich (sofern es um
> Dialog-orientierte Entwiclungen geht).

Jetzt Du! :-)

von Bewerber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Wenn ich meine Tasks nicht in der "Estimated Time" abhandle werden
> Fragen gestellt.

Deshalb sollte man auch immer kräftig over-estimaten. Auch so eine 
Bewältigungsstrategie bei Diagnose Scrum

von Jan H. (j_hansen)


Bewertung
2 lesenswert
nicht lesenswert
René H. schrieb:
> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
> nicht in der "Estimated Time" abhandle werden Fragen gestellt.

Scrum verlangt doch gar keine "Estimated Time". Empfohlen wurde mir 
beispielsweise eine Kategorisierung nach T-Shirt-Größen. Und es ist auch 
nicht nötig seinen Sprint mit Tasks vollzuknallen.

Aber ich kenne ja die Realität auch bei uns. Der schlaue Projektleiter, 
den es bei Scrum ja gar nicht geben sollte, lässt sich die Aufwände auf 
Viertelstunden genau schätzen, drückt noch ein bisschen weil die faulen 
Programmierer ja sicher gepuffert haben und knallt den Sprint dann mit 
der theoretischen Iststundenanzahl voll.

Scrum steht drauf obwohl es ziemlich das Gegenteil der Philosophie ist.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
blöde meetings haben mich erst jetzt erwischt, da sitzt man und gibt 
seine Kenntnisse zum Besten und keiner nimmt diese auf oder arbeitet 
danach, es wird ALLES anders gemacht was man auf Grund seiner Erfahrung 
vorschlägt und weswegen man eingeladen wurde und es ist egal. Diese 
"meetings" hätte ich nicht mehr gebraucht.

von Qwertz (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Das Geld musste nur etwas mehr als reichen, solange ich damit gut lebte
> war es für mich OK. Nachteil reich bin ich nicht geworden, aber macht
> reich glücklich?

Nein, alleine nicht, aber man muss sich aufgrund seiner Passion trotzdem 
nicht ausbeuten lassen. Ich bin für gutes Geld für gute Arbeit (die auch 
Spaß machen darf), ich finde, das ist kein Widerspruch.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Hugo H. schrieb:
>> (O.K. ich tue gerne, wofür ich bezahlt werde)

Unrecht hat Hugo aber nicht. Ich programmiere seit ich 12 bin. Es ist 
eine Leidenschaft und deshalb mache ich das auch heute noch gerne (fragt 
nicht wie lange das her ist :-)).
Es sind die Umstände die einem das madig machen, nicht nicht die Sache.

Darauf war ich ehrlich gesagt nicht vorbereitet. Jetzt ist es halt so. 
Ich zieh das noch ein paar Jahre durch bis ich es mir leisten kann in 
Rente zu gehen (oder ausgemustert werde, was wahrscheinlicher ist).

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Qwertz schrieb:
> Ich bin für gutes Geld für gute Arbeit (die auch
> Spaß machen darf), ich finde, das ist kein Widerspruch.

dafür, ich fand das Geld das ich bekam immer gut (OK heute denke ich 
hätte besser sein können).

René H. schrieb:
> Es sind die Umstände die einem das madig machen, nicht nicht die Sache.

stimmt, vor allem in meinen 1% Jobs, da wollte und war ich halt schnell 
wieder raus, alles in Allem keine schlechte Bilanz, ich denke Andere 
mussten ab und an viel länger miese Jobs machen in Ihrem Arbeitsleben 
als nur 1%.

von MaWin (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jan H. schrieb:
> In der Realität konnte ich aber leider noch kein einziges echtes
> Scrum-Projekt beobachten. Denn die Methodik ist ja recht streng
> vorgegeben. Stattdessen werden meist die dysfunktionalen Prozesse
> umetikettiert

Oje, das Geschwafel eines Scrum-Fanboys.

So wie das Geschwafel eines Sozialismus-Funktionärs.

Merke: ein Verfahren, was nicht zur realen Welt passt, hat in der realen 
Welt nichts verloren. Das gehört höchstens in Märchenbücher.

von Dennis (Gast)


Bewertung
0 lesenswert
nicht lesenswert
René H. schrieb:
> Jan H. schrieb:
> Erbsenzählermethodik
>
> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
> nicht in der "Estimated Time" abhandle werden Fragen gestellt.

Estimated time einfach höher ansetzen.

von Ben S. (bensch123)


Bewertung
0 lesenswert
nicht lesenswert
Und das dieses Denglisch den ganzen Tag....

von Jan H. (j_hansen)


Bewertung
1 lesenswert
nicht lesenswert
MaWin schrieb:
> Oje, das Geschwafel eines Scrum-Fanboys.
>
> So wie das Geschwafel eines Sozialismus-Funktionärs.
>
> Merke: ein Verfahren, was nicht zur realen Welt passt, hat in der realen
> Welt nichts verloren. Das gehört höchstens in Märchenbücher.

Seine Welt in einfache Schubladen zu klassifizieren ist menschlich, aber 
taugt selten als absolute Wahrheit.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Dennis schrieb:
> René H. schrieb:
>> Jan H. schrieb:
>> Erbsenzählermethodik
>>
>> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
>> nicht in der "Estimated Time" abhandle werden Fragen gestellt.
>
> Estimated time einfach höher ansetzen.

Tja, das wird dann durch das Team angezweifelt: "Low Performer".

Hmmmm....

: Bearbeitet durch User
von Bewerber (Gast)


Bewertung
2 lesenswert
nicht lesenswert
René H. schrieb:
> Tja, das wird dann durch das Team angezweifelt: "Low Performer".
>
> Hmmmm....

Muss schon ein Scheiß team sein... Von meinem Team kommt höchstens dann 
beim Scrum planning Einspruch, wenn ich mich zu übernehmen drohe.

Auf einen gestressten Kollegen der das Verhältnis von eingeplanten zu 
erledigten User Stories ruiniert hat nämlich keiner Bock.

Das der Scrum master niemals selbst einschätzen kann wie groß ein 
einzelner Task ist ist jedem klar.

Daher immer niedrig ansetzen, bisschen Fachchinesisch hilft um die 
Aufgaben jede für sich wie eine praktisch unmögliche Aufgabe wirken zu 
lassen. Dann während des Sprints noch extra Aufgaben einbuchen, das 
macht Eindruck und man kriegt die Dinge die wirklich getan werden müssen 
am product owner vorbeigeschmuggelt.

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
2 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch
> einfach mal am Anfang einer Entwicklung einen Anforderungskatalog
> erstellen können - dann könnte man sich diesen modernen Unsinn sparen
> und jeder weiß, was realistisch zu tun ist.

Seit irgendjemand vor gefühlt 15 Jahren beschlossen hat, dass SCRUM 
etwas gutes ist und alle Probleme löst, hechelt dem jeder hinterher.

Ich kenne das von meiner Tätigkeit aus dem Automotive-Sektor, dem ich 
vor Jahren schon den Rücken gekehrt habe.

Entwicklung in Software gleicht heute einem großen Gruppenbasteln, wobei 
Gruppe als heilig angesehen wird, da Team das große Ziel ist.

Gleichzeit wird das Teamdenken nachhaltig gestört. Dies ist ein 
klassisches Beispiel: Solches Denken ist die weit verbreitete Reaktion 
der SCRUM-Politik:

Bewerber schrieb:
> Daher immer niedrig ansetzen, bisschen Fachchinesisch hilft um die
> Aufgaben jede für sich wie eine praktisch unmögliche Aufgabe wirken zu
> lassen. Dann während des Sprints noch extra Aufgaben einbuchen, das
> macht Eindruck und man kriegt die Dinge die wirklich getan werden müssen
> am product owner vorbeigeschmuggelt.

Weiteres Tun ist das Zurückhalten von potenziellen Gefahren und 
Problemen, um noch etwas in der Hinterhand zu haben, wenn Verzug droht. 
Dann zieht man einfach das Problem und lässt den PO grübeln und neu 
disponieren. Damit sind alle Sprinttermine wieder offen.

Damit geht das Eigentliche jeder guten Teamleistung in die Binsen.

: Bearbeitet durch User
von Matthias Döpke (Gast)


Bewertung
0 lesenswert
nicht lesenswert
BonusGekoppeltAnGewinn schrieb:
> Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder
> gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit
> so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder
> ohne Scrum.
>
> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger
> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten
> und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer
> sich und laestern dann in Online Foren.

Vielen Dank für die lieben Worte ... ein netter Zeitgenosse :)

Ich nehme gerne Dinge an die Innovation und echte Vorteile bringen ... 
ich programmiere heute auch nicht mehr in Assembler ;)

Die Frischlinge sind leider keine, sondern teilweise (fast) mein Alter. 
Sie haben aber weder Ahnung von Software, noch Hardware ... meinen aber 
Prozesse und moderne Tools lösen alle Probleme von selbst.
Sie implementieren Code, ich teste den und gebe den wegen Fehlern 
zurück. Dann kommen solche Leute und möchten von mir möglich exakt 
wissen, wo sie was ändern müssen.
Hat nichts mit dem Thema zu tun ... aber komischerweise sind genau 
solche Pfeiffen die, die auf solchen modernen, unbrauchbaren Mist stehen 
und ganz toll finden (z.B. modellbasierte Entwicklung - ohne zu 
verstehen was die Blöcke im Hintergrund überhaupt genau tun).
Das sind auch die Mitarbeiter die als erste bei jeder Gelegenheit der 
Arbeit fernbleiben ...
Ich helfe gerne und gebe mein Wissen weiter, aber es gibt Menschen die 
sind einfach unbelehrbar ... ;)

von SchonWiederGast (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Matthias Döpke schrieb:
> Noch Fragen ???

Eher nicht. Aber ich verstehe Dich vollkommen. Mein Beileid. AG Wechsel?

von SchonWiederGast (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Name: schrieb:
> Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am
> Handy rumwischen.

Nette Geschichte: letzten Winter laufe ich hier durch die Stadt. Kaum 
Fußgänger unterwegs. Ich sehe so 40m vor mir einen Schulbub 
(Grundschule) auf mich zukommen. Gehweg war an der Stelle so 3-3,5m 
breit. Mitten auf dem Weg stand ein temporäres Strassenschild (die unten 
mit diesen Platten beschwert sind). Der Bub geht auf mich zu, guckt 
dabei nur auf sein Handy. Ich schaue nach unten, nach einigen Sekunden 
wieder nach vorne. Er sitzt hinter dem Schild auf dem Hosenboden, 
rappelt sich langsam auf und greift mit der rechten Hand an die Stirn. 
Ich musste acht geben, dass ich nicht losgelacht habe. Meine Eltern 
hätten gesagt: "Pass uff wo 'de hi'latschst!"

von Michael Gugelhupf (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern!

Typischer Bullshit.

In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson 
übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner 
Karriere arbeitet und sich wichtig macht. So wild herumlaufende 
Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab.

Soll es in Scrum nicht geben? Ja, FML.
Ist nicht die Schuld von Scrum? Ja, FML.

Eine Methode, die nicht robust genug ist so etwas auszuhalten, und Scrum 
hält es nicht aus, ist nun mal scheiße.

> Grüne Häkchen für Vorgesetzte muss es im Sprint nicht geben. Die helfen
> nicht bei der Entwicklung.

Doch, die muss es geben, wenn der Chef sagt es muss sie geben.

> Wenn ein Vorgesetzter während des Sprints
> quengelt - schickt ihn zum Scrum-Master oder PO.

Ha, ha, ha. Der Begriff "abhängiger Beschäftigter" sagt dir was?

> Wofür gibt es diesen
> Proxy?

Damit zwei Leute mehr schönen Ehrentitel haben und von einer Karriere 
träumen können.

> Klar kann der Scrum-Master auch einen Burndown-Chart malen und grüne
> Häkchen reporten. Das ist aber keine Aufgabe fürs Daily, das kann er
> ganz allein machen.

Dann müsste er ja mal selber arbeiten und denken. Ist doch viel 
einfacher dass das Team "mal schnell" unter Aufsicht des Scrummasters 
malt und Häckchen macht. Das spart dem Scrummaster noch dazu den Aufwand 
die Ergebnisse separat im Team zu kommunizieren. War ja jeder dabei und 
"involved".

von Sys (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Unglaublich schrieb:
> endwiggler schrieb:
>> Dann sind die Scrummaster zufrieden, dass ich selbst einen
>> längerfristigen Plan verfolge muss der nicht wissen.
>
> Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal
> häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in
> der Firma am Kicker fachsimpeln.

Genau, Abends am Kicker. Warum nicht gleich auf die Familie scheißen und 
direkt neben, oder besser, in die Firma einziehen.

von SysIngMue (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sys schrieb:


Das sollte SysIngMue heißen.

Beitrag #6142110 wurde von einem Moderator gelöscht.
von vn nn (Gast)


Bewertung
2 lesenswert
nicht lesenswert
René H. schrieb:
> Jan H. schrieb:
>> Erbsenzählermethodik
>
> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks
> nicht in der "Estimated Time" abhandle werden Fragen gestellt.

Und? Dann beantwortest du die Frage eben. Oder fehlen dir die Cojones, 
um zu sagen "ich hab mein Arbeitspensum leider nicht fertig gekriegt 
wegen XYZ"?
Genau dieses Feedback ist der Sinn der Retrospektive, um mit der Zeit 
die Abschätzungen zu verbessern.
Und stell dir vor, das hat auch nix mit Scrum zu tun, derartiges 
Feedback macht auch ohne Scrum Sinn. Woher soll der Vorgesetzte oder der 
Rest des Teams denn sonst wissen, dass es irgendwo hakt?

René H. schrieb:
> Tja, das wird dann durch das Team angezweifelt: "Low Performer".

Tja, wenn du dich durch sowas fertig machen lässt... Wahrscheinlich 
verschweigst du auch immer schön, wenn du hinter dem Zeitplan bist, und 
kompensierst das dann durch kräftig Überstunden, denn der Projektleiter 
darf ja auf keinen Fall mitkriegen dass der Zeitplan zu eng war? Sehr 
gut, denn dann wird er ihn beim nächsten mal gleich noch enger 
gestalten, denn es hat ja funktioniert.

Michael Gugelhupf schrieb:
> Tilo R. schrieb:
>> Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern!
>
> Typischer Bullshit.
>
> In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson
> übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner
> Karriere arbeitet und sich wichtig macht. So wild herumlaufende
> Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab.
>
> Soll es in Scrum nicht geben? Ja, FML.
> Ist nicht die Schuld von Scrum? Ja, FML.

"Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, 
deswegen ist Scrum kacke!!1elf"

Sounds legit.

von Name: (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
René H. schrieb:
> Joachim B. schrieb:
>> Hugo H. schrieb:
>>> (O.K. ich tue gerne, wofür ich bezahlt werde)
>
> Unrecht hat Hugo aber nicht. Ich programmiere seit ich 12 bin. Es ist
> eine Leidenschaft und deshalb mache ich das auch heute noch gerne (fragt
> nicht wie lange das her ist :-)).
> Es sind die Umstände die einem das madig machen, nicht nicht die Sache.
>
> Darauf war ich ehrlich gesagt nicht vorbereitet. Jetzt ist es halt so.
> Ich zieh das noch ein paar Jahre durch bis ich es mir leisten kann in
> Rente zu gehen (oder ausgemustert werde, was wahrscheinlicher ist).

Entwickler die Entwicklen mit Basteln verwechseln ist die Spezies, die 
in Firmen den größten Schaden anrichten. Das sind zwei völlig 
verschiedene Dinge.

Da kommt meist nichts dabei raus.

Das sind dann die "tollen" "Programme" für die es keine Doku gibt, 
keinen Projektplan, keine Tests und die massig Bugs enthalten. Weil 
"Programmieren ja soviel Spass macht", lässt man den "lästigen Beikram" 
weg oder die Kollegen machen. Dass Softwareentwicklung mit Programmieren 
wenig zu tun hat, wissen solche Bastler oft nicht.

Bin Hardwerker, aber auch hier gibts diese Spezies.
Auch ich bastle in der Freizeit an Elektronik rum. Die Tätigkeit hat mit 
Hardwareentwickeln nur wenig gemeinsam.
Wenn doch: Herzliches Beileid für die Kollegen :-(

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
vn nn schrieb:
> Genau dieses Feedback ist der Sinn der Retrospektive, um mit der Zeit
> die Abschätzungen zu verbessern.

Nein, der Sinn ist, dass man die Leistung jeder Person genau 
kontrollieren, bewerten und bemaßen kann, jederzeit und möglichst fein 
granuliert.
So wie man das am Fliessband kann.
Und genau das will der BWLer, Chef und Controller.

Genau deshalb ist die Chefetage ja auch so geil auf das SCRUM Zeugs, 
zusätzlich ist es noch ein Marketing Argument.

Meine Devise: Wenn man ständig kurze Sprints macht und dann wieder prüft 
wie weit man gekommen ist, dann ist man deutlich langsamer und schneller 
erschöpft, als wenn man kontinuerlich langsamer joggt.
Oder hast du schon mal gesehen, daß jemand mit kurzen Sprints einen 
Marathon gewonnen hat?

Und wenn ich unsere SCRUm Teams hier sehe (nein, ich bin zum Glück in 
keinem) dann sind sie weder schneller noch besser in ihrer Arbeit, aber 
unzufriedener.

: Bearbeitet durch User
von Ben S. (bensch123)


Bewertung
-2 lesenswert
nicht lesenswert
Scrum ist der Vorhof vom Vorhof (Jira) der Hölle.

von Michael Gugelhupf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
vn nn schrieb:
> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
> deswegen ist Scrum kacke!!1elf"

Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht 
100% idealen Umgebung sofort zusammenbricht.

> Sounds legit.

Wie alt bist du? 12?

von hbl (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Scrum wurde von China oder den USA erfunden um uns
endgültig zu ruinieren. Mein Arbeitgeber hat es auch
eingeführt, seitdem kommt nixhts mehr raus .....

von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Name: schrieb:
> Das sind dann die "tollen" "Programme" für die es keine Doku gibt,
> keinen Projektplan, keine Tests

Klingt wie die allseits bei Kunden und Chefs beliebten schnell 
erstellten Prototypen.

Es kann gar nicht schnell genug gehen.

Und meistens bliebt es dann beim Provisorium, denn für alles andere ist 
ja kein Geld da, läuft a, irgendwie.

Es ist nicht der basteldnde Entwickler, der so geil darauf ist.


Und gerdae Scrum manifestiert diese (Fehl-)Entwicklung: im ersten Sprint 
den Prototypen und dann kontinuierlich 'verbessern'.

von Spieler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Stichwort "Agiles Theater"!

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
Spieler schrieb:
> Stichwort "Agiles Theater"!

Oft genug agiles Drama

SCNR

von Jan H. (j_hansen)


Bewertung
1 lesenswert
nicht lesenswert
Michael Gugelhupf schrieb:
> Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht
> 100% idealen Umgebung sofort zusammenbricht.

Nö.

MaWin schrieb:
> Und gerdae Scrum manifestiert diese (Fehl-)Entwicklung: im ersten Sprint
> den Prototypen und dann kontinuierlich 'verbessern'.

Das hat doch nichts mit Scrum zu tun. Völlig unabhängig von der Methodik 
kann ich mich dafür entscheiden einen Prototypen wegzuwerfen oder nicht.

von hbl (Gast)


Bewertung
2 lesenswert
nicht lesenswert
MaWin schrieb:
> Und meistens bliebt es dann beim Provisorium, denn für alles andere ist
> ja kein Geld da, läuft a, irgendwie.

Bei den Scrumprojekten werden dann solange die Anforderungen runter-
geschraubt bis ein "minimal verkaufsfähiges Produkt" entsteht.
Hab ich alles schon erlebt.

von Udo S. (urschmitt)


Bewertung
1 lesenswert
nicht lesenswert
hbl schrieb:
> "minimal verkaufsfähiges Produkt"

Nennt sich "minimum viable product"

Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so 
einem "minimal viable system" herum, das der Nachfolger eines von 4 
Personen (incl. mir) entwickelten Produktes werden soll.
Wir hatten damals 3 Monate bis zur Installation beim ersten Kunden.

von Unglaublich (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Herrlich, dass auch viele andere so denken, wie ich :)

von hbl (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Udo S. schrieb:
> Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so
> einem "minimal viable system" herum, das der Nachfolger eines von 4

Ich kenne das !

Da sollte etwas ersetzt werden, im Endeffekt konnte das neue
nicht einen Bruchteil des Altsystems. Damit fahren die Burschen
dann auch noch zu einem Keykunden, der hat sie zum Glück raus-
geschmissen.

Aber immerhin ist das ganze mit agilen Methoden entwickelt.

Bei meinem Arbeitgeber läuft das nur noch so. Nichts kommt mehr
raus.....

von ping (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Udo S. schrieb:
> hbl schrieb:
>> "minimal verkaufsfähiges Produkt"
>
> Nennt sich "minimum viable product"

Nein, minimum marketable product. Minimum viable product ist das 
mindeste was man dem Kunden für eine erst evaluation in die hand drücken 
kann um festzustellen ob es in die richtige Richtung geht.

von Michael B. (laberkopp)


Bewertung
3 lesenswert
nicht lesenswert
Udo S. schrieb:
> Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so
> einem "minimal viable system" herum, das der Nachfolger eines von 4
> Personen (incl. mir) entwickelten Produktes werden soll.
> Wir hatten damals 3 Monate bis zur Installation beim ersten Kunden.

Kenn ich...

Seit mehr als 10 Jahren versucht ein 10 mal grösseres Team mit Scrum ein 
altes Produkt durch einen Nachfolger zu ersetzen (der zu Beginn zwar mal 
besser, vor allem schneller sein sollte, aber inzwischen wurden alle 
Anforderungen gestrichen, man ist froh wenn er dasselbe kann und nicht 
langsamer läuft), der damals (vor 2000) in 2 Jahren von 2 Leuten ohne 
Scrum realisiert wurde und sich seit dem gut verkauft.

: Bearbeitet durch User
von soso (Gast)


Bewertung
-8 lesenswert
nicht lesenswert
Michael B. schrieb:
> aber inzwischen wurden alle
> Anforderungen gestrichen, man ist froh wenn er dasselbe kann und nicht
> langsamer läuft), der damals (vor 2000) in 2 Jahren von 2 Leuten ohne
> Scrum realisiert wurde und sich seit dem gut verkauft.

Ich hab geschafft und du bist nix Mentalität. Immer die gleiche Leier.
Echt amüsant die Diskussion zu verfolgen, wobei etliche Klischees 
erfüllt werden.

Jungs, setzen 6;-9

von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
soso schrieb:
> Ich hab geschafft und du bist nix Mentalität.

Und ?

So ist die Welt.

Einige können es, und Andere können eben nix.

Deine Mentalität ist:

"Wenn man es nur hart genug anstrengt,
gibt es Nichts, was man nicht erreichen könnte ?

Bullshit, passend zum Bingo.

von Matthias Döpke (Gast)


Bewertung
1 lesenswert
nicht lesenswert
soso schrieb:
> Ich hab geschafft und du bist nix Mentalität.

Es gibt überall bessere und schlechtere Leute.
Sicherlich auch bessere als man selbst ....

Aber wenn gerade Leute die noch nicht einmal herkömmlich vernünftig 
arbeiten können, meinen mit neuen Techniken und Tools könne man fehlende 
Kenntnisse (manchmal sogar Basics) und Fähigkeiten wettmachen, irren sie 
gewaltig.

Wenn man Scrum wenigstens sinnvoll anwenden würde, aber damit nur Zeit 
totzuschlagen und Motivation von Mitarbeitern zusätzlich zu rauben, 
macht keinen Sinn.
Oft sind es halt nicht die Leute die gut führen und vernüftig und 
zielstrebig arbeiten die so etwas einführen oder/und leiten, sondern 
genau die anderen.

Darum ging es in diesem Blog ... und offenbar stimmen die meisten der 
Poster in der Meinung überein - was natürlich nicht repräsentativ ist ;)

von Platzwart (Gast)


Bewertung
2 lesenswert
nicht lesenswert
hbl schrieb:
> endgültig zu ruinieren. Mein Arbeitgeber hat es auch
> eingeführt, seitdem kommt nixhts mehr raus .....

Scrum-Guru:"Ja dann macht ihr es nicht richtig!!! Ich kenn mich aus!"

Ist das selbe Geschwätz wie beim "Kein Wahrer Schotte":
https://de.wikipedia.org/wiki/Kein_wahrer_Schotte

von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
Platzwart schrieb:
> Ist das selbe Geschwätz wie beim "Kein Wahrer Schotte":
> https://de.wikipedia.org/wiki/Kein_wahrer_Schotte

Der Hinweis auf Religionen in dem Wikipedia Artikel passt gut. Ich 
glaube SCRUM ist so ein bischen was wie eine Religion für manche.

Wie gesagt, man kann so arbeiten, aber meins ist es nicht und was ich 
gesehen habe wird es oft für mehr Überwachung und zur Beurteilung von 
Personen eingesetzt und die Produkte werden dadurch nicht besser.
Die Motivation ist bei vielen eher schlechter, nicht bei allen.

von Hugo H. (hugohurtig1)


Bewertung
0 lesenswert
nicht lesenswert
Name: schrieb:
> Entwickler die Entwicklen mit Basteln verwechseln ist die Spezies, die
> in Firmen den größten Schaden anrichten.

Du verwechselst das mit "Dummlaberern" - davon gibt es mehr als genug. 
Ich zumindest habe nicht mit Entwicklern zu tun, die das Entwickeln mit 
Basteln verwechseln.

von Tilo R. (joey5337) Benutzerseite


Bewertung
4 lesenswert
nicht lesenswert
Michael Gugelhupf schrieb:
> vn nn schrieb:
>> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
>> deswegen ist Scrum kacke!!1elf"
>
> Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht
> 100% idealen Umgebung sofort zusammenbricht.

Wasserfall und V-Modell sind auch kacke, weil die nicht robust sind und 
in einer nicht 100% idealen Umgebung sofort zusammenbrechen.
Oder was macht man da, wenn zu einem späteren Zeitpunkt noch 
Requirements dazukommen?


Der ganze Thread ist ein Lamentieren, wie furchtbar doch alles ist und 
dass früher alles besser war. Stimmt ja auch :-)

Die Dilbert-Comics beschreiben genau das selbe Bullshit-Bingo und kommen 
aus einer Zeit, als noch nicht die ganze Branche mit Scrum und agile 
durchseucht war. Also erzählt mir nicht, dass die Probleme 
ausschließlich an Scrum liegen.

Auch früher schon gab es immer wieder Hypes und neue Konzepte, die in 
der Theorie toll waren, halbgar über ein bestehendes Unternehmen 
gestülpt aber nicht richtig funktioniert haben.

: Bearbeitet durch User
von Hugo H. (hugohurtig1)


Bewertung
1 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Wasserfall und V-Modell sind auch kacke, weil die nicht robust sind und
> in einer nicht 100% idealen Umgebung sofort zusammenbrechen.
> Oder was macht man da, wenn zu einem späteren Zeitpunkt noch
> Requirements dazukommen?

Darüber reden und entsprechenden Zusatzaufwand abstimmen. Ist das bei 
Srcum anders?

Tilo R. schrieb:
> Also erzählt mir nicht, dass die Probleme
> ausschließlich an Scrum liegen.

Nein - die werden dadurch aber auch nicht weniger - eher mehr. Wenn ich 
nicht von Anfang eine genaue Vorstellung davon habe, wie "mein Haus" 
aussehen soll - wie will ich mich dann iterativ nähern ohne deutlich 
mehr (gegenüber welcher Schätzung? Einem pauschalen Maximalbetrag?) zu 
investieren und mein Ziel zu erreichen? Ich habe nichts gegen Scrum - 
außer dass es instrumentalisiert und bürokratisiert wird (offiziell 
natürlich anders - dynamisch - dargestellt). Wie geschrieben lebe ich 
"rapid prototyping" (bei Dialog-orientierten Entwicklungen) - das ist 
nichts wesentlich anderes - nur ohne Bürokratie.

Tilo R. schrieb:
> Auch früher schon gab es immer wieder Hypes und neue Konzepte, die in
> der Theorie toll waren, halbgar über ein bestehendes Unternehmen
> gestülpt aber nicht richtig funktioniert haben.

Ja - die sind auch alle eines stillen Todes gestorben :-). Scrum - ruhe 
in Frieden :-)

: Bearbeitet durch User
von Dick Boutsos (Gast)


Bewertung
4 lesenswert
nicht lesenswert
Ich war mal kurz in einer kleine Firma, da gab es mehr 
Projektentwickler/leiter, Scrum-Master, Product-Owner, 
Schwaller-Priest,...  als reine Entwickler. Drei Entwickler, ein Student 
der seine Abschlussarbeit dort machte, ein Azubi und eine Teilzeitfrau 
die ich nie gesehen habe, die hat glaube ich Design oder sowas gemacht, 
GUIs aufgemöbelt, Icons gemalt.

Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des 
selben products. Der Eine von denen (der war zertifizierter Scrotum 
Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper 
gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in 
dem Laden installiert hat.

Ich war dort nicht mal ein Monat. Einer dieser Schwätzer ist ja schon 
schlimm aber wenn die du die im Rudel den ganzen Tag um dich rum hast, 
da drehste durch. Das ist wie im Kindergarten, malen nach Zahlen, 
Software entwickeln mit Scrum.

Sprint, daily, product owner, user story, backoffice,... immer wenn ich 
diese Begriffe höre zucke ich sofort zusammen und muss an diese Firma 
denken.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
1 lesenswert
nicht lesenswert
Dick Boutsos schrieb:
> Sprint, daily, product owner, user story, backoffice,... immer wenn ich
> diese Begriffe höre zucke ich sofort zusammen und muss an diese Firma
> denken.

Klingt traumatisch :-)

von Recht hat er (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Dick Boutsos schrieb:
> Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des
> selben products. Der Eine von denen (der war zertifizierter Scrotum
> Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper
> gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in
> dem Laden installiert hat

Das ist heutzutage leider üblich geworden! Waren früher die 
Fertigungsleute die Arbeitshuren die man ausbeuten musste sind es heute 
die Programmierer!
Diese sogenannte Networking ist eine massive Seuche für die, die noch 
etwas leisten und für den Betrieb sowieso! Fakt ist, mit Bullshitbingo, 
Networking und viel Geschwafel geht es die Erfolgsleiter nach oben! Wer 
nicht mitspielt hat schon verloren! Oben angekommen ist der Erfolg der 
Firma bzw. der Arbeitsweise egal, geht man halt woanders hin!
Dieser Wahnsinn hat system! Zack ist die nächste Firma am Abgrund!
Leider nicht so schnell, daß es sich rumspricht, aber dennoch real!
Die größten Posauner mit der niedrigsten Kompetenz in den wichtigsten 
Belangen zeigen, wo es lang geht!
Leider habe ich wohl ein Zuviel an Kompetenz, und zuwenig Dummschwätz... 
deshalb komm ich übers Brötchenbacken auch nicht hinaus!

von MaWin (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Tilo R. schrieb:
> Oder was macht man da, wenn zu einem späteren Zeitpunkt noch
> Requirements dazukommen?

Eine neue Rechnung an den Auftraggeber schreiben, was sonst ?

von René H. (Firma: anonymous) (hb9frh)


Bewertung
1 lesenswert
nicht lesenswert
MaWin schrieb:
> Tilo R. schrieb:
>> Oder was macht man da, wenn zu einem späteren Zeitpunkt noch
>> Requirements dazukommen?
>
> Eine neue Rechnung an den Auftraggeber schreiben, was sonst ?

Neue Requirements bedeuten in jedem Modell dass selbe. Änderungen. Das 
kann Agile nicht besser und nicht schlechter auffangen als andere 
Modelle.

Scrum war nicht dafür gedacht die Arbeitsleistung des Teams und 
einzelnen Personen zu kontrollieren und zu messen, aber dafür wird es 
verwendet und das ist nun mal ein Faktum. In der Realität wird es dafür 
missbraucht, damit auch die faulen ihre Ärsche hochbekommen. Darunter 
haben aber alle zu leiden, mit eben den bereits erwähnten vielen 
Meetings.

Das ist kein Klagen, dass ist eine Kritik an der Methode und wie sie 
verwendet wird!

von Johannes F. (doppelgrau)


Bewertung
-1 lesenswert
nicht lesenswert
René H. schrieb:
> Neue Requirements bedeuten in jedem Modell dass selbe. Änderungen. Das
> kann Agile nicht besser und nicht schlechter auffangen als andere
> Modelle.

Ich würde schon sagen, dass die agilen Modelle (sofern halbwegs tauglich 
gelebt) schon etwas besser auf wechselnde Anforderungen reagieren 
können. Da man nicht so weit in die Zukunft plant, muss man bei Änderung 
von Anforderungen nicht soviel Planungen "wegwerfen".
Außerdem ist eine engere Einbindung des Kunden vorgesehen (idealerweise 
ist ja das Ergebnis jedes Sprints vom Kunden ausprobierbar, ob das in 
die Richtung geht, die er sich vorgestellt hat).

Dadurch kommen Änderungswünsche eher => lassen sich noch besser 
integrieren als wenn man im V-Modell defakto alles fertig hat bevor der 
Kunde das erste mal was zu sehen bekommt.

Natürlich gibt's das nicht ohne Nachteile, dadurch das man nicht alles 
im Vorfeld durchplant, muss man öfter was wegwerfen was im Nachhinein so 
nicht mehr passt (und das auch politisch akzeptiert sein).

Am Ende ist es halt ein Werkzeug, und das muss zum Problem passend 
gewählt werden. Habe ich ein Projekt, wo die Anforderungen wirklich 
bekannt sind (z.B. Programmierung der Steuerung einer "konventionellen" 
Waschmaschine), ist was agiles einfach dämlich.
Ist klar, dass sich die Anforderungen ändern, sei es weil das Projekt 
innovativ ist, so das der Kunde/die Nutzer erst beim Testen wirklich 
merken was sie (anders) wollen oder so lang läuft, dass klar ist, dass 
die Rahmenbedingungen sich ändern (irgendwas Konzernweites, Projekt über 
Jahre. Da ist klar, das zwischendurch sich 48 juristische 
Rahmenbedingungen ändern, 12 Firmen integriert und abgestoßen werden und 
das "irgendwie" die Anforderungen beeinflusst), dann kann agil sinnvoll 
sein.
Sonst hat man nach 4 Jahren ein Produkt, was gut gewesen war vor 5 
Jahren als die Anforderungen erhoben wurden, aber im aktuellen Umfeld 
einfach keinen Sinn mehr ergibt.

: Bearbeitet durch User
von Egon D. (egon_d)


Bewertung
-2 lesenswert
nicht lesenswert
René H. schrieb:

> Neue Requirements bedeuten in jedem Modell dass selbe.
> Änderungen. Das kann Agile nicht besser und nicht
> schlechter auffangen als andere Modelle.

Vielleicht solltest Du mal mit Deiner alten Tradition
brechen und DOCH mal einen Blick in ein Buch werfen.
Das "Agile Manifest" würde sich eignen.

von Egon D. (egon_d)


Bewertung
1 lesenswert
nicht lesenswert
Udo S. schrieb:

> Der Hinweis auf Religionen in dem Wikipedia Artikel
> passt gut. Ich glaube SCRUM ist so ein bischen was
> wie eine Religion für manche.

Ich fühle mich eher an den Marxismus erinnert... oder
nehmen wir besser Cholesterin, das ist (scheinbar!)
nicht so politisch: Ancel Keys hat seinerzeit eine
Korrelation zwischen Cholesterinspiegel und Herz-
infarktrate gefunden und dieses Ergebnis publiziert.

Prompt kamen die Marktschreier und behaupteten:
"Cholesterin löst Herzinfarkte aus!" Millionen Menschen
quälten sich mit cholesterinarmer Ernährung, obwohl die
Chemiker WISSEN , dass der Cholesterinspiegel nur
minimal von dem mit der Nahrung aufgenommenen Cholesterin
abhängt -- das meiste produziert der Körper selbst.

Cholesterinsenker sind ein RIESIGER Markt, damit werden
jedes Jahr Milliarden gescheffelt. Dumm nur, dass bisher
niemand wirklich zuverlässig weiss, wovon der körper-
eigene Cholesterinspiegel abhängt und was ein Eingriff
von außen bewirkt. (Es gab beispielsweise Studien, die
einen Zusammenhang zwischen zu niedrigen Cholesterin-
spiegel und Demenz nahelegen.) Trotzdem werden fleissig
Cholesterinsenker verschrieben...

Und das Schlimmste: Außer ein paar akademischen Gehirn-
wichsern interessiert sich NIEMAND dafür, was Keys
wirklich geschrieben hat -- denn gerade, wenn er sich
geirrt hat, sollte man ihm nur das als Irrtum anlasten,
was er tatsächlich behauptet hat, und nicht das, was
ihm von seinen unkundigen Jüngern angedichtet wurde...

von Jan H. (j_hansen)


Bewertung
-1 lesenswert
nicht lesenswert
Johannes F. schrieb:
> Habe ich ein Projekt, wo die Anforderungen wirklich bekannt sind (z.B.
> Programmierung der Steuerung einer "konventionellen" Waschmaschine), ist
> was agiles einfach dämlich.

Warum? Wenn du das agile Manifest liest ist die Änderung von 
Anforderungen nur ein kleinerer Teil der Idee.

Wenn die anderen Rahmenbedingungen passen kann Scrum auch bei Projekten 
mit vollständig bekannten Anforderungen sinnvoll sein. Vielleicht möchte 
sie Hardwareentwicklung ja eine lauffähige Zwischenversion haben um das 
Schleudern oder EMV zu testen.

von Egon D. (egon_d)


Bewertung
1 lesenswert
nicht lesenswert
Johannes F. schrieb:

> Ist klar, dass sich die Anforderungen ändern, sei es
> weil das Projekt innovativ ist, so das der Kunde/die
> Nutzer erst beim Testen wirklich merken was sie
> (anders) wollen oder so lang läuft, dass klar ist,
> dass die Rahmenbedingungen sich ändern (irgendwas
> Konzernweites, Projekt über Jahre. Da ist klar, das
> zwischendurch sich 48 juristische Rahmenbedingungen
> ändern, 12 Firmen integriert und abgestoßen werden
> und das "irgendwie" die Anforderungen beeinflusst),
> dann kann agil sinnvoll sein.

Du sprichst hier nebenbei aus, was ungefähr 90% der
Kritiker hier in A,S&B ihr Leben lang ein Geheimnis
bleiben wird: Es ist ein intrinsisches Merkmal eines
Projektes, dass am Anfang ein Wissensdefizit vorliegt.
Genau das Wissensdefizit ist es, was ein Projekt zum
Projekt macht -- wüsste man am Anfang schon alles,
wäre es ein einfacher Auftrag.

von Name: (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Dick Boutsos schrieb:
> Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des
> selben products. Der Eine von denen (der war zertifizierter Scrotum
> Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper
> gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in
> dem Laden installiert hat.

Das ist aber kein SCRUM-Problem. Solche Schwätzer haben wir hier auch. 
Nennt sich "Innovationsabteilung".

Deren "geniale Ideen" dürfen normale Entwickler nicht kritisieren oder 
kommentieren, denn Cheffe hat sich dort als Teamleiter dort installiert 
und fasst Kritik entsprechend als persönlichen Angriff auf. Er liebt 
Selfies vor Patantanträgen, die öffentlich aushängen. Keine einzige der 
"Innovationen" jemals zu einem Produkt geführt. Seit 5 Jahren nur teures 
Scheitern, oft an der Physik. Wenn nich daran, dann daran, dass deren 
Schmarrn viel zu teuer ist.

Die haben 5(!) Jahre lang keine, aber auch gar keine einzieg Idee 
irgenwie in ein Produkt überführen können. Nichts. Da wird nichts davon 
verkauft. 0,000€ verdient, Millionen ausgegeben. Inzwischen dürfen sie 
glücklicherweise kein Geld mehr ausgeben, oder sonstige Ressourcen 
nutzen. Irgendwer hat also was gemerkt. Langsam wird man dort sichtlich 
nervös.
Ich fürchte schlimmes, den Cheffe wird die Leute vermutlich in die 
Entwicklung drücken, und wir müssen die mitziehen. Darum wälze ich schon 
Stellenazeigen.

--> Die Schwätzerseuche ist ein größeres Problem in der Wirtschaft, als 
der Wandel in der Fahrzeugindustrie je sein könnte...
--> Für heutige Chefs zählt oft nur Geschwätz. Leistung ist irrelevant. 
Traurig.

von Egon D. (egon_d)


Bewertung
2 lesenswert
nicht lesenswert
Jan H. schrieb:

> Johannes F. schrieb:
>> Habe ich ein Projekt, wo die Anforderungen wirklich
>> bekannt sind (z.B. Programmierung der Steuerung einer
>> "konventionellen" Waschmaschine), ist was agiles
>> einfach dämlich.
>
> Warum? Wenn du das agile Manifest liest ist die
> Änderung von Anforderungen nur ein kleinerer Teil
> der Idee.

... aber m.E. der entscheidende.


> Wenn die anderen Rahmenbedingungen passen kann Scrum
> auch bei Projekten mit vollständig bekannten
> Anforderungen sinnvoll sein. Vielleicht möchte sie
> Hardwareentwicklung ja eine lauffähige Zwischenversion
> haben um das Schleudern oder EMV zu testen.

Ich würde zwischen "iterativ" und "agil" unterscheiden.
Iteratives Vorgehen ist praktisch immer sinnvoll (siehe
Winston W. Royce: "Do it twice"). Dass Agilität bei
vollständig bekannten Anforderungen sinnvoll sein soll,
erschließt sich mir erstmal nicht.

von Scrummaster (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird 
aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde. 
Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg 
durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes 
Tätigungsfeld suchen.

Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile 
von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt?

Bitte zu machen und löschen, danke.

von Name: (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Scrummaster schrieb:
> Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird
> aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde.
> Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg
> durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes
> Tätigungsfeld suchen.

Krieg, Landmienen, Folter und Krankheit haben sich auch weltweit 
durchgesetzt und sind erfolgreich...

von soso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Scrummaster schrieb:
> Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile
> von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt?

Siehe oben...Was mir gerade klar wird, der Tenor ist:

René H. schrieb:
> Das ist kein Klagen, dass ist eine Kritik an der Methode und wie sie
> verwendet wird!

von Udo S. (urschmitt)


Bewertung
2 lesenswert
nicht lesenswert
Scrummaster schrieb:
> Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird
> aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde.

Klingst ein bischen wie Trump, der kann Kritik auch nicht leiden und 
hält sich für besser als Gott.

SCNR

Egon D. schrieb:
> Ich fühle mich eher an den Marxismus erinnert... oder
> nehmen wir besser Cholesterin, das ist (scheinbar!)
> nicht so politisch:

Dein Beispiel passt ganz gut. SCRUM als Idee ist ja nicht das Problem, 
im Endeffekt unterscheidet es sich nicht so viel von guten Projekten die 
ich erlebt habe bevor hier irgendwer SCRUm kannte.
Mich nervt nur das starre Konzept das drüber gestülpt wird, was dazu 
führt dass zumindest ein Teil der Leute Scheuklappen aufsetzt.
Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl 
klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja 
"mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage 
ich mich wohin das Hirn verschwunden ist.
Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck 
aufzubauen um mehr Leistung aus den Leuten zu quetschen und die 
Verantwortung bei Problemen von oben nach unten zu schieben.

: Bearbeitet durch User
von MaWin (Gast)


Bewertung
1 lesenswert
nicht lesenswert
vn nn schrieb:
> um mit der Zeit die Abschätzungen zu verbessern

Während mwn beum Hausbau weiss,  wie lange es dauert Stein auf Stein zu 
stellen, ist eine Fehlersuche eben eine Suche.
Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen 
zu finden.

vn nn schrieb:
> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
> deswegen ist Scrum kacke!!1elf"

Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig 
tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit 
heilen, bete mehr.

von Framulestigo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Udo S. schrieb:
> Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck
> aufzubauen um mehr Leistung aus den Leuten zu quetschen
Ob mit oder ohne SCRUM:
Wenn Dein Kollege den Job sauber in der Hälfte der Zeit schafft, dann 
sollte Dir das zu denken geben.
Aber meist sind es doch nur die Dummschwätzer, denen ihr Code nach einer 
statt drei Wochen Arbeit beim ersten Start um die Ohren fliegt. Von 
denen muss man sich nicht drängen lassen.

von Agiler (Gast)


Bewertung
5 lesenswert
nicht lesenswert
Wir sind in einem Projekt auch agil unterwegs. In meinem SW-Subteam 
leben wir das nicht mehr wirklich, da es doppelte Arbeit ist. 
Detaillierte Planungen und Regelmeetings im Team und mit anderen 
Parteien werden weiterhin benötigt, um Prozessforderungen (intern und 
von den Kunden) zu erfüllen.

Ich habe in zwei aufeinanderfolgenden Demos (3 Wochen dazwischen) mal 
den Versuch gemacht, genau die gleichen Ergebnisse zu präsentieren (auf 
Grund anderer Themen war tatsächlich auch kein Fortschritt da, aber das 
habe ich verschwiegen).
Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal 
wurde ich sogar noch für den Fortschritt gelobt ^^

von Framulestigo (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Agiler schrieb:
> Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal
> wurde ich sogar noch für den Fortschritt gelobt ^^

Genau dazu habe ich mal eine Frage:

SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse 
beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller 
zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden 
vorzulegen, damit der zeitnah eingreifen und lenken kann.

Aber wie sieht das in der Realität aus? Sind die Verantwortlichen beim 
Kunden wirklich so realitätsnah und wissen, was gebraucht wird? Oder 
sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken 
für die Besprechungen aufweist.

Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch 
SCRUM real erfolgreicher?

von Egon D. (egon_d)


Bewertung
1 lesenswert
nicht lesenswert
Udo S. schrieb:

> Egon D. schrieb:
>> Ich fühle mich eher an den Marxismus erinnert... oder
>> nehmen wir besser Cholesterin, das ist (scheinbar!)
>> nicht so politisch:
>
> Dein Beispiel passt ganz gut. SCRUM als Idee ist ja nicht
> das Problem, im Endeffekt unterscheidet es sich nicht so
> viel von guten Projekten die ich erlebt habe bevor hier
> irgendwer SCRUm kannte.

Ja, klar, aber...


> Mich nervt nur das starre Konzept das drüber gestülpt
> wird, was dazu führt dass zumindest ein Teil der Leute
> Scheuklappen aufsetzt.

...das "starre Konzept" ist ein intrinsisches Problem,
das jeder agilen Methodik -- und jeder Projektmethodik
überhaupt -- innewohnt: Man versucht, das, was gute Leute
intuitiv können und richtig machen, explizit als Regelsatz
zu formulieren.

Wenn jetzt ein Anfänger diese Regeln liest, ohne den
Erfahrungshintergrund dazu zu kennen, kommt natürlich
Mist heraus, weil er sich an formalen Details aufhängt
und das Prinzip dahinter nicht versteht.

Dazu kommt noch, dass die Erfinder der Agilität m.E.
die Interessenkonflikte zwischen Management, Projekt-
leitung und Indianern ziemlich blauäugig behandeln.


> Wenn ich sehe dass ein Team hier 3 Tage munter
> weiterentwickelt, obwohl klar ist daß sich eine
> wesentliche Anforderung geändert hat, weil man ja
> "mitten im Sprint" ist, und da keine Änderungen
> erlaubt sind, dann frage ich mich wohin das Hirn
> verschwunden ist.

Naja, das sehe ich nicht ganz so. Ist ein weites
Feld.


> Und eben die Tatsache das SCRUm massiv dazu genutzt
> wird Druck aufzubauen um mehr Leistung aus den Leuten
> zu quetschen und die Verantwortung bei Problemen von
> oben nach unten zu schieben.

Richtig -- das ist der eigentlich ärgerliche Punkt. Die
agile Gilde muss sich den Vorwurf gefallen lassen, dass
sie dieses Problemfeld unterschätzt hat.

von Jan H. (j_hansen)


Bewertung
1 lesenswert
nicht lesenswert
Udo S. schrieb:
> Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl
> klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja
> "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage
> ich mich wohin das Hirn verschwunden ist.

Das kann (nicht muss!) durchaus sinnvoll sein. Die Geschäftswelt ist 
teilweise leider schlimmer als ein Kindergarten. Erlaube einmal eine 
Änderung während des Sprints, und schon kommen täglich "dringende 
wesentliche" Änderungen. Kommt natürlich stark auf die Kultur an.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Egon D. schrieb:
> René H. schrieb:
>
>> Neue Requirements bedeuten in jedem Modell dass selbe.
>> Änderungen. Das kann Agile nicht besser und nicht
>> schlechter auffangen als andere Modelle.
>
> Vielleicht solltest Du mal mit Deiner alten Tradition
> brechen und DOCH mal einen Blick in ein Buch werfen.
> Das "Agile Manifest" würde sich eignen.

Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum 
Master. Ich bin gegenüber Neuem immer erst mal offen und Neutral. Bilde 
mich auch weiter. Und wie bereits geschrieben, ich finde Scrum nicht 
grundsätzlich schlecht. Richtig eingesetzt. Wie jedes andere Werkzeug 
auch.

Also, Egon, belehr mich nicht!

Beitrag #6143463 wurde von einem Moderator gelöscht.
Beitrag #6143466 wurde von einem Moderator gelöscht.
von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
René H. schrieb:

> Egon D. schrieb:
>> René H. schrieb:
>>
>>> Neue Requirements bedeuten in jedem Modell dass selbe.
>>> Änderungen. Das kann Agile nicht besser und nicht
>>> schlechter auffangen als andere Modelle.
>>
>> Vielleicht solltest Du mal mit Deiner alten Tradition
>> brechen und DOCH mal einen Blick in ein Buch werfen.
>> Das "Agile Manifest" würde sich eignen.
>
> Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter
> Scrum Master.

In der Tat: Das glaube ich wirklich nicht! :)

Der praktische Unterschied zwischen einem einfach nur
iterativen Vorgehen und einer agilen Vorgehensweise ist
ja GERADE der, dass die schrittweise Annäherung AUCH
die Anforderungen einschließt und also den Kunden
einbezieht.

Die agile Methodenwelt ist ja eine Reaktion auf die
Erfahrungstatsache, dass späte Änderungen eben NICHT
vollständig vermeidbar sind -- also versucht man, den
Spieß umzudrehen: Wenn Änderungen ohnehin nicht vermeidbar
sind, dann richten wir all unsere Arbeitsabläufe darauf
aus, dass wenigstens die Kosten für diese Änderung
möglichst niedrig bleiben.

Dass das als Einladung zum Missbrauch aufgefasst werden
kann, hatten die Vordenker der Agilität wohl nicht aus-
reichend auf dem Schirm...

von Udo S. (urschmitt)


Bewertung
2 lesenswert
nicht lesenswert
Egon D. schrieb:
> Dass das als Einladung zum Missbrauch aufgefasst werden
> kann, hatten die Vordenker der Agilität wohl nicht aus-
> reichend auf dem Schirm...

Vor allem auch nicht, dass ganze Horden von Beratungs und 
Schulungsunternehmen alle Entscheider/Geschäftsleitung mit den tollsten 
Versprechungen zumüllen um Umsatz zu machen.
Sind diese Horden dann (teilweise) wieder gegangen wird doppelte 
Produktivität erwartet, was bei vorher funktionierenden Prozessen die 
nicht SCRUM waren natürlich Schwachsinn ist.
Durch die komplette Umkrempelung wird es dann erst mal zu weniger 
Produktivität kommen.

von Michael Gugelhupf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Udo S. schrieb:
> Mich nervt nur das starre Konzept das drüber gestülpt wird, was dazu
> führt dass zumindest ein Teil der Leute Scheuklappen aufsetzt.
> Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl
> klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja
> "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage
> ich mich wohin das Hirn verschwunden ist.

Die Frage ist völlig berechtigt. Hirnmangel oder Lesemangel. Man kann 
einen Sprint auch mittendrin einfach abbrechen. Formal können das zwei 
Spieler:

1) Der PO bricht den Sprint ab weil das Ziel des Sprint obsolet ist.

2) Der Scrummaster bricht im Namen des Teams den Sprint ab weil das Team 
von irgendwas die Schnauze voll hat.

Die dritte Variante ist nicht offiziell:

3) Das Team bricht den Sprint unter Umgehung des Scrummasters ab weil es 
von irgendwas und dem Scrummaster die Schnauze voll hat.

Natürlich wird das alles in der Praxis nicht gemacht. 1) bedeutet der PO 
muss verstehen was seine Rolle ist und Verantwortung übernehmen, nicht 
zuletzt für die Zusatzkosten und die verschwendete Arbeit die der 
Abbruch und die radikale Änderung der Anforderung mit sich bringt. Statt 
dessen mogelt sich der PO lieber durch um beim Chef nicht blöd 
dazustehen.

2) und 3) entspricht einem kleinen Streik, einer Arbeitsverweigerung. 
Dann bricht das ganze Kartenhaus um das Scrumteam zusammen, von wegen 
selbstorganisierend und alle Freiheiten. Dann werden Leute auf höheren 
Hierarchieebenen richtig böse. Wer zahlt bestimmt die Musik und das ist 
letzten Endes nicht das Scrumteam.

So bricht Scrum dann mal wieder in der harten Realität des Arbeitslebens 
zusammen.

Nebenbei bemerkt, der hier herum turnende zertifizierte(!) Scrummaster 
hätte Antwort 1) und 2) sofort geben müssen. Das sollte er auf der 
Schule für kleine Scrummaster gelernt haben.

von Eulenspiegel (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ach ja, Agile und Scrum.

Das Interessante ist, das bei meinem ehemaligen AG (Ausland, 20 
hochqualifizierte Tech-"Bros", 2 Produktmanager, die selber 
Vollblutingenieure waren) völlig ohne Kotzen und relativ effizient 
funktioniert. Wenig Verwaltungsoverhead, konzentriertes Arbeiten. "Agile 
Light" funktioniert ganz gut.

Nun habe ich hier im Team (1 Dutzend) einen Agile-"Coach" und einen 
nicht-technischen PM sowie PO. 120% Scrum. Alle 2 Wochen: 4x2h 
Scrum-"Zeremonien" und 1x1h Inter-Team-"Review", dazu jede andere Woche 
2x2h "Refinement" und 5x0.5h "Daily" sowieso.

Da wird dann sinnlos an Tickets rumgeschnitzt nach dem Motto "1 
Arbeitspaket von 12h lässt sich in 3 Arbeitspakete zu 4h unterteilen, 
die von verschiedenen Leuten bearbeitet werden, lasst uns das jetzt 
kleinlabern und dann von Leuten, die keine Ahnung haben und nicht am 
Thema interessiert sind, schätzen lassen".

Bis heute haben die nicht verstanden, dass ein wertschöpfender 
Entwicklungstask von 6h bei Unterteilung in 2x3h mindestens 8h dauert 
und dass somit prinzipiell mit Schnipseltickets alles länger dauert als 
die Summe der "Storypunkte" vermuten ließe.

Und dann wundern sie sich, wenn die Monate ins Land gehen.

von Eulenspiegel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Egon D. schrieb:
>> Und eben die Tatsache das SCRUm massiv dazu genutzt
>> wird Druck aufzubauen um mehr Leistung aus den Leuten
>> zu quetschen und die Verantwortung bei Problemen von
>> oben nach unten zu schieben.
>
> Richtig -- das ist der eigentlich ärgerliche Punkt. Die
> agile Gilde muss sich den Vorwurf gefallen lassen, dass
> sie dieses Problemfeld unterschätzt hat.

Läuft doch alles nach Plan. Agile wurde zuerst dem Management verkauft 
und dann unter die Leute gebracht.

von Michael Gugelhupf (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Framulestigo schrieb:
> SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse
> beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller
> zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden
> vorzulegen, damit der zeitnah eingreifen und lenken kann.
>
> Aber wie sieht das in der Realität aus?

Meiner Erfahrung nach sehr sehr mau. Es mag in anderen Firmen, in 
anderen Branchen Kunden geben die das Spiel mitmachen. Der Kunde will 
sich doch gar nicht ständig mit der Softwareentwicklung befassen. Wollte 
er das würde er die Software selber entwickeln, nicht kaufen.

Wer soll denn jede Woche vom Kunden aus die letzten Entwicklungen 
begutachten (Demo)? Ein teurer Manager? Der hat doch keine Ahnung. Der 
weniger teure Spezialist, der dann jede Woche einen Tag ausfällt? Der 
Praktikant, der billig ist aber nicht weiß was benötigt wird?

> Sind die Verantwortlichen beim
> Kunden wirklich so realitätsnah und wissen, was gebraucht wird?

Wer weiß was gebraucht wird hat häufig nicht die Verantwortung. 
Entscheidungen behält sich das Management vor, besonders solche, die 
Geld kosten.

> Oder
> sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken
> für die Besprechungen aufweist.

Nein, weil der Kunde nicht gar nicht erst kommt. Egal ob Manager, 
Spezialist oder Praktikant.

> Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch
> SCRUM real erfolgreicher?

Wenn er mitspielen würde vielleicht.

Was funktioniert ist eine Art gemeinsame Entwicklung. Das ist ein altes 
Konzept noch aus XP-Zeiten, der On-Site Customer. Scrum hat sowieso die 
Hälfte von XP (schlecht) kopiert.

Der Kunde stellt für die Entwicklung einen Mitarbeiter (Spezialisten) 
ab, der Teil des Entwickler-Teams wird. Es muss aber wirklich ein 
Spezialist sein, nicht der Praktikant.

Wenn das Interesse der beteiligten Firmen groß genug ist, z.B. ein 
gemeinsames Produkt zu dem die Software gehört, dann funktioniert das. 
Ansonsten scheitert auch das.

von Udo S. (urschmitt)


Bewertung
1 lesenswert
nicht lesenswert
Bei vielen Projekten ist der Kunde die Fachabteilung oder das eigene 
Management.

Beitrag #6144028 wurde von einem Moderator gelöscht.
Beitrag #6144039 wurde von einem Moderator gelöscht.
von René H. (Firma: anonymous) (hb9frh)


Bewertung
-2 lesenswert
nicht lesenswert
Egon D. schrieb:
> In der Tat: Das glaube ich wirklich nicht! :)
> Der praktische Unterschied zwischen einem einfach nur iterativen
> Vorgehen und einer agilen Vorgehensweise ist ja GERADE der, dass die
> schrittweise Annäherung AUCH die Anforderungen einschließt und also den
> Kunden einbezieht.

Ja, alles korrekt. In einer schöner theoretischen Welt. Die Welt ist 
aber nicht so.
Scrum ist eine gute Sache wenn ein neues Projekt/Produkt entwickelt wird 
in einem Team. Es ist aber untauglich für Maintenance. Da braucht es 
kein agil. Scrum wird missbraucht! Und das ist der Punkt.

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Michael Gugelhupf schrieb:
> Nebenbei bemerkt, der hier herum turnende zertifizierte(!) Scrummaster
> hätte Antwort 1) und 2) sofort geben müssen. Das sollte er auf der
> Schule für kleine Scrummaster gelernt haben.

Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum 
Master! Ich bin und bleibe Entwickler.

Beitrag #6144051 wurde von einem Moderator gelöscht.
Beitrag #6144057 wurde von einem Moderator gelöscht.
Beitrag #6144096 wurde von einem Moderator gelöscht.
Beitrag #6144113 wurde von einem Moderator gelöscht.
Beitrag #6144114 wurde von einem Moderator gelöscht.
Beitrag #6144117 wurde von einem Moderator gelöscht.
Beitrag #6144122 wurde von einem Moderator gelöscht.
von PO (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bin vom Entwickler zum Product Owner "aufgestiegen" und grundsätzlich 
funktioniert es ganz gut bei uns. In den Sprints arbeiten die Entwickler 
eigenständig ihre Tasks ab.
Daily Standups gibt und gab es bei uns sowieso schon immer, da wir eine 
aktive "Kaffeekultur" haben...

Grundsätzlich bin ich als PO für die technische Entwicklung voll 
verantwortlich. Ich behalte den Überblick, kenne die Architektur und 
bereite das Backlog vor. Die Kommunikation mit dem Kunden und 
Anforderungen übernimmt zu 2/3 der Produkt Manager, der mich dann bei 
Bedarf mitnimmt.

Es gibt bei uns alleridngs aus Prozessgründen auch Projektmanager, die 
kümmern sich allerdings nicht um technische Details der Entwicklung, 
sondern um die Planung der Auslieferungen, Inbetriebnahmen, 
Vertragsdetails... von denen kommt dann als Rückmeldung zum PM und PO, 
dass Kunde X eine Anlage zum Zeitpunkt Y bekommt und diese Features 
(bzw. diese Version) von der Software dort eingesetzt werden soll.

Ich denke es gibt ein paar "Fallen", in die traditionelle 
Projektmanager, die Mikromanagement bis ins kleinste Detail 
perfektioniert haben, treten und damit dann Scrum aktiv zerstören (ist 
dann aber Quatsch, dass Scrum dann nicht robust genug ist -> jeder 
Prozess kann aktiv zerstört und umgangen werden)

- Das Team muss selbstorganisiert sein: Ich als PO "assigne" nicht 
direkt Tasks bzw. nur in Ausnahmefällen (dringender Bug). In den 
Planning Meetings kommt vom Team die Rückmeldung, wer was macht, wenn 
ich das Backlog für den Sprint zeige. Bei uns hat sich das sowieso schon 
eingespielt, da die Entwickler natürlich Spezialisierungen haben und der 
eine oder andere immer Tasks in diese Richtung macht.
- Überplanung der Backlog-Items: Ich schreibe in die Backlog-Items, was 
ich am Ende "in der Hand haben will". Den Lösungsweg muss der Entwickler 
bringen. Im klassischen PM kommt der Lösungsweg oft "von oben" und der 
Entwickler muss es dann auf die Spezifikation genau umsetzen. Das geht 
gegen den Gedanken von Scrum.
- Nach jedem Sprint muss die Software/Hardware ein Stück weiter sein: 
Das Backlog für einen Sprint muss so aufbereitet sein, dass nach dem 
Sprint die Software "ein wenig mehr" an Funktionalität hat, als davor. 
Das ist die Aufgabe vom PO, das sicher zu stellen.

Wenn diese drei Merkmale nicht erfüllt sind, dann kann man wohl wirklich 
von "bullshit-bingo" sprechen...

von Hugo H. (hugohurtig1)


Bewertung
-1 lesenswert
nicht lesenswert
René H. schrieb:
> Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum
> Master.

René H. schrieb:
> Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum
> Master! Ich bin und bleibe Entwickler.

Ohne böse Worte - jetzt besser? :-)

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Hugo H. schrieb:
> René H. schrieb:
>> Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum
>> Master.
>
> René H. schrieb:
>> Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum
>> Master! Ich bin und bleibe Entwickler.
>
> Ohne böse Worte - jetzt besser? :-)

Böse Worte sind mir grundsätzlich Wurscht wenn sie berechtigt sind. In 
diesem Fall waren sie es nicht. Allgemeine Entspannung?

von René H. (Firma: anonymous) (hb9frh)


Bewertung
0 lesenswert
nicht lesenswert
BTW: ich poste hier mit meinem Rufzeichen. Mein AG liest hier übrigens 
auch mit. Lügen ist da nicht.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
PO schrieb:
> Grundsätzlich bin ich als PO für die technische Entwicklung voll
> verantwortlich. Ich behalte den Überblick, kenne die Architektur und
> bereite das Backlog vor.

Wenn das gegeben ist, und Du als PO das wie den Entwicklern überlassen 
kannst, dann ist das schon ideal. Da würde auch andere Verfahren laufen.


Schlimm ist, wenn der PO nur Manager ist ohne fachlichen Durchblick 
("ihr seid die Fachleute"). Leider ist das oft so, dass PO und Co der 
Karriereweg für jene ist, die in der Entwicklung scheitern.

Beitrag #6144565 wurde vom Autor gelöscht.
Beitrag #6144573 wurde vom Autor gelöscht.
von Udo S. (urschmitt)


Bewertung
0 lesenswert
nicht lesenswert
PO schrieb:
> Ich denke es gibt ein paar "Fallen", in die traditionelle
> Projektmanager, die Mikromanagement bis ins kleinste Detail
> perfektioniert haben, treten und damit dann Scrum aktiv zerstören

Sorry, aber mein Eindruck hier bei uns ist, dass bei den SCRUM Teams 
viel mehr "Mikromanagement" betrieben wird, weil jede Aufgabe zwanghaft 
versucht wird in maximal kleine Teilaufgaben zu zersplittern.

Wenn eure Projektmanager "Mikromanagement" betrieben haben, dann sollten 
sie sich eine andere Aufgabe suchen.
Ich bin hier völlig frei meine Aufgaben so zu erledigen wie ich (und die 
anderen Projektmitarbeiter) es für richtig halten, das Projektmanagement 
gibt nur die Rahmen und das grobe Lastenheft vor und erhält vom 
Entwicklungsteam zusammen mit dem Produktverantwortlichen eine 
Zeitabschätzung möglichst incl. Risikobewertung.
Klar knirscht es da auch mal, oder der Kunde kippt spät Änderungen rein 
und sieht nicht ein dass es dann länger dauert, aber genau dann ist der 
Projektmanager gefordert.
Und das funktioniert völlig ohne starres SCRUM Korsett.

von Egon D. (egon_d)


Bewertung
-1 lesenswert
nicht lesenswert
Udo S. schrieb:

> Wenn eure Projektmanager "Mikromanagement" betrieben haben,
> dann sollten sie sich eine andere Aufgabe suchen.

Genau.
Und wer nicht mit einer vollständigen Kenntnis des C-Standards
geboren wird, soll Bäcker werden -- und nicht Programmierer.
Schulen, Universitäten, Ausbildung wird sowieso überschätzt.
Kein Mensch mus je irgendwas lernen -- entweder er kann es,
oder es hat sowieso keinen Sinn.


> [...]
> Und das funktioniert völlig ohne starres SCRUM Korsett.

Das bedeutet nur, dass Eure Führungskräfte gut und fähig
sind -- und nicht, dass SCRUM generell schlecht ist.

Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
Versuch, die Dinge explizit zu formulieren und lehrbar zu
machen, die gute Leute intuitiv richtig machen.

Das ist im Ansatz erstmal nicht falsch.

Beitrag #6144708 wurde von einem Moderator gelöscht.
Beitrag #6144753 wurde von einem Moderator gelöscht.
Beitrag #6144884 wurde von einem Moderator gelöscht.
Beitrag #6144896 wurde von einem Moderator gelöscht.
Beitrag #6144910 wurde von einem Moderator gelöscht.
von DrFounder (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Scrum funktioniert eben nicht überall und zwanghaft alles in das 
Framework reinzupressen macht einfach keinen Sinn. Leider wird Scrum 
häufig zum Mikromanagement missbraucht und dient häufig dazu, dass man 
eine Art Fabrikarbeit etabliert, die Entwickler zu Implementierern 
degradiert. Besonders bei großen Konzernen ist das oft der Fall, weil 
man dort alles möglichst in kleine übertragbare Aufgaben verpacken will.

Wenn man aber vernünftig "agile" arbeitet, funktioniert es auch recht 
gut. Nur meistens nicht so wirklich mit Scrum. Man braucht aber auch die 
richtigen Leute dafür. Der lernresistene 9to5 Arbeiter ist denkbar 
ungeeignet für richtiges "Agile". Jemand, der gegen alles neue kämpft 
und destruktiv ist kann eben nichts sinnvolles beitragen. Die Idee 
dahinter ist ja eigentlich, dass man Hierachien abbaut und nicht alles 
vorkaut.

Scrum ist so ein Mittelding, irgendwie braucht man die ganzen 
Wasserköpfe noch (oder sogar mehr) und irgendwie kann man damit werben 
agil zu arbeiten. Wasserköpfe behalten ihre unnötigen Jobs und 
Entwickler bekommen das Gefühl agil zu sein, nur bringen tut es effektiv 
halt nix.

Beitrag #6144941 wurde von einem Moderator gelöscht.
von Matthias Döpke (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Egon D. schrieb:
> Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
> Versuch, die Dinge explizit zu formulieren und lehrbar zu
> machen, die gute Leute intuitiv richtig machen.

Sehe ich ganz genauso !!! ;)

von Matthias Döpke (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Bei uns testet der Kunde tätsächlich die einzelnen Releases .. d.h. 
nicht der Kunde selbst - die haben oft keine Ahnung von der Materie.
Das machen Subauftragnehmer wie üblich heute - 
Entwicklungsdienstleister.
Abartig in welche Richtung das heute läuft ...

Aber die Dienstleister testen dann Releases die Wochen zurückliegen, da 
sie wohl mit der Arbeit ned hinterher kommen oder was immer.

Die Folge :
Wir müssen dann Schwächen in Releases suchen, die schon längst 
überarbeitet wurden und folglich verlieren wir eine Menge Zeit, um alte 
Hardware- und Softwarestände wieder einzurichten und dann dort Fehler zu 
suchen und zu korrigieren ... obwohl mit denen gar nicht mehr gearbeitet 
wird, da sie nur ein Zwischenstand waren.
Die neue Hard-/Software arbeitet möglicherweise schon anders, so dass 
die Probleme dort gar nicht auftreten würden.

Wir haben früher ebenfalls abschnittsweise entwickelt und die 
entsprechenden Abschnitte getestet.
Ich denke mal es erklärt sich von selbst, dass ein engagierter 
Entwickler seinen Kram selbst auf Herz und Nieren testet und so viel 
Ehre hat ein 'sauberes' Produkt abzuliefern.

von Matthias Döpke (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Und früher ohne Prozesse haben wir Kundenwünsche in wenigen Stunden 
umgesetzt getestet und 2 Tage später hatte der Kunde das auf dem 
Steuergerät zum Testen und war sehr zufrieden.

Heute bei all den modernen Prozessen mit viel mehr Leuten, aber Scrum, 
Controll-Board und all dem Blödsinn dauert es Wochen bis wir überhaupt 
Anstalten machen Fehler oder Änderungen zu bearbeiten, der Kunde ist 
ärgerlich und wir unmotiviert ...
 :D

von vn nn (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
MaWin schrieb:
> vn nn schrieb:
>> um mit der Zeit die Abschätzungen zu verbessern
>
> Während mwn beum Hausbau weiss,  wie lange es dauert Stein auf Stein zu
> stellen, ist eine Fehlersuche eben eine Suche.
> Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen
> zu finden.

Nein? Doch! Oh!
Genau deswegen wird einem normalerweise keiner den Kopf abreißen, wenn 
man als Softwareentwickler mal seine Zeiteinschätzung nachträglich 
korrigieren muss. Egal ob mit Scrum, oder ohne.
Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang 
du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine 
Bastelbude?

MaWin schrieb:
> vn nn schrieb:
>> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut,
>> deswegen ist Scrum kacke!!1elf"
>
> Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig
> tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit
> heilen, bete mehr.

Dein Posting macht leider absolut keinen Sinn. Überraschung, wer hätte 
das gedacht...

von vn nn (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Udo S. schrieb:
> Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck
> aufzubauen um mehr Leistung aus den Leuten zu quetschen und die
> Verantwortung bei Problemen von oben nach unten zu schieben.

Ob dein Chef ein Arsch ist oder nicht, wird sich wohl durch die 
Verwendung von Scrum (oder sonst irgendeinem Prozess) nicht ändern. 
Entweder er ist einer, dann wird er immer einen Weg finden, Druck 
aufzubauen, oder er ist eben keiner.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
vn nn schrieb:
> Egal ob mit Scrum, oder ohne.
> Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang
> du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine
> Bastelbude?

Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft 
gemacht wurden) und Dinge, die nicht abschätzbar sind,  z.B. manchmal 
Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und 
denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber 
es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen 
Projektes wenn man den sporadischen Absturz nicht findet oder patchen 
kann.

Beitrag #6145887 wurde von einem Moderator gelöscht.
von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> vn nn schrieb:
>> Egal ob mit Scrum, oder ohne.
>> Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang
>> du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine
>> Bastelbude?
>
> Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft
> gemacht wurden) und Dinge, die nicht abschätzbar sind,  z.B. manchmal
> Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und
> denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber
> es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen
> Projektes wenn man den sporadischen Absturz nicht findet oder patchen
> kann.

Genau das ist es, was ich die ganze Zeit sage. Und in jedem Projekt ist 
es üblich, seinen Vorgesetzten über sowas im Bilde zu halten.
Außer
a) Bastelbude, er will es gar nicht wissen
b) keine Eier dem Chef zu sagen dass man hinter dem Zeitplan ist.
c) cholerischer Vorgesetzter wirfst jeden beim geringsten Fehlschlag 
raus.

In allen drei Fällen hilft nur ein Jobwechsel, bei a) und c) zu einer 
Firma wo nicht gebastelt wird und es eine ordentliche Fehlerkultur gibt, 
bei b) in eine Branche wo man keine Eier braucht.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
BTW, wenn es "sporadische, unauffindbare Abstürze" gibt, die ein ganzes 
Projekt zum scheitern bringen, läuft auch was falsch...

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
Nachdem die meisten hier scheinbar was gegen Scrum & Co haben, mal die 
konstruktive Gegenfrage: Welche Softwareentwicklungsmodelle 
funktionieren den besser bei Projekten wo die Anforderungen sich im 
Laufe des Projektes ändern können (innovativ, lang laufend usw.)?
Und das meine ich für "ernsthafte" Projekte, also wo nicht mehr "rede 
halt mit meinen Kollegen im gleichen Zimmer" ausreicht.

von DrFounder (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Kanban

von Johannes F. (doppelgrau)


Bewertung
0 lesenswert
nicht lesenswert
DrFounder schrieb:
> Kanban

Laut der allwissenden Müllhalde: "Kanban weist viele Gemeinsamkeiten mit 
dem agilen Managementframework Scrum auf, steht jedoch in keinem 
zwingenden Verhältnis zu diesem. Weder muss man zuerst Scrum einsetzen, 
bevor man Kanban einführt, noch schließen sich beide Ansätze komplett 
aus. In gewisser Weise lässt sich Scrum als eine mögliche 
Implementierung von Kanban ansehen. Der Hauptunterschied zwischen beiden 
Ansätzen besteht darin, dass Scrum ein team-zentrierter Ansatz ist und 
Kanban primär die Wertgenerierung entlang der Wertschöpfungskette 
optimiert. "

Kannst du mir erläutern, wie das die bei der Ähnlichkeit die ganzen 
angesprochenen Kritikpunkte adressiert werden?

von René H. (Firma: anonymous) (hb9frh)


Bewertung
-1 lesenswert
nicht lesenswert
Johannes F. schrieb:
> Kannst du mir erläutern, wie das die bei der Ähnlichkeit die ganzen
> angesprochenen Kritikpunkte adressiert werden?

Kanban finde ich besser, weil weniger Meetings als mit Scrum.

Den oben zitierten Satz von Dir verstehe ich nicht. Zu komplizierten 
Syntax :-).

von M. W. (elektrowagi78) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Matthias Döpke schrieb:
> Egon D. schrieb:
>> Alle Vorgehensmodelle und Methodiken sind sowieso nur ein
>> Versuch, die Dinge explizit zu formulieren und lehrbar zu
>> machen, die gute Leute intuitiv richtig machen.
>
> Sehe ich ganz genauso !!! ;)

+1!

Beitrag #6146485 wurde von einem Moderator gelöscht.
von Unglaublich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die neueste Quintessenz: Die Tools funktionieren gar nicht richtig. Man 
packt seine Dokumentationen und Workflow in Tools, die ihre Daten in 
Clouds parken. Werden die morgen abgeschaltet, dann wars das. Dann auch 
außerhalb Meetings endlose Kommentare und Diskussionen, wie man was auf 
dem Backlog anlegt, ob das noch in den Sprint passt, dass "du dafür ja 
nur noch x Tage Zeit hast".

Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in - 
zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc. 
kümmert. Bei einer 8 mann Bude. Weil da keiner für diese belanglosen 
Dinge Zeit hat oder es nicht tun darf? Pervers.

Ich schreibe jetzt Bewerbungen...

von unbunt (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in -
> zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc.
> kümmert.

DAS ist kein Devop, das ist ein Sysadmin.
Devops ist, wenn das gleiche Team Aministration und Entwicklung macht 
(um die Zielkonflikte zwischen Betrieb und Entwicklung zu reduzieren).
Das mit den Bewerbungen klingt allerdings gut, so viel "Bullshit-Bingo" 
und wenig "echtes Umsetzen" da anklingt.

Beitrag #6152523 wurde von einem Moderator gelöscht.
von Festus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Managementmethode Scrum wird heute mit agiler Unternehmensführung 
gleichgesetzt, also einer Art Ideologie des richtigen Führens, in der 
Menschen freier, selbstbestimmter und zufriedener sind.  Wenn man aber 
nach der hintergründigen Wahrheit sucht, dann stößt man schnell darauf, 
was dieses Scrum wirklich ist: eine Managementmethode zur 
Effizienzsteigerung in bester tayloristischer Tradition. Dort wird keine 
Transformation geboren, sondern kleine Projektchen werden effizient 
abgewickelt. Alles andere ist ein attraktiver Anstrich.

von Framulestigo (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der Projektentwicklung 
reine Lotterie war, ob man denn als Kunde das bekommt, was man meint, 
bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen 
Fehler finden.

von Mamuschka (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Framulestigo schrieb:
> Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der
> Projektentwicklung
> reine Lotterie war, ob man denn als Kunde das bekommt, was man meint,
> bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen
> Fehler finden.

Das wird heute dadurch kompensiert, dass SCRUM Projekte 10mal so lange 
dauern wie damals und im Endeffekt das vielfache von vergeigten 
Entwicklungen, die man ggf. mal neu startet, kosten.

von Unfassbar (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
In Zeiten von Corona werden jetzt die fehlenden Teammitglieder, die im 
Homeoffice zu Hause hocken, per Videoschalte in die täglichen Meetings 
zugeschaltet. Unfassbar..

von Carl D. (jcw2)


Bewertung
1 lesenswert
nicht lesenswert
Unfassbar schrieb:
> In Zeiten von Corona werden jetzt die fehlenden Teammitglieder, die im
> Homeoffice zu Hause hocken, per Videoschalte in die täglichen Meetings
> zugeschaltet. Unfassbar..

Na und? Gut so, mein Team ist zu 100% remote und meine Produktivität ist 
erheblich gestiegen, da ich entscheide, ob mich jemand stört. Nur unser 
SCRUM-Master hat Probleme. Langeweile!

Beitrag #6214531 wurde von einem Moderator gelöscht.
von Rainer Zufall (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was bei uns so auffällt... Wo man früher im Wasserfall Servicetöpfe 
hatte bei uns hatte und kleine Dinge immer Mal "einfach so" mitgemacht 
hat, also meist technische Sachen, kommt heute immer nur "müssen wir 
dann Mal mit ins Sprint planning mitnehmen". Da hat der fachlich 
zentrierte Productowner natürlich kein Bock auf technische Themen.. also 
geht das drumherum so langsam aber sicher den Berg herunter. Und man 
lähmt sich wo es nur geht. Man versteckt sich förmlich hinter scrum...

von Qwertz (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Rainer Zufall schrieb:
> Da hat der fachlich zentrierte Productowner natürlich kein Bock auf
> technische Themen..

Dann müsst ihr es ihm beibringen, dass sich das sonst langfristig rächt. 
Dann werden solche Themen auch höher priorisiert.

von Rainer Zufall (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jo... sollte man meinen.... aber die Leute blicken es halt nicht. Ist 
halt wie so eine Aktiengesellschaft. Hauptsache schnelle Rendite - mit 
den langfristigen Problemen können sich dann die nächsten rumschlagen...

Es gibt sogar ein festgelegtes Budget von 20% je Sprint was in Technik 
investiert werden muss. Wird halt nur permanent übersteuert, oder es 
wird irgendein Crap als "das ist doch wohl Technik!" definiert.... man 
schiesst sich halt gerne selber ins Knie.... mir egal. Ich nehme es zum 
Glück nur von außen wahr.

von Carl D. (jcw2)


Bewertung
0 lesenswert
nicht lesenswert
Echte Projektmanager managen unabhängig davon was gerade hipp ist, jedes 
Projekt als <Fortran-Äquivalent in Projektmanagement>.

: Bearbeitet durch User
von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Rainer Zufall schrieb:
> festgelegtes Budget von 20% je Sprint was in Technik investiert werden muss

?
Beispiel?

von Rainer Zufall (Gast)


Bewertung
1 lesenswert
nicht lesenswert
A. S. schrieb:
> ?
> Beispiel

- Update Framework Version
- Optimierungen grundsätzlicher Natur
- einführen neuer Dinge wie zentralisiertes Logging, verbessern 
Monitoring
- erneuern von Dingen wie Authentifizierungsverfahren, 
Laufzeitmonitoring
- Upgrade von Betriebsmodell Application Server auf virtueller Maschine 
vs. Betrieb im Cluster
Usw. Usw. Halt so Dinge neben fachlichen usecases die für den Kunden 
keine direkte Sichtbarkeit haben....

von Robert K. (Firma: Medizintechnik) (robident)


Bewertung
2 lesenswert
nicht lesenswert
PO schrieb:
> - Nach jedem Sprint muss die Software/Hardware ein Stück weiter sein:
> Das Backlog für einen Sprint muss so aufbereitet sein, dass nach dem
> Sprint die Software "ein wenig mehr" an Funktionalität hat, als davor.
> Das ist die Aufgabe vom PO, das sicher zu stellen.

"ein wenig mehr, als zuvor"? Das kann es wohl kaum sein. Mit der 
Mentalität kämst du in der Medizintechnik nicht weit.

Erforderlich sind klare Vorgaben, was zu einem bestimmten Zeitpunkt 
fertig sein soll, denn nur so kannst du abschätzen ob du im Zeitplan 
bist.

Hört sich sehr nach Wursteln an ...

von Unglaublich (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Vor allem muss ich mir immer den Scheiss der anderen Mitglieder ahören, 
der mich überhaupt nicht interessiert und ich auch gar nichts mit 
anfangen kann und der für meine Arbeit auch vollkommen unwichtig ist. 
Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander tauschen 
können, da muss der Raketentechniker auch schon mal eine Uhr 
zusammenbauen 🤣🤣😲🤓

von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Robert K. schrieb:
> Erforderlich sind klare Vorgaben, was zu einem bestimmten Zeitpunkt
> fertig sein soll, denn nur so kannst du abschätzen ob du im Zeitplan
> bist.

Was willst du denn machen, wenn der Kunde selber nicht weiß, was er 
will, braucht und bezahlen kann?

Ich meine: Wer leidet denn nicht darunter wenn alle drei Wochen der 
Vertriebler dazwischenquäkt, daß das ab jetzt alles anders gemacht 
werden muß weil er dem Kunden das so versprochen hat?

von Qwertz (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Unglaublich schrieb:
> Vor allem muss ich mir immer den Scheiss der anderen Mitglieder
> ahören, der mich überhaupt nicht interessiert und ich auch gar nichts
> mit anfangen kann und der für meine Arbeit auch vollkommen unwichtig
> ist. Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander
> tauschen können, da muss der Raketentechniker auch schon mal eine Uhr
> zusammenbauen 🤣🤣😲🤓

Das hängt von der Homogenität des Teams ab, ob das funktioniert. Der 
Gedanke bei Scrum geht wohl tatsächlich in die Richtung, dass jeder im 
Team alles kann, und die Leute im Team ohne Probleme beliebig 
untereinander austauschbar sind. Ich würde aber auch behaupten, dass das 
in der Praxis wohl häufig so nicht funktionieren kann.

Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so 
täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen 
falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben 
müsst, da von oben vorgegeben).

von Wühlhase (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Qwertz schrieb:
> Ich würde aber auch behaupten, dass das
> in der Praxis wohl häufig so nicht funktionieren kann.

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.
Und manchmal sieht jemand anderes ja doch etwas, an das man selber noch 
gar nicht gedacht hat.

Und andersrum finde ich die Probleme anderer oft deutlich einfacher (und 
interessanter) als die meine eigenen. Übrigens ein wichtiger Grund für 
mich, mich in Foren herumzutreiben.

Übrigens völlig unabhängig davon, ob man nach Scrum arbeitet oder nicht. 
Ich habe diese Arbeitsweise immer noch nicht kennengelernt und keine 
Ahnung wie das wirklich zugeht.


Qwertz schrieb:
> Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so
> täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen
> falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben
> müsst, da von oben vorgegeben).

Oder das jemand einfach nicht in ein Team mit zwei oder mehr Mann 
reinpasst. ;)

von M. W. (elektrowagi78) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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? 
Das könnten die Softwareker doch nicht einmal untereinander: Wenn ich 
sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar 
nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten. 
Das ist vollkommen oberflächlich.

Ich kenne die Runden aus Erfahrung und sehe, was bei rumkommt. Viel 
oberflächlich schnell dahin gesagtes.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:
> Wenn ich
> sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar
> nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten

"Eng ist die Welt, und das Gehirn ist weit. Leicht beieinander wohnen 
die Gedanken, doch hart im Raume stoßen sich die Sachen" [Schiller]

das mit den Konzepten wird regelmäßig überbewertet: Klar, wenn ich eine 
abgeschlossene Funktionalität habe (die Funktion sin() z.B.), dann mache 
ich in 10% der Zeit die Beschreibung der Schnittstelle inklusive Tests 
und Doku, und lasse den Programmierer dann machen. Das gleiche gilt für 
viele Web-Anwendungen, HALs oder Treiber. Deshalb setzt man dort zum 
Codieren auch Programmierer ein.

Wenn ich jedoch wirklich etwas neues schaffe, für ein neues Produkt neue 
Features, dann sind Konzepte maximal ein Plan nach Sunzi: "Der Beste 
Plan versagt beim ersten Feindkontakt". Oder modern: Vergiss den Plan, 
Planung ist alles.

Ein echtes SW-Projekt, wo nicht nur Programmierer dransitzen, ist wie 
das Einräumen eines Geschirrspülers oder das Einrichten eines Lagers: 
Ja, man stellt sich das so oder so vor, und am Anfang macht man auch wie 
geplant, doch dann kommen halt Teile in der falschen Größe oder im 
falschen Verhältnis und das hätte man ja alles kommen sehen müssen.

Nein hätte man nicht.

Am Ende räumt man immer mehr wieder um, gruppiert was heute sinnvoll ist 
und wirft einige der besten Ideen über Board, weil sie sich nicht 
bewähren. Und spätestens beim dritten Projekt geht das umso besser, je 
weniger man schon in Beton gegossen hat. Wände, die man schon "für die 
Ewigkeit gebaut und getestet" eingebaut hat, reißt man ungern ein und 
behilft sich lieber mit dubiosen Workarounds.

Das, und genau das ist der Grund für agile Programmierung, egal ob 2 
erfahrene Entwickler in XP mit Verachtung als Prutscher durch Kollegen 
und Chefs, als Scrum oder als ungeliebter Chef, der "immer wieder mit 
Änderungen" kommt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.