Announcement: there is an English version of this forum on 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.
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.
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 ...
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?
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.
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.
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"?
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.
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!
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.
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.
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.
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.
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?
Sheeva P. schrieb: > Kannst Du nicht wenigstens ein bisschen kreativer trollen? Kannst du ein bisschen leiser erzählen dass du keine Ahnung hast ?
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.
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.
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".
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
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
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,
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
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.
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.
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.
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.
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.)
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...
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.
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"?
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?
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.
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.
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.
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?
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.
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)
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.
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. :-)
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.
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
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.
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.
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.
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.
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.
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)
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!
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?
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
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
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.
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? :-)
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?
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
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.
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.
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."
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.
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.
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.
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
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«)"
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.
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.
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. :-)
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.
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. :-)
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.
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.
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. :-)
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. :-)
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.
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".
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.
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.
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
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.
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.
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.
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?
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
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.
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.
Franko S. schrieb: > 1. Eclipse ist längst überall rausgeflogen, IntelliJ ist seit Jahren > Standard, Nur in deiner sehr kleinen Bubble.
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. :-)
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.
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.
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.
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
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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
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)
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.
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. :-)
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.
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.
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.
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
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.
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! :-)
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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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
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.
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.
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.
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."
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?
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.
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. ;-)
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
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]
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.
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! :-)
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.
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
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".
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.
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.
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! :-)
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
Rbx schrieb: > [...] Was auch immer Du mir sagen möchtest, ist vermutlich wichtig, aber ich kann Deinen Ausführungen leider nicht folgen. Bitte entschuldige.
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
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
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.
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.
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
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
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. ;-)
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.
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?
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.
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".
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 :-)
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.
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.
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.
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.
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.
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
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.
Rudi R. schrieb: > Ein Lasten- und Pflichtenheft ist essentieller Bestandteil des > Kontraktes. Es muss ja eine Vertragsgrundlage geben. Scrum schafft das > nicht ab. Nein, aber es setzt bewußt auf die Erkenntnis, daß sich die Anforderungen im Verlauf eines Projekts verändern können. > 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. Viel Glück und Erfolg beim Versuch, "gesunden Menschenverstand" rechtssicher in Vertragwerke, Lasten- und Pflichtenhefte einzubinden. :-) > 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. Wir haben aber gleichzeitig auch das Problem, daß Entwickler, Informatiker, Team-, Projekt-, Lasten- und Pflichtenheftverantwortliche meistens wenig bis nichts über die fachlichen und sachlichen Anforderungen wissen. Damit kann man entweder umgehen, indem man zu Beginn eines Projekts alles bis ins Detail haarklein festzurrt... dabei können dann mitunter Monate vergehen. Und das geht jedes Mal wieder von vorn los, wenn sich bei der Implementierung oder bei der Nutzung herausstellt, daß die Planung irgendwo unsinnig war oder sich die Anforderungen geändert haben. Oder man kann damit umgehen, indem man nur Ziele vorgibt und deren Umsetzung den Fachleuten überläßt: den Entwicklern zusammen mit jenen, die am Ende mit dieser Software arbeiten müssen. Das erfordert dann natürlich, daß die Leute miteinander kommunizieren. Das hat dann auch etwas mit Change Management zu tun: wer an der Gestaltung einer Software beteiligt war, entwickelt weniger innere Widerstände dagegen, als wenn sie ihm aufgezwungen wurde.
Sheeva P. schrieb: > Wir haben aber gleichzeitig auch das Problem, daß Entwickler, > Informatiker, Team-, Projekt-, Lasten- und Pflichtenheftverantwortliche > meistens wenig bis nichts über die fachlichen und sachlichen > Anforderungen wissen. Dann, mit Verlaub, ist man wohl eher nicht in der Lage etwas Vernünftiges zu liefern. Man muss zumindest ein gewisses Grundverständnis für die Abläufe beim Kunden haben. Beispiel: Wenn ich null Ahnung davon habe, welche Probleme sich beim Bohren eines Tunnels ergeben, wie soll ich dann erfolgreich eine gut funktionierende Tunnelbohrmaschine entwickeln? > Oder man kann damit umgehen, indem man nur Ziele vorgibt Genau das macht ja eine vernünftig geschriebene Spezifikation: Sie gibt vor, was zu tun ist (die funktionalen Anforderungen), aber nicht wie es umzusetzen ist. Ich glaube daran, dass es möglich ist vernünftige Spezifikationen zu schreiben, wenn man sich mit dem Kunden zusammensetzt und die richtigen Fragen stellt. Die richtigen Fragen zu stellen ist einer der wichtigsten Aspekte der Ingenieursarbeit überhaupt. Dafür muss man aber halt eine gewisse Ahnung von der Materie haben, um die es geht. Halb ironisch: SCRUM ist zumindest zu einem Teil der Versuch, die Fehler auszubügeln, die durch ein schlechtes Requirements Management entstehen. ;-)
Mark B. schrieb: > Ich glaube daran, dass es möglich ist vernünftige Spezifikationen zu > schreiben, wenn man sich mit dem Kunden zusammensetzt und die richtigen > Fragen stellt. Aber nur (das wurde ja schon mehrfach geschrieben), wenn es für beide prinzipiell nicht neu ist. Der Kunde muss das Ergebnis schon bei der Konkurrenz gesehen haben oder ein unzureichendes Vorgängerprodukt kennen. Der Entwickler muss etwas vergleichbares schon umgesetzt haben. Und beide müssen sich das im Zweifel gegenseitig zeigen können. Ansonsten geht nur Iteration. So wie bei allen großen Erfindern oder Produkten. Dass sich jemand etwas Neues überlegt und ein anderer das umsetzt, ist quatsch. Auch das selber umsetzen erfordert viele Iterationen, die verdrängt man nur viel erfolgreicher.
Sheeva P. schrieb: > Wir haben aber gleichzeitig auch das Problem, daß Entwickler, > Informatiker, Team-, Projekt-, Lasten- und Pflichtenheftverantwortliche > meistens wenig bis nichts über die fachlichen und sachlichen > Anforderungen wissen. Das ist nur zur Hälfte richtig. Nun haben Informatiker softwareseitig die Probleme schon mehrfach umgesetzt, in anderen Projekten für andere Kunden, aber es ist immer die gleiche Domäne. Und selbst wenn das nicht gegeben ist: Ein erfahrener Informatiker (mit Liebe zu Algorithmen u. Datenstrukturen) sollte früh involviert sein, damit er frühzeitig erkennt, wo man welche Algorithmen anwenden kann. Bei der Bundeswehr hatte ich 'nen Stabsfeldwebel als Vorgesetzten, der mir mühsam am Telefon erklärt, wie ich 'nen Durchschnitt errechnen müsse. Nun hatte ich ja auch Abitur, war mir von Anfang klar war höflich und habe es über mich ergehen lassen. Nun hat er sich aber mühsam ausgedrückt. Bei mir hingegen ist aber die Formel dafür immer präsent, auch der Begriff arithmetisches Mittel. Nun stelle man sich vor, da wäre jetzt der Bürokollege (Gas-Wasser-Sch...) ans Telefon gegangen und hätte das machen sollen bzw. er hätte es mir erklären müssen. So ist es aber mit der Consultants und den Vertrieblern, die dann versuchen, 1:1 das zu dokumentieren, was der Kunde sich in den Bart brabbelt. Das Beispiel mit dem arithmetischen Mittel ist unterkomplex, aber wie oft erkenne ich beispielsweise, dass mühsam so etwas wie topologische Sortierung beschrieben wird. Problem ist, dass die involvierten Leute den Begriff nicht kennen. Und dann wird auf zehn Seiten etwas beschreiben, obwohl 'ne halbe Seite genügt hätte, wo dann in wenigen Sätzen steht, wie man die Datenstrukturen aufzieht und dass man eine topologische Sortierung anwendet und mit dem Ergebnis dieses und jenes macht. Dem Kunden kann man da keinen Vorwurf machen, aber den Consultants u. Vertrieblern, die meinen, sie während die Durchblicker. Ein weiteres Problem ist, wenn dann dieser Zehn-Seiten-Mist geschrieben ist (Kostet Zeit und Geld!), dass das an einen Entwickler geht, der nicht den Background hat wie ein Diplom-Informatiker und leider lernt das auch nicht jeder Diplom-Informatiker. Hängt von der Anstalt ab; die FH Kaiserslautern hatte es vor 20 Jahren nicht. Und dann müht sich ein nächster tagelang ab. Und dann ist das Ergebnis falsch. Idealerweise wäre frühzeitig das mit der halben Seite dokumentiert gewesen. Idealerweise schlägt der Entwickler, der das bearbeiten soll, mal in der Wikipedia nach oder fragt einen besseren Kollegen. Man würde so viel Zeit sparen und man könnte sogar mit der gewonnen Zeit 'ne kleine Lehrheit machen, wie TopSort funktioniert. Man hätte unterm Strich immer noch Zeit gespart und der Entwickler wäre besser geworden.
Da fällt mir noch eine Story eine. Der Kunde hat beschrieben, wie er Einsätze beim Personal plant, dass es eine rollierende Tabelle gibt, in der die Leute hochrutschen und in den obersten zehn Plätzen wären sie dran. Nun gab es die Anforderung, dass die Personen ihre Tabellenpositionen tauschen können, beispielsweise Platz 21 gegen 38. Und dass die Zeitgewinne- und -verluste miteinander verrechnet werden. Wie dokumentiert man das dann? Der Kunde hat sich Mühe gegeben, zu beschreiben, dass es verrechnet werden muss. Ich saß im selben Raum. Ich hatte es auch verstanden und auch pikobello implementiert, weil ich Anforderungen erkannte, z. B. dass wenn A und B tauschen und unmittelbar darauf noch einmal, dass sich das neutralisiert. Oder Dreieckstäusche. Ich hatte das sehr gut durchdrungen. Tests waren da. Ein Problem war: In dem Moment, wo getauscht wird, weiß man ja noch gar nicht, wann in der Zukunft die Einteilung erfolgt wäre. Ich führte eine Zeitstempelklasse mit Identität ein. Schön objektorieniert. Der Wert darin konnte aber null sein, was ja auch richtig ist. Dafür war es da. Nun hat es aber der minderbemittelte Chef nicht verstanden und hat Zeter und Mordio geschrien, weil ein anderer Entwickler es auch nicht verstanden hat und in eine NullPointerException lief. Nun war es aber gut dokumentiert und irgendwo hört die Verantwortung auch auf. Wenn er es falsch verwendet trotz guter Dokumentation, warum bin ich da schuld. Ich war da sowieso auf einer Abschussliste und bekam alles ab. Ich spürte es auch körperlich. Es hatte auch keiner gefragt, warum ich das denn so gemacht habe, es wurde nur runtergeputzt und herumgeschrien. Irre. Auch das war Scrum. Es hängt natürlich viel von den Akteuren haben. Ich bin von zurückhaltender Natur und das verwechseln viele mit Dummheit. Glücklicherweise war ich dann wenige Monate später raus aus dem Laden und es gibt ihn auch nicht mehr. Die beiden Gründer scheinen sich zerstritten zu haben.
@Rudi, sorry - nimm‘s nicht persönlich: Wenn ich Deine ewig langen Einlassungen lese, ausgeschmückt mit Anekdoten und persönlichen Wertungen, dann wachsen in mir Zweifel, ob Du wirklich Teamplayer sein willst. Und das ist ausgerechnet bei agiler Arbeitsweise wichtig.
:
Bearbeitet durch User
Uwe D. schrieb: > @Rudi, sorry - nimm‘s nicht persönlich: Wenn ich Deine ewig langen > Einlassungen lese, ausgeschmückt mit Anekdoten und persönlichen > Wertungen, dann wachsen in mir Zweifel, ob Du wirklich Teamplayer sein > willst. > Und das ist ausgerechnet bei agiler Arbeitsweise wichtig. Mein Problem mit seinen Beiträgen ist eher, dass er hauptsächlich trivialen Kram beschreibt und glaubt er wäre damit der technische Overlord. Mag in seiner Umgebung vielleicht auch so sein, unter Blinden ist halt der Einäugige der König.
Rudi R. schrieb: > Ich war da sowieso > auf einer Abschussliste und bekam alles ab. Ich spürte es auch > körperlich. D.h. sie haben dich angeschossen?
Mark B. schrieb: > Sheeva P. schrieb: > >> Wir haben aber gleichzeitig auch das Problem, daß Entwickler, >> Informatiker, Team-, Projekt-, Lasten- und Pflichtenheftverantwortliche >> meistens wenig bis nichts über die fachlichen und sachlichen >> Anforderungen wissen. > > Dann, mit Verlaub, ist man wohl eher nicht in der Lage etwas > Vernünftiges zu liefern. Man muss zumindest ein gewisses > Grundverständnis für die Abläufe beim Kunden haben. Ach Mark, das meine ich doch: daß es sinnvoll ist, mit dem Kunden zu reden. > Beispiel: Wenn ich > null Ahnung davon habe, welche Probleme sich beim Bohren eines Tunnels > ergeben, wie soll ich dann erfolgreich eine gut funktionierende > Tunnelbohrmaschine entwickeln? Mit Tunneln kenne ich mich nicht aus, sorry. >> Oder man kann damit umgehen, indem man nur Ziele vorgibt > > Genau das macht ja eine vernünftig geschriebene Spezifikation: Sie gibt > vor, was zu tun ist (die funktionalen Anforderungen), aber nicht *wie* > es umzusetzen ist. Dann möchte ich allzu gerne einmal eine dieser "vernünftig geschriebenen Spezifikationen" sehen. Die, die ich kenne, gehen nämlich ins Detail, wo Freiheit geboten wäre, und ergehen sich in Allgemeinheiten, wo genauere Darstellungen nötig wären. > Ich glaube daran, dass es möglich ist vernünftige Spezifikationen zu > schreiben, wenn man sich mit dem Kunden zusammensetzt und die richtigen > Fragen stellt. Die richtigen Fragen zu stellen ist einer der wichtigsten > Aspekte der Ingenieursarbeit überhaupt. Dafür muss man aber halt eine > gewisse Ahnung von der Materie haben, um die es geht. True. > Halb ironisch: > SCRUM ist zumindest zu einem Teil der Versuch, die Fehler auszubügeln, > die durch ein schlechtes Requirements Management entstehen. ;-) Naja, es arbeitet daran, einige dieser Fehler zu überwinden, indem es Kunden und Entwickler zusammenzubringen versucht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.