Forum: Ausbildung, Studium & Beruf Meeting-Hölle/Scrum


von Robert K. (Firma: Projektleiter Medizinsoftware) (robident)


Lesenswert?

Huebi H. schrieb:
> 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.

Wie findet denn dann diese Klärung faktisch statt? Redet etwa jeder mit 
der betreffenen fachlich kompetenten Person? Sowas aber auch - wo ist 
dann die Neuerung? Dann braucht es Scum nur zum Ergebnisverkünden? Kann 
nicht sein.

Bernd G. schrieb:
> 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.

Man muss 2 Dinge trennen:

a) Die Aufgabenverteilung und das Festlegen des Vorgehens

b) Die Umsetzung einzelner Aufgaben in Code oder sonstige Dokumente, bzw 
Ergebnisse in der CAD.

Bei a) ist durchaus ein Team denkbar, das aus unterschiedlichen Experten 
besteht und sich Lösungswege überlegt und die Aufgaben für die 
Sprintperiode definiert. Das sollen und müssen die Beteiligten ja tun. 
Das macht allerdings nur Sinn, wenn die zwischenzeitlich erreichten 
Ziele und Ergebnisse auch einen Einfluss auf Folgeentscheidungen und 
Tasks anderer haben können und es somit nötig ist, ist regelmäßig 
auszutauschen.

Bei b) ist es natürlich erforderlich, daß die Team Members wirklich 
austauschbares Wissen haben, wenn sie einen task als Gruppe bearbeiten 
wollen.

Damit hätte man zunächst eine klassische Teamstruktur mit sagen wir 4 
Teamleitern in Level a) und jeweils 2-3 Leuten in der Hierarchie 
darunter in Level b)

Nun sind aber bei Weitem nicht alle Firmen SO aufgestellt! Wirft man die 
nun in ein einziges Scrum Team, ergibt sich das Problem wie oben 
beschrieben, daß viele jeweils nur Herumsitzen und nichts beitragen und 
sich die Planungen und Entscheidungen unnötig verkompliziieren und in 
die Länge ziehen.

Tatsächlich sind die Abteilungen eben nur mit 10-15 Personen besetzt, 
die kaum Subteams bilden können, weil zu unterschiedlich ausgebildet. 
Sie müssten Level a und b gleichzeitig abdecken. Es verfügen aber nicht 
alle über die nötige Planungskompetenz, um in einer solchen Gruppe die 
strategischen Entscheidungen zu tragen. Es ist daher besser,  man bildet 
das Scrum Team nur aus wenigen Experten, die das Wissen abdecken und 
wickelt alle umsetzenden Themen linear nach unten ab.

von Gastino G. (gastino)


Lesenswert?

J. S. schrieb:

> Das ist aber jetzt ein von Scrum losgelöstes Thema, wenngleich ein
> interessantes: Grundsätzlich soll der Papierkram ja sicherstellen DASS
> nach den Normen entwickelt und getestet wurde und die Prüfungen gelaufen
> sind. Ohne Papier wird es daher nicht notwendigerweise unsicherer, aber
> die Vorgehensweise ist belegbar und irgendwo auch tatsächlich belegt.
> Damit ist die Sicherheit formell zumindest bestätigt und durchaus höher.

Naja, es wurde ja angeführt, dass dieser ganze formalistische Kram wie 
Scrum solche sicherheitskritischen Systeme erst möglich macht. Meine 
Erfahrung dazu ist, dass das eine hochgefährliche Illusion ist.
Sicherlich helfen Formalismen bei der Entwicklung von solchen Systemen, 
aber so was wie Scrum ganz sicher nicht.

> Das gilt natürlich nur, sofern a) die Prozesse auch eingehalten wurden
> und b) diese Vorgaben auch adequat waren, was beides nicht unbedingt der
> Fall ist. Ich sehe im Rahmen sicherheitskritischer Entwicklungen immer
> wieder FOkus an Stellen, die früher mal kritisch waren und als Folge in
> die Prozess- und Prüfungslandschaft eingelossen sind, heute aber längst
> gelöst und überholt sind. Teilweise sind die sogar der Sicherheit
> entgegenstehend. Anders herum gibt es Dinge, sich sich noch nicht in den
> Vorgaben niedergeschlagem haben, obwohl die fortschreitende Technik
> diese Probleme aufwirft. Damit stehen sie einer maximalen Sicherheit
> sogar im Wege.

Die Prozesse sind eigentlich alle mehr oder weniger Schrott, da muss man 
sich nichts vormachen. Bisher wurde es immer nur formalistischer und 
bürokratischer. Das Einzige, was Prozesse ermöglichen (und daher sind 
sie auch so beliebt): Man kann sich wunderbar (zum Schein!!) absichern. 
Man hat ja alles gemacht, was gefordert wurde.
Dummerweise interessiert das vor Gericht dann keinen, wenn man auf 
technischer Ebene Fehler gemacht hat, die bei mehr Fokus auf technische 
Probleme und Lösungen hätten auffallen müssen.

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


Lesenswert?

Ich habe jetzt nicht alle Beiträge gelesen, dafür ist der Thread zu 
lang. Was ich als Problem erkannt habe - und da sollte SCRUM ja 
eigentlich gegenhalten, oder? - ist das "individuelle Herrschaftswissen" 
einzelner Teammitglieder. Wie seht ihr das?

Beispiel: Ich kenne eine Firma (1 kreativer und geschäftstüchtiger Chef 
und ca. 5...6 sehr motivierte Progger), die hat mit einem sehr 
umfassenden ERP-System für Druckereien und Verlage ein wirklich gutes 
Produkt am Markt platziert und damit über Jahre richtig Kohle gemacht.

Nun, wir werden alle älter und als der erste Programmierer der 
(modularen Software), der für genau eines der Super-Module zuständig 
war, sich auf seinen Altersruhesitz in die Karibik verabschiedete, 
begann das Drama:

Es gab niemanden, der auch nur ansatzweise beim Code zu diesem Modul 
durchblickte. Als die Kunden nach der ersten Begeisterung dann nach und 
nach doch noch die eine oder andere Ergänzung bzw. Änderung wünschten, 
erkannte man das Problem. Man konnte sie zwar nach Außen hin noch eine 
Weile hinhalten ("Nächste Release ...!"), aber irgendwann wurde es 
ernst.

Die Firma wäre beinahe an dem Problem zerbrochen, wenn man das Tool 
nicht komplett neu geschrieben hätte, weil zumindest die Schittstellen 
bekannt waren. Das hat die Bude um die 3 "Mannjahre" gekostet und 
anstatt ewigem Dank schleicht dem Abtrünnigen nun ziemlicher Frust 
hinterher ...

von Sheeva P. (sheevaplug)


Lesenswert?

Robert K. schrieb:
> Sheeva P. schrieb:
>> Carsten P. schrieb:
>>> Wenn Individuen sich nichtmal an Scrum
>>> gewöhnen können, ist das Projekt schon zum Scheitern verurteilt.
>>
>> Das könnte die klügste Aussage im ganzen Thread sein. Danke.
>
> Nicht zwangsläufig! Es ist absolut legitim, Prozesse infrage zustellen,

Irgendwie vermisse ich einen Zusammenhang zwischen Deinen Aussagen und 
denen meines Vorposters. Letzten Endes geht es bei agilen Methoden um 
Kommunikation, nicht um Prozesse. Willst Du jetzt die Kommunikation der 
Teams untereinander und mit den anderen Teams in Frage stellen? Oder 
möchtest Du in Frage stellen, daß jedes Projekt zwangsläufig scheitern 
wird, wenn diese Kommunikationen in und unter den Teams nicht 
stattfinden?

von Sheeva P. (sheevaplug)


Lesenswert?

Frank E. schrieb:
> Ich habe jetzt nicht alle Beiträge gelesen, dafür ist der Thread zu
> lang. Was ich als Problem erkannt habe - und da sollte SCRUM ja
> eigentlich gegenhalten, oder? - ist das "individuelle Herrschaftswissen"
> einzelner Teammitglieder. Wie seht ihr das?

Ich sehe nicht, daß das etwas mit Scrum zu tun hätte. Scrum und andere 
agile Methoden sind keine Allheilmittel.

von Michael B. (laberkopp)


Lesenswert?

Frank E. schrieb:
> Wie seht ihr das?

Es kann halt nicht Jeder Alles.

Wenn man Überdurchschnittliches will, muss man Spezialisten haben, deren 
Fähigkeiten und Verstand zumindest in ihrem Spezialbereich über das 
hinaus geht was die anderen können. Helden. Alle herausragenden Produkte 
stammen von Helfen.

Und damit hat sich Scrum erledigt.

Scrum bringt nur Durchschnittliches.

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


Lesenswert?

Sheeva P. schrieb:
> Frank E. schrieb:
>> Ich habe jetzt nicht alle Beiträge gelesen, dafür ist der Thread zu
>> lang. Was ich als Problem erkannt habe - und da sollte SCRUM ja
>> eigentlich gegenhalten, oder? - ist das "individuelle Herrschaftswissen"
>> einzelner Teammitglieder. Wie seht ihr das?
>
> Ich sehe nicht, daß das etwas mit Scrum zu tun hätte. Scrum und andere
> agile Methoden sind keine Allheilmittel.

Ist es nicht auch ein Aspekt der Prozessorganisation, solche Situationen 
zu vermeiden? Quasi "integral"?

von Sheeva P. (sheevaplug)


Lesenswert?

Michael B. schrieb:
> Wenn man Überdurchschnittliches will, muss man Spezialisten haben, deren
> Fähigkeiten und Verstand zumindest in ihrem Spezialbereich über das
> hinaus geht was die anderen können. Helden. Alle herausragenden Produkte
> stammen von Helfen.
>
> Und damit hat sich Scrum erledigt.

Das Eine schließt das Andere nicht aus. Auch Helden müssen 
kommunizieren, Informationen erhalten und weitergeben.

> Scrum bringt nur Durchschnittliches.

Durchschnittlichkeit wäre für Deine "Beiträge" ein riesiger Fortschritt.

von Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)


Lesenswert?

Michael B. schrieb:
> Alle herausragenden Produkte stammen von Helfen.

Korrektur (um Wiederholung gleichen Inhaltes zu vermeiden):

Alle herausragenden Produkte stammen von Elfen.

https://de.wikipedia.org/wiki/1,_2_oder_3
Ob ihr recht habt oder nicht, sagt euch gleich das Licht!

von Sheeva P. (sheevaplug)


Lesenswert?

Frank E. schrieb:
> Sheeva P. schrieb:
>> Ich sehe nicht, daß das etwas mit Scrum zu tun hätte. Scrum und andere
>> agile Methoden sind keine Allheilmittel.
>
> Ist es nicht auch ein Aspekt der Prozessorganisation, solche Situationen
> zu vermeiden? Quasi "integral"?

Scrum ist kein Allheilmittel. Das behaupten nur die, die entweder etwas 
damit verscherbeln wollen, oder jene, die "Argumente" dagegen suchen und 
dann, qed, sofort lautstark beklagen, daß es kein Allheilmittel ist.

Zu kommunizieren, wie bestimmte Softwaremodule funktionieren, gehört 
aber nicht zu Scrum oder irgendeiner anderen agilen Methode. 
Dokumentation ist ein inhärenter Bestandteil professioneller 
Entwicklungsarbeit, und es ist Aufgabe eines funktionierenden 
Controlling in diesem Bereich, das durchzusetzen. Eine Möglichkeit, so 
etwas umzusetzen, wäre die Methode des Code Review. Dann muß 
(mindestens) ein zweiter Entwickler bestätigen, daß er den Code gelesen 
(und natürlich verstanden) hat, bevor er in den Hauptzweig integriert 
wird.

von Achim H. (anymouse)


Lesenswert?

Frank E. schrieb:
> Sheeva P. schrieb:
>> Frank E. schrieb:
>>> Ich habe jetzt nicht alle Beiträge gelesen, dafür ist der Thread zu
>>> lang. Was ich als Problem erkannt habe - und da sollte SCRUM ja
>>> eigentlich gegenhalten, oder? - ist das "individuelle Herrschaftswissen"
>>> einzelner Teammitglieder. Wie seht ihr das?
>>
>> Ich sehe nicht, daß das etwas mit Scrum zu tun hätte. Scrum und andere
>> agile Methoden sind keine Allheilmittel.
>
> Ist es nicht auch ein Aspekt der Prozessorganisation, solche Situationen
> zu vermeiden? Quasi "integral"?

Nein, Weiterbildung, Wissensmanagement und Wissenstransfer ist nicht die 
Aufgabe eines Vorgehensmodells oder der Prozessorganisation, sondern 
geht darüber hinaus. Diese sind -- vermute ich -- auch kein Bestandteil 
des Wasserfall-Modells oder V-Modells.

von Achim H. (anymouse)


Lesenswert?

Ein paar weitere Anmerkungen:

* In einem Scrum-Team müssen nicht alle das gleiche können, im 
Gegenteil. Heterogene Teams sind ausdrücklich erwünscht. Nur weil das 
Team seine Aufgaben selbst aufteilt bzw. Personen zuordnet, heist das ja 
nicht, das eine Zuordnung beliebig sein muss. Desweiteren kann das Team 
auch mal eine Aufgabe einem darin nicht so ganz erfahrenen Teammitglied 
zuweisen, etweder um das erfahrene Teammitglied für andere Aufgaben zu 
entlasten, oder auch damit das unerfahrene Teammitglied Erfahrungen 
sammeln kann. Das Team mussentscheiden dürfen, dass ein Teilaspekt der 
Arbeit nicht optimal angegangen wird, wenn dafür deas Ganze (der 
aktuelle Sprint oder auch die weiteren) optimaler laufen kann.

* Ich finde die Anzahl der Meetings nicht entscheidend, sondern 
vielmehr deren Effizienz. Bei einem Daily, was 15 Minuten dauert aber 
keinen Gewinn für die Sprintarbeit des Teams liefert, sollte eher 
überlegt werden, wie man das effizienter (Kürzer oder besseren Inhalt) 
gestalten kann. Beispiel: Geht man besser die einzelnen Personen durch, 
oder aber die aktuell bearbeiteten Themen? Was sollte man im Daily 
nennen, und was nicht? Kann man Themen auf Gespräche nach dem Daily in 
kleineren Gruppen verschieben?

* Scrum soll ein Vorgehensmodell sein als Alternative zum V-Modell, 
Wasserfallmodell, Kanban, etc., um ein systematisches Vorgehen anstelle 
eines "Wir arbeiten mal irgendwie vor uns hin" zu bekommen. Dabei kann 
Scrum zum jeweiligen Prozess, Produkt, Umfeld passen, oder nicht.

* Scrum hat Nachteile, die kommen hier aber selten ins Gespräch. Viel 
wird m.E. über die Unzulänglichkeiten eines missbrauchten werkzeugs 
gesprochen (a la: Der Griff eines Torx-Schraubers ist einfach zu weich, 
um die Schraube in die Wand zu hämmern, also ist Torx viel schlechter 
als ein Hammer+Nägel).

* Scrum (wie andere iterative Modelle) dürfte vor allem dort vorteilhaft 
sein, wenn man zwar ein gewisses Ziel (Scrum: "Produktvision") hat, aber 
noch kein genaues Pflichtenheft schreiben kann oder will. Beispiel: 
Larry Page und Sergey Brin hatten am Anfang sicherlich auch nicht auf 
dem Schirm, dass sie die Ergebnisse von Kamera-Autos integrieren 
möchten. Manchmal weiß man am Anfang halt gar nicht, wohin die Reise 
genau geht, bzw. was wirklich sinnvoll wird.


VORTEILE von Scrum sind m.M:

a) Die Einführung ist mit ein Bestandteil des Modells, und der Aufwand 
wird, etwa durch den Scrum-Master, deutlicher.

b) Feedback und Verbesserung ist ebenfalls Bestandteil des Modells 
(Review und Retro). Die Eigenverantwortung des Teams kann in 
regelmäßigen und recht kurzen Zeitabständen gegengespiegelt werden, und 
es gibt einen integrierten Anstoß, über eine Verbesserung des Prozess, 
das Umfeld, der Arbeitsmethoden zu reflektieren. Ergebnis der Reflexion 
kann auch sein, eine Begründung dafür zu erhalten, warum das 
Vorgehensmodell "Scrum" für die aktuelle Gesamtsituation nicht passt, 
und vielleicht ein anderes Modell geeigneter und erfolgsversprechender 
ist.

c) Es gibt regelmäßig Zwischenergebnisse, die nutzbar sein sollen. Es 
muss also nicht ganz bis zum Schluss gewartet werden, bis die ersten 
Erfahrungen oder Erträge anfallen können.

d) Grundsätzliche Probleme können deutlicher werden; ob sie dann gelöst 
werden können, steht auf einem anderen Blatt. Wenn häufig das Sprintziel 
verfehlt wird, kann man meist schneller eine Ursache finden, daran 
arbeiten und die Tauglichkeit von Gegenmaßnahmen bewerten, als wenn erst 
nach einem halben Jahr 'plötzlich' festgestellt wird, dass man komplett 
über den Zeitplan ist.


NACHTEILE von Scrum sind m.E.:

a) Schlechte Integration von Exploration und nachfolgende Umsetzung ein 
einem einzigen Sprint. Da eigentlich alle Arbeiten vor dem Sprint 
geschätzt sein sollte, ist es bei unbekannten Lösungen schlecht möglich, 
erst einen Ansatz zu entwickeln (das kann man meist noch abschätzen), 
und diesen dann im selben Sprint noch umzusetzen (dies geht im Vorfeld 
dann meist nicht).

b) Keine Reaktion auf außergewöhnliche Ereignisse von außerhalb des 
Teams -- beispielsweise ein neu aufgetauchter Bug oder Misfeature, der 
vom Scrumteam gefixed werden soll, etc. Entweder wartet man damit bis 
zum nächsten Sprint, oder man braucht weitere Leute außerhalb des 
Scrum-Teams, oder man muss den Sprint ändern. Andererseites können so 
auch disruptive Ereignisse bzw. Vorgänge deutlicher werden.

von Gastino G. (gastino)


Lesenswert?

Achim H. schrieb:

> NACHTEILE von Scrum sind m.E.:

> b) Keine Reaktion auf außergewöhnliche Ereignisse von außerhalb des
> Teams -- beispielsweise ein neu aufgetauchter Bug oder Misfeature, der
> vom Scrumteam gefixed werden soll, etc. Entweder wartet man damit bis
> zum nächsten Sprint, oder man braucht weitere Leute außerhalb des
> Scrum-Teams, oder man muss den Sprint ändern. Andererseites können so
> auch disruptive Ereignisse bzw. Vorgänge deutlicher werden.

Oder übersetzt: SCRUM nennt sich zwar "agil", ist aber eigentlich extrem 
unflexibel. Es ist eine Vorgehensweise, wo das Team um sich selber 
kreist und Pläne über Monate verfolgt werden können, losgelöst von der 
Realität.
Dafür erzählt dann dauernd jeder jedem (wie im Kindergarten), was er 
gerade macht.

von Sheeva P. (sheevaplug)


Lesenswert?

Gastino G. schrieb:
> Oder übersetzt: SCRUM nennt sich zwar "agil", ist aber eigentlich extrem
> unflexibel. Es ist eine Vorgehensweise, wo das Team um sich selber
> kreist und Pläne über Monate verfolgt werden können, losgelöst von der
> Realität.
> Dafür erzählt dann dauernd jeder jedem (wie im Kindergarten), was er
> gerade macht.

Kannst Du nicht wenigstens ein bisschen kreativer trollen?

von Michael B. (laberkopp)


Lesenswert?

Sheeva P. schrieb:
> Kannst Du nicht wenigstens ein bisschen kreativer trollen?

Kannst du ein bisschen leiser erzählen dass du keine Ahnung hast ?

von Sheeva P. (sheevaplug)


Lesenswert?

Michael B. schrieb:
> Sheeva P. schrieb:
>> Kannst Du nicht wenigstens ein bisschen kreativer trollen?
>
> Kannst du ein bisschen leiser erzählen dass du keine Ahnung hast ?

Immer dreimal mehr wie Du.

von Rolf (audiorolf)


Lesenswert?

Gastino G. schrieb:
> Die Prozesse sind eigentlich alle mehr oder weniger Schrott, da muss man
> sich nichts vormachen. Bisher wurde es immer nur formalistischer und
> bürokratischer.

Solche Sachen dienen nur einem Zweck: immer schlechtere Leute mit 
weniger Denkvermögen zum Arbeiten zu bringen.

Die Idee, per Scrum oder womit auch immer, mit vielen Personen eine 
gemeinsame Denkerzelle zu bilden, scheitert einfach an der schieren 
Größe. Mehr als ein paar Männeken kannst du nicht zusammen lassen, weil 
der Aufwand zur Querkommunikation und Informationsaustausch ins 
Unermessliche steigt.

Man kann das leicht vergleichen mit den Bemühungen, Busse in einen FPGA 
zu bringen: Es muss mit jedem Teilnehmer ein Vorwärtssystem aufgebaut 
werden weil es keine Busse gibt. Wenn jeder mit jedem telefoniert 
beträgt der Aufwand 2 k zur Potenz.

Mit 3 Leuten hast du 3 Destinationen und bei 2 Direktionen = 6 
Verbindungen
Sagen wir 3 x 8h arbeiten und 6h Austausch -> 12/15 -> Effizienz 80%

Mit 5 Leuten hast du 5 Destinationen und 15 Verbndungen
Sind 5 x 8h arbeiten und 15h Austausch -> Effizienz 73%

Mit 7 Leuten -> 56 + 28 -> 67%

Das war es schon, mehr ist gar nicht mehr tragbar, wenn du nicht von 
anderen ausgekontert werden willst, die effizienter arbeiten.

von Achim H. (anymouse)


Lesenswert?

Gastino G. schrieb:
> SCRUM nennt sich zwar "agil", ist aber eigentlich extrem
> unflexibel.

Deswegen lieber Wasserfall?

Gastino G. schrieb:
> Es ist eine Vorgehensweise, wo das Team um sich selber
> kreist und Pläne über Monate verfolgt werden können, losgelöst von der
> Realität.

Hm, das mit den "Monaten" bringe ich bei einer Sprint-Dauer von 2-3 
Wochen nicht überein. Spätestens bei der Review und nächsten Planung 
sollte der Kontakt mit der Realität wieder hergestellt sein.

Gut, wenn es immer nur im Mini-Projektchen in der Größenordnung von 
wenigen Personentagen geht, ist Scrum (und die meisten anderen 
Vorgehensmodelle) sicherlich überdimensioniert.

Nebenbei: Wenn es zu kleinteilig und von oben vorgegeben wird, ist 
irgendwann der Projektleiter der "Single Point of Failure".

von Michael B. (laberkopp)


Lesenswert?

Achim H. schrieb:
> Gastino G. schrieb:
>> SCRUM nennt sich zwar "agil", ist aber eigentlich extrem
>> unflexibel.
>
> Deswegen lieber Wasserfall?

Eher: deswegen statt Religion lieber Vernunft walten lassen

von Rbx (rcx)


Lesenswert?

Ich hatte mir mal was zu preußischen Tugenden notiert:

Einfach
Nüchtern
Zweckorientiert.

Das Problem mit nix Verschwenden: Wenn mal aus dem Vollen schöpfen 
möchte, hat man immer irgendwie doch oft damit zu tun.

Da ist ja zum Arbeiten echt noch das klassische Kreuz besser, also das 
in der Vertikalen und der Senkrechten.

Aus der VWL weiß man auch, das es Zeiten gibt, wo der Staat investieren 
sollte.

Das erklärt aber nicht, wie die Gemeinden jemals, ihre in guten Zeiten 
angehäuften Schulden abbauen könnten.

Letztendlich gibt es immer auch inhaltliche Vorgaben mit dem, womit man 
Geld verdienen möchte.
Das Glück, automatisch klüger/erfahrener zu werden, ist auch nicht immer 
gegeben.
(sowas kann kein xy-Managementplan vorschreiben)

Früher gab es ein lesenswertes BWL/VWL-Buch:
https://link.springer.com/book/10.1007/978-3-662-41529-0

von Robert K. (Firma: Projektleiter Medizinsoftware) (robident)


Lesenswert?

Frank E. schrieb:
> Es gab niemanden, der auch nur ansatzweise beim Code zu diesem Modul
> durchblickte.

Das hat mit Scrum nichts zu tun und kann durch keine 
Projektmanagementmethodik verhindert werden. Software lebt von 
Transparenz und Dokumentation! Wenn die nicht aufgezeigt und angefertig 
wird, sondern alle oder einer an seinem Zeug herumkaspert und schnell 
programmiert, dann ist das eine Weile effektiv, irgendwann explodiert 
das System.

Sheeva P. schrieb:
> Irgendwie vermisse ich einen Zusammenhang zwischen Deinen Aussagen und
> denen meines Vorposters. Letzten Endes geht es bei agilen Methoden um
> Kommunikation, nicht um Prozesse.

Nun vermisse ich den Bezug zu dem was ich geschrieben habe. :-)

Ich kommentierte die Vermutung, dass die Aussage "Wenn Individuen sich 
nichtmal an Scrum gewöhnen können, ist das Projekt schon zum Scheitern 
verurteilt" nicht zwangsläufig "die klügste Aussage im ganzen Thread" 
sein muss, weil :

Scrum als von oben herbab aufoktuiertes System nicht überall sinnvoll 
ist, wo es angewendet ist und erfahrene Entwickler und Projektleiter in 
der Lage sind, das zu erkennen und berechtigterweise hinterfragen.

Wenn also Personen nicht ins Scrum einzugewöhnen sind, kann das auch an 
Scrum und der Art der Umsetzung liegen und muss nicht Fehler der 
Personen sein. Ich sehe auch nicht, wie jemand nicht nach Scrum arbeiten 
können soll: Das Einhalten von Meetings und die Durchführung von 
Besprechungen ist kein Hexenwerk.

Wenn es an etwas krankt, dann ist es das transparente Arbeiten. Wenn das 
nicht da ist, kommt es durch Scrum auch nicht zum Fenster reingeflogen.

Wenn man aber Scrum einführt, ohne die Menschen dahin zu bringen, dass 
auch leben zu können, geht der Schuss nach hinten los! Das zeigen alle 
Beispiel und widerspiegelt sich auch in den Erfahrungen und Aussagen 
hier.

Die Entwickler, die in solche Prozesse eingebunden sind, sind ja nicht 
blöde! Die haben alle ein Studium und könnten Denken und sie merken, 
wann etwas faul ist. Sie merken innerhalb von Scrum, wenn etwas an ihrer 
Software schief läuft und korrigieren es (Scrum unterstellt ja, dass sie 
dazu in der Lage sind und ermächtigt sie zum handeln und diskutieren) - 
sie merken aber eben auch, wenn an Scrum selber was faul ist.

Und wenn sie schlau sind, passen sie Scrum an ihre Abteilung an!





>
> Nicht zwangsläufig! Es ist absolut legitim, Prozesse infrage zustellen,

von Sheeva P. (sheevaplug)


Lesenswert?

Robert K. schrieb:
> Sheeva P. schrieb:
>> Irgendwie vermisse ich einen Zusammenhang zwischen Deinen Aussagen und
>> denen meines Vorposters. Letzten Endes geht es bei agilen Methoden um
>> Kommunikation, nicht um Prozesse.
>
> Nun vermisse ich den Bezug zu dem was ich geschrieben habe. :-)

Dabei sagst Du es selbst:

Robert K. schrieb:
> Ich sehe auch nicht, wie jemand nicht nach Scrum arbeiten
> können soll: Das Einhalten von Meetings und die Durchführung von
> Besprechungen ist kein Hexenwerk.

Genau das ist mein Punkt, allerdings siehst Du ja selbst, wie manche 
Menschen in diesem Thread genau darüber wettern.

Nun muß man natürlich auch sagen, daß Meeting nicht Meeting und 
Besprechung nicht Besprechung ist. Denn, mal unter uns Pastorentöchtern: 
wir kennen sie doch alle, die Besprechungen, in denen bereits alles 
gesagt wurde, aber noch nicht von jedem. Die Meetings, deren wichtigstes 
Ergebnis die Vernichtung der Meetingkekse war und nach denen sich jeder 
fragt: warum?

In so einem Umfeld machen agile Methoden, egal welche, sicher keinen 
Spaß. Im Gegenteil halten sie einen von der Arbeit ab, die ja auch noch 
irgendwann und irgendwie erledigt werden will. Wenn so etwas in Scrum 
Meetings passiert, ist es natürlich fraglich, ob das dann noch Scrum 
ist. Manchmal erinnert mich das an den Term "Objektorientierung" aus 
einer Zeit, in der viele plötzlich ihre "struct XY" durch "class XY { 
public:" ersetzt und dann behauptet haben, sie würden objektorientiert 
entwickeln. :-)

Andererseits bin ich aber seit vielen Jahren in der komfortablen 
Situation, daß es weder bei meinem ehemaligen, noch bei meinem aktuellen 
Arbeitgeber Meetings und Besprechungen wie die oben erwähnten gibt. 
Stattdessen sind wir mit den Dailys meistens in drei bis fünf Minuten 
durch, obwohl wir für ein Scrum-Team mit acht bis zwölf Leuten schon an 
der Obergrenze sind. Trotzdem passiert es immer wieder, daß wir in 
dieser kurzen Zeit feststellen, wo wir unsere Kollegen entlasten können.

Ein Beispiel, das mir gerade noch in Erinnerung ist, betrifft unsere 
Grafik. Die mußte ungefähr 250 inkonsistent formatierte Logos in ein 
einheitliches Format bringen, also: mit konsistenten Randabständen und 
ohne Rahmen. Für eine ähnliche Aufgabe habe ich vor einigen  ein kleines 
Python-Skript mit OpenCV entwickelt und den Grafikern angeboten, das mal 
auszuprobieren. Nach unserem Daily haben wir uns dann kurz abgesprochen, 
ich habe mein Skript ein bisschen angepaßt, laufen lassen, und die 
Aufgabe war erledigt.

So haben wir unseren Grafikern zwei Tag langweilige, fehleranfällige 
Arbeit erspart, mit höchstens zehn Minuten Absprache und vielleicht 
zwanzig Minuten Rechnerei auf meinem Rechner. Ohne die Absprachen im 
Daily wäre nie jemand auf die Idee gekommen, daß die DevOps so ein 
Skript haben und den Job dadurch leicht automatisieren können. Das ist 
natürlich nur ein kleines Beispiel, das ganz gut zeigt, was mit ein 
wenig Abstimmung untereinander möglich ist, und zwar gerade bei uns auch 
abteilungsübergreifend.

Bei meinem ehemaligen Arbeitgeber war ich (aus dummen Gründen) zuerst 
zwei Jahre lang bei den Beratern und danach bei den Technikern 
aufgehängt. Dort hatten wir regelmäßig das Problem, daß die 
Informationen ausschließlich über die Abteilungsleiter ausgetauscht 
wurden. Ein Ergebnis davon war, daß mehrere Berater zu mir gekommen sind 
und gefragt haben, was denn dieses "Docker" sei und warum die Kunden sie 
ständig darauf ansprechen. Tja, dumm gelaufen: die Berater hatten zwar 
ihren Abteilungsleiter schon auf das Thema angesprochen, der hatte das 
aber nicht für wichtig genug gehalten, das weiterzugeben. Und auch mein 
Chef war, wie ich später erfahren habe, von mehreren Kollegen auf das 
Thema angesprochen worden, hatte das aber als Technikthema abgetan und 
deswegen nicht mit unserem Oberberater darüber geredet... und genau so 
kann Kommunikation fehlschlagen, wenn sie an einzelnen Personen mit 
ihrem jeweils eigenen Horizont (nicht negativ gemeint) hängt.

Wie dem auch sei, um wieder den Bogen zum Kernthema zu bekommen: 
Kommunikation ist IMHO viel zu wichtig, um sie den Zufall, den 
Informationsfluß einzelnen Personen zu überlassen. Informationslücken 
und -verluste sind wie Fehler: je später sie bemerkt werden, desto 
aufwändiger und teurer ist es, sie wieder zu beheben. Meine Erfahrungen 
mit Scrum sind -- sicherlich auch dank der guten Meetingkulturen bei 
meinem Ex- und dem aktuellen Arbeitgeber -- prima, aber das muß 
natürlich nicht überall gelten. Allerdings: wer nicht kommunizieren 
kann, wird in unserer arbeitsteiligen Welt früher oder später große 
Probleme bekommen, und das gilt für Unternehmen ebenso wie für 
Individuen.

Edit: Typo.

: Bearbeitet durch User
von Rudi R. (rudi_r)


Lesenswert?

Gastino G. schrieb:
> J. S. schrieb:
>
>> Das ist aber jetzt ein von Scrum losgelöstes Thema, wenngleich ein
>> interessantes: Grundsätzlich soll der Papierkram ja sicherstellen DASS
>> nach den Normen entwickelt und getestet wurde und die Prüfungen gelaufen
>> sind. Ohne Papier wird es daher nicht notwendigerweise unsicherer, aber
>> die Vorgehensweise ist belegbar und irgendwo auch tatsächlich belegt.
>> Damit ist die Sicherheit formell zumindest bestätigt und durchaus höher.
>
> Naja, es wurde ja angeführt, dass dieser ganze formalistische Kram wie
> Scrum solche sicherheitskritischen Systeme erst möglich macht. Meine
> Erfahrung dazu ist, dass das eine hochgefährliche Illusion ist.
> Sicherlich helfen Formalismen bei der Entwicklung von solchen Systemen,
> aber so was wie Scrum ganz sicher nicht.

Sehe ich auch so. Scrum fände ich sogar höchst fahrlässig als 
Entwicklungsmodell. Und speziell die kritischen Bereiche einer Software 
sollten verifiziert und nicht nur getestet werden. Es laufen viele 
Entwickler da draußen herum, die nicht mal wissen, dass Tests nicht die 
Abwesenheit von Fehlern belegen können.

Ich bin manchmal oft erschrocken, wie naiv manche Leute an die Sache 
gehen.

Frank E. schrieb:
> Nun, wir werden alle älter und als der erste Programmierer der
> (modularen Software), der für genau eines der Super-Module zuständig
> war, sich auf seinen Altersruhesitz in die Karibik verabschiedete,
> begann das Drama:
>
> Es gab niemanden, der auch nur ansatzweise beim Code zu diesem Modul
> durchblickte. Als die Kunden nach der ersten Begeisterung dann nach und
> nach doch noch die eine oder andere Ergänzung bzw. Änderung wünschten,
> erkannte man das Problem. Man konnte sie zwar nach Außen hin noch eine
> Weile hinhalten ("Nächste Release ...!"), aber irgendwann wurde es
> ernst.


Scrum hätte das Problem nicht abgewendet. Das Problem war fehlende 
Dokumentation. Wenn ein Modul aus einem sehr fähigen Entwickler und aus 
einem Guss entwickelt worden ist, ist die Dokumentation auch nicht so 
schwer. Gute Architekturen sind in der Regel ästhetische Architekturen. 
Algorithmen muss man beispielsweise in LaTeX dokumentieren. Bei Scrum 
wurde ich noch angehalten, etwas zu dokumentieren. Die Sprinthetzerei 
stand dem entgegen. Und was ich erlebten durfte im letzten Projekt: Der 
eine macht es so, der andere ganz anders. Es wurde niedrigen Niveau sehr 
unterschiedlich programmiert und es passt nicht zusammen, weil es 
niemanden gab, der Rolle hatte, die Richtung vorzugeben.

Ich finde es beispielsweise immer putzig, wenn die Leute was mit 
Prozenten machen und dem Kunden abieten, etwas einzustellen. Es wird 
immer ein Integer. Immer! Und unter der Haube murksen die sich einen ab, 
und teilen es durch 100. Anstatt die Einstellmöglichkeit korrekt 
anzubieten: Fließkommazahl im Intervall [0;1]. Fertig ist die Laube. Und 
wenn irgendwer meint, die Leute könnten damit nicht umgehen, dem seien 
amerikanische Sportstatistiken ans Herz zu legen. Da sieht man für 
gewöhnlich keine Prozentzeichen, das ja ohnehin nur der Faktor 1/100 
ist.

Das sind so Kleinigkeiten, die aber potentielle Fehlerquellen bedeuten. 
Der eine macht es so, der andere wieder anders.

Michael B. schrieb:
> Frank E. schrieb:
>> Wie seht ihr das?
>
> Es kann halt nicht Jeder Alles.
>
> Wenn man Überdurchschnittliches will, muss man Spezialisten haben, deren
> Fähigkeiten und Verstand zumindest in ihrem Spezialbereich über das
> hinaus geht was die anderen können. Helden. Alle herausragenden Produkte
> stammen von Helfen.

So ist es. Linus Torvalds hat sich auch nicht 1990 hingesetzt und 
Scrum-mäßig losgelegt. Ruby und Python sind auch Ein-Mann-Projekte von 
sehr guten Entwicklern gewesen.

Michael B. schrieb:
> Achim H. schrieb:
>> Gastino G. schrieb:
>>> SCRUM nennt sich zwar "agil", ist aber eigentlich extrem
>>> unflexibel.
>>
>> Deswegen lieber Wasserfall?
>
> Eher: deswegen statt Religion lieber Vernunft walten lassen

So ist es. Gesunder Menschenverstand. Schrieb ich öfter hier.

Sheeva P. schrieb:
> Nun muß man natürlich auch sagen, daß Meeting nicht Meeting und
> Besprechung nicht Besprechung ist. Denn, mal unter uns Pastorentöchtern:
> wir kennen sie doch alle, die Besprechungen, in denen bereits alles
> gesagt wurde, aber noch nicht von jedem. Die Meetings, deren wichtigstes
> Ergebnis die Vernichtung der Meetingkekse war und nach denen sich jeder
> fragt: warum?

Ich empfinde Besprechungen häufig als Überrumpelung. Ich muss plötzlich 
mein Zustimmung oder Ablehnung zu etwas preisgeben, über das ich nicht 
genug Zeit hatte nachzudenken. Für alle gibt es Unbekannte, sowohl 
bekannte als auch unbekannte Unbekannte. Es wäre daher wichtig, 
frühzeitig die Themen rauszugeben, was besprochen werden muss. Dann 
müssen die relevanten sich mal alleine hinsetzen, etwas für sich 
erarbeiten, mit Anforderungen, Nebenbedingungen, Optimierungszielen usw. 
beschäftigen, um die Sache so gut wie möglich zu lösen. Es muss aber was 
auf Papier sein. Andere müssen die Chance haben, sich da einzulesen, 
bevor es in die Besprechung geht. Es würden viele kostspielige 
Falschentwicklungen gespart werden.

Sheeva P. schrieb:
> Ein Beispiel, das mir gerade noch in Erinnerung ist, betrifft unsere
> Grafik. Die mußte ungefähr 250 inkonsistent formatierte Logos in ein
> einheitliches Format bringen, also: mit konsistenten Randabständen und
> ohne Rahmen. Für eine ähnliche Aufgabe habe ich vor einigen  ein kleines
> Python-Skript mit OpenCV entwickelt und den Grafikern angeboten, das mal
> auszuprobieren. Nach unserem Daily haben wir uns dann kurz abgesprochen,
> ich habe mein Skript ein bisschen angepaßt, laufen lassen, und die
> Aufgabe war erledigt.
>
> So haben wir unseren Grafikern zwei Tag langweilige, fehleranfällige
> Arbeit erspart, mit höchstens zehn Minuten Absprache und vielleicht
> zwanzig Minuten Rechnerei auf meinem Rechner. Ohne die Absprachen im
> Daily wäre nie jemand auf die Idee gekommen, daß die DevOps so ein
> Skript haben und den Job dadurch leicht automatisieren können. Das ist
> natürlich nur ein kleines Beispiel, das ganz gut zeigt, was mit ein
> wenig Abstimmung untereinander möglich ist, und zwar gerade bei uns auch
> abteilungsübergreifend.

Schöne Sache. Gutes Beispiel für kooperatives Arbeiten. Gegen ein Daily 
ist nichts einzuwenden, ist aber nicht kein Alleinstellungsmerkmal von 
Scrum. Problem aber hierbei ist wieder: Wir denn daraus gelernt und von 
Anfang an eine automatisierte Lösung angestrebt? Ich bin ein ein 
Refaktorierer und Code-Vereinfacher. Die Kollegen sehen das ja. Es wird 
verständlicher und besser wartbar, aber die Kollegen schreiben immer 
noch mühsam ihr Zeug zusammen und produzieren Unmengen an unnützen Code.

Sheeva P. schrieb:
> Bei meinem ehemaligen Arbeitgeber war ich (aus dummen Gründen) zuerst
> zwei Jahre lang bei den Beratern und danach bei den Technikern
> aufgehängt. Dort hatten wir regelmäßig das Problem, daß die
> Informationen ausschließlich über die Abteilungsleiter ausgetauscht
> wurden. Ein Ergebnis davon war, daß mehrere Berater zu mir gekommen sind
> und gefragt haben, was denn dieses "Docker" sei und warum die Kunden sie
> ständig darauf ansprechen. Tja, dumm gelaufen: die Berater hatten zwar
> ihren Abteilungsleiter schon auf das Thema angesprochen, der hatte das
> aber nicht für wichtig genug gehalten, das weiterzugeben. Und auch mein
> Chef war, wie ich später erfahren habe, von mehreren Kollegen auf das
> Thema angesprochen worden, hatte das aber als Technikthema abgetan und
> deswegen nicht mit unserem Oberberater darüber geredet... und genau so
> kann Kommunikation fehlschlagen, wenn sie an einzelnen Personen mit
> ihrem jeweils eigenen Horizont (nicht negativ gemeint) hängt.

Was fehlgeleitete Kommunikation angeht, da könnte ich 'ne Geschichte 
erzählen. Eine Produktionsanlage wurde mehrfach verkauft, mit ein paar 
Änderungen von Standort zu Standort, die aber nicht so ins Gewicht 
fielen. Wenigstens sollte die letzte Anlage eine exakte Kopie einer 
vorherigen Anlage sein. Der Consultant lief mit Kundenvertreter durch 
die Anlage (die kopiert werden sollte) und nahm das Wort "Spiegelung" in 
den Mund. Er wollte eine kleine Änderung, also ein delta wie bei den 
vorherigen Anlagen auch schon. Der Consultant transportierte aber das 
böse Wort Spiegelung und das Unglück nahm seinen Lauf. Alle 
Gerätenummern wurden gespiegelt, Bezeichner wurden gespiegel. Es gab 
Spiegelungen an Geraden, aber auch an Punktrotationen. Ein neue 
CAD-Zeichnung war notwendig. Das delta wäre in 30 min abgefrühstückt 
worden. Wegen der Spiegelung der gesamte Anlage saß ich mehrere Tage. 
Wie kam es zu dem Unglück: Es wurde einfach reingedrückt, ohne jetzt den 
Profi, also mich, zu konsultieren. Hätte man mich früh eingebunden, 
hätte ich dem CAD-Zeichner und einer weiteren Abteilung viel Arbeit 
erspart und vor allem mir selbst. Es wurde auch noch still und heimlich 
geändert... Wir waren am Ende der Verwertungskette und wenige Tage vor 
Go-Live sah ich durch Zufall, dass alles gespiegelt war. Offiziell war 
ja der Tenor bis dahin immer noch: Es ist eine exakte Kopie von... 
Go-Live war durch meine Arbeit Zusatzarbeit nicht gefährdet, aber es 
dankte mir auch niemand. In dem Fall konnte ich meine Fähigkeiten gut 
ausspielen. Ein anderer hätte das nicht so schnell geschafft wie ich.

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Ich empfinde Besprechungen häufig als Überrumpelung. Ich muss plötzlich
> mein Zustimmung oder Ablehnung zu etwas preisgeben, über das ich nicht
> genug Zeit hatte nachzudenken.

So etwas passiert mir nicht (mehr), weil ich mich auf jede Besprechung 
heute akribisch vorbereite.

> Schöne Sache. Gutes Beispiel für kooperatives Arbeiten. Gegen ein Daily
> ist nichts einzuwenden, ist aber nicht kein Alleinstellungsmerkmal von
> Scrum.

Nein, Scrum ist nur eine Formalisierung. Aber ohne so eine 
Formalisierung ist der Drang der Beteiligten, jetzt gerade nur mal ihre 
Arbeit machen zu wollen, mitunter größer als es dem Projekt (oder 
Unternehmen) gut tut.

> Problem aber hierbei ist wieder: Wir denn daraus gelernt und von
> Anfang an eine automatisierte Lösung angestrebt?

Wenn so eine Aufgabe alle drölf Millionen Jahre ansteht, lohnt sich eine 
Automatisierung gemeinhin eher nicht.

> Ich bin ein ein
> Refaktorierer und Code-Vereinfacher. Die Kollegen sehen das ja. Es wird
> verständlicher und besser wartbar, aber die Kollegen schreiben immer
> noch mühsam ihr Zeug zusammen und produzieren Unmengen an unnützen Code.

Eigentlich müßte jemand Deinen Kollegen beibringen, wie sie Code 
schreiben können, der nicht mehr refaktoriert werden muß.

> Wie kam es zu dem Unglück: Es wurde einfach reingedrückt, ohne jetzt den
> Profi, also mich, zu konsultieren. Hätte man mich früh eingebunden,
> hätte ich dem CAD-Zeichner und einer weiteren Abteilung viel Arbeit
> erspart und vor allem mir selbst.

Ein Paradebeispiel für schlechte Kommunikation, finde ich.

von Rudi R. (rudi_r)


Lesenswert?

Sheeva P. schrieb:
>> Problem aber hierbei ist wieder: Wir denn daraus gelernt und von
>> Anfang an eine automatisierte Lösung angestrebt?
>
> Wenn so eine Aufgabe alle drölf Millionen Jahre ansteht, lohnt sich eine
> Automatisierung gemeinhin eher nicht.

Auch das ist richtig, aber man kann ja abschätzen, wann sich so eine 
Automatisierung lohnt und wann nicht.

Sheeva P. schrieb:
> Eigentlich müßte jemand Deinen Kollegen beibringen, wie sie Code
> schreiben können, der nicht mehr refaktoriert werden muß.

Nicht jemand müsste es ihnen beibringen, sie müssten es sich selbst 
beibringen. Dazu gehört stetige Weiterbildung. Ich habe Informatik 
studiert und keine Softwareentwicklung als solche. Softwareentwicklung 
war nur ein Nebenaspekt. Viele Kenntnisse erarbeitete ich mir aber 
parallel zum Studium und danach an.

Wahrscheinlich gibt es keinen anderen Beruf, wo lebenslanges Lernen 
schon immer notwendig war. Und meiner Meinung nach darf man auch 
erwarten, dass die Leute selbst erkennen, welches Wissen wichtig ist, 
dass man es dauerhaft lernt und welches nicht. Eine Bibliothek zum 
Zeichnen von Diagrammen... Da arbeitet man sich, und vergisst es wieder, 
wenn durch stetige Praxis das Wissen darüber nicht weiter gefestigt 
wird. Das kann man und darf man vergessen. Aber wenn es um Architektur, 
Entwurfsmuster und Algorithmen geht, dann darf man das eben nicht 
vergessen, sondern muss durch zusätzliche Lektüre das Wissen darüber 
festigen.

Beispiel: Viele meiner Kollegen verwenden täglich das Strategiemuster, 
weil unser firmeneigenes Framework exzessiv das Muster verwendet. Aber 
sie sind nicht in der Lage, selber eine Lösung zu entwickelt und dabei 
auf das Strategiemuster zu setzen.

Sheeva P. schrieb:
> So etwas passiert mir nicht (mehr), weil ich mich auf jede Besprechung
> heute akribisch vorbereite.

Klappt ja nicht immer. Wenn zu spät der Termin in Outlook erscheint, 
dann hat man keine Chance. So ein Problem ist von Projektleitern 
verursacht. Ich bereite mich auch vor, wenn genug Zeit da ist. Aber das 
Überrumpeln mag ich gar nicht. Ich mag auch Konzeptarbeit und über eine 
Lösung grübeln. Ich stelle auch fest, dass andere das nicht mögen. Die 
wollen aber mitreden. Ich finde, das geht dann auch nicht. Auch schon 
öfter erlebt, dass sich solche Personen dann ohne fundierte Meinung an 
der Person am längeren Hebel orientieren.

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Sheeva P. schrieb:
>> Eigentlich müßte jemand Deinen Kollegen beibringen, wie sie Code
>> schreiben können, der nicht mehr refaktoriert werden muß.
>
> Nicht jemand müsste es ihnen beibringen, sie müssten es sich selbst
> beibringen. Dazu gehört stetige Weiterbildung.

Ja, aber ganz offensichtlich tun sie das ja nicht. Das wirft die Frage 
auf: wie bringen wir sie dazu, das zu tun. Jetzt kannst Du natürlich 
warten, bis sie selbst tätig werden, aber das scheint ja schon bisher 
nicht so richtig funktioniert zu haben. Es ist also Zeit für eine neue 
Strategie.

Denn die Idee kann doch nicht sein, daß erst teuer und aufwändig 
Software entwickelt wird, die dann aber leider noch gar nicht genutzt 
werden kann, sondern vorher erst noch teuer und aufwändig überarbeitet 
werden muß.

Darum würde ich an Deiner Stelle jetzt einige Schulungen vorschlagen. 
Kurz über die üblichen GoF-Entwurfsmuster gehen, UML und so, das Übliche 
halt. Du sagst, Ihr nutzt exzessiv das Strategy-Pattern? Prima, dann 
hast Du Deinen Kandidaten für eine erste Schulung, und wenn die 
erfolgreich ist, können in regelmäßigen Abständen ja noch einige weitere 
folgen.

> Sheeva P. schrieb:
>> So etwas passiert mir nicht (mehr), weil ich mich auf jede Besprechung
>> heute akribisch vorbereite.
>
> Klappt ja nicht immer. Wenn zu spät der Termin in Outlook erscheint,
> dann hat man keine Chance. So ein Problem ist von Projektleitern
> verursacht.

Solche Dinge können agile Methoden oft besser lösen können als 
klassische.

von Rbx (rcx)


Lesenswert?

Rudi R. schrieb:
> Ich finde es beispielsweise immer putzig, wenn die Leute was mit
> Prozenten machen und dem Kunden abieten, etwas einzustellen. Es wird
> immer ein Integer. Immer! Und unter der Haube murksen die sich einen ab,
> und teilen es durch 100. Anstatt die Einstellmöglichkeit korrekt
> anzubieten: Fließkommazahl im Intervall [0;1]. Fertig ist die Laube. Und
> wenn irgendwer meint, die Leute könnten damit nicht umgehen, dem seien
> amerikanische Sportstatistiken ans Herz zu legen. Da sieht man für
> gewöhnlich keine Prozentzeichen, das ja ohnehin nur der Faktor 1/100
> ist.

Es gibt übrigens psychologische Untersuchungen dazu. Die Leute verstehen 
es besser, wenn man sie nach Häufigkeiten fragt bzw. wenn man die 
Verhältnisse besser einschätzen kann. (also x von 100 statt x/100 -> x,y 
Prozent)
Und Prozentzahlen werden häufig missbraucht, um Genauigkeiten 
vorzutäuschen.
Fließkommazahlen in Computern können auch problematisch werden. Aber 
lassen wir das mal, das führt zu weit, nur sollte man das im Hinterkopf 
behalten.

(darüberhinaus ist Fuzzy Logic auch gar nicht so schwer.)
(spannenderweise gibt es sogar ANFIS (Adaptive Neuro Fuzzy Inference 
System) was noch besser sein soll als Fuzzy Logic.)

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> (darüberhinaus ist Fuzzy Logic auch gar nicht so schwer.)

Ob Fuzzy Logik für Menschen verständlicher ist, die schon Probleme mit 
der Prozentrechnung haben? Da habe ich so meine Zweifel...

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Ob Fuzzy Logik für Menschen verständlicher ist, die schon Probleme mit
> der Prozentrechnung haben? Da habe ich so meine Zweifel...

Ich glaube schon, wird halt nicht so oft eingesetzt, wie die 
Prozentrechnung, und Schulkurse zur Fuzzy Logic gibt es üblicherweise 
auch nicht.
Lehrer fragen da auch lieber nach dem Dreisatz.

Es gibt auch Anwendungen, wie das Heron Verfahren zum Wurzelziehen, da 
setzt man besser Fließkommazahlen ein.

Dass sollte aber nicht ablenken von dem Sachverhalt, dass sich für Rudi 
Rs Beobachtungen auch Belege finden lassen.
Darüber hinaus können Perspektivenwechsel (z.B. Sportveranstaltungen als 
Referenz) eine gute Hilfe sein, gerade, bei schwierig erscheinenden 
Zusammenhängen.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Alle
> Gerätenummern wurden gespiegelt, Bezeichner wurden gespiegel. Es gab
> Spiegelungen an Geraden, aber auch an Punktrotationen.

Was bedeutet denn "Spiegelung" in diesem Kontext? Und was "Delta"?

von Rudi R. (rudi_r)


Lesenswert?

Bruno V. schrieb:
> Rudi R. schrieb:
>> Alle
>> Gerätenummern wurden gespiegelt, Bezeichner wurden gespiegel. Es gab
>> Spiegelungen an Geraden, aber auch an Punktrotationen.
>
> Was bedeutet denn "Spiegelung" in diesem Kontext? Und was "Delta"?

Ich kann da nicht zu sehr ins Detail gehen (wegen Geheimhaltung), aber 
stell dir mal ein Layout einer Produktionsanlage vor. Und stellen Sie 
sich vor, dass da eine Bahn, die aus dem Komplex nach Norden rausführt, 
eigentlich blöd ist, und es besser wäre, diese Bahn umzuhenkeln,  sodass 
sie nach Süden abgeht. Das hat der Kunde zusammen mit einen der 
Consultants so festgestellt. Diese Differenz zur Anlage davor wäre sehr 
einfach umgesetzt gewesen. Aber als das Wort Spiegelung in den Mund 
genommen wurde, wurde es ein Selbstäufer. Die zogen eine Gerade 
horizontal durch die Anlage, und spiegelten daran das gesamte Layout. Es 
wurde alles verändert, obwohl man nur 1 % ändern wollte, das sogenannte 
Delta. Und manche Sachen ließen sich nicht an der Gerade spiegeln. Aber 
davon hingen wieder Benamsungen ab. Da kamen auch Punktspiegelungen zum 
Einsatz. Sehr viel Arbeit, sehr viel Risiko. Erinnert ein wenig an Frank 
Mills Pfostentreffer bei einem freien Tor. Manche Leute bei uns 
verstehen es gut, sich, den Kunden und den Entwicklern das Leben unnötig 
schwer zu machen. Hätte man von Anfang an korrekt kommuniziert (mit 
Einbeziehung der richtigen Leute), was die Motivation ist, dass es 
wirklich nur um das 1 % Delta ging und wir uns diese teure Spiegelung 
der Anlage hätten sparen können, hätte das enorm viel Zeit und Geld 
gespart.

Ich kann mir gut vorstellen, dass insbesondere der CAD-Zeichner alle 
Hände voll zu tun hatte. Und so eine Spiegelung kann auch Auswirkung auf 
die Gebäudestatik haben... Ob jemand daran gedacht hat?

von Rudi R. (rudi_r)


Lesenswert?

Rbx schrieb:
> Es gibt übrigens psychologische Untersuchungen dazu. Die Leute verstehen
> es besser, wenn man sie nach Häufigkeiten fragt bzw. wenn man die
> Verhältnisse besser einschätzen kann. (also x von 100 statt x/100 -> x,y
> Prozent)
> Und Prozentzahlen werden häufig missbraucht, um Genauigkeiten
> vorzutäuschen.
> Fließkommazahlen in Computern können auch problematisch werden. Aber
> lassen wir das mal, das führt zu weit, nur sollte man das im Hinterkopf
> behalten.

Prozent ist ja auch ja nichts anders als Hunderstel. Früher gab es noch 
"i. T. v. H." als feste Abkürzung: in Teilen von Hundert.

Fließkommazahlen können tatsächlich problematisch sein; ein Drittel 
lässt sich nicht exakt darstellen. Ein Fünftel auch nicht. Wenn der 
Kunde aber 20 einstellt, eine Integer-Zahl abgespeichert wird, wird ja 
irgendwann bis zur Anwendung der Zahl "20 /100.0" gesteilt, dass man 
damit arbeiten kann. Und an das Drittel kommt man mit einem Integer von 
0 bis 100 auch nicht ran.

Aber es geht ja nicht nur um Kunden. Selbst Parameter, die der Kunde nie 
zu sehen bekommt, werden als Integer hinterlegt und unter der Haube 
durch 100 geteilt. Also selbst wer mathematisch über dem Durchschnitt 
liegt sollte, fängt mit so einer Mickey-Mouse-Programmierung an. Nun 
kann ich mich gut an meinem Mathematikunterricht erinnern und selbst in 
der 8. Klasse haben wir in der Stochastik Wahrscheinlichkeiten im 
Intervall [0;1] angegeben. Prozentrechnung beherrschte man, aber das 
Prozentzeichen war in der Stochastik wieder verpönt.

Micky-Mouse-Programmierung ist eine Begrifflichkeit von mir (analog zur 
Mickey-Mouse-Sch... für infantilen Blödsinn) und ich finde sie treffend, 
weil sich manche Entwickler sich nicht trauen, erwachsen und 
professionell zu werden und dieses Prozentzeichen in die Tonne zu 
treten. Das kann man allenfalls in End-User-Masken anbieten und bitte 
nur in Metiers, wo es üblich ist. In der Stochastik jedenfalls nicht. 
Wahrscheinlichkeiten von 45 %... ist allgemeinsprachlich. Im Metier der 
Stochastik spricht man von 0,45.

Ein anderes Unding ist, dass die Leute Statistik sagen, aber Stochastik 
oder die Wahrscheinlichkeitstheorie meinen. Ist mir nun auch schon 
mehrfach über den Weg gelaufen, dass ich mich wundere: War denn mein 
Mathematikunterricht in den 90ern an einem Provinzgymnasium so 
außergewöhnlich gut?

Ein Vorteil, direkt eine Fließkommazahl zu nehmen: Genauigkeit. Wer nur 
ganze Zahlen von 0 bis 100 anbietet, bietet exakt 101 Möglichkeiten. 
50,5 % lässt sich einstellen. 0,505 schon.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Die zogen eine Gerade
> horizontal durch die Anlage, und spiegelten daran das gesamte Layout.

Das hätte ich ja noch verstanden. Und das passiert auch wohl in der 
Praxis, das ganze Objekte aus versehen gespiegelt konstruiert werden 
(oftmals reicht ein falscher Pfeil oder Satz).

Ich verstehe nur nicht, was das mit Nummern und Bezeichnern zu tun hat

Rudi R. schrieb:
>>> Alle Gerätenummern wurden gespiegelt, Bezeichner wurden gespiegelt.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Ein Vorteil, direkt eine Fließkommazahl zu nehmen: Genauigkeit. Wer nur
> ganze Zahlen von 0 bis 100 anbietet, bietet exakt 101 Möglichkeiten.

Ich verstehe die Diskussion nicht ganz. Bei % habe ich einen in den 
meisten Fällen guten Default für die Auflösung. Und wenn nicht, nehme 
ich 1, 2 oder 3 Nachkommastellen. Bei jedem GUI-Schieberegler mit 
Pfeilen muss ich mich entscheiden, wie viel er weiterspringen soll beim 
drücken des Pfeils und beim Drücken auf die Skale.

Das Verwenden von Ganzzahlen empfinde ich jetzt auch nicht wirklich als 
Nachteil: Auf Integer kann ich z.B. == anwenden. Oder sie im 
Hex-Editor/Memory-Dump untersuchen.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Sheeva P. schrieb:
>> Ob Fuzzy Logik für Menschen verständlicher ist, die schon Probleme mit
>> der Prozentrechnung haben? Da habe ich so meine Zweifel...
>
> Ich glaube schon, wird halt nicht so oft eingesetzt, wie die
> Prozentrechnung, und Schulkurse zur Fuzzy Logic gibt es üblicherweise
> auch nicht.

Wenn jemand schon Schwierigkeiten mit Verhältnissen hat, ist es wohl 
keine Vereinfachung für ihn, mit dem Wahrheitswert noch ein weiteres 
Verhältnis hinzuzufügen, oder siehst Du das anders?

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Wenn jemand schon Schwierigkeiten mit Verhältnissen hat, ist es wohl
> keine Vereinfachung für ihn, mit dem Wahrheitswert noch ein weiteres
> Verhältnis hinzuzufügen, oder siehst Du das anders?

Naja, was soll ich darauf jetzt antworten? Prinzipiell schon, wenn man 
Beispielsweise gewisse Teilungen hinbekommen möchte, kann man ja auch 
300 als Referenzwert einsetzen, oder eben auch z.B. 12er Zahlen,
also z.B. 1,2,3,4,5.6,7,8,9,L,U,10,11...

Kann recht praktisch sein. Und ja, ich habe keine Informatik studiert, 
war aber mal kurz davor, jedenfalls wird da auch zur Problemlösung so 
manches krasse Zahlensystem angewendet.
Es gibt an den Unis oft Gastvorträge, vielleicht solltest du bei 
Gelegenheit da auch mal (öfter) hingehen.

Naja, und bei den Entwicklungsmodellen denkt man sich von außen, warum 
die Mitarbeiter nicht ein eigenes System aufstellen. Oder sich was 
zusammensuchen, was zu ihnen passt.
Wir hatten im Studium auch ein paar äußere Modelle zur Evaluation 
angesehen, z.B. bei der Chemie, oder bei der Wirtschaft. Fand ich sehr 
spannend. Aber eher, als Vorbild zur Orientierung angesehen, und nicht 
als dogmatischer Plan zum Nachmachen.
Wichtiger war halt, sich an den Grundlagen zu orientieren oder zur 
Diskussion - und die äußeren Modelle zur Evaluation halfen auch, die 
Grundlagen zur sicheren Objektivität zu vertiefen.
Z.B. wird bzw. wurde bei der Bundeswehr viel das V-Modell eingesetzt.
Da kann man dann hingehen, und fragen, ob man gewisse Pläne zum Vorbild 
nehmen darf, aber nicht als dogmatischen Plan, sondern eher zur 
Orientierung und Unterstützung der eigenen Pläne.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Sheeva P. schrieb:
>> Wenn jemand schon Schwierigkeiten mit Verhältnissen hat, ist es wohl
>> keine Vereinfachung für ihn, mit dem Wahrheitswert noch ein weiteres
>> Verhältnis hinzuzufügen, oder siehst Du das anders?
>
> Naja, was soll ich darauf jetzt antworten? Prinzipiell schon, wenn man
> Beispielsweise gewisse Teilungen hinbekommen möchte, kann man ja auch
> 300 als Referenzwert einsetzen, oder eben auch z.B. 12er Zahlen,
> also z.B. 1,2,3,4,5.6,7,8,9,L,U,10,11...

Darum geht es aber nicht, fürchte ich.

> Es gibt an den Unis oft Gastvorträge, vielleicht solltest du bei
> Gelegenheit da auch mal (öfter) hingehen.

Die eine oder andere habe ich sogar schon angehört. Aber was die Fuzzy 
Logik angeht, durfte ich als damaliger Mitarbeiter der INFORM Software 
GmbH [1] an der Vorlesungsreihe von Prof. Dr. Hans-Jürgen Zimmermann [2] 
teilnehmen, die er damals noch jährlich für die neuen Mitarbeiter 
gehalten hat. Das war ein großes Glück, denn er kann die Fuzzy Logik so 
wahnsinnig gut erklären, daß sogar ich sie verstanden habe -- und 
obendrein ist er ein prima Typ. :-)


[1] https://www.inform-software.com/de/ueber-uns/Unsere-Geschichte
[2] 
https://de.wikipedia.org/wiki/Hans-J%C3%BCrgen_Zimmermann_(Wirtschaftswissenschaftler)

von Rudi R. (rudi_r)


Lesenswert?

Bruno V. schrieb:

> Ich verstehe nur nicht, was das mit Nummern und Bezeichnern zu tun hat
>
> Rudi R. schrieb:
>>>> Alle Gerätenummern wurden gespiegelt, Bezeichner wurden gespiegelt.

Problem war, das Teile des Layouts an einer geraden gespiegelt wurden 
und andere gar nicht, weil die Bezeichner kreisrund angeordnet waren und 
das musste für den Kunden so bleiben. Es ist schwer zu erklären, ohne 
tief in die Materie einzusteigen und ohne Firmeninterna auszuplaudern. 
Schlussendlich wollte ich gesagt haben: Falsche Kommunikation hat hier 
enorme viel Extraarbeit verursacht.

Um aber auf das Thema zurückzukommen: Manche scheinen in den 
Vorgehensmodellen die  ein Alleilmittel zu sehen. Jeder kann alles, weil 
man die Arbeit möglichst in kleine Happen aufsplittet, also jetzt 
speziell bei Scrum. Der denkende und handelnde Mensch bleibt auf der 
Strecke. Wo bleibt der? Ist es der, vor dem man Angst hat?

Ich sehe, was unsere Azubis eingetrichtet wird. Scrum ist Teil des 
Lehrplanes unserer Fachinformatik-Azubis. Aussagenlogik hingegen nicht. 
Da habe ich ihnen was geboten. Ich habe den Azubis auch schon reguläre 
Ausdrücke innerhalb eines mehrstündigen Workshops beigebracht, in dem 
ist auch selbst programmieren durften. Ich hoffe, da bleibt etwas hängen 
und dass sie etwas haben, das sie die nächsten Jahrzehnte produktiv 
einsetzen können, denn ich habe Kollegen, die nie einen systematischen 
Zugang dazu hatten. Das spürt man.

Ein Professor von mir sagte damals in einer Vorlesung, ingenieurmäßiges 
Vorgehen sei: "All should be done systematically." - Finde ich gut. Ich 
programmiere auch nicht drauf los, sondern mache Konzepte auf Papier, 
versuche auch, alle Anwendungsfälle direkt zu erfassen, weil ich der 
Meinung bin, das Abstraktion und Generalisierung, sowie die Erfassung 
von Spezialfällen, Ordnung und damit Produktivität reinbringt. Dazu sagt 
Scrum gar nichts. Scrum ist ein BWLer-Konzept, es ist wie Brainstorming, 
wo der Geschwätzigste gewinnt. Auch so ein Modeding. Beim Brainstorming 
verliere ich immer, weil es Extrovertiertheit begünstigt.

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Schlussendlich wollte ich gesagt haben: Falsche Kommunikation hat hier
> enorme viel Extraarbeit verursacht.

Also sind wir uns einig, daß falsche Kommunikation Probleme verursacht. 
Ist das aber nicht auch bei fehlender Kommunikation so?

> Um aber auf das Thema zurückzukommen: Manche scheinen in den
> Vorgehensmodellen die  ein Alleilmittel zu sehen.

Lustigerweise tun das vor allem ihre Gegner, damit sie dem 
Vorgehensmodell danach vorwerfen können, kein Allheilmittel zu sein. 
Niemand, der halbwegs seriös mit dem Thema Agilität umgeht, hält es für 
ein Allheilmittel. Sowas wäre ja auch der feuchte Traum schlechthin: ein 
Vorgehensmodell, das alle sozialen Probleme, unterschiedliche Wissens- 
und Erfahrungsstände und die verschiedenen Charaktere und Temperamente 
in einem Team löst... kennst Du eins? Dann bitte, sprich langsam und 
deutlich! :-)

> Jeder kann alles, weil
> man die Arbeit möglichst in kleine Happen aufsplittet, also jetzt
> speziell bei Scrum.

Es geht weder darum, daß jeder alles kann, noch darum, daß die Arbeit in 
möglichst kleine Happen aufgeteilt wird. Wobei die Implementierung einer 
modularen Software letztlich eine Abfolge von Schritten ist, oder?

> Scrum ist ein BWLer-Konzept, es ist wie Brainstorming,
> wo der Geschwätzigste gewinnt.

Das ist weder die Idee, noch der Sinn und Zweck des Ganzen. Scrum hat 
primär mit Kommunikation und kontinuierlicher Verbesserung zu tun, nicht 
mehr, aber eben auch nicht weniger. Ja, das zieht die Betriebswirte an, 
auf einmal gibt es Zahlen, und, juchhuuu, mit denen kann man rechnen. Wo 
ich Betriebswirte in Scrum-Mettings sehe, weiß ich: nix wie weg hier.

Übrigens: der Geschwätzigste gewinnt nur dann, wenn die anderen nicht 
richtig vorbereitet sind. Das hat aber nichts mit dem Vorgehensmodell zu 
tun, sondern ist immer und in jedem Modell so. Das Schöne an 
beispielsweise Scrum ist aber, daß ja morgen noch einmal ein Daily 
stattfindet und mich nichts daran hindert, morgen vorbereitet zu sein 
und mit einem vorsichtigen "wir hatten ja gestern über XY gesprochen und 
Z beschlossen, aber mittlerweile bin ich überzeugt, daß ich eine bessere 
Lösung dafür kenne" beginnen. Durch das ohnehin stattfindende Daily ist 
die Eintrittshürde dafür niedriger als bei einem klassischen Modell, wo 
man für solche Gespräche erstmal ein neues Meeting terminieren muß -- 
mit Kollegen, die dann genervt sind, wegen bereits Beschlossenem noch 
einmal die trockenen Meetingkekse futtern zu müssen. :-)

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Es geht weder darum, daß jeder alles kann, noch darum, daß die Arbeit in
> möglichst kleine Happen aufgeteilt wird.

Ich kann das, was Rudi weiter oben schreibt, nur unterschreiben. Die 
Aufteilung einer Arbeit in kleine Happen ist die eigentliche Leistung 
bei Software-Entwicklung. Das wird aber bei dem Scrum, was ich aus der 
Praxis und Theorie kennengelernt habe, überhaupt nicht thematisiert. Es 
herrscht ein Drausloswurschteln / Fahren auf Sicht vor - gerne mit dem 
mahnenden Hinweis darauf, daß systematisches Durchplanen doch nur zum 
dem bösen bösen Wasserfall hinführen würde. Zu dem Drauflosarbeiten 
kommen regelmäßige Abstimm- und Abnickrunden. Und: Die starre 
Funktionstrennung ist ein Grundmerkmal von Bürokratie und fördert diese.

>Wobei die Implementierung einer
>modularen Software letztlich eine Abfolge von Schritten ist, oder?

Diese rhetorische Frage zeigt, daß es am Grundverständnis hapert!

Auch die Konstruktion einer mechanischen Uhr ist letztlich eine Abfolge 
von Schritten, ja, selbst ein Turing-preis-verdächtiger mathematischer 
Beweis! Das heißt nicht, daß man etwa den Uhrenbau mit einem 
Scrum-Master in ein paar Sprints mit dressierten Affen als 
Teammitglieder betreiben kann.

> Ja, das zieht die Betriebswirte an,
> auf einmal gibt es Zahlen, und, juchhuuu, mit denen kann man rechnen. Wo
> ich Betriebswirte in Scrum-Mettings sehe, weiß ich: nix wie weg hier.

Informatiker sind Einzelgänger, BWLer Herdentiere. Wenn man dem 
Informatiker ein schwieriges Thema gibt, sagt er "Ich will die nächsten 
Tage nicht gestört werden, muß eine Lösung ausbrüten". Der BWLer, 
konfrontiert mit einer schwierigen Aufgabe, ist kurz ganz verzweifelt, 
dann kommt ihm die rettende Idee "Wir machen ein Meeting! Ich lade 
einfach alle ein. Auch die ganzen Techies, damit die sagen, was wir tun 
können und sollen"

> Übrigens: der Geschwätzigste gewinnt nur dann, wenn die anderen nicht
> richtig vorbereitet sind. Das hat aber nichts mit dem Vorgehensmodell zu
> tun, sondern ist immer und in jedem Modell so.

Auch das greift zu kurz. Scrum erzwingt solche großen Laberrunden, die 
eigentlich zur schnellen Abstimmung gedacht sind. Je schwieriger ein 
Problem, desto weniger kann es in Dailys gelöst werden, es gilt das 
"Parkinsonsche Gesetz der Trivialität" (siehe weiter oben im Follow-up).

> Das Schöne an
> beispielsweise Scrum ist aber, daß ja morgen noch einmal ein Daily
> stattfindet und mich nichts daran hindert, morgen vorbereitet zu sein
> und mit einem vorsichtigen "wir hatten ja gestern über XY gesprochen und
> Z beschlossen, aber mittlerweile bin ich überzeugt, daß ich eine bessere
> Lösung dafür kenne" beginnen.

Wenn der Scrum-Master BWLer ist, wird er spätestens nach 30 Sekunden 
abpfeifen, wenn Du beginnst, deine bessere Lösung auszuführen. Es sei 
denn, die Lösung kann in 30 Sekunden präsentiert werden. Weil die 
Problemstellung und/oder die Lösung trivial ist.

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Ich bin störrischerweise und altersbedingt immer noch der Meinung, daß 
klassische Designmethodologie auch in unserer Zeit noch ihre bewiesene 
Daseignsberechtigung hat.

Die Scrum Philosophie hat für mich einen etwas Trumpian- oder Elonian 
Beigeschmack. Vielleicht würden weniger seiner Raketen explodieren, wenn 
man da etwas weniger "modern" vorgehen würden und man Erfahrungen 
berücksichtigen würde, anstatt einfach darauf los zu werkeln.

Wer nicht bedachtsam vorgeht macht leichter Fehler. Ich kann mir 
vorstellen, daß man sich in den Entwicklungsabteilungen wichtiger 
Produkte wie Flugzeugentwicklung u.ä. immer noch die bewährten Methoden 
hält. Methodisches, durchdachtes Arbeiten macht sich immer bezahlt.

Ausführliche und fehlerfreie Pflichtenhefte als Skelett der Anwendung 
sind Voraussetzung. Design ist 90% Planung und 10% Coden. Ausarbeiten 
von Testmethoden. Top Down wenn es um Systemeinzelheiten geht. Bottom Up 
bei den HW Treibern und Fundamenten.

Aber was weiß ich:-)

Duck und weg

: Bearbeitet durch User
von Cyblord -. (cyblord)


Lesenswert?

Gerhard O. schrieb:
> Vielleicht würden weniger seiner Raketen explodieren, wenn
> man da etwas weniger "modern" vorgehen würden und man Erfahrungen
> berücksichtigen würde, anstatt einfach darauf los zu werkeln.

Komplett verquere Ansicht wenn man bedenkt was er bisher mit SpaceX 
erreicht hat. Allein die Booster Landungen sind ein reines Wunder.

von Gerhard O. (gerhard_)


Lesenswert?

Cyblord -. schrieb:
> Gerhard O. schrieb:
>> Vielleicht würden weniger seiner Raketen explodieren, wenn
>> man da etwas weniger "modern" vorgehen würden und man Erfahrungen
>> berücksichtigen würde, anstatt einfach darauf los zu werkeln.
>
> Komplett verquere Ansicht wenn man bedenkt was er bisher mit SpaceX
> erreicht hat. Allein die Booster Landungen sind ein reines Wunder.

Schon recht. Das muß man anerkennen. Aber wie dort gearbeitet wird, weiß 
man nicht viel. Aber andererseits wird da "drüben" jetzt viel gehudelt, 
wie man am Chaos in der USA observieren kann. Da scheint wenig 
durchdacht zu sein. Wenn bei Space-X ähnlich vorgegangen wird...

Aber lassen wir das. Ich möchte den Thread nicht stören.

von Cyblord -. (cyblord)


Lesenswert?

Gerhard O. schrieb:
> Schon recht. Das muß man anerkennen. Aber wie dort gearbeitet wird, weiß
> man nicht viel. Aber andererseits wird da "drüben" jetzt viel gehudelt,
> wie man am Chaos in der USA observieren kann. Da scheint wenig
> durchdacht zu sein. Wenn bei Space-X ähnlich vorgegangen wird...

Genau du weißt davon nicht viel. Die Ergebnisse sprechen für sich. Der 
Rest ist doch nun wirklich wirres Bashing aus lauter verqueren 
Mutmaßungen.

von Gerhard O. (gerhard_)


Lesenswert?

Cyblord -. schrieb:
> Gerhard O. schrieb:
>> Schon recht. Das muß man anerkennen. Aber wie dort gearbeitet wird, weiß
>> man nicht viel. Aber andererseits wird da "drüben" jetzt viel gehudelt,
>> wie man am Chaos in der USA observieren kann. Da scheint wenig
>> durchdacht zu sein. Wenn bei Space-X ähnlich vorgegangen wird...
>
> Genau du weißt davon nicht viel. Die Ergebnisse sprechen für sich. Der
> Rest ist doch nun wirklich wirres Bashing aus lauter verqueren
> Mutmaßungen.

Lassen wir es gut sein. Ich gab nur meine Ansicht vom Besten und 
beabsichtige nicht zu streiten oder rechthaberisch zu sein. Daß die 
Ergebnisse für sich sprechen, bestreite ja keiner. Aber trotzdem 
instillt mir Elons Vorgehensweise sonst wenig Bewunderung.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Die
> Aufteilung einer Arbeit in kleine Happen ist die eigentliche Leistung
> bei Software-Entwicklung. Das wird aber bei dem Scrum, was ich aus der
> Praxis und Theorie kennengelernt habe, überhaupt nicht thematisiert.

Darum geht es ja auch nicht.

Mir fällt auf, wie sehr Du immer wieder betonst, daß Du Scrum angeblich 
in "Theorie und Praxis kennengelernt" haben willst, sich Deine Aussagen 
dazu jedoch lesen, als schriebe ein Blinder über Farben.

Und wer dann dabei auch noch von

> dressierten Affen

faselt, disqualifiziert sich selbst und demonstriert nur seine 
Frustration. Hab trotzdem einen schönes Wochenende.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Joe schrieb:
>> Die
>> Aufteilung einer Arbeit in kleine Happen ist die eigentliche Leistung
>> bei Software-Entwicklung. Das wird aber bei dem Scrum, was ich aus der
>> Praxis und Theorie kennengelernt habe, überhaupt nicht thematisiert.
>
> Darum geht es ja auch nicht.

Oh doch, genau darum geht es. Das ist der Knackpunkt!

Der ad hominem Angriff weist auf Erregung durch argumentativen Notstand 
hin. Ich erspare mir, darauf einzugehen, zitiere nur ein Videointerview 
mit einem ausgewiesenen Fachmann:
https://www.youtube.com/watch?v=Xi4WG-FVT6Q
The Ugly of Agile (with Dr. Bertrand Meyer)

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Sheeva P. schrieb:
>> Joe schrieb:
>>> Die
>>> Aufteilung einer Arbeit in kleine Happen ist die eigentliche Leistung
>>> bei Software-Entwicklung. Das wird aber bei dem Scrum, was ich aus der
>>> Praxis und Theorie kennengelernt habe, überhaupt nicht thematisiert.
>>
>> Darum geht es ja auch nicht.
>
> Oh doch, genau darum geht es. Das ist der Knackpunkt!

Sehr witzig, genau darauf geht der von Dir verlinkte Dr. Bertrand 
Meyer in seinem Video "The Good of Agile (with Dr. Bertrand Meyer)" [1] 
sogar selbst  ein. Aber Deine... "Argumentation" sieht ohnehin vielmehr 
danach aus, daß Du primär Deine grundsätzliche Ablehnung bestätigen 
willst.

Der Vollständigkeit halber sei erwähnt, daß es aus der von Dir 
verlinkten Reihe mit Dr. Bertrand Meyer noch ein weiteres Video, genannt 
"The Hype of Agile (with Dr. Bertrand Meyer)" [2] gibt.

[1] https://www.youtube.com/watch?v=Oo-tmrSVdB0
[2] https://www.youtube.com/watch?v=0XHwmxgoBTI

> Der ad hominem Angriff

Ausgerechnet jemand, der andere Menschen als "dressierte Affen" 
bezeichnet, beschwert sich dann über "ad hominem Angriffe". Welch 
lustige Ironie. :-)

> Ich erspare mir, darauf einzugehen, zitiere nur ein Videointerview
> mit einem ausgewiesenen Fachmann:
> https://www.youtube.com/watch?v=Xi4WG-FVT6Q
> The Ugly of Agile (with Dr. Bertrand Meyer)

Daß Dr. Meyer bereits in seinem Eingangsstatement von berechtigter 
Kritik ("criticism [...] that is justified") an den Wasserfallmodellen 
spricht, ist Dir vermutlich nur zufällig entgangen.

Andererseits ist bereits Herrn Dr. Meyers Behauptung, agile Methoden 
würden eine "Deprecation of upfront requirements & design" aus meiner 
Perspektive ziemlicher Humbug. Tatsächlich schweigt sich die 
Fachliteratur zu dem Thema weitestgehend aus -- stattdessen sieht zum 
Beispiel Scrum sogar eigens eine feste Rolle dafür vor, den Product 
Owner. Oh!

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Sehr witzig, genau darauf geht der von Dir verlinkte Dr. Bertrand
> Meyer in seinem Video "The Good of Agile (with Dr. Bertrand Meyer)"
> sogar selbst  ein.

Die Punkte von Bertrand Meyer "Depreciation of upfront requirements & 
design" und "User Stories as a basis for requirements" sind es, die ich 
vor allem meine. Für mich als Informatiker ist Abstraktion das a und o. 
Wenn ich von einer neuen User Story erfahre, dann stellt sich für mich 
zu allererst die Frage, ob das mit der Softwarearchitektur kompatibel 
ist oder man das frickeln anfangen muß. Beide Punkte von Meyer heißen in 
Umgangssprache "Drausfloswurschteln" oder "Fahren auf Sicht", "Sich von 
Software-Laien die Architektur diktieren lassen müssen". Wegen 
"Abstraktion" gleich eine Analogie: Der Bauingenieur stellt sich immer 
an erster Stelle die Frage, ob ein neuer Wunsch des Bauherrn die Statik 
verändert - ob das, was der Bauherr sich vorstellt, cool ist oder den 
Marktwert des Hauses verbessert ist, interessiert ihn weniger. Ein 
Bauherr (Product Owner), der während der Bauphase alle Naslang neue 
Flügel, Zimmer, Türen und Kellergeschoße wünscht, kann jeden 
Bauingenieur in den Wahnsinn treiben, besonders wenn er ihm gegenüber 
weisungsbefugt ist.

> Der Vollständigkeit halber sei erwähnt, daß es aus der von Dir
> verlinkten Reihe mit Dr. Bertrand Meyer noch ein weiteres Video, genannt
> "The Hype of Agile (with Dr. Bertrand Meyer)" [2] gibt.

Ich habe das ganze! Buch von Meyer in meiner Freizeit gelesen.

Ich kenne auch das agile Manifest, nicht auswendig, aber Google ist 
einen Mausklick entfernt:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans

So wie ein intellektuell redlicher Sozialist nicht den idealen 
Sozialismus dem real existierenden Kapitalismus entgegenstellen sollte 
(auch wenn er dabei die Diskussion immer haushoch gewinnt), so sollten 
die Agilisten auch nicht die Augen davor verschließen, daß *Agile 
systematische Schwächen hat*. Was ich meine: So böse ist Wasserfall auch 
nicht, und ein maßvoller Wasserfall ist weitaus besser als ein radikales 
Agile.

> Ausgerechnet jemand, der andere Menschen als "dressierte Affen"
> bezeichnet, beschwert sich dann über "ad hominem Angriffe". Welch
> lustige Ironie. :-)

Das mit den "dressierten Affen" ist so eine Redensweise, mit der ich 
fleißige, aber gering qualifizierte Mitarbeiter, welche nichts 
hinterfragen, meine. Wenn dich das verletzt hat, dann möchte ich mich 
dafür aufrichtig entschuldigen. Ja, es ist Frust bei mir im Spiel und 
ich werde auch gern polemisch. Ich wollte mit der Polemik sagen, daß 
etwa beim Uhrenbau der Prozess nicht die Qualifikation Uhrmacher 
ersetzen kann (hingegen bei Mc Donald´s und bei Ford am Fließband konnte 
man Qualifikation durch ein Standardprozess ersetzen - habe ich schon 
vor einem Jahr weiter oben geschrieben, ich wiederhole mich).

> Daß Dr. Meyer bereits in seinem Eingangsstatement von berechtigter
> Kritik ("criticism [...] that is justified") an den Wasserfallmodellen
> spricht, spricht, ist Dir vermutlich nur zufällig entgangen.

Nein, es ist mir nicht entgangen. Wollen wir solche Spitzen vielleicht 
in Zukunft weglassen?

> Andererseits ist bereits Herrn Dr. Meyers Behauptung, agile Methoden
> würden eine "Deprecation of upfront requirements & design" aus meiner
> Perspektive ziemlicher Humbug. Tatsächlich schweigt sich die
> Fachliteratur zu dem Thema weitestgehend aus -- stattdessen sieht zum
> Beispiel Scrum sogar eigens eine feste Rolle dafür vor, den Product
> Owner. Oh!

Das sind wir wieder genau am Knackpunkt. *Der P.O. hat die 
Anwenderbrille auf*, nicht die eines Softwarearchitekten / 
Systemanalytikers.

Was meinst du mit "Fachliteratur schweigt sich zu dem Thema 
weitestgehend aus", heisst das, daß niemand Meyer widersprochen hat oder 
daß das Problem an sich nicht thematisiert wird?

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Die Punkte von Bertrand Meyer "Depreciation of upfront requirements &
> design" und "User Stories as a basis for requirements" sind es, die ich
> vor allem meine. Für mich als Informatiker ist Abstraktion das a und o.
> Wenn ich von einer neuen User Story erfahre, dann stellt sich für mich
> zu allererst die Frage, ob das mit der Softwarearchitektur kompatibel
> ist oder man das frickeln anfangen muß. Beide Punkte von Meyer heißen in
> Umgangssprache "Drausfloswurschteln" oder "Fahren auf Sicht", "Sich von
> Software-Laien die Architektur diktieren lassen müssen".

Das sind die Vorwürfe von Herrn Dr. Meyer. In der gelebten Praxis von 
agilen Projekten habe ich jedoch noch nie(!) sowas gesehen, wobei meine 
Erfahrungen natürlich nicht repräsentativ sein können.

> Wegen
> "Abstraktion" gleich eine Analogie: Der Bauingenieur stellt sich immer
> an erster Stelle die Frage, ob ein neuer Wunsch des Bauherrn die Statik
> verändert - ob das, was der Bauherr sich vorstellt, cool ist oder den
> Marktwert des Hauses verbessert ist, interessiert ihn weniger. Ein
> Bauherr (Product Owner), der während der Bauphase alle Naslang neue
> Flügel, Zimmer, Türen und Kellergeschoße wünscht, kann jeden
> Bauingenieur in den Wahnsinn treiben, besonders wenn er ihm gegenüber
> weisungsbefugt ist.

Der Product Owner repräsentiert zwar den Bauherrn, ist aber entweder 
selbst ein Bauingenieur oder hört seinen Ingenieuren zu. Insofern ähnelt 
seine Rolle dem Projektleider in klassischen Projekten, wenngleich seine 
Befugnisse nicht so groß sind: der Projekt Owner schreibt nämlich keine 
technischen Lösungen für die Probleme vor, sondern überläßt das den 
Fachleuten.

> Ich kenne auch das agile Manifest, nicht auswendig, aber Google ist
> einen Mausklick entfernt:
> Individuen und Interaktionen mehr als Prozesse und Werkzeuge
> Funktionierende Software mehr als umfassende Dokumentation
> Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
> Reagieren auf Veränderung mehr als das Befolgen eines Plans

Gegen welche dieser Werte erhebst Du bitte welche Einsprüche?

> So wie ein intellektuell redlicher Sozialist nicht den idealen
> Sozialismus dem real existierenden Kapitalismus entgegenstellen sollte

Verzeihung, aber der Sozialismus ist doch das klassische 
Vorgehensmodell: da wird ein Plan (im Sozialismus der Fünfjahresplan, im 
klassischen Modell die Lasten- und Pflichtenhefte) erstellt und dann 
befolgt. Mit ein bisschen Glück funktioniert der Plan, alles fein!

Aber mit nur einem kleinen bisschen Pech krankt der Plan an genau 
demselben Problem wie der Sozialismus, das der Comedian und Physiker 
Vince Ebert in seinem Buch "Unberechenbar. Warum das Leben zu komplex 
ist, um es perfekt zu planen" (Rowolt 2016) beschreibt. Mit wachsender 
Komplexität eines Projekts steigen sowohl seine Implementierungs- und 
seine Laufzeit und damit auch die Wahrscheinlichkeit, daß sich etwas an 
den Rahmenbedingungen ändert.

Der Umgang klassischer Vorgehensmodelle mit veränderten 
Rahmenbedingungen ist, daß a) die notwendigen Modifikationen an Lasten- 
und Pflichtenheften geplant, dann b) mit dem Kunden verhandelt wird, wer 
das bezahlen soll und wie sich das auf die Projektlaufzeit auswirkt und 
erst, wenn c) die Einigung mit dem Kunden getroffen ist, mit den 
Modifikationen an den Heften und den Implementierungen überhaupt erst 
angefangen wird.

Wenn sich hingegen im schlimmsten Fall keine Einigung mit dem Kunden 
treffen läßt, wer die Änderung nun bezahlt... was dann? Ach ja, wir 
hatten ja einen ursprünglichen, vertraglich vereinbarten Plan, und an 
den halten wir uns dann einfach. Daß der Kunde unser Produkt dann am 
Ende nicht oder zumindest nicht richtig und komfortabel nutzen kann, ist 
nicht so schlimm, denn wir haben ja unseren Vertrag erfüllt und werden 
dafür bezahlt.

Agile Modelle gehen hingegen von vorneherein davon aus, daß es im Laufe 
der Umsetzung eines Projekts zu unvorhersehbaren Änderungen kommen muß. 
Das ist letztlich eine Funktion der Komplexität des Projekts und wird 
damit auch in gewissen Grenzen kalkulierbar hinsichtlich der Budget- und 
Zeitvorgaben. Der primäre Fokus liegt darauf, dem Kunden eine praktisch 
nutzbare Software zu liefern, die ihm einen realen Gebrauchswert und im 
Idealfall sogar einen Wettbewerbsvorteil sichern kann.

> Das mit den "dressierten Affen" ist so eine Redensweise, mit der ich
> fleißige, aber gering qualifizierte Mitarbeiter, welche nichts
> hinterfragen, meine. Wenn dich das verletzt hat, dann möchte ich mich
> dafür aufrichtig entschuldigen.

Danke.

> Ja, es ist Frust bei mir im Spiel und
> ich werde auch gern polemisch. Ich wollte mit der Polemik sagen, daß
> etwa beim Uhrenbau der Prozess nicht die Qualifikation Uhrmacher
> ersetzen kann (hingegen bei Mc Donald´s und bei Ford am Fließband konnte
> man Qualifikation durch ein Standardprozess ersetzen - habe ich schon
> vor einem Jahr weiter oben geschrieben, ich wiederhole mich).

Man kann auch in den agilen Methoden nicht auf die Expertise verzichten, 
aber das ist dabei auch gar nicht intendiert. Genau das bildet das 
"Individuen und Interaktionen mehr als Prozesse und Werkzeuge" im agilen 
Manifest ab. Agile Projekte setzen auf und nutzen die Erfahrungen und 
die Expertise der an dem Projekt Beteiligten. Darum ist es so wichtig, 
die Kommunikation zu fördern, und die im Team vorhandene Expertise 
sicht- und nutzbar zu machen.

> Nein, es ist mir nicht entgangen. Wollen wir solche Spitzen vielleicht
> in Zukunft weglassen?

Das wäre mir sehr willkommen. :-)

> Das sind wir wieder genau am Knackpunkt. *Der P.O. hat die
> Anwenderbrille auf*, nicht die eines Softwarearchitekten /
> Systemanalytikers.

Die Product Owner mit denen ich bisher zusammenarbeiten durfte, hatten 
alle einen starken technischen Hintergrund als Analytiker und / oder 
Architekten. Wenn man da einen Fachfremden hinsetzen würde, hätte man 
dasselbe Problem, das man bei klassischen Vorgehensmodellen einen 
Fachfremden an die Erstellung von Lasten- und Pflichtenheften oder als 
Projektleiter einsetzen würde.

> Was meinst du mit "Fachliteratur schweigt sich zu dem Thema
> weitestgehend aus", heisst das, daß niemand Meyer widersprochen hat oder
> daß das Problem an sich nicht thematisiert wird?

Ich meine, daß die Fachliteratur an dieser Stelle nicht viel dazu sagt, 
weil es aus meiner Sicht nicht nur offensichtlich und selbstverständlich 
ist, sondern vor allem auch zu den Punkten gehört, die agile Methoden 
gar nicht adressieren. Ohne "upfront requirements & design" kann man 
ohnehin nicht mit der Implementierung einer Software anfangen, es muß 
schon von Anfang an ein mehr oder weniger grobes Ziel geben.

Jedoch ist das "mehr oder weniger Grobe" dann auch der Punkt, der die 
beiden Herangehensweisen unterscheidet. Während klassische Modelle 
versuchen, das Projekt gleich von Anfang an in einen festen, 
unveränderbaren, detaillierten und weitgehend unflexiblen Plan 
festzulegen, gehen die agilen Methoden einen anderen Weg und akzeptieren 
Veränderungen als einen inhärenten Bestandteil sowohl des Planes, als 
auch des Projekts.

Lustigerweise sehe ich bei den agilen Methoden auch gewisse Anleihen bei 
den Leitsätzen der OpenSource-Entwicklung, nämlich einerseits des 
"release early, release often" von Eric S. Raymond aus "The cathedral 
and the bazaar" [1] und andererseits beim "Rough consensus [and running 
code]" der IETF.

[1] https://en.wikipedia.org/wiki/Release_early,_release_often
[2] https://en.wikipedia.org/wiki/Rough_consensus

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Auch klassische Vorgehensweise kann Rücksicht auf Änderungen, die 
während der Entwicklung entstehen, nehmen. Der Vorteil einer 
intelligenten klassischen Vorgehensweise ist eben die größer mögliche 
Bedachtsamkeit. Die Scrum Vorgehensweise erinnert stark an Elons 
Kettensäge Vorgehensweise die bekannterweise viel Klebstoff zum 
instandsetzen der gehudelt verursachten Schäden notwendig macht. So, aus 
dieser Sicht, bevorzuge ich behutsame und bedachte, mit Sachverstand 
ausgeführte Entwicklung, die auch der heutzutage geforderten 
Flexibilität Rechnung trägt. Auch das kann man planen. Klassische 
Entwicklung wird der Hudelei meist immer überlegen sein. Scrum instillt 
wenig Vertrauen, daß es überhaupt möglich ist, in der Weise durchdacht 
und überlegt vorzugehen.

Es ist vielleicht hart, diese Ansicht hinzunehmen, aber die Ergebnisse 
werden das in vielen Fällen auch belegen. Was ich damit sagen will, ist, 
daß, ganz gleich, ob klassisch oder nicht, überlegte Vorgehensweise die 
Essenz des Erfolges ist. Ich habe die Erfahrung gemacht, daß viele 
moderne IT Billigprodukte ziemlich grottenschlecht und voller Bugs sind. 
Dazu kommt, daß modernes Marketing sich drängend anstellt, daß 
Entwicklung nur ein geduldeter Kostenpunkt ist und so schnell wie 
möglich fertig werden muß.

Obwohl mein Fahrzeug als Auto gut ist, werde ich von den vielen SW 
"Eigenheiten" täglich genervt. Die Fahrzeug Einstellungs-SW benimmt sich 
in vielen Aspekten unmöglich und irritiert in vielen Aspekten. Das wäre 
nicht der Fall, wenn man bei der SW durchdacht und überlegt vorgehen 
würdet. Und regt Euch jetzt nicht auf; die SW nervt und keine 
Entschuldigung kann das entkräften.

Als Kunde habe ich das Recht es zu kritisieren. Aber es hört ja kein 
Mensch auf den Kunden, ausser wenn er mit dem Portmonee auf dem Boden 
stampft, was ein gewisser Elon jetzt in jüngster Zeit erfahren muß. Ich 
bin von vielen modernen Produkten hinsichtlich Bedienungsfreundlichkeit 
und Zuverlässigkeit sehr enttäuscht. Die Ergonomie "sucks" in vielen 
Fällen.

: Bearbeitet durch User
von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Das sind die Vorwürfe von Herrn Dr. Meyer. In der gelebten Praxis von
> agilen Projekten habe ich jedoch noch nie(!) sowas gesehen, wobei meine
> Erfahrungen natürlich nicht repräsentativ sein können.

Ich habe nur gut ein Jahr Scrum erlitten. Und doch passen meine 
Erfahrung zu den Beschreibungen von Bertrand Meyer. Nach dem Motto "Wir 
sind ja jetzt agil, wir brauchen nicht mehr die ganze Vorausplanung"

> Der Product Owner repräsentiert zwar den Bauherrn, ist aber entweder
> selbst ein Bauingenieur oder hört seinen Ingenieuren zu. ... der Projekt Owner 
schreibt nämlich keine
> technischen Lösungen für die Probleme vor, sondern überläßt das den
> Fachleuten.

Der PO repräsentiert das Business, ist typischerweise ein BWLer oder 
irgendwas mit Wirtsch-I**. Auch wenn er keine technischen Lösungen einer 
einzelnen User Story vorschreibt, greift er implizit in die Architektur 
ein. Indem er sagt, was wann zu tun ist. Ich habe es weiter oben mal 
verglichen mit dem Bauherrn, der bestimmt, was am Haus in welcher 
Reihenfolge gebaut wird.

>> Ich kenne auch das agile Manifest, nicht auswendig, aber Google ist
>> einen Mausklick entfernt:
>> Individuen und Interaktionen mehr als Prozesse und Werkzeuge
>> Funktionierende Software mehr als umfassende Dokumentation
>> Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
>> Reagieren auf Veränderung mehr als das Befolgen eines Plans
>
> Gegen welche dieser Werte erhebst Du bitte welche Einsprüche?

Gegen keinen! Genauso wie ich die sozialistischen Werte und Ziele 
ehrenwert finde. Aber genauso wie der real existierende Sozialismus, 
gelinde gesagt, den Menschen regelmäßig keinen Segen gebracht hat, ist 
das real existierende Agile oft "Prozesse und Werkzeuge mehr als 
Individuen und Interaktionen" oder "Optimierung der Velocity anstatt 
Verhinderung technischer Schulden". "Optimierung der Velocity" wäre etwa 
analog zu den 5 Jahres-Plänen im Sozialismus, die imho ja immer optimal 
erfüllt wurden. Wenn man "Dark Agile" oder "Fake Agile" googelt, dann 
findet man viel Lesestoff. Und mich stört, wenn ein Agilist behauptet, 
das wäre halt alles kein wahres Agile, Ende der Diskussion. Die No True 
Scotsman Fallacy läßt grüßen.

> Agile Modelle gehen hingegen von vorneherein davon aus, daß es im Laufe
> der Umsetzung eines Projekts zu unvorhersehbaren Änderungen kommen muß.
> Das ist letztlich eine Funktion der Komplexität des Projekts und wird
> damit auch in gewissen Grenzen kalkulierbar hinsichtlich der Budget- und
> Zeitvorgaben. Der primäre Fokus liegt darauf, dem Kunden eine praktisch
> nutzbare Software zu liefern, die ihm einen realen Gebrauchswert und im
> Idealfall sogar einen Wettbewerbsvorteil sichern kann.

Ja, ich weiß! :-) Das ist die Theorie. Das sich bewußt machen, daß 
jederzeit unvorhersehbare Dinge geschehen können, kann dazu führen, daß 
man gar nicht plant. Es ist alles weiter oben im Follow-up schon 
beschrieben worden, Stichwort "ticketgetriebene Architektur. Der 
Professor Betrand Meyer beginnt ja seinen Vortrag mit der Aussage, daß 
die schlechten Erfahrungen mit Wasserfall-Projekten dazu führen, daß man 
sein Heil im Gegenteil sucht. Da sollte man sich immer bewußt sein: Das 
Gegenteil von etwas Falschem ist nicht zwingend etwas Richtiges.

> Agile Projekte setzen auf und nutzen die Erfahrungen und
> die Expertise der an dem Projekt Beteiligten. Darum ist es so wichtig,
> die Kommunikation zu fördern, und die im Team vorhandene Expertise
> sicht- und nutzbar zu machen

Auch klassische Projekte setzen auf und nutzen die Erfahrungen und die 
Expertise der an dem Projekt Beteiligten. Auch in klassischen Projekten 
ist die Kommunikation sowie die Nutzng der vorhandenen Expertise 
entscheidend wichtig.

> Die Product Owner mit denen ich bisher zusammenarbeiten durfte, hatten
> alle einen starken technischen Hintergrund als Analytiker und / oder
> Architekten. Wenn man da einen Fachfremden hinsetzen würde, hätte man
> dasselbe Problem, das man bei klassischen Vorgehensmodellen einen
> Fachfremden an die Erstellung von Lasten- und Pflichtenheften oder als
> Projektleiter einsetzen würde.

Auch im klassischen Vorgehensmodell ist es von entscheidender Bedeutung, 
daß die Lasten- und Pflichtenhefte von Fachleuten geschrieben und der 
Projektleiter sowohl einen technischen Hintergund als auch 
Business-Wissen hat, um in intensiver Kommunikation mit den 
Projektmitgliedern und Stakeholdern das Projekt optimal zu steuern.

> Ohne "upfront requirements & design" kann man
> ohnehin nicht mit der Implementierung einer Software anfangen, es muß
> schon von Anfang an ein mehr oder weniger grobes Ziel geben.

Das wollte ich hören! :-)
Es braucht bei Software eine Architektur. Ein wunderbares Beispiel ist 
das Netzwerk-Schichtenmodell, das Jahrzehnte überdauert hat. So etwas 
entsteht nicht spontan als Evolution von vielen User-Stories. Dann noch 
meine Aussage von weiter oben dazu, daß "upfront requirements & design" 
bei Scrum nicht thematisiert bzw. problematisiert wird.

> Jedoch ist das "mehr oder weniger Grobe" dann auch der Punkt, der die
> beiden Herangehensweisen unterscheidet. Während klassische Modelle
> versuchen, das Projekt gleich von Anfang an in einen festen,
> unveränderbaren, detaillierten und weitgehend unflexiblen Plan
> festzulegen, gehen die agilen Methoden einen anderen Weg und akzeptieren
> Veränderungen als einen inhärenten Bestandteil sowohl des Planes, als
> auch des Projekts.

Schön gesagt! Aber es klingt wie ein Katechismus. Das kann ich auch:

Während agile Methoden versuchen, die Erfordernis einer systematischen 
Planung durch eine Folge von kurzfristigen ad-hoc-Lösungen zu umgehen, 
wird im Wasserfall auf umfassende Vorausschau, genaue Analyse und feste 
Projektphasen geachtet, und so eine optimale Umsetzung sowohl des 
Planes, als auch des Projekts garantiert.

von Sheeva P. (sheevaplug)


Lesenswert?

Gerhard O. schrieb:
> Auch klassische Vorgehensweise kann Rücksicht auf Änderungen, die
> während der Entwicklung entstehen, nehmen.

Selbstverständlich kann sie das. Aber in klassischen Modellen sind 
Änderungen weder eingeplant noch einkalkuliert.

> Der Vorteil einer
> intelligenten klassischen Vorgehensweise ist eben die größer mögliche
> Bedachtsamkeit.

Nichts, genauer: genau gar nichts hält agile Modelle von einer 
bedachtsamen Vorgehensweise ab, und haargenau dasselbe -- nämlich 
nichts, genauer: genau gar nichts -- hält klassische Vorgehensweise 
davon ab, die Bedachtsamkeit außer Acht zu lassen.

> Die Scrum Vorgehensweise erinnert stark an Elons Kettensäge

Wo wären wir denn ohne Herumtüfteln und Ausprobieren? Vermutlich wäre 
das Rad nicht erfunden und das Feuer zwar erfunden, aber wegen der damit 
verbundenen Gefahren sofort wieder verboten worden.

> Obwohl mein Fahrzeug als Auto gut ist, werde ich von den vielen SW
> "Eigenheiten" täglich genervt. Die Fahrzeug Einstellungs-SW benimmt sich
> in vielen Aspekten unmöglich und irritiert in vielen Aspekten. Das wäre
> nicht der Fall, wenn man bei der SW durchdacht und überlegt vorgehen
> würdet. Und regt Euch jetzt nicht auf; die SW nervt und keine
> Entschuldigung kann das entkräften.

Mitunter ist es sogar so, daß das nervige Verhalten sogar vorgeschrieben 
ist. Jüngst bin ich während eines Ölwechsels beim Schlachtschiff ein 
ganz modernes Fahrzeug gefahren, IIRC einen Opel Mokka. Jedes Mal, wenn 
ich die zulässige Höchstgeschwindigkeit um auch nur einen Kilometer pro 
Stunde überschritten habe, wurde ich gezielt mit Geblinke und Gepiepe 
genervt. Das konnte ich zwar mittels mehrerer Menüpunkte des 
Bordcomputers wieder ausschalten, aber nicht dauernd: beim nächsten 
Losfahren war es wieder aktiv.

Eine Recherche ergab, daß dieses Verhalten heute vorgeschrieben ist, und 
zwar auf Betreibender Europäischen Union. Die will die Anzahl der 
Verkehrstoten bis (IIRC) 2050 auf 0 bringen und da das Überschreiten der 
Höchstgeschwindigkeiten eine der größten Unfallursachen ist, 
insbesondere solchen mit Personenschäden, werden wir uns wohl an 
nervende Fahrzeuge gewöhnen müssen. (Okay: solange ich meinen 
Donkervoort fahren kann, MUSS ich nicht, aber... ich werde doch leider 
weder jünger noch gelenkiger, ne.)

Nebenbei bemerkt: ich bin ein großer Freund der großen europäischen Idee 
und unterstütze auch das Ziel, bis 2050 keine Verkehrstoten mehr zu 
haben. Auf der anderen Seite sehe ich es aber nicht als europäische 
Idee, wenn Tausende von Bürokraten in Brüssel herumsitzen und sich was 
ausdenken, um uns zu nerven.

Es gibt genug, das einen heute beim Umgang mit Software nerven kann. Das 
alles hat aber nun wirklich rein nichts damit zu tun, mit welcher 
Vorgehensweise die Software entwickelt wurde.

Ich glaube auch nicht, daß es die Diskussion voranbringt, die 
unerwünschten Effekte bei einer Software einem, sagen wir: US-Oligarchen 
anzudichten. Wir müssen den Tuppes nicht gut finden, aber in diesem 
Punkt liegt unser Cyblord absolut richtig: Klebstoff macht Fortschritte 
nicht weniger fortschrittlich. Denn am Ende kommt es auf das Ergebnis 
an, oder? :-)

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Ich habe nur gut ein Jahr Scrum erlitten. Und doch passen meine
> Erfahrung zu den Beschreibungen von Bertrand Meyer. Nach dem Motto "Wir
> sind ja jetzt agil, wir brauchen nicht mehr die ganze Vorausplanung"

Wenn ich so etwas höre, könnte ich ko^Werbrechen. Nein, im Ernst: das 
löst bei mir sofort massive Fluchtinstinkte aus. Ähnlich übrigens auch 
bei klassischen Projekten mit fachfremden Architekten und oder PLs... 
das hat aber nichts mit der Methode zu tun. Man kann Positionen in jedem 
Projekt falsch besetzen, ganz unabhängig von der jeweiligen Methode.

> Der PO repräsentiert das Business, ist typischerweise ein BWLer oder
> irgendwas mit Wirtsch-I**. Auch wenn er keine technischen Lösungen einer
> einzelnen User Story vorschreibt, greift er implizit in die Architektur
> ein. Indem er sagt, was wann zu tun ist. Ich habe es weiter oben mal
> verglichen mit dem Bauherrn, der bestimmt, was am Haus in welcher
> Reihenfolge gebaut wird.

Dann habe ich das Bauherren-Beispiel mißverstanden. Allerdings habe ich 
es (bislang) auch noch nicht erleben müssen, daß ein PO a) fachfremd war 
und, obendrein, sich b) dessen nicht bewußt war und den eigenen 
Fachleuten nicht zuhören wollte oder konnte. Glück gehabt.

Die andere Alternative, mit einem... sagen wir, ignoranten Projektleiter 
zu arbeiten, kenne ich aber leider zu Genüge. Das führt auch zu nichts 
Gutes, hast Du das nicht auch mal erlebt?

> Gegen keinen! Genauso wie ich die sozialistischen Werte und Ziele
> ehrenwert finde. Aber genauso wie der real existierende Sozialismus,
> gelinde gesagt, den Menschen regelmäßig keinen Segen gebracht hat, ist
> das real existierende Agile oft "Prozesse und Werkzeuge mehr als
> Individuen und Interaktionen" oder "Optimierung der Velocity anstatt
> Verhinderung technischer Schulden". "Optimierung der Velocity" wäre etwa
> analog zu den 5 Jahres-Plänen im Sozialismus, die imho ja immer optimal
> erfüllt wurden.

Da sind wir wieder bei den Betriebswirten... oder genauer, den 
Controllern. Solcherart ausgebildete Menschen versuchen immer, Meßgrößen 
zu finden, um Arbeitsleistungen einzelner Mitarbeiter zu messen und 
vergleichen.

Aber Deine Parallele zum Sozialismus paßt schon: während 
kapitalistische, vulgo agile Projekte mit den Risiken von Änderungen und 
Scheitern leben, kennen klassische Projekte nur den Fünfjahresplan -- 
und müßten eigentlich sterben, wenn sie dessen Ziele reißen.

Ein ideales klassisches Projekt kann zweifellos ebenso erfolgreich sein 
wie ein ideales agiles Projekt. Aber während die Verantwortungen in den 
agilen Projekten verteilt wird, neigen klassische Projekte zur 
Konzentration dieser Verantwortlichkeiten. Ob das sinnvoller ist, hängt 
an den Verantwortlichen.

> Die No True Scotsman Fallacy läßt grüßen.

LOL Ja, natürlich. Aber wenn Du Dir in den Fuß schießt und Dich dann 
über eine Verletzung an Deinem Fuß beschwerst... genau. :-)

> Ja, ich weiß! :-) Das ist die Theorie. Das sich bewußt machen, daß
> jederzeit unvorhersehbare Dinge geschehen können, kann dazu führen, daß
> man gar nicht plant. Es ist alles weiter oben im Follow-up schon
> beschrieben worden, Stichwort "ticketgetriebene Architektur.

Im Endeffekt ist es ja so: wer bis ins kleinste Detail plant, wird 
genauso scheitern wie jener, der gar nichts plant.

Dieser Umstand hat aber nichts mit Modellen zu tun, denn: man kann in 
einem klassischen Projekt genau so gut planen wie in einem agilen, und 
man kann in einem klassischen Projekt dieselben Pfeifen auf 
Entscheiderpositionen setzen wie in agilen. Natürlich könnte man sagen: 
die verdammten Betriebswirte sind schuld (das sind sie ja immer, und 
dann... irgendwie auch wieder nicht).

Aber würde das unsere Welten irgendwie besser machen?

von Gerhard O. (gerhard_)


Lesenswert?

Sheeva,

Du hast recht, und ich, meine Ruhe:-)))

Was ich damit ausdrücken will, ist, daß ich Deinen Kommentar durchaus 
sachdienlich finde.

Ich bin schockiert, was bei Euch in der EU nun mittlerweile Pflicht 
geworden ist. Da ist sogar mein (kanadischer) Mazda, dezent, daß die 
Höchstgeschwindigkeitsüberschreitung nur mit einer roten Umrandung der 
Anzeige am TFT "Armaturenbrett" quittiert wird. Darüber hinaus, stimme 
ich Deinen Bemerkungen bezüglich Reduzierung oder Vermeidung von 
Verkehrstoten zu.

Was den Elon betrifft, möchte ich lieber verschweigen:-)
(das Paar zerschlägt bei uns jede Menge Porzellan und sorgt für viel 
Aufregung, Kommentar und hohen Blutdruck)

Was SW Entwicklung im Betrieb betrifft, kommen wir mit unserem "agilen 
klassischen" Entwicklungsmodell einer Zusammenarbeit durchaus ganz gut 
zurecht. Wir besprechen uns miteinander, wenn es "Team" harmonisch 
zweckdienlich ist und weil wir aufeinander gut eingespielt sind.

Gerhard

: Bearbeitet durch User
von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Joe schrieb:
>> Ich habe nur gut ein Jahr Scrum erlitten. Und doch passen meine
>> Erfahrung zu den Beschreibungen von Bertrand Meyer. Nach dem Motto "Wir
>> sind ja jetzt agil, wir brauchen nicht mehr die ganze Vorausplanung"

> Wenn ich so etwas höre, könnte ich ko^Werbrechen.

Willkommen im Club!

> Ähnlich übrigens auch
> bei klassischen Projekten mit fachfremden Architekten und oder PLs...
> das hat aber nichts mit der Methode zu tun.

Da widerspreche ich. Es hat viel mit der Methode zu tun. Natürlich 
machen Menschen extrem viel aus, aber bestimmte Muster sind 
systembedingt.

Ich erinnere ich an die Zeit, wo wir agil wurden. Da bekamen wir im Team 
einen Scrum Master von einer externen Beratungsfirma oktroyiert, die uns 
agil machen sollte. Der Typ war so penetrant und übergriffig wie der 
klischeehafte Animateur vom Kreuzfahrtschiff und fachlich völlig 
schmerzfrei auf dem Gipfel des berühmten Mount Stupid (siehe "Dunning 
Kruger Effekt"). Er hat den Leuten hinterhertelefoniert, wenn sie einmal 
nicht pünktlich bei den ganzen neu eingeführten Meetings waren.

In der Zeit habe ich einmal, im Daily befragt, was ich am Tag davor 
getan hatte, geantwortet, daß ich mit einem Kollegen aus der 
Fachabteilung zusammen intensiv eine Anforderung auf Machbarkeit und 
Umfang analysiert hatte. Dafür fing ich mir einen Rüffel ein, weil es 
keine User Story gäbe und schon gar keine im aktuellen Sprint. Ich war 
etwas irritiert, habe mich dann ganz übertrieben unterwürfig 
entschuldigt, daß ich "schwarz gearbeitet" hatte und eine gerechte 
Strafe wegen Eigenmächtigkeit erwarte.

An einem anderen Tag hatte ich im Daily gesagt, daß ich mit meinen 
Tickets aus dem Sprint vorzeitig fertig geworden bin und mir jetzt das 
eine oder andere Thema anschauen will, wo ich mich eine Zeit lang 
reindenken müßte. Die Reaktion war, ich solle das gefälligst lassen, 
sondern mir aus dem Backlog etwas nehmen. Meine Reaktion war, zu 
geloben, daß ich in Zukunft nicht mehr "zu schnell" zu arbeiten gedenke.

Gottseidank hat unser Chef diesen Scrum Master dann bald 
rausgeschmissen, als dieser begann, auch ihm gegenüber übergriffig zu 
werden.

Das war ungefähr die Zeit, als Rudi hier den Thread angefangen hat. Und 
auch die Zeit, wo ich das googeln zum Thema angefangen habe:

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
"Es ist bekannt, dass kreative Menschen ihre Kreativität verlieren, wenn 
sie während der Arbeit aufgefordert werden, sich zu erklären. Genauso 
ist es mit Software. Programmierer müssen oft in einem Umfeld 
einseitiger Transparenz arbeiten. Diese agilen Systeme, die so oft 
falsch angewendet werden, verlangen, dass sie trotz mangelnder 
Gegenseitigkeit einen demütigenden Einblick in ihre Zeit und Arbeit 
bieten. Anstatt an tatsächlichen, langfristigen Projekten zu arbeiten, 
für die sich eine Person begeistern könnte, wird sie dazu verdammt, an 
atomisierten "User Stories" auf Feature-Ebene zu arbeiten, und es wird 
ihnen oft nicht erlaubt, an Verbesserungen zu arbeiten, die nicht mit 
kurzfristigen, unmittelbaren Geschäftsanforderungen in Verbindung 
gebracht werden können (die oft von oben bereitgestellt werden). Diese 
fehlgeleitete, aber weit verbreitete Variante von Agile eliminiert das 
Konzept des Eigentums und behandelt Programmierer als austauschbare, 
standardisierte Komponenten."

Auch heute ist bei uns im Team noch so, daß jegliche Analyse von neuen 
Anforderungen (die 90% der Arbeit ausmacht) unbedingt im Sprint 
abgebildet werden muß, es muß dafür mindestens einen "Spike" im Jira 
geben. Ich erwarte, daß ich vielleicht irgendwann auf die Frage "An was 
denkst Du gerade" antworte "Spike 4711, Sprint 2025.7, 3,5 story 
points".

Kurz gesagt, das Scrum hat eine Bürokratie, eine Methoden- und 
Tickethuberei eingeführt, die ich in den 20 Jahren Beruf davor nie 
erlebt hatte. Unter Kollegen wird nur noch wenig fachlich gesprochen, es 
dominiert die Frage, welche User Story wieviel Story Points hat und in 
welchem Sprint sie gehen soll. Die inhaltliche Analyse beschränkt sich 
auf eine Schnellversteigerung, sog. "Planning Poker". Mehr Zeit ist 
nicht, wegen Anschlußtermin, sie wissen schon...

> Die andere Alternative, mit einem... sagen wir, ignoranten Projektleiter
> zu arbeiten, kenne ich aber leider zu Genüge. Das führt auch zu nichts
> Gutes, hast Du das nicht auch mal erlebt?

Ja, natürlich. Und ich erinnere mich an einen anderen Diskutanten weiter 
oben im Thread, der ganz verärgert war, als ich gesagt hatte, daß ein 
klassischer Projektleiter, der gut ist, mir tausend mal lieber ist, als 
der ganze Scrum-Zirkus.

> Da sind wir wieder bei den Betriebswirten... oder genauer, den
> Controllern. Solcherart ausgebildete Menschen versuchen immer, Meßgrößen
> zu finden, um Arbeitsleistungen einzelner Mitarbeiter zu messen und
> vergleichen.

Für solche Leute ist Agile ein willkommener Anlaß, beobachten zu können, 
daß die teure und knappe Ressource IT-Experte stets ausgelastet und den 
richtigen Aufgaben zugewiesen wird. Der Nerd, wo sonst keiner so recht 
weiß, an was er gerade tüftelt, muß an die Kandare genommen werden.

> Ein ideales klassisches Projekt kann zweifellos ebenso erfolgreich sein
> wie ein ideales agiles Projekt. Aber während die Verantwortungen in den
> agilen Projekten verteilt wird, neigen klassische Projekte zur
> Konzentration dieser Verantwortlichkeiten. Ob das sinnvoller ist, hängt
> an den Verantwortlichen.

Zustimmung. Aber so ist es wie die Aussage "ob Methode A oder B bessere 
Ergebnisse bringt, liegt an den Menschen", wahr, aber ohne wirkliche 
Aussage über die Methoden.

> Im Endeffekt ist es ja so: wer bis ins kleinste Detail plant, wird
> genauso scheitern wie jener, der gar nichts plant.

Unbedingt.

Das Paradoxe für mich und meine kleine Welt ist aber das, was ich weiter 
oben beschrieben habe: es wird die Arbeit immer in sprint-gerechte 
Häppchen zerteilt, was auf eine totale Verplanung der Zeit und 
Atomisierung der Aufgaben rausläuft bei gleichzeitigen Verlust der Sicht 
auf das Ganze.

Ein Bürokratiemonster, das von der Arbeit ablenkt. Ein Versuch, der 
BWLer, den Techies ihre Arbeitsmethoden aufzuzwingen. Vielleicht ist es 
ganz gut für Junioren, die an die Hand genommen werden wollen und eine 
Struktur brauchen.

von Franko S. (frank_s866)


Lesenswert?

Joe schrieb:
> Das Paradoxe für mich und meine kleine Welt ist aber das, was ich weiter
> oben beschrieben habe: es wird die Arbeit immer in sprint-gerechte
> Häppchen zerteilt, was auf eine totale Verplanung der Zeit und
> Atomisierung der Aufgaben rausläuft bei gleichzeitigen Verlust der Sicht
> auf das Ganze.
Die Coder sollen ihre Häppchen runtertippen und gar nicht mehr wissen, 
so bleiben sie schnell austauschbar, wie eine Fliessbanddrohne. Das war 
das Ziel bei dem Ganzen.

von Joe (jowu)


Lesenswert?

Franko S. schrieb:
> Die Coder sollen ihre Häppchen runtertippen und gar nicht mehr wissen,
> so bleiben sie schnell austauschbar, wie eine Fliessbanddrohne. Das war
> das Ziel bei dem Ganzen.

Ich würde nicht sagen, daß Agile von Anfang so gemeint war. Es ist m.E. 
eher so, daß ein für bestimmte Situationen hervorragend geeignetes 
Arbeitskonzept irgendwann von BWLern übernommen wurde, um die Techies 
einzuspannen und zu kontrollieren.

Daß der unersetzbare Technik-Mitarbeiter (aka "Diva") der Alptraum eines 
jeden Unternehmers ist, ist sicherlich eine Triebfeder beidem Ganzen. 
Deshalb versucht man, persönliches Know-How so weit wie möglich durch 
Prozesse  zu ersetzen. Nach dem Motto: Wenn im 5-Sterne-Restaurant ein 
Koch geht, ist es eine Katastrophe, den Mc Donald´s hingegen juckt das 
nicht.

https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
"Wenn Sie sich Scrum ansehen, ist es so konzipiert, die erfahrenen, 
fähigsten Ingenieure zu enteignen, indem diese sich an Prozesse halten 
müssen (nur an Backlog-Elementen arbeiten, 5-10 Stunden pro Woche in 
Statusbesprechungen verbringen), die für Leute gedacht sind, die erst 
letzten Monat mit dem Schreiben von Code begonnen haben.

Wie ein gescheiterter kommunistischer Staat, der alle gleich macht, 
indem er Armut verbreitet, stellt Scrum in seiner reinsten Form das 
gesamte Engineering auf das gleiche niedrige Niveau: nicht auf ein klar 
definiertes, aber klar auf eines unter all den Geschäftsleuten, welchen 
die volle Autorität gegeben wird, zu entscheiden, woran gearbeitet wird.

Agile, wie es oft implementiert wird, erhöht die Feedback-Frequenz, 
während es den Ingenieuren keine wirkliche Macht gibt. Das ist ein 
verlorenes Geschäft, denn es bedeutet, dass sie eher herumgerissen oder 
bestraft werden, wenn die Dinge länger dauern, als sie "scheinen" 
dauern. Das sorgt für viel Angst und Eile, aber es gibt wenig von dem, 
was wirklich zählt: exzellente Produkte zu entwickeln."

von Franko S. (frank_s866)


Lesenswert?

Joe schrieb:
> Ich würde nicht sagen, daß Agile von Anfang so gemeint war. Es ist m.E.
> eher so, daß ein für bestimmte Situationen hervorragend geeignetes
> Arbeitskonzept irgendwann von BWLern übernommen wurde, um die Techies
> einzuspannen und zu kontrollieren.

Google mal nach "Kopfmonopole" beseitigen/abbauen/aufbrechen. SCRUM ist 
das selbe nur mit anderem Namen. Change Management, Wissensmanagment,... 
ist alles der selbe Dreck mit dem gleich Ziel. Da soll keiner zu wichtig 
werden, sonst könnte der noch Forderungen stellen und einem auf der Nase 
rumtanzen. Dann sagt der der Führungswurst auch noch wie und was zu 
machen ist, das geht ja gar nicht. Man will viele austauschbare Sklaven.

von Michael B. (laberkopp)


Lesenswert?

Cyblord -. schrieb:
> Komplett verquere Ansicht wenn man bedenkt was er bisher mit SpaceX
> erreicht hat. Allein die Booster Landungen sind ein reines Wunder.

SoaceX wurde durch einen Helden möglich, und der hiess nicht Musk, von 
dem kam nur die Anschubfinanzierung, sondern Thomas John Mueller.

Seit dem er weg ist (Einführung von Scrum?), klappt nicht mehr so viel.

Die Triebwerke, die gebremste Landung, sind seine Kinder.

von Cyblord -. (cyblord)


Lesenswert?

Michael B. schrieb:
> Cyblord -. schrieb:
>> Komplett verquere Ansicht wenn man bedenkt was er bisher mit SpaceX
>> erreicht hat. Allein die Booster Landungen sind ein reines Wunder.
>
> SoaceX wurde durch einen Helden möglich, und der hiess nicht Musk, von
> dem kam nur die Anschubfinanzierung, sondern Thomas John Mueller.
>
> Seit dem er weg ist (Einführung von Scrum?), klappt nicht mehr so viel.
>
> Die Triebwerke, die gebremste Landung, sind seine Kinder.

Na und? Der Chef ist verantwortlich. Wenn es klappt oder wenn es schief 
geht. Dass der Chef nichts selber macht sollte klar sein und ist immer 
so.

von Udo S. (urschmitt)


Lesenswert?

Joe schrieb:
> Daß der unersetzbare Technik-Mitarbeiter (aka "Diva") der Alptraum eines
> jeden Unternehmers ist, ist sicherlich eine Triebfeder beidem Ganzen.
> Deshalb versucht man, persönliches Know-How so weit wie möglich durch
> Prozesse  zu ersetzen. Nach dem Motto: Wenn im 5-Sterne-Restaurant ein
> Koch geht, ist es eine Katastrophe, den Mc Donald´s hingegen juckt das
> nicht.

Hätte man gerne. Nur wird vergessen, dass diese "unersetzbaren 
Technik-Mitarbeiter" deshalb unsersetzbar sind, weil sie Know how haben, 
das man nicht in 2 x 8h an irgendeinen Inder weitergeben kann.
Das verstehen aber nur Unternehmer, die selbst mal Technik-Mitarbeiter 
waren.

Dein Beispiel passt. Statt Hightech Schmiede / "Hidden Champion" 
(5-Sterne-Restaurant) wird dann halt eine Allerweltsbude mit sehr 
durchschnittlichen Produkten (Mc Donalds)

Deinen unteren Absätzen stimme ich zu. Nach unserer letzten 
Firmenübernahme sind wir da gerade voll drin.

: Bearbeitet durch User
von Joe (jowu)


Lesenswert?

Udo S. schrieb:
> Hätte man gerne. Nur wird vergessen, dass diese "unersetzbaren
> Technik-Mitarbeiter" deshalb unsersetzbar sind, weil sie Know how haben,
> das man nicht in 2 x 8h an irgendeinen Inder weitergeben kann.
> Das verstehen aber nur Unternehmer, die selbst mal Technik-Mitarbeiter
> waren.

ACK. Tragisch.

Ich kann dazu nur zu Erbauung einen Autor empfehlen, der mit Witz die 
Thematik beschreibt:
Gunter Dueck
Heute schon einen Prozess optimiert?
Das Management frisst seine Mitarbeiter
Erscheinungstermin: 12.02.2020
ISBN 9783593510842

https://www.campus.de/uploads/tx_campus/leseproben/9783593510842.pdf

"In die Sackgasse der Inkompetenz – Menschmaschinen
statt Zukunftsbauer

In diesem Kapitel führe ich in erste wichtige Gedanken ein, die im 
weiteren Verlauf des Buches noch detaillierter ausgeführt werden. Wenn
das Management unsere Arbeit durch Digitalisierung rücksichtslos
automatisieren und beschleunigen will, dann gibt es diese 
Folgewirkungen:

• Man betreibt so starke Arbeitsverdichtung, dass die Menschen wie
Fließbandarbeiter nur noch durch das Tagesgeschäft hetzen. Zum
Lernen und damit für die Zukunft bleibt einfach keine Zeit, sogar das 
normale Nachdenken ist unter solchem Stress kaum noch
möglich.

• Man versucht, immer mehr Arbeit in computerisierte Prozesse
einzubetten, sodass die Arbeitskräfte möglichst wenig selbst zu
entscheiden haben und nur noch Bedienungspersonal optimierter
Prozesse werden.

• Man strebt an, die Menschen bei der Arbeit fast beliebig austauschbar 
zu machen (Crews im Luftverkehr und bei der Bahn,
Call-Center, Personal im Einzelhandel, Leiharbeiter, Berater) – wir
als Kunden haben es dann nur noch mit immer anderen Arbeitskräften zu 
tun, die uns gegenüber eine immer unpersönlichere
Rolle einnehmen; menschliche Beziehungen sind nicht mehr nötig und auch 
nahezu unmöglich; die Mitarbeiter kommen quasi
»aus der Cloud«, sie kommunizieren in vorgeschriebenen Floskeln
(»Crew, prepare for landing«)"

von Rudi R. (rudi_r)


Lesenswert?

Joe schrieb:
> Das war ungefähr die Zeit, als Rudi hier den Thread angefangen hat. Und
> auch die Zeit, wo ich das googeln zum Thema angefangen habe:
>
> 
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

Sehr guter Essay. Ich habe ihn kopfnickend gelesen, weil vieles auch 
meinen gemachten Erfahrungen entspricht.

Udo S. schrieb:
> Hätte man gerne. Nur wird vergessen, dass diese "unersetzbaren
> Technik-Mitarbeiter" deshalb unsersetzbar sind, weil sie Know how haben,
> das man nicht in 2 x 8h an irgendeinen Inder weitergeben kann.
> Das verstehen aber nur Unternehmer, die selbst mal Technik-Mitarbeiter
> waren.

So ist es. Manche glauben, es gäbe eine Abkürzung, um Kenntnisse zu 
erwerben. Aber der harte Weg ist:

1. Lesen.
2. Nachdenken.
3. Ausprobieren.
4. Schlussfolgerungen ziehen.
5. Schreite zu Punkt 1.

Und diese Iteration macht man ein paar tausend Male. Softwareentwicklung 
ist eine Fähigkeit, die man nicht nebenbei erlernt. Man muss schon tief 
hinabtauchen, wie ein Profimusiker. Bei Musikern ist man sich einig, 
dass derjenige keine Chance auf ein Platz im Orchester haben kann, wenn 
er nicht schon in jungen Jahren viel geübt hat. Bei Softwareentwicklern 
jedoch glaubt man, alle über einen Kamm zu scheren.


Ich habe vor etwas mehr als ein Jahr im Projekt erzählt, ich hätte ein 
tolles Framework, das uns die Arbeit bei Simulation & Test stark 
beschleunigt. Ich hatte es im Projekt auch schon verwendet. Nun wollten 
die eine Einführung haben. Es war ein Donnerstagnachmittag: "Kannst du 
uns morgen vormittag eine Einführung geben?" - Das waren Entwickler, die 
recht schwachen Code bis dato ablieferten, wollten aber mit meinem 
Framework, arbeiten, das dadurch Gewinn zieht, dass abstrahiert wird, 
dass eine Groovy-DSL viel Boilerplate-Code versteckt und die Sachen 
elegant aussehen lässt. Ich war nicht in der Lage, so schnell zu liefern 
und weigerte mich regelrecht, weil es war meine kostbare Zeit und ich 
hätte die Mühe auch vergebens gefunden.

Ich kann natürlich verstehen, dass die Unternehmensleitungen sich nicht 
zu sehr abhängig machen wollen von einigen wenigen. Aber es ist selten 
so, dass diese Schlauköpfe um sich beißen und nichts hergeben wollen. Im 
Gegenteil: Sie sind ja gerade deshalb so gut, weil sie technisch 
interessiert sind, weil sie die Software so konstruieren, dass geeignete 
Abstraktionen es am Ende leichter werden handhaben lassen. Ich bin so 
ein Schlaukopf. Ich habe vor vielen Jahren mal - ich glaube bei Paul 
Graham - gelesen, dass sehr gute Entwickler irgendwann Programme 
schreiben, die Programme schreiben. Da bin ich eigentlich schon lange. 
DSLs schreibe ich seit etlichen Jahren; das geht ja in diese Richtung.

Michael B. schrieb:
> SoaceX wurde durch einen Helden möglich, und der hiess nicht Musk, von
> dem kam nur die Anschubfinanzierung, sondern Thomas John Mueller.
>
> Seit dem er weg ist (Einführung von Scrum?), klappt nicht mehr so viel.
>
> Die Triebwerke, die gebremste Landung, sind seine Kinder.


Wurde Scrum eingeführt? Ich kann mir nicht vorstellen, dass Elon selbst 
viel von Scrum hält.

von Joe (jowu)


Lesenswert?

Rudi R. schrieb:
> 
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/

> Sehr guter Essay. Ich habe ihn kopfnickend gelesen, weil vieles auch
> meinen gemachten Erfahrungen entspricht.

Absolut. Für mich war er wie Medizin zu lesen, weil er brillant 
beschrieben ist, was mir so durch den Kopf ging:

"...Wenn Ihr Unternehmen dazu bestimmt ist, geschäftsorientiert zu sein, 
ist das in Ordnung. Stellen Sie jedoch keine Vollzeit-Ingenieure ein, 
wenn Sie Talente suchen. Sie können die besten Leute als Berater 
bekommen (beginnend im Bereich von 200 US-Dollar pro Stunde und von dort 
aus steil nach oben), aber nicht als Vollzeitbeschäftigte in einem 
geschäftsorientierten Unternehmen. Gute Ingenieure wollen in 
ingenieurgesteuerten Unternehmen arbeiten, in denen sie das Sagen haben, 
woran gearbeitet wird, ohne sich vor "Scrum Mastern" und "Product 
Ownern" und Schichten des nicht-technischen Managements rechtfertigen zu 
müssen.
(...)
Die ständige Überwachung der eigenen Arbeit deutet auf einen Mangel an 
Vertrauen und einen niedrigen sozialen Status hin, und die 
statussensibelsten Menschen (selbst wenn sie die besten Arbeitskräfte 
sind) sind die ersten, die ablehnen, wenn die Überwachung zunimmt. Wenn 
sie das Gefühl haben, dass ihnen nicht vertraut wird (und was wird sonst 
noch von einer Kultur kommuniziert, die erwartet, dass jede Arbeit 
rechtfertigt werden muß?), dann verlieren sie schnell die Motivation."

> Ich kann natürlich verstehen, dass die Unternehmensleitungen sich nicht
> zu sehr abhängig machen wollen von einigen wenigen. Aber es ist selten
> so, dass diese Schlauköpfe um sich beißen und nichts hergeben wollen. Im
> Gegenteil: Sie sind ja gerade deshalb so gut, weil sie technisch
> interessiert sind, weil sie die Software so konstruieren, dass geeignete
> Abstraktionen es am Ende leichter werden handhaben lassen.

Die "Nerds" haben ja das Mindset, daß sie alles, was sie können und 
wissen, mit Freude teilen. Ihnen fehlt geradezu das "Business-Gen", aus 
dem Wissensmonopol finanziell zu profitieren.

Ich habe mal "Kopfmonopol" gegoogelt, und es ist grauenhaft, wie da 
manche ihr Geld verdienen:
https://www.klaus-nitsche.de/kopfmonopole-so-schaffen-sie-abhilfe/
"Bestehende Kopfmonopole bauen wir so ab:
Die Aufgaben der betroffenen Person sofort 
reduzieren/wegpriorisieren..."

Wenn eine "betroffene Person" ihre Aufgaben reduziert/wegpriorisiert 
bekommt (weil ein Unternehmensberater das vorgeschlagen hat) , und nicht 
zu dumm ist, das zu merken, dann wird sie sich zeitnah verabschieden.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Ich würde nicht sagen, daß Agile von Anfang so gemeint war. Es ist m.E.
> eher so, daß ein für bestimmte Situationen hervorragend geeignetes
> Arbeitskonzept irgendwann von BWLern übernommen wurde, um die Techies
> einzuspannen und zu kontrollieren.

Deswegen haben Betriebswirte in der Veranstaltung auch nichts zu suchen.

> Daß der unersetzbare Technik-Mitarbeiter (aka "Diva") der Alptraum eines
> jeden Unternehmers ist, ist sicherlich eine Triebfeder beidem Ganzen.

Eine Triebfeder bei den Übernahmeversuchen, aber sicher nicht beim 
Konzept. Hinter dem Konzept stehen dann nämlich auch keine 
Betriebswirte, sondern (mitunter bekannte, erfahrene und verdiente) 
Techniker wie Kent Beck.

Daß die Konzepte oft, wenn nicht sogar meistens falsch umgesetzt werden, 
sagt ja sogar eine der von Dir zitierten Quellen. Das kann man aber 
seriöserweise nicht den Konzepten vorwerfen. Ebensowenig kann man den 
Konzepten vorwerfen, daß sie mitunter von unangenehmen und / oder 
inkompetenten Menschen beworben und / oder realisiert werden.

Wie auch immer: Du wirst mich nicht überzeugen, denn ich arbeite gerne 
mit agilen Methoden und habe damit deutlich bessere Erfahrungen gemacht 
als mit den klassischen. Andererseits werde ich auch Dich nicht 
überzeugen -- daher müssen wir uns wohl darauf einigen, uns nicht 
einigen zu können. :-)

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Ich habe vor etwas mehr als ein Jahr im Projekt erzählt, ich hätte ein
> tolles Framework, das uns die Arbeit bei Simulation & Test stark
> beschleunigt. Ich hatte es im Projekt auch schon verwendet. Nun wollten
> die eine Einführung haben. Es war ein Donnerstagnachmittag: "Kannst du
> uns morgen vormittag eine Einführung geben?" - Das waren Entwickler, die
> recht schwachen Code bis dato ablieferten, wollten aber mit meinem
> Framework, arbeiten, das dadurch Gewinn zieht, dass abstrahiert wird,
> dass eine Groovy-DSL viel Boilerplate-Code versteckt und die Sachen
> elegant aussehen lässt. Ich war nicht in der Lage, so schnell zu liefern
> und weigerte mich regelrecht, weil es war meine kostbare Zeit und ich
> hätte die Mühe auch vergebens gefunden.

Ich weiß ja nicht, Rudi, aber irgendwie bekomme ich bei Deinen 
Ausführungen ziemlich häufig irgendwie... Bauchweh. Kaum eines kommt 
ohne den Hinweis aus, was für ein toller Überentwickler Du bist, und daß 
Deine Kollegen so unfähig sind, daß Du nicht einmal mit ihnen 
kommunizieren kannst. Warum arbeitest Du denn mit solchen Stümpern? Mit 
Deinen Fähigkeiten solltest Du doch jederzeit in der Lage sein, Dir ein 
Arbeitsumfeld zu suchen, in dem Deine Leistungen verstanden, anerkannt 
und gewürdigt werden, und in dem Du nicht vornehmlich von inkompetenten 
Kollegen umgeben (und genervt) bist.

Hier baust Du jetzt irgendeine Supersoftware und benutzt sie sogar in 
einem Projekt, willst sie Deinen Kollegen aber nicht erklären, weil sie 
"bis dato recht schwachen Code ablieferten", Du "die Mühe [...] 
vergebens gefunden" hättest, und "nicht so schnell zu liefern" imstande 
gewesen wärest.

Wenn ich diese Aussagen einmal in meine Arbeitsumfelder hinein denke... 
dann ist da etwas vollkommen anderes kaputt, und das hat nichts mit 
irgendwelchen Modellen zu tun. Kannst Du in Deinem Arbeitsumfeld nicht 
sagen "ich hab viel zu tun und schaffe es nicht bis morgen Vormittag, 
das vorzubereiten" und "es ist ausgesprochen komplex und erfordert 
umfangreiche Vorkenntnisse, die ich zuerst vermitteln müßte"? Was ist 
das für ein merkwürdiges Arbeitsumfeld, in dem man so etwas nicht einmal 
als Senior sagen kann? Und was ist das für ein Senior, der das nicht 
sagen kann? Das erscheint mir doch alles irgendwie... sagen wir mal: 
merkwürdig.

Ich weiß auch nicht, wie es um den mittel- und langfristigen Bestand 
eines Unternehmens bestellt ist, wenn dort ein Einzelner sein eigenes 
Ding macht, das er seinen Kollegen nicht erklären will. Vielleicht komme 
ich da zu sehr von der Sysop-Seite, aber bei meinen Arbeitgebern habe 
ich immer laut und deutlich darauf bestanden, wie extrem wichtig es ist, 
daß mich jemand mit ökonomisch vertretbarem Aufwand ersetzen kann. Denn 
ich möchte ja auch mal einen längeren Urlaub machen, oder womöglich 
krank werden dürfen, aber dann hinterher immer noch ein Unternehmen 
vorfinden, das nicht nur meine Brötchen bezahlen kann, sondern auch 
keine technischen Schulden angehäuft hat.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Deswegen haben Betriebswirte in der Veranstaltung auch nichts zu suchen.

Das ist ja richtig als normative Aussage, aber: es wird m.E. in den 
meisten Fällen das Agile vom Management oktroyiert (ich habe leider 
keine empirischen Quellen mit Zahlen dazu). Es existiert gar eine ganze 
Branche ("agil industrieller Komplex"), wo, meine ich, auch vor allem 
Betriebswirte und vielleicht ein paar (Halb-)Techies mit Business-Gen 
sich rumtreiben. In dem Metier fühlen sich Betriebswirte zuhause wie der 
Fisch im Wasser, manches ist verwandt mit dem "Scientific Management" 
von Frederic Taylor. Polemisch gesagt, sind Scrum, User Stories und 
Sprints das Geschirr, das dem Techie angelegt wird.

> Wie auch immer: Du wirst mich nicht überzeugen, denn ich arbeite gerne
> mit agilen Methoden und habe damit deutlich bessere Erfahrungen gemacht
> als mit den klassischen. Andererseits werde ich auch Dich nicht
> überzeugen -- daher müssen wir uns wohl darauf einigen, uns nicht
> einigen zu können. :-)

Da bin ich wie der DDR-Bürger, dem die Vorzüge des Sozialismus gepriesen 
werden...

Ich kann Dir nur sagen, daß das, was Du schreibst, sich streckenweise 
wie ein Katechismus, wie aus dem Glaubenslehrbuch, liest, und nicht 
analytisch ist. So wie ein Sozialist, der, konfrontiert mit den 
menschenverachtenden Auswüchsen des Kommunismus, anfängt, Marx und Lenin 
zu zitieren. Oder ein Christ, der, konfrontiert mit den Gräueln, welche 
die Geschichte des Christentums durchziehen, anfängt, die Bergpredigt zu 
rezitieren.

Ich bin nicht so vermessen, Dich überzeugen zu wollen - das wäre völlig 
unrealistisch. So wie es sicherlich noch nie passiert ist, daß einer den 
Zeugen Jehovas an der Haustür zu sich auf eine Tasse Kaffee 
hereingeladen hat, um ihn dann einige Zeit später bekehrt wieder zu 
verabschieden. :-)

von Rudi R. (rudi_r)


Lesenswert?

Sheeva P. schrieb:
> Kannst Du in Deinem Arbeitsumfeld nicht
> sagen "ich hab viel zu tun und schaffe es nicht bis morgen Vormittag,
> das vorzubereiten" und "es ist ausgesprochen komplex und erfordert
> umfangreiche Vorkenntnisse, die ich zuerst vermitteln müßte"? Was ist
> das für ein merkwürdiges Arbeitsumfeld, in dem man so etwas nicht einmal
> als Senior sagen kann? Und was ist das für ein Senior, der das nicht
> sagen kann? Das erscheint mir doch alles irgendwie... sagen wir mal:
> merkwürdig.

Die Antwort darauf ist ganz einfach: Die Leute müssen selbst erkennen, 
dass man sowas nicht mal eben aus dem Ärmel schüttelt und dass es 
Vorkenntnisse benötigt. Die Erstsemester in Medizin verlangen doch auch 
nicht, dass die Operation am Herzen morgen demonstriert wird.

Ich erkläre meine Sachen gerne. Aber es gehört auch die Anerkennung 
dazu, dass ich nicht innerhalb von wenigen Arbeitsstunden etwas 
vorbereiten kann, wenn ich doch mit so viel anderen Zeug belastet bin. 
Ich habe es als Affront empfunden. Das Framework fand Eingang ins 
Projekt und ich nutzte es auch gewinnbringend.

Ich habe einige gute Lösungen, die immer wieder firmenintern nachgefragt 
werden. Ich erwarte aber auch, sich das Hineinversetzen in Lösungen, was 
auch etwas Aufwand benötigt. Aber man muss diese Hürde nehmen, es 
verstehen zu wollen. Man kommt nicht drumherum.

Sheeva P. schrieb:
> Kannst Du in Deinem Arbeitsumfeld nicht
> sagen "ich hab viel zu tun und schaffe es nicht bis morgen Vormittag,
> das vorzubereiten" und "es ist ausgesprochen komplex und erfordert
> umfangreiche Vorkenntnisse, die ich zuerst vermitteln müßte"? Was ist
> das für ein merkwürdiges Arbeitsumfeld, in dem man so etwas nicht einmal
> als Senior sagen kann?

Das habe ich denen gesagt. Ein Problem hierbei: Die betreffenden 
Entwickler hatten bei den einfachsten Dingen ihre lieben 
Schwierigkeiten. Die haben in den Wochen zuvor meine Hinweise ignoriert. 
Beispielsweise haben sie SQL-Anweisungen in Strings gepackt und an 
Hibernate vorbei die Persistenz erledigt. Da ich da aber schon auf taube 
Ohren stieß und die Projektleitung mir nicht beisprang, sah ich den 
Nutzen, denen meinen Framework zu erklären, als sehr gering an. Das Team 
wurde später komplett ausgetauscht, nach meinen Hinweisen, dass das 
gründlich schief gehen würde. Wir hatten eine Scrum-Masterin, die mich 
ständig  vollgesülzt hat, aber nicht von sich aus erkannt hat, dass 
architektonisch 'ne Menge falsch läuft. Bei mir schrillen die 
Alarmglocken, wenn ich SQL-Code in Java-Code eingebettet sehe. Wichtige 
Hinweise von mir wurden ignoriert, obwohl man mich als Hilfe anforderte. 
Gleichzeitig wurde Code von mir nicht genehmigt, weil ich da 
irgendwelche Code-Style nicht einhielt.

Ich zitiere mal die Wikipedia: "Ein Scrum Master ist gegenüber dem 
Entwicklungsteam eine dienende Führungskraft.[38] Er gibt einzelnen 
Team-Mitgliedern keine Arbeitsanweisungen. Weder beurteilt er sie, noch 
belangt er sie disziplinarisch.[39] Der Scrum Master ist als Coach für 
den Prozess und die Beseitigung von Hindernissen verantwortlich. 
Unterschiedliche Teams und Situationen erfordern vom Scrum Master ein 
situatives Führen."

Also kümmert sich diese Person nur um die Prozess. Aber was beurteilt 
sie nicht?  Das Arbeitsergebnis? Die Softwarearchitektur? Fragt man man 
Menschen mit gesunden Menschenverstand, woran man denn erkennen können, 
ob der Prozess läuft oder nicht, würde man zu hören bekommen: "Das sieht 
man doch am Arbeitsergebnis!" Die Scrum-Masterin hat ihre Rolle so 
interpretiert, dass der Code sie nichts angehe. Das Arbeitsergebis hat 
sie nicht interessiert. Qualitative Aspekte blieben auf der Strecke. Die 
Frau hat übrigens gekündigt oder ihr wurde nahegelegt, zu kündigen. So 
genau weiß ich das nicht.



Sheeva P. schrieb:
> Ich weiß auch nicht, wie es um den mittel- und langfristigen Bestand
> eines Unternehmens bestellt ist, wenn dort ein Einzelner sein eigenes
> Ding macht, das er seinen Kollegen nicht erklären will.

Ich erkläre doch meine Sachen. Aber nicht zwischen Tür und Angel.

Sheeva P. schrieb:
> Wie auch immer: Du wirst mich nicht überzeugen, denn ich arbeite gerne
> mit agilen Methoden und habe damit deutlich bessere Erfahrungen gemacht
> als mit den klassischen. Andererseits werde ich auch Dich nicht
> überzeugen -- daher müssen wir uns wohl darauf einigen, uns nicht
> einigen zu können. :-)

Es geht um Scrum und nicht um Agilität. Wenn ich mit das agile Manifest 
durchlese und mit der gelebten Scrum-Praxis vergleiche, dann ist Scrum 
ein enges Korsett, nichts agiles.

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> Es geht um Scrum und nicht um Agilität. Wenn ich mit das agile Manifest
> durchlese und mit der gelebten Scrum-Praxis vergleiche, dann ist Scrum
> ein enges Korsett, nichts agiles.

Kommunisten/Scrum-Guru Antwort: Ja dann hast du Scrum falsch angewendet, 
nicht verstanden. Der Scrum Scharlatan äh Master deiner Wahl erklärt dir 
das sicher nochmal, für viel Geld.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Sheeva P. schrieb:
>
>> Deswegen haben Betriebswirte in der Veranstaltung auch nichts zu suchen.
>
> Das ist ja richtig als normative Aussage, aber: es wird m.E. in den
> meisten Fällen das Agile vom Management oktroyiert

Vielleicht ist es ja der große Unterschied zwischen uns, daß das bei mir 
nicht so gewesen ist. Bei uns hat sich das Team zusammengesetzt und 
überlegt wie wir besser zusammenarbeiten können.

> Es existiert gar eine ganze Branche

Ja, keine Frage. Das war aber auch schon bei der Objektorientierung so, 
als plötzlich ein Haufen Nichtentwickler herumgelaufen ist und allen 
Leuten, die nicht schnell genug geflohen waren, erklärt hat, wie toll 
OOP ist.

Andererseits frage ich mich, ob das ein seriöses Argument ist. Daß bei 
jeder nützlichen -- und auch vielen unnützen -- Dingen eine ganze 
Industrie daraus bildet, die dabei Gelder abgreifen will, ist ja nun 
nichts Neues.

> ("agil industrieller Komplex")

Warst es nicht Du, der...

> Polemisch gesagt, sind Scrum, User Stories und
> Sprints das Geschirr, das dem Techie angelegt wird.

... auf die Spitzen verzichten wollte?

> Ich kann Dir nur sagen, daß das, was Du schreibst, sich streckenweise
> wie ein Katechismus, wie aus dem Glaubenslehrbuch, liest, und nicht
> analytisch ist. So wie ein Sozialist, der, konfrontiert mit den
> menschenverachtenden Auswüchsen des Kommunismus, anfängt, Marx und Lenin
> zu zitieren. Oder ein Christ, der, konfrontiert mit den Gräueln, welche
> die Geschichte des Christentums durchziehen, anfängt, die Bergpredigt zu
> rezitieren.

Das Lustigste an Deinen Ausführungen ist, daß der Sozialismus 
tatsächlich funktionieren kann, zum Beispiel in israelischen Kibbutzen. 
Der wesentliche Unterschied zum staatlich erzwungenen Sozialismus ist: 
dort können die Leute nämlich freiwillig ein- und austreten. :-)

Nur geringfügig weniger lustig ist, daß es Du ja ausgerechnet Du bist, 
der unbedingt einen Fünfjahresplan, vulgo eine bereits vor der 
Implementierung festgezurrte Detailplanung haben will, während mir 
kapitalistische, mithin: vergleichsweise grobe, dafür aber 
anpassungsfähige Steuerungen lieber sind, auch wenn sie die Gefahr des 
teilweisen Scheiterns bergen. :-)

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Die Antwort darauf ist ganz einfach: Die Leute müssen selbst erkennen,
> dass man sowas nicht mal eben aus dem Ärmel schüttelt und dass es
> Vorkenntnisse benötigt.

Können sie das denn selbst erkennen? Wie sollten sie das erkennen, wenn 
sie nicht einmal wissen, was Du vorstellen sollen würdest? Woher?

> Die Erstsemester in Medizin verlangen doch auch
> nicht, dass die Operation am Herzen morgen demonstriert wird.

Ach, Rudi... bei einer Herzoperation wissen wir alle, daß die 
hochkomplex und gleichzeitig lebensbedrohlich ist, aber bei einer 
unbekannten DSL?

> Ich habe es als Affront empfunden.

Nur so eine Vermutung, aber: ist vielleicht genau das das Problem? Und: 
was hat das mit dem Modell zu tun?

> Das habe ich denen gesagt. Ein Problem hierbei: Die betreffenden
> Entwickler hatten bei den einfachsten Dingen ihre lieben
> Schwierigkeiten. Die haben in den Wochen zuvor meine Hinweise ignoriert.
> Beispielsweise haben sie SQL-Anweisungen in Strings gepackt und an
> Hibernate vorbei die Persistenz erledigt. Da ich da aber schon auf taube
> Ohren stieß und die Projektleitung mir nicht beisprang, sah ich den
> Nutzen, denen meinen Framework zu erklären, als sehr gering an.

Du warst / bist verletzt, weil sie Deine Hinweise ignoriert haben.

> Wir hatten eine Scrum-Masterin, die mich
> ständig  vollgesülzt hat, aber nicht von sich aus erkannt hat, dass
> architektonisch 'ne Menge falsch läuft.

Das ist ja auch nicht ihre Aufgabe.

> Bei mir schrillen die
> Alarmglocken, wenn ich SQL-Code in Java-Code eingebettet sehe.

Ach, kommt drauf an. Normalerweise ist sowas Unfug, aber manchmal ist 
das notwendig, um die Limitierungen des ORM zu umgehen, oder um die 
Performance und / oder Verständlichkeit von sehr komplexen Queries 
verbessern. Window Functions zum Beispiel konnte Hibernate früher ja 
AFAIK nicht so richtig.

> Gleichzeitig wurde Code von mir nicht genehmigt, weil ich da
> irgendwelche Code-Style nicht einhielt.

Komisch, unsere Java-Leute haben ihre Entwicklungsumgebungen so 
eingerichtet, daß bei jedem Commit ein Stylechecker und / oder 
Formatierer über den Code laufen. Gibt es so etwas bei Euch etwa nicht?

> Die Scrum-Masterin hat ihre Rolle so
> interpretiert, dass der Code sie nichts angehe. Das Arbeitsergebis hat
> sie nicht interessiert. Qualitative Aspekte blieben auf der Strecke.

Richtig so. Denn ihre Aufgabe war es, sich um die Zusammenarbeit im Team 
zu kümmern. Hat man Dir das nicht gesagt? Hast Du Dich nie gefragt?

> Ich erkläre doch meine Sachen. Aber nicht zwischen Tür und Angel.

In Deinem vorherigen Beitrag hat sich das anders gelesen, nämlich für 
mich nach einem massiven Kommunikationsproblem mindestens in Eurem Team.

> Es geht um Scrum und nicht um Agilität. Wenn ich mit das agile Manifest
> durchlese und mit der gelebten Scrum-Praxis vergleiche, dann ist Scrum
> ein enges Korsett, nichts agiles.

Von wegen. :-)

von Rudi R. (rudi_r)


Lesenswert?

Sheeva P. schrieb:
> Ja, keine Frage. Das war aber auch schon bei der Objektorientierung so,
> als plötzlich ein Haufen Nichtentwickler herumgelaufen ist und allen
> Leuten, die nicht schnell genug geflohen waren, erklärt hat, wie toll
> OOP ist.
>
> Andererseits frage ich mich, ob das ein seriöses Argument ist. Daß bei
> jeder nützlichen -- und auch vielen unnützen -- Dingen eine ganze
> Industrie daraus bildet, die dabei Gelder abgreifen will, ist ja nun
> nichts Neues.

Guter Vergleich. Ich bin zwar zu jung, um die 90er als Berufsentwickler 
miterlebt zu haben, aber so stelle ich es mir vor, dass da 
Schlangenölverkäufer als OOP-Consultants herumliefen.

Mit den Ergebnissen muss man aber bis heute leben. Viele haben 
Objektorientierung nicht endgültig verstanden. Man merkt richtig, dass 
da im Gehirn ein Mischmasch aus imperativer Programmierung, relationalen 
Datenbanken und objektorientierten Konzepten vorherrscht. Manche fangen 
auch erst an objektorientierte Datenstrukturen zu entwickeln, wenn das 
Zeug wirklich in einer DB persistiert wird. Dass man kleine 
objektorientierte Strukturen aufbaut, um ein algorithmisches Problem zu 
lösen, das gibt's bei denen nicht. Sehe ich bei vielen Kollegen, dass 
die das nicht machen.

Ich habe auch schon um das Jahr 2002 herum (da machte ich Abitur), dass 
man manchen die Vorstellung vorherrscht, objektorientierte 
Programmierung sei irgendwas mit graphischen Benutzeroberfläschen, mit 
Widgets. Das kam offensichtlich so rüber, als der Hype in den 90ern auf 
dem Höhepunkt war.

Sheeva P. schrieb:
> Rudi R. schrieb:
>> Die Antwort darauf ist ganz einfach: Die Leute müssen selbst erkennen,
>> dass man sowas nicht mal eben aus dem Ärmel schüttelt und dass es
>> Vorkenntnisse benötigt.
>
> Können sie das denn selbst erkennen? Wie sollten sie das erkennen, wenn
> sie nicht einmal wissen, was Du vorstellen sollen würdest? Woher?

Ich hatte es ja mal demonstriert anhand eines anderes Projektes. Die 
wollten 'ne Einführung, wie man es verwendet.

Sheeva P. schrieb:
> Ach, Rudi... bei einer Herzoperation wissen wir alle, daß die
> hochkomplex und gleichzeitig lebensbedrohlich ist, aber bei einer
> unbekannten DSL?

Zu komplex, um es mal eben in 45 min durchzuexerzieren, dass sie es 
verwenden können.

Sheeva P. schrieb:
> Du warst / bist verletzt, weil sie Deine Hinweise ignoriert haben.

Ich war nicht verletzt, sondern entsetzt und genervt.

Sheeva P. schrieb:
> Ach, kommt drauf an. Normalerweise ist sowas Unfug, aber manchmal ist
> das notwendig, um die Limitierungen des ORM zu umgehen, oder um die
> Performance und / oder Verständlichkeit von sehr komplexen Queries
> verbessern. Window Functions zum Beispiel konnte Hibernate früher ja
> AFAIK nicht so richtig.

Es war in diesem Falle Unfug, weil es triviale Dinge waren. Besondere 
Performanzanforderungen gab es auch nicht.

Sheeva P. schrieb:
> Komisch, unsere Java-Leute haben ihre Entwicklungsumgebungen so
> eingerichtet, daß bei jedem Commit ein Stylechecker und / oder
> Formatierer über den Code laufen. Gibt es so etwas bei Euch etwa nicht?

Ich halte es für relativ unwichtig. In diesem konkreten Falle war es 
alter Code, der auskommentiert wurde. Die Scrum-Masterin wollte aber, 
dass es gelöscht wird. Also nichts funktionales, wenig relevant. 
Gleichzeitig nahm sie die SQL-Geschichten in Java-Strings hin. Mir 
geht's um die Prioritätensetzung. Man muss erkennen, dass man bei dem 
SQL-Zeug in Java-Strings sofort gegensteuern muss, wenn es mit Hibernate 
erledigt werden kann und man Typsicherheit gewinnt. Wenn man das nicht 
erkennt als verantwortlicher Entwickler oder Srum-Master, ist man auf 
dem Posten falsch.

Sheeva P. schrieb:
> Richtig so. Denn ihre Aufgabe war es, sich um die Zusammenarbeit im Team
> zu kümmern. Hat man Dir das nicht gesagt? Hast Du Dich nie gefragt?

Dann braucht man keinen Scrum-Master in so einem Miniprojekt. Es muss 
jemanden geben, der technisch den Hut auf hat. Von dem Chefentwickler 
habe ich da auch nicht viel mitbekommen

Aber noch einmal: Wenn die Scrum-Masterin auf meine Hinweise mit 
Schulterzucken reagiert und nichts passiert, dann funktioniert der 
Prozess nicht, wenn sie keine Korrektur einleiten kann. Ein Prozess kann 
nur dann als funktionierend bezeichnet werden, wenn das Ergebnis 
halbwegs stimmt. Aber es stimmte ja gar nicht, weil zu viele Stunden 
verbraten wurden und nichts funktionierte. Deswegen wurde das auch 
gestoppt, die Projektteam komplett gewechselt. Ich war der einzige, der 
blieb. Ich kam auch sehr spät zum alten Projektteam, weshalb ich das 
nicht als mein Scheitern ansehe. Wir haben fast alles weggeschmissen, 
was die programmiert haben.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Vielleicht ist es ja der große Unterschied zwischen uns, daß das bei mir
> nicht so gewesen ist. Bei uns hat sich das Team zusammengesetzt und
> überlegt wie wir besser zusammenarbeiten können.

Das ist sogar ganz sicher die Erklärung, keine Frage. Bei uns ist ein 
Manager geschasst und dafür ein anderer Manager eingestellt worden, der 
wenig von der technischen Seite versteht, aber ein Agil- und 
Methodenfreak ist und das als Weg zum Heil verkauft hat.

> Andererseits frage ich mich, ob das ein seriöses Argument ist. Daß bei
> jeder nützlichen -- und auch vielen unnützen -- Dingen eine ganze
> Industrie daraus bildet, die dabei Gelder abgreifen will, ist ja nun
> nichts Neues.

Es liegt da schon der Verdacht nahe  das das eine Eigendynamik 
entwickelt und den Kunden etwas angedreht wird, was sie nicht brauchen 
und ihnen vielleicht sogar schadet.

>> Polemisch gesagt, sind Scrum, User Stories und
>> Sprints das Geschirr, das dem Techie angelegt wird.
>
> ... auf die Spitzen verzichten wollte?

Gegen das Scrum will ich weiter schimpfen!

> Das Lustigste an Deinen Ausführungen ist, daß der Sozialismus
> tatsächlich funktionieren kann, zum Beispiel in israelischen Kibbutzen.

Unbestritten. Der Sozialismus hat aber einen anderen Anspruch, als in 
kleinen, persönlichem Rahmen zu funktionieren.

> Nur geringfügig weniger lustig ist, daß es Du ja ausgerechnet Du bist,
> der unbedingt einen Fünfjahresplan, vulgo eine bereits vor der
> Implementierung festgezurrte Detailplanung haben will,

Scrum ist innerhalb der Sprints sehr rigide. Es entspricht einem Fahren 
auf Sicht, wo dann die Velocity als Maßstab gilt. "Wir wissen noch nicht 
genau, wohin die Reise geht, aber wir fahren mal 2 Stunden Richtung 
Westen. Je weiter wir kommen, desto besser sind wir".

von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Sheeva P. schrieb:
>> Andererseits frage ich mich, ob das ein seriöses Argument ist. Daß bei
>> jeder nützlichen -- und auch vielen unnützen -- Dingen eine ganze
>> Industrie daraus bildet, die dabei Gelder abgreifen will, ist ja nun
>> nichts Neues.
>
> Guter Vergleich. Ich bin zwar zu jung, um die 90er als Berufsentwickler
> miterlebt zu haben, aber so stelle ich es mir vor, dass da
> Schlangenölverkäufer als OOP-Consultants herumliefen.

Massenhaft, ja. Gleichzeitig haben viele die Vererbung (is-a) anstelle 
von Komposition (has-a) gepredigt, weil: es ging ja und war eine der 
wichtigen Neuerungen, die mit OO möglich waren und sind. Lustig: von 
Vererbung gehen einige moderne OO-Konzepte wie Go sogar mehr oder 
weniger wieder weg, und ermutigen stattdessen die Komposition.

> Mit den Ergebnissen muss man aber bis heute leben. Viele haben
> Objektorientierung nicht endgültig verstanden.

True, und leider hat die OO bis heute oft keinen guten Ruf. In einem 
Python-Forum bin ich sogar mal blöd angefurzt worden, weil ich etwas mit 
OO gelöst habe, das man auch prozedural hätte lösen können.

> Sheeva P. schrieb:
>> Rudi R. schrieb:
>>> Die Antwort darauf ist ganz einfach: Die Leute müssen selbst erkennen,
>>> dass man sowas nicht mal eben aus dem Ärmel schüttelt und dass es
>>> Vorkenntnisse benötigt.
>>
>> Können sie das denn selbst erkennen? Wie sollten sie das erkennen, wenn
>> sie nicht einmal wissen, was Du vorstellen sollen würdest? Woher?
>
> Ich hatte es ja mal demonstriert anhand eines anderes Projektes. Die
> wollten 'ne Einführung, wie man es verwendet.

Naja, ein "sorry, bis morgen bekomme ich leider keine sinnvolle, 
brauchbare Einführung hin" hätte das Problem sicher in jedem anständigen 
Team gelöst. Wenn solche Hinweise überhört werden, ist das ein sehr 
eindeutiger Hinweis darauf, daß man sich einen neuen Brötchengeber 
suchen sollte... :-)

> Sheeva P. schrieb:
>> Ach, Rudi... bei einer Herzoperation wissen wir alle, daß die
>> hochkomplex und gleichzeitig lebensbedrohlich ist, aber bei einer
>> unbekannten DSL?
>
> Zu komplex, um es mal eben in 45 min durchzuexerzieren, dass sie es
> verwenden können.

Naja, ich hab' selbst schon ein paar DSLs entwickelt, die Spannweite ist 
groß und reicht von einer DSL für eine simple Konfiguration über eine 
DSL wie die Konfigurationsdatei sendmail.cf... hüstel

> Ich halte es für relativ unwichtig. In diesem konkreten Falle war es
> alter Code, der auskommentiert wurde. Die Scrum-Masterin wollte aber,
> dass es gelöscht wird. Also nichts funktionales, wenig relevant.
> Gleichzeitig nahm sie die SQL-Geschichten in Java-Strings hin.

Und das war auch völlig richtig von ihr, denn es ist eben nicht ihre 
Aufgabe, die Codequalität zu bewerten oder zu verbessern.

> Dann braucht man keinen Scrum-Master in so einem Miniprojekt. Es muss
> jemanden geben, der technisch den Hut auf hat. Von dem Chefentwickler
> habe ich da auch nicht viel mitbekommen

Und daran soll dann das Modell schuld sein? Ich bitte Dich.

> Aber noch einmal: Wenn die Scrum-Masterin auf meine Hinweise mit
> Schulterzucken reagiert und nichts passiert, dann funktioniert der
> Prozess nicht, wenn sie keine Korrektur einleiten kann.

Wie gesagt, das ist nicht ihre Aufgabe, sondern die Aufgabe des Teams -- 
und insbesondere natürlich seiner fähigeren und erfahreneren Mitglieder.

> Ein Prozess kann
> nur dann als funktionierend bezeichnet werden, wenn das Ergebnis
> halbwegs stimmt. Aber es stimmte ja gar nicht, weil zu viele Stunden
> verbraten wurden und nichts funktionierte. Deswegen wurde das auch
> gestoppt, die Projektteam komplett gewechselt. Ich war der einzige, der
> blieb. Ich kam auch sehr spät zum alten Projektteam, weshalb ich das
> nicht als mein Scheitern ansehe. Wir haben fast alles weggeschmissen,
> was die programmiert haben.

Wenn das Team unfähig ist, dann ist ein Scheitern vorprogrammiert, und 
da können dann auch ein Prozeß und ein Modell nichts mehr retten. Und, 
nebenbei bemerkt: ich habe auch schon klassische Projekten scheitern 
sehen, weil zu viele unerfahrene Leute involviert waren.

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Franko S. schrieb:
> Ja dann hast du Scrum falsch angewendet, nicht verstanden. Der Scrum
> Scharlatan äh Master deiner Wahl erklärt dir das sicher nochmal, für
> viel Geld.

So wurde ich in Scrum eingeführt. Scrum sei die unfehlbare Lösung für 
alle Firmen.

So hat es natürlich nicht geklappt, aber die Consulter haben gut daran 
verdient.

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Sheeva P. schrieb:
> unsere Java-Leute haben ihre Entwicklungsumgebungen so eingerichtet, daß
> bei jedem Commit ein Stylechecker und / oder Formatierer über den Code
> laufen.

Diese Idee wirst du verfluchen, sobald eine andere IDE zugelassen wird, 
die sich nicht genau gleich konfigurieren lässt. Bei jedem Commit wird 
dann die gesamte Datei als geändert angezeigt, anstatt nur die wirklich 
relevanten Zeilen.

Man kann sich im Team auf wemige Code-Style Regeln einigen, ohne jedes 
Detail fest zu zurren. Ein bisschen flexibilität im Kopf schadet nicht. 
Wichtiger ist eine saubere Struktur des Programms, die kann keine IDE 
erzwingen. Wobei man auch da individuelle Unterschiede in einem gewissen 
Maße tolerieren sollte.

: Bearbeitet durch User
von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Wenn das Team unfähig ist, dann ist ein Scheitern vorprogrammiert, und
> da können dann auch ein Prozeß und ein Modell nichts mehr retten. Und,
> nebenbei bemerkt: ich habe auch schon klassische Projekten scheitern
> sehen, weil zu viele unerfahrene Leute involviert waren.

Entschuldigung, wenn ich da nochmal meinen Senf dazu gebe. Der letzte 
Absatz bringt es doch auf den Punkt, eigentlich gibt es gar keinen 
Dissens. Man könnte es auch so formulieren: Wenn die Leute gut sind, 
dann werden bestimmte Themen adressiert, ansonsten nicht - unabhängig 
von Prozeß und Modell.

> ich habe auch schon klassische Projekten scheitern
> sehen, weil zu viele unerfahrene Leute involviert waren.

Der Satz ist bemerkenswert. Chapeau! Ein Agilist würde das Scheitern 
eines klassischen Projekts immer kausal auf eine bestimmte Ursache 
zurückführen. Die "Leute" wären für so jemand "Ressourcen", die vor 
allem quantitativ gemessen werden.

> Und das war auch völlig richtig von ihr, denn es ist eben nicht ihre
> Aufgabe, die Codequalität zu bewerten oder zu verbessern.

> Wie gesagt, das ist nicht ihre Aufgabe, sondern die Aufgabe des Teams --
> und insbesondere natürlich seiner fähigeren und erfahreneren Mitglieder.

Ja, es ist ausdrücklich nicht die Aufgabe des Scrum Masters, technische 
Vorgaben zu machen. Aber das ändert doch nichts daran, daß ein Scrum 
Master, der technisch bewandert ist und sich da einbringt, besser ist, 
als einer, der technisch "unbelastet" ist, und nur nach Schema F. 
moderiert (weil er gar nicht versteht, worum es Teammitglied R. 
überhaupt geht). Eine sture Rollenzuweisung aus dem Scrum-Lehrbuch ist 
etwas furchtbares, sie impliziert ja, ein Scrum Master könnte heute in 
der Flugzeugentwicklung arbeiten, morgen in der Softwareentwicklung und 
übermorgen in der Chemieindustrie. Geradezu nach dem Motto, je weniger 
er technisch versteht, desto besser ist er, weil er dann neutral in 
seiner Rolle ist.

von Sheeva P. (sheevaplug)


Lesenswert?

Sherlock 🕵🏽‍♂️ schrieb:
> Franko S. schrieb:
>> Ja dann hast du Scrum falsch angewendet, nicht verstanden. Der Scrum
>> Scharlatan äh Master deiner Wahl erklärt dir das sicher nochmal, für
>> viel Geld.
>
> So wurde ich in Scrum eingeführt. Scrum sei die unfehlbare Lösung für
> alle Firmen.

Ach Du liebe Güte... und das hat wirklich jemand geglaubt?

> So hat es natürlich nicht geklappt, aber die Consulter haben gut daran
> verdient.

Nunja, den Heilsverkäufern ist der Erfolg eines Projekts -- und die 
Parameter, an denen dieser Erfolg hängt -- doch eher gleichgültig. Wenn 
der Erfolg oder Mißerfolg eines Projekts oder seines Produkts sich 
abzuzeichnen beginnt, sind diese Leute schon längst woanders.

Und vielleicht beginnt der Fehler bei vielen Scrum-Versuchen auch schon 
damit, sich externe Berater zu suchen, anstatt eigene Mitarbeiter 
auszubilden.

von Sheeva P. (sheevaplug)


Lesenswert?

Sherlock 🕵🏽‍♂️ schrieb:
> Sheeva P. schrieb:
>> unsere Java-Leute haben ihre Entwicklungsumgebungen so eingerichtet, daß
>> bei jedem Commit ein Stylechecker und / oder Formatierer über den Code
>> laufen.
>
> Diese Idee wirst du verfluchen, sobald eine andere IDE zugelassen wird,
> die sich nicht genau gleich konfigurieren lässt. Bei jedem Commit wird
> dann die gesamte Datei als geändert angezeigt, anstatt nur die wirklich
> relevanten Zeilen.

Meine Java-Kollegen haben das ziemlich problemlos hinbekommen, als ein 
neuer Kollege statt des etablierten Eclipse unbedingt etwas anderes 
haben wollte, IIRC war das IntelliJ.

von Manfred P. (pruckelfred)


Lesenswert?

Sheeva P. schrieb:
> Meine Java-Kollegen haben das ziemlich problemlos hinbekommen,

Arbeiten die ähnlich wie Arduino-Bastler, kopieren Klassen zusammen und 
sind anschließend an nichts schuld?

von Sheeva P. (sheevaplug)


Lesenswert?

Manfred P. schrieb:
> Sheeva P. schrieb:
>> Meine Java-Kollegen haben das ziemlich problemlos hinbekommen,
>
> Arbeiten die ähnlich wie Arduino-Bastler, kopieren Klassen zusammen und
> sind anschließend an nichts schuld?

Meine Java-Kollegen entwickeln eine Software mit ca. 350 kLOC zur 
Erkennung von Banken- und Versicherungsbetrug in Echtzeit, die seit 
ungefähr dreißig Jahren weltweit erfolgreich eingesetzt wird.

Edit: Wort vergessen.

: Bearbeitet durch User
von Franko S. (frank_s866)


Lesenswert?

Sheeva P. schrieb:
> Meine Java-Kollegen haben das ziemlich problemlos hinbekommen, als ein
> neuer Kollege statt des etablierten Eclipse unbedingt etwas anderes
> haben wollte, IIRC war das IntelliJ.

Wasn das für ne komische Bude wo du arbeitest?

1. Eclipse ist längst überall rausgeflogen, IntelliJ ist seit Jahren 
Standard,
das hat alles abgehängt. Was das fürn Laden der noch Eclipse nutzt? Ne 
Behörde?

2. Dass ein Neuzugang sich Wünsch dir was spielen darf habe ich auch 
noch nie gesehen, gerade im Javaumfeld. Wem die IDE nicht passt kommt 
gar nicht erst rein, Diven die gleich Sonderlocken brauchen kann man 
dort nicht brauchen.

von Udo S. (urschmitt)


Lesenswert?

Franko S. schrieb:
> 1. Eclipse ist längst überall rausgeflogen

Was ist "überall". Hast du konkrete Beispiele?

Franko S. schrieb:
> 2. Dass ein Neuzugang sich Wünsch dir was spielen darf habe ich auch
> noch nie gesehen, gerade im Javaumfeld. Wem die IDE nicht passt kommt
> gar nicht erst rein, Diven die gleich Sonderlocken brauchen kann man
> dort nicht brauchen.

Vielleicht arbeitest du ja ein einem Großunternehmen im 
Pseudobeamtentum. Bei uns darf sich jeder die Entwicklungsumgebung 
installieren die er möchte.
Für Java ist das ca. 80% IntelliJ aber noch 20% Eclipse.
Kleineres Unternehmen mit Standorten in DE, Schweiz, Indien und 
Frankreich, ca. 300 Mitarbeiter.

von Cyblord -. (cyblord)


Lesenswert?

Franko S. schrieb:
> 1. Eclipse ist längst überall rausgeflogen, IntelliJ ist seit Jahren
> Standard,

Nur in deiner sehr kleinen Bubble.

von Jeno (tuner)


Lesenswert?

kenne Leute die extrem wenig von Scrum halten , soviel dazu ...

von Sheeva P. (sheevaplug)


Lesenswert?

Jeno schrieb:
> kenne Leute die extrem wenig von Scrum halten , soviel dazu ...

Wow, keinen vollständigen Satz zusammenbringen und dann auch noch 
plenken. Deine Mami ist sicher stolz auf Dich, vielen Dank für das 
Gespräch. :-)

von Rudi R. (rudi_r)


Lesenswert?

Eclipse ist in der Tat kaputt gefrickelt worden. Ich bin mehr ein Fan 
von Emacs mit eglot. Die Autovervollständigung in Eclipse und IntelliJ 
sind natürlich viel besser; Java konnte Emacs nie gut. Aber der 
entscheidende Punkt ist: Eine IDE nervt bestenfalls nicht und nimmt 
zuverlässig Standardroutinen ab, z. B. Autovervollständigung, denn 
selbst erfahrene Entwickler verlieren bei der riesigen Code-Basis die 
Übersicht. Aber was keine IDE einem abnehmen kann: Selbst denken, 
Lösungen finden.

Eine IDE vorzuschreiben, ist ein Graus. Man kommt ja zum Glück davon 
weg. Microsoft hat das Language Server Protocol geschaffen. Besagtes 
eglot nutzt das. Im Intergrund werkelt eine Laufzeitumgebung und 
kompiliert und bietet die schönen Sachen an, die Eclipse und IntelliJ so 
angenehm machen.

Ich erinnere mich an meine erste Firma, wo ich gescholten wurde, weil 
ich vom Emacs geschwärmt habe. Das war 2008/9. Obwohl die immer auf 
meinem Bildschirm den Eclipse sahen, ich auch sagte, für Java nutze ich 
Eclipse (aus den oben genannten Gründen), aber für viele andere Sachen 
eben nicht. Die hörten nur Emacs und waren gegen mich. Die hörten mir 
auch nicht zu. Irre.Ich Der Emacs macht mich aber unheimlich produktiv. 
Gerade die Tastaturmakros nutze ich ständig.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Eine IDE vorzuschreiben, ist ein Graus

Ich sehe das von 2 Seiten. Natürlich soll jeder benutzen, was ihm liegt, 
wenn er Code liest, schreibt oder debuggt.

Es sollte aber eine Art "Referenz-Workflow" existieren, wo ein Projekt 
nach dem Ausschecken auf einem fremden Rechner und ein paar Skripten 
kompilier- und lesbar ist, ohne dass erst dutzende von Schritte mit der 
Maus z.B. in Eclipse notwendig sind. Das artete  bei uns sonst aus. 
Einerseits dass dutzende (fehlerträchtige) Schritte notwendig waren, um 
ein Kompilat zu reproduzieren, andererseits dass Leute überall Krümmel 
ihrer IDE im VCS hinterlassen.

von Franko S. (frank_s866)


Lesenswert?

Rudi R. schrieb:
> auch nicht zu. Irre.Ich Der Emacs macht mich aber unheimlich produktiv.
> Gerade die Tastaturmakros nutze ich ständig.
Ach Gottchen als ob das keine andere IDE könnte. Tastaturmakros 
GRÖÖÖÖHL!

Und überhaupt EMACS, unter welchem Stein bist du denn hervorgekrochen? 
Das Gerümpel habe ich schon seit 20 Jahren nicht mehr irgendwo für 
irgendwas im Einsatz gesehen, ausser Fanbois die an dem Ding aus 
Langeweile herumfricklen, Studentenköpfe die das Ding "wiederentdeckt" 
haben weil ein alter Fuzzy denen was vorphantasiert hat das wäre was 
ganz dolles, arbeiten tut mit dem Monstrum schon lange keiner mehr.

Also echt jetzt, die 80/90er haben angerufen, ein Editorwar, das hatten 
wir ja schon lange nicht mehr. Jetzt kommt sicher gleich einer mit vim 
angewanzt und plustert sich auf wie ein Paradisvogel.

IntelliJ machte alles platt, das ist die Referenz-IDE für 
Javaentwicklung, mit extrem weitem Abstand, da kommt einfach gar nix 
mehr ran. Allein schon die Spring Unterstützung ohne die heute kein 
Projekt mehr läuft ist die beste die es gibt, da kommt einfach nix mehr 
hinterher von der Konkurrenz, die sind weit abgeschlagen. Dann der ganze 
AI Support der da in letzter Zeit eingeflossen ist, da kommst du mit 
Emacs an. Wir haben 2025 nicht 1985.

Und speziell Eclipse unter Linux ist pain in the ass dank dem kaputten 
SWT, mit seinen uralten offenen Bugs die immer noch nicht gefixed sind. 
Ich sag nur Accessible Bug. Geh mir weg dem Schrott.
Eclipse war nur gross als deren RCP-Gerümpel mal verbreitet war, das ist 
doch inzw. auch überall rausgeflogen, heute wandert alles ins Web, 
diesen
Klumpen bindet sich heute keiner mehr ans Bein, mein Beileid wer noch 
den alten Schrott warten muss.

von Gerhard O. (gerhard_)


Lesenswert?

Moin,

Jetzt schütte ich mal Öl gehörig ins Feuer:-)

Ich finde, alles ist Gewöhnungssache. Dem "Hungrigen schmeckt alles".

Wer sich seine Brötchen damit verdient, macht meistens im Rudel mit:-) 
Die modernen IDEs möchte ich eigentlich nicht vermissen.

Mein erster Editor war übrigens IBM "PE".
Dann für einige embedded Linux Sachen vi.
Dann später für PIC Sachen Textpad(++).
Später diverse IDE verschiedenster Hersteller.
Zur Zeit ist es schon eine Zeitlang Eclipse.
Ich fand übrigens das alte uV2 IDE von Keil recht angenehm.
Auch mit dem recht einfachen Arduino IDE lässt es sich produktiv 
arbeiten.

Mit allen kam ich gut genug zurecht.

Ich weiß also nicht wirklich "What all the fuss is about":-)

Wer da nicht wirklich nur SW entwickelt, dem ist es wahrscheinlich 
relativ einerlei welches Werkzeug zur Hand kommt. Da ich HW und SW 
mache, finde ich genug Abwechslung zwischen Editoren, CAD Tools und 
Lötkolben.

Duck und weg,
Gerhard

: Bearbeitet durch User
von Rudi R. (rudi_r)


Lesenswert?

Bruno V. schrieb:
> Rudi R. schrieb:
>> Eine IDE vorzuschreiben, ist ein Graus
>
> Ich sehe das von 2 Seiten. Natürlich soll jeder benutzen, was ihm liegt,
> wenn er Code liest, schreibt oder debuggt.
>
> Es sollte aber eine Art "Referenz-Workflow" existieren, wo ein Projekt
> nach dem Ausschecken auf einem fremden Rechner und ein paar Skripten
> kompilier- und lesbar ist, ohne dass erst dutzende von Schritte mit der
> Maus z.B. in Eclipse notwendig sind. Das artete  bei uns sonst aus.
> Einerseits dass dutzende (fehlerträchtige) Schritte notwendig waren, um
> ein Kompilat zu reproduzieren, andererseits dass Leute überall Krümmel
> ihrer IDE im VCS hinterlassen.

Ja, so ein Workflow sollte es geben, keine Frage. Aber das geht ja 
alles, ohne eine IDE festzulegen. Nach dem Erfolg einiger IDEs wie 
Eclipse, NetBeans, Visual-C++ etc. ist es keinem Entwickler zuzumuten, 
für jede Programmiersprache sich neu zurechtfinden zu müssen. Folglich 
geht die Richtung zur Trennung von Frontend und Backend bei den IDEs. 
Dazu gibt es das Language Server Protocol. Dahin wird die Richtung 
gehen. In Java-Projekten nimmt Gradle einen sehr viel Arbeit ab.

Franko S. schrieb:
> Ach Gottchen als ob das keine andere IDE könnte. Tastaturmakros
> GRÖÖÖÖHL!

Bei Emacs gehört es zur Kultur, Makros aufzuzeichnen. Andere Editoren 
verstecken diese Funktion, sofern sie diese überhaupt haben. Eclipse 
liefert das nicht mal standardmäßig aus. Da gibt es ein Plugin und die 
letzte Version ist von 2015.

Franko S. schrieb:
> Und überhaupt EMACS, unter welchem Stein bist du denn hervorgekrochen?
> Das Gerümpel habe ich schon seit 20 Jahren nicht mehr irgendwo für
> irgendwas im Einsatz gesehen, ausser Fanbois die an dem Ding aus
> Langeweile herumfricklen, Studentenköpfe die das Ding "wiederentdeckt"
> haben weil ein alter Fuzzy denen was vorphantasiert hat das wäre was
> ganz dolles, arbeiten tut mit dem Monstrum schon lange keiner mehr.

Es ist kein Gerümpel, sondern äußerst vital. Es ist einfach sehr gut. 
Emacs wurde auch nicht durch Scrum-Teams entwickelt. Bei Eclipse, das ab 
einer bestimmten Version sehr buggy war, bin ich mir nicht so sicher.

Franko S. schrieb:
> Also echt jetzt, die 80/90er haben angerufen, ein Editorwar, das hatten
> wir ja schon lange nicht mehr. Jetzt kommt sicher gleich einer mit vim
> angewanzt und plustert sich auf wie ein Paradisvogel.

Den Krieg hast du doch begonnen. Und Eclipse finde ich auch nicht so 
dolle.

Der Emacs wird auch in 30 Jahren noch existieren und genutzt werden. Die 
Community wird immer größer. Sicherlich ist er nicht so fancy wie 
IntelliJ, aber Emacs durchgängige Bedienkonzepte, die in allen Arten von 
Projekten verwendet werden können. Gerade erst heute habe ich wieder den 
org-Mode mit babel verwendet.

Eclipse war vor 17 Jahren richtig populär. Man dachte, Eclipse kann 
einfach alles, also wurden auch C++-Plugins bereitgestellt, die nie 
überzeugen konnten. Das kann mit IntelliJ auch passieren, wenn es nicht 
andere Programmieraufgaben jenseits der Java-Welt beherrscht.

von Sheeva P. (sheevaplug)


Lesenswert?

Franko S. schrieb:
> Rudi R. schrieb:
>> auch nicht zu. Irre.Ich Der Emacs macht mich aber unheimlich produktiv.
>> Gerade die Tastaturmakros nutze ich ständig.
> Ach Gottchen als ob das keine andere IDE könnte. Tastaturmakros
> GRÖÖÖÖHL!
>
> Und überhaupt EMACS, unter welchem Stein bist du denn hervorgekrochen?

Franko ist ein Troll.

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Sheeva P. schrieb:
> Ach Du liebe Güte... und das hat wirklich jemand geglaubt?

Sicher doch. Beratern wurden dafür ausgebildet, Manager zu überzeugen. 
Viele davon sind in ihrem Job erfolgreich.

Ähnlich läuft es doch auch bei den Motivations-Predigern in den USA (und 
anderswo). Jeder kannst alles erreichen, wenn er es wirklich will. Schau 
her, ich bin vom Tellerwäscher zum Millionär aufgestiegen" Der Irrsinn 
darin ist: Sie sind damit reich geworden, anderen Leuten mit Gelaber 
Geld aus der Tasche zu ziehen. Wenn das alle machen würden, würde gar 
nichts mehr funktionieren. Vor allem nicht das Reich-werden.

> Und vielleicht beginnt der Fehler bei vielen Scrum-Versuchen auch
> schon damit, sich externe Berater zu suchen, anstatt eigene
> Mitarbeiter auszubilden.

Amen!

Udo S. schrieb:
> Bei uns darf sich jeder die Entwicklungsumgebung
> installieren die er möchte.

Bei uns auch. Gleiches gilt auch für viele andere Arbeitsmittel, z.B. 
Datenbank-Clients. Allerdings muss jeder seine Probleme selbst lösen, 
wenn er von den Referenz-Lösungen abweicht. Damit kommen wir alle gut 
klar.

: Bearbeitet durch User
von Rudi R. (rudi_r)


Lesenswert?

Re D. schrieb:
> Ein T. schrieb:
>> Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal
>> mit Softwareentwicklung
>
> Du kannst so viel fachlich argumentieren wie du willst, gegen ein "ich
> hab den Durchblick, der Rest sind Deppen" kommst du nicht an. Aber schon
> die Sichtweise macht offensichtlich, wer der Depp ist.

Es hat wirklich nichts mit Projektmanagement zu tun. Es ist eine Frage, 
der Kultur, von der Bereitschaft, lernen zu wollen, aber auch von der 
Bereitschaft, sein Wissen zu teilen. Ich bin wissbegierig und arbeite 
auch gerne Sachen für andere heraus.

Mir gefallen elegante Lösungen. Ich bin kein Freund davon, ständig neuen 
Code zum bestehen hinzuzufügen. Nun habe ich über 15 Jahren im Beruf 
vieles erlebt, wie die Entwickler häufig genau das machen, anstatt mal 
kurz innezuhalten und zu abstrahieren, und etwas elegantes umsetzen. 
Gerade erst am Donnertag rief mich eine Entwicklerin an, wie mich frage, 
wie man dieses oder jenes macht. Ich habe ihr den Code geschickt, 
erklärt und es läuft. Es überzeugt, weil es elegant und ästhetisch. Das 
kam nun in mehreren meiner Projekte unter und wenn man es verstanden 
hat, wird die Umsetzung von Lösungen derartiger Anforderungen zum 
Nobrainer.

Scrum proklamiert für sich: "Die Entwickler reden miteinander.", als 
wenn sie das sonst nicht täten. Es mag vielleicht erfolgreiche 
Scrum-Projekte geben, aber sie funktioniert nicht wegen, sondern trotz 
Scrum. Es sind die Akteure. Unabhängig vom Vorgehensmodell braucht man 
immer den gesunden Menschenverstand. Und Wasserfall-Modell wird ja auch 
nicht 1:1 umgesetzt. Wenn man in einer späteren Phase erkennt, dass die 
Spezifikation falsch ist, dann wird das korrigiert.

Problematisch wird es, unabhängig vom Vorgehensmodell, man sich 
Erkenntnissen verschließt. Das ist im Wasserfallmodell der 
Spezifikationsfehler, der in einer späteren Phase als solcher erkannt 
wird, das ist bei Scrum das Festhalten als User-Storys. Man hat einen 
wichtigen Bug Fix beigesteuert, bekommt aber eins auf den Deckel, weil 
der im Sprint nicht geplant wurde.

Ich habe beides erlebt schon erlebt: Festhalten ans Spezifikation sowie 
dieses festhalten am Sprintkorsett. Und Menschen, wie ich, die sich 
stark mit der eigenen Arbeit identifizieren und auch nicht die 
Schlechtesten im Beruf sind, verzweifeln regelrecht. Kann man sich einen 
Steve Wozniak oder einen Linus Torvalds in der Scrum-Mühle vorstellen? 
Oder Ken Thompson, Brian Kernighan und Dennis Ritche? Ich habe mich in 
letzter Zeit viel mit den Unix-Tools beschäftigt und für Analyseaufgaben 
nutze ich lange Pipe-Konstrukte. Unix- und Shellkonzepte sind elegant 
und deshalb sind sie sehr mächtig. Kein Scrum-Zirkus wäre in der Lage, 
sowas zu schaffen. Auch keine Wasserfall-Methodik, wo der Spezifikateur 
seltsame Vorgaben macht, auch weil er nicht in der Lage ist, die 
geeigneten Abstraktionen zu sehen, um zu einer eleganten Lösung zu 
kommen.

Der Scrum-Zirkus wirkt auf mich sehr abstoßend. Ich habe nun auch ein 
paar Videos mit Scrum-Mastern bzw. Scrum-Coaches gesehen. Mich überzeugt 
das nicht. Da wird ein riesiges Bohei da drum gemacht, es als sehr große 
Gefahr angesehnen, dass etwas ausgeliefert wird, was der Kunde gar nicht 
bestellt hat, aber die Entwickler es für sinnvoll befanden. Ich hatte da 
schon mehrfach Streit deswegen, aber nicht, weil ich eigenmächtig 
irgendwas entwickelt habe, was der Kunde nicht braucht. Nein, weil meine 
Lösungen genereller sind und mehr abdecken als ursprünglich 
spezifiziert. Und ziehe ich urpsrünglich spezifiziertes in Frage, genau 
dann, wenn ich erkenne, dass es einfacher und besser geht. Ich hatte 
schon Projektleiter, die das Talent hatten, ohne tiefe 
Frameworkkenntnisse dem Kunden etwas zu versprechen, wofür ich dann 
einen Mordsaufwand das Framework hätte aufbohren müssen. Dabei wollen 
die Kunden vor allem gut beraten werden und die Ziele sind immer: 
maximale Zuverlässigkeit, maximale Robustheit, maximale Performanz und 
das bei korrekter Funktionalität. Und wenn Constultants und 
Projektleiter ihren Circle of Competence ignorieren und ohne 
Rückendeckung aus der Fachabteilung, dem Kunden Unsinn verkaufen.

von Michael B. (laberkopp)


Lesenswert?

Rudi R. schrieb:
> Ich erinnere mich an meine erste Firma, wo ich gescholten wurde, weil
> ich vom Emacs geschwärmt habe. Das war 2008/9.

Oh ha, wer 2008 von EscapeMetaAltControlShift schwärmte, hat 30 Jahre 
verpennt und hört vermutlich noch Elvis Presley.

Nein, von Eclipse zu schwärmen war genau so verkehrt, aber es war 
kostenlos, das erklärt Vieles.

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> Franko ist ein Troll.

Ja, du auch. Kommt mal wieder auf die Teamanforderungen zurück. Hier 
geht es um Scrum und um die Nachteile der Teamzusammenarbeit, nicht um 
Editoren, IDEs usw.
Und bleib einfach mal sachlich beim Thema und nicht immer auf Einzelne 
zeigen und die beleidigen, heruntermachen usw.

Ansonsten kann man den Thread hier ja auch gleich schließen.

von Joe (jowu)


Lesenswert?

Rudi R. schrieb:
> Ich hatte da
> schon mehrfach Streit deswegen, aber nicht, weil ich eigenmächtig
> irgendwas entwickelt habe, was der Kunde nicht braucht. Nein, weil meine
> Lösungen genereller sind und mehr abdecken als ursprünglich
> spezifiziert.

Der Konkretismus, den Du beschreibst, daß bei Entwicklungen immer nur 
das konkrete Problem gelöst wird (und bei neuen Problemen wieder 
dazugecodet werden muß), ist ein Graus.

Da muß ich mal kurz einen Gedanken bringen. Weil das ein typisches 
Beispiel für die unterschiedliche Denke von Techies und Kaufleuten ist. 
Für die Techies sind technische Schulden ein Graus, die Kaufleute sehen 
die gar nicht. Scrum wird ja gerade dafür eingesetzt, daß die Techies 
nicht overengineeren und den Kundenfokus außer acht lassen. Und dabei 
übertreibt es.

Als Karikatur kann man sich eine Firma denken, wo die Techies mit 
Begeisterung an einer Lösung tüfteln, welche auch bei 10 hoch n mit n > 
10 performant läuft - während die Kaufleute die brennende Sorge haben, 
daß, wenn man nicht bis Ende des Jahres mindestens 100 Kunden hat, die 
Banken die Kredite nicht mehr verlängern und die Zukunft des 
Unternehmens fraglich ist.

Ja, Techies sind große Kinder und regelmäßig sehr eingebildet dazu, sie 
schauen auf die Kaufleute herab, deren mathematische Kenntnisse beim 
Dreisatz enden.

von Rudi R. (rudi_r)


Lesenswert?

Joe schrieb:
> Der Konkretismus, den Du beschreibst, daß bei Entwicklungen immer nur
> das konkrete Problem gelöst wird (und bei neuen Problemen wieder
> dazugecodet werden muß), ist ein Graus.

Erlebe ich immer wieder. Ich sehe Entwickler, die das Talent haben, 
mehrfach den gleichen Code hinzuballern, wo mir sofort auffällt, dass 
das Gros des Quelltextes eingedampft werden kann, wenn man Funktionen 
draus macht. Das ärgerlich ist dann, dass dann schon Monate ins Land 
gegangen sind, wenn mir der Code über den Weg läuft und ich dann 
refaktoriere. Sicherlich ein Risiko. Aber das Risiko, wenn ich eine 
Kleinigkeit übersehe. Aber das Risiko wurde initial von jemand anderen 
geschaffen. Warum programmiert die Person denn nicht von Anfang an 
redundantfrei? In Martin Fowlers Buch über das Refactoring steht: 
"Dreimal und die refaktorierst!" - Also wenn ich merke, dass ich drei 
mal ähnliches hinschreibe, muss ich schon die Funktion schaffen. Die 
Ernte wird dann später eingefahren durch schnelleres, sicheres 
Entwickeln. Auch die potentiellen Bugs werden weniger.

Joe schrieb:
> Da muß ich mal kurz einen Gedanken bringen. Weil das ein typisches
> Beispiel für die unterschiedliche Denke von Techies und Kaufleuten ist.
> Für die Techies sind technische Schulden ein Graus, die Kaufleute sehen
> die gar nicht. Scrum wird ja gerade dafür eingesetzt, daß die Techies
> nicht overengineeren und den Kundenfokus außer acht lassen. Und dabei
> übertreibt es.

Overengineering ist mir in mehr als 15 Jahren Praxis kaum begegnet. Eher 
ein Underengineering. Die meisten Kundenwünsche sind nicht explizit 
geäußert. Da hat die Verkaufsabteilung ohnehin ein Problem. Das 
Underengineering kommt von Entwicklern,  die lieber Dienst nach 
Vorschrift machen und ihre Freizeit kaum erwarten können. Bei vielen 
herrscht Desinteresse.

Speziell bei Software ist Overengineering ohnehin Kokolores, weil eine 
einmal erbrachte Leistung weiterverwendet werden kann und hinten raus 
wieder Geld spart, sofern die Leistung (in Form eines Softwaremoduls) 
hohe Qualität aufweist, z. B. durch gute Algorithmen, durch gute 
Datenstrukturen, vor allem aber durch gute Schnittstellen.

von Bruno V. (bruno_v)


Lesenswert?

Rudi R. schrieb:
> Overengineering ist mir in mehr als 15 Jahren Praxis kaum begegnet.

Rudi R. schrieb:
> Speziell bei Software ist Overengineering ohnehin Kokolores, weil eine
> einmal erbrachte Leistung weiterverwendet werden kann und hinten raus
> wieder Geld spart, sofern die Leistung (in Form eines Softwaremoduls)
> hohe Qualität aufweist,


Ich vermute, "Overengineering" war im Sinne von "Featuritis" gemeint: 
Eine "coole Funktion, die keinen Mehraufwand kostet" (tut sie doch und 
verursacht Nacharbeit/Testaufwand/Doku) oder "Das fände ich als Kunde 
toll" (weil ich das als einziger immer so mache). Manchmal um Genialität 
statt Qualität zu zeigen.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Rudi R. schrieb:
> Es hat wirklich nichts mit Projektmanagement zu tun.

Fein, da sind wir also einmal einig.

> Mir gefallen elegante Lösungen. Ich bin kein Freund davon, ständig neuen
> Code zum bestehen hinzuzufügen. Nun habe ich über 15 Jahren im Beruf
> vieles erlebt, wie die Entwickler häufig genau das machen, anstatt mal
> kurz innezuhalten und zu abstrahieren, und etwas elegantes umsetzen.

Das kennen die Erfahreneren unter uns sicherlich alle.

> Gerade erst am Donnertag rief mich eine Entwicklerin an, wie mich frage,
> wie man dieses oder jenes macht. Ich habe ihr den Code geschickt,
> erklärt und es läuft. Es überzeugt, weil es elegant und ästhetisch. Das
> kam nun in mehreren meiner Projekte unter und wenn man es verstanden
> hat, wird die Umsetzung von Lösungen derartiger Anforderungen zum
> Nobrainer.

Ja, also...

> Scrum proklamiert für sich: "Die Entwickler reden miteinander.", als
> wenn sie das sonst nicht täten.

...gerade Dein Beispiel mit Deiner Kollegin finde ich richtig gut. Jetzt 
habt Ihr also beide diesen eleganten und ästhetischen Code, und außer 
Euch beiden weiß niemand im Team und in der Company davon. Und morgen 
steht dann wieder ein Kollege vor einem ähnlichen Problem, und weil er 
nichts von der eleganten und ästhetischen Lösung weiß, fängt er wieder 
bei Null an.

Am Ende läuft das dann wie bei der PAM-Sicherheitssoftware bei einem 
großen Mobilfunker, die ich vor ca. 30 Jahren übernommen habe. Am Ende 
stellte sich heraus, daß das Netzwerkteam einen CSV-Parser für eine 
CSV-Datei mit fünf, während das Userteam einen für eine CSV-Datei mit 
sechs Feldern entwickelt hatte. Weil Entwickler von sich aus so prima 
miteinander reden...

Bei Deinem vorigen Beispiel mit in einer funktionierenden 
Scrum-Umsetzung hätte Deine Kollegin morgens im Daily nach Deiner Lösung 
gefragt, Du hättest kurz erklärt daß Du ihr gerne den Code gibst und ihn 
erklärst, und dadurch hätte danach jeder einzelne im Team gewußt, daß es 
eine Lösung für solche Anwendungsfälle gibt und wer man dafür 
angesprechen kann.

Jetzt könnte man alternativ natürlich sagen, daß der Projektleiter für 
solche Kommunikationen verantwortlich sei. Nur: der hat meistens eh 
schon genug zu tun und in der Regel gar keine Zeit, alle jeweiligen 
Anwendungsfälle korrekt durchschauen zu können und den Kollegen mit dem 
ähnlichen Problem einfach zu Dir oder Deiner Kollegin zu schicken.

> Ich hatte da
> schon mehrfach Streit deswegen, aber nicht, weil ich eigenmächtig
> irgendwas entwickelt habe, was der Kunde nicht braucht. Nein, weil meine
> Lösungen genereller sind und mehr abdecken als ursprünglich
> spezifiziert.

Auch Generalisierungen können in YAGNI enden.

von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> Sheeva P. schrieb:
>> Franko ist ein Troll.
>
> Ja, du auch. Kommt mal wieder auf die Teamanforderungen zurück. Hier
> geht es um Scrum und um die Nachteile der Teamzusammenarbeit, nicht um
> Editoren, IDEs usw.
> Und bleib einfach mal sachlich beim Thema und nicht immer auf Einzelne
> zeigen und die beleidigen, heruntermachen usw.

Na Du bist ja ein lustiger Scherzbold. Der von Dir zitierte Satz war 
meine bislang einzige Äußerung in diesem Thread zum Thema "Editoren, 
IDEs usw", geäußert in der naiven Hoffnung, daß andere Mitdiskutierenden 
dann nicht auf sein Getrolle eingehen würden. Ansonsten habe ich hier, 
im Gegensatz zu Dir übrigens, mich nahezu ausschließlich zum Thema 
geäußert.

Nebenbei bemerkt, nutze auch ich immer noch und seit mittlerweile gut 30 
Jahren den Emacs. Der ist nämlich eine ausgesprochen leistungsfähige und 
überaus flexible Lösung, und bietet mir für alle meine Sprachen dieselbe 
Funktionalität, dieselbe Optik, alles: C, C++, Perl, Python, Golang, 
LaTeX, HTML, JavaScript, CSS, SQL, Yaml, JSON und... you name it. Auch 
Jinja2-, Go- und Django-Templates, oder Svelte-Dateien sind allesamt 
kein Problem. Zudem kann ich ihn sogar vom Handy aus auf der 
Kommandozeile meiner Server nutzen, wenn ich mal irgendwo kein gutes 
Netz, aber einen Notfall habe. Insofern ist und bleibt der Emacs der 
Editor meiner Wahl.

> Ansonsten kann man den Thread hier ja auch gleich schließen.

Wenn Franko, Pruckelfred, Laberkopp und Du Euch nicht "beteiligt" 
hättet, wäre dieser Thread viel sachlicher und näher am Thema geblieben.

von Franko S. (frank_s866)


Lesenswert?

Sheeva P. schrieb:
> gefragt, Du hättest kurz erklärt daß Du ihr gerne den Code gibst und ihn
> erklärst, und dadurch hätte danach jeder einzelne im Team gewußt, daß es
> eine Lösung für solche Anwendungsfälle gibt und wer man dafür
> angesprechen kann.

Und nach drei Minuten wieder vergessen. Solche Infos gehören in ein Wiki 
und der Code in eine firmeneigene Lib/Framework Coderepo.

: Bearbeitet durch User
von Uwe D. (monkye)


Lesenswert?

Franko S. schrieb:
> Sheeva P. schrieb:
>> gefragt, Du hättest kurz erklärt daß Du ihr gerne den Code gibst und ihn
>> erklärst, und dadurch hätte danach jeder einzelne im Team gewußt, daß es
>> eine Lösung für solche Anwendungsfälle gibt und wer man dafür
>> angesprechen kann.
>
> Und nach drei Minuten wieder vergessen. Solche Infos gehören in ein Wiki
> und der Code in eine firmeneigene Lib/Framework Coderepo.

Wer bezahlt das Wiki? Wenn das Wiki für den Kunden (Dokumentation) oder 
den Support gedacht ist, dann vielleicht ja - ansonsten kommt der 
Projektleiter und haut auf die Finger (auch ohne Scrum)

von Joe (jowu)


Lesenswert?

Bruno V. schrieb:

> Ich vermute, "Overengineering" war im Sinne von "Featuritis" gemeint:
> Eine "coole Funktion, die keinen Mehraufwand kostet" (tut sie doch und
> verursacht Nacharbeit/Testaufwand/Doku) oder "Das fände ich als Kunde
> toll" (weil ich das als einziger immer so mache). Manchmal um Genialität
> statt Qualität zu zeigen.

Ich meinte mehr die Neigung, zu dolle und in die Zukunft gerichtet zu 
entwickeln. Bsp: Der Brötchengeber hat derzeit drei Kunden in 
Deutschland - der Entwickler entwickelt aber schon mal für 
unterschiedliche Zeitzonen und Währungen - weil er es kann. Der 
Entwickler macht eine skalierende Architektur, die für Millionen von 
Anwendern gleichzeitig performant laufen würde - weil es Spaß macht und 
herausfordernd ist und man da die Sachen aus dem Studium einbringen kann 
- aber derzeit gibt es eben nur 30 Anwender.

Das ist es, was ich meine: Die Nerds machen gerne das, worauf sie Bock 
haben, was Spaß macht und herausfordernd ist. Irgendwelche blöden 
Features für den Anwender zu bauen ist da vielleicht weniger spannend - 
aber der Kunde zahlt halt die Rechnungen und Gehälter.

Deshalb der Ansatz von Scrum, vor allem den Anwender entscheiden zu 
lassen, was mit welcher Prio gemacht wird. Und damit logischerweise die 
Gefahr, daß Architekturthemen und technische Schulden zu wenig 
fokussiert werden.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Ich meinte mehr die Neigung, zu dolle und in die Zukunft gerichtet zu
> entwickeln. Bsp: Der Brötchengeber hat derzeit drei Kunden in
> Deutschland - der Entwickler entwickelt aber schon mal für
> unterschiedliche Zeitzonen und Währungen - weil er es kann. Der
> Entwickler macht eine skalierende Architektur, die für Millionen von
> Anwendern gleichzeitig performant laufen würde - weil es Spaß macht und
> herausfordernd ist und man da die Sachen aus dem Studium einbringen kann
> - aber derzeit gibt es eben nur 30 Anwender.
>
> Das ist es, was ich meine: Die Nerds machen gerne das, worauf sie Bock
> haben, was Spaß macht und herausfordernd ist.

Wenn... ja was denn eigentlich? Wenn keiner auf die Kinder aufpaßt und 
stets hinter ihnen her ist, damit sie bei der Sache bleiben? ;-)

> Irgendwelche blöden
> Features für den Anwender zu bauen ist da vielleicht weniger spannend -
> aber der Kunde zahlt halt die Rechnungen und Gehälter.

Ich fürchte, viele Nerds sind weder per se dumm noch verspielt, und 
zumindest die meisten wissen ziemlich gut, wer ihr Gehalt bezahlt. Zur 
Erinnerung steht das ja regelmäßig nochmal auf ihrem Kontoauszug.

Nein, mal im Ernst: ja, natürlich gibt es solche Nerds, die gerne 
spielen, und manche von ihnen gehören gerade deswegen zu den 
kompetentesten und kreativsten Technikern, denen ich in meinem Leben 
begegnen durfte. Die allermeisten können genau zwischen Arbeit und 
Spielereien allerdings gut unterscheiden und spielen auch nicht, wenn es 
schnell gehen muß. Möglicherweise ist der Spieltrieb bei unerfahrenen 
Nerds auch größer, aber mit zunehmender Erfahrung wird auch ihnen immer 
klarer, wann es die Zeit zum Spielen, und wann es die zum Anpacken ist.

Im Endeffekt bewegt sich aber jede Entwicklung zwischen den drei Zielen 
"gut", "schnell" und "billig", und man kann immer nur zwei davon 
umsetzen. Die Nerds tendieren zu "gut" und sind bezüglich "schnell" und 
"billig" meist gespalten, die Ökonomen neigen gerne zu "schnell" und 
"billig", weil sie die Vorzüge des "gut" mitunter nicht nachvollziehen 
können. Also ergeben sich Spannungen, die sich mit Weisungsbefugnissen 
nur scheinbar lösen lassen (und sich dadurch oft extrem negativ auf die 
Motivation aller Beteiligten auswirken können).

Insofern bleiben wir doch mal bei Deinem Beispiel mit 
Internationalisierung und Lokalisierung. Solche Funktionen schon früh in 
einem Projekt vorzusehen ist viel weniger Aufwand, als so etwas 
nachträglich einzubauen.

Nehmen wir zum Beispiel eine Webapp, die ihre Templates aus dem 
Verzeichnis templates/ lädt und ihre Nachrichten aus messages/. Jetzt 
kann ich dort die Templates und Nachrichten direkt in diese beiden 
Verzeichnisse legen, klar. Aber spätestens wenn der erste internationale 
Kunde die Lokalisierung haben möchte, muß ich eine Funktionalität 
einbauen, die darüber hinaus geht. Mein Ansatz wäre daher, die 
Lokalisierung vorzubereiten: die Templates kommen in das Verzeichnis 
templates/de und die Nachrichten in messages/de, dazu kommt eine 
Variable, die zunächst standardmäßig immer mit "de" vorbelegt ist. Den 
ganzen übrigen Mumpitz -- die Vorbelegung überschreiben mit 
Konfigurations-,  wenn vorhanden Browser- und die überschreiben mit 
einer Benutzereinstellung, wenn vorhanden -- den kann ich mir 
einstweilen sparen, bis es nötig wird.

So nutzen alle Entwickler damit jedoch bereits frühzeitig die Funktionen 
zur Auswahl der korrekten Templates und Nachrichten. Aber wenn wir dann 
wirklich einen internationalen Kunden gewonnen haben, geht alles ganz 
schnell: in den Verzeichnissen templates/ und messages/ werden die neuen 
Unterverzeichnisse templates/fr und messages/fr angelegt, templates/de 
und messages/de gehen an den Übersetzer und ich kümmere mich darum, die 
Sprache in der Konfiguration meiner Software einstellbar zu machen. 
Danach kommt der nächste Kunde, sagen wir: aus der Schweiz. Da wird nun 
die dritte Sprache gesprochen, darum gehen die Daten wieder an unser 
Übersetzerbüro und landen dann in templates/it und messages/it, und 
obendrein entwickle ich die Auswahl per Requestheader und Benutzerprofil 
aus, alles ohne Änderungen am schon Entwickelten. Yay!

Meine Investition war anfangs vielleicht ein Manntag, aber am Ende haben 
wir eine saubere Internationalisierung mit überschaubarem Aufwand. Und 
wie hätte die Alternative ausgesehen? Dabei hätte ich mir die 
Vorbereitung gespart und dann wenn es notwendig geworden wäre, alle 
vorhandenen Teile meiner Software noch einmal anfassen müssen, um dort 
die neue Funktionalität einzubauen.

Um in solchen Fällen sinnvolle, belastbare und seriöse Entscheidungen 
treffen zu können, müssen Projektbeteiligte über ihren Tellerrand hinaus 
schauen, sie müssen vor allem informiert sein. Entwickler müssen wissen 
wie wahrscheinlich es ist, daß eine Internationalisierung notwendig 
werden wird -- wenn sich der Arbeitgeber ohnehin nur an Kunden im Inland 
wenden will, geschenkt, dann wird zumindest ein erfahrener Entwickler 
keine Zeit darauf verschwenden. Aber auch Projektleiter, Productowner 
und die BWLler müssen an dieser Stelle verstehen, daß es mit zunehmender 
Zeit und wachsender Größe immer aufwändiger wird, eine Basisfunktion wie 
diese in ein bestehendes Produkt einzubauen.

Und dann gibt es noch Situationen -- wenngleich: vielleicht nicht für 
dieses Beispiel -- die noch eine andere Strategie erfordern. Wenn der 
Kunde bereits mit Verzug, Vertragsstrafen oder Kündigung gedroht hat, 
könnte die Situation wieder ganz anders aussehen und derlei Erwägungen 
überwiegen.

Insofern leben wir in einem Spannungsfeld zwischen Spieltrieb und 
Zeitdruck, zwischen Nice-to-have und den heutigen und absehbaren 
Notwendigkeiten. Diese Diskrepanzen und Abwägungen lassen sich nur mit 
Information, Qualifikation, Erfahrung und Vertrauen auflösen.

Andererseits unterstellst Du den Nerds einen Spieltrieb. Das ist eine 
Sicht, die ich schon mehrmals bei Projektleitern erlebt habe und die 
(leider?) dazu beigetragen hat, daß ich diesem Modell eher skeptisch 
gegenüberstehe. Auf der anderen Seite höre ich meine Entwickler, die 
sagen: "der kennt zwar von allem den Preis, aber von nichts den Wert". 
Klar, den einen großen Entscheider zu haben, den man für Mißerfolg zur 
Verantwortung ziehen kann, das ist aus der hierarchischen Sicht 
natürlich eine feine Sache. Aber auf der anderen Seite dürfen wir dabei 
aber nicht vergessen, warum der staatliche Sozialismus (das war nicht 
mein Vergleich :-) bisher bisher immer gescheitert ist: weil es in allen 
komplexen Systemen Dinge gibt, die sich weder wissen, noch vorhersagen 
lassen, und je komplexer das System wird, desto mehr davon gibt es.

Naja, wie auch immer, ich schweife ab. Das hat nämlich auch nur noch 
ganz am Rande mit Projektmanagement zu tun und ist im Wesentlichen eine 
Funktion der guten, also vertrauensvollen und konstruktiven 
Zusammenarbeit zwischen allen Beteiligten eines Projekts -- angefangen, 
wohlgemerkt, beim Kunden. Der, wie Du natürlich völlig richtig sagst, 
bezahlt nämlich am Ende die Rechnung, und die besten Kunden sogar die 
für Spielereien.

> Deshalb der Ansatz von Scrum, vor allem den Anwender entscheiden zu
> lassen, was mit welcher Prio gemacht wird.

Entschuldige bitte, aber das ist definitiv nicht der Ansatz von Scrum. 
:-)

von Mark B. (markbrandis)


Lesenswert?

Sheeva P. schrieb:
> Bei Deinem vorigen Beispiel mit in einer funktionierenden
> Scrum-Umsetzung hätte Deine Kollegin morgens im Daily nach Deiner Lösung
> gefragt, Du hättest kurz erklärt daß Du ihr gerne den Code gibst und ihn
> erklärst, und dadurch hätte danach jeder einzelne im Team gewußt, daß es
> eine Lösung für solche Anwendungsfälle gibt und wer man dafür
> angesprechen kann.

Ja schön, dann wissen es die Leute, die zu dem Zeitpunkt im Team sind. 
Wer später ins Team dazu kommt, oder in einem anderen Team oder anderen 
Abteiling in der gleichen Firma ist, bekommt es aber nicht mit.

Das ist eines der großen Probleme von SCRUM: Es hat nur den Blickwinkel 
auf ein einzelnes Projekt. Es enthält von sich aus keinerlei Maßnahmen 
oder Regeln, wie man Wissen über ein Projektteam hinweg organisiert und 
aufbewahrt.

von Mark B. (markbrandis)


Lesenswert?

Franko S. schrieb:
> Und nach drei Minuten wieder vergessen. Solche Infos gehören in ein Wiki
> und der Code in eine firmeneigene Lib/Framework Coderepo.

Vollkommen korrekt. In einem Wiki hat man eine Suchfunktion und kann 
Dinge sehr einfach und schnell wiederfinden. Außerdem kann man mit wenig 
Aufwand neue Informationen hinzufügen. Besser und einfacher geht es wohl 
nicht.

von Mark B. (markbrandis)


Lesenswert?

Uwe D. schrieb:
>> Und nach drei Minuten wieder vergessen. Solche Infos gehören in ein Wiki
>> und der Code in eine firmeneigene Lib/Framework Coderepo.
>
> Wer bezahlt das Wiki? Wenn das Wiki für den Kunden (Dokumentation) oder
> den Support gedacht ist, dann vielleicht ja - ansonsten kommt der
> Projektleiter und haut auf die Finger (auch ohne Scrum)

Was gibt es denn da großartig zu bezahlen? Server hat man in einer 
Entwicklungsabteilung sowieso am laufen, z.B. für das Code Repository. 
Da packt man halt noch ein MediaWiki auf einen Server mit drauf, und gut 
is.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Nein, mal im Ernst: ja, natürlich gibt es solche Nerds, die gerne
> spielen, und manche von ihnen gehören gerade deswegen zu den
> kompetentesten und kreativsten Technikern, denen ich in meinem Leben
> begegnen durfte. Die allermeisten können genau zwischen Arbeit und
> Spielereien allerdings gut unterscheiden und spielen auch nicht, wenn es
> schnell gehen muß. Möglicherweise ist der Spieltrieb bei unerfahrenen
> Nerds auch größer, aber mit zunehmender Erfahrung wird auch ihnen immer
> klarer, wann es die Zeit zum Spielen, und wann es die zum Anpacken ist.

Logo. Die Gegenüberstellung Nerd <-> Kaufmann ist natürlich nicht 
schwarz-weiß und es gibt unzählige Grautöne.

> Im Endeffekt bewegt sich aber jede Entwicklung zwischen den drei Zielen
> "gut", "schnell" und "billig", und man kann immer nur zwei davon
> umsetzen. Die Nerds tendieren zu "gut" und sind bezüglich "schnell" und
> "billig" meist gespalten, die Ökonomen neigen gerne zu "schnell" und
> "billig", weil sie die Vorzüge des "gut" mitunter nicht nachvollziehen
> können. Also ergeben sich Spannungen, die sich mit Weisungsbefugnissen
> nur scheinbar lösen lassen (und sich dadurch oft extrem negativ auf die
> Motivation aller Beteiligten auswirken können).

Genau. Das kann ich so nur unterschreiben. Am besten man sieht die 
Spannungen je nach persönlicher Vorliebe als Tragödie oder Komödie. Der 
berühmte Karikaturist Scott Adams ("Dilbert") lebt als Künstler bestens 
davon.

> Insofern bleiben wir doch mal bei Deinem Beispiel mit
> Internationalisierung und Lokalisierung. Solche Funktionen schon früh in
> einem Projekt vorzusehen ist viel weniger Aufwand, als so etwas
> nachträglich einzubauen.

Das ist richtig. Angesichts des "Fachkräftemangels" wird aber auch schon 
um einzelne Manntage gerungen. Ich selbst bin ja auch ein Nerd mit wenig 
Neigung und begrenztem Talent, meine Lösungen ständig verkaufen zu 
müssen. Wenn ich beim "Planning Poker" sage "wenn man es gescheit macht, 
2 Tage, sonst 1 Tag", dann wird nur "1 Tag" gehört. Das Backlog ist ja 
sooo lang! Für eine wirklich sachliche Argumentation bleibt ja in den 
Sprint-Zeremonien keine Zeit - es wird gleich abmoderiert. Das ist der 
Grund, warum ich diese Meetings hasse!

> Aber auch Projektleiter, Productowner
> und die BWLler müssen an dieser Stelle verstehen, daß es mit zunehmender
> Zeit und wachsender Größe immer aufwändiger wird, eine Basisfunktion wie
> diese in ein bestehendes Produkt einzubauen.

Sicher. Und wenn sie es nicht begreifen, dann hilft auch kein 
Vorgehensmodell.

> Insofern leben wir in einem Spannungsfeld zwischen Spieltrieb und
> Zeitdruck, zwischen Nice-to-have und den heutigen und absehbaren
> Notwendigkeiten. Diese Diskrepanzen und Abwägungen lassen sich nur mit
> Information, Qualifikation, Erfahrung und Vertrauen auflösen.

Exakt. Und Scrum ist kein Ersatz für Information, Qualifikation, 
Erfahrung und Vertrauen.

> Naja, wie auch immer, ich schweife ab. Das hat nämlich auch nur noch
> ganz am Rande mit Projektmanagement zu tun und ist im Wesentlichen eine
> Funktion der guten, also vertrauensvollen und konstruktiven
> Zusammenarbeit zwischen allen Beteiligten eines Projekts

Ja, und auf die Gefahr, mich zu wiederholen: Scrum wird gerne vom 
Management eingekauft als Wundermedizin. Genauso wie der körperlich 
Verspannte in die Apotheke läuft, so läßt sich der Manager einen 
Vertreter kommen, der ein Mittel hat gegen "Spannungen, die sich mit 
Weisungsbefugnissen
nur scheinbar lösen lassen (und sich dadurch oft extrem negativ auf die
Motivation aller Beteiligten auswirken können)."

>> Deshalb der Ansatz von Scrum, vor allem den Anwender entscheiden zu
>> lassen, was mit welcher Prio gemacht wird.

> Entschuldige bitte, aber das ist definitiv nicht der Ansatz von Scrum.
> :-)

?!? Ich könnte schwören, daß die strikte Rollentrennung eines der 
Erfolgsrezepte von Scrum ist!

Anstelle vieler Quellen eine kurze Google-Suche:

https://www.google.de/search?q=scrum+rollen
https://scrumguide.de/scrum-rollen/
"Der Product Owner
Der Product Owner vertritt die Interessen des Kunden. Er ist der 
Auftraggeber und möglicherweise auch der Kunde selbst. Er hat das größte 
Interesse daran, dass ein qualitativ hochwertiges Produkt entwickelt 
wird, denn er zahlt schließlich die Rechnung.

Zudem verwaltet er oder sie das Backlog und legt somit fest, in welcher 
Reihenfolge etwas erledigt werden muss. Die wichtigsten Vorstellungen 
und Wünsche stehen immer an erster Stelle, weil sie die größten Vorteile 
bringen."

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Mark B. schrieb:
> Sheeva P. schrieb:
>> Bei Deinem vorigen Beispiel mit in einer funktionierenden
>> Scrum-Umsetzung hätte Deine Kollegin morgens im Daily nach Deiner Lösung
>> gefragt, Du hättest kurz erklärt daß Du ihr gerne den Code gibst und ihn
>> erklärst, und dadurch hätte danach jeder einzelne im Team gewußt, daß es
>> eine Lösung für solche Anwendungsfälle gibt und wer man dafür
>> angesprechen kann.
>
> Ja schön, dann wissen es die Leute, die zu dem Zeitpunkt im Team sind.
> Wer später ins Team dazu kommt, oder in einem anderen Team oder anderen
> Abteiling in der gleichen Firma ist, bekommt es aber nicht mit.

Ständig wechselnde Leute -- und damit der Verlust des Wissens, daß sie 
sich hinsichtlich dieses Projekts angeeignet haben -- ist ein vollkommen 
anderes Problem und noch viel unabhängiger von der Verwaltungsmethodik.

> Das ist eines der großen Probleme von SCRUM: Es hat nur den Blickwinkel
> auf ein einzelnes Projekt.

Nein.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> [...]

Danke für Deinen Beitrag, den ich bislang leider nur überfliegen konnte. 
In den nächsten Tagen finde ich (hoffentlich, gerade ist es ein wenig 
hektisch) die Zeit, ihn zu beantworten! :-)

von Mark B. (markbrandis)


Lesenswert?

Sheeva P. schrieb:
> Mark B. schrieb:
>> Ja schön, dann wissen es die Leute, die zu dem Zeitpunkt im Team sind.
>> Wer später ins Team dazu kommt, oder in einem anderen Team oder anderen
>> Abteiling in der gleichen Firma ist, bekommt es aber nicht mit.
>
> Ständig wechselnde Leute -- und damit der Verlust des Wissens, daß sie
> sich hinsichtlich dieses Projekts angeeignet haben -- ist ein vollkommen
> anderes Problem und noch viel unabhängiger von der Verwaltungsmethodik.

Von einem ständigen Wechsel hat überhaupt niemand gesprochen. Den hast 
Du eben gerade selbst erfunden.

Jede Firma hat eine natürliche Fluktuation. Angestellte gehen in Rente, 
manche wechseln in eine andere Firma, manche sterben gar vor Erreichen 
des Rentenalters. Also wird man immer mal wieder Leute einstellen 
müssen. Um so mehr noch, wenn die Firma wächst.

So, und wie integriert man nun die neu eingestellten Leute bitte in ein 
SCRUM-Team, welches schon länger existiert? Ich bin sehr gespannt auf 
Deine Antwort. :-)

>> Das ist eines der großen Probleme von SCRUM: Es hat nur den Blickwinkel
>> auf ein einzelnes Projekt.
>
> Nein.

Nein? Okay, dann zeig mir doch gerne die Stelle im Agilen Manifest, an 
der beschrieben steht wie man mit SCRUM projektübergreifend und 
abteilungsübergreifend zu guten Ergebnissen kommt.

von Ein T. (ein_typ)


Lesenswert?

Mark B. schrieb:
> Sheeva P. schrieb:
>> Mark B. schrieb:
>>> Das ist eines der großen Probleme von SCRUM: Es hat nur den Blickwinkel
>>> auf ein einzelnes Projekt.
>>
>> Nein.
>
> Nein? Okay, dann zeig mir doch gerne die Stelle im Agilen Manifest, an
> der beschrieben steht wie man mit SCRUM projektübergreifend und
> abteilungsübergreifend zu guten Ergebnissen kommt.

Nein. Wenn Du Dich für das Thema interessieren würdest und für einige 
Sekunden recherchiert hättest, wärst Du auch längst über die Begriffe 
"Scrum of Scrums" oder "Meta-Scrum" gestolpert.

von Mark B. (markbrandis)


Lesenswert?

Ein T. schrieb:
> Nein. Wenn Du Dich für das Thema interessieren würdest und für einige
> Sekunden recherchiert hättest, wärst Du auch längst über die Begriffe
> "Scrum of Scrums" oder "Meta-Scrum" gestolpert.

Funktionieren diese denn nachweislich besser als andere Methoden? Soweit 
ich weiß gibt es keinen Nachweis, dass Projekte mit SCRUM besser laufen 
als ohne. Wenn es eine Studie gibt die das belegt, dann würde ich sie 
wirklich sehr gerne lesen.

Zu oft hat man bei SCRUM den Eindruck:
Es wird so verkauft, als würde es sämtliche Probleme lösen. In Wahrheit 
hat es aber gar nicht die Mächtigkeit das tun zu können.

von Michael B. (laberkopp)


Lesenswert?

Mark B. schrieb:
> wie integriert man nun die neu eingestellten Leute bitte in ein
> SCRUM-Team, welches schon länger existiert? Ich bin sehr gespannt auf
> Deine Antwort. :-)

Coder sind bloss austauschbares Menschenmaterial, dank Scrum wird man 
den schon züchtigen, das kann dir jeder BWL Hengst sagen.

von Ein T. (ein_typ)


Lesenswert?

Mark B. schrieb:
> Funktionieren diese denn nachweislich besser als andere Methoden? Soweit
> ich weiß gibt es keinen Nachweis, dass Projekte mit SCRUM besser laufen
> als ohne. Wenn es eine Studie gibt die das belegt, dann würde ich sie
> wirklich sehr gerne lesen.

Echt jetzt, noch eine nächste Iteration in diesem Thread? Wenn Du in der 
Lage bist, eine dieser modernen sogenannten "Internet-Suchmaschinen" zu 
benutzen, kannst Du binnen Sekunden mehr als genug statistische 
Untersuchungen sowohl aus wissenschaftlicher, als auch aus 
unternehmerischer Sicht finden, guckstu zum Beispiel hier [1] oder hier 
[2] oder hier [3]. Zumindest die aktuelleren Untersuchungen scheinen 
jedenfalls vorwiegend für agile Methoden zu sprechen.

[1] https://docs.broadcom.com/doc/the-impact-of-agile-quantified
[2] https://echometerapp.com/en/scrum-statistics/
[3] 
https://www.parabol.co/resources/agile-statistics/#agile-effectiveness

> Zu oft hat man bei SCRUM den Eindruck:
> Es wird so verkauft, als würde es sämtliche Probleme lösen. In Wahrheit
> hat es aber gar nicht die Mächtigkeit das tun zu können.

Und noch eine neue Iteration desselben Vorwurfs, wie "originell". Na 
klar, wenn windige Berater etwas als Allheilmittel anpreisen oder ein 
Management so dämlich ist, das dann auch noch zu glauben, dann kann das 
so Angepriesene natürlich nur Mist sein. Auch dieses Thema wurde im 
Verlauf des Threads bis zum Erbrechen durchgekaut. Wenn Dich das Thema 
wirklich interessiert, dann lies doch einfach wenigstens mal diesen 
Thread, denn hier sind Deine Fragen alle schon bis zum Erbrechen 
durchgekaut worden.

von Joe (jowu)


Lesenswert?

Ich habe mal kurz in das erste pdf reingeschaut:
https://docs.broadcom.com/doc/the-impact-of-agile-quantified

Steile Ansagen:
-Double Your Productivity
-Improve Quality by 250%
-Cut Time to Market in Half
-Balance Your Team Performance

Sounds great, doesn´t it? Guess what: there are no side effects, of 
course!

Ein T. schrieb:

> Na
> klar, wenn windige Berater etwas als Allheilmittel anpreisen oder ein
> Management so dämlich ist, das dann auch noch zu glauben, dann kann das
> so Angepriesene natürlich nur Mist sein.

Einmal noch kauen und runterschlucken, bitte:
Die wenigsten behaupten, daß es Mist ist. Es mag für manche Situationen 
genau richtig sein.

Die steilen Zahlen aus der Werbebroschüre hingegen würde ich mit 
Vorsicht genießen. Solche Broschüren haben auch Schlankheitsmittel und 
Mittel gegen Haarausfall. Das liest sich wie wenn windige Berater etwas 
als Allheilmittel anpreisen.

von Mark B. (markbrandis)


Lesenswert?

Ein T. schrieb:
> Echt jetzt, noch eine nächste Iteration in diesem Thread? Wenn Du in der
> Lage bist, eine dieser modernen sogenannten "Internet-Suchmaschinen" zu
> benutzen, kannst Du binnen Sekunden mehr als genug statistische
> Untersuchungen sowohl aus wissenschaftlicher, als auch aus
> unternehmerischer Sicht finden, guckstu zum Beispiel hier [1] oder hier
> [2] oder hier [3]. Zumindest die aktuelleren Untersuchungen scheinen
> jedenfalls vorwiegend für agile Methoden zu sprechen.
>
> [1] https://docs.broadcom.com/doc/the-impact-of-agile-quantified
> [2] https://echometerapp.com/en/scrum-statistics/
> [3]
> https://www.parabol.co/resources/agile-statistics/#agile-effectiveness

Hast Du die von Dir verlinkten Dokumente mal richtig durchgelesen? Da 
wird zum Beispiel eine Behauptung aufgestellt wie: "Improve Quality by 
250%".  Die Qualität soll also angeblich um den Faktor 3,5 besser sein. 
Allein: Es wird nirgendwo benannt, wie dieser Wert zustande kommt. Der 
wird einfach so hingeklatscht, und dann soll der geneigte Leser ihn 
glauben.

Bei einem anderen Artikel steht:
"Building a strong agile culture in your organization will result in an 
increased commercial performance of 237%. (Source: JCURV)"

--> Wenn ich mir die Quelle anschauen will, steht da: "Website Expired
This account has expired. If you are the site owner, click below to 
login."
:-(

Wenn Du richtige, seriöse Quellen hast, die klar benennen können:
1.) nach welcher Methodik
2.) und mit welcher Datenbasis
sie auf ihre Ergebnisse kommen, dann poste sie bitte gern.

von Bruno V. (bruno_v)


Lesenswert?

Mark B. schrieb:
>> Building a strong agile culture in your organization will result in an
>> increased commercial performance of 237%.
>
> --> Wenn ich mir die Quelle anschauen will, steht da: "Website Expired

Respekt, wenn ich solch exakte Resultate (273%) bei derart definierten 
Rahmenbedingungen ("strong agile culture") sehe, dann würde ich die 
Quelle erst gar nicht anklicken ;-)

Und es geht noch weiter: Alle auf dem Weg sind, finden, dass er sich 
auszahlt. Und 3/4 würden gar ihre Freunde reinreißen.

von Mark B. (markbrandis)


Lesenswert?

Bruno V. schrieb:
> Und es geht noch weiter: Alle auf dem Weg sind, finden, dass er sich
> auszahlt. Und 3/4 würden gar ihre Freunde reinreißen.

Und 103% aller Firmen, die SCRUM-Schulungen verkaufen, bestätigen dass 
SCRUM sehr gut ist :-)

von Cyblord -. (cyblord)


Lesenswert?

Mark B. schrieb:
> Und 103% aller Firmen, die SCRUM-Schulungen verkaufen, bestätigen dass
> SCRUM sehr gut ist :-)

103%? So viele gibts davon doch gar nicht!

: Bearbeitet durch User
von Ein T. (ein_typ)


Lesenswert?

Joe schrieb:
> Steile Ansagen: [...]

Hast Du bessere Belege? Weil, das fällt ja auf: die Agile-Hasser 
bestehen gerne auf wissenschaftlichen Belegen, bringen aber selbst keine 
bei, nicht einmal angeberische Broschüren von Consultants.

> Die wenigsten behaupten, daß es Mist ist.

Anscheinend hast Du einen anderen Thread gelesen als ich.

> Die steilen Zahlen aus der Werbebroschüre hingegen würde ich mit
> Vorsicht genießen.

Keine Frage.

von Ein T. (ein_typ)


Lesenswert?

Mark B. schrieb:
> Bei einem anderen Artikel steht:
> "Building a strong agile culture in your organization will result in an
> increased commercial performance of 237%. (Source: JCURV)"
>
> --> Wenn ich mir die Quelle anschauen will, steht da: "Website Expired
> This account has expired. If you are the site owner, click below to
> login."
> :-(

Du würdest die "State of Agile"-Umfragen finden, wenn Du wolltest.

> Wenn Du richtige, seriöse Quellen hast, die klar benennen können:
> 1.) nach welcher Methodik
> 2.) und mit welcher Datenbasis
> sie auf ihre Ergebnisse kommen, dann poste sie bitte gern.

Deine Hausaufgaben machst Du bitte selbst.

von Joe (jowu)


Lesenswert?

Ein T. schrieb:

> Hast Du bessere Belege? Weil, das fällt ja auf: die Agile-Hasser
> bestehen gerne auf wissenschaftlichen Belegen, bringen aber selbst keine
> bei, nicht einmal angeberische Broschüren von Consultants.

Öha. Kommt jetzt drauf, wer die Beweislast hat.

Ich meine, daß es genauso wie bei anderen Dingen des Lebens ist. Wenn 
einer ein Haarwuchsmittel preist, das angeblich den Haarwuchs innerhalb 
14 Tagen vervielfacht, würde man schon von ihm den Beweis verlangen. Und 
nicht selbst den Beweis erbringen müssen, das es den Haarwuchs nicht 
ankurbelt. Meine Kritik war analog dem auf die Zutatenliste kucken: Wenn 
da nur Stärke, Geschmacksmittel und Koffein drin sind, dann reicht mir 
das zur Beurteilung.

von Michael B. (laberkopp)


Lesenswert?

Ein T. schrieb:
> Joe schrieb:
>> Steile Ansagen: [...]
>
> Hast Du bessere Belege?

Beweise gegen Religionen ? You must be kidding. Natürlich propagieren 
Religionen bullshit und Scrum ist eine Religion. Dass Scrum nicht 
funktioniert gibt es tausendfach zu beobachten, das wissen sogar 
Scrum-Verfechter und man hört dann nur: "dann hast du es nicht richtig 
gemacht, du musst mehr glauben".

Seit Jahrtausenden fallen Menschen auf Religionen rein, der heutige 
Mensch ist da keinen Deut besser und klüger als im Mittelalter, du bist 
das beste Beispiel. Religionen beginnen immer mit gern geglaubten 
Aussagen "10 Gebote" "agiles Manifest" und verschliessen die Aufen wenn 
es halt nicht funktioniert sondern bezichtigen die Ungläubigen der 
Ketzerei. Und wie das Volk im Mittelalter unter der Kirche leiden musste 
leidet heute halt die Software Branche unter Scrum.

Man baut auch nicht ein Haus nach Scrum: "wie hoch soll es denn werden ? 
Keine Ahnung, aber bau schon mal das Fundament."

von Uwe D. (monkye)


Lesenswert?

Michael B. schrieb:
> Ein T. schrieb:
>> Joe schrieb:
>>> Steile Ansagen: [...]
>>
>> Hast Du bessere Belege?
>
> Beweise gegen Religionen ? You must be kidding. Natürlich propagieren
>
> Man baut auch nicht ein Haus nach Scrum: "wie hoch soll es denn werden ?
> Keine Ahnung, aber bau schon mal das Fundament."

Ja, die äußere Hülle - aber der Innenausbau, der viel teurer ist als der 
Rohbau und wo dann jede Änderung - je fortgeschrittener der Ausbau ist - 
richtig fett ins Geld geht.
Und wenn ich als Auftraggeber noch nicht genau weiß was ich brauche, was 
dann?

Aber immerhin: In Brandenburg baut man so einen ganzen Flughafen.

Mit Verlaub: Was ist mit Deinen Glaubenssätzen?

von Ein T. (ein_typ)


Lesenswert?

Joe schrieb:
> Öha. Kommt jetzt drauf, wer die Beweislast hat.
>
> Ich meine, daß es genauso wie bei anderen Dingen des Lebens ist. Wenn
> einer ein Haarwuchsmittel preist, das angeblich den Haarwuchs innerhalb
> 14 Tagen vervielfacht, würde man schon von ihm den Beweis verlangen.

Ja, natürlich. Ich habe aber im gesamten Thread von niemandem 
irgendwelche Beweise eingefordert, sondern lediglich von meinen 
persönlichen Erfahrungen berichtet: daß nämlich die agilen Projekte, an 
denen ich bislang beteiligt war, wesentlich besser funktioniert haben, 
was die Zusammenarbeit im Team, Erreichung der Zeit-, der Buget- und der 
Qualitätsziele anging, und meine eigene Zufriedenheit bei der und mit 
meiner Arbeit war im Rückblick meist wesentlich größer. (Und ja, ich 
hatte auch schon gute klassische Projekte, allerdings fällt mir auf, daß 
der Anteil der ätzenden Projekte in diesem Bereich wesentlich größer ist 
als mit agilen Methoden.)

Jetzt poppen hier auf einmal Leute auf, die erkennbar nur einen 
Bruchteil des Threads gelesen und ganz offensichtlich überhaupt kein 
Interesse an der Sache außer darüber zu mosern haben, und fordern von 
mir Belege, während sie sich dabei gleichzeitig auf Punkte kaprizieren, 
die in diesem Thread schon längst mehrmals und mehr als erschöpfend 
behandelt worden sind.

von Ein T. (ein_typ)


Lesenswert?

Uwe D. schrieb:
> Michael B. schrieb:
>> Beweise gegen Religionen ?
>
> Mit Verlaub: Was ist mit Deinen Glaubenssätzen?

Er glaubt, er könne mich provozieren, womöglich gar zu einer Antwort auf 
sein Gelaber. Da hat er leider Pech, denn ich weiß: sein Name ist 
Programm. ;-)

von Sherlock 🕵🏽‍♂️ (rubbel-die-katz)


Lesenswert?

Ein T. schrieb:
> Deine Hausaufgaben machst Du bitte selbst.

Wie bitte? Wenn mir jemand etwas andrehen will, muss er mich überzeugen. 
Nicht umgekehrt.

Ich habe mit Scrum und anderen agilen Methoden bereits gute und 
schlechte Erfahrung hinter mir. Ich kann das vernünftig einschätzen. Wer 
das nicht kann, dem rate ich dringend, Erfolgsversprechen nicht einfach 
so zu glauben. Am Besten ist wohl Ausprobieren, wenn es nicht allzu 
teuer wird.

Übrigens: 2001 wurde das Agile Manifest von 17 "Evangelisten" in 
Snowbird, Utah, erstellt und unterzeichnet. Sie haben sich selbst so 
genannt und damit den religiösen Bezug eingeführt.

: Bearbeitet durch User
von Rbx (rcx)


Lesenswert?

Michael B. schrieb:
> Seit Jahrtausenden fallen Menschen auf Religionen rein, der heutige
> Mensch ist da keinen Deut besser und klüger als im Mittelalter,

Interessanterweise sind viele Religiontexte in der Bibel an Sternen 
orientiert.
Und die Sternfiguren wurden in Geschichten verbündelt, weil die früher 
keine Bücher hatten, und nur Verwaltungstexte und Symbole in Stein rein 
hackten usw.
Früher gab es auch noch viele Geschichtenerzähler die herumreisten, die 
sich natürlich auch geistig an vielen Symbolen orientieren mussten.

Idries Shah hatte den Lesern mal in dem Buch "Karawane der Träume" 
empfohlen, in seinem (Leser-)Leben und in der Umgebung Wachstum, 
Entwicklung und Auswirkungen von Sachzwängen zu beobachten.

Ach so und ganz nebenbei: [OT] Imkerreduzierung von 100% auf 5-1%[\OT]

von Sheeva P. (sheevaplug)


Lesenswert?

Bruno V. schrieb:
> Respekt, wenn ich solch exakte Resultate (273%) bei derart definierten
> Rahmenbedingungen ("strong agile culture") sehe

[ ] Du weißt, wie eine statistische Auswertung (von Umfragen) 
funktioniert.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Ich meine, daß es genauso wie bei anderen Dingen des Lebens ist. Wenn
> einer ein Haarwuchsmittel preist, das angeblich den Haarwuchs innerhalb
> 14 Tagen vervielfacht, würde man schon von ihm den Beweis verlangen. Und
> nicht selbst den Beweis erbringen müssen, das es den Haarwuchs nicht
> ankurbelt. Meine Kritik war analog dem auf die Zutatenliste kucken: Wenn
> da nur Stärke, Geschmacksmittel und Koffein drin sind, dann reicht mir
> das zur Beurteilung.

Da Du zu wissen scheinst, welche Zutaten wirksame Haarwuchsmittel 
benötigen, möchte ich Dich aus gegebenem Anlaß herzlich darum bitte, mit 
Dein Wissen (gerne auch insgeheim per PN) zukommen zu lassen. Denn 
mittlerweile bin ich leider in dem Alter, in dem meine Haare von Stellen 
abwandern, wo ich sie zu gerne behalten hätte, und sich anstelle an 
Orten niederlassen, an denen ich wunderbar auf sie verzichten könnte. 
Vielen Dank! :-)

von Uwe D. (monkye)


Lesenswert?

Sherlock 🕵🏽‍♂️ schrieb:
> Ein T. schrieb:
>> Deine Hausaufgaben machst Du bitte selbst.
>
> Wie bitte? Wenn mir jemand etwas andrehen will, muss er mich überzeugen.
> Nicht umgekehrt.
Also im ganzen Thread konnte ich erkennen, dass @Ein T. jemanden 
überzeugen (Predigen - Überzeugen - Bekehren) wollte.

> Übrigens: 2001 wurde das Agile Manifest von 17 "Evangelisten" in
> Snowbird, Utah, erstellt und unterzeichnet. Sie haben sich selbst so
> genannt und damit den religiösen Bezug eingeführt.

Ja und, bei Microsoft gibt es auch Technology Evangelists - eigentlich 
bei allen großen (und wirtschaftlich erfolgreichen) Firmen.

Wer von seinem Produkt nicht überzeugt ist, wird es Niemanden näher 
bringen. Und das hat mit SCRUM auch überhaupt nichts zu tun. Es ist eine 
Lebenseinstellung.

von Sheeva P. (sheevaplug)


Lesenswert?

Sherlock 🕵🏽‍♂️ schrieb:
> Ein T. schrieb:
>> Deine Hausaufgaben machst Du bitte selbst.
>
> Wie bitte? Wenn mir jemand etwas andrehen will, muss er mich überzeugen.
> Nicht umgekehrt.

Da hast Du zweifellos Recht, aber wo siehst Du denn, daß dieser Typ Dir 
oder jemand anderem "etwas andrehen will"?

> Ich kann das vernünftig einschätzen.

Möglicherweise könnte genau diese Überzeugung die größte Gemeinsamkeit 
fast aller sein, die sich bisher an diesem Thread beteiligt haben. :-)

Zu den leicht ironischen Aspekten dieses Threads gehört andererseits 
IMHO auch, daß etliche der hier zitierten Kritiken an agilen Methoden 
explizit darauf hinweisen, daß sie oft falsch angewendet werden. Der 
oben zitierte Michael O. Church zum Beispiel sagt das im zitierten 
Artikel in (gefühlt) jedem dritten Satz, auch bei anderen bekannten 
Kollegen wie Martin Fowler sowie Kent Beck ("make it work, make it 
right, make it fast") finden sich solche und ähnliche Aussagen.

Von Robert C. "Uncle Bob" Martin findet sich sogar ein, wie ich finde, 
sehr sehens- und vor allem hörenswerter Vortrag [1], wie agile Methoden 
häufig zu einem Schatten ihrer Ideen, Gedanken, Prinzipien, ja, ihrer 
selbst geworden sind: "and then came certification". Ich denke an die 
"Regierungserklärung" von Andy Müller-Maguhn [2], nachdem zum 
ICANN-Direktor gewählt wurde, dort insbesondere den Abschnitt mit 
Geschäftsleuten, Juristen, und Geld.


[1] https://www.youtube.com/watch?v=PnwhBP_Lmow
[2] http://www.trend.infopartisan.net/trd1200/t421200.html

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Joe schrieb:

> Da Du zu wissen scheinst, welche Zutaten wirksame Haarwuchsmittel
> benötigen, möchte ich Dich aus gegebenem Anlaß herzlich darum bitte, mit
> Dein Wissen (gerne auch insgeheim per PN) zukomme.

Ich kann nur mit dem Allgemeinwissen dienen, daß Koffein eine gewisse 
Wirkung zu haben scheint und es deshalb Standardzutat in solchen Mitteln 
ist. Persönlich bin ich hier recht gut weggekommen (nur 
Geheimratsecken), aber ich habe es es im meinem Umfeld erlebt, daß bei 
erblich bedingtem Haarausfall die Betroffenen es bereits Anfang, Mitte 
20 merken, daß sich die Haare zu lichten bedingen. Und dann verzweifelt 
alles Seriöse bis Hanebücherne durchprobieren - um sich dann irgendwann 
in das Unvermeidliche zu fügen.

Um die Kurve zum Thema wieder zu bekommen: Mit meinem Vergleich "Blick 
auf die Zutatenliste" bedeutete ich dem Kollegen, daß Scrum und Agile 
nichts Neues darstellt, sondern eine Mischung aus altbekannten 
Ingredienzen ist. Ein solcher Blick kann schon zeigen, daß es schwerlich 
ein Wundermittel sein kann, wenn es nur Standardingredienzien 
beinhaltet. Betrand Meyer meinte mal "What is good is not new and what 
ist new is not good".

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Zu den leicht ironischen Aspekten dieses Threads gehört andererseits
> IMHO auch, daß etliche der hier zitierten Kritiken an agilen Methoden
> explizit darauf hinweisen, daß sie oft falsch angewendet werden.

Wenn ein Manager liest, daß er durch dieses "Agile" erwarten kann, in 
der Firma die Produktivität zu verdoppeln, die Qualität um 250% zu 
verbessern und die Time to Market zu halbieren und sich denkt "Genau das 
brauche ich" - dann passiert doch das, worum es geht bei der ganzen 
Diskussion! Es wird nicht wie beim Arzt geschaut, ob ein Medikament 
indiziert ist oder nicht. Nein, es wird  nicht geschaut, ob Agile zum 
Unternehmen passt, das Agile wird oktroyiert und reingedrückt und 
Skeptiker wie Ketzer verfolgt.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Sheeva P. schrieb:
>> Insofern bleiben wir doch mal bei Deinem Beispiel mit
>> Internationalisierung und Lokalisierung. Solche Funktionen schon früh in
>> einem Projekt vorzusehen ist viel weniger Aufwand, als so etwas
>> nachträglich einzubauen.
>
> Das ist richtig. Angesichts des "Fachkräftemangels" wird aber auch schon
> um einzelne Manntage gerungen. Ich selbst bin ja auch ein Nerd mit wenig
> Neigung und begrenztem Talent, meine Lösungen ständig verkaufen zu
> müssen. Wenn ich beim "Planning Poker" sage "wenn man es gescheit macht,
> 2 Tage, sonst 1 Tag", dann wird nur "1 Tag" gehört. Das Backlog ist ja
> sooo lang! Für eine wirklich sachliche Argumentation bleibt ja in den
> Sprint-Zeremonien keine Zeit - es wird gleich abmoderiert. Das ist der
> Grund, warum ich diese Meetings hasse!

Vielleicht -- bitte versteh' mich nicht falsch, das ist lediglich so 
eine Vermutung -- trägt ausgerechnet Dein Haß auf diese Meetings zum 
Problem bei. Wenn ich auf etwas so gar keine Lust habe oder es sogar 
hasse, dann bin ich meistens auch sehr schlecht darin.

Da sind wir wieder bei den inneren Widerständen, deren Überwindung zu 
den Aufgaben und zum Arbeitsalltag von DevOpslern wie mir gehören: Du 
kannst Deinen Anwendern die benutzerfreundlichste, performanteste und 
schlicht allerbeste Software der Welt zur Verfügung stellen, und sie 
werden diese ablehnen, solange sie sich umgewöhnen müssen und für sich 
keinen Mehrwert darin erkennen können. Anders gesagt: Du mußt die 
Anwender mitnehmen, und sofern ich das richtig verstanden habe, war das 
bei Dir nicht so.

> Sicher. Und wenn sie es nicht begreifen, dann hilft auch kein
> Vorgehensmodell.

So true!

> Exakt. Und Scrum ist kein Ersatz für Information, Qualifikation,
> Erfahrung und Vertrauen.

Nein, das soll es ja auch nicht sein, im Gegenteil: es soll ausgerechnet 
diese Aspekte durch eine formalisierte und gestärkte Kommunikation 
verbessern.

> Ja, und auf die Gefahr, mich zu wiederholen: Scrum wird gerne vom
> Management eingekauft als Wundermedizin.

Leider muß auch ich mich an dieser Stelle wiederholen: wenn das so 
gemacht wird, wird jede agile Methode schon allein dadurch zerstört. 
Nicht nur, weil die Erwartung einer "Wundermedizin" natürlich völliger 
Unfug ist und ich mich sehr wundere, welche Art von "Management" so dumm 
und naiv sein könnte, sich etwas als "Wundermedizin" verkaufen zu 
lassen.

Letztlich geht es bei einer solchen Einführung um Change Management -- 
und wo Manager so inkompetent sind, sich in Dinge einzumischen, aus 
denen sie sich lieber heraus halten sollten, weil sie davon keine Ahnung 
haben... echt jetzt, ist das die Schuld der agilen Methoden? Ich meine, 
auch der Wasserfall ist ja nun nicht dafür verantwortlich zu machen, daß 
es inkompetente Ersteller von Lasten- und Pflichtenheften, und unfähige 
Projektleiter gibt.

> ?!? Ich könnte schwören, daß die strikte Rollentrennung eines der
> Erfolgsrezepte von Scrum ist!
>
> "Der Product Owner
> Der Product Owner vertritt die Interessen des Kunden. Er ist der
> Auftraggeber und möglicherweise auch der Kunde selbst."

Ein PO vertritt zwar die Interessen des Kunden, darf aber in den 
seltensten Fällen der Kunde selbst sein -- und muß in diesen Fällen 
kompetent genug sein, die Interessen des Kunden (wohlgemerkt: nicht den 
Kunden, nur die Interessen) zu vertreten. Wenn ein unfähiger PO nicht 
versteht, daß der Aufwand deutlich steigt, je später bestimmte Dinge 
(Dein Beispiel mit i10n und i18n) umgesetzt werden, ist das haargenau 
exakt dieselbe Situation, wie wenn ein PL das nicht versteht -- und 
insofern hat das nichts mit der Methode zu tun.

Zudem ist der PO ein Organisator, sonst nichts. Er ist kein Vorgesetzter 
und ist nicht weisungsbefugt. Ja, ich weiß es ist schwierig, aus der 
klassischen Denke herauszufinden, aber das ist die Idee.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Sheeva P. schrieb:
>> Joe schrieb:
>
>> Da Du zu wissen scheinst, welche Zutaten wirksame Haarwuchsmittel
>> benötigen, möchte ich Dich aus gegebenem Anlaß herzlich darum bitte, mit
>> Dein Wissen (gerne auch insgeheim per PN) zukomme.
>
> Ich kann nur mit dem Allgemeinwissen dienen, daß Koffein eine gewisse
> Wirkung zu haben scheint und es deshalb Standardzutat in solchen Mitteln
> ist.

Prima, da bekommt "sich etwas in die Haare schmieren" jetzt auch noch 
einen Kreuzverweis zu Kaffee. Danke! :-)

von Rbx (rcx)


Lesenswert?

Sheeva P. schrieb:
> [ ] Du weißt, wie eine statistische Auswertung (von Umfragen)
> funktioniert.

Du eben gar nicht. Könnte man schon lernen, wäre aber bei einem 
Psychologiestudium schon viel leichter.

Kontrollgruppen, passende Mengen, verschiedene Experimentaufbauten usw.
Es gibt auch eine ganze Liste von Problemen diesbezüglich, welche die 
Neutralität stören.
Muss man auch im Hinterkopf haben, das heißt, lerne erstmal solche 
Untersuchungen, bevor du dich daran machst, Datenvergleiche zu 
interpretieren.

Ich wollte dir schon mal was beibringen an Interpretationsbeispielen, 
aber da war ich nicht angemeldet - und als ich angemeldet war, war 
dieses Thema verschlossen.
(Es ging um Benutzerinterpretationen, angemeldet, nicht angemeldet), da 
fehlte aber eine passende Kontrollgruppe, um die Interpretation zu 
neutralisieren, weiß aber nicht mehr welche jetzt, ist schon etwas 
Trickreich.
Darüberhinaus brauchte es auch Korrekturen und Standardisierungen, also 
Objektivierungen.
Wie gesagt, das Thema wurde leider geschlossen, aber du kannst ja mal 
andere Untersuchungen vorstellen, an denen ich mich z.B. orientieren 
kann, und dir verklickern kann, wie du die Interpretationen mehr in die 
Objektivität und Neutralität hinbekommst.
Aber da du die Geschichte von Unix auch nicht recht akzeptierst, bist du 
wohl auch Lernunwillig?
Hauptsache mit dem Finger auf andere zeigen, das kannst du gut.

Bei den Problemen mit Linux warst du früher viel besser drauf.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Rbx schrieb:
> [...]

Was auch immer Du mir sagen möchtest, ist vermutlich wichtig, aber ich 
kann Deinen Ausführungen leider nicht folgen. Bitte entschuldige.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Vielleicht -- bitte versteh' mich nicht falsch, das ist lediglich so
> eine Vermutung -- trägt ausgerechnet Dein Haß auf diese Meetings zum
> Problem bei. Wenn ich auf etwas so gar keine Lust habe oder es sogar
> hasse, dann bin ich meistens auch sehr schlecht darin.

Wenn ich als Nerd etwas nicht mag, dann ist es Pseudokommunikation. Das 
sind dann Rituale oder Skripte, wie in der Kirche, auf dem Standesamt 
oder beim Rapport im Kasernenhof. Ich kann als Techie nicht anders: Es 
steht für mich der Inhalt im Vordergrund, nicht die Form ("Individuen 
und Interaktionen mehr als Prozesse und Werkzeuge").

> Du
> kannst Deinen Anwendern die benutzerfreundlichste, performanteste und
> schlicht allerbeste Software der Welt zur Verfügung stellen, und sie
> werden diese ablehnen, solange sie sich umgewöhnen müssen und für sich
> keinen Mehrwert darin erkennen können.

Man kann die Logik aber nicht umdrehen, und aus der Ablehnung einer 
neuen Software folgern, daß es sich offensichtlich um eine ganz 
besonders benutzerfreundliche und performante Software handeln muß, und 
die Anwender das eben noch nicht gemerkt haben.

>> Exakt. Und Scrum ist kein Ersatz für Information, Qualifikation,
>> Erfahrung und Vertrauen.
>
> Nein, das soll es ja auch nicht sein, im Gegenteil: es soll ausgerechnet
> diese Aspekte durch eine formalisierte und gestärkte Kommunikation
> verbessern.

Und das kann es eben nicht! Wenn die Leute keine Ahnung und keinen Plan 
haben und nicht miteinander können, dann helfen auch keine Rituale was.

> Nicht nur, weil die Erwartung einer "Wundermedizin" natürlich völliger
> Unfug ist und ich mich sehr wundere, welche Art von "Management" so dumm
> und naiv sein könnte, sich etwas als "Wundermedizin" verkaufen zu
> lassen.

Leider ist die Annahme, daß Manager immer eine besonders gute 
Urteilsfähigkeit haben, ein Vorurteil.

> Wenn ein unfähiger PO nicht
> versteht, daß der Aufwand deutlich steigt, je später bestimmte Dinge
> (Dein Beispiel mit i10n und i18n) umgesetzt werden, ist das haargenau
> exakt dieselbe Situation, wie wenn ein PL das nicht versteht -- und
> insofern hat das nichts mit der Methode zu tun.

Das ist ja absolut richtig. Hier besteht absolut kein Dissens. Es gibt 
keine Methode gegen Ignoranz. Ein Saftladen wird durch Einführung von 
Scrum nicht doppelt so produktiv bei Verdreifachung seiner Qualität.

> Zudem ist der PO ein Organisator, sonst nichts. Er ist kein Vorgesetzter
> und ist nicht weisungsbefugt.

Das kenne ich eben anders. Ich möchte jetzt nicht nochmal Quellen 
zitieren müssen. Der PO ist für das Backlog zuständig. Damit bestimmt er 
entscheidend, wie gearbeitet wird. Ich kann nur auf mein Analogbeispiel 
von oben wiederholen, mit dem Bauherrn, welcher bestimmen darf, ob der 
Keller oder das Erdgeschoß zuerst gebaut wird.

Wenn Scrum eine Grundidee hat, dann ist es doch die strikte 
Rollentrennung und Formalisierung der Kommunikation: Der PO bestimmt die 
Arbeitspakete, die Entwickler, wie die Arbeitspakete umgesetzt werden 
und der Scrum Master hat eine reine Moderatorenrolle. Und damit haben 
wir die Probleme: Requirements engineering, Fokus auf User Stories und 
Sprints statt Fokus auf die Architektur und langfristige Ziele.

: Bearbeitet durch User
von Bruno V. (bruno_v)


Lesenswert?

Uwe D. schrieb:
> Und wenn ich als Auftraggeber noch nicht genau weiß was ich brauche, was
> dann?

Dass ein Auftraggeber nicht wissen kann, was er braucht, ist eine 
Binsenweisheit. Zumindest dann nicht, wenn etwas Neues erschaffen wird. 
Und das ist bei SW in den meisten Fällen so (da es keine keine 
nennenswerten "Arbeits- und Materialkosten" wie beim Hausbau gibt)

Bei jeder Entwicklung gibt es "handwerkliche" Tätigkeiten (Schaltplan 
zeichnen, Layout) und "schöpferische" Tätigkeiten (welcher µC und welche 
Verbindungen).

Wer sich des Unterschiedes nicht bewusst ist, wird mit jedem 
Vorgehensmodell scheitern. Nicht mal das: Er wird Dank schöpferischer 
Mitarbeiter Mal erfolgreich sein und Mal nicht und keine Ahnung haben, 
warum. Die "schöpferischen" Anteile stellen sich niemals dadurch ein, 
dass die handwerklichen Tätigkeiten in Rituale gepresst werden.

Bei SW ist es noch viel schlimmer. Ich vergleiche es gerne mit einem 
Gedichtband. Satz und Layout, Rechtschreibung und Grammatik sind 
größtenteils handwerkliche Tätigkeiten, die sich in Regeln packen 
lassen. Analog Coding styles, Code Review, Metriken etc.

Die Arbeit des Dichters hingegen nicht. Egal wie genau ich Reimschemata 
oder Strophen vorgebe.

Mit "Schöpfung" habe ich nach 4 Wochen brüten ein munteres Küken, ohne 
einen stinkenden Klumpen. Egal ob agil oder mit klassischer Glucke.

: Bearbeitet durch User
von Joe (jowu)


Lesenswert?

Bruno V. schrieb:

> Bei SW ist es noch viel schlimmer. Ich vergleiche es gerne mit einem
> Gedichtband. Satz und Layout, Rechtschreibung und Grammatik sind
> größtenteils handwerkliche Tätigkeiten, die sich in Regeln packen
> lassen. Analog Coding styles, Code Review, Metriken etc.
>
> Die Arbeit des Dichters hingegen nicht. Egal wie genau ich Reimschemata
> oder Strophen vorgebe.

Man versucht meiner Meinung nach viel zu viel vorzuschreiben, was 
handwerklich beschreibbar ist. Da will man eine schlechte Codebasis 
dadurch in den Griff bekommen, daß man Regeln vorschreibt, welche 
algorithmisch prüfbar sind. Und vergißt dabei, daß die wirkliche 
Leistung jenseits davon ist. Danke für den Beitrag :-)

Ist analog einer Zeitung in der wirtschaftlichen Krise, wo man dann 
genau den Schriftsatz vorschreibt, vorschreibt, wie groß die Abstände 
zwischen Absätzen sind, wie lang eine Überschrift maximal sein darf, 
nach wieviel Zeilen ein neuer Absatz beginnen muß und dergleichen mehr. 
Man kann sogar bestimmte Stilmittel vorschreiben, in der Art: eine 
Glosse muß mindestens alle 10 Zeilen eine Ironie und zwei Metaphern 
enthalten. Als Ergebnis bekommt man ein einheitliches und aufgeräumtes 
Aussehen der Zeitung; nur ob die Artikel wahr und oder interessant sind, 
das hat man nicht fokussiert. Wenn die Zeitung in Wirklichkeit daran 
krankt, daß die Inhalte einseitig und  langweilig sind, dann war der 
ganze Zirkus für die Katz.

Und bei der Softwareentwicklung ist die eigentliche Leistung jenseits 
von Sprints und User Stories.

von Uwe D. (monkye)


Lesenswert?

Bruno V. schrieb:
> Uwe D. schrieb:
>> Und wenn ich als Auftraggeber noch nicht genau weiß was ich brauche, was
>> dann?
>
> Dass ein Auftraggeber nicht wissen kann, was er braucht, ist eine
> Binsenweisheit. Zumindest dann nicht, wenn etwas Neues erschaffen wird.

Prima, dann sind wir uns ja einig geworden. Komischerweise sehen das 
nicht besonders viele Leute in dem Thread so…

> Und das ist bei SW in den meisten Fällen so (da es keine keine
> nennenswerten "Arbeits- und Materialkosten" wie beim Hausbau gibt)
What? Lies mal den Titel dieses Fadens… Wenn das mal keine Fixkosten 
sind, die PL- und Lenkungsausschuss-Meetings, dazu die Projektmeetings 
aus fachlicher Sicht usw.
Im Absatz vorher hattest Du gerade festgestellt, dass die Anforderungen 
noch nicht feststehen. Verschenkst Du diese Leistungen (inkl. 
Dokumentation), weil sie „nebensächlich“ sind?

Meine Erfahrungen sagen diesbezüglich etwas anderes.

von Uwe D. (monkye)


Lesenswert?

Bruno V. schrieb:
> Die "schöpferischen" Anteile stellen sich niemals dadurch ein,
> dass die handwerklichen Tätigkeiten in Rituale gepresst werden.

Wer hat das denn behauptet?

> Bei SW ist es noch viel schlimmer. Ich vergleiche es gerne mit einem
> Gedichtband. Satz und Layout, Rechtschreibung und Grammatik sind
> größtenteils handwerkliche Tätigkeiten, die sich in Regeln packen
> lassen. Analog Coding styles, Code Review, Metriken etc.

Bei größeren bis großen Projekten gibt es eine nette Abkürzung mit viel 
Wirkung: RAMS.

Das schließt eine Angemessenheit an das Projekt und die Anforderungen 
nicht aus - nur diese Vorgaben allgemein zu geißeln bringt wenig.

: Bearbeitet durch User
von Bruno V. (bruno_v)


Lesenswert?

Uwe D. schrieb:
>> Und das ist bei SW in den meisten Fällen so (da es keine keine
>> nennenswerten "Arbeits- und Materialkosten" wie beim Hausbau gibt)
> What? Lies mal den Titel dieses Fadens… Wenn das mal keine Fixkosten
> sind, die PL- und Lenkungsausschuss-Meetings, dazu die Projektmeetings
> aus fachlicher Sicht usw.

Bei einem Haus planen ein Architekt und ein paar Vorarbeiter und die 
meisten Kosten sind (wasserfallartig) geplante Handarbeit.

Die Komplexität/Innovation/Ungewissheit eines Hauses ist klein gegenüber 
der Gesamtarbeit.

Bei HW und SW dient das meiste von dem, was Du auflistest, die Arbeit 
des Architekten zu unterstützen, also die Anforderungen des Bauherrn zu 
erarbeiten (und natürlich braucht der Bauherr dazu erste Entwürfe) und 
(unter Einhaltung von Gesetzen/Statik/Materialien) in Pläne umzusetzen. 
Die Arbeit der Handwerker ("die Produktion") ist in HW noch sichtbar 
(Schaltplan in Form bringen, Layout, Platinen bestellen und bestücken, 
etc.) in SW vernachlässigbar. Natürlich gibt es Ausnahmen, wo Dutzende 
SW-Entwickler gegen eine sehr detaillierte Spezifikation programmieren, 
z.B. eine neue Steuergesetzgebung oder Geschäftslogik einpflegen. Das 
sind aber nicht die Teile, die scheitern!

Es scheitert auch nicht an Dokumentation. Wenn, dann ist es nur ein 
erstes Indiz, dass die Schöpfung mangelhaft ist. Eine gute Dokumentation 
kann ein gutes Projekt vollenden, aber keines rausreißen.

: Bearbeitet durch User
von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Sheeva P. schrieb:
> Wenn ich als Nerd etwas nicht mag, dann ist es Pseudokommunikation. Das
> sind dann Rituale oder Skripte, wie in der Kirche, auf dem Standesamt
> oder beim Rapport im Kasernenhof. Ich kann als Techie nicht anders: Es
> steht für mich der Inhalt im Vordergrund, nicht die Form ("Individuen
> und Interaktionen mehr als Prozesse und Werkzeuge").

Den Satz "Individuen und Interaktionen mehr als Prozesse und Werkzeuge" 
verstehe ich nicht als "es steht die Form im Vordergrund", und das wäre 
natürlich weder Sinn der Sache, noch erlebe ich das in meiner Praxis.

> Man kann die Logik aber nicht umdrehen, und aus der Ablehnung einer
> neuen Software folgern, daß es sich offensichtlich um eine ganz
> besonders benutzerfreundliche und performante Software handeln muß, und
> die Anwender das eben noch nicht gemerkt haben.

Eine Umgewöhnung ist für jeden Anwender unangenehm, und das gilt nicht 
nur, aber auch für Software. Das kannst Du schon sehr schön in den 
vielen Threads in diesem Forum sehen, wo manche Anwender zum Teil an 
uralten Versionen einer Software festhalten -- nicht, weil ihr Rechner 
nicht damit zurecht käme oder es keine aktuellere Software gäbe, häufig 
sogar kostenlos, sondern weil die neue Software anders aussieht, andere 
Funktionen hat, ... you name it.

>>> Exakt. Und Scrum ist kein Ersatz für Information, Qualifikation,
>>> Erfahrung und Vertrauen.
>>
>> Nein, das soll es ja auch nicht sein, im Gegenteil: es soll ausgerechnet
>> diese Aspekte durch eine formalisierte und gestärkte Kommunikation
>> verbessern.
>
> Und das kann es eben nicht! Wenn die Leute keine Ahnung und keinen Plan
> haben und nicht miteinander können, dann helfen auch keine Rituale was.

Das stimmt, das ist eine Frage der Unternehmenskultur, des Miteinander, 
und vielleicht auch persönlicher Animositäten. Da hilft allerdings 
überhaupt gar kein Modell etwas, weder agile noch klassische.

>> Nicht nur, weil die Erwartung einer "Wundermedizin" natürlich völliger
>> Unfug ist und ich mich sehr wundere, welche Art von "Management" so dumm
>> und naiv sein könnte, sich etwas als "Wundermedizin" verkaufen zu
>> lassen.
>
> Leider ist die Annahme, daß Manager immer eine besonders gute
> Urteilsfähigkeit haben, ein Vorurteil.

Das ist auch nicht meine Annahme, im Gegenteil: nach meinen Erfahrungen 
gibt es im Management anteilig genau so viele großartige Leute und genau 
so viele Nieten wie in allen anderen Bereichen auch.

>> Zudem ist der PO ein Organisator, sonst nichts. Er ist kein Vorgesetzter
>> und ist nicht weisungsbefugt.
>
> Das kenne ich eben anders.

Huch... das macht Deine Perspektive für mich viel besser verständlich.

> Ich möchte jetzt nicht nochmal Quellen
> zitieren müssen. Der PO ist für das Backlog zuständig. Damit bestimmt er
> entscheidend, wie gearbeitet wird.

Jaein: er organisiert in Abstimmung sowohl mit dem Kunden, als auch mit 
dem Team, was in welcher Folge bearbeitet wird. Genau dasselbe machen 
klassische Projektleiter übrigens auch -- und wie bei POs, Managern und 
Entwicklern gibt es dabei gute Leute, mittelmäßige, und... sagen wir, 
die anderen.

> Wenn Scrum eine Grundidee hat, dann ist es doch die strikte
> Rollentrennung und Formalisierung der Kommunikation: Der PO bestimmt die
> Arbeitspakete, die Entwickler, wie die Arbeitspakete umgesetzt werden
> und der Scrum Master hat eine reine Moderatorenrolle. Und damit haben
> wir die Probleme: Requirements engineering, Fokus auf User Stories und
> Sprints statt Fokus auf die Architektur und langfristige Ziele.

Die User Stories sind Teil des Requirements Engineering, andernorts 
werden sie Anwendungsfälle genannt. Letzten Endes sind die 
Geschäftsfälle in Lasten- und Pflichtenheften den User Stories recht 
ähnlich: sie helfen der Kommunikation zwischen Fachlichkeit und 
Entwicklung. Der Unterschied ist, daß User Stories sich stärker auf den 
Anwender und seine Aufgaben und dadurch im Wesentlichen auf das Ziel 
konzentrieren, anstatt den Weg zu fixieren. Was sollte so falsch daran 
sein, die Bedürfnisse der Anwender zu berücksichtigen und ihnen einen 
gewissen Einfluß darauf einzuräumen, welche Features besonders wichtig 
sind und deswegen früher umgesetzt werden sollen als andere?

Ich persönlich erlebe agile Methoden so, daß sie einerseits die Aufgaben 
der klassischen Projektleitung auf mehrere Schultern verteilen und 
dadurch auch Interessenskonflikte vermeiden, und andererseits sowohl der 
Zielgruppe, als auch den Entwicklern mehr Möglichkeiten zur 
Mitgestaltung geben. Wen das an "The cathedral and the bazaar" von Eric 
S. Raymond erinnert, liegt aus meiner Sicht nicht ganz falsch: es geht 
um mehr Mitwirkung, mehr Flexibilität, mehr Teilhabe (ich mag das Wort 
nicht, habe aber kein besseres) der Beteiligten. Und an mir selbst habe 
ich bemerkt: ich bin zufriedener mit meiner Arbeit und ihren 
Ergebnissen, wenn ich daran mitgestalten konnte, anstatt mich in ein 
feinmaschig vorgegebenes Konzept quetschen zu lassen und es einfach 
stumpf herunter hacken zu müssen, manchmal sogar wider besseren Wissens.

Allerdings, auch das gehört natürlich zur Wahrheit, ist das nichts für 
jeden, dieses Mitgestalten. Denn natürlich birgt das am Ende auch zwei 
Bürden: auf der einen Seite muß man dann selbst Entscheidungen treffen, 
und dann auf der anderen Seite auch die Verantwortung dafür übernehmen. 
Das mag schon auf der persönlichen Ebene nicht jeder, und je nach 
Unternehmens- und Teamkultur ist das mit der Verantwortung auch nicht 
immer ein Vergnügen.

Nichtsdestotrotz ist es wohl nach dem, was ich so lese, mittlerweile so, 
daß ungefähr 85% aller Softwareprojekte mit agilen Methoden realisiert 
werden. Da kann ich jetzt jeden Morgen mit Bauchschmerzen zum Daily 
gehen und die Leute in meinem Umfeld dafür hassen, daß sie mir auf den 
Keks gehen. Aber ob mich das am Ende glücklicher machen würde, bezweifle 
ich stark -- und nach meinem Dafürhalten gibt es ohnehin schon zu viele 
Wütende, die ihre Frustration an ihren Mitmenschen auslassen. Da muß ich 
mich nicht einreihen. ;-)

von Sheeva P. (sheevaplug)


Lesenswert?

Bruno V. schrieb:
> Dass ein Auftraggeber nicht wissen kann, was er braucht, ist eine
> Binsenweisheit.

Stimmt. Allerdings wissen Manager, Team- und Projektleiter, und 
Entwickler ihrerseits auch nicht genau, was der Anwender braucht.

von Sheeva P. (sheevaplug)


Lesenswert?

Joe schrieb:
> Man versucht meiner Meinung nach viel zu viel vorzuschreiben, was
> handwerklich beschreibbar ist.

Aber bist es denn nicht Du, der ein Lasten- und ein Pflichtenheft haben 
mag, das alles bis ins kleinste Detail vorschreibt, und dazu einen 
Argus, der mit seinen berühmten Augen argwöhnisch darüber wacht, daß 
sich alles daran hält?

> Da will man eine schlechte Codebasis
> dadurch in den Griff bekommen, daß man Regeln vorschreibt, welche
> algorithmisch prüfbar sind.

Ach Du liebe Güte... wer kommt denn auf sowas?

von Bruno V. (bruno_v)


Lesenswert?

Sheeva P. schrieb:
> Stimmt. Allerdings wissen Manager, Team- und Projektleiter, und
> Entwickler ihrerseits auch nicht genau, was der Anwender braucht.

Natürlich nicht. Wenn etwas neu ist (*) weiß niemand, wie es sein soll. 
Weil man neue Dinge noch nicht kennt und noch keine Erfahrung hat, was 
alles möglich ist und was man braucht.

(*) es geht hier immer nur um neue Dinge. Die (individualisierte) 
Reproduktion bekannter Dinge (also mit wenig Schöpfung) ist trivial und 
als Beispiel untauglich.

von Sheeva P. (sheevaplug)


Lesenswert?

Bruno V. schrieb:
> Natürlich nicht. Wenn etwas neu ist (*) weiß niemand, wie es sein soll.
> Weil man neue Dinge noch nicht kennt und noch keine Erfahrung hat, was
> alles möglich ist und was man braucht.
>
> (*) es geht hier immer nur um neue Dinge. Die (individualisierte)
> Reproduktion bekannter Dinge (also mit wenig Schöpfung) ist trivial und
> als Beispiel untauglich.

Deswegen heißt das ja auch "Entwicklung", weil dabei etwas Neues 
entwickelt wird. Wäre es eine Reproduktion, hieße es "Nachahmung".

von Mark B. (markbrandis)


Lesenswert?

Sheeva P. schrieb:
> Deswegen heißt das ja auch "Entwicklung", weil dabei etwas Neues
> entwickelt wird. Wäre es eine Reproduktion, hieße es "Nachahmung".

Naja, so ganz pauschal stimmt das nicht. Es gibt etliche Beispiele für 
Dinge wo nichts wirklich Neues entwickelt wird. Beispiel: In ein 
vorhandenes Gerät X wird zusätzlich zu den bereits vorhandenen eine neue 
Schnittstelle Y eingebaut. Y ist Bluetooth, oder CAN, oder Modbus, 
oder... irgendwas, such Dir's aus. Nichts wirklich Neues also. Gab es 
schon tausendfach.

Und doch ist es Entwicklung. Frag mal die Leute, die eine bekannte 
Schnittstelle in ein bekanntes Gerät einbauen und während des 
Entwickelns fluchen, weil irgendwas nicht so funktioniert wie es soll 
:-)

von Peter (informatiker78)


Lesenswert?

Mark B. schrieb:
> Sheeva P. schrieb:
>> Deswegen heißt das ja auch "Entwicklung", weil dabei etwas Neues
>> entwickelt wird. Wäre es eine Reproduktion, hieße es "Nachahmung".
>
> Naja, so ganz pauschal stimmt das nicht. Es gibt etliche Beispiele für
> Dinge wo nichts wirklich Neues entwickelt wird. Beispiel: In ein
> vorhandenes Gerät X wird zusätzlich zu den bereits vorhandenen eine neue
> Schnittstelle Y eingebaut. Y ist Bluetooth, oder CAN, oder Modbus,
> oder... irgendwas, such Dir's aus. Nichts wirklich Neues also. Gab es
> schon tausendfach.
>
> Und doch ist es Entwicklung. Frag mal die Leute, die eine bekannte
> Schnittstelle in ein bekanntes Gerät einbauen und während des
> Entwickelns fluchen, weil irgendwas nicht so funktioniert wie es soll
> :-)

Ja. Wenn man etwas neuartiges entwickelt, was es in dieser Form noch 
nicht gegeben hat, dann nennt man es in der Regel eine Innovation.

Meiner Beobachtung nach werden unterschiedliche Begriffe, wie 
Entwicklung und Innovation, oftmals durcheinandergeschmissen.

von Uwe D. (monkye)


Lesenswert?

Peter schrieb:
> Mark B. schrieb:
>> Sheeva P. schrieb:
>>> Deswegen heißt das ja auch "Entwicklung", weil dabei etwas Neues
>>> entwickelt wird. Wäre es eine Reproduktion, hieße es "Nachahmung".
>>
>> Naja, so ganz pauschal stimmt das nicht. Es gibt etliche Beispiele für
>> Dinge wo nichts wirklich Neues entwickelt wird. Beispiel: In ein
>> vorhandenes Gerät X wird zusätzlich zu den bereits vorhandenen eine neue
> Ja. Wenn man etwas neuartiges entwickelt, was es in dieser Form noch
> nicht gegeben hat, dann nennt man es in der Regel eine Innovation.
>
> Meiner Beobachtung nach werden unterschiedliche Begriffe, wie
> Entwicklung und Innovation, oftmals durcheinandergeschmissen.

Wer schon einmal die Aufgabe hatte, eine Alt-App abzulösen - mehr oder 
weniger 1:1 in der Funktionalität, mit einem technologischen Update - 
der weiß, dass das weder trivial noch schnell zu machen ist.
In der Regel gibt es auch keine vollständige Dokumentation und/oder 
Quellcode.

Und die Klugscheißer, die das Go-Live Datum auf den Tag genau angeben 
und wirklich alles wissen, genau die Kosten angeben können, es ja schon 
immer gewusst haben, scheitern immer.

Und weil das genau so ist, gibt es immer wieder die Suche nach der 
perfekten Methode oder Framework, getrieben von Projektleuten, die mit 
ihren Erfahrungen unzufrieden sind.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:

> Aber bist es denn nicht Du, der ein Lasten- und ein Pflichtenheft haben
> mag, das alles bis ins kleinste Detail vorschreibt, und dazu einen
> Argus, der mit seinen berühmten Augen argwöhnisch darüber wacht, daß
> sich alles daran hält?

Nein. Das ist jetzt ein Strohmann-Argument wie aus dem Lehrbuch. Mir zu 
blöd.  Bin raus.

von Joe (jowu)


Lesenswert?

Sheeva P. schrieb:
> Was sollte so falsch daran
> sein, die Bedürfnisse der Anwender zu berücksichtigen und ihnen einen
> gewissen Einfluß darauf einzuräumen, welche Features besonders wichtig
> sind und deswegen früher umgesetzt werden sollen als andere?

Das ist weiter oben schon ausgeführt, welche Schwächen der Ansatz hat.

von Rudi R. (rudi_r)


Lesenswert?

Sheeva P. schrieb:
> Joe schrieb:
>> Man versucht meiner Meinung nach viel zu viel vorzuschreiben, was
>> handwerklich beschreibbar ist.
>
> Aber bist es denn nicht Du, der ein Lasten- und ein Pflichtenheft haben
> mag, das alles bis ins kleinste Detail vorschreibt, und dazu einen
> Argus, der mit seinen berühmten Augen argwöhnisch darüber wacht, daß
> sich alles daran hält?

Ein Lasten- und Pflichtenheft ist essentieller Bestandteil des 
Kontraktes. Es muss ja eine Vertragsgrundlage geben. Scrum schafft das 
nicht ab.

Was die Beschreibung ins kleinste Detail angeht, so muss man diese 
Seuche eindämmen. Da ist Scrum auch kein Mittel. Es ist der gesunde 
Menschenverstand. Wir schreiben 'ne Software, die eine Leistung 
abliefert, die gemessen werden kann. Ich sagte in einem Projekt vor 
zwei, drei Jahren zum IT-Projektleiter: Bloß nichts reinschreiben, wie 
wir etwas umsetzen werden, denn wir wissen heute nicht, ob das die 
richtige Lösung ist. Nicht, dass es der Performanz abträglich ist und 
wir aus der Nummer nicht mehr rauskommen.

Man hat ja oberschlaue Kunden, die wollen Algorithmen mitbestimmen, 
haben dafür das Vokabular nicht, auch nicht das Verständnis. Wir haben 
Verkäufer und Gesamtprojektleiter, da ist genau das gleiche Problem. 
Aber die wirken ständig darauf ein und die Entwickler müssen es 
ausbaden. Ich bin ja Informatiker und ich will ausdrücklich daran 
beteiligt sein, wie wir etwas umsetzen und will nicht durch Fachfremde 
determiniert werden, wie ich meine Lösung umsetze. (Es geht 
ausschließlich ums Wie.) Da fühlt man sich schon degradiert, zu Lasten 
beider Vertragsparteien.

Habe ich leider schon mehrfach solche Grenzüberschreitungen erlebt.

Ich habe auch einen speziellen IT-Projektleiter erlebt, der für flexible 
Ansätze nie zu haben ist. Obwohl Informatiker, denkt er weniger 
abstrakt, dafür sehr konkret und heraus kommen Lösungen, die initial 
mehr Aufwand bedeuten, zu komplizierteren Datenstrukturen führen und wir 
auch noch Performanz links liegen lassen.

von Gerhard O. (gerhard_)


Lesenswert?

Hier ein ketzerischer Einwand von mir:

Hinsichtlich der hier diskutierten Thematik, wirft sich die Frage auf, 
ob der eigentliche Ansatz einer KI Konsultation die Problemlösung 
beschleunigen könnte. Der Schritt vom Pflichtenheft zum Design ist dann 
die Kunst und Fähigkeit die Einzelheiten der Problemlösung, exakt, 
fehlerfrei und komplett spezifizieren zu können.

Ein interaktiver Diskurs zwischen Ing und KI könnte dann zu KI 
generierten ersten Entwürfen führen, die dann von den Entwicklern später 
optimiert und geprüft werden können. Ich könnte mir auch vorstellen, daß 
die KI sehr nützlich zur Erstellung von komprehensiven Test Skripts 
eingesetzt werden könnte.

Die Symbiose Mensch und Maschine könnte sich als durchaus fruchtbar bzw. 
nützlich gestalten. Man müsste halt diesbezüglich Versuche anstellen, ob 
komplexe Fragestellungen zu reproduzierbaren und brauchbaren Ansätzen 
führen könnten.

Hier gilt natürlich die Fähigkeit Problembeschreibungen an die KI 
ausreichend detailliert und fehlerfrei erstellen zu können. Vielleicht 
sollte man KI Kurse einführen, um die Technik professioneller 
Fragekomplexe zu erlernen. In eigenen Firmenarbeiten haben sich KI 
angebotene kleinere Teil-Lösungen ab und zu teilweise durchaus bewährt. 
Das gilt besonders bei Themen, wo man noch nicht zu viel eigene 
Erfahrungen hat.

Ich rate, abzuwarten, aber vorsichtig an der Entwicklung teilzuhaben, um 
die Möglichkeiten und Beschränkungen ständig erfassen zu können. Ich 
sehe jedenfalls der weiteren Entwicklung mit großen Interesse entgegen 
und bin der Ansicht, daß die Zusammenarbeit mit KI-Assistenten durchaus 
nützlich sein könnte.

Duck und weg,
Gerhard

: Bearbeitet durch User
von Michael B. (laberkopp)


Lesenswert?

Rudi R. schrieb:
> Ein Lasten- und Pflichtenheft ist essentieller Bestandteil des
> Kontraktes. Es muss ja eine Vertragsgrundlage geben. Scrum schafft das
> nicht ab.

Doch, darin liegt ja der Reiz.

Vereinbart wird nur eine Programmierdienstleistung mit offenem Ende.

Daher kommt meistens nichts bei raus, siehe Lidl SAP Desaster.

Gerhard O. schrieb:
> einer KI Konsultation

Wenn man selbst zu doof ist, glaubt man gern einem noch dööferen.

KI kann mit den richtigen Fragen helfen, aber auch völligen bullshit 
abliefern.

Für eine komplette Programmentwicklung ost sie zu doof.

Zum aggregieren von Dokumentationen und Diskussionen kann sie helfen.

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.