Forum: Ausbildung, Studium & Beruf Meeting-Hölle/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 Rudi R. (rudi_r)


Lesenswert?

Ich kam 2008/9 mal in Kontakt mit Scrum... Ich fand das damals nicht in 
Gänze falsch, wenngleich ich damals schon Missstände sah, dass 
beispielsweise für Refaktorierung keine Zeit gelassen wurde, dass keine 
Zeit damit verbracht, grundsätzlich architektonische Entscheidungen zu 
treffen. Ich erinnere mich gut, wie damals 2008/9 ein Entwickler begann, 
2 mal 40 Klassen zu schreiben, die sich nur geringfügig unterschieden 
und es steckte ein System dahinter. Das kann natürlich in jedem anderen 
Entwicklungsmodell auch passieren, aber wenn jeder Entwickler für sich 
erstmal "wurschteln" darf und das Sprint-Ende naht, fördert man 
kurzfristiges denken. Ich habe mich damals hingesetzt und die Sache 
aufgeräumt (also so richtig eingedampft bei gleich bleibender 
Funktionalität) und ich erntete keinen Dank, sondern Unverständnis.

Nun bin ich schon wieder in einer Situation, in der Sprints geplant 
werden und ständig zieht man mich in dämliche Teams-Besprechungen. Ein 
Problem ist auch, dass zwei Entwickler, deren Hintergrund ich nicht 
kenne. sich sehr schwer tun, aber man lässt sie machen. Dass eine eine 
seltsame architektonische Entscheidung von dem einen getroffen wurde, 
sprach ich an. Repariert wurde sie nicht. ich bin ja eigentlich nur 
beratend dabei, weil ich viel Erfahrung habe, generell, mit unseren 
Use-Cases und unseren Frameworks.

Die Arbeit macht mir eigentlich Spaß, bin Informatiker mit Leidenschaft, 
wenn nur diese dämlichen Besprechungen nicht wären und dieses Scrum. 
Scrum kann nicht funktionieren, wenn da alle im Team sind und es 
niemanden gibt, der architektonische Richtungsentscheidungen trifft, was 
er aufgrund seiner Erfahrung und seiner Kompetenz auch tun kann. Ich bin 
Diplom-Informatiker mit 15 Jahren Berufserfahrung und treffe plötzlich 
auf Leute, die gerade frisch mit ihrem Bachelor eingestiegen sind oder - 
noch schlimmer - von einer Coding-School kommen. Da ich ja auch mal als 
junger Dachs angefangen habe, finde ich es gar nicht so schlimm, wenn 
Berufsanfänger erstmal nicht so viel Verantwortung tragen, dass dadurch 
ein Projekt riskiert wird, denn das befürchte ich ja gerade.

Ich finde es schlimm, wenn ich von einem Entwurfsmuster spreche und ich 
in leere Gesichter gucke, weil die das nicht kennen. Ich sehe auch nicht 
mehr, dass jemand UML-Diagramme malt, auf Papier, um eine Idee zu 
durchdenken, zu verfeinern. Mich hat das schon als Student interessiert 
und ich malte für mich diese Diagramme, verwarf natürlich auch häufig 
Ideen. Letztendlich hat es mich reifen lassen.

Bin ich Teamplayer oder bin ich es nicht? Die Menschen wissen, dass sie 
sich auf mich verlassen können, dass ich immer hilfsbereit bin. Das 
sagen sie mir auch, ob im Beruf oder auch außerhalb. Nur geht mir 
Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil 
intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen 
Leuten durchdringen kann. Dann wünsche ich mir häufig, dass diese Leute 
ihr Zeug für Benutzeroberflächen dengeln, wo sie nicht viel falsch 
machen können und wenig mit mir zu tun haben.

Wir geht es mit euch bei diesem Thema? Nutzt ihr auch Scrum? Nerven euch 
auch die Meetings? Ich bin ja Informatiker geworden, weil ich auch eine 
bestimmte Persönlichkeitsstruktur aufweise. Ich kann mich hinsetzen und 
Dinge durchdenken, programmieren... darin kann ich regelrecht aufgehen. 
Oder Probleme analysieren. Gestern konnte ich live ein Problem 
beobachten, weil dem Kunden meine Nummer gegeben hat. Er rief mich an, 
ich schaute es an, erstmals. Ich habe nach 20 Minuten die Problemursache 
verstanden. Das Problem nervt aber täglich seit neun Monaten. Das sind 
die Momente, in denen ich einen Informatiker-Stolz verspüre. Natürlich 
sehen jetzt die Kollegen blöd aus, die nach neun Monaten immer noch 
gesagt haben: So genau wissen wir nicht, wo das Problem liegt. Die haben 
sogar noch Stacktraces dokumentiert, die mit dem Problem gar nichts zu 
tun haben.

Ich befürchte, viel Potenzial geht dadurch verloren, dass Menschen wie 
ich, die einfach nur einer Sache aufgehen wollen, daran durch 
Besprechungen und Sozialtänze abgehalten werden. Meine Kompetenz ist ja 
nicht vom Himmel gefallen, sondern ist das Ergebnis vielen Lesen, Denken 
und Machen. Aber wird das noch goutiert?

Ein Projekt, nur mit mir alleine, das wär's doch.

von Marcel V. (mavin)


Lesenswert?

Nur kurz am Rande, meine Firma hat sich durch mehrfache tägliche 
Meetings und Besprechungsrunden, mit Kaffee und Keksen oder Plätzchen, 
regelrecht zugrunde gerichtet. Ab 2015 "durften" wir dann alle mit einer 
mageren Abfindung zu Hause bleiben.

Aber das nur nebenbei.

von Jan H. (j_hansen)


Lesenswert?

Oh, ein Scrum-Rant - etwas ganz kreatives /s

Nein, Scrum ist nicht schuld, dass das Team kacke ist. Auch nicht, dass 
keine Architekturüberlegungen angestellt, kein Refactoring betrieben 
oder zu viele Meetings abgehalten werden.

Und ja, oft wäre es effizienter, wenn der Experte das alleine 
runtercoden würde. Und schönen, wenn man in einem Team aus lauter 
fachlich interessanten Gesprächspartnern wäre. Mit deiner Erfahrung 
solltest du aber auch wissen, warum das oft nicht geht bzw. auch kacke 
sein kann.

von Michael O. (michael_o)


Lesenswert?

Wenn das Team nicht passt oder nur bremst, sollte man sich ein anderes 
Team suchen, oder nach ein paar versuchen sich ein eigenes suchen oder 
wenn man es gar nicht ertragen kann allein weiter machen. Hab ich vor 30 
Jahren mit angefangen und nie bereut.

MfG
Michael

von Frank E. (Firma: Q3) (qualidat)


Lesenswert?

Man kann natürlich aussen das Etikett "Scrum" draufschreiben (z.B. um 
gegenüber dem Management oder den Aktionären auf den Schlamm zu hauen) 
und innen drinnen Stress und Hektik verbreiten und gegen grundlegende 
Prinzipien verstossen ...

Ich persönlich finde ja den "kleinen Bruder" XP (extreme programming) 
wesentlich besser für die Software-Entwicklung geeignet (z.B. "pair 
programming"). Sehr schön beschrieben in den Büchern von Robert C. 
Martin ("uncle bob", best buddy von Kent Beck: Agiles Manifest).

Nützt nur alles nichts, wenn du keinen Einfluss auf die Abläufe hast. 
Mein Beileid.

von Marcel V. (mavin)


Lesenswert?

Michael O. schrieb:
> Wenn das Team nicht passt

Bei uns hieß es "Du passt nicht ins Team". Dabei genügte es schon wenn 
jemand in der Frühstückspause Gemüsesticks aß, während alle anderen 
lecker Mettbrötchen mit Zwiebeln gegessen haben. Da war das Mobben im 
Wesentlichen schon vorprogrammiert.

Dagegen werden Heute Vegetarier groß geschrieben.

von Steve van de Grens (roehrmond)


Lesenswert?

Scrum wurde den Managern lange Zeit als universelle Lösung zahlreicher 
Mängel beworben, um im Anschluss Schulungen für Scrum durchführen zu 
können. Dadurch wurden falsche Erwartungshaltungen gefördert. Man hat 
versäumt, die Probleme auf konstruktive Art zu lösen.

So habe ich das in zwei Firmen erlebt. In der ersten Firma hat man 
irgendwann aufgehört, Software zu entwickeln (mein Ende dort). In der 
zweiten Firma hat man die Probleme gelöst und konnte mit Scrum weiter 
arbeiten.

Inzwischen arbeite ich quasi in einer dritten Firma agil, nicht nach 
Scrum, und es läuft ebenfalls gut.

: Bearbeitet durch User
von Max (bit8)


Lesenswert?

Wieso schon immer musste man sich austauschen.
Gibt Menschen, die das nicht drauf haben, weil deren Persönlichkeit 
dafür uneingeengt ist.
Also nicht Teamfähig z. B. Menschen mit Persönlichkeitsstörungen, die 
auf andere toxisch wirken, und auch krankhaft sich au andere Menschen 
auswirken.

Solche Patienten sind eindeutig hier im Forum unterwegs.
Solche Typen werden als Einzelkämpfer alleine gelassen oder als Leiter, 
und da hast Du dann ganz schnell das Problem, wenn die leiten, dann 
würden normale Menschen wegrennen...
Andere verbrennen... burnout...

Deshalb ist das schwierig mit solchen Typen zu arbeiten, klar können 
manche von denen auch etwas.
Aber heutzutage gibt es eigentlich gar keine Projekte mehr, die man ohne 
Austausch machen kann.
Ich frage mich, ob es jemals ohne ging, und dieser Mythos vom Kellerkind 
ist auch etwas fragwürdig.

Ich glaube eher, dass das diese genannten Persönlichkeiten nehmen, um 
sich ins Rampenlicht mal wieder zu stellen, um von anderen die 
Leistungen und das Ansehen abzugreifen.

Ja manche "Maßnahmen" sind ganz toll solche Typen zu entlarven und dann 
sollte man auch entsprechend das Projekt kündigen oder die Leute 
fristgerecht an die frische Luft setzen, um die Allgemeinheit zu 
erhalten.

Ich denke mal entsprechende Reaktionen zeigen allen deutlich auf, wo das 
Problem wirklich liegt.

von Michael B. (laberkopp)


Lesenswert?

Scrum ist genial.

Es definiert dass alle Entwickler gleich gut und austauschbar sind.

Es definiert eine Velocity so dass man als Management eine Messlatte für 
ständige Produktivitätssteigerungen hat.

Es überlässt alle Verantwortung dem Team und Kunden, da ist man als 
Management fein taus wenn es wieder mal scheitert.

Es erlaubt es, die Definition dessen was eigentlich implementiert werden 
soll on the fly zusammenzustreichen bis es dem kläglichen Rest 
entspricht, den man trotz aller Meetings mit dem Haufen 
Computerspielzocker von denen kein einziger programmieren kann 
hinbekommen hat, 100% Planerfüllung.

Scrum hat Ähnlichkeit mit dem Hype Lean Produktion, das war die Sau aus 
Japan die man in den 1990er Jahren durch jede Fabrik gejagt hat. Dass 
Japan inzwischen damit zum Entwicklungsland zurückgefallen ist mit 
halben Löhnen wie in Deutschland, na ja, weiss hier ja kein Schwein.

Scrum schafft dasselbe.

von Rudi R. (rudi_r)


Lesenswert?

Frank E. schrieb:
> Man kann natürlich aussen das Etikett "Scrum" draufschreiben (z.B. um
> gegenüber dem Management oder den Aktionären auf den Schlamm zu hauen)
> und innen drinnen Stress und Hektik verbreiten und gegen grundlegende
> Prinzipien verstossen ...
>

Das kann sein und schließe ich auch nicht aus. 2008/9 hatte ich bessere 
Erfahrungen mit Scrum gemacht. Es kann ja auch speziell an den Personen, 
die gerade involviert sind.

> Ich persönlich finde ja den "kleinen Bruder" XP (extreme programming)
> wesentlich besser für die Software-Entwicklung geeignet (z.B. "pair
> programming"). Sehr schön beschrieben in den Büchern von Robert C.
> Martin ("uncle bob", best buddy von Kent Beck: Agiles Manifest).
>

Das Buch "extreme programming" habe ich mir während des Studiums 
gekauft. Ich  müsste es mal wieder lesen, denn nur Pair Programming 
blieb mir in Erinnerung. Tatsächlich wird Pair-Programming nur wenig 
Zeit gegeben, obwohl da ein Greenhorn von einem Erfahrenen, der ich ja 
mittlerweile bin, sehr gut lernen kann. Aber auch nicht alles kann ich 
per Pair-Programming umsetzen, gerade dann, wenn man algorithmisch 
tiefer in einer Materie einsteigen muss. Ich kann im Pair-Programming 
mal zehn Minuten abschweifen und das Beobachter-Muster erklären, das ist 
was architektonisches, aber ich kann nicht mal locker aus der Hüfte das 
große Fass der Graphentheorie aufmachen, Kruskal erklären und erläutern, 
warum unser konkretes Problem zum Problem mit den minimalen Spannbäumen 
passt.

Ich bin auch zu der Überzeugung gelangt dass in höheren Führungsebenen 
die Verantwortlichen gar nicht wissen, dass manchmal auch harte 
algorithmische Nüsse geknackt werden müssen. Die halten alles für 
Architektur und man müsse nur einen Baustein dem anderen hinzufügen. Die 
halten die sehr denklastige und kreative Entwicklerarbeit für 
Fließbandarbeit.

von Bernd G. (Gast)


Lesenswert?

Du diskutierst hier 3 Sachen, die im Grunde nichts miteinander zu tun 
haben, weil eines das andere nicht impliziert:

1) Verhalten von Jungspunten
2) zu viele Meetings
3) schlechtes Schrum


Zu 1) ist zu sagen, daß ich das auch mitbekommen habe: Die Fraktion "Ich 
habe meine Thesis verteidigt" ist darauf getrimmt, alles perfekt 
darzustellen, hat aber nicht kapiert, dass sie nicht viel können und 
noch lernen müssen. Sie sind extrem selbstbewusst, weil sie in ihrem 
schmalen Studium nichts Anspruchsvolles zu tun hatten. Dass sie keine 
Konzepte machen, würde ich aber nicht pauschal auf Jugend schieben. Das 
erlebe ich bei den Erfahrenen auch. Ist eine Frage der Person und 
Einstellung. Konzepte zu machen, ist bei größeren Projekten absolute 
Pflicht, leider hacken die meisten Programmierer nur in den Tag hinein 
und konzeptionieren, während sie Programmieren. Die muss man umerziehen 
oder aussortieren, d.h. nur Aufgaben geben, die sie allein mit sich 
abarbeiten können.

Zu 2): Dass es zu viele Meetings gibt, liegt an der ineffizienten 
Gestaltung von Besprechungen und der mangelnden Vorbereitung: Es wird 
nicht im Vorfeld investiert und damit der Tatsache Rechnung getragen, 
dass dort mehrere die Daumen drehen, beim Zuhören und die Zeit 
verstreicht. Das muss effizient laufen, geht aber nicht, wenn jeder 
unvorbereitet alles aus dem Stehgereif macht. Das aber ist der Fall, 
weil sie von einem Treff zum Nächsten stolpern.

Da deshalb die meetings nicht nachbereitet werden, weil keine Zeit ist, 
verpufft die Wirkung und verbunden mit der Unfähigkeit, Beschlüsse zu 
fassen, werden die Themen weitergeschleppt, und wieder aufgewärmt. Da 
das Folgemeeting aber erst Tage später stattfindet, ist es aus dem 
Kurzeitgedächtnis raus und die Tiefe der Diskussion muss neu aufgebaut 
werden. Damit bleibt es immer flach!

Zu 3) Scrum wird heute überall angewendet und misachtet, daß es nur dann 
funktioniert, wenn alle im Team in etwa dasselbe können und das gleiche 
Knowhow haben. Nur dann macht es Sinn, Aufgaben zu splitten und sich das 
selbständig aufzuteilen und es auch zusammen zu planen. ist das nicht 
der Fall, sollte eine kompetente Person die Planung übernehmen, was aber 
wieder heißt, wie bei Punkt 1 angeführt, Dokumente zu verfassen und 
Konzepte zu machen.

Ich sehe aber das Gegenteil: Die Entwickler treffen sich in einem großen 
Team, nennen es Scrum, es macht aber jeder was anderes und sie können 
sich weder gegenseitig helfen, noch den anderen verplanen. Auch da 
spielt es eine Rolle, wie transparent ein Entwickler arbeitet. Wenn du 
nicht weißt, welches Konzept seine SW verfolgt, kannst du auch nicht 
eingreifen oder beihelfen.

Scrum wird einfach in vielen Firmen völlig falsch angewendet.

von Bernd G. (Gast)


Lesenswert?

Michael B. schrieb:
> Es definiert dass alle Entwickler gleich gut und austauschbar sind.

Da liegt der Hase im Pfeffer: Das ist nur selten der Fall!

Es gibt 2 unterschiedlich gelagerte Aufgabenpaletten:

1) Forschende und anspruchsvolle sowie breit gefächerte Themen, z.B. die 
Entwicklung eines neuartigen Geräts mit HW, SW, Mechanik und Software 
für Datenprozessierung

2) Umsetzende und begrenzt anspruchsvolle, schmal gefächrte Themen in 
jeweils einem Teilgebiet, wo es auf Effizienz ankommt.

In Abteilung 1 brauchst Du breit aufgestellte Leute, die sich stark 
ergänzen und damit die Breite und Tiefe schaffen. Die müssen flexibel 
und dynamisch sein. Diese Abteilungen wirken durch Qualität / Kosten. Im 
Extremfall kann jeder Experte etwas anderes.

In Abteilung 2 brauchst Du Leute mit konzentriertem Wissen und 
eingeübten Methoden, die sehr präzise ihre Aufgaben erledigen, um das 
Tempo und die Termine zu schaffen. Diese Abteilungen wirken durch 
Quantität / Kosten. Im Extremfall können alle dasselbe.

Nur in der Abteilung 2 macht Scrum mit selbständiger Aufgabenvergabe und 
Umverteilung der Tätigkeiten Sinn. Dort kannst Du Teilaufgaben so 
verteilen, wie threads auf einem MultiCore-Prozessor.

Je mehr eine Firma forscht, neues entwickelt und breit aufgestellte 
Leute hat, desto weniger macht Scrum Sinn. Scrum ist am Besten für 
Zulieferbetriebe und Abteilungen geeignet, die z.B. nur Software für 
MCUs machen oder sich ums Linux kümmern. Auch Software für IT- und 
Serverlösungen kann man so managen.

Wenn aber eine Kleinfirma oder Entwicklungsabteilung aus 10 Leuten 
besteht, wo 2 Mechanik, 2 Elektronik, 2 die firmware und 2 das Linux 
machen und die restlichen beiden PM - dann kriegst du da kein Scum rein. 
Wie auch?

von ArnoNym (bergler)


Lesenswert?

Es gibt einfach Tätigkeiten, die man gut in kleine Teilchen 
zerschnippeln kann, und solche, wo man es besser lässt.
Hardware ist meist letzteres, ausßer sie besteht aus irgendwelchen 
Modulen.

Eine komplexe Platine sollte man z.B. nicht in kleine Teilbereiche 
zerschnippeln und welchselweise unterschiedliche Mitarbeiter machen 
lassen, weil dann die Blöcke nicht aufeinander abgestimmt sind. Was bei 
Hardware aber zentral ist.
Und wenn nicht der gleiche Entwickler die Inbetriebnahme braucht, dauert 
alles viel länger, weil sich die anderen erst mal einlesen müssen.

Außerdem brauchts jemanden der sich ein stimmiges Gesamtkonzept 
einsetzt. Und dieses pseudo-Scrum das die Firmen gern verwenden, tötet 
oft jede Motivation, sich persönlich für irgendwas zuständig zu fühlen.

Ich musste scho so arbeiten, beim letzten Arbeitgeber. Scrum hat man 
dort so verstanden, dass die Mitarbeiter den sich immer schneller 
ändernden Anforderungen agil wie Rehlein hinterherspringen.

Seit man das so handhabt, kamen eine Menge teurer Prototypen heraus, 
aber das Projekt hate bei meinem Weggang schon 2 Jahre Verzögerung. 
Übrigens nicht wegen der Elektronik. Die Lieferanten und die Fertigung 
sind immer noch keine "springenden Rehlein" und haben - huch - 
Lieferzeiten.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

[OT]

Bernd schrieb:
> aus dem Stehgereif
Nur, weil mir dieses so oft verwendete und fast genauso oft falsch 
geschriebene Wort fast das Auge auskratzt: "aus dem Stegreif" 
verkündeten die berittenen Boten der Herrschenden relativ unwichtige 
Botschaften. Für diese Botschaften lohnte es sich nicht mal, extra vom 
Pferd abzusteigen.

- 
https://www.geo.de/geolino/redewendungen/8166-rtkl-redewendung-aus-dem-stegreif
- https://www.google.com/search?q=aus+dem+stegreif+machen+redewendung
- https://gfds.de/aus-dem-stehgreif/
- https://de.wikipedia.org/wiki/Stegreif

[/OT]

: Bearbeitet durch Moderator
von Max B. (citgo)


Lesenswert?

Na Lothar, du zeigst aber Rückrad mit deinem Post.
Solche Fehler sind doch Gang und Gebe. Denke ich. Also meine ich. Vom 
höheren sagen. Wer zu erst kommt, malt zu erst! :)

Btw. Rudi R. ist wieder da!

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Lothar M. schrieb:
> Nur, weil mir dieses so oft verwendete und fast genauso oft falsch
> geschriebene Wort fast das Auge auskratzt

Du musst mal ein bisschen tollleranter sein, Der Mensch ist doch keine 
Maschiiene, die sich immer nur an Stantarts haelt ;-)

scnr,
WK

von Marcel V. (mavin)


Lesenswert?

Da sind ja gleich 4 Fehler auf einmal drin:

Statt Rückrad, Gebe, höheren und malt

Lautet es: Rückgrat, Gäbe, hören und mahlt

Das klingt ja sonst so, als wenn bei der Ankunft, noch auf die Schnelle 
hektisch ein Bild gemalt werden muss.

von Max B. (citgo)


Lesenswert?

Marcel V. schrieb:
> Da sind ja gleich 4 Fehler auf einmal drin:
>

Ach? Ja sowas.
Ich hätte meinen Beitrag vielleicht in Ironie-tags setzen sollen.

von Marcel V. (mavin)


Lesenswert?

Max B. schrieb:
> Ach? Ja sowas.

Ja, spätestens bei Maschine und Standard habe ich es jetzt auch gemerkt.

von Le X. (lex_91)


Lesenswert?

Marcel V. schrieb:
> Da sind ja gleich 4 Fehler auf einmal drin:

Kriegst du für die Fehlersuche wenigstens ein Endgeld?

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Le X. schrieb:
> Endgeld?
Oder schlimmer noch: das allseits beliebte Entgeld.

Aber lasst mal stecken: ich schrieb doch, dass das OT ist!
Lassen wir die Scrummer wieder zum wohlverdienten Wort kommen.

: Bearbeitet durch Moderator
von Bernd G. (Gast)


Lesenswert?

Lothar M. schrieb:
> Lassen wir die Scrummer wieder zum wohlverdienten Wort kommen.

Gerne, dann schreibe ich noch einen Punkt dazu:

Ich kann mich nicht erinnern, wo es hier von wem verfasst wurde, aber es 
gab schon eine Diskussion um Scrum, dem man eine interessante 
Information entnehmen konnte:

Scrum ist bereits >20 Jahre alt und die Personen, die es entwickelt 
haben, taten dies aus ihrer Erfahrung heraus, die sie in ihrer Karriere 
mit Firmen und Entwicklern sowie Software-Prozessen und -Anforderungen 
gesammelt hatten. D.h. Die Gründe, sich Scrum auszudenken, beziehen sich 
Strukturen, die sie in den 1990er-2000er Jahren kennengelernt haben!

Konkret waren das schwerpunktmäßig die Entwicklungs-Strukturen in den 
US-amerikanischen und japanischen Firmen Mitte der 1990er! Die dort 
tätigen Entwickler hatten wiederum ein Ausbildungsniveau der 
1980er-1990er Jahre und hatten mit völlig anderen Problemen bei der 
SW-Erstellung zu tun. ES gab völlig andere Probleme, andere SW und 
andere Tools.

Jetzt tut man Folgendes:

1) Man verwendet eine Sache, die sich auf 1980er Bildungsniveau bezieht, 
auf Personen, die heute schwerpunktmäßig zwischen 25 und 35 sind, also 
zwischen 2000 und 2010 ausgebildet sind, so als habe sich in 30 Jahren 
nichts geändert. In den frühen Jahren der SW-Entwicklung gab es 
praktisch keine Informatikausbildung. Das waren alles Selbstlerner. Die 
meisten SW-Entwickler hatten das nicht gelernt und waren fachfremd.

2) Man wendet es auf Personen des deutschen und europäischen 
Bildungssystems an, dass sich trotz Bologna noch stark vom 
US-amerikanischen und speziell dem japanischen System unterscheidet. In 
Japan studieren die meisten Studenten irgendwas und in beiden Ländern 
ist die Ausbildung kürzer. Das ist auf DE nicht einfach so zu 
übertragen.

3) Man verwendet es auch außerhalb der Software und das ist aber 
unrichtig. Zwar sind auch hierzulande auch heute noch viele 
Programmierer fachfremde Quereinsteiger ohne Hintergrundausbildung, das 
ist in der Hardware aber nicht so. Elektro und Mechanikkontrukteure 
haben fachorientiert gelernt und studiert.

Man tut also so, als ob das, was einst woanders, in einer anderen Zeit 
für andere Personen galt, nun für alle und jeden in jeder Firmen gelten 
müsse.

Das ist nicht nur unlogisch, sondern auch gefährlich, weil es vorhandene 
- oft bessere - Strukturen zerstört und behindert. Es wird die 
Individualität untergraben und einer Gleichmacherei untergeordnet.

Wer ungeprüft und unreflektiert überall Srum auf jeden anwendet, fördert 
den Niedergang des ehemaligen guten deutschen Standards hin zu einem 
weltweiten Mittelmaß. Bologna war der erste Schritt dahin und Scrum ist 
der Sargnagel.

von Torsten R. (Firma: Torrox.de) (torstenrobitzki)


Lesenswert?

Marcel V. schrieb:

> Dagegen werden Heute Vegetarier groß geschrieben.

Vegetarier wurde schon immer groß geschrieben!

von Reinhard S. (rezz)


Lesenswert?

Rudi R. schrieb:
> ich bin ja eigentlich nur beratend dabei,
> (…)
> wenn nur diese dämlichen Besprechungen nicht wären

Dämliche Besprechungen gibts auch außerhalb von Scrum und wenn du nur 
beratend dabei bist ist sowas doch genau dein Jobprofil? Also lieber mal 
die Position wechseln.

> Nur geht mir
> Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil
> intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen
> Leuten durchdringen kann.

Was hat das mit Scrum zu tun?

Klassischer Freitags-Troll.

von Michael B. (laberkopp)


Lesenswert?

Torsten R. schrieb:
> Marcel V. schrieb:
>> Dagegen werden Heute Vegetarier groß geschrieben.
>
> Vegetarier wurde schon immer groß geschrieben!

Heute jedoch nicht.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Michael B. schrieb:
> Heute jedoch nicht.
Aber am Satzanfang doch.

von Cyblord -. (cyblord)


Lesenswert?

Bernd schrieb:
> 3) schlechtes Schrum

Das ist wie mit dem Kommunismus. Er ist überall gescheitert. Aber 
natürlich nicht weil er schlecht ist. Er wurde immer nur schlecht 
umgesetzt.

von Oliver S. (oliverso)


Lesenswert?

Bernd schrieb:
> Das ist nicht nur unlogisch, sondern auch gefährlich, weil es vorhandene
> - oft bessere - Strukturen zerstört und behindert.

Ja, insbesondere die deutsche Softwareindustrie ist von unerreichtem 
Weltruhm, und hat sich schon immer durch extreme Innovationskraft und 
vor allem Ausführungsgeschwindigkeit hervorgetan. Die vielen Beispiele 
grandios gescheiterter Großprojekte sind legendär...

Oliver

von Marcel V. (mavin)


Lesenswert?

Michael B. schrieb:
> Heute jedoch nicht.

Auch heute werden Vegetarier immer noch groß geschrieben, genau wie 
damals. Nur damals waren die Vegetarier noch nicht in der Überzahl. Das 
ist damit gemeint.

von Michael B. (laberkopp)


Lesenswert?

Marcel V. schrieb:
> Das ist damit gemeint.

Ach.

von Rudi R. (rudi_r)


Lesenswert?

Bernd schrieb:
> Zu 1) ist zu sagen, daß ich das auch mitbekommen habe: Die Fraktion "Ich
> habe meine Thesis verteidigt" ist darauf getrimmt, alles perfekt
> darzustellen, hat aber nicht kapiert, dass sie nicht viel können und
> noch lernen müssen. Sie sind extrem selbstbewusst

Die Leute, mit denen ich gerade zu tun habe, sind gar nicht mehr so 
jung. Ich kann leider auch nicht deutsch mit ihnen reden und bestimmte 
Dinge kann ich schlecht abschätzen. Ich weiß ja, was ein deutschen 
Curriculum beinhaltet, aber die kommen vielleicht nur von einer 
Coding-School oder so ein Blödsinn.

Bei der einen Entwicklerin steht auf LinkedIn geschrieben, bei ihr 
gehöre Hibernate zum Skillset. Aber wie viel? Ich erlebte dann, wie sie 
statt Standard-Hibernate zu werden, selber SQL-Create-Statements in Java 
hinterlegte. Und das scheint mir auch ein kulturelles Problem, dass in 
anderen Kulturen kräftig geklappert wird, speziell die Amerikaner. Wir 
hatten mal einen im Projekt, der wirklich nichts konnte, dem wir auch 
noch verboten, überhaupt noch Code hinzuzufügen. Der haut aber bei 
LinkedIn auch mächtig auf den Putz und hat 'ne "Direktorenposition". 
Keine Ahnung, wie sowas geht.

> Das
> erlebe ich bei den Erfahrenen auch. Ist eine Frage der Person und
> Einstellung. Konzepte zu machen, ist bei größeren Projekten absolute
> Pflicht, leider hacken die meisten Programmierer nur in den Tag hinein
> und konzeptionieren, während sie Programmieren.

Da stimme ich zu. Zu mir kommen junge wie alte Entwickler, die mich um 
Hilfe bitten. Dann geht es sofort in den Source-Code. Hinweise, doch mal 
ein paar UML-Zeichnungen anzufertigen und vor allem 
Zustandsüberführungsmodelle, aber besten, bevor sie anfangen, zu 
programmieren, werden ignoriert. Seltsam. Mich kotzt diese Ignoranz an.

> Die muss man umerziehen
> oder aussortieren, d.h. nur Aufgaben geben, die sie allein mit sich
> abarbeiten können.
>

Leider nicht immer möglich.

> Zu 2): Dass es zu viele Meetings gibt, liegt an der ineffizienten
> Gestaltung von Besprechungen und der mangelnden Vorbereitung: Es wird
> nicht im Vorfeld investiert und damit der Tatsache Rechnung getragen,
> dass dort mehrere die Daumen drehen, beim Zuhören und die Zeit
> verstreicht. Das muss effizient laufen, geht aber nicht, wenn jeder
> unvorbereitet alles aus dem Stehgereif macht. Das aber ist der Fall,
> weil sie von einem Treff zum Nächsten stolpern.

Das ist richtig. Ich ließ aber offen, ob das mit Scrum zu tun hat oder 
nicht.

>
> Da deshalb die meetings nicht nachbereitet werden, weil keine Zeit ist,
> verpufft die Wirkung und verbunden mit der Unfähigkeit, Beschlüsse zu
> fassen, werden die Themen weitergeschleppt, und wieder aufgewärmt. Da
> das Folgemeeting aber erst Tage später stattfindet, ist es aus dem
> Kurzeitgedächtnis raus und die Tiefe der Diskussion muss neu aufgebaut
> werden. Damit bleibt es immer flach!
>

Die Meeting-Kultur finde ich generell ganz schlimm. Man wird regelrecht 
überfallen. Ich halte es für falsch, eine Entscheidung treffen zu 
müssen. Ich bin ein denkender Mensch, der auf Papier Pro und Kontra 
gegenüberstellt, Konzepte entwirft und verwirft. Ich sehe es bei anderen 
nicht.

> Zu 3) Scrum wird heute überall angewendet und misachtet, daß es nur dann
> funktioniert, wenn alle im Team in etwa dasselbe können und das gleiche
> Knowhow haben.

Ich denke, Scrum macht es bestimmten Leuten besonders leicht, sich 
hinter einem Team zu verstecken. Ich schrieb ja, dass 2008/9 Scrum 
halbwegs funktioniert hat, es sogar zeitweilig Spaß machte. Das lag 
daran, weil unsere Kompetenzen nicht weit auseinandergingen und weil die 
Anwendung simpler war. Das aktuelle Projekt aber erfordert sehr viele 
unterschiedliche Kompetenzen innerhalb der Softwareentwicklung in einer 
komplexen Domäne. Ich bin ja selbst aufgeschmissen, wenn ich dann 
gefragt werden, wie etwas ganz speziell bei uns im Dialog-Framework 
umzusetzen ist. Hinzu kommt, dass die Entwickler auch noch wie Glucken 
auf dem Source-Code sitzen, anstatt viele kleine Commits zu pushen, 
damit jeder Entwickler im Code des anderen stöbern kann.

> Nur dann macht es Sinn, Aufgaben zu splitten und sich das
> selbständig aufzuteilen und es auch zusammen zu planen. ist das nicht
> der Fall, sollte eine kompetente Person die Planung übernehmen, was aber
> wieder heißt, wie bei Punkt 1 angeführt, Dokumente zu verfassen und
> Konzepte zu machen.
>

So ist es. Bei uns ist es so, dass ich mehr als zehn Jahre in der Firma 
bin und die anderen in Summe nicht mal auf sechs Jahre kommen. Ich bin 
erst später hinzugekommen.

> Ich sehe aber das Gegenteil: Die Entwickler treffen sich in einem großen
> Team, nennen es Scrum, es macht aber jeder was anderes und sie können
> sich weder gegenseitig helfen, noch den anderen verplanen. Auch da
> spielt es eine Rolle, wie transparent ein Entwickler arbeitet. Wenn du
> nicht weißt, welches Konzept seine SW verfolgt, kannst du auch nicht
> eingreifen oder beihelfen.
>
> Scrum wird einfach in vielen Firmen völlig falsch angewendet.

Das kann auch sein. Es wird ohnehin vieles falsch angewendet. Ich habe 
mal in Privatprojekten test-driven programmiert (TDD). Ich fand die Idee 
gut, finde sie immer noch gut. Ich schreibe erst den Test und dann die 
dazugehörige zu testende Einheit. Die Folge davon ist, dass die 
Schnittstellen recht gut sind, denn was sich in einem Modultest anwenden 
lässt, ist auch in einem Dialog oder auf einem Server aufrufbar. Ich 
kenne Entwickler, die haben es noch nie ausprobiert, gucken mich an, als 
hätte ich sie auf ihre Lieblingsstellung angesprochen. Die entwickeln 
oft den Dialog und dann die Logik dahinter. Und dann ist mühsam zu 
testen.

Ich erinnere mich, wie ich vor elf, zwölf Jahren mal eine Schnittstelle 
zu einem Fremdsystem programmieren musste. Wir kommunizierten über 
Datenbanktabellen. Ich habe das recht schnell programmiert, schöne Tests 
geschrieben, weit über 80. Dabei unter Anwendung des TestRunners 
Parameterized, welchen viele Kollegen bis heute nicht kennen oder erst 
in den letzten vier Jahren begonnen haben, einzusetzen. (Es ist so 
traurig.) Die Tests liefen ruckzuck ab, weil ich den Seiteneffekt, das 
Schreiben in die Datenbank und das Lesen daraus, nicht ständig abtesten 
wollte. Denn das kostet Zeit. Entscheidend ist, dass unsere 
Empfangsseite mit den Objekten das richtig macht und die richtigen 
Objekte erstellt. Es funktioniert alles bis auf eine Definitionslücke: 
Darf man Bestellungen haben, wo jemand von Art A die Menge 0 bestellt? 
War leider nie spezifiert, ob > 0 oder >= 0. Also banal. Ein Kollege 
übernahm und er war nicht zufrieden und was machte er? Schrieb weitere 
Tests, die auch wirklich persistierten. Dann liefen die über 80 Sekunden 
nicht unter 10 Sekunden ab, sondern brauchten mehrere Minuten. Die guten 
Schnittstellen wurden da auch noch aufgeweicht.

Ich glaube, ich wiederhole mich. Es kann natürlich sein, dass bei uns 
ein "Pseudo-Scrum" umgesetzt wird und es machen nicht alle 
Niederlassungen. Was sich bei mir äußerst, ist in weiten Teilen ein 
Kulturpessimismus. Mir wird von Kollegen auch gesagt, dass Scrum gar 
nicht zu der Art Software passe, die wir programmieren. Agile Methoden 
halte ich nicht für falsch. Ich habe damals mit Begeisterung das Buch 
von Kent Beck gelesen. Das Wasserfallmodell habe ich immer schon für 
Unsinn gehalten. Es wurde doch mal entwickelt, um aufzuzeigen, wie 
Softwareentwicklung auf keinen Fall funktioniert. Ich finde bei Design 
und Planung iterative Herangehensweise sehr sinnvoll und ich gehe auch 
iterativ vor.  Ich fange grob an, liefere Grundfunktionalitäten, so, 
dass die Kollegen, die von von meiner Arbeit abhängig sind, auch schon 
mal anfangen können. Es gibt Kollegen und auch Vorgesetzte, die mich zu 
einer sehr frühen Zeit im Projekt was sehr, sehr spezielle fragen und ob 
ich mir darüber Gedanken gemacht hätte. Ich bin dann ganz offen und 
sage, wo es grob hingeht, aber Details könne und dürfe ich nicht nennen, 
denn es wäre angesichts vieler anderer Aufgaben, einfach noch nicht 
dran.

Ein Beispiel: Man kann in Interface Guide-Lines sehr früh festlegen, wie 
Buttons angeordnet werden, dass der OK-Button immer links, der 
Abbrechen-Button immer rechts steht, wo der Nein-Button ist. Das ist 
vernünftig. Es ist aber schwachsinnig, sehr früh festzulegen, welche 
drei Buttons in einem ganz speziellen Dialog überhaupt da sein müssen. 
Das ist zu konkret.

Wenn ich mir die "agilen Leitsätze" anschaue, dann fehlt da eine Menge, 
die ich bei Scrum nicht sehe, bzw. bei dem, was sich bei mir als  Crum 
gebärdet:

"Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge" 
- Ich habe das Gefühl, dass der Sprint und das Sprintende das 
wichtigste. Hauptsache, alles ist fertig, der Sprint ist abgeschlossen. 
Schlimm. Individuen spielen keine Rolle. Ich bin bislang überall nur auf 
Widerstand gestoßen, wenn ich mal vorschlug, dass die Leute einfach mal 
Buch zur Hand nehmen, sich in etwas einarbeiten und damit spielen. Vor 
ein paar Jahren arbeitete ich das Buch "Functional Programming in Scala" 
durch. Damit verbrachte ich meinen Feierabend. Ich habe mich da sehr 
schön vertieft und auch etwas rausgenommen, selbst wenn ich Scala in der 
Praxis nicht anwende. Die Kollegen, mit denen ich tun hatte, winkten ab. 
Bloß keine Bücher, bloß nichts lernen. Ein Fehler unserer Bildung und 
Ausbildung ist wohl, dass das zweckfreie Agieren verpönt ist. Es wird 
sich nur in etwas eingearbeitet, wenn ein ganz konkreter Zweck sichtbar 
ist. Arbeitgeber lassen das ja auch nicht zu. Wenn nichts zu tun war, 
hätte ich immer noch Ärger bekommen, wenn ich während der Arbeitszeit 
was anderes gemacht hätte. (Ich habe mir die Zeit einfach genommen.)

"Funktionierende Software ist wichtiger als umfassende Dokumentationen" 
- Dokumentiert wird wenig, daher ist das "bei mir" erfüllt. Aber die 
Software funktioniert nicht und wenn, allenfalls schlecht.

"Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert 
Agilität." - Da möchte man doch glatt Thomas Doll zitieren. Design geht 
ja bei uns leider den Bach runter. Ich bekomme in Code-Reviews 
angemecket, ich hätte alten Code nur auskommentiert und nicht gelöscht, 
während meine Reviews, wo ich anmahne, Konstruktoren mit 20 primitiven 
Argumenten seine eine gefährliche Stolperfalle für jeden Entwickler und 
müssten daher ersetzt werden, wirkungslos verpuffen.

Vielen Dank übrigens für die Diskussion hier. Ich bin kein Troll, nur 
weil ich es so aussieht, ob hier jemand nur Dampf ablässt. Ich würde 
sonst platzen, wenn ich mich nicht dazu äußern würde und das wäre nicht 
gesund. Ich bin auch kein Experte für Vorgehensmodelle, mit dem Fokus 
auf dem Team. Mich interessierte sowas nie so sehr, weil ich es nicht 
organisieren will, sondern lieber selbst immer entwickeln wollte. Und da 
interessieren mich eher die Vorgehensmodelle, die sich auf den Code 
beziehen, wie TDD.

von Steve van de Grens (roehrmond)


Lesenswert?

Rudi R. schrieb:
> Ich würde sonst platzen, wenn ich mich nicht dazu äußern würde

Das merkt man :-)

von Marcel V. (mavin)


Lesenswert?

Rudi R. schrieb:
> Ich würde sonst platzen, wenn ich mich nicht dazu äußern würde und das
> wäre nicht gesund.

Steve van de Grens schrieb:
> Das merkt man :-)

Ich habe mir den ellenlangen Text zwar nicht zu Gemüte geführt, aber 
schon beim runterscrollen wird sofort sichtbar, dass zu dieser Thematik 
massiver Gesprächsbedarf herrscht.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Geh' mal raus an die frische Luft, mach nen Spaziergang und iss mal 
einen Apfel.

scnr,
WK

von Christoph Z. (christophz)


Lesenswert?

Dergute W. schrieb:
> Geh' mal raus an die frische Luft, mach nen Spaziergang und iss mal
> einen Apfel.

Nee, das reicht hier bei weitem nicht.

Michael O. schrieb:
> Wenn das Team nicht passt oder nur bremst, sollte man sich ein anderes
> Team suchen, oder nach ein paar versuchen sich ein eigenes suchen oder
> wenn man es gar nicht ertragen kann allein weiter machen. Hab ich vor 30
> Jahren mit angefangen und nie bereut.

Genau. Das weite Suchen.

von Bernd G. (Gast)


Lesenswert?

Christoph Z. schrieb:
> Genau. Das weite Suchen.
Das ist nicht so einfach, wenn so viele Firmen scrum-verseucht sind. Das 
ist ein Riesenhype, wie eine Flutwelle, der man sich nicht 
entgegenstellen und der man nicht entkommen kann.

Marcel V. schrieb:
> dass zu dieser Thematik
> massiver Gesprächsbedarf herrscht.
Sehe ich ebenso!

Problem: SCRUM ist eine heilige Kuh! Es ist in den Hirnen fest 
eingebrannt wie die Wehrpflicht und "unsere" 5-Jahres-Pläne in der DDR 
samt ihrer dämlichen Pro-Argumente! Und obwohl jeder wusste und spürte, 
dass es falsch läuft und unsinnig ist, plappert ein jeder die 
vorgegebene mainstream Haltung nach! Wenn du nur etwas dagegen gesagt 
hast, warst du ein Systemgegner!

Ok, DDR und die Wehrplicht sind weg. Aber Scrum ist noch da. Warten wir 
also. Es dauert wahrscheinlich auch weitere 10-20 Jahre, bevor der Spuk 
vorüber ist. Solange werden wir mit dem Hype noch zu kämpfen haben. Es 
ist ja auch ein gutes Geschäft für die Dampfplauderer aka Scrum Master. 
Du musst im Kontext fast nichts können, sondern nur JIRA-Tasks und bunte 
Zettel verwalten.

Ach ja: Kennt wer noch "KANBAN" und "KAIZEN"? Das war vor 30 Jahren DER 
Hit! Super neu und super geil!  Alles, was aus dem fernen Japan kam, 
wurde blindwütig übernommen. Vor etwa 20 Jahren hatte KANBAN seinen 
Höhepunkt in Deutschland. Danach merkten einige, dass es für deutsche 
Produktionslandschaften nicht unbedingt optimal ist und eigentlich dafür 
gedacht war, die japanische Verschwendungswirtschaft zu entmüllen, die 
dadurch entstand, dass sich niemand verantwortlich zeigt und 
Entscheidungen seines Chefs abändert. Heute kennt das hierzulande keine 
Sau mehr!

"Wir" Deutschen leiden an einer Krankheit: Wir müssen immer das nehmen, 
was von außen kommt. Seien es Pommes, Jeans und Cola oder eben 
Ami-Methoden. Würde man aber genauer hinsehen, was die Ursachen für die 
Einführung der Methoden waren, unterbliebe Vieles.

von Kara B. (Firma: ...) (karabenemsi)


Lesenswert?

Bernie schrieb:
> Seien es Pommes, Jeans

Pommes kömmen übrigens aus Belgien:

https://de.wikipedia.org/wiki/Pommes_frites

Und was jetzt Schlimmes an Jeans ist, weißt nur du alleine.

Bernie schrieb:
> und Entscheidungen seines Chefs abändert.

Du hast offenbar noch nie mit Asiaten speziell aus China, Korea oder 
Japan zu tun gehabt. Da gilt das Senioritätsprinzip bis zum Exzess. Da 
ändert niemadn die Entscheidung des Chefs ab.

Aber Hauptsache die eigenen Vorurteile gepflegt, gelle.

: Bearbeitet durch User
von Huebi H. (huebi)


Lesenswert?

Kanban ist ein schönes Stichwort. Ich benutze das in etwa so wie Postits 
mit allen Aufgaben und Unteraufgaben drauf. Wenn ich zu einem Punkt eine 
gute Idee habe, arbeite ich ihn einfach ab. In kleinen Teams 
funktioniert das richtig klasse, ersetzt, wie auch Scrum, aber nicht die 
Kommunikation im Team.

Große Meetings bleiben kurz und knackig wenn vorher mit allen 
Beteiligten die Details schon geklärt sind, alle Bescheid wissen, und 
nur noch das Ergebnis verkündet wird.
Die Kaffeeküche ist für mich der kreativste Raum im Büro. Dort kommt 
soviel Information auch und besonders aus unerwarteten Ecken zusammen, 
dass die Effizienz in der Entwicklung unvorstellbar steigen kann.

von Bernd G. (Gast)


Lesenswert?

Kara B. schrieb:
> Du hast offenbar noch nie mit Asiaten
Doch, sehr wohl, Ich habe schon in Japan gearbeitet. Du kannst nur nicht 
richtig lesen:

Kara B. schrieb:
> Da gilt das Senioritätsprinzip bis zum Exzess. Da
> ändert niemadn die Entscheidung des Chefs ab.
Das war doch die Aussage! (?)

Der Chef entscheidet runter und drückt jeden Fehler ins System. Da 
niemand rund gemacht werden will, akzeptiert er alles und korrigiert 
nichts. Damit es funktioniert, wird nochmal parallel gearbeitet, 
bestellt und gebaut. Daher brauchte Japan ein System, in "dem nur 
bestellt und gebaut wird, was auch benötig wird".

Hierzulande herrschen völlig andere Mechanismen.

von Bruno V. (bruno_v)


Lesenswert?

Bernie schrieb:
> . Die meisten SW-Entwickler hatten das nicht gelernt und waren
> fachfremd.

Ich hab dazu keine Zahlen (nur eine Meinung 😄): in der Zeit gab es 
vermutlich deutlich weniger Stellen so dass der Nerd -Anteil (mit 
durchcodeten Nächten) und der Durchdringung in die Tiefe relativ hoch 
war.

Heute studieren Leute Informatik, die weder Lust noch Erfahrung damit 
haben.

Insgesamt gibt es natürlich wesentlich mehr brillante SW-Entwickler 
heute. Relativ (also auf n SW-Entwickler in einer Firma bezogen) bin ich 
mir da nicht sicher. Und bei N Frameworks und Aufgaben ist es vermutlich 
auch kaum einfacher zu erkennen, ob jemand ein Verständnis von Codierung 
hat

von Steve van de Grens (roehrmond)


Lesenswert?


von Reinhard S. (rezz)


Lesenswert?

Bernie schrieb:
> Christoph Z. schrieb:
>> Genau. Das weite Suchen.
> Das ist nicht so einfach, wenn so viele Firmen scrum-verseucht sind. Das
> ist ein Riesenhype, wie eine Flutwelle, der man sich nicht
> entgegenstellen und der man nicht entkommen kann.

Hättest halt mal was ordentliches gelernt :)

> Problem: SCRUM ist eine heilige Kuh! Es ist in den Hirnen fest
> eingebrannt

SCRUM kam und geht, genau wie StudiVZ und Facebook.

Steve van de Grens schrieb:
> Ist der Artikel Zufall?
> https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.html

Golemao.

von Max (bit8)


Lesenswert?

Der Traumjob für euch 80% Meeting 10 % coden 10 % auf die Kollegen 
koten...

Ich glaub es passt über ein im Meeting dann poppeln ...

Mein Traumjob ich code den ganzen Tag meine skills im social sector A.
Den Traum haben sich hier einige Frührentner und Sozialamtbezieher 
erfüll, sind dann noch so dreist im Xing Probil eine Firma anzugeben, 
die seit 30 13 Jahren durch ihre Mitarbeit zu Robert H. Eigentum 
übergangen ist.

Und heute poppeln sie im Forum mit unbefugten Wissen rum.

Kennen Sie John Dumbo ? Der war in der Scrum Meeting Hölle 65 bis 75 
Minuten um Stück, heute hat es den Kaffelöffel mit Auszeichnung für die 
kurzen Kaffeepausen.

Sein Quellcode finden sie täglich im WC -> Klo um 9:12:34...

von Steve van de Grens (roehrmond)


Lesenswert?

Jetzt hat mir auch noch der Hanser Verlag eine SPAM Mail für ein SCRUM 
Buch geschickt. Langsam wird es gruselig. Merken die nicht, dass der 
alte Gaul längst tot geritten wurde?

: Bearbeitet durch User
von Rudi R. (rudi_r)


Lesenswert?

Bruno V. schrieb:
> Bernie schrieb:
>> . Die meisten SW-Entwickler hatten das nicht gelernt und waren
>> fachfremd.
>
> Ich hab dazu keine Zahlen (nur eine Meinung 😄): in der Zeit gab es
> vermutlich deutlich weniger Stellen so dass der Nerd -Anteil (mit
> durchcodeten Nächten) und der Durchdringung in die Tiefe relativ hoch
> war.
>

Ich habe in letzter Zeit öfter darüber nachgedacht. Was war früher 
anders? Zuerst einmal viele Studierte aus Ingenieursfächern und auch aus 
der Mathematik. Ein Studium trainiert das Aneignen Kenntnissen und 
Wissen. Ich als Diplom-Informatiker (Beginn des Studiums war 2003) 
musste viel lernen, d.h. zu Hause sitzen, Bücher durcharbeiten, am 
Computer Programmierfähigkeiten ausbauen. Ich hatte aber auch schon vor 
meinem Studium mir einiges selbst beigebracht. Sicherlich gab es hier 
und da einen Anstupser (bei Basic, bei Pascal), aber C++ habe ich aus 
eigenem Antrieb erlernt. Und das nimmt mir keiner. Das GoF-Buch habe ich 
mir vor meinem Studium gekauft. (Ich erinnere mich, dass ich es bei der 
Bundeswehr dabei hatte, weil ich naiverweise dachte, ich hätte während 
der Grundausbildung Zeit zum Lesen.)

Die Fähigkeit, sich selbständig und systematisch Ding aneignen zu 
können, ist ja mit das wichtigste, was einen Akademiker ausmacht. Und in 
meinem Fall begann das ja schon vor dem Studium, aus einer intrinsischen 
Motivation heraus, und nicht für gute Noten in der Schule.

> Heute studieren Leute Informatik, die weder Lust noch Erfahrung damit
> haben.
>

Das wird es sein. Bei mir war das Studium eine Überzeugungstat. Eine 
beliebte Frage von mir an die neuen Mitarbeiter, die da frisch von der 
FH kommen, ist die Frage nach Linux, ob sie es denn privat verwendeten. 
Und dann heißt es, kein Interesse, keine Lust, keine Zeit... Mir ist das 
ein Rätsel. Viele studieren dann Informatik, weil sie gehört haben, 
damit könne man gut Geld verdienen.

Während mein Studium war es so, dass viele recht gute 
Programmierkenntnisse schon mitbrachten. Wer ohne Programmierkenntnisse 
ins Studium startete, hat sehr viel schlechtere Chancen, das Studium zu 
bestehen. Nun kommen viele meiner Kollegen von der FH, wo schon 
geringere Anforderungen an das selbständige Lernen gefordert werden. Und 
der Bachelor tut sein übriges.

> Insgesamt gibt es natürlich wesentlich mehr brillante SW-Entwickler
> heute. Relativ (also auf n SW-Entwickler in einer Firma bezogen) bin ich
> mir da nicht sicher. Und bei N Frameworks und Aufgaben ist es vermutlich
> auch kaum einfacher zu erkennen, ob jemand ein Verständnis von Codierung
> hat

Das denke ich auch. Es gibt aus den oben genannten Gründen immer mehr 
Mittelmaß. Ich sehe die intrinsische Motivation bei vielen Leuten nicht. 
Und das frustiert dann ungemein. Vor allem hörte bei mir das Lernen mit 
dem Studium nie auf. Jedes Jahr kaufte ich neue Fachbücher und arbeitete 
mehr oder weniger durch. Während des Corona-Winters 20/21 arbeitete ich 
ein Haskell-Buch durch. Die Sporthallen waren ja geschlossen, also hatte 
ich für Haskell viel Zeit.

Ich merke bei den Kollegen die Defizite immer dann, wenn sie im Code ein 
Mengenobjekt (In Java üblicherweise das HashSet.) haben und etwas 
hinzufügen. Es gibt tatsächlich Programmierer, die vorher abfragen, ob 
das hinzufügende Objekt nicht schon drin sei und nur wenn nicht, fügen 
sie ein. Das ist für mich ein Zeichen, dass die Person nicht weiß, was 
'ne Menge und was sie auszeichnet. Oder wissen die nicht, dass Menge auf 
Englisch set heißt? Ich finde die Mengentheorie essentiell und wende sie 
häufig an. Kann ich sicher sein, dass ein Kollege mich korrekt versteht, 
wenn ich von Differenzmenge, von der Schnittmenge, der Vereiniunsmenge, 
oder von der Ober - oder Teilmenge spreche? Oder vom kartesischen 
Produkt?

Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum 
geht: https://www.danisch.de/blog/2024/01/16/scrum/

von Hadmut F. (hadmut)


Lesenswert?

Rudi R. schrieb:
> Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum
> geht: https://www.danisch.de/blog/2024/01/16/scrum/

Beim Danisch finde ich toll wenn er über feministen herzieht.

von Wolfgang H. (Firma: AknF) (wolfgang_horn)


Lesenswert?

Huebi H. schrieb:
Sehr schön und klar:

> Die Kaffeeküche ist für mich der kreativste Raum im Büro. Dort kommt
> soviel Information auch und besonders aus unerwarteten Ecken zusammen,
> dass die Effizienz in der Entwicklung unvorstellbar steigen kann.

Wie schön, dass die Orgbanisationswissenschaften die Kaffeeküche noch 
nicht instrumentalisiert haben.

Ciao
Wolfgang Horn

von Bernd G. (Gast)


Lesenswert?

Rudi R. schrieb:
> aber C++ habe ich aus eigenem Antrieb erlernt.
wann hast du denn studiert? C++ wurde bei uns schon 1993 gelehrt.

von Mark B. (markbrandis)


Lesenswert?

Hadmut F. schrieb:
> Beim Danisch finde ich toll wenn er über feministen herzieht.

Was ist so toll daran, wenn jemand über etwas schreibt von dem er nichts 
versteht?

von Bruno V. (bruno_v)


Lesenswert?

Bernie schrieb:
> wann hast du denn studiert? C++ wurde bei uns schon 1993 gelehrt.

Er hat doch sehr ausführlich geschrieben, dass es (zumindest damals) 
üblich war, schon vor dem Studium intensiv programmieren zu können. Und 
GoF durchgearbeitet zu haben, erfordert einiges. So wie die 
Bewerbungs-Mappe zur Kunsthochschule tausende Stunden Erfahrung/Übung 
brauchen, bei Musik ähnlich.

Wer Programmieren erst im Informatikstudium lernt (gibt ja keine 
Aufnahmeprüfun), kommt damit zwar auch durch, dürfte aber später eher 
als Consulter oder SAP-Systemberater denn als Informatiker Karriere 
machen.

Im Studium hat man 2 oder 3 Sprachen, an denen man konkrete 
pattern/Konzepte zeigt.

: Bearbeitet durch User
von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum
> geht: https://www.danisch.de/blog/2024/01/16/scrum/

Der Typ hat von Softwareentwicklung schon mal gar keine Ahnung, 
Fricklerniveau auf dem Stand der 90er, so typischer 
Uni-Werksstudentenbastler. Mal schnell was zusammenfrickelt für die Uni 
und sich als Held der Softwareentwicklung fühlen. Solche Gestalten kennt 
man, wenn er seine Entwickleranekdoten von vor 30 Jahren runterleiert.
Sein IT-Sicherheitswissen ist erschreckend dünn und allgemein gehalten, 
wenn er überhaupt mal was zu dem Thema schreibt auf dem er angeblich 
Experte ist, das ist ein sicheres Zeichen dass er eine aufgeblasene 
Luftpumpe ist. Ab und an verrät er sich mit seinem epischen Artikeln 
über Trivialproblemen unter Ubuntu, Puppet,... Seine Ausführungen zur 
Kryptografie lesen sich genauso, so schreiben Anfänger und 
selbsternannte Profis aber keine echten Fachleute.
Habt ihr von dem mal einen einzigen tiefergehenden Artikel zu seiner 
angeblichen Expertenwissen gelesen? Das ganze Blog ist nur voller 
Geschwafel.

Ein sicheres Zeichen, dass er nur ein Grossmaul ist, er weiss ja immer 
alles am besten, die ganze Welt hat sich gegen ihn verschworen, sein 
heroischer Kampf gegen alle Windmühlen dieser Welt beschreibt er in 
epischer Breite in jahrelanger Dauerwiederholung. Der Typ hat meiner 
Ferndiagnose nach eine riesige Psychomacke. Z.T. hat er ja recht mit 
seine Behauptungen und Erlebnissen aber ein aufgeblasener Schwätzer ist 
dennoch.

: Bearbeitet durch User
von Hadmut F. (hadmut)


Lesenswert?

Er hat schon 1995 eine digitale sprachverschlüsselung gebastelt als wir 
nicht mal wussten was ein vocoder ist. Wenn man sich im gebiet auskennt 
ist das ziemlich eindrücklich.

von Bernd G. (Gast)


Lesenswert?

Bruno V. schrieb:
> Er hat doch sehr ausführlich geschrieben, dass es (zumindest damals)
> üblich war, schon vor dem Studium intensiv programmieren zu können.

Also auch bei uns war das üblich, schon vor dem Studium was zu 
programmieren. Machen ja heute allemöglichen 15-jährigen 
APP-Programmierer. Deren Problem ist es, ein Konto zu bekommen, um sich 
Paypal überweisen zu lassen.

Wie sehr das von Vorteil ist, sei dahin gestellt. Man unterscheide 
Programmieren und Software entwickeln. Es gibt Leute die entwickeln 
täglich Software, schreiben aber keine einzige Zeile Code.

Meine Frage war auch eine andere:

Seine Aussage war, C++ gelernt zu haben und das sei "neu" gewesen. C++ 
ist an Hochschulen seit 30 Jahren nicht mehr "neu". Es wurde Mitte der 
1980er eingeführt und war Ende der 1980er bereits an einigen Hochschulen 
wählbar. Spätestens Mitte der 1990er Jahre hatte das jede Hochschule, 
die ich kenne, im Programm. Natürlich nur Informatik. Die Elektriker 
blieben freilich beim C. Reichte auch für Prozessoren. Ist heute auch 
anders.

von Rudi R. (rudi_r)


Lesenswert?

Bernie schrieb:

> Also auch bei uns war das üblich, schon vor dem Studium was zu
> programmieren. Machen ja heute allemöglichen 15-jährigen
> APP-Programmierer. Deren Problem ist es, ein Konto zu bekommen, um sich
> Paypal überweisen zu lassen.
>

Ich weiß nicht, wie weit verbreitet das ist. Einer unserer Azubis 
erzählte mir aber, dass er regelmäßig an Coding Challenges teilnimmt. 
Dort verwendet man irgendwelche Frameworks für kleine Spiele, deren 
Namen ich schon wieder vergessen habe. Das ist immerhin besser als 
nichts. Ich musste heute auch zurückdenken, als Delphi sehr populär war. 
1998 probierte ich es damit. Ich konnte da schön Oberflächen 
zusammenklicken, aber ich hatte meine Schwierigkeiten, es mit Leben zu 
füllen. Ich empfand das nicht sehr als lehrreich und begann später 
Dialog-Programmierung per Hand. Ich will mal hoffen, dass die jungen 
Leute auch noch textbasiert und oldschool entwickeln. 
Entwicklungsumgebungen nehmen einen sehr viel ab und wir müssen bei der 
Ausbildung darauf achten, dass die Azubis wirklich in die Materie 
einsteigen und nicht immer nur die IDE die Arbeit machen lassen.

Ich konnte mich als Jugendlicher mich stundenlang darin vertiefen, einen 
Interpreter für Terme (wie z. B. 5+3*10) zu entwickeln. Ich war ja 
vollkommen unbeleckt, was Grammatiken angeht und vielleicht gerade 
deshalb war es sehr lehrreich. Heute würde ich das anders entwickeln. 
Ich habe meine Zweifel, dass meine Kollegen es entwickeln könnten. Sie 
kämen nicht auf meine damalige Lösung mit einer rekursiven Funktion noch 
kämen sie nicht auf die, mit antlr/Lex&Yacc etc. zu definieren.

> Meine Frage war auch eine andere:
>
> Seine Aussage war, C++ gelernt zu haben und das sei "neu" gewesen.

Die Stelle zeigen Sie mir bitte. Sie werden Probleme haben, weil ich das 
nie schrieb. Wenn ich 2003 begann zu studieren, kann man mein Alter 
ungefähr abschätzen. Als C++ eingeführt eingeführt wurde, war ich noch 
nicht mal geboren.

von Bri (bri)


Lesenswert?

Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem 
Entwicklungsmodell zu tun.

Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als 
Hobby programmiert haben und seit mindestens 10 Jahren große Projekte 
planen und mit Begeisterung und hohen Ansprüchen an die eigene 
Sourcecodequalität selbst programmieren.

von Rudi R. (rudi_r)


Lesenswert?

Bri schrieb:
> Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem
> Entwicklungsmodell zu tun.
>
> Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als
> Hobby programmiert haben und seit mindestens 10 Jahren große Projekte
> planen und mit Begeisterung und hohen Ansprüchen an die eigene
> Sourcecodequalität selbst programmieren.

Dem widerspreche ich nicht, aber es ist ein Problem, wenn diese Leute 
mit Meetings gequält werden. Ich sehe meine Entwicklerfähigkeiten als 
weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier 
anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme, 
wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit 
investieren und das Fortentwickeln wäre das beste, dann weiß ich, es 
geht schief. Denn erstmal will man nicht der Arsch sein, der die anderen 
nur für Idioten hält. Dann investiert man Zeit, um es zu verstehen, was 
da programmiert wurde und dann wird zusätzlich viel Zeit und Geld 
verschwendet für Erweiterungen. Und immer ist das unwohle Gefühl da: 
Hätte man alles neue gemacht, wäre man günstiger gefahren. Aber das 
kapieren viele Projektleiter leider nicht.

Wir hatten schon mehrfach die Situation, dass Code von Entwicklern 
komplett weggeschmissen werden musste. Erst kosten die Entwickler Geld 
und dann geht die Zeit anderer Entwickler drauf, um aufzuräumen und neu 
machen. Es waren u.a. Festangestellte, wo wir froh sind, dass die weg 
waren. Externe sind ein gesondertes Problem. Die haben es ja besonders 
schwer, weil die sich in kurzer Zeit einarbeiten müssen. In der Regel 
machen die Externen mehr Arbeit als sie bringen. Nur kapieren das die 
Verantwortlichen auch nicht. Ich habe in den letzten zehn Jahren ca. 10 
externe Entwickler in meinen Projekten gehabt. Nur zwei konnten am Ende 
etwas produktives vorweisen.

Scrum lebt ja von der Illusion, dass Entwickler schon alle gleich wären, 
austauschbare Verschiebemasse und dass Softwareentwicklung etwas ist, 
was man in Zwei-Wochen-Sprints aufteilen könne. Es gibt aber die 
Aufgaben, wo man auch länger mal drüber brüten muss, damit es vernünftig 
wird. Und man muss in Ruhe nachdenken können. Ich habe vor zwei Jahren 
mal einen Prototypen für einen Algorithmus entwickelt. Obwohl wir in 
Java entwickeln, habe ich den Prototypen in Python entwickelt, um zu 
schnellen Ergebnissen zu kommen, denn im Zentrum steht der Algorithmus 
und nicht die Implementierung. (Das hatte so Spaß gemacht, dass ich 
sogar nach Feierabend dran arbeitete.) Hundertprozentig wäre in einem 
Scrum-Umfeld das nicht möglich gewesen, weil es von vielen Leuten nicht 
gerne gesehen wird, dass jemand Entwicklungszeit aufwendet, was im 
Endprodukt ja komplett neu entwickelt werden muss, weil anderes 
Ökosystem.

2010 sprang mal bei uns ein Lean-Berater herum, der uns etwas von Kaizen 
erzählte. Was für ein Blödsinn. Da wurden Grundsätze entwickelt wie, 
dass nur die Programmierung, bei der Funktionalität herauskommt, gut 
ist. Also laut diesem Grundsatz ist Refactoring ein No-Go. Lean mit 
Kaizen ist ja genauso ein Mode-Blödsinn wie Scrum.

Ich finde ja zyklische Vorgehensmodelle ganz sinnvoll und ich verwende 
diese informell. Kollegen von mir sind auf meine Arbeit angewiesen, dass 
sie erstmal weiter machen könne. Ich entwickle so, dass die 
Grundfuntionalität schnell bereitsteht, sodass die anderen weitermachen 
können und dann widme ich mich dem nächsten Thema (wo andere Entwickler 
wieder auf Grundfunktionalität warten), wohlwissend, dass ich Monate 
später die Themen wieder anfassen muss. Damit fahre ich am besten. 
Meilensteine kann man definieren, aber man sollte mit diesem 
Zwei-Wochen-Unfug aufhören.

Meine Erfahrung ist, das ich das Vertiefen in unwichtigen Details am 
Anfang unsinnig ist, weil die Spezifikation sich ja noch ändern kann. 
Viele Dinge kritallisieren sich noch heraus, warum also Energie 
schwerden. Und wenn man darauf vorbereitet ist, dass es doch wieder 
anders kommen kann, dann man implizit so, dass man die Sachen schnell 
umstellen kann.

Ich erwähnte ja, dass im aktuellen Projekt Scrum angewendet wird. Da 
wird ständig darüber gequatscht, dass eine Aufgabe grob in zwei 
Teilaufgaben aufgesplittet werden kann. Die Quatscherei darüber 
verschlang schon ein paar Stunden. Nun wird endlich gemacht.

von Steve van de Grens (roehrmond)


Lesenswert?

Rudi R. schrieb:
> Hundertprozentig wäre in einem Scrum-Umfeld das nicht möglich gewesen,
> weil es von vielen Leuten nicht gerne gesehen wird, dass jemand
> Entwicklungszeit aufwendet

Viele Softwareentwickler (eigentlich alle, die ich kenne), wirken am 
Arbeitsplatz zeitweise faul, weil sie nicht tippen sondern z.B. 
Katzenvideos gucken oder Freizeit-Aktivitäten diskutieren. Aber zu hause 
grübeln und lernen sie oft ganze Wochenenden, um ein Problem ordentlich 
zu lösen.

Ich bin froh darüber, dass meine Chefs das alle wussten. Niemand bekam 
jemals Ärger, wenn er am Arbeitsplatz mal zeitweise faul zu sein 
scheinte.

: Bearbeitet durch User
von Mark B. (markbrandis)


Lesenswert?

Bri schrieb:
> Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem
> Entwicklungsmodell zu tun.

Nein, das stimmt so pauschal nicht. Es macht einen großen Unterschied 
ob:

-Man das x-te Projekt nach Schema F macht (z.B. einen Webshop für ein 
kleines Unternehmen), was man so oder so ähnlich schon dutzendfach hatte 
oder ob
-Man etwas völlig Neues entwickelt, am besten mit komplexen 
Anforderungen die man so zum ersten Mal im Leben sieht :-)

> Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als
> Hobby programmiert haben und seit mindestens 10 Jahren große Projekte
> planen und mit Begeisterung und hohen Ansprüchen an die eigene
> Sourcecodequalität selbst programmieren.

Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn 
das Requirements Management nichts taugt. Wenn der Vertrieb dem Kunden 
sonstwas verspricht - aber selbst auf Nachfrage nicht präzise sagen 
kann, was dem Kunden denn nun alles verkauft wurde - was willste dann 
machen?

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> ...
> Ich sehe meine Entwicklerfähigkeiten als
> weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier
> anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme,
> wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit
> investieren und das Fortentwickeln wäre das beste, dann weiß ich, es
> geht schief. Denn erstmal will man nicht der Arsch sein, der die anderen
> nur für Idioten hält. Dann investiert man Zeit, um es zu verstehen, was
> da programmiert wurde und dann wird zusätzlich viel Zeit und Geld
> verschwendet für Erweiterungen. Und immer ist das unwohle Gefühl da:
> Hätte man alles neue gemacht, wäre man günstiger gefahren. Aber das
> kapieren viele Projektleiter leider nicht.
> ...

Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum 
eingenordet oder fliegen halt raus.

von Bruno V. (bruno_v)


Lesenswert?

Franko S. schrieb:
> Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum
> eingenordet oder fliegen halt raus

Ja. Die nächsten 5 Jahre lebt die Firma von der Cash Cow. Bis ein 
kleines Nischenprodukt einer anderen Diva zur neuen Cash Cow wird oder 
die Firma verschwindet.

von Andi (chefdesigner)


Lesenswert?

Mark B. schrieb:
> Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn
> das Requirements Management nichts taugt.

Guter Punkt!

Ich habe gerade was Nettes gefunden:
https://www.co-improve.com/media/co_programm_agile_hardware_d.pdf

Dort tauchen gleich zwei Referenten von 2 Firmen auf, für die ich tätig 
war!   Alle beiden referieren über ihre großartigen Erfolge im Bereich 
SCRUM und dem Einsatz bei der Hardwareentwicklung.

Wenn man sich die Probleme ansieht, die die Firma jeweils hatte und wie 
ort real gearbeitet wurde, dann weiß man, dass die sich was in die 
Tasche lügen! Das hat mit den realen Vorgängen, die stattfanden nichts, 
aber auch rein gar nichts zu tun. Das war eher Chaos- und 
Problembewätigung.

Aber jeder hüpft auf das Pferd auf und spricht von agilen Methoden.

Es ist zuweilen lächerlich, was da läuft.

von Rudi R. (rudi_r)


Lesenswert?

Franko S. schrieb:
> Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum
> eingenordet oder fliegen halt raus.

Ich kenne bei uns in der Framework-Entwicklung eine Diva, die wirklich 
sehr viele Register der Informatik und Softwarearchitektur zieht. Dessen 
Software ist 1A und läuft in allen Projekten sehr gut. Problem aber ist, 
dass anderes Framework unserer Produktepalette von sehr geschwätzigen 
Teams in Scrum-Sprints zusammengefrickelt werden, was aber so blöd 
entwickelt wurde, dass die Stärken des Erzeugnisses der Diva gar nicht 
zu Geltung kommen. Es gibt bei uns grosso modo zwei Möglichkeiten, 
Projekte umzusetzen. Man setzt nur auf dem auf, was die Diva gemacht, 
dann gibt es grüne Zahlen. Oder aber man nimmt den Unfug des 
Entwicklerteams, das seit 14 Jahren an einer Einheitslösung frickelt, 
dann geht es in die Hose. Das Management kapiert nicht, dass sie bei dem 
großen Entwicklerteams nur Geld verbrennt. Das ist 'ne heilige Kuh. Ich 
bin mir sicher, dass das Management die Wichtigkeit dieser Diva gar 
nicht kennt.

Warum ist das Framework der Diva so gut nutzbar? Weil es architektonisch 
so gestaltet ist, dass man Bausteine austauschen kann. Die Verwendung 
von Schablonenmethoden und Strategieklassen ist exzessiv. In 95 % der 
Fälle sind die Default-Strategien korrekt und bei 5 % entwickelt man 
seine eigene Implementierung. Das Entwicklerteam des anderen Frameworks 
jedoch geht den Ansatz, dass man alles per Mausklick konkfigurieren 
können muss und dann versenkt man natürlich Zeit für die Bereitstellung 
von Schaltern, Konfigurationsoberflächen und Dokumentation und man deckt 
immer noch nicht zu 100 % alle Kundenwünsche ab, weil es nicht möglich 
ist. Ich merke auch bei vielen Entwicklungen, dass sich viele gar nicht 
darüber im Klaren sind, in welcher konzeptuellen Schicht sie sich gerade 
befinden. Unsere Software hat mehrere Schichten mit mehreren 
Zuständigkeiten, aber die schleifen ein Konzept von ganz unten nach ganz 
oben durch. Die würden es sogar hinbekommen, das Konzept 
Festplattensektor nach ganz oben ins Word-Programm zu schleifen, d.h. 
der Anwendung kann sich aussuchen, in welchem Sektorenbereich der 
Festplatte die Datei abgelegt werden soll. Obwohl es richtig ist, dass 
Dateien in irgendwelche Sektoren gespeichert werden, ist es falsch, 
dieses Konzept in diese sehr hohe konzeptuelle Ebene zu bringen, weil es 
da einfach nicht hingehört. Über so grundlegende Dinge muss gewacht und 
entschieden werden. Es muss Architekten geben, die da zur Not 
dazwischengrätschen, wenn jemand die Schichtenarchitektur zerstört. 
Leider passiert das bei uns nicht, weil die Leute im großen 
Entwicklerteam gar nicht verstehen, dass es Teil ihrer Aufgabe ist. Die 
erwähnte Diva jedoch muss sich nicht mit diesen Schmalspurarchitekten 
auseinandersetzen.

Ich bin nicht in der Position, aber ich wenn ich in einer wäre und 
jemand hat einen Vorschlag, dann würde ich grundsätzlich um 
grundsätzlich um eine schriftliche Ausarbeitung bitten, die folgendes 
enhält bzw. genüg:

1. Motivation.
2. Vor- und Nachteile.
3. Was zu tun ist.
4. UML-Diagramme über den wesentlichen(!) Aspekt.
5. in ganzen Sätzen, auf Deutsch.
6. Zusammenhängender Text und kein Powerpoint! Nur so kommen Gedanken 
rüber.

Jemanden zu zwingen, etwas zu Papier zu bringen, heißt, dass er sich 
darüber tiefgründige Gedanken machen muss. Ich kann mich erinnern, wie 
ich als Student mal ein Architekturpapier erarbeitet hatte, das für 
meinen damaligen Kenntnisstand gar nicht mal so  schlecht war und ich 
bei der Ausarbeitung schon viel nachgedacht hatte.

Die UML-Diagramme sollen mir zeigen, worauf es ankommt. Wenn mir jemand 
eine Klasse per UML präsentiert, wo dann ca. 25 Attribute auftauchen, 
der hat's nicht kapiert. Das wichtige sind ja Klassen- und 
Objektbeziehungen. Auch Objekt-Diagramme sind interessant, um etwas zu 
illustrieren. Ich kannte mal jemanden, der hat in ArgoUML alle Klassen 
seiner Software in eine große Zeichnung gequetscht. Ausgedruckt locker 
A1 oder gar A0. Alle Felder der Klassen waren aufgeführt, aber das 
wichtige, die Beziehungen der Klassen untereinander, gingen unter. Man 
sieht dann den Wald vor lauter Bäumen nicht.

von Steve van de Grens (roehrmond)


Lesenswert?

Im Team muss man so entwickeln, dass alle Kollegen durch blicken.

Mit der Einstellung: "Wenn die anderen das nicht durchblicken sind sie 
halt zu dumm" kommt man nicht weit. Irgendwann fällt so eine 
Vorgehensweise dem Management auf, und dann wird die "Diva" gekündigt. 
Kein vernünftiger Manager macht seine Firma von einem einzelnen 
Programmierer abhängig.

: Bearbeitet durch User
von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Die würden es sogar hinbekommen, das Konzept Festplattensektor nach ganz
> oben ins Word-Programm zu schleifen,

Schönes Bild!

Rudi R. schrieb:
> Die UML-Diagramme sollen mir zeigen, worauf es ankommt.

Das klappt m.E. nur, wenn alle Beteiligten auch wirklich UML sprechen. 
Sonst unterscheidet es sich kaum von Visio Bubble-Pfeildiagrammen (was 
OK ist, nur sollte man es dann nicht UML nennen)

von Michael B. (laberkopp)


Lesenswert?

Steve van de Grens schrieb:
> Irgendwann fällt so eine Vorgehensweise dem Management auf, und dann
> wird die "Diva" gekündigt. Kein vernünftiger Manager macht seine Firma
> von einem einzelnen Programmierer abhängig.

Umgekehrt wird ein Schuh draus:

um was herausragendes zu entwickeln, darfst du nicht nur Durchschnitt 
sein.

Alle herausragenden Produkte wurden von Diven (Helden) ersonnen und 
entwickelt.

Die Diva ist die Firma, wer so blöd ist und dem Helden kündigt, killt 
die Firma

Ob ein Apple oder Tesla, ob ein Amazon oder SpaceX (Tom Mueller, nicht 
Musk), ob eine LED oder OLED, damals hinter Chips wie LM324 oder uA709 
oder NE555, hinter jedem grossen Ding steckt eine Diva, denn wenn die 
Leute nur Durchschnitt sind bleibt halt auch das Ergebnis so.

Das verstehen aber der durchschnittliche Manager nicht. Die glauben, mit 
9 Frauen bekommt man das Kind in 1 Monat.

Scrum klappt wenn du eine Horde Affen verwalten musst und mit einem 
Haufen Scheisse zufrieden bist.

Ich kenne ein schönes Beispiel, wo eine Software, die von 2 Leuten in 2 
Jahren entwickelt wurde, dann von einem Scrum-Team neu implementiert 
werden sollte. Das hat 10 Leute über 10 Jahre beschäftigt und erreichte 
laut Kundenmeinung nicht die Qualität des Originals.

Nicht ohne Grund gehen bergeweise Firmen ein  wenn der Gründer stirbt 
oder der Held kündigt. Was auch immer die für Eigenschaften hatten, es 
waren herausragende, nicht durchschnittliche.

: Bearbeitet durch User
von Steve van de Grens (roehrmond)


Lesenswert?

Michael B. schrieb:
> Alle herausragenden Produkte wurden von
> Diven (Helden) ersonnen und entwickelt.
> Die Diva ist die Firma, wer so blöd ist und
> dem Helden kündigt, killt die Firma

In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held 
gar keiner ist. Hochmut kommt vor dem Fall.

: Bearbeitet durch User
von Bernd G. (Gast)


Lesenswert?

Michael B. schrieb:
> Scrum klappt wenn du eine Horde Affen verwalten musst und mit einem
> Haufen Scheisse zufrieden bist.

Etwas sachlicher formuliert:

"Wenn man eine Gruppe von Personen verwalten möchte, deren Aufgabe es 
ist, eine vordefinierte Leistung zu bringen, die wenig Innovation 
erfordert".

Das ist nämlich das Mißverständnis unseres TE sowie einiger 
Beitragenden:

Rudi R. schrieb:
> Dem widerspreche ich nicht, aber es ist ein Problem, wenn diese Leute
> mit Meetings gequält werden. Ich sehe meine Entwicklerfähigkeiten als
> weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier
> anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme,
> wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit
> investieren und das Fortentwickeln wäre das beste, dann weiß ich, es
> geht schief.

Du verwechselst hier das Systemdesign, also die Erstellung des 
Lösungskonzeptes, mit dessen Umsetzung!  Mit einem Blatt Papier 
anzufangen, heißt sich die Lösung als Konzept auszudenken. Scrum in der 
Entwicklung taugt aber eher für die schnelle Unmsetzung. Das Konzept 
wurde vom Product Owner schon definiert.

Gleichwohl solltest auch du in der Lage sein, die von anderen Leuten 
erarbeiteten Lösungen zu verstehen und nötigenfalls zu verbessern und / 
oder mitzubenutzen. Wenn es dir schwer fällt, liegt es entweder an Dir, 
oder der mangelnden Planung und Doku deiner Kollegen.

Meistens ist es beides, denn Leute wie du sind oft die, die nicht in der 
Lage sind, ein Lösungskonzept zu skizzieren und für andere nutzbar zu 
machen. Es fällt ihnen beim Umsetzen immer noch was ein, was sie selber 
gut einpflegen können und daher nicht merken, wie schlecht ihr Konzept 
anfänglich war. Soll das aber ein Team machen, wird es schwer!

Daher haben sie sich Srum ausgedacht, das die Hintertüre für "sich 
ändernde Anforderungen" offen hält. Das ist auf den ersten Blick gut, 
führt aber dazu, dass die Systemplaner noch weniger Zeit in ein gutes 
Konzept investieren, weil das "Ändern" nun Teil der Strategie ist. Die 
Planungsfaulheit wird also gefördert!

Und auch die Umsetzer können jetzt ständig umdisponieren, weil sie es ja 
dürfen: Alle 2 Wochen wird die Windrichtung geändert. Es wird also immer 
mehr aus dem Stegreif gearbeitet. Für manche Chaoten ist das prima, weil 
sie eingebaute Ausreden parat haben und von den unzulänglichen 
Fähigkeiten der Systemingeniuere profitieren. Scrum bietet ihnen auch 
die Chance, binnen 2 Wochen alles abzuwehren, was noch nachgefordert 
wird. Auch das, was von Teammitgliedern in der Zeit aufgedeckt wird. 
Deshalb begrüßen viele Entwickler Scrum, weil sie die "Vorteile" für 
sich zu nutzen wissen.

Siehe dazu auch diese interessante Diskussion, wie Selbständige von 
Scrum profitieren:
Beitrag "SCRUM und die Arbeitsweise von Selbständigen"

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:

Dann steckt Typen als Architekten in euer Scrumteam. Er gibt das Desing 
vor und wacht darüber dass die anderen Hansel das korrekt umsetzen und 
nicht aus der Spur laufen.

von Bruno V. (bruno_v)


Lesenswert?

Steve van de Grens schrieb:
> In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held
> gar keiner ist. Hochmut kommt vor dem Fall.

Sorry, aber das ist Nonsens:jeder ambitionierte Entwickler hält sich für 
überdurchschnittlich. Und das ist auch gut so. Niemand möchte einen 
Programmierer, dessen größte Sorge es ist, aufzugfliegen.

Aufgabe des Managers ist es, jeden nach seinen Fähigkeiten einzusetzen. 
Die nicht ambitionierten als Programmierer, die guten in Brot und Butter 
Projekten und die Diven für wichtige Sachen:

Vielleicht verwechselt Du Diven mit denen, die sich so benehmen (die 
waren es in meiner Laufbahn nie!)

von Michael B. (laberkopp)


Lesenswert?

Bruno V. schrieb:
> jeder ambitionierte Entwickler hält sich für
> überdurchschnittlich

Natürlich.

Daher geht man nicht nach dem für was er sich hält, sondern nach dem was 
er erreicht hat.

Weiss man natürlich erst retrospektiv.

Wobei: bei manchen hat man vorher eine Einschätzung.

Die wirklichen Diven (Helden) wissen meist gar nicht, dass sie 
überdurchschnittlich sind, sondern glauben, die Anderen könnten doch 
dasselbe.

von Rudi R. (rudi_r)


Lesenswert?

Michael B. schrieb:
>
> Die wirklichen Diven (Helden) wissen meist gar nicht, dass sie
> überdurchschnittlich sind, sondern glauben, die Anderen könnten doch
> dasselbe.

Eher ist es so, dass ist es so, dass sie erst im Laufe ihres 
Berufslebens merken, dass bei Kollegen bestimmtes Wissen schlichtweg 
fehlt und nicht aufgeholt werden kann. Ich verwendete vor drei, vier 
Jahren mal den Begriff "topologische Sortierung" gegenüber einem 
Architekten, denn damit firmierte er. Er konnte mit dem Begriff 
anfangen. Man möchte doch meinen, zur Softwarearchitektur gehören auch 
algorithmische Verfahren.

Mich deprimiert das. Ich schrieb ja oben, dass ich mich als 
überdurchschnittlicher Entwickler ansehen. Das liegt an meinem 
Wissensschatz der Informatik und meinen Fähigkeiten, konkrete Probleme 
darauf zu projezieren und Probleme zu abstrahieren. Ich merke, dass die 
Kollegen es nicht verstehen und würde mich am liebsten einigel. Ich kann 
auch verstehen, wenn jemand seine Gesundheit schützen muss und sagt: 
Euch erkläre ich es nicht. Hier ist ein Dokument, dort gibt es drei 
Wikipedia-Artikel. Lies dich gefälligst ein.

Ich sehe ja, was ich leiste. Ich mache ich Projekten das, woran in 
anderen Projekten fünf Leute gemeinsam dran arbeiten. Ich bin sogar noch 
ohne Allüren. Während andere mit dem Taxi vom Bahnhof kommen oder zum 
Bahnhof fahren, da nehme ich den ÖPNV. (Tatsächlich gab es bei uns mal 
eine jüngere Minderleisterin, die nicht mit der Tram zum Bahnhof fuhr, 
obwohl die Tram keine 20 Minuten braucht und praktisch direkt vor dem 
Büro startet.)

Ein Kollege sagte mal Telefon: "Rudi, das finde ich so toll an dir. Wir 
schildern ein Problem und du suchst zuerst in deinem Code." - Kann ich 
mir vorstellen. Ich hatte schon öfter Kollegen, die angepisst reagieren.

Habe ich schon mal erzählt, dass ein anderer Entwickler mich angeschrien 
hat? Ich schrieb ihm freundlich, dass ein bestimmter Teil Code nicht 
funktionieren könne, ich begründete es auch detailliert. Keine Antwort. 
Ich sprach ihn zwei Tage später persönlich drauf an. Er reagierte eher 
abweisend, er würde sich irgendwann mal drum kümmern. Also änderte ich 
es und schon explodierte er: "Aber der Test hat doch gezeigt, dass es 
funktioniert." - Dass ein Softwaretest nicht die Abwesenheit von Fehler 
beweist, hatte er wohl noch nie gehört. Dieser Mensch hatte jahrelang 
das Projekt mit seinem schlechten Code in die Grütze geritten, ja in die 
Grütze reiten dürfen, weil oben drüber keine Fachkundigen standen, und 
den damals jungen Mann an die kurzen Leine nahmen.

Wenn ich 'nen Schusslichkeitsfehler einbaue, wenn etwas seltsam 
ausschaut, und es mir gemeldet wird, dann behebe ich das sofort, denn 
mir ist klar, dass Fehler möglichst früh behoben werden müssen. Und 
gerade wenn die Lösung klar ist und das alles nur fünf Minuten braucht, 
mache ich das sofort oder halt geordnet noch am selben Tag. Und ein 
Entwickler, der das nicht einsieht, hat seinen Beruf verfehlt. Ein 
typischer Fehler in der Java-Welt ist, versehentlich einen Enumerate mit 
einem String zu vergleichen. Da dass konstant falsch ist, kann es kaum 
das sein, was der Entwickler beabsichtigen konnte. Die statische 
Code-Analyse findet das schnell. So viele Entwickler ignorieren das 
einfach. Schon viel zu oft erlebt.

Franko S. schrieb:
> Dann steckt Typen als Architekten in euer Scrumteam. Er gibt das Desing

Das wird nichts. So viel Architektur-Entscheidungen müsse ja gar nicht 
mehr getroffen werden. Das Problem sind die Entwickler, die vieles 
falsch verstehen. Ich habe gerade mit Entwickler zu tun, die ständig 
neue Persistenzklassen aus der Taufe heben, wo ich schon mehr sagte, 
dass die nicht gebraucht werden, aber es passiert nichts. Ich habe es 
auch dem Projektleiter und dem Scrum-Master gesagt. Es fehlt dann oft 
auch der gesunde Menschenverstand. Wenn ich beispielsweise Konstruktoren 
bei Klassen sehe, wo ca. 20 Primitive als Argumente übergeben werden 
müssen (für jedes Feld einen), dann verstehe ich nicht, was in diesen 
Leuten vorgeht. Wollen die, dass die Leute sich verhaspeln? Gibt es ein 
Verbot am  Konstruktor die drei, vier wichtigsten Sachen zu übergeben 
und ansonsten nimmt man die Setter-Methoden. Und in einer Fabrik kann 
man ein paar Methoden zum Erzeugen von Objekten dieser Klasse 
bereitstellen. Ich habe es - so mein Eindruck - mit Entwicklern zu tun, 
die exakte Regeln brauchen. Mein Hinweis, maximal drei, vier Argumente 
und nur die wichtigsten, ist schon zu viel Spielraum. Für die gibt es 
nur: Gar keine Argumente oder alle. Mit Sachen wie: "gesunder 
Menschenverstand", so ein Konstruktorenaufruf/Methodenaufruf müsse 
überblickbar sein, erfordert ja eigenständiges Denken und Handeln.

von Rudi R. (rudi_r)


Lesenswert?

Bruno V. schrieb:
> Rudi R. schrieb:
>> Die würden es sogar hinbekommen, das Konzept Festplattensektor nach ganz
>> oben ins Word-Programm zu schleifen,
>
> Schönes Bild!
>
> Rudi R. schrieb:
>> Die UML-Diagramme sollen mir zeigen, worauf es ankommt.
>
> Das klappt m.E. nur, wenn alle Beteiligten auch wirklich UML sprechen.
> Sonst unterscheidet es sich kaum von Visio Bubble-Pfeildiagrammen (was
> OK ist, nur sollte man es dann nicht UML nennen)

Es sollte unter Entwicklern Standard sein, finde ich. Ich habe mich 
eigenmächtig mal darum bemüht. Ich halte aber auch andere graphische 
Verfahren für nicht falsch. Was ich aber absolut nervtötend finde, wenn 
jemand um die Ecke kommt, und mit seiner Grafik nicht in der Lage ist, 
den Wesenskern zu illustrieren. So der Kommilitone von 2006, der in 
seinem ArgoUML-Blatt alle seine Klassen unterbrachte und alle Felder der 
Klassen waren auch angezeigt. Die wichtigen Beziehungen der Klassen 
untereinandern aber gingen da unter. Dann kann ich mir doch gleich den 
Code anschauen.

Wie ich gesehen habe, ist die UML sogar Teil des Ausbildungsberufes 
Fachinformatiker für Anwendungsentwicklung.

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> seinem ArgoUML-Blatt alle seine Klassen unterbrachte und alle Felder der
> Klassen waren auch angezeigt. Die wichtigen Beziehungen der Klassen
> untereinandern aber gingen da unter. Dann kann ich mir doch gleich den
> Code anschauen.

Vielleicht konnte er ArguUML nicht bedienen.

von Mark B. (markbrandis)


Lesenswert?

Michael B. schrieb:
> um was herausragendes zu entwickeln, darfst du nicht nur Durchschnitt
> sein.
>
> Alle herausragenden Produkte wurden von Diven (Helden) ersonnen und
> entwickelt.

Dem würde ich sogar soweit zustimmen.

Aber: Wie viele herausragende Produkte haben denn die Unternehmen dieser 
Welt tatsächlich? Und wie viele "Brot-und-Butter" Produkte, mit denen 
ein großer Teil des Umsatzes erwirtschaftet wird?

Apple hatte mit dem iPhone die Idee des Jahrhunderts. Kein anderes Gerät 
hat unser aller Leben so sehr und so nachhaltig beeinflusst. Freilich: 
Seit dem iPhone kam nichts anderes mehr, was auch nur annähernd so 
innovativ war. Dennoch verdient die Firma prächtig viel Geld.

Braucht man auch geniale Entwickler? Wenn man etwas Geniales entwickeln 
will, dann schon. Aber noch viel mehr braucht man solide Entwickler, die 
ihren Job beherrschen ohne unbedingt Genies zu sein.

Nicht jede Aufgabe in einer Firma ist super interessant und super 
kreativ. Dennoch muss die Arbeit erledigt werden.

von Reinhard S. (rezz)


Lesenswert?

Mark B. schrieb:
> Nicht jede Aufgabe in einer Firma ist super interessant und super
> kreativ. Dennoch muss die Arbeit erledigt werden.

Bei vielen Produkten wäre es nicht schade, wenn die Arbeit nicht 
erledigt worden wäre :D

von Ein T. (ein_typ)


Lesenswert?

Mark B. schrieb:
> Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn
> das Requirements Management nichts taugt. Wenn der Vertrieb dem Kunden
> sonstwas verspricht - aber selbst auf Nachfrage nicht präzise sagen
> kann, was dem Kunden denn nun alles verkauft wurde - was willste dann
> machen?

Also ich hole dann den Michael "laberkopp" B., der im Nachbarthread [1] 
alle zu "Idioten und Pfeifen" erklärt, die nicht alles vorausplanen 
können. ;-)


[1] Beitrag "Re: SCRUM und die Arbeitsweise von Selbständigen"

von Rudi R. (rudi_r)


Lesenswert?

Mark B. schrieb:
>
> Braucht man auch geniale Entwickler? Wenn man etwas Geniales entwickeln
> will, dann schon. Aber noch viel mehr braucht man solide Entwickler, die
> ihren Job beherrschen ohne unbedingt Genies zu sein.

Ja, die braucht es auch. Gibt es aber auch zu wenig. Ich habe schon 
einige Leute darüber nölen hören, die fachfremd sind, Software 
entwickeln, aber der Meinung sind, man müsste auf das, was in den 
schlauen Büchern steht, komplett pfeifen. Es verlangt ja niemand, dass 
man gleich den nächsten Videokompressionsalgorithmus entwickelt. Aber 
selbst von einem soliden Entwickler erwarte ich solide Kenntnisse und 
die sehe ich häufig nicht. Man guckt in leere Augen, wenn das Wort 
Observer-Muster fällt. Die kennen nur oft nur die in der Firma 
verwendeten Muster und Idiome.

Franko S. schrieb:
> Vielleicht konnte er ArguUML nicht bedienen.

Das wäre keine Entschuldigung. Er hat sich da offensichtlich nicht 
bemüht, mehrere Zeichenblätter aufzumachen. Unwichtige Felder konnte man 
da meines Wissens auch ausblenden. Er hat diese Möglichkeiten nicht 
gefunden, weil er sie nicht gesucht hat. Und warum hat er sie nicht 
gesucht? Weil er den Sinn der UML nicht verstanden hat. Der Sinn war 
nie, bis ins letzte Detail alles zu beschreiben, sondern zu 
visualisieren, was der Wesenskern der Architektur ist und von Teilen der 
Architektur ist.

Ich glaube, das kommt daher, dass viele gar nicht mehr auf Papier 
Gedanken bringen, sondern meinen, man müsse unbedingt Werkzeuge wie 
ArgoUML und Enterprise Architect. Ich hingegen skizziere regelmäßig 
meine Architekturen auf Papier. Der Traum, das man in einem UML-Tool auf 
einen Knopf drückt und es kommt gescheiter Code heraus, ist ja auch 
zerplatzt.

Ein T. schrieb:
> Also ich hole dann den Michael "laberkopp" B., der im Nachbarthread [1]
> alle zu "Idioten und Pfeifen" erklärt, die nicht alles vorausplanen
> können. ;-)

Man muss wissen, wissen, mit welchem Imponderabilien man leben kann und 
mit welchen nicht. Ich gestalte Software mit Strategienklassen so, dass 
da schnell etwas austauschbar gestaltet ist und ich erstmal einen 
Billig-Strategie implementiere, die halbwegs robust ist und andere 
Entwickler nicht aufhält. Schlimm finde ich es, wenn in dem Moment, wenn 
ich noch so viele andere Aufgaben habe, Leute um die Ecke kommen, und 
die endgültige Strategie stundenlang diskutieren wollen. Da gehört dann 
auch Selbstbewusstsein hinzu, zu sagen, dass dazu im Moment keine Zeit 
sei. Ich musste in meinem letzten Projekt mehrfach den Projektleiter 
kontra geben.

Imponderabilien, mit denen man nicht leben kann, sind grundlegende 
architektonische Entscheidungen. Wenn man weiß, dass etwas suboptimal 
ist und später auch schwer herausoperierbar ist, sollte man sich genau 
überlegen, ob es das wert ist. Auch schon mehrfach erlebt. Bestes 
Beispiel sind BIRT-Report. Ein fürchterliches Framework. Das 
Versprechen, ein Eclipse-Plugin übernimmt die meiste Arbeit. Nun war die 
Benutzung dieses Plugins eine Wissenschaft für sich und nach einem 
kleineren Update des Eclipses oder des Plugins schon wieder 
inkompatibel. Was ich machen würde, wenn um Statistiken geht: Rohdaten 
werden gesammelt und weggeschrieben, und man bietet REST-Schnittstellen 
an, mit denen sich Python Pandas oder R verbinden kann. Bei uns wird 
zwar nicht mehr BIRT verwendet, denn man hat daraus gelernt, aber man 
fummelt mit JGraph und Konsorten Zeugs zusammen, wo ich sehe, dass da 
viel Entwicklerarbeit dahintersteckt, aber mein Ansatz, eine 
Schnittstelle für einen Profitool zu schreiben, viel besser und 
schneller wäre. (Ich habe sowas mal geschrieben.) Nur setzt sich diese 
Idee nur schlecht durch, weil dann wieder Vorbehalte kommen, Java könne 
man doch und der ganze Nonsens. Die Folge ist aber, dass man falsche 
Statistiken und Diagramme hat, weil nicht jedem Entwickler klar ist, was 
ein Durchschnitt ist.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Man guckt in leere Augen, wenn das Wort
> Observer-Muster fällt. Die kennen nur oft nur die in der Firma
> verwendeten Muster und Idiome.

Da gibt es m.E. 2 Arten von "Enttäuschungen":

A) Leute, die das Pattern kennen, sich über alle Aspekte vortrefflich 
austauschen können und letztendlich 0 Erfahrung damit haben. Das wäre 
OK, dafür wurden sie ja kanonisiert. Problematisch wird es, wenn das 
Muster dann nur halb auf das Problem passt.

B) Leute, die das Pattern nicht kennen, also auch nicht das Vokabular, 
aber jahrelange Erfahrung bei dessen Implementierung besitzen. Die 
Pattern waren ja nicht neu sondern beschrieben und benannten 
Best-Practices, die wie Dein Beispiel schon in Assembler umgesetzt 
wurden.

von Cyblord -. (cyblord)


Lesenswert?

Bruno V. schrieb:
> B) Leute, die das Pattern nicht kennen, also auch nicht das Vokabular,
> aber jahrelange Erfahrung bei dessen Implementierung besitzen. Die
> Pattern waren ja nicht neu sondern beschrieben und benannten
> Best-Practices, die wie Dein Beispiel schon in Assembler umgesetzt
> wurden.

Ja nur wenn man die Terminologie beherrscht kann man sich halt schnell 
und effizient austauschen. Deshalb ist das wichtig.
Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben, 
aber mal zufällig eins implementiert haben bringen einen nicht weiter.

von Bernd G. (Gast)


Lesenswert?

Mark B. schrieb:
> Und wie viele "Brot-und-Butter" Produkte, mit denen
> ein großer Teil des Umsatzes erwirtschaftet wird?

B&B Produkte sind die in die Jahre gekommenen ehemaligen 
Top-Innovationen.

Cyblord -. schrieb:
> die noch nie von Pattern gehört haben
hör mir blos auf mit "pattern" und anderem Entwicklergedöhns!

Rudi R. schrieb:
> Imponderabilien
Genau die, ja, das sind die Besten.
(Ich geh jetzt googlen, was das ist ...)

von Mark B. (markbrandis)


Lesenswert?

Bernd schrieb:
> B&B Produkte sind die in die Jahre gekommenen ehemaligen
> Top-Innovationen.

Je nun, irgendwann mal war alles neu. Auch Brot und Butter wurden einst 
erfunden. Oder vielleicht auch per Zufall entdeckt.

von Franko S. (frank_s866)


Lesenswert?

Cyblord -. schrieb:
> Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben,
> aber mal zufällig eins implementiert haben bringen einen nicht weiter.
Wie geht der Spruch?
Ein Nicht OO-Entwickler hat Probleme in seinem Programm. Dann kommt ein 
OO-Fanboi angetanzt und sagt ihm dass das daran läge, weil er keine 
Pattern nutzt. Dann geht der Fanboi wieder an seinen Rechner und grübelt 
über seine ProblemFactories.

von Cyblord -. (cyblord)


Lesenswert?

Franko S. schrieb:
> Cyblord -. schrieb:
>> Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben,
>> aber mal zufällig eins implementiert haben bringen einen nicht weiter.
> Wie geht der Spruch?
> Ein Nicht OO-Entwickler hat Probleme in seinem Programm. Dann kommt ein
> OO-Fanboi angetanzt und sagt ihm dass das daran läge, weil er keine
> Pattern nutzt. Dann geht der Fanboi wieder an seinen Rechner und grübelt
> über seine ProblemFactories.

Pattern sind nicht auf OO beschränkt. Den Rest deiner Ausführungen und 
Gedanken kann und sollte man sich schenken.

von Franko S. (frank_s866)


Lesenswert?

Cyblord -. schrieb:
> Pattern sind nicht auf OO beschränkt. Den Rest deiner Ausführungen und
> Gedanken kann und sollte man sich schenken.

[ ] Das hast den Kern des Spruches erfasst.
[X] Einen Rest gibt es nicht.
[X] Du bist vermutlich besoffen.

von Ein T. (ein_typ)


Lesenswert?

Steve van de Grens schrieb:
> In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held
> gar keiner ist. Hochmut kommt vor dem Fall.

Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das 
aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was 
ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das 
erdet. :-)

von Mark B. (markbrandis)


Lesenswert?

Ein T. schrieb:
> Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das
> aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was
> ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das
> erdet. :-)

Schrödingers Programmierer:
Er schreibt im gleichen Projekt sowohl guten als auch schlechten Code. 
;-)

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Ein T. schrieb:
> Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das
> aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was
> ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das
> erdet. :-)

Und wenn du mit der Zeit bei der Betrachtung alter eigener Lösungen 
immer mehr von der ersten und immer weniger von der zweiten Variante 
findest, dann kannst du es als Indikator des Alterns ansehen. :)

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

(prx) A. K. schrieb:
> Und wenn du mit der Zeit bei der Betrachtung alter eigener Lösungen
> immer mehr von der ersten und immer weniger von der zweiten Variante
> findest, dann kannst du es als Indikator des Alterns ansehen. :)

Das Alter funktioniert leider in beide Richtungen... :-)

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> Ein Projekt, nur mit mir alleine, das wär's doch.

Ja du bist der tollte Hecht im Karpfenteich, in Selbstbeweihräucherung 
bekommst du ne Eins mit Sternchen.

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Ein Projekt, nur mit mir alleine, das wär's doch.

Vielleicht kann Dir jemand eine Webseite mit Unbekleideten empfehlen, 
und der Erfolg Deines Projekts wird auf der Hand liegen. Viel Spaß! :-)

von Andi (chefdesigner)


Lesenswert?

Steve van de Grens schrieb:
> Im Team muss man so entwickeln, dass alle Kollegen durch blicken.

Die Frage ist doch, wie sehr sie durchblicken müssen, um ihre Arbeit zu 
machen. Kann kann unmöglich alle Details der Überlegungen und 
Festlegungen der Kollegen durchschauen. Es geht darum, genau das 
richtige zu wissen und dazu müssen die Teilnehmer aktiv kommunizieren. 
Solche Dinge sind es, die über den Erfolg eines Teams entscheiden und 
nicht, ob es nach Scrum geht oder sonst irgendwie.

Mit diesem transparenten Arbeiten tun sich aber viele schwer, sondern 
kommunizieren nur das Eingeforderte und hocken ansonsten auf ihren 
Lösungen. Auch wenn es keine Absicht ist, haben sehr viele gebildete 
Akademiker eine Problem mit bildlichen und textbasierten Darstellungen 
ihrer Überlegungen, sodass es überhaupt erst möglich wäre, das es ein 
anderer plausibilisert oder gar mitdenkt, bzw irgendwann weiterwickelt. 
Sie haben auch Probleme einzuschäzen, wieviel sie wann offenbaren und 
aktiv darstellen müssen, weil sie die Schnittstelle zwischen den 
Bearbeitern nicht bedienenen können. Oftmals hört man, der hätte ja 
fragen können. Solches Wirken ist aber nötig und essenziell für eine 
gute Zusammenarbeit. Wenn das fehlt, läuft nichts.

Dagegen hilft auch das Scrummen nicht. Das verschlimmert das Problem 
eher.

von Markus H. (dasrotemopped)


Lesenswert?

Scrum löst so viel Zustimmung im Management aus weil es eine Steigerung 
der Produktivität verspricht. Produktivität ist der einzige Maßstab, der 
für das Management relevant ist. Leider kann das Management die 
Produktivität bei Software nicht beurteilen. Was ist schell 
programmieren, wann ist das Arbeitsergebnis Ausschuss oder hochwertig. 
Das Unwissen wird gemessen in "der Kunde/Anwender ist zufrieden (aka 
gibt bei uns Geld aus, Umsatz mit dem Softwareprodukt)". Scrum Begriffe 
werden fehlinterpretiert ( Sprint - alle rennen mit voller Energie und 
bis zur Erschöpfung zum Ziel, Ticket - zähle die Tickets und du kannst 
die Produktion von Software quantifizieren, scrum Rollen - 
Verantwortliche die man zur Rechenschaft zieht wenn der Kunde meckert ( 
Scrum Master - Termin nicht eingehalten, Programmierer - Bug in 
Softwarepaket vom Ticket ). Scrum war gedacht um Entwicklungsprozesse zu 
organisieren durch Experten, Scrum wird benutzt um Entwicklungsprozesse 
unter Produktivitätszwang zu setzen durch Fachfremde. Der Knoten lässt 
sich nicht lösen, darum bekommen Programmierer oft kein Gehalt sondern 
Schmerzensgeld. Das Grundübel lautet immer : ich brauche 1000 Zeilen 
Code, wer macht das billiger in kürzerer Zeit. Firmen, die ihre eigene 
Software einsetzen müssen, um Geld zu verdienen, machen nicht 
automatisch besseren Code, aber sie stehen unter einem Selektionsdruck.

Beispiel gaming: 1 Spiel programmieren, das über Jahre Geld bringt oder 
100 Casual Games, die nur kurz relevant bleiben. Das eine Spiel muss 
exzellent sein, die 100 Games können Massenschund sein, müssen es aber 
nicht.

von Markus H. (dasrotemopped)


Lesenswert?

Das Management ist bei der Softwareentwicklung in folgender Situation 
gefangen:
Vor ihnen stehen 2 Fernseher, auf jedem läuft eine Kochschow, in dem ein 
Team ein Menü zubereitet. Die eine Show dauert 30min, die zweite Show 
dauert 45min. In beiden Shows gibt es viel Drama, Action, glückliche 
Momente. Am Ende muss das Management sagen welches Essen sie auf die 
eigene Speisekarte bringen und zu welchem Preis. Wie müsste die 
Begründung aussehen und wie ist die Begründung in der Realität ?

Scrum verspricht eine faktenbasierte Bewertung ohne das Essen geschmeckt 
zu haben.

von Markus H. (dasrotemopped)


Lesenswert?

Scrum wäre längst abgeschafft wenn das Management nicht darin ein 
Werkzeug für sich selbst sehen würde. Ob scrum für die Entwickler 
nützlich ist, ist nur zweitrangig.

von Rainer Z. (mrpeak)


Lesenswert?

Solange Scrum das Weisungsrecht fachlicher und disziplinarischer 
Vorgesetzter nicht vollständig ersetzt, ist Scrum eine Clownshow.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Markus H. schrieb:
> Produktivität ist der einzige Maßstab, der
> für das Management relevant ist.
Na die Qualität und das Ergebnis = Kundenbewertung wird schon auch eine 
Rolle spielen, denke ich :-)

Die Prouktivität ist natürlich die am besten zu bewertende Größe in 
Sachen Kosten und dem Verhältnis von Verkaufbarkeit, Marktreserve und 
der Umsatzerwartung und eben den negativ wirkenden Kosten, welche die 
Rentabilität mindern oder sogar ins Negative verkehren können. Das kann 
die Geschäftsführung ja direkt sehen, oder sie könnte es jedenfalls:

> Leider kann das Management die
> Produktivität bei Software nicht beurteilen.
Nur auf den ersten Blick! Das lässt sich durchaus machen, wenn man die 
Zeiten für einzelne Tätigkeiten mitprotokolliert, einschließlich der 
Kosten und Zeiten für Planung und Gespräche, den Aufwand für Orga, 
Schulungen und Trainings (auch Scrumtrainings !), aber auch dem Aufwand 
der späteren Inbetriebnahme und der Fehlerbehebung in Sachen Garantie! 
Das sind wesentliche Komponenten!

Besonders dann, wenn es nicht nur um reine Softwareprodukte geht, 
sondern um Software oder firmware, die in großen Geräten sitz, die dort 
die Funktion macht, ist das so, weil sie in der Entwicklung nur einen 
Teil der Kosten verursacht, aber bei Fehlfunktionen zu enormen Aufwänden 
und Kosten bei der IB* und der IM* führt.

Da zeigt sich, wie wichtig das Kriterium der qualitativ soliden und 
vollständigen Entwicklung der SW vor deren Entwicklungsgeschwindigkeit 
und dem Fertigstellungszeitpunkt ist! Was vorneweg nicht eingeplant 
wurde, wird hinterher sehr viel teuer. Und es zeigt sich, dass man schon 
bei der Entwicklung auf die IB* und die IM*-Anforderungen Rücksicht 
nehmen muss. Dazu aber sind viele Entwickler mit der reduzierten Sicht 
nicht in der Lage. Wenn dann von Außen nicht das Team mit solchen 
Kriterien versorgt wird, sie also Teil der Aufgabenstellung sind, dann 
kriegt man aus dem Teamentscheid ein unzureichendes Ergebnis heruas.

Genau das zeigt sich durch solche Kostennachbetrachtungen bei Projekten 
und besonders tritt der Unterschied dann zutage, wenn man wenn diese 
Daten hat bevor und nachdem etwas an den Prozessen geändert wurde. 
Soweit das Kunden von mir gemacht haben, hat sich gezeigt, dass sich 
durch Scrum nichts verbessert hat. Es gab nur mehr Kosten durch 
Diskussionen. Im Gegenteil: Nicht wenige haben Scrum eben deshalb wieder 
rausgeschmissen und sich auf die genauere Definition der Ziele durch 
kompetente(re) Systemingenieure konzentiert, damit die umsetzenden Teams 
genauere Vorgaben hatten.

Es hat sich nämlich gezeigt, dass der große Vorteil von Scum, nämlich 
das Reagieren auf sich ändernde Wünsche in solchen Projekten extrem 
nachteilig ist, weil das Zulassen solcher Änderungen immer zu erhöhten 
Aufwänden und Risiken in späteren Phasen von Projekten führt. Es ist 
daher besser und effektiver, man setzt den Rahmen genauer und investiert 
Zeit, um zuverweiden, dass sich Anforderungen mitten drin ändern.

-----------------
*IB = InBetriebnahme
*IM = InMarktbringung

: Bearbeitet durch User
von Le X. (lex_91)


Lesenswert?

Markus H. schrieb:
> Das Grundübel lautet immer : ich brauche 1000 Zeilen
> Code, wer macht das billiger in kürzerer Zeit.

In meinen 1,5 Jahrzehnten in der (Embedded-) Softwareentwicklung, in 
diversen Positionen, habe ich noch nie einen Manager, einen 
Projektleiter, einen Kunden oder einen Zulieferer erlebt der sich 
irgendwas aus lines of code macht.
Niemand zählt die loc, niemand verlangt so-und-soviel loc und niemand 
zahlt nach loc oder lässt sich für loc bezahlen.
Überhaupt ist der Begriff in meiner Branche nichtexistent, ich hör das 
nur dauernd von Heulsusen im Netz.

von Bernd G. (Gast)


Lesenswert?

Rainer Z. schrieb:
> Solange Scrum das Weisungsrecht fachlicher und disziplinarischer
> Vorgesetzter nicht vollständig ersetzt, ist Scrum eine Clownshow.

Heißt das, dass aus deiner Sicht dies ein Ziel sein sollte? - Dass Scrum 
die Führung ersetzt? Scrum / der ScrumMaster soll sich doch aus dem 
fachlichen raushalten und keine Aussage dazu machen. Für das Fachliche 
gibt es keine Vorgaben. Das muss also gänzlich aus der Gruppe kommen.

Ich halte das für Theorie. Hat auch noch nirgends funktioniert.

Le X. schrieb:
> Markus H. schrieb:
>> Das Grundübel lautet immer : ich brauche 1000 Zeilen
>> Code, wer macht das billiger in kürzerer Zeit.
>
> In meinen 1,5 Jahrzehnten in der (Embedded-) Softwareentwicklung, in
> diversen Positionen, habe ich noch nie einen Manager, einen
> Projektleiter, einen Kunden oder einen Zulieferer erlebt der sich
> irgendwas aus lines of code macht.

Mal abgesehen, dass ich das seltsam finde, dass einer in "1,5 Jahren" 
diverse Position gehabt haben will, scheint mir das anders gemeint 
gewesen zu sein: Es geht nicht um eine konkrete Codezeilenzahl. Die 
kennt der Beauftrager eh nicht im Voraus. Aber sie suchen immer den 
Billigsten. Die Hauptaufgabe des Programmierens kriegen deshalb gerne 
die Anfänger, die nichts anderes können.

von Wegstaben V. (wegstabenverbuchsler)


Lesenswert?

B. schrieb:
> dass einer in "1,5 Jahren" diverse Position gehabt haben will,

Er schrub von 1,5 Jahrzehnten. Das sind 15 Jahre, nicht 1,5 Jahre

von Bernd G. (Gast)


Lesenswert?

Wegstaben V. schrieb:
> Er schrub von 1,5 Jahrzehnten.
ok, überlesen. Dann lassen wir das beiseite.

Die Kernfrage bleibt: Soll Scrum den technischen Fachverantworlichen 
ersetzen? Das Ideal des auf mehrere Personen verteilten Gehirns? Wie ich 
schon schrieb (seit wann heißt das "schrub") habe ich damit sehr 
schlechte Erfahrungen gemacht. Das gibt Kompetenzgerangel, 
Positionskampf und zieht ellenlange Diskussionen über mögliche Lösungen 
nach sich. Ohne einen technischen Projektleiter, der Verantwortung hat 
und die Vorgaben macht, geht da nichts.

von Franko S. (frank_s866)


Lesenswert?

Neulich in einer Softwarebude:
Bieten Scrumberatung für andere Firmen an, entwickeln auch selber 
Software. Frage: Verwendet ihr auch Scrum und wie? AW: Äh ne das stört 
nur, wir machen mit Scrum nur Beratung. Wenigstens waren sie ehrlich.

von Michael B. (laberkopp)


Lesenswert?

Franko S. schrieb:
> Wenigstens waren sie ehrlich.

Es ist immer klug, dem potentiellen Konkurrenten Steine in den Weg zu 
rollen um selbst flinker am Ziel zu sein.

von Cyblord -. (cyblord)


Lesenswert?

Franko S. schrieb:
> Neulich in einer Softwarebude:
> Bieten Scrumberatung für andere Firmen an, entwickeln auch selber
> Software. Frage: Verwendet ihr auch Scrum und wie? AW: Äh ne das stört
> nur, wir machen mit Scrum nur Beratung. Wenigstens waren sie ehrlich.

Mal wieder Geschichten ausm Paulanergarten.

von Franko S. (frank_s866)


Lesenswert?

Cyblord -. schrieb:
> Mal wieder Geschichten ausm Paulanergarten.
Der hat noch geschlossen, dehalb wahr.

von Bernd G. (Gast)


Lesenswert?

Cyblord -. schrieb:
> Geschichten ausm Paulanergarten.

In einem solchen Umfeld dürfte der Scrum-mist erdacht worden sein.

von Ein T. (ein_typ)


Lesenswert?

🐻 Bernie - Bär schrieb:
> Scrum-mist

Keine Ahnung, aber felsenfeste Vorurteile. Du demonstrierst ziemlich 
gut, was das Problem mit Projektleitern ist, die niemandem zuhören 
können oder wollen und sich überall einmischen, weil sie alles besser zu 
wissen glauben. Danke.

von Bernd G. (Gast)


Lesenswert?

Ein T. schrieb:
> Keine Ahnung, aber felsenfeste Vorurteile.

Erfahrung lieber Mr. T, Erfahrung. Scrum wird wie so vieles was aus den 
USA kommt, mit einem selbstverständlichen Automatismus gehyped, ohne 
jegliche Hinterfragung. Das System eignet sich bestenfalls für 
Ausschnitte der Projektlandschaft und der täglichen Arbeit, nur können 
das viele Entwickler mit ihrer schmalbandigen Erfahrung nicht erkennen.

von Ein T. (ein_typ)


Lesenswert?

🐻 Bernie - Bär schrieb:
> das viele Entwickler mit ihrer schmalbandigen Erfahrung nicht erkennen.

Was für ein Glück, daß ich nicht immer nur Entwickler war und ein 
bisschen mehr als nur "schmalbandige Erfahrung" gesammelt habe. Aber 
auch hier zeigt sich wieder das alte Problem mit der Selbstüberschätzung 
und -Überhöhung bei manchen Projektleitern, die sich selbst für klüger 
halten als alle anderen.

von Rbx (rcx)


Lesenswert?

Rudi R. schrieb:
> Und das scheint mir auch ein kulturelles Problem, dass in
> anderen Kulturen kräftig geklappert wird, speziell die Amerikaner.

War wohl damals in der DDR auch beliebt. Das kann man sogar heute noch 
beobachten, und als Sahnehäubchen obendrauf: Verlogenheit.
Das muss aber nicht automatisch heißen, die Leute wären unfähig.
Man hat nicht viel mehr dagegen, als mit guten Beispiel voranzugehen. 
Also Sorgfalt da wo sie angezeigt ist, Kompromisse mit allen Beteiligten 
(nicht nur mit einigen), Liebe zur Qualität usw.
Ein anderer Punkt wäre noch Korruption. Ehrlichkeit und Anstand gehören 
auch zum Leben, nicht nur abkassieren, schummeln oder die Mitmenschen 
für PlemPlem halten.

Einen der besseren Texte dazu gibt es beim Simplicssimus in der 
ungekürzten Ausgabe wo es ums Würfeln auf einem "Spielplatz" geht. Sehr 
unterhaltsam, sehr merkwürdig.
https://www.projekt-gutenberg.org/grimmels/simpl/simpl220.html

von Franko S. (frank_s866)


Lesenswert?

Interessant ist dass es in Big Techfirmen keine grosse Rolle spielt:

https://blog.pragmaticengineer.com/project-management-at-big-tech/

Da zählt kein cargo cult sondern nur output.

von A. B. (funky)


Lesenswert?

🐻 Bernie - Bär schrieb:
> Die Kernfrage bleibt: Soll Scrum den technischen Fachverantworlichen
> ersetzen? Das Ideal des auf mehrere Personen verteilten Gehirns

Nein, soll und will es nicht.
Scrum ist ausserdem für komplexe Projekte gedacht wo eben nicht schon 
jeder alle Antworten kennt sondern diese iterativ erarbeitet sollen. Und 
der projektverantwortliche ist der Product Owner. Der kippt 
Anforderungen ein & klärt Dinge ab.

Ach so... Und Hirn einschalten ist auch noch erforderlich wenn man Scrum 
einsetzt

von Franko S. (frank_s866)


Lesenswert?

https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm

Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Franko S. schrieb:
> Lest euch das mal durch

wenn das jeder genau durch liest - es sind ja an die 100 Punkte - dann 
vergeht mehr Zeit, als man mit dem besten Scrum jemals wieder reinholen 
kann :-)

A. B. schrieb:
> der projektverantwortliche ist der Product Owner. Der kippt Anforderungen
Da sehe ich aber ein Problem:

Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern 
praktisch immer ein ganzes Bündel an Personen, das die Anforderungen 
definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht 
es deutlich mehr, als einen "product owner". Oder aber das "product" ist 
nur eine kleine Subkomponente, die wirklich von einer Person gehandhabt 
werden kann.

von Rainer Z. (mrpeak)


Lesenswert?

Franko S. schrieb:
> https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm
> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt

Die Seite ist Gold: Einfach mal die Hauptbegriffe durch 
Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten. 
Vielleicht öffnet das den Fanboys die Augen.

von A. B. (funky)


Lesenswert?

J. S. schrieb:
> A. B. schrieb:
>> der projektverantwortliche ist der Product Owner. Der kippt Anforderungen
> Da sehe ich aber ein Problem:
>
> Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern
> praktisch immer ein ganzes Bündel an Personen, das die Anforderungen
> definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht
> es deutlich mehr, als einen "product owner". Oder aber das "product" ist
> nur eine kleine Subkomponente, die wirklich von einer Person gehandhabt
> werden kann.

Er soll das ja auch nicht alleine machen sondern zusammen mit den Leuten 
erarbeiten die davon Plan haben. Dafür gibt's dann das Product Backlog 
Refinement z.B.
Außerdem kann er solche Aufgaben auch delegieren wenn es sinnvoll 
erscheint. Er bleibt aber fürs Gesamtergebnis verantwortlich und sollte 
es in die richtige Richtung lenken.

Wie gut die Theorie dann in der Praxis funktioniert sei mal 
dahingestellt

von Wegstaben V. (wegstabenverbuchsler)


Lesenswert?

Rainer Z. schrieb:
> Die Seite ist Gold: Einfach mal die Hauptbegriffe durch
> Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten.
> Vielleicht öffnet das den Fanboys die Augen.

"Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine 
gemeinsame Vision für den Super Circle. Er schafft einen offenen und 
transparenten Austausch innerhalb des Super Circles und stimmt sich mit 
internen und externen Stakeholdern des Super Circles ab."

klingt für mich teilweise wie Satire. Kann sich da wirklich jemand "vom 
Fussvolk" mit so einer Sprache identifizieren? Jemand ist da anscheinend 
in einen englischen Sprach-Topf gefallen und kommt da nicht wieder raus 
...

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

Rainer Z. schrieb:
> Franko S. schrieb:
>> https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm
>> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt
>
> Die Seite ist Gold: Einfach mal die Hauptbegriffe durch
> Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten.
> Vielleicht öffnet das den Fanboys die Augen.

Nenne konkrete Beispiele und hau nicht so sinnlos „Alles ist Scheiße“ in 
den Raum. Dann können wir darüber sprechen, was jeder verstanden hat.

PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich 
erfolgreich, was man von vielen anderen Banken nicht sagen kann…

von Ein T. (ein_typ)


Lesenswert?

Franko S. schrieb:
> Interessant ist dass es in Big Techfirmen keine grosse Rolle spielt:
>
> https://blog.pragmaticengineer.com/project-management-at-big-tech/
>
> Da zählt kein cargo cult sondern nur output.

Das behauptet zwar der von Dir verlinkte Artikel, aber wenn ich dazu 
einmal die Internet-Suchmaschine meines erträglichsten Mißtrauens 
bemühe, sieht die Sache ganz anders aus, als der Artikel beinhaltet. 
Alleine unter den ersten Suchergebnissen finden sich eine Stellenanzeige 
von Microsoft für einen Scrum Master und ein Artikel über Google Sprints 
-- weiter habe ich nicht geschaut, weil mir die Sache nicht wichtig 
genug ist und mir die Behauptungen aus dem  Artikel damit bereits 
widerlegt zu sein scheinen.

von Ein T. (ein_typ)


Lesenswert?

J. S. schrieb:
> Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern
> praktisch immer ein ganzes Bündel an Personen, das die Anforderungen
> definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht
> es deutlich mehr, als einen "product owner".

Das stimmt. Es braucht dazu aber natürlich auch mehr als einen 
"Projektleiter" "technischen Fachverantwortlichen", und deswegen wird 
unbedingt eine Methode zur Kommunikation zwischen diesen Leuten nötig.

von Gerhard M. (ggcode)


Lesenswert?

Uwe D. schrieb:
> PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich
> erfolgreich, was man von vielen anderen Banken nicht sagen kann…

so so ..... ob das an scrum liegt oder einfach am Markt?

https://www.handelsblatt.com/finanzen/banken-versicherungen/banken/deutsche-bank-bestes-ergebnis-seit-15-jahren-aber-anleger-sind-enttaeuscht/28957940.html

https://www.handelsblatt.com/finanzen/banken-versicherungen/banken/jahreszahlen-niederlaendische-grossbank-ing-enttaeuscht-mit-ausblick-aktie-buesst-ein/28959120.html

fühlt sich eher wie eine Marketingstrategie an.

von Roland F. (rhf)


Lesenswert?

Uwe D. schrieb:
> Dann können wir darüber sprechen, was jeder verstanden hat.

Was ist ein Squad?

rhf

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

Gerhard M. schrieb:
> Uwe D. schrieb:
>> PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich
>> erfolgreich, was man von vielen anderen Banken nicht sagen kann…
>
> so so ..... ob das an scrum liegt oder einfach am Markt?
> …
> fühlt sich eher wie eine Marketingstrategie an.

„Agil“ heißt, schnell auf Richtungsänderungen zu reagieren. Alles mit 
„Marketing“ zu erschlagen ist ein schwaches Argument.

Das WARUM kann ich nicht direkt beantworten, nur befürworten.
Siehe: 
https://www.manager-magazin.de/unternehmen/agiles-arbeiten-wie-radikal-nick-jue-die-bank-ing-umbaut-a-57b3b24d-b6e0-491a-8004-f01e2041691d

Oder 
https://www.wiwo.de/erfolg/management/agiles-arbeiten-wer-nicht-aufpasst-dem-fliegt-das-projekt-um-die-ohren/19988386.html

https://entwickler.de/agile/agile-im-konzern-kann-das-funktionieren-001

Nachtrag: Ich liebe die intellektuell Überforderten, die reflexhaft 
negativ bewerten anstatt in einen Dialog zu kommen.

: Bearbeitet durch User
von Rainer Z. (mrpeak)


Lesenswert?

Uwe D. schrieb:
> Rainer Z. schrieb:
>> Franko S. schrieb:
>>> https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm
>>> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt
>>
>> Die Seite ist Gold: Einfach mal die Hauptbegriffe durch
>> Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten.
>> Vielleicht öffnet das den Fanboys die Augen.
>
> Nenne konkrete Beispiele und hau nicht so sinnlos „Alles ist Scheiße“ in
> den Raum. Dann können wir darüber sprechen, was jeder verstanden hat.

"Der Plumbus ist verantwortlich für das „Was“ (operationale Ebene) in 
einem Hurtz und für die Maximierung des Wertes der erledigten Arbeit. 
Der PB legt Ipsum fest und setzt Prioritäten bezüglich der 
zurückgestellten Arbeit des Hurtz."

von Bernd G. (Gast)


Lesenswert?

Wegstaben V. schrieb:
> Rainer Z. schrieb:
>> Die Seite ist Gold:

Man möge sich vor Augen führen, dass es sich bei der Firma um eine Bank 
handelt, die virtuell ist, also keine Filialen hat, und die zudem noch 
in den Niederlanden sitzt, wo viel seltsame Sachen geraucht werden.

Die ING hat z.B. in einem Anfall von Größenwahn Anfang des Jahres satte 
3,75% Zinsen fürs Tagesgeld ausgelobt und dann festgestellt, dass sie 
kaum neue Kunden, sondern nur neues Geld bekommen hat, das die Kunden 
(wie ich auch!) nur im Kreis gebucht haben, weil andere Banken wie die 
Postbank das auch gemacht haben. Hinzu kommen einige wenige Kunden, die 
in Brokermanier genau die maximale Anlagesumme von 100.000 eingebucht 
haben, um sie am 30.6.24 wieder zu entfernen.

Jetzt haben sie keinen Effekt müssen aber auf die Einlagen hohe Zinsen 
zahlen, die ihnen die Gewinne schmälern! Da das Geld- und Kreditgeschäft 
wegen der Baukrise zusammenbrutzeln und sie kein Goldgeschäft machen, 
gucken die Holländer jetzt in die Röhre!

Als Konsequenz geben sie jetzt nur noch 3,25% und noch weniger. Man sehe 
sich mal die lustige Werbung mit dem Basketballer Dirk Nowitzki an: Das 
Schild das er hochhält, ist ein Dummy , über den der neue Zinssatz 
drübergeblendet wird!

Eine einzige Lachnummer! Die Diba wird sich sowieso bald umgucken, weil 
sie ein großes Automatennetz betreibt und immer weniger Gewinne macht. 
Mal schauen, was sie ab 1.4. so anbieten, wenn wieder die EZB die 
Leitzinsen nicht erhöht ...

von Rudi R. (rudi_r)


Lesenswert?

Es gibt Neuigkeiten zu "meinem" Scrum-Projekt. Meine Warnungen an die 
richtige Stelle adressiert, haben nun dazu geführt, dass andere Leute 
mit dem Projekt betraut werden. Es hört nun hoffentlich auf mit der 
Sprinterei und Scrummerei. Auch der personelle Zusammensetzung des alten 
Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der 
Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war. 
Vielleicht mag ja das Scrum für irgendwelche Casual Games oder Websites 
vernünftig sein und wer immer Scrum macht und nicht anderes kennt, der 
wendet Scrum auf jedwedes Problem an.

von Bernd G. (Gast)


Lesenswert?

Rudi R. schrieb:
> Auch der personelle Zusammensetzung des alten
> Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der
> Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war.

aber genau da soll Scrum doch eigentlich Abhilfe schaffen, weil nur so 
unterschiedlich agierende Menschen zusammenarbeiten sollen.

Ein gut geformtes und etabliertes Team mit erfahrenen Personen ist auf 
einander eingespielt, hat für seine Produkte optimierte Prozesse und 
Abläufe und braucht kein simplifiertes, leicht erlernbares System wie 
Scrum.

Die heutige Fluktuation in den Firmen untergräbt natürlich die 
Ausbildung eines solchen stabilen System. Da sind die Firmen mit Schuld, 
die Mitarbeiter nur noch als austauschbare Resource ansehen.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Wegstaben V. schrieb:
> "Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine
> gemeinsame Vision für den Super Circle. Er schafft einen offenen und
> transparenten Austausch innerhalb des Super Circles und stimmt sich mit
> internen und externen Stakeholdern des Super Circles ab."
>
> klingt für mich teilweise wie Satire.
Stimmt irgendwie. Müsste man sich etwas ausdenken, um Scrum zu bashen 
würde es wohl auf so ein buzzword-Denglish hinauslaufen.

> Kann sich da wirklich jemand "vom
> Fussvolk" mit so einer Sprache identifizieren?
Nicht wirklich, aber rein inhaltlich macht es Sinn, wenn man das 
Denglish in althergebrachte Industriesprache übersetzt:

"Lead" -> der Anführende
"Super" -> "übergeordnet"
"circle" -> "Lenkkreis"
"Vision" -> Vorhaben
"Purpose" -> Zweck
"stakeholder" -> Interessensvertreter

Damit hätten wir:

Die den übergeordneten Lenkkreis anführende Person(engruppe) macht klare 
Vorgaben hinsichtlich der Zweckziele an den übergeordneten Lenkkreis 
selbst, sorgt für einen durchsichtigen Informationsfluss innerhalb 
desselben und stimmt sich mit den Interessensvertretern ab.

Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum.

Handelt es sich bei der Personengruppe nur um einen einzigen und bei den 
Lenkkreisen jeweils um die Abteilungs- und Teamleiter sowie bei den 
Interessensvertretern um das Produktmanagement, dann haben wir die 
typische Hierarchie: Es gibt 2 Kreise = Teams, deren Leiter ihrerseits 
ein Team bilden und ganz oben ist der "Führer". Würde sogar zu 1933 
passen :D

Im Prinzip ist es das gleiche wie das hier:

A. B. schrieb:
> Er soll das ja auch nicht alleine machen sondern zusammen mit den
> Leuten erarbeiten die davon Plan haben. Dafür gibt's dann das
> Product Backlog Refinement z.B.
> Außerdem kann er solche Aufgaben auch delegieren wenn es sinnvoll
> erscheint.

Ja, das berühmte "Product Backlog Refinement"!

Wer kennt es nicht? Hat es ja vorher nie gegeben, dass man über 
ausstehende Projektkenngrößen und Produktmerkmale gemäß des aktuellen 
und eventuell zuküftigen Plans gesprochen und seine Vorgehensweisen im 
Projekt angepasst hat. Wurde erst mit Scrum erfunden. Schön dass wir es 
nun haben.

: Bearbeitet durch User
von A. B. (funky)


Lesenswert?

wer sagt das es sowas nicht gab? Niemand! Auch Scrum nicht!

Scrum strukturiert dir das halt nur und gibt fixe, sinnvolle Termine 
vor, mit denen das outcome positiv beeinflusst werden kann.
Ob du dich dran hälst oder nicht ist immer noch dein Bier.

Scrum ist dafür da, Abläufe zu vereinheitlichen und gewisse Dinge & 
Zeitaufwände einfach sichtbar zu machen.

Und nicht das ich Scrum groß verteidigen würde(obwohl ich es nicht per 
se scheisse finde. Schlecht wirds nur, wenn irgendwo nix funktioniert 
und dann nur durch die Einführung von Scrum alles supi werden soll. Aber 
Läden wo das so läuft haben häufig noch ganz andere Probleme)

Man sollte aber auch mal festhalten: viele sogenannte "funktionierende & 
eingespielte" Teams sind das ja auch nicht wirklich. Man rührt halt seit 
Urzeiten im gleichen Fahrwasser, bloss nix ändern und wenn mir jemand in 
die Karten schauen kann, bin ich gleichmal angepisst hoch 10 und 
echauffier mich bisschen und aus meinen eingetrottenen Abläufen will ich 
mal gleich gar nicht raus

von A. B. (funky)


Lesenswert?

Bernd G. schrieb:
> Ein gut geformtes und etabliertes Team mit erfahrenen Personen ist auf
> einander eingespielt, hat für seine Produkte optimierte Prozesse und
> Abläufe und braucht kein simplifiertes, leicht erlernbares System wie
> Scrum.

das ist halt auch schon so ein Käse. Scrum ist nicht dafür da Produkte 
ohne Unbekannte einfach weiter zu warten.
Das ist ja genau dafür da, wo es große Komplexität und viele Unbekannte 
gibt, die man irgendwie einfangen & handlebar machen will.
Deine piefige, seit 30 Jahren zusammengefummelte & gut abgehangene 
Standardsoftware brauch auch kein Scrum mehr. Die kannste am besten 
gleich mit der Rostschaufel erschlagen

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

J. S. schrieb:
> Wegstaben V. schrieb:
>> "Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine
>> gemeinsame Vision für den Super Circle. Er schafft einen offenen und
>> klingt für mich teilweise wie Satire.
> Stimmt irgendwie. Müsste man sich etwas ausdenken, um Scrum zu bashen
> würde es wohl auf so ein buzzword-Denglish hinauslaufen.
>> Kann sich da wirklich jemand "vom
>> Fussvolk" mit so einer Sprache identifizieren?

Sich selbst als Fußvolk zu bezeichnen ist halt kein guter Ausgangspunkt 
für eine Zusammenarbeit als Team.

> Denglish in althergebrachte Industriesprache übersetzt:
> "Lead" -> der Anführende
> "Super" -> "übergeordnet"
> "circle" -> "Lenkkreis"
> "Vision" -> Vorhaben
> "Purpose" -> Zweck
> "stakeholder" -> Interessensvertreter

„Lead“ im Sinne von „Erfahren“
„Circle“ im Sinne von „Arbeitsgruppe (zum gleichen Thema)“
„Vision“ im Sinne von „ambitioniertes Ziel eines Unternehmens in der 
Zukunft“
„Stakeholder“ im Sinne von „die Betroffenen“

> Damit hätten wir:
> Die den übergeordneten Lenkkreis anführende Person(engruppe) macht klare
> Vorgaben hinsichtlich der Zweckziele an den übergeordneten Lenkkreis

Nö, das was hier so belächelt wird ist eine Möglichkeit, übergeordnet 
mehrere wichtige Projekte zu steuern.

Im klassischen Wasserfallmodell setze ich ein Programmanagement auf.


> Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum.

Das ist eine unzulässige Verallgemeinerung und gibt nicht wieder, was 
der Hauptzweck von agilen Methoden ist.

> A. B. schrieb:
>> Er soll das ja auch nicht alleine machen sondern zusammen mit den
>> Leuten erarbeiten die davon Plan haben. Dafür gibt's dann das
>> Product Backlog Refinement z.B.
> Ja, das berühmte "Product Backlog Refinement"!
> Wer kennt es nicht? Hat es ja vorher nie gegeben, dass man über
> ausstehende Projektkenngrößen und Produktmerkmale gemäß des aktuellen
> und eventuell zuküftigen Plans gesprochen und seine Vorgehensweisen im
> Projekt angepasst hat. Wurde erst mit Scrum erfunden. Schön dass wir es
> nun haben.
Im Refinement wird fachlich klargestellt, dass die Entwickler wissen was 
sie zu tun haben, das sie per Feedback bestätigen, was sie verstanden 
haben und in der Lage sind, den Aufwand zu schätzen. Zu dem fliegen alle 
Issues (Arbeitspakte) für das nächste Planning raus, wenn nicht alle 
Voraussetzungen zur Umsetzung vorliegen.

Der Unterschied: Im Wasserfallmodell ist ja schon festgelegt was 
gebraucht wird, auch der Aufwand wurde vor dem Start der Entwicklung 
ermittelt. Change Requests gibt es meist deshalb, weil „Besserwisser“ es 
nicht vorher eben nicht wussten was der Kunde braucht.

von Michael B. (laberkopp)


Lesenswert?

Uwe D. schrieb:
> Sich selbst als Fußvolk zu bezeichnen ist halt kein guter Ausgangspunkt
> für eine Zusammenarbeit als Team

Im Team ist ja jeder Hauptling.

Uwe D. schrieb:
>> Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum.
>
> Das ist eine unzulässige Verallgemeinerung und gibt nicht wieder, was
> der Hauptzweck von agilen Methoden ist.

Der Hauptzweck ist offenkundig nicht  dass ein Produkt zur Zufriedenheit 
des Kunden fertiggestellt wird, denn DAS war 1950 schon Hauptzweck.

Agil gilt eher, wie man dem Kunden möglichst lange hinhalten kann um 
möglichst wenig zu liefern und dafür möglichst viel aus der Tasche zu 
ziehen, und damit er am Ball bleibt tut man so als ob er in die Arbeit 
eingebunden ist. Das war 1950 noch nicht so.

A. B. schrieb:
> Scrum strukturiert dir das halt nur und gibt fixe, sinnvolle Termine vor

Tägliches Gequatsche und 3-wöchentliche Milestones, obwohl die 
Teilarbeitsschritte 1-40 Tage benötigen und der Kunde den 
Projektfortschritt monatlich sehen will und Auslieferungen halbjährlich 
(26 Wochen nicht durch 3 teilbar) ? Scrum ist offenkundig von Idioten 
für Idioten. Wie viele Mitarbeiter warten zum Sprintende damit sie den 
aktuellen Stand vorführen können und nicht halb-angefangenes 
unterbrechen müssen  bloss weil das idiotische Zeitraster nicht passt.

von A. B. (funky)


Lesenswert?

Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann dein 
cvs nicht branchen? Oder kopierst du Source Ordner um?

26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch. 
Nein! Doch! Ohhh!

Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß 
verteidigen wollen, aber einige der Kritikpunkte sind auch ziemlicher 
Quatsch

von A. B. (funky)


Lesenswert?

A. B. schrieb:
> Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann
> dein cvs nicht branchen? Oder kopierst du Source Ordner um?
> 26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch.
> Nein! Doch! Ohhh!
> Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß
> verteidigen wollen, aber einige der Kritikpunkte sind einfach ziemlicher
> Quatsch

von Michael B. (laberkopp)


Lesenswert?

A. B. schrieb:
> Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann dein
> cvs nicht branchen? Oder kopierst du Source Ordner um?
> 26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch.
> Nein! Doch! Ohhh!
> Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß
> verteidigen wollen, aber einige der Kritikpunkte sind auch ziemlicher
> Quatsch

Wenn man wie du offenkundig nie mit Scrum was zu tun hattest...

Scrum ist der Quatsch.

Vorführen heisst, ein lauffähiges Umfeld bereit zu halten, darin eine 
bestimmte Sequenz durchzuführen, an der andere Server und Dienste 
beteiligt sein können. Die Einrichtung dauert, der Umbau auf die nächste 
Story dauert auch. Fas bait man nicht hin und wieder her und wieder hin 
und wieder her. Zumindest nicht, wenn man noch klar im Kopf ist.

von A. B. (funky)


Lesenswert?

Du bist echt der geborene Laberkopp. Ist natürlich bei jeder Aufgabe so, 
dass man eine gesamte Serverfarm dafür herrichten muss. Ist klar. Du 
bist halt nur an wichtigen Sachen am fummeln dran

von Christoph Z. (christophz)


Lesenswert?

Michael B. schrieb:
> Vorführen heisst, ein lauffähiges Umfeld bereit zu halten, darin eine
> bestimmte Sequenz durchzuführen, an der andere Server und Dienste
> beteiligt sein können. Die Einrichtung dauert, der Umbau auf die nächste
> Story dauert auch. Fas bait man nicht hin und wieder her und wieder hin
> und wieder her. Zumindest nicht, wenn man noch klar im Kopf ist.

Ja, wer klar im Kopf ist (oder Faul wie die meisten die verstanden haben 
wozu Computer erfunden wurden), automatisiert das ganze. Jeder 
Entwickler muss ja zu jeder Zeit (mit oder ohne Sprint) seine aktuellen 
Änderungen testen können.
Dazu braucht es immer ein Testsystem. Diese Tests sind gefälligst 
reproduzierbar (Automatisierung, Snapshots, configuration as code, wie 
auch immer).
Dann purzeln hinten log-files, screenshots oder sonst was raus, das man 
dann "vorführen" kann.

Und für alle anderen:
Heute ist Freitag, nicht vergessen vor dem Wochenende noch "Push to 
production" zu machen...

von Andi (chefdesigner)


Lesenswert?

Uwe D. schrieb:
> er Unterschied: Im Wasserfallmodell ist ja schon festgelegt was
> gebraucht wird, auch der Aufwand wurde vor dem Start der Entwicklung
> ermittelt. Change Requests gibt es meist deshalb, weil „Besserwisser“ es
> nicht vorher eben nicht wussten was der Kunde braucht.

Da gehe ich bedingt mit, nur ist es eben nötig, vor dem Start der 
Entwicklung eine Aufwandabschätzung zu machen und zu checken, ob man das 
Projekt überhaupt machen kann. Da liegt doch der Hase im Pfeffer! Wird 
das unterlassen, läuft man in die "Scrumhölle" hinein und man stellt 
mittendrin fest, dass man das besser hätte sein lassen sollen.

von Andi (chefdesigner)


Lesenswert?

Michael B. schrieb:
> Agil gilt eher, wie man dem Kunden möglichst lange hinhalten kann um
> möglichst wenig zu liefern und dafür möglichst viel aus der Tasche zu
> ziehen, und damit er am Ball bleibt tut man so als ob er in die Arbeit
> eingebunden ist. Das war 1950 noch nicht so.

Aber auch da gehe ich mit. Die Offenheit gegenüber Änderungen wird dazu 
genutzt, keine Festlegungen gegenüber dem Kunden zu machen und ihn damit 
in die Pflicht zu nehmen, trotz Scrum sofort und verbindlich Vorgaben zu 
machen, weil es sonst gegen ihn verschleppend verwendet wird.

Sehen wir immer wieder. Das Team kommt mit Rückfragen an den PL, der der 
schickt uns die Fragenliste. 90% von dem hätten sie selber beantworten 
können, wenn sie einfach nur das Konzept umsetzen und ihren Job machen 
würden.

von Ein T. (ein_typ)


Lesenswert?

A. F. schrieb:
> Da gehe ich bedingt mit, nur ist es eben nötig, vor dem Start der
> Entwicklung eine Aufwandabschätzung zu machen und zu checken, ob man das
> Projekt überhaupt machen kann. Da liegt doch der Hase im Pfeffer! Wird
> das unterlassen, läuft man in die "Scrumhölle" hinein und man stellt
> mittendrin fest, dass man das besser hätte sein lassen sollen.

Na klar, das wird bei agiler Entwicklung natürlich nie gemacht.

A. F. schrieb:
> Aber auch da gehe ich mit. Die Offenheit gegenüber Änderungen wird dazu
> genutzt, keine Festlegungen gegenüber dem Kunden zu machen und ihn damit
> in die Pflicht zu nehmen, trotz Scrum sofort und verbindlich Vorgaben zu
> machen, weil es sonst gegen ihn verschleppend verwendet wird.

Janeeisklaa... es ist natürlich viel besser, bei jeder Änderung erst 
einmal auszudiskutieren, ob das jetzt ein kostenpflichtiger Change 
Request ist und was er kosten wird. Das verzögert Projekte kein 
bisschen... oder so.

> Sehen wir immer wieder. Das Team kommt mit Rückfragen an den PL, der der
> schickt uns die Fragenliste. 90% von dem hätten sie selber beantworten
> können, wenn sie einfach nur das Konzept umsetzen und ihren Job machen
> würden.

Hach, Geschichten ausm Paulanergarten...

von Andi (chefdesigner)


Lesenswert?

Ein T. schrieb:
> Na klar, das wird bei agiler Entwicklung natürlich nie gemacht.

Es wird nicht in dem gleichen Maß gemacht, weil man sich die 
Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht 
sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip 
dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten 
zu können.

Der Fehler den viele machen ist, darin einen Vorteil zu sehen:

Nur weil Scrum es ermöglicht, auf sich ändernde Anfragen zu reagieren, 
heißt das nicht, dass sich ändernde Anfragen eine gute Methode sind! Es 
ist nach wie vor zu vermeiden, dass sich Dinge mitten im Prozess ändern 
und Entscheidungen, die fällbar wären, ins Projekt hinzuschleppen.

Da liegt das Problem von Scum!

Die Vorgehensweise erinnert mich sehr stark an Corona, als alle die 
Masken haben fallen lassen und die Abstände misachteten, nachdem heraus 
war, dass es ja im Krankenhaus genug Intensivbetten und ECMO-Geräte 
gibt!

Scrum ist die Notlösung, um einen ungeordneten Haufen dahin zu bringen, 
ungeordnet eintrudelnde Wünsche zu erfüllen.

Es ließe sich auch der Vergleich zu einem Multi-Tasking-System ziehen: 
Weil ein MTS in der Lage ist, mit ungeordneten Anfragen umzugehen, heißt 
das  nicht, dass man alles so aufbauen muss.

von Uwe D. (monkye)


Lesenswert?

A. F. schrieb:
> Ein T. schrieb:
>> Na klar, das wird bei agiler Entwicklung natürlich nie gemacht.
>
> Es wird nicht in dem gleichen Maß gemacht, weil man sich die
> Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht
> sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip
> dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten
> zu können.

Lauter Prosa, angereichert mit Behauptungen und Dingen, die Dich selbst 
am meisten treiben.

>
> Der Fehler den viele machen ist, darin einen Vorteil zu sehen:
>
> Nur weil Scrum es ermöglicht, auf sich ändernde Anfragen zu reagieren,
> heißt das nicht, dass sich ändernde Anfragen eine gute Methode sind! Es
> ist nach wie vor zu vermeiden, dass sich Dinge mitten im Prozess ändern
> und Entscheidungen, die fällbar wären, ins Projekt hinzuschleppen.

Noch so ein Klugscheißer der vorneweg alles weiß. Und wieder nur 
Behauptungen, als wenn das nicht der Regelfall in allen Projekten 
wäre.

Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen.

> Die Vorgehensweise erinnert mich sehr stark an Corona, als alle die
> Masken haben fallen lassen und die Abstände misachteten, nachdem heraus
> war, dass es ja im Krankenhaus genug Intensivbetten und ECMO-Geräte
> gibt!
Whataboutism…


> Scrum ist die Notlösung, um einen ungeordneten Haufen dahin zu bringen,
> ungeordnet eintrudelnde Wünsche zu erfüllen.

SCRUM ist der entspanntere Weg, unklare Projekte zum Erfolg zu bringen. 
Kannst Du eigentlich einen Satz ohne Beleidigungen abfassen?

> Es ließe sich auch der Vergleich zu einem Multi-Tasking-System ziehen:
> Weil ein MTS in der Lage ist, mit ungeordneten Anfragen umzugehen, heißt
> das  nicht, dass man alles so aufbauen muss.

Hör auf Dinge zu vergleichen, von denen Du offensichtlich keine 
Erfahrung hast.

von Andi (chefdesigner)


Lesenswert?

Uwe D. schrieb:
> Lauter Prosa, angereichert mit Behauptungen und Dingen, die Dich selbst
> am meisten treiben.
Richtig, ich bin der Einzigste, der Scrum kritisch sieht. Das Seltsame 
ist, dass ich bei fast allen Kollegen Ähnliches höre - es sei denn sie 
sitzen gerade im SCRUM-Meeting und erstatten dem Master Rapport, oder 
jemand von der GL hört mit :-)

Da stoßen dann alle in dasselbe Horn :-)

Uwe D. schrieb:
> SCRUM ist der entspanntere Weg, unklare Projekte zum Erfolg zu bringen.
Du hast es nicht verstanden. Das Ziel ist es, erst gar keine großen 
Unklarheiten aufkommen zu lassen, die eines dafür geeigneten Prozesses 
bedürfen. Selbverständlich hat man in klar denkenden Firmen immer schon 
auch Methoden gehabt, auf offene Punkte zu reagieren und diese zu 
managen. Es tun nur viele plötzlich so, als gäbe es das erst durch 
SCRUM.

> Kannst Du eigentlich einen Satz ohne Beleidigungen abfassen?
Du solltest nochmals meinen Text mit deinem Vergleichen und summiere, 
wer hier mit wievielen Beleidungen um sich wirft persönlich angreift.

Solche wie dich wären nach solch einem Getexte direkt aus dem Projekt 
entfernt!

von A. B. (funky)


Lesenswert?

"erstatten dem Master rapport"

Auch schon so eine Formulierung die darauf hindeutet, dass bei euch noch 
andere Sachen schieflaufen als nur Scrum ;) Der ScrumMaster hat eh nix 
zu entscheiden. Der soll euch helfen eure Scrumprozesse zu optimieren 
und Ablaufprobleme aus dem Weg zu räumen. Rapporten müßt ihr da nix. Der 
kann eh nix entscheiden

Und wenn das früher alles so top lief, warum habt ihr dann Scrum 
eingeführt?

von Ein T. (ein_typ)


Lesenswert?

A. F. schrieb:
> Ein T. schrieb:
>> Na klar, das wird bei agiler Entwicklung natürlich nie gemacht.
>
> Es wird nicht in dem gleichen Maß gemacht, weil man sich die
> Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht
> sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip
> dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten
> zu können.

Schau, wir entwickeln und verkaufen eine Realtime Stream Processing 
Business Rule Engine, die überwiegend zur Betrugserkennung und 
-Prävention in Echtzeit bei Banken und Versicherungen eingesetzt wird. 
Das ist ein hochkomplexes und obendrein volatiles Umfeld, bei dem 
niemand -- und auch kein Team -- jeden Entwicklungsschritt detailliert 
überblicken und schon gar nicht planen kann.

Neben den technischen Herausforderungen mit ihrer inhärenten Komplexität 
sind es aber auch noch externe Faktoren, die unplanbar sind. Das fängt 
an mit den ständig neuen Betrugsmustern, die die Fachexperten entdeckt 
haben und die sich nicht immer mit den vorhandenen Funktionen abbilden 
lassen und endet noch lange nicht bei den unterschiedlichen gesetzlichen 
und vertraglichen Vorgaben, von Sarbanes-Oxley über DSGVO und HIPAA bis 
hin zu PCI-DSS, die sich während der Entwicklungs- und Laufzeit des 
Projekts ändern und an die die Software und / oder ihre Deployments 
zwangsläufig angepaßt werden müssen. Erschwerend kommt hinzu, daß diese 
Änderungen meistens interdisziplinär erarbeitet und umgesetzt werden 
müssen.

Sowas kannst Du schon wegen seiner technischen Komplexität nicht planen, 
auch dann nicht, wenn Du fünfmal so gut bist wie alle Scrumhasser in 
diesem Thread zusammengenommen.

> Der Fehler den viele machen ist, darin einen Vorteil zu sehen:

Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und 
Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit", 
"Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen. Das 
ist aber so falsch, daß nicht einmal das Gegenteil richtig ist. Und, 
ach, weißt Du, woran sich Dein Mangel an Erfahrung und Kenntnis von 
agilen Methoden mehr als deutlich zeigt? An so blöden Sprüchen wie "sie 
sitzen gerade im SCRUM-Meeting und erstatten dem Master Rapport", die 
mit Scrum und anderen agilen Methoden nun wirklich so ganz und gar 
nichts zu tun haben.

Langsam gewinne ich in dieser Diskussion das Gefühl, daß es sich ein 
wenig wie mit der Whitespace-Sache in Python verhält: wer noch nie mit 
Python gearbeitet hat (und womöglich sogar noch frühe Versionen von 
Fortran kennt), für den ist es der schiere Horror -- während 
andererseits Leute, die ihre Erfahrungen mit Python gesammelt haben, das 
meistens (wie ich) sogar ziemlich gut und elegant finden, während eine 
Minderheit (wie einer unserer hiesigen Moderatoren) sagt, daß sie zwar 
nicht begeistert sind, sich aber daran gewöhnen konnten.

Übrigens, nur so ein Hinweis: Deine, sagen wir mal, "robuste" Wortwahl, 
Dein mangelnder Respekt gegenüber anderen und ihren Meinungen und Deine 
Rückgriffe auf hinkende Vergleiche und ein Argumentum ad populum 
beeindrucken mich nicht und sind für mich nur ein Indiz für fehlende 
Sachargumente. Vielleicht magst Du einmal darüber nachdenken, wie es 
wohl auf Dich wirken würde, wenn ich es nötig hätte, Dir gegenüber so zu 
poltern.

von Reinhard S. (rezz)


Lesenswert?

Ein T. schrieb:
> Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und
> Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit",
> "Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen.

Man munkelt, es gibt solche Projekte in nennenswerter Menge. Nicht nur 
im Softwarebereich.

von Ein T. (ein_typ)


Lesenswert?

Reinhard S. schrieb:
> Ein T. schrieb:
>> Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und
>> Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit",
>> "Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen.
>
> Man munkelt, es gibt solche Projekte in nennenswerter Menge. Nicht nur
> im Softwarebereich.

Und nicht nur in agilen Projekten.

von Andi (chefdesigner)


Lesenswert?

Ein T. schrieb:
> Das fängt an mit den ständig neuen Betrugsmustern ...
> unterschiedlichen gesetzlichen und vertraglichen Vorgaben ...

Das wären von außen kommende und vor allem neue Anforderungen, die 
nicht die Vorgaben des aktuell laufenden Produktentwicklung tangieren, 
sondern eine Fortentwicklung induzieren. Solange eine solche neue 
Änderung nicht kommt, bleibt es ja bei den zuvor getroffenen Vorgaben, 
die irgendwo niedergelegt sind und damit geradlinig umgesetzt werden 
können. Da sehe ich keinen Bedarf für SCRUM, abgesehen davon dass man 
die technischen Änderungen diskutieren und formulieren muss. Das 
passiert(e) überall und immer - ganz ohne Spezialvorgehen nach Scrum, 
oder dass man es so nennt oder noch einen Master braucht, der die Teams 
moderiert.

Sollten solche Änderungen in so großer Dichte kommen, dass sie in die 
laufende Entwicklung einfließen müssen, dann würde das Produkt ja 
niemals fertig. Irgendwie muss ja mal ein Strich gezogen werden, was in 
eine neue SW hinein muss und was erst in die nächste kommt. Also muss 
man sammeln und die Software-Maturität stufenweise steigern.

Eine solche Änderung vom Kunden oder per Gesetz wäre für mich einfach 
ein REQ-change, der eine neue Produktversion nach sich zieht und ganz 
konventionell gehandhabt wird.

Abgesehen davon, sind von solchen Effekten so ziemlich alle Produkte 
betroffen, die einen ausreichend langen product life cycle haben und 
keineswegs etwas Neues oder Ungewöhnliches. In der Medizintechnik kenne 
ich es gar nicht anders. Da gibt es allenthalben ein neues Gesetz oder 
eine Zulassungsanforderung, z.B. auch in der Dokumentation.

Die wird einfach im Konzept erfasst, aufgeplant, kostengeschätzt und in 
die SW- bzw HW-Pläne übernommen. Das sind für mich 10-15 Sätze = 1-2h im 
Doors und weitere 3-4h an den Dokumenten, pro Punkt! Geht relativ 
stringent durch. Am Ende gibt es ein paar geänderte Dokumente und einige 
Absätze. Da braucht es auch keine großen Runden, wenn die PL, die das 
erfassen und umsetzen, die wissen, was sie tun und ihren Job können.

Danach wird es in die Teams reingeworfen und die z.B. Softwareentwickler 
können sich drum kümmern. Da gibt es aber meistens einen einzigen, der 
das linear und effektiv macht. Auch da braucht es keine Gruppe. Es 
braucht vor allem keine Orga drum herum und viel Gerede,  weil sich 
innerhalb dieser defiierten Spanne, nichts mehr ändert. Es muss auch 
kein Sprint definiert werden oder es in den nächsten reingeplant werden, 
sondern es gibt einen Task, der die Änderung definiert und einen 
Teamleiter, der anhand von Dringlichkeiten, die Erledigung committed. 
Bevor die Scrumteams ihre Sprintplanungen gemacht die Scrummaster 
warmgelaufen sind, hat es einer unserer kompetenten Entwickler schon 
gemacht, in allen Codes durchgezogen und so sauber und durchsichtig 
dokumentiert, dass es auch von einem anderen weiter ausgebaut werden 
kann, falss nochmal etwas kommt, was diese Baustellen betrifft. Das 
geht, weil wir auf gute Doku achten. Da kann schon der PL sehen, wo 
überall angepackt werden muss.

von Andi (chefdesigner)


Lesenswert?

A. B. schrieb:
> uch schon so eine Formulierung die darauf hindeutet, dass bei euch noch
> andere Sachen schieflaufen als nur Scrum ;)
Nicht in meinem Geschäftsbereich. Das Scrum läuft im Konzern aber eben 
nicht überall.

A. B. schrieb:
> Und wenn das früher alles so top lief, warum habt ihr dann Scrum
> eingeführt?
Weil da Leute reingekommen sind, die irgendeine Berechtigung für ihr 
Dasein liefern müssen und deren Hauptqualität eben der Scrum Master 
Schein und ihre Erfahrung in solchen Teams war.

von Andi (chefdesigner)


Lesenswert?

Ein T. schrieb:
> Mangel an Erfahrung mit und
> Kenntnis von agilen Methoden machst,

Ich beziehe mich definitiv auf die realen Erfahrungen, die ich mit Scrum 
seit fast 20 Jahren mache. Es bietet in funktionierenden Firmen nichts 
neues und bewirkt dort, wo keine Inhalte abgestimmt werden, nicht 
Positives. Dazu kommt die mangelnde Umsetzung, das ist richtig. Es ist 
aber nun einmal eine Tatsache dass es nirgendwo richtig funktioniert.

Ich kann dir jetzt Audi, IAV, MB-Tech und auch die Porsche-Engineering 
nennen -überall steigen die Kosten und die Softwarequaltiät sinkt. Bei 
Volksagen und auch der IAV machen inzwischen fast alle Abteilungen 
Scrum, einige davon schon seit über 10 Jahren. Die Ingenieure dort 
kennen nichts mehr anderes.

Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit 
ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen - 
nicht zu letzt aus Altersgründen. Bei einer IAV laufen daher 
ausschließlich Team- und Projektleiter herum, die Hauptsächlich in 
meetings sitzen und selber keine technischen Entscheidungen mehr fällen 
können - weil ihr Haupteinstellungskriterium die "Teamleitererfahrung" 
und die "PL-Erfahrung" waren, die schon in der Firma aus der sie kamen, 
nicht funktioniert hat, sonst hätten sie kaum den Job gewechselt. Das 
Kriterum Nummer 1 ist immer "Scrum" - das Allheilmittel.

Auf Inhalte und Erfahrung schauen sie immer weniger. Wie man hört ziehen 
jetzt einige die Notbremse und lagern SW-Entwicklung ins Ausland aus. 
Vornehmlich da hin, wo effizient und stabil gearbeitet wird. Konsequenz:

Man stellt sich alte und erfahrene Selbständige sowie temporäre 
Projektleiter ein, die noch in der Lage sind, ein richtiges 
Pflichtenheft zu schreiben, um dann die Arbeitspakete für dies externen 
Firmen zu definieren, weil es von den Internen, die nur das große 
"Gedrängel" können,  keiner mehr kann.

Scrum mag für solche Softwareabteilungen wie euch einen Vorteil haben, 
aber in vielen Fällen schafft es mehr Probleme, als es löst.

von Mark B. (markbrandis)


Lesenswert?

Uwe D. schrieb:
> Noch so ein Klugscheißer der vorneweg alles weiß. Und wieder nur
> Behauptungen, als wenn das nicht *der Regelfall in allen Projekten*
> wäre.
>
> Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen.

Ja, viele Projekte in vielen Firmen laufen chaotisch und mit großen 
Verzögerungen. Aber warum ist das so?

-Weil der Vetrieb den Kunden das Blaue vom Himmel verspricht, ohne 
Rücksicht darauf ob/wann dies tatsächlich geliefert werden kann.

-Weil manche Angebote so erstellt werden, dass man von vornherein weiß: 
Die Termine kann man eh nicht halten. Man wird eine Pönale zahlen 
müssen. Aber wenn man selbst mit dieser Pönale unterm Strich 
voraussichtklich noch einen Gewinn macht, dann pfeift manch ein 
Management darauf und unterzeichnet den Vertrag trotzdem. Dumm nur wenn 
die Verspätung dann noch größer wird.

-Weil man im Management glaubt, "Programmieren können die Inder auch, 
das kaufen wir billig als Dienstleistung ein", bis sich dann 
herausstellt dass ohne massive Nacharbeit in den teureren Ländern (EU, 
USA) überhaupt nichts funktioniert.

-Weil die Projektmanager keine Ahnung von der Hardware und Software 
haben, aber meinen sie müssten trotzdem ständig Entscheidungen über HW 
und SW treffen, ohne die Experten zu fragen worauf man achten muss.

-Weil niemand mehr vernünftig eingearbeitet wird. Die Leute sollen 
gleich bei der Einstellung sofort schon alles können.

-Weil es zu viele Hierarchieebenen gibt und ein beträchtlicher Teil an 
Manpower und somit Geld für sinnloses Reporting verbraten wird, ohne 
dass dadurch irgendein Mehrwert geschaffen wird.

von Crazy Harry (crazy_h)


Lesenswert?

Franko S. schrieb:
> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt.

Hat ned funktioniert .... war aber absehbar :-D

von Uwe D. (monkye)


Lesenswert?

Mark B. schrieb:
> Uwe D. schrieb:
>> Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen.
>
> Ja, viele Projekte in vielen Firmen laufen chaotisch und mit großen
> Verzögerungen. Aber warum ist das so?
>
> -Weil der Vetrieb den Kunden das Blaue vom Himmel verspricht, ohne
> Rücksicht darauf ob/wann dies tatsächlich geliefert werden kann.
>
> -Weil manche Angebote so erstellt werden, dass man von vornherein weiß:
> …
> … schnipp…

Alles super Beispiele, ohne das es an einer Projektmethode oder 
Framework festgemacht wäre. Tja, es macht mehr Sinn seine Zeit mit 
Verbesserungen zu verbringen anstatt mit der Suche nach Schuldigen.

: Bearbeitet durch User
von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Wenn man so im Internet auf Suche geht, sind anscheinend die 
Markenzeichen von Management nach Scrum herunterfallende Türbolzen, 
Räder und was sonst noch so alles verloren werden kann. Es gibt einige 
Quellen, die besagen, dass man ohne Scrum-Kenntnisse sich gar nicht zu 
bewerben brauche.

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> t
> was architektonisches, aber ich kann nicht mal locker aus der Hüfte das
> große Fass der Graphentheorie aufmachen, Kruskal erklären und erläutern,
> warum unser konkretes Problem zum Problem mit den minimalen Spannbäumen
> passt.

Das muss man auch nicht, wenn man nicht einen ehemaligen 
Supermarktkassierer danebensitzen hat oder stellt ihr fachfremde 
Volldeppen ein?

: Bearbeitet durch User
von Mark B. (markbrandis)


Lesenswert?

Uwe D. schrieb:
> Alles super Beispiele, ohne das es an einer Projektmethode oder
> Framework festgemacht wäre. Tja, es macht mehr Sinn seine Zeit mit
> Verbesserungen zu verbringen anstatt mit der Suche nach Schuldigen.

Ich habe noch vergessen hinzuzufügen:
-Weil man im Management glaubt, dass durch das Hinzufügen einer 
bestimmten Projektmethode (z.B. Scrum) dann einfach alles glatt laufen 
würde.

von Ein T. (ein_typ)


Lesenswert?

A. F. schrieb:
> Das wären von außen kommende und vor allem neue Anforderungen, die
> nicht die Vorgaben des aktuell laufenden Produktentwicklung tangieren,
> sondern eine Fortentwicklung induzieren.

Leider nehmen Gesetzgeber und Vertragspartner selten Rücksicht auf die 
Planungen von Unternehmen, die ihre Vorgaben umsetzen müssen.

> Sollten solche Änderungen in so großer Dichte kommen, dass sie in die
> laufende Entwicklung einfließen müssen, dann würde das Produkt ja
> niemals fertig.

Genau so ist das, das Produkt ist niemals "fertig" (für jede sinnvolle 
oder wie auch immer geartete Definition von "fertig").

> Eine solche Änderung vom Kunden oder per Gesetz wäre für mich einfach
> ein REQ-change, der eine neue Produktversion nach sich zieht und ganz
> konventionell gehandhabt wird.

Been there, done that, got the t-shirt. Wenn das ein Change Request ist, 
diskutieren Kunde und Management erst einmal aus, wer dafür bezahlen 
muß. Dadurch wird die Weiterentwicklung mitunter deutlich ausgebremst, 
und wenn schließlich eine Entscheidung getroffen wurde, bleibt 
regelmäßig wenig Zeit für eine sorgfältige, langfristig orientierte 
Planung und Implementierung.

A. F. schrieb:
> Ich kann dir jetzt Audi, IAV, MB-Tech und auch die Porsche-Engineering
> nennen -überall steigen die Kosten und die Softwarequaltiät sinkt.

Und Du denkst, das läge am agilen Projektmanagement? Das halte ich für 
ein Gerücht. Der Grund ist ein ganz anderer, nämlich, daß an Software 
zunehmend höhere Anforderungen gestellt werden und sie deswegen immer 
komplexer wird. KFZ-Elektronik ist heute nicht mehr primär die 
Motorsteuerung und eventuell noch das ABS, sondern heutige Fahrzeuge 
sind fahrende Computer, die viele unterschiedliche Sensoren auswerten 
und mit den so gewonnen Informationen  verschiedenste Aktoren ansteuern 
müssen. Und im selben Maße, wie sich Hard- und Software weiterentwickelt 
haben, werden sie auch ausgenutzt.

Denn eines ist Softwareentwicklung immer, nämlich ein Rattenrennen. In 
dem Moment, indem jemand eine neue kluge Methode zu ihrer Vereinfachung 
findet, entwickelt ein anderer auf dieser Basis neue Komplexität, die 
die vorherige Vereinfachung dann sofort wieder auffrißt. Das hat 
zunächst einmal überhaupt gar nichts mit irgendeiner Art des 
Projektmanagement zu tun.

Aber sekundär hat das dann doch wieder mit Projektmanagement zu tun, 
nämlich mit der Frage, wie sich die steigende Komplexität beherrschen 
läßt. Agile Vorgehensweisen wurden nämlich entwickelt, weil je nach 
Untersuchung sechzig bis achtzig Prozent aller Softwareprojekte ihre 
Planungen in Bezug auf Zeit, Budget und / oder Funktionalität gesprengt 
hatten. Soviel dann übrigens auch zum angeblich überlegenen klassischen 
Projetmanagement, das ja offensichtlich auch schon oft genug versagt 
hat.

Insofern scheint es mir ein logischer Fehlschluß (post hoc ergo propter 
hoc) zu sein, alle Probleme in der Softwareentwicklung der zunehmenden 
Verbreitung agiler Methoden anzulasten. Ockhams Rasiermesser legt nahe, 
daß die zunehmend komplexen Anforderungen dabei die mit Abstand größte 
Rolle spielen.

> Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit
> ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen -
> nicht zu letzt aus Altersgründen.

Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal 
mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk 
und aus etlichen anderen Bereichen.

von Re D. (re_d228)


Lesenswert?

Ein T. schrieb:
> Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal
> mit Softwareentwicklung

Du kannst so viel fachlich argumentieren wie du willst, gegen ein "ich 
hab den Durchblick, der Rest sind Deppen" kommst du nicht an. Aber schon 
die Sichtweise macht offensichtlich, wer der Depp ist.

von Manfred P. (pruckelfred)


Lesenswert?

> Projektmanagement

Ich habe vorhin etwas gelesen, was zu diesem Thema passen könnte:

https://www.initiative-zukunftsfaehigkeit.de/das-paul-carla-dilemma/

von Mark B. (markbrandis)


Lesenswert?

Ein T. schrieb:
>> Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit
>> ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen -
>> nicht zu letzt aus Altersgründen.
>
> Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal
> mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk
> und aus etlichen anderen Bereichen.

Es hat aber sehr viel mit Management an sich zu tun.

Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%. Man weiß 
sehr wohl, wer wann in Rente gehen wird. Wenn man es dann nicht schafft, 
eine Weitergabe des Wissens und der Erfahrung von den älteren auf die 
jüngeren Mitarbeiter zu organisieren, dann hat das Management schlicht 
und ergreifend versagt.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Mark B. schrieb:
> Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%.
Das sollte man denken. Ich kann dir aber sagen, daß das bei den meisten 
Firmen ein echtes Problem ist. Auch unsere Politiker schaffen es ja 
nicht, zu zählen und ausreichend Lehrer einzuplanen. Die Planstellen 
wurden erst geschaffen, nachdem der Mangel offenbar wurde.

Die Sache ist auch die, dass manche Manager gezielt Fachwissen aus der 
Firma drängen indem sie alte Erfahrene nicht mehr ersetzen und dann als 
Alleinentscheider die Aufträge an den Billigsten vergeben zu können, 
ohne dass ihnen einer reinreden kann.

Da kann ich dir eine Firma hier aus Heidelberg nennen, die das so macht. 
Die Entwicklungsabteilungen werden immer mehr ausgedünnt und wenn 
überhaupt mit billigen aus dem Ausland bestückt, die über Zeitarbeit 
beschäftigt werden und indirekt dazu beitragen, das KnowHow in andere 
Firmen zu übertragen.

von Ein T. (ein_typ)


Lesenswert?

Mark B. schrieb:
> Ein T. schrieb:
>> Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal
>> mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk
>> und aus etlichen anderen Bereichen.
>
> Es hat aber sehr viel mit Management an sich zu tun.

Darum geht es in diesem Thread aber nicht.

> Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%. Man weiß
> sehr wohl, wer wann in Rente gehen wird. Wenn man es dann nicht schafft,
> eine Weitergabe des Wissens und der Erfahrung von den älteren auf die
> jüngeren Mitarbeiter zu organisieren, dann hat das Management schlicht
> und ergreifend versagt.

Hach ja, wenn das nur so einfach wäre... ist es aber nicht. Denn auch 
das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob 
ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen, 
kündigen oder krankheitsbedingt ausfallen. Außerdem hat auch das beste 
Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich 
ein adäquater Ersatz für ausscheidende Mitarbeiter findet -- beim 
heutigen Fachkräftemangel ist das nämlich nicht so einfach, wie Otto 
Normalelektroniker sich das vorstellt.

Aber klar, es ist natürlich immer ganz einfach, wenn immer nur die 
anderen doof und natürlich immer an allem schuld sind, vor allem 
natürlich besonders gerne "das Management". Meine persönliche Erfahrung 
ist, daß es dort genauso viele Nieten, gleichzeitig aber auch genauso 
viele richtig Leute gibt wie in allen anderen Bereichen auch. Schade, 
daß Du es Dir dabei so einfach machst, eigentlich würde ich Klügeres und 
Differenzierteres von Dir erwarten...

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Ein T. schrieb:
> das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob
> ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen,
> kündigen oder krankheitsbedingt ausfallen.
Es ist bekannt wieviele junge und kinderlose man hat, die in Elternzeit 
gehen. Das kann man auch statistisch bewerten.

Auch Krankheiten lassen sich statistisch einstufen. Das wird auch 
gemacht.

> Außerdem hat auch das beste
> Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich
> ein adäquater Ersatz für ausscheidende Mitarbeiter findet
doch, indem es Marktpreise bezahlt. Firmen möchten nicht ausbilden, 
sondern sich einfach bedienen und wundern sich, dass andere ihre 
Mitarbeiter nicht kostenlos hergeben, sondern nur die faulen Eier! 
Wichtige Mitarbeiter werden nämlich per ehalten und zwar mit dem -> 
"Gehalt"!!!!

> heutigen Fachkräftemangel
Die Industrie lamentiert doch permanent wegen dem Mangel sorgt aber 
durch die Gehaltspoliktik dafür, dass sich fähige Leute etwas anderes 
suchen.
Selbst in der Krise und während der Insolvenzen durch Covid waren sie 
nicht in der Lage, ihr angebliches Personaldefifiz aufzufüllen!

Es sollte niemand eingestellt werden. Es gab allerdings die eine oder 
andere Firma, die das genutzt hat und investierte! Die haben jetzt einen 
Vorsprung u.a in KI.

Nur eben nicht in Deutschland-Jammerland!

von Ein T. (ein_typ)


Lesenswert?

Martin K. schrieb:
> Es ist bekannt wieviele junge und kinderlose man hat, die in Elternzeit
> gehen. Das kann man auch statistisch bewerten.
>
> Auch Krankheiten lassen sich statistisch einstufen. Das wird auch
> gemacht.
>
> doch, indem es Marktpreise bezahlt. Firmen möchten nicht ausbilden,
> sondern sich einfach bedienen und wundern sich, dass andere ihre
> Mitarbeiter nicht kostenlos hergeben, sondern nur die faulen Eier!

Jaja, immer sind die anderen schuld. Meine Güte, Diskussionen auf diesem 
"Niveau" sind so enervierend und ermüdend... und ignorieren vollkommen, 
daß auch andere Menschen jeweils ihren ganz eigenen Sachzwängen 
unterliegen, mit denen sie dann irgendwie umgehen müssen.

> Wichtige Mitarbeiter werden nämlich per ehalten und zwar mit dem ->
> "Gehalt"!!!!

Es ist immer sehr angenehm, wenn man sich die Welt so einfach machen 
kann. Leider hat das wenig mit der Realität zu tun. Für die meisten 
Menschen, die ich kenne, spielt das Gehalt nur eine vergleichsweise 
kleine Rolle in einer wesentlich umfangreicheren Gesamtbetrachtung. Die 
ausufernde Verwendung von Ausrufezeichen ändert daran auch nichts.

> Die Industrie lamentiert doch permanent wegen dem Mangel sorgt aber
> durch die Gehaltspoliktik dafür, dass sich fähige Leute etwas anderes
> suchen.
> Selbst in der Krise und während der Insolvenzen durch Covid waren sie
> nicht in der Lage, ihr angebliches Personaldefifiz aufzufüllen!

Genau, alle doof außer Dir. Hätten wir bloß mal Dich gefragt, das große, 
allwissende Orakel mit dem totalen Durchblick! Dann würden Milch und 
Honig fließen und uns allen gebratene Tauben in den Mund fliegen!

> Nur eben nicht in Deutschland-Jammerland!

rolleyes Wie viel Erfahrung hast Du denn schon im Ausland gesammelt?

von Mark B. (markbrandis)


Lesenswert?

Ein T. schrieb:
> Darum geht es in diesem Thread aber nicht.

Selbstverständlich geht es in diesem Thread unter anderem auch darum, 
wie man Firmen, Abteilungen, Projekte, Teams managt.

> Hach ja, wenn das nur so einfach wäre... ist es aber nicht. Denn auch
> das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob
> ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen,
> kündigen oder krankheitsbedingt ausfallen. Außerdem hat auch das beste
> Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich
> ein adäquater Ersatz für ausscheidende Mitarbeiter findet -- beim
> heutigen Fachkräftemangel ist das nämlich nicht so einfach, wie Otto
> Normalelektroniker sich das vorstellt.

Man kennt aber die durchschnittlichen Fluktuationsraten. Das ist schon 
mal ein Anhaltspunkt.

Nebenbei bemerkt:
Wenn eine Firma eine überdurchschnittliche hohe Fluktuationsrate hat, 
dann sollte sie sich vielleicht einmal überlegen, wie sie zu einem 
besseren und attraktiveren Arbeitgeber werden kann. Es ist der 
Firmenleitung nicht verboten, in diese Richtung zu denken und auch zu 
handeln.

> Aber klar, es ist natürlich immer ganz einfach, wenn immer nur die
> anderen doof und natürlich immer an allem schuld sind, vor allem
> natürlich besonders gerne "das Management".

Niemand wird dazu gezwungen ins Management gehen. Wer diese 
Verantwortung nicht übernehmen will, der soll es eben sein lassen.

Man bekommt in einer Führungslaufbahn mehr Geld als in einer 
Fachlaufbahn. Dafür kann man auch mit Fug und Recht einen entsprechenden 
Gegenwert erwarten. Wenn dieser ausbleibt, dann war die Leistung des 
Managements eben nicht gut. Da gibt es nichts schön zu reden.

von Katrin I. (Gast)


Lesenswert?

Mark B. schrieb:
> Wenn dieser ausbleibt, dann war die Leistung des
> Managements eben nicht gut. Da gibt es nichts schön zu reden.

Leider entlässt dann das Management aber nicht etwa sich selbst, um die 
firma zu entlasten und zu retten, sondern macht weiter und spart 
Fachleute ein. Das tut sie so lange, bis gar nichts mehr läuft und der 
Laden stirbt. Solange haben sie noch gute Zahlen, weil sie 
Entwicklungsinvestitionen an die Gewinne gekoppelt sind. Und mit diesen 
Zahlen gehen sie in die nächste Firma.

von Martin K. (mkmannheim) Benutzerseite


Lesenswert?

Ein T. schrieb:
> Für die meisten
> Menschen, die ich kenne, spielt das Gehalt nur eine vergleichsweise
> kleine Rolle in einer wesentlich umfangreicheren Gesamtbetrachtung

Das ist interessant! Das erklärt solche Gehälter, wie sie derzeit 
angeboten werden. Beispiel:

------------------------------------
Machine Learning Engineer
Trilogy (Remote) - $60,000/year USD
Crossover · München (Remote)
Bewerben Sie sich als Erster von 15
3-5 years experiences in machine
learning algorithm design
MATLAB, Simulink, C++, C#
------------------------------------

So werden momentan Stellen verhökert. Meistens werden damit Leute aus 
aller Wert angelockt, sich hier niederzulassen.

Dass bei den steigenden Kosten irgendwann niemand mehr da ist, der die 
Steuern aufbringen kann und die Rente bezahlen kann, scheint niemanden 
zu interessieren.

Offenbar ist die Strategie, möglichst große billige Horden anzulernen, 
die dann mit u.a. Scrum gemanaged werden sollen.

von Franko S. (frank_s866)


Lesenswert?

Martin K. schrieb:
> -
> Machine Learning Engineer
> Trilogy (Remote) - $60,000/year USD
> Crossover · München (Remote)
> Bewerben Sie sich als Erster von 15
> 3-5 years experiences in machine
> learning algorithm design
> MATLAB, Simulink, C++, C#
> ------------------------------------

ML Experte ist der neue HTML-Programmierer.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Mark B. schrieb:
> Selbstverständlich geht es in diesem Thread unter anderem auch darum,

"unter anderem" ist treffend formuliert :-) Die Diskussion gleitet ab.

Eigentlich geht es nur um Scrum ... und dessen Nutzung ist Teil der 
Betriebsführung, also zweifellos eine Managementfrage. Im speziellen 
natürlich eine Frage des "Managements" der Abteilung und der fließenden 
Informationen.

Mark B. schrieb:
> Nebenbei bemerkt:
> Wenn eine Firma eine überdurchschnittliche hohe Fluktuationsrate hat,
... dann hat sich schon einmal grundsätzlich ein Problem, weil sich 
nirgendwo ein stabiles Team einstellen kann, dass einen funktionierenden 
Scrum-Prozess formen kann.

Rudi R. schrieb:
> dass Menschen wie
> ich, die einfach nur einer Sache aufgehen wollen, daran durch
> Besprechungen und Sozialtänze abgehalten werden.
Ich habe gerade mit einem solchen Hansi zu tun, der in seiner Sache voll 
aufgeht und der ist extrem schwer mit Informationen zu versorgen. Da 
hilft auch kein Scrum und kein Garnichts.

Die Frage ist bei Allem immer, wieviel Besprechungen hat man und wie 
führt man sie durch. Wenn das Gesagte nur an den Leuten vorbeirauscht, 
alles ohne Vorbereitung aus der Hüfte gemacht wird, im nichts Wirksames 
entschieden sondern viel verschoben wird und im Nachhinein keine Zeit 
ist, das Besprochene aufzuarbeiten -> in Dokumente fließen zu lassen 
oder sofort umzusetzen, weil man von einer B in die nächste hüpft, dann 
wird das in der Tat sehr schnell sehr inffektiv.

Es kommt daher darauf an, Besprechungen zu planen, nur die zu 
beteiligen, die auch benötigt werden und die Menge des zu bearbeitenden 
anzupassen, zu skalieren und zu sequenzialisieren. Das erfordert es z.B. 
Aufgaben zu aufzuteilen, dass gar nicht erst der Bedarf für so viel 
Kommunikation entsteht. Wenn die Projektleitung aber nicht stimmt, der 
Informationsfluss nicht passt, oder manche Leute einfach nicht fähig 
sind, ordentlich zu arbeiten und voraus zu dokumentieren, muss wegen 
jedem Krümel ein Meeting her und je mehr da dann wieder mitmachen, desto 
konfuser wird es meistens.

In solche Meetings müssen nur die wenigen hinein, die wirklich 
entscheiden können, weil sie das relevante Thema selber planen oder 
bearbeiten und die Entscheidungen anderer brauchen.

Daher muss das auch in Scrum-Gruppen so sein und sieht man sich die 
Strategien dahinter an, dann ist das auch so gedacht! Was ich 
diesbezüglich eben nur immer sehe, sind riesige Gruppen, wo 
allemmöglichen Teilthemen besprochen werden, zu deren Verlauf und Stand 
3/4 der Anwesenden nichts beitragen können und denen die Besprechung 
auch keine Information bringt, die sie verwerten könnten. Da gehen dann 
20min Diskussion weitgehend nutzlos durch.

Diese 20min sind es aber dann, die angeblich fehlen, um einfach mal 
selber proaktiv den Ablauf einer Software hinzuschreiben, eine Seite zu 
machen, die andere in 5min durchlesen und in weiteren 10min sukkzessive 
zu einem fähigen Konstrukt ergänzen könnten, damit dann jeder sein Modul 
anpassen und die Interaktionen zum Laufen bekommen kann. Stattdessen 
werden 5 Meetings gemacht werden, mit jeweils 4 Leuten, die eine volle 
Stunde über die SW-Struktur diskutieren, was sich über 2 Wochen zieht 
und ein eher schlechteres Ergebnis hat, bei dem Dreifachen der 
Nettozeit.

von Uwe D. (monkye)


Lesenswert?

J. S. schrieb:
> Mark B. schrieb:
>> Selbstverständlich geht es in diesem Thread unter anderem auch darum,
> …
> Die Frage ist bei Allem immer, wieviel Besprechungen hat man und wie
> …
> Es kommt daher darauf an, Besprechungen zu planen, nur die zu
> beteiligen, die auch benötigt werden und die Menge des zu bearbeitenden
> anzupassen, zu skalieren und zu sequenzialisieren. Das erfordert es z.B.
> Aufgaben zu aufzuteilen, dass gar nicht erst der Bedarf für so viel

Ja, wenn die Beteiligten das notwendige Handwerk nicht beherrschen ist 
es halt Brühe… Egal wie das Framework/Methodik heißt.

> In solche Meetings müssen nur die wenigen hinein, die wirklich
> entscheiden können, weil sie das relevante Thema selber planen oder
> bearbeiten und die Entscheidungen anderer brauchen.
>
> Daher muss das auch in Scrum-Gruppen so sein und sieht man sich die
> Strategien dahinter an, dann ist das auch so gedacht!

Nee, ist es nicht und war es nicht. Du machst genau, das was viele an 
SCRUM nicht verstehen: Es gibt kein „Ober sticht Unter“ und vor allem 
keinen „großen Plan“. Iterativ arbeiten heißt nicht, große Aufgaben in 
Pakete zu zerstückeln und wie gehabt auf Personen vom Scrum master 
verteilen zu lassen.

> …
> diesbezüglich eben nur immer sehe, sind riesige Gruppen, wo
> allemmöglichen Teilthemen besprochen werden, zu deren Verlauf und Stand
> 3/4 der Anwesenden nichts beitragen können und denen die Besprechung
> auch keine Information bringt, die sie verwerten könnten. Da gehen dann
> 20min Diskussion weitgehend nutzlos durch.

Nun, der Scrum master ist genau dafür da, das Framework mit Leben zu 
erfüllen und „planenden Besserwissern“ - insbesondere den Managern - 
diese Art der Kommunikation abzugewöhnen.

Deine Worte wie „..wer etwas beizutragen hat..“ zeigen, dass Du die 
Chance bzw. Notwendigkeit, nämlich weitere Beteiligte des Teams 
weiterzuentwickeln (damit sie sich später vertreten können oder dem 
Team mehr Fähigkeiten geben) nicht siehst. Suche besser nach Lösungen 
als Schuldige - das macht auch viel mehr Spaß…

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Uwe D. schrieb:
> Es gibt kein „Ober sticht Unter“ und vor allem
> keinen „großen Plan“.
Das Fehlen des Plans ist aber letztlich das, was die Ineffizienz ins 
Spiel bringt. Ein Großteil der Dinge, die es in einem Projekt zu 
entscheiden gibt, sind nun einmal weitgehend trivial und durchsichtig 
genug, dass es dazu keine Gruppenentscheidung oder Gruppenkompetenz 
braucht. Unnötig viele zu involvieren ist damit einfach langwierig und 
ineffizient. Es macht daher einfach keinen Sinn, alles in 
Gruppenentscheidungen zu drängen.

Uwe D. schrieb:
> Nun, der Scrum master ist genau dafür da, das Framework mit Leben zu
> erfüllen
Das ist wieder so ein typischer nichtssagender Satz. Wie soll er dies 
denn deiner Meinung nach real tun? Der SM hat nur die Methodenkompetenz 
in Sachen Scrum, ist aber nur in Ausnahmefällen der Fachmann für die 
Inhalte. Er kann so die Mitwirkende nur anleiten, wie sie arbeiten und 
kommunizieren sollen, aber das was müssen sie selber entscheiden.

Das was ist sind aber die 90% des Handelns. Wenn dort unnötig 
Innefizienz hinkommt, ist die durch nichts wieder auszugleichen.

Uwe D. schrieb:
> Iterativ arbeiten heißt nicht, große Aufgaben in
> Pakete zu zerstückeln und wie gehabt auf Personen vom Scrum master
> verteilen zu lassen.
Dass der Scrummaster die Pakete verteilen soll hat niemand behauptet und 
würde auch wenig Sinn machen, da er dazu oft nicht in der Lage ist, 
wenngleich ich genau das auch schon erlebt habe.

Der Theorie nach verteilen sich die Mitwirkenden die Aufgaben 
bekanntlich selber. Da muss man aber jetzt mal genau hinschauen, wie das 
im Einzelnen passiert und wie das abläuft, wenn es bezüglich der 
Umsetzung gegenteilige Auffassungen gibt, weil unterschiedliche 
Wissenstände kollidieren oder gar Interessen aufeinanderprallen, weil 
jeder gerne die Rosinen picken möchte.

Erfahrungsmäß neigen manche sehr wohl dazu, sich die Arbeit leicht zu 
machen und Unangenehmes anderen zuzuschieben. Ich konnte aus nächster 
Nähe gerade vor Kurzem sehen, dass jemand deswegen nicht nur das Scrum, 
sondern die Firma verlassen hat. Es muss auch nicht einmal eine 
böswillige Strategie dahinter stehen, sondern es reicht, wenn manche in 
ihrem flow arbeiten, sich Infos ad hoc holen wollen und selber Dinge nur 
auf Anfrage herausgeben, damit Dinge die synchronisiert laufen müssten, 
auseinander gehen.

Ohne eine Instanz, die das zusammenhält und auch Entscheidungen fällen 
kann, geht es dann nicht. Das ist allein schon deshalb nötig, weil 
vielen "unten", wie du es formulierst, der Überblick im Projekt fehlt.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Mir kam es aber mit meiner Aussage eigentlich auf einen anderen Punkt 
an:

Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet 
sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind, 
sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende 
Minute ist, die an anderer Stelle als Problem doppelt und dreifach 
aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren 
und ein Konzept zu schreiben, das überhaupt erst einmal als 
Diskussionsgrundlage fungieren könnte und andere haben keine Zeit, 
Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand 
in den Mund" wie es mal jemand formuliert hat. Und ich sehe nicht, wie 
die Nutzung von Scrum das irgendwie irgendwo geändert hätte. Scrum 
verbraucht sehr viel Zeit, die es oft nicht einspielt, die aber an 
anderer Stelle wieder sehr weh tut.

Ich sehe mir das nun seit fast 20 Jahren an und meine eigentlich, dass 
praktisch jeder Entwickler einmal in einer Firma war mehrfach mit Scrum 
zu tun hatte. Die meisten sollten also damit vertraut sein.

Fakt ist aber: Scrum läuft in jeder Firma anders und in vielen Firmen 
ist es wie eine zweite Arbeitsebene, die man einfach formell erfüllt und 
abwickelt, weil es so vorgegeben ist, so wie andere Prozesse vorgegeben 
sind. Praktisch weicht man aufgrund irgendwelcher Notwendigkeiten 
andauernd davon ab. Oft deklariert man dann das, was man tut und wie man 
es tut, kurzhand als Scrum. Kürzlich ebenfalls erlebt. Seit 3 Jahren 
Scrum eingeführt, aber keiner arbeitet tatsächlich danach. Aufgaben 
wurden vom Product Owner eingeteilt. Natürlich gab es keine Regel, wann 
man abweichen durfte, bzw. die Deutungshoheit darüber hat man sich 
passend gegriffen und es sich angenehm ausgelegt. Hinweise auf die 
Diskrepanz zu dem, was in den Scrum-Schulungen extra vorher noch 
kommuniziert wurde, kamen nicht positiv an. Es ist dann ein Problem, 
wenn du zuviel Erfahrungen mit Scrum hast :-)

In manchen Firmen sehe ich das sogar wie eine dritte Arbeitsebene, neben 
der formellen Vorgehensweise in Projekten, wie sie nach internen durch 
Gesetze regulierten eProzessen offiziell erfolgen soll - Stichwort 
Dokumentenmanagement, Milestones mit Konzept, Validierung und 
Verifikation, Auditfähigkeit der Doku, sowie strikter Einhaltung der 
Unterschriftenkette. Man probiert, irgendwie diese formellen Prozesse 
einzuhalten, während man noch das Tagesgeschäft an sich abwickelt, etwas 
reales irgendwie fertigstellt, wobei probiert wird, das irgendwie unter 
einen Hut zu bringen.

In diesem Dreieck springen dann viele hin und her, weil es einfach nicht 
richtig zusammenpasst und/oder nicht richtig umgesetzt wird. Und genau 
das lese ich auch aus den Eingangspost heraus.

Was sind die Gründe?

Ich sehe ein großes Problem darin, eine gewachsene Struktur in einem 
großen Maßstab umzustellen. Jeder will schon irgendwie, es geht aber 
wegen der Sachzwänge nicht, weil die anderen das nicht so machen. Der 
reale Takt ist ein anderer, weil von der großen Masse der Mitarbeiter 
vorgegeben. Ich vergleiche das gerne mit dem Experiment der riesigen 
langen Skier, wo 10 Mann mit festgeschraubten Schuhen drinstecken und 
gleichzeitig laufen sollen. Jeder will auch loslaufen, aber die anderen 
machen nicht zeitglich mit, sondern beschweren sich, dass man selber 
nicht läuft. Die Richtung zu ändern, geht gar nicht. Der große Schwarm 
bewegt sich in Summe zu 99% dort hin, wo die anderen hinsteuern.

Für mich folgt daraus ganz klar die Maxime, solche Prozesse und Vorgaben 
zu Vorgehensweisen wie Scrum entweder richtig oder gar nicht einzuführen 
und sich ansonsten den Aufwand und den Stress zu sparen. Damit folgt 
unweigerlich, dass das Einführen nur in einem kleinen überschaubaren 
Projekt mit einer kleinen Gruppe erfolgen kann und sich das erst einmal 
manifestieren muss.

Mit Hinweis auf das Phänomen der Männer mit den Skischuhen, muss es auch 
bei solchen kleinen homogenen Gruppen bleiben. Nur wenn das maximal 2-4 
Personen sind, können solche Gruppen noch funktionieren und auch 
effektiv arbeiten. Voraussetzung ist, dass die Stile auch zueinander 
passen bzw einander angelichen werden.

Und es bleibt dabei, dass Aufgaben grundsätzlich gut modularisiert 
werden müssen und nur dann auf Teams, statt auf Einzelpersonen verteilt 
werden sollten, wenn es aus Geschwindigkeits- oder Redunanzgründen 
unbedingt angezeigt ist, um unnötige Überlappungen zu vermeiden. Eine 
Kompetenzabdeckung lässt sich z.B. sehr viel besser dadurch erzielen, 
dass man Module auf Teams verteilt und dann manche Kompetenzträger als 
Einzelpersonen eben in 2 oder 3 Scrum-Teams arbeiten und mitdenken.

Der Große Scrum-Haufen, mit allen möglichen Projektteilnehmern, den ich 
aber meistens sehe, macht jedenfalls keinen Sinn. Dahe gehe ich nicht 
von weg.

Das Gesagte gilt IMO auch für das übergeordnete Denken, um die Module 
zusammen zu halten und vorausschauende Zeitpläne zu machen. Es hat 
niemand gesagt, dass diese Projektleitung nur von einer einzigen 
Personen durchgeführt werden kann und muss. In dem Zusammenhang muss 
auch hinterfragt werden, ob es bei Entwicklungen ab einer gewissen 
Komplexität wirklich nur einen einzigen Product Owner geben kann und ob 
bei übergeordneten Planungen 2 Wochen Sichten sinnvoll sind.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

J. S. schrieb:
> Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet
> sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind,
> sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende
> Minute ist, die an anderer Stelle als Problem doppelt und dreifach
> aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren
> und ein Konzept zu schreiben, das überhaupt erst einmal als
> Diskussionsgrundlage fungieren könnte und andere haben keine Zeit,
> Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand
> in den Mund" wie es mal jemand formuliert hat.

Derartige Situationen kennen wir Entwickler vermutlich alle. Aber gerade 
in solchen Situationen ist eine gute Kommunikation und Koordination 
unter den Projektbeteiligten besonders wichtig, um weitere Folgekosten 
zu vermeiden.

von Uwe D. (monkye)


Lesenswert?

Ein T. schrieb:
> J. S. schrieb:
>> Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet
>> sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind,
>> sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende
>> Minute ist, die an anderer Stelle als Problem doppelt und dreifach
>> aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren
>> und ein Konzept zu schreiben, das überhaupt erst einmal als
>> Diskussionsgrundlage fungieren könnte und andere haben keine Zeit,
>> Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand
>> in den Mund" wie es mal jemand formuliert hat.
>
> Derartige Situationen kennen wir Entwickler vermutlich alle. Aber gerade
> in solchen Situationen ist eine gute Kommunikation und Koordination
> unter den Projektbeteiligten besonders wichtig, um weitere Folgekosten
> zu vermeiden.

Bestimmt kennt Ihr die Geschichte:
Ein alter Mann geht durch den Wald und sieht ein paar Waldarbeiter, wie 
sie beim sägen mächtig schwitzen.
Er ruft ihnen zu: „Männer, Ihr müsst innehalten und Eure Sägen 
schärfen.“
Und die Männer antworten: „Keine Zeit alter Mann, wir müssen sägen!“

Die Kommunikation einschränken und weiter malochen ist einfach falsch, 
wenn die Ursache für den personellen Engpass nicht beseitigt wird. Da 
werden Symptome behandelt anstatt Ursachen zu beseitigen.

Hat im übrigen nichts mit SCRUM zu tun.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Uwe D. schrieb:
> Er ruft ihnen zu: „Männer, Ihr müsst innehalten und Eure Sägen
> schärfen.“
> Und die Männer antworten: „Keine Zeit alter Mann, wir müssen sägen!“

> Die Kommunikation einschränken und weiter malochen ist einfach falsch,
Also meine Aussage war keines falls "Kommunikation einschränken".
Sie lautete im Gegensatz:

"Kommunikation durch geeignete Planung und Dokumente verbessern". Das 
ist inhaltlich das Gegenteil.

Um dein Beispiel aufzugreifen, sei das zitiert, was ich dauernd höre und 
sehe:

"Wir haben keine Zeit etwas Besprochenes niederzulegen, zu präsisieren 
oder zu Ende zu diskutieren - wir müssens ins nächste Meeting".

sowie

"Wir haben keine Zeit genau zu planen, wir müssen loslegen, um fertig zu 
werden".

Der Rest soll sich dann von selber erledigen oder wird unterwegs 
gemanaged.

D.h. man rennt ohne Abstimmung in den Wald, fängt an zu sägen und stimmt 
sich als Gruppe von Baum zu Baum ab, was als Nächstes kommt. Im 
Nachhinein stellt man fest, dass man vergessen hat, genug Sägen mit zu 
bringen, nicht rechtzeitig Sägeblätter bestellt hat, einige Bäume in der 
falschen Reihenfolge gesägt wurden, was dan Abtransport anderer 
behindert hat und man vorher mal hätte schauen sollen, welche Bäume 
morsch sind und zuerst hätten gefällt werden müssen.

Ich habe ein Beispiel dafür, dass das Scrum-Team nach 2.5 monatigem 
Sägen ohne vorherige Planung - trotz permanenter Absprache mit einem 
Haufen Schnitzel dastand, die man nicht verkaufen konnte. Ein Beispiel 
habe ich, dass man einen Wald gar nicht hätte absägen sollen und sogar 
eines, bei dem das selbst organisierte Team am Ende merkte, dass es im 
falschen Wald war.

Man glaubt das nicht, aber es ist so.

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

J. S. schrieb:
> Also meine Aussage war keines falls "Kommunikation einschränken".
> Sie lautete im Gegensatz:
>
> "Kommunikation durch geeignete Planung und Dokumente verbessern". Das
> ist inhaltlich das Gegenteil.

Deine Ausführungen lasen sich, insbesondere nach dem Threadtitel und 
-Verlauf, zumindest für mich allerdings leider ein wenig anders.

> "Wir haben keine Zeit etwas Besprochenes niederzulegen, zu präsisieren
> oder zu Ende zu diskutieren - wir müssens ins nächste Meeting".

Diese Meetings haben aber durchaus einen tieferen Sinn, nämlich, die 
Dinge auszudiskutieren, festzulegen und zu dokumentieren.

> D.h. man rennt ohne Abstimmung in den Wald, fängt an zu sägen und stimmt
> sich als Gruppe von Baum zu Baum ab, was als Nächstes kommt.

Das ist dann aber nicht agil, sondern bescheuert. Und es hat auch nichts 
mit der Projektmanagementmethode zu tun, denn das gibt es ja bei den 
klassischen Projekten ganz genauso -- und nach meiner Erfahrung sogar 
noch öfter. Da ist dann nicht die Zeit für eine ordentliche Planung, 
Lasten- und Pflichtenhefte werden mal schnell hin gebastelt, wichtige 
Aspekte offen gelassen, schwammig und mehrdeutig formuliert, denn: "wir 
haben ja keine Zeit". Und bei nötigen Änderungen wird dann alles auf 
Stopp gestellt, bis Management, Projektleiter und Kunde ausgekaspert 
haben, wer dafür bezahlt.

> Ich habe ein Beispiel dafür,

Das Dumme ist halt: wir alle haben Beispiele -- für alles. 
Fehlgeschlagene agile und genauso auch klassische Projekte, 
selbstherrliche und inkompetente Manager und Projektleiter, 
Vertriebsleute die dem Kunden das Blaue vom Himmel herunter versprochen 
haben, und so weiter, und so fort.

Daher nochmal: agile Vorgehensweisen wurden entwickelt, weil (je nach 
Studie) 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte 
gescheitert waren, weil sie die projektierten zeitlichen, ökonomischen 
oder funktionalen Grenzen gesprengt haben. Gleichzeitig hat sich 
herausgestellt, daß die Projekte an Umfang zunahmen und es häufig gar 
nicht mehr möglich war, in einem ökonomisch vertretbaren und von einem 
menschlichen Geist erfaßbaren Rahmen alles bis ins Detail voraus zu 
planen.

Das heißt natürlich nicht, daß agile Projekte immer erfolgreich wären 
oder klassische Projekte immer zum Scheitern verurteilt wären. Aber in 
meinen ganz persönlichen Erfahrungen war die Erfolgsquote in agilen 
Projekten höher, und die Arbeit deutlich entspannter... okay, jedenfalls 
meistens. :-)

von A. B. (funky)


Lesenswert?

Schön wirds, wenn dann überall wo Scrum (aufgrund der halbherzigen 
Einführung usw.) nicht oder nur bescheiden funktioniert, SAFE ausgerollt 
wird.

Dann wird gekotzt.
Ich stehe Scrum positiv gegenüber und hab auch schon gesehen wie es ganz 
gut funktioniert hat (wenn man ehrlich war und nicht alles verbogen hat, 
um Schönheit nach oben zu Faken)

Aber bei SAFE hörts auch bei mir auch. In einer Firma wo Scrum schon 
nicht funktioniert ist das der super-Gau und es geht gar nix mehr.

von Uwe D. (monkye)


Lesenswert?

SAFe wird ja nicht für ein „normales“ (agiles) Projekt genutzt, 
wohingegen „SAFe“ ja ausdrücklich für sehr große und häufig mehrere 
parallel laufende Großprojekte mit sehr hoher Komplexität angewendet 
wird.
Zumindest kenne ich es so. Und dann braucht man halt auch passende 
Werkzeuge und ausgebildete Menschen dafür.

Das ist ja nicht anders als in Wasserfallprojekten oder Programmen: Mit 
Sprüchen und Marketing kommt Niemand ans Ziel.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Ein T. schrieb:
> 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte
> gescheitert waren
Bei Softwareprojekten ist ein dynamisches Umsteuern ja auch leichter 
möglich. Daher lässt sich Scrum auch dort noch am ehesten wirksam 
einsetzen. Ich sehe aber, dass es für alles eingesetzt wird. Bei HW geht 
das gar nicht. Schon wegen Lieferketten, Teilebestellung etc und vielem 
mehr.

von Uwe D. (monkye)


Lesenswert?

J. S. schrieb:
> Ein T. schrieb:
>> 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte
>> gescheitert waren
> Bei Softwareprojekten ist ein dynamisches Umsteuern ja auch leichter
> möglich. Daher lässt sich Scrum auch dort noch am ehesten wirksam
> einsetzen. Ich sehe aber, dass es für alles eingesetzt wird. Bei HW geht
> das gar nicht. Schon wegen Lieferketten, Teilebestellung etc und vielem
> mehr.

Wie überraschend: Warum sollten Störungen in Wasserfallprojekten besser 
zu handhaben sein, das musst Du jetzt mal erklären.

Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte 
ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem 
2,5-fach über dem Planbudget…

: Bearbeitet durch User
von A. B. (funky)


Lesenswert?

Uwe D. schrieb:
> SAFe wird ja nicht für ein „normales“ (agiles) Projekt genutzt,
> wohingegen „SAFe“ ja ausdrücklich für sehr große und häufig mehrere
> parallel laufende Großprojekte mit sehr hoher Komplexität angewendet
> wird.
> Zumindest kenne ich es so. Und dann braucht man halt auch passende
> Werkzeuge und ausgebildete Menschen dafür.
>

Wäre schön. ich hab es nur erlebt, als es betriebsblind ohne 
Hinterfragung einfach über alles gestülpt wurde. Teams nie die 
Berührungspunkte miteinander haben, saßen dann im PI rum.
Für Unmut sorgte auch, dass an vielen Stellen die Leute fehlen. Wurde 
nix gemacht. Für SAFe wurden aber plötzlich haufenweise neue Leute 
eingestellt um die vorgesehenen Rollen zu besetzen. Hat auch für einiges 
an Unmut gesorgt

Kann man sicherlich nicht SAFe per se anlasten, aber wenn so ein Prozess 
einfach durchgeprügelt wird ohne Punkt und Komma und ohne mal 
Innezuhalten und zu überlegen, ob es auch nur ansatzweise Sinn ergibt, 
dann  kommt bei SAFe noch größerer Murcs raus als wenn Scrum in der Art 
& Weise eingeführt wird

von Katrin I. (Gast)


Lesenswert?

A. B. schrieb:
> bei SAFe noch größerer Murcs raus als wenn Scrum in der Art
> & Weise eingeführt wird
Alles was ohne Verstand eingeführt wird, dürfte darunter leiden und 
scheitern.

A. B. schrieb:
> wurden aber plötzlich haufenweise neue Leute
> eingestellt um die vorgesehenen Rollen zu besetzen.
Das kenne ich aus der Firma, für die ich zuvor tätig wurde. Ich war eine 
der Personen, die in eine neu geschaffene Rolle eingesetzt wurden. Es 
war keine aktive SCRUM-Rolle aber es war die Folge dessen Einführung und 
der Neuorganisation der Abteilungen.

Ich merkte sehr schnell, daß das Problem der Firma nicht die 
Projektorganisation sondern einfach die Anzahl der Bearbeiter war. Die 
neu eingeführten Organisations-meetings raubten ihnen noch mehr Zeit, 
als es davor schon der Fall war. Als die Firma auf SCRUM umgestellt war, 
ging es noch holpriger voran.

Hat dann auch direkt einer gekündigt.

von Ein T. (ein_typ)


Lesenswert?

A. B. schrieb:
> [...SAFe...]
>
> Wäre schön. ich hab es nur erlebt, als es betriebsblind ohne
> Hinterfragung einfach über alles gestülpt wurde.

Wie erwähnt, erlebt haben die meisten von uns sicherlich schon vieles. 
Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer 
einzuschlagen, dann ist das weder die Schuld des Hammers, noch die der 
Schraube. Und genau wie man mit jeder Programmiersprache besch...eidenen 
Code schreiben kann -- sogar in Python -- kann man mit jedem 
Projektmanagement Projekte verkacken.

von Andi (chefdesigner)


Lesenswert?

Ein T. schrieb:
> Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer
> einzuschlagen,
Dann kannst du ein anderes Werkzeug nehmen.

Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen 
zwingt, ist das etwas problematischer mit dem "sich richtig verhalten". 
Besonders, wenn andere den Hammer nicht zur Seite legen und das 
Einkloppen der Schrauben zur Maxime erklärt wird.

Wenn eine Firma als Beispiel eingeführt, dass alles mit dem 
Akku-Schrauber zu  machen ist, dann hat der Feinwerktechniker verka**t. 
Er könnte ohne diese Automatismen besser schrauben, schneller und 
genauer.

von Re D. (re_d228)


Lesenswert?

A. F. schrieb:
> Dann kannst du ein anderes Werkzeug nehmen.
>
> Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen

Eine Struktur ist halt kein Werkzeug. Eine Struktur sagt lediglich, wo 
man das Werkzeug findet und was für Prozesse man bei der Nutzung 
beachten muss (UVV-Prüfung gültig?). Wenn du mit der Struktur nicht klar 
kommst, dann ist das halt so, die Ludolfs haben auch eine andere 
Struktur als eine VW.

von Ein T. (ein_typ)


Lesenswert?

A. F. schrieb:
> Ein T. schrieb:
>> Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer
>> einzuschlagen,
> Dann kannst du ein anderes Werkzeug nehmen.

Wenn ich eines habe, aber: in meiner Fabel ging es gar nicht um mich.

> Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen
> zwingt,

... dann gibt es ein probates Mittel, das sich "Kündigung" nennt.

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?

Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken 
der Details...

So wie halt früher von guten Ingenieuren der Entwicklungsprozess 
gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch 
ihre Details miteinander bedächtig ausgetauscht haben?

Ich hatte immer den Eindruck, wir wären ganz gut gefahren mit den 
etablierten Methoden früherer Zeiten. Ist das wieder mal nach " If it 
works, break it"?

Ist es wirklich ein Vorteil, so hastig vorzugehen? Ich kann mir unter 
Scrum Bedingungen nicht vorstellen, daß man dort bedächtig und planvoll 
voranschreiten könnte.

Auch ist der Mensch keine Maschine. Wir brauchen auch Pausen zum 
Überdenken und Reflektion. Auch muß man manchmal Zeit zum Überdenken bei 
der Problemlösung zur Verfügung haben.

Ich würde besorgt sein, in ein Fahrzeug oder Flugzeug zu steigen und 
wissen, daß Scrum bei der Entwicklung im Spiel war.

Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht 
arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver 
Rückkopplung?

Mich würde wirklich interessen, wie erfahrene ältere Ingenieure über 
solche Sachen denken, ohne gleich wegen "Eingefahren" beschuldigt 
werden.

Was brauchen wir übrigens soviel Software und embedded Technik in 
unserem Leben? Ich bekomme zunehmend den Eindruck wir müllen uns mit 
gängelnder Technik zu in unserem täglichen Leben. Da ist weniger und 
essenziell besser. Wir sollten alle viel kritischer sein, mit der 
Adoption von SW Gadgets, die um uns herum sind. Vieles ist, wenn es 
wirklich darauf ankommt, ziemlich nutzlos.

Was mich betrifft gehe ich nach der Devise vor, weniger ist besser und 
verwende "Tried and True" Philosphie ohne zum Lebensstress beizutragen. 
Das besorgt das Leben alleine. Und da seid ihr mit Eurer SW Entwicklung 
auf Steroidbasis und müllt unser Leben mit Technik zu die wir eigentlich 
nicht wirklich brauchen und man sich wegen der vielen Bugs doch nicht 
verlassen kann. Und in Technik die mit Sicherheit zu tun hat, sollte 
ohnehin bewährte Entwicklungsmethodologie vorrangig sein.

Ich mag mich vielleicht in einigen Punkten irren; kann man aber wirklich 
so Vertrauen zum Produkt haben?

Wenn ich mir den trivialen Elektronik Müll vor Augen halte, bin ich 
wirklich froh einen gewissen Abstand halten zu können und nur das Beste 
heraus zu picken, sozusagen die Rosinen finden, die wirklich das Leben 
tangentiell bereichern.

Welcher Hahn kräht denn nach den Produkten einer zu hastigen Industrie 
die überhaupt keine Bestandsdauer haben? Ist Scrum das wert? Die 
modernen Firmen machen sich vielleicht oft was vor und merken erst viel 
zu spät, daß mit traditioneller Denkweise viel mehr erreicht werden 
hätte können.

Unsere Wirtschaft produziert in der IT und Elektronik fast nur noch 
"Eintagsfliegen". Die wichtigen Produkte unserer Wirtschaft müssen eben 
anders angegangen werden. Konsumerprodukte, unter Scrum geschaffen, 
bringen viel Zweifel auf, weil man als Fachmann einfach wenig Vertrauen 
zu dieser Arbeitsmethode haben kann.

Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise 
wirklich dauerhafte Erfolge bringen könnte. Man hat ja scheinbar wenig 
Zeit zum Durchdenken des Designs und guter Dokumentation. In meiner 
Arbeitspraxis hat mich gute Begleitdokumentation meiner Projektarbeiten 
oft sehr geholfen oder mir Zeit gespart.

Ich bin ein alter Sack, aber ich würde kündigen, wenn ich in solch 
chaotische Firmen überwechseln oder mich da einfügen müsste. Ich weiß 
ich werde von Euch was zu hören kriegen. Aber ich vermute, ich habe 
schon etwas recht.

Kopfschüttelnd,
Gerhard

von Michael B. (laberkopp)


Lesenswert?

Gerhard O. schrieb:
> Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise
> wirklich dauerhafte Erfolge bringen könnte

Für Manager zählen dauerhafte Einnahmen. Und die gibt es mit Scrum, weil 
der Kunde eingebettet ist in die ständig nur halbfertigen Projekte. 
Zudem kann der Manager nachweisen wie seine Arbeitsaffen ständig 
produktiver werden in dem er die Velocity des Scrum als Massstab für das 
nutzt, was er sowieso nicht versteht.

Und die Arbeitsaffen gehen begeistert mit, wurde ihnen doch erzählt wie 
wichtig sie sind, dass sie sich selbst verwalten, keinen Chef haben 
sondern ein Team sind.

Dass aus dem ganzen Kram nichts ausser Scheisse rauskommt, wie man 
selbst an den wenigen super finanzierten Projekten wie eBay oder 
ChefKoch oder AliExpress sieht, spielt keine Rolle. Da muss die erste 
Seite glänzen, die Monetarisierung funktionieren, und ob 404 oder altes 
Zeug in den hinteren Ecken spielt keine Rolle.

von Andi (chefdesigner)


Lesenswert?

Re D. schrieb:
> die Ludolfs haben auch eine andere
> Struktur als eine VW.

Die hatten aber eine der Aufgabe angemessene Struktur. Man bekam dort 
schnell und günstig Ersatzteile und der Verwalter wusste, wo es zu 
finden war.

Bestelle dir bei VW ein Ersatzteil! Dann zahlst du den gesamten 
Wasserkopf mit. Der ist für viele Dinge aber nicht nötig und nicht 
angepasst.

Zurückkommend auf das Thema bleibt einfach festzustellen, dass Scrum an 
vielen Stellen zwar offiziell eingeführt ist, aber nur selten passt. Es 
klappt nicht, weil es dort, wo es funktionieren könnte, nicht gelebt 
wird und an vielen Stellen eben die falsche Struktur ist.

Scrum und Elektronikentwicklung passen nun einmal nicht zusammen.

Scrum kannst du bestenfalls dort einsetzen, wo es für gemacht ist, also 
z.B. für eine SW Truppe, die embedded programmiert und das Projekt so 
umfangreich ist, dass es nicht einer alleine packt und selber 
organisiert.

von Steve van de Grens (roehrmond)


Lesenswert?

Gerhard O. schrieb:
> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?

Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er 
es oft nicht, speziell bei komplexen Projekten.

von Steve van de Grens (roehrmond)


Lesenswert?

Gerhard O. schrieb:
> Ich bin ein alter Sack, aber ich würde kündigen, wenn ich in solch
> chaotische Firmen überwechseln oder mich da einfügen müsste.

Ich sehe es als sportliche Herausforderung. Solange ich mit halten kann 
und will, schwimme ich oben. Niemand zwingt mich dazu, meine Produkte 
selbst zu benutzen oder gar gut zu finden. Ich muss sie nur so bauen 
(bzw. programmieren), wie andere es haben wollen.

von Markus L. (tap)


Lesenswert?

Gerhard O. schrieb:
> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?
>
> Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken
> der Details...
>
> So wie halt früher von guten Ingenieuren der Entwicklungsprozess
> gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch
> ihre Details miteinander bedächtig ausgetauscht haben?

Daran ist nicht prinzipiell etwas falsch, das funktioniert oft wunderbar 
wenn 15 Leute an einem Projekt arbeiten.
Wenn 50 Leute an einem Projekt arbeiten ist es nicht mehr so einfach die 
Details miteinander bedächtig auszutauschen. Da ergibt es schon Sinn, 
das Projekt aufzuteilen und die Kommunikation zu organisieren.
Das ist ja noch recht einfach, wenn das Projekt in 
Hardware-Software-Mechanik mit jeweils kleinen Teams aufzuteilen ist, ab 
einer gewissen Größe ist aber einfach eine weitere Aufteilung nötig.

> Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken
> der Details...

Diese Schritte sollte es natürlich in Scrum auch geben. Sie sind halt 
auf unterschiedliche Leute aufgeteilt. Der Ausführende kümmert sich dann 
immer nur um ein Detail, wie dieses Detail ins größere Bild paßt sollte 
jemand anders überblicken.

Gerhard O. schrieb:
> Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht
> arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver
> Rückkopplung?

Das Chaos habe ich auch bei den Methoden des letzten Jahrhunderts immer 
wieder kennengelernt. Das wurde dann durch inoffizielle Strukturen - mal 
besser, mal schlechter - in den Griff gebracht.
Scrum ist halt einer von vielen Versuchen, dieses Chaos durch offizielle 
Strukturen in den Griff zu bekommen.

Und natürlich leidet Scrum an den selben Problemen wie all die anderen 
Säue die durchs Dorf gejagt wurden.
Das Management liest den Werbefolder, um die Details der Umsetzung soll 
sich jemand anderer kümmern.
- Scrum wird oft eingesetzt, wo es keinen Sinn ergibt.
- Es fehlt die Unterstützung des Management. z.B. erhalten nicht die 
richtigen Leute Entscheidungsbefugnisse, die Firmenstrukturen werden 
nicht angepaßt, ...
- Es fehlt die Unterstützung der Ausführenden. Vom Management kommt nur 
die Vorgabe: setzt Scrum um. Was man sich davon erwartet bleibt ein 
Staatsgeheimnis. Also setzt man irgendetwas um, das man dann Scrum 
nennt. Damit das Management zufrieden ist.
- Man erwartet sich von Scrum Dinge, für die es höchstens eine Basis 
darstellt. z.B. Kommunikation: Wenn die Leute die wichtigen 
Informationen für sich behalten, dann ist es egal, wie viele 
Besprechungen, und mit wem, stattfinden.

Erst vor kurzem bin ich darauf gekommen: Scrum ist angeblich schon seit 
Jahren in der Firma etabliert. Da habe ich die ganze Zeit nicht das 
geringste davon bemerkt. Aber irgendwer im mittleren Management konnte 
das von seiner ToDo-Liste streichen.
Und dann fragt man sich, ob Scrum funktioniert? Diese Frage stellt sich 
oft gar nicht erst.

von Markus L. (tap)


Lesenswert?

Steve van de Grens schrieb:
> Gerhard O. schrieb:
>> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?
>
> Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er
> es oft nicht, speziell bei komplexen Projekten.

Das herauszufinden ist immer wieder ein eigenes Projekt.
Es hat halt sowohl Vor- als auch Nachteile, wenn man das gleich mit der 
Umsetzung zusammen macht.

von Ein T. (ein_typ)


Lesenswert?

Gerhard O. schrieb:
> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?

Daß sie mit zunehmender Komplexität immer schlechter und irgendwann gar 
nicht mehr funktionieren. Lies einfach den Thread.

von Uwe D. (monkye)


Lesenswert?

Gerhard O. schrieb:
> Moin,
>
> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?
>
> Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken
> der Details...

Wenn Du die Kosten übernehmen musst, für alle schief gelaufenen Sachen, 
die nicht bedacht wurden, die sich inzwischen geändert hatten (seit 
Erstellung des LH) und dem, was der Kunde eigentlich braucht… dann 
ändert sich vielleicht Deine Sichtweise.
Und jedes neue Jahr, welches das Projekt verschlingt - wegen der CRs - 
steigern die Kosten - und der Auftraggeber hat immer noch kein Produkt 
und muss weiter warten…

>
> So wie halt früher von guten Ingenieuren der Entwicklungsprozess
> gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch
> ihre Details miteinander bedächtig ausgetauscht haben?
Früher war nicht alles besser - und auch nicht billiger, insbesondere 
bei Wasserfallprojekten.

> Ist es wirklich ein Vorteil, so hastig vorzugehen? Ich kann mir unter
> Scrum Bedingungen nicht vorstellen, daß man dort bedächtig und planvoll
> voranschreiten könnte.
Naja, was hat denn SCRUM (oder agil) mit „hastig“ zu tun?

> Ich würde besorgt sein, in ein Fahrzeug oder Flugzeug zu steigen und
> wissen, daß Scrum bei der Entwicklung im Spiel war.

Du meinst also, das Toyota unsichere Autos baut?

> Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht
> arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver
> Rückkopplung?
Sorry Gerhard, hast Du persönlich genau diese Erfahrung gemacht? Also 
ich nicht. Dafür habe ich insbesondere im erfolgreichen Mittelstand zu 
oft erlebt, wie assozial der Inhaber oder GF mit den Arbeitnehmern 
umgegangen ist - weil ich das „Gespräch“ noch 50m weiter im 
Konferenzraum gehört habe.


> Mich würde wirklich interessen, wie erfahrene ältere Ingenieure über
> solche Sachen denken, ohne gleich wegen "Eingefahren" beschuldigt
> werden.
Argumente zu bringen doch kein Problem, nur interessiert mich die 
persönliche Schublade nicht. Also: nicht bewertend und nicht vom Thema 
abschweifend.


> Was brauchen wir übrigens soviel Software und embedded Technik in
> unserem Leben? Ich bekomme zunehmend den Eindruck wir müllen uns mit
> gängelnder Technik zu in unserem täglichen Leben.
Die „Sinnfrage“ hat jetzt aber nix mehr mit SCRUM zu tun.


>  Und in Technik die mit Sicherheit zu tun hat, sollte
> ohnehin bewährte Entwicklungsmethodologie vorrangig sein.

Trotzdem wird auch sicherheitsrelevante Software erfolgreich mit SCRUM 
entwickelt, seit mehr als 10 oder 15 Jahren.


> Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise
> wirklich dauerhafte Erfolge bringen könnte. Man hat ja scheinbar wenig
> Zeit zum Durchdenken des Designs und guter Dokumentation. In meiner
> Arbeitspraxis hat mich gute Begleitdokumentation meiner Projektarbeiten
> oft sehr geholfen oder mir Zeit gespart.
Du hast keine Erfahrung mit SCRUM, anders ist Deine Beurteilung für mich 
nicht zu verstehen.
Vielleicht hilfts ja, mal mit erfahrenen SCRUM Anwendern zu sprechen 
oder über die Schulter zu schauen. Vermutlich wärst Du überrascht, wie 
zufrieden Kunden sein können und wie konsequent mit „Klugscheißern und 
Faulpelzen“ umgegangen wird…

von Gerhard O. (gerhard_)


Lesenswert?

Hallo Uwe,

Wie ich sehe hast Du Dir die Zeit genommen, meinen "aufgewirbelten 
Staub" mit dem sachlichen "Besen" wieder in den richtigen Platz fegen zu 
versuchen:-)

Nun ja! Was soll ich darauf antworten? Bei uns geht es noch ohne Scrum 
zu. Da wir nur acht Entwickler zählen, haben wir uns gut aufeinander 
eingespielt. Generell läuft alles harmonisch und mehr oder weniger 
innerhalb der Gefüge und notwendige Erörterungen sind spontan und 
informal. Ich glaube schon, der Laden läuft. Das Thema ist übrigens hier 
niemals, nicht einmal ansatzweise, aufgekommen. Allerdings kann sich ein 
kleiner Betrieb nicht leisten, "unfähig" zu agieren. Da geht es wirklich 
um technische Klarheit und Sauberkeit.

Wenn man alles hier so liest, bekommt man einen sehr widersprüchlichen, 
chaotischen Eindruck. Ist wahrscheinlich, wie sonst im Internet, mit 
viel Wahrheit und Unwahrheit vermischt. Möglicherweise mache ich mir ein 
falsches, oder zumindest ein verzerrtes, Bild davon. Ich weiß es nicht.

Man bekommt schon den Eindruck, Scrum ist alles andere als Bedächtigkeit 
und ruhiges Vorgenen und Ausführung. Zusammen mit den menschlichen 
Unvollkommenheiten wird da ein düsteres Bild gemalt. Andrerseits bekomme 
ich von Dir den Eindruck, daß Scrum tatsächlich sehr von den 
menschlichen Qualitäten des Entwicklungsteams abhängig ist und 
Unvollkommenheiten stärker zum Ausdruck kommen. Aber da muß die PL sich 
im Klaren sein, daß sie hier entsprechend organisieren müssen und nicht 
ein zusammengewürfeltes Team ohne Harmonie. Die Mißtöne machen sich dann 
sonst sofort bemerkbar.

Insgesamt bekommt hier im Forum leider schon allgemein ein sehr 
negatives Bild von Scrum. Bei Diskussionen über Scrum bekommt den 
Eindruck einer chaotischen Umgangsatmosphäre ohne daß die Mitglieder in 
eine gemeinsame Richtung ziehen.

Du erwähntest Autos. Nun gut, mein 2006er Toyota war ziemlich perfekt. 
Mein 2021 Mazda softwaremässig weniger so. Da könnte ich viele, auf eine 
andere Sichtweise, demonstrierte Einstellungsweise, Verhalten und 
Inkonsistinenzen aufmerksam machen, die eigentlich nicht vorkommen 
sollten, die man als Fachmann schon bemerkt. Das Fahrzeug selber ist 
schon gut. Aber die SW darin, könnte man wesentlich verfeinern und 
benutzerfreundlicher machen.

Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein 
soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet. 
Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das 
verschlingt viel Energie, Zeit und Geld.

OK. Ich merke, Deine Einwände sind ehrlich und objektiv und geben Anlass 
mit den Vorurteilen gegenüber vielleicht sparsamer umzugehen:-)


Gruß,
Gerhard

: Bearbeitet durch User
von Katrin I. (Gast)


Lesenswert?

Gerhard O. schrieb:
> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert?

Nur der Vollständigkeit halber:

Scrum ist auch aus dem letzten Jahrhundert. Es wurde Ende der 1980er 
Jahre bis Anfang der 1990er Jahre erdacht. Es ist also ein mindestens 30 
Jahre alter Hut.

von Franko S. (frank_s866)


Lesenswert?

Scrum dient doch in Wahrheit nur dazu Arbeit so kleinteilig aufzudröseln 
dass ein beliebiger Idiot die Arbeit des anderen übernehmen kann. Das 
Ganze lässt sich dann auch noch gut tracken und überwachen, sprich man 
kann die Leute einfacher unter Druck setzen. "Du bist zu langsam, dein 
Kollege schafft mehr Minitasks in der gleiche Zeit also gib mal Gas du 
faule Sau".
Das ist praktisch die Fliesbandisierung der Kopfarbeiter.

von Katrin I. (Gast)


Lesenswert?

Franko S. schrieb:
> dass ein beliebiger Idiot die Arbeit des anderen übernehmen kann.
Es reicht nicht, die Aufgabe zu benennen und ihr einen Namen zu geben.
Es muss definiert werden, was zu tun ist, wie sie umzusetzen ist und in 
welche Komponenten sie zu unterteilen ist. Das Ganze dann so, dass es 
mit den Tätigkeiten und Aufgaben anderer harmonisiert.

Das muss so oder so passieren. Auch wenn es die Gruppe selbst definiert, 
also jeder für sich, müssen die Inhalte der Aufgaben und Lösungen 
dokumentiert werden. Ohne das geht es nicht. Wird das unterlassen, hilft 
auch scrum nicht. Dann kann niemand nirgendwo einspringen.

Wird das hingegen ausreichend gut gemacht, können andere in die Lücken 
hinein springen, das ist richtig. Ob es effektiv ist, daß jeder alles 
vom Projekt ganz genau in der erforderlichen Tiefe kennt, um das im 
Ernstfall auch wirklich zu leisten, ist eine andere Frage, die sich die 
Firme beantworten muss.

Daß kleinteilige Aufgaben das tracking verbessern, ist auch richtig. 
Muss aber irgendwie sein, wenn kontrolliert werden soll, wo die Gruppe 
steht. Zumindest die Gruppe muss wissen, wo sie steht.

Allerdings kommt da bei mir eine Frage auf:

Sind die Aufgaben, die die Gruppe zur Umsetzung der Lösungen definiert 
und abarbeitet, vom Scrum Master einsehbar? Oder auch der 
Geschäftsleitung?

Wie sieht es mit den Teilaufgaben und der Zuordnung zu den Personen aus?
Ist das von der Teamleitung einsehbar? Dann könnte es zur Beurteilung 
herangezogen werden, was aber problematisch ist.

Bleibt das als Arbeitsdukumentation dauerhaft gespeichert?
Könnte es mit einer Software ausgewertet werden, wie lange jeder 
einzelne an einer Aufgabe dran war?

Ich kann mich an einen AG erinnern, der die Protokolle der Mitarbeiter 
an den Maschinen automatisch ausgewertet hatte und Ärger mit dem 
Betriebsrat bekam, weil die berechtigen Schutzinteressen verletzt waren. 
Es war gegen den Datenschutz das elektronisch zu speichern, weil es 
automatisch auswertbar war. Als Folge mussten die Protokolle ohne den 
Bearbeiter in SAP gespeichert werden und der Zusammenhang zwischen 
Person und Protokoll blieb nur als Papier im Ordner. Die Datenbank, die 
die Fehler und die Maßnahmen an der Anlage protokollierte, wurde auch 
zusammengestrichen. Die Installationspläne mussten nach einer Weile 
gelöscht werden, weil durch die Planungen letzterdings die Urlaube und 
Krankheiten nachvollzogen werden konnten und es offensichtlich war, wie 
lange jeder Überstunden gemacht hatte.

Nachtrag: Ich mache jetzt doch einen Extra Beitrag dazu:
Beitrag "verletzt die Arbeit mit SCRUM die Betriebsratsvereinbarungen?"

von Bruno V. (bruno_v)


Lesenswert?

Gerhard O. schrieb:
> Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein
> soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet.
> Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das
> verschlingt viel Energie, Zeit und Geld.

Wenn Du Scrum mit fortlaufenden Zieländerungen assoziierst, dann geht 
das natürlich nicht. Die Koordination der vielen Teil-Arbeiten, neuer 
Baustellen und alle non-safety-Teile profitieren dagegen genauso viel 
oder wenig wie SW ohne Safety.

von Uwe D. (monkye)


Lesenswert?

Gerhard O. schrieb:
> Hallo Uwe,
>
> Wie ich sehe hast Du Dir die Zeit genommen, meinen "aufgewirbelten
> Staub" mit dem sachlichen "Besen" wieder in den richtigen Platz fegen zu
> versuchen:-)

Hallo Gerhard,

beim letzten Forumstreffen in Dresden saßen viele Meinungen und 
Persönlichkeiten im Biergarten und konnten mit Respekt und „einfach mal 
stehenlassen“ viel übereinander erfahren - auch über das jeweilige 
Arbeitsumfeld.
Das ist ein prima Fundament für eine Zusammenarbeit.
Du warst damals virtuell dabei ß stimmt‘s?


> Wenn man alles hier so liest, bekommt man einen sehr widersprüchlichen,
> chaotischen Eindruck. Ist wahrscheinlich, wie sonst im Internet, mit
> viel Wahrheit und Unwahrheit vermischt. Möglicherweise mache ich mir ein
> falsches, oder zumindest ein verzerrtes, Bild davon. Ich weiß es nicht.

Meine These: Halbwissen, Hörensagen und persönliche Meinungen - 
diametral dazu  relativ wenige erfahrene Leute im agilen Umfeld.


> Man bekommt schon den Eindruck, Scrum ist alles andere als Bedächtigkeit
> und ruhiges Vorgenen und Ausführung.

SCRUM bzw. Agil - Schnell die Richtung ändern zu können hat nichts mit 
oberflächlich, Massenproduktion, Kleinteiligkeit und „Management Tool“ 
zu tun. Menschen die das behaupten, sind meistens mit keinem Team 
zufrieden - die stehen nur auf ihrer eigenen Seite.

> Zusammen mit den menschlichen
> Unvollkommenheiten wird da ein düsteres Bild gemalt. Andrerseits bekomme
> ich von Dir den Eindruck, daß Scrum tatsächlich sehr von den
> menschlichen Qualitäten des Entwicklungsteams abhängig ist und

Jedes Team entsteht durch Arbeit miteinander. Agile Teams funktionieren 
prinzipiell nicht viel anders als klassische Teams - allerdings gibt es 
keine Hierarchie.
Diese Teams entwickeln weniger Erfahrene aktiv weiter, so dass 
Abhängigkeiten von Spezialisten abgebaut werden und damit der 
„Nachwuchs“ gesichert ist. Zudem hat das Team direkten Einfluss auf das 
Verhalten des Einzelnen: Wer wiederholt nicht das vereinbarte abliefert, 
der kriegt eins auf den Deckel - warum sollte es mit der 
Verantwortung/Verbindlichkeit anders laufen?

> Du erwähntest Autos. Nun gut, mein 2006er Toyota war ziemlich perfekt.
> Mein 2021 Mazda softwaremässig weniger so. Da könnte ich viele, auf eine
> andere Sichtweise, demonstrierte Einstellungsweise, Verhalten und

Das Vorgehen bei Toyota hat mich stark beeinflusst. Vor allem nicht 
ständig immer nur auf Probleme zu fixieren, wurde auch immer die Chance 
betrachtet und wahrgenommen…

> Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein
> soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet.
> Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das
> verschlingt viel Energie, Zeit und Geld.
Ich selbst kann nur von europäischen Firmen sprechen. Wer schon einmal 
eine Software mit SIL > 2 mitgebaut hat - oder eine Zertifizierung nach 
Common Criteria ab EAL3 aufwärts, der weiß das da extrem viel 
Formalismus, Disziplin und vor allem langer Atem notwendig ist, um 
erfolgreich (in Quality, Time & Budget) zu sein.

Jede Menge Systeme wird genau so und mit SCRUM gebaut. Das betrifft 
Aviation, Rail, Automotive, Computing…

In den Projekten in denen ich arbeite, sind oft mehrere hundert Menschen 
involviert, verteilt über Europa. Meine Erfahrung ist zu über 80% 
positiv - es gibt nach wie vor 20% beschissene Projekte - z.B. mit 
völlig unterfinanzierten Vorhaben (Wolkenkuckucksheim) oder bekloppten 
Geldgebern, die sozial unfähig sind und ihre Grenzen nicht kennen.

Was das Thema Produktivität angeht: Der Kunde hat nach Ende des Sprints 
ein Produktinkrement, das er sofort verwenden kann. Und das Produkt ist 
genau so, wie es während der Entwicklung der Kunde selbst definiert hat. 
Und ich als Dienstleister habe implizit die Teilabnahme und ein 
Protokoll - nicht ganz unwesentlich bei der Abrechnung.
Und es gibt eine belastbare Velocity nach spätestens 3-5 Sprints. Dazu 
gibt es ein Commitment der Mitglieder des Teams zum Ziel. Durch die enge 
Zusammenarbeit fällt der ganze Flurfunk weg, denn Transparenz ist 
Pflicht. Wir erreichen damit eine Abrechenbarkeit von 80-90% in 
Projekten, der Rest ist für Weiterbildung und die Entwicklung sozialer 
Fähigkeiten.

Lebensqualität:
Und ich selbst bin fast immer der Älteste in den Projekten und lebe 
beruflich entspannt, meine Gesundheit ist nicht in Gefahr und ich lerne 
sehr gerne von meiner Kollegenschaft - die teilweise deutlich jünger als 
meine Kinder sind.

Beste Grüße aus Dresden,

Uwe

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