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 Berni-Bär 🐼 (stm32prof)


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.

: Bearbeitet durch User
von Berni-Bär 🐼 (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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.

: Bearbeitet durch User
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 Berni-Bär 🐼 (stm32prof)


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 🐻 Bernie - Bär (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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 F. (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 Berni-Bär 🐼 (stm32prof)


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"

: Bearbeitet durch User
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 Berni-Bär 🐼 (stm32prof)


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 F. (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. 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 Berni-Bär 🐼 (stm32prof)


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 🐻 Bernie - Bär (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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. 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 Berni-Bär 🐼 (stm32prof)


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 Berni-Bär 🐼 (stm32prof)


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.

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.