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)
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.