Ich kam 2008/9 mal in Kontakt mit Scrum... Ich fand das damals nicht in Gänze falsch, wenngleich ich damals schon Missstände sah, dass beispielsweise für Refaktorierung keine Zeit gelassen wurde, dass keine Zeit damit verbracht, grundsätzlich architektonische Entscheidungen zu treffen. Ich erinnere mich gut, wie damals 2008/9 ein Entwickler begann, 2 mal 40 Klassen zu schreiben, die sich nur geringfügig unterschieden und es steckte ein System dahinter. Das kann natürlich in jedem anderen Entwicklungsmodell auch passieren, aber wenn jeder Entwickler für sich erstmal "wurschteln" darf und das Sprint-Ende naht, fördert man kurzfristiges denken. Ich habe mich damals hingesetzt und die Sache aufgeräumt (also so richtig eingedampft bei gleich bleibender Funktionalität) und ich erntete keinen Dank, sondern Unverständnis. Nun bin ich schon wieder in einer Situation, in der Sprints geplant werden und ständig zieht man mich in dämliche Teams-Besprechungen. Ein Problem ist auch, dass zwei Entwickler, deren Hintergrund ich nicht kenne. sich sehr schwer tun, aber man lässt sie machen. Dass eine eine seltsame architektonische Entscheidung von dem einen getroffen wurde, sprach ich an. Repariert wurde sie nicht. ich bin ja eigentlich nur beratend dabei, weil ich viel Erfahrung habe, generell, mit unseren Use-Cases und unseren Frameworks. Die Arbeit macht mir eigentlich Spaß, bin Informatiker mit Leidenschaft, wenn nur diese dämlichen Besprechungen nicht wären und dieses Scrum. Scrum kann nicht funktionieren, wenn da alle im Team sind und es niemanden gibt, der architektonische Richtungsentscheidungen trifft, was er aufgrund seiner Erfahrung und seiner Kompetenz auch tun kann. Ich bin Diplom-Informatiker mit 15 Jahren Berufserfahrung und treffe plötzlich auf Leute, die gerade frisch mit ihrem Bachelor eingestiegen sind oder - noch schlimmer - von einer Coding-School kommen. Da ich ja auch mal als junger Dachs angefangen habe, finde ich es gar nicht so schlimm, wenn Berufsanfänger erstmal nicht so viel Verantwortung tragen, dass dadurch ein Projekt riskiert wird, denn das befürchte ich ja gerade. Ich finde es schlimm, wenn ich von einem Entwurfsmuster spreche und ich in leere Gesichter gucke, weil die das nicht kennen. Ich sehe auch nicht mehr, dass jemand UML-Diagramme malt, auf Papier, um eine Idee zu durchdenken, zu verfeinern. Mich hat das schon als Student interessiert und ich malte für mich diese Diagramme, verwarf natürlich auch häufig Ideen. Letztendlich hat es mich reifen lassen. Bin ich Teamplayer oder bin ich es nicht? Die Menschen wissen, dass sie sich auf mich verlassen können, dass ich immer hilfsbereit bin. Das sagen sie mir auch, ob im Beruf oder auch außerhalb. Nur geht mir Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen Leuten durchdringen kann. Dann wünsche ich mir häufig, dass diese Leute ihr Zeug für Benutzeroberflächen dengeln, wo sie nicht viel falsch machen können und wenig mit mir zu tun haben. Wir geht es mit euch bei diesem Thema? Nutzt ihr auch Scrum? Nerven euch auch die Meetings? Ich bin ja Informatiker geworden, weil ich auch eine bestimmte Persönlichkeitsstruktur aufweise. Ich kann mich hinsetzen und Dinge durchdenken, programmieren... darin kann ich regelrecht aufgehen. Oder Probleme analysieren. Gestern konnte ich live ein Problem beobachten, weil dem Kunden meine Nummer gegeben hat. Er rief mich an, ich schaute es an, erstmals. Ich habe nach 20 Minuten die Problemursache verstanden. Das Problem nervt aber täglich seit neun Monaten. Das sind die Momente, in denen ich einen Informatiker-Stolz verspüre. Natürlich sehen jetzt die Kollegen blöd aus, die nach neun Monaten immer noch gesagt haben: So genau wissen wir nicht, wo das Problem liegt. Die haben sogar noch Stacktraces dokumentiert, die mit dem Problem gar nichts zu tun haben. Ich befürchte, viel Potenzial geht dadurch verloren, dass Menschen wie ich, die einfach nur einer Sache aufgehen wollen, daran durch Besprechungen und Sozialtänze abgehalten werden. Meine Kompetenz ist ja nicht vom Himmel gefallen, sondern ist das Ergebnis vielen Lesen, Denken und Machen. Aber wird das noch goutiert? Ein Projekt, nur mit mir alleine, das wär's doch.
Nur kurz am Rande, meine Firma hat sich durch mehrfache tägliche Meetings und Besprechungsrunden, mit Kaffee und Keksen oder Plätzchen, regelrecht zugrunde gerichtet. Ab 2015 "durften" wir dann alle mit einer mageren Abfindung zu Hause bleiben. Aber das nur nebenbei.
Oh, ein Scrum-Rant - etwas ganz kreatives /s Nein, Scrum ist nicht schuld, dass das Team kacke ist. Auch nicht, dass keine Architekturüberlegungen angestellt, kein Refactoring betrieben oder zu viele Meetings abgehalten werden. Und ja, oft wäre es effizienter, wenn der Experte das alleine runtercoden würde. Und schönen, wenn man in einem Team aus lauter fachlich interessanten Gesprächspartnern wäre. Mit deiner Erfahrung solltest du aber auch wissen, warum das oft nicht geht bzw. auch kacke sein kann.
Wenn das Team nicht passt oder nur bremst, sollte man sich ein anderes Team suchen, oder nach ein paar versuchen sich ein eigenes suchen oder wenn man es gar nicht ertragen kann allein weiter machen. Hab ich vor 30 Jahren mit angefangen und nie bereut. MfG Michael
Man kann natürlich aussen das Etikett "Scrum" draufschreiben (z.B. um
gegenüber dem Management oder den Aktionären auf den Schlamm zu hauen)
und innen drinnen Stress und Hektik verbreiten und gegen grundlegende
Prinzipien verstossen ...
Ich persönlich finde ja den "kleinen Bruder" XP (extreme programming)
wesentlich besser für die Software-Entwicklung geeignet (z.B. "pair
programming"). Sehr schön beschrieben in den Büchern von Robert C.
Martin ("uncle bob", best buddy von Kent Beck: Agiles Manifest).
Nützt nur alles nichts, wenn du keinen Einfluss auf die Abläufe hast.
Mein Beileid.
Michael O. schrieb: > Wenn das Team nicht passt Bei uns hieß es "Du passt nicht ins Team". Dabei genügte es schon wenn jemand in der Frühstückspause Gemüsesticks aß, während alle anderen lecker Mettbrötchen mit Zwiebeln gegessen haben. Da war das Mobben im Wesentlichen schon vorprogrammiert. Dagegen werden Heute Vegetarier groß geschrieben.
Scrum wurde den Managern lange Zeit als universelle Lösung zahlreicher Mängel beworben, um im Anschluss Schulungen für Scrum durchführen zu können. Dadurch wurden falsche Erwartungshaltungen gefördert. Man hat versäumt, die Probleme auf konstruktive Art zu lösen. So habe ich das in zwei Firmen erlebt. In der ersten Firma hat man irgendwann aufgehört, Software zu entwickeln (mein Ende dort). In der zweiten Firma hat man die Probleme gelöst und konnte mit Scrum weiter arbeiten. Inzwischen arbeite ich quasi in einer dritten Firma agil, nicht nach Scrum, und es läuft ebenfalls gut.
Wieso schon immer musste man sich austauschen. Gibt Menschen, die das nicht drauf haben, weil deren Persönlichkeit dafür uneingeengt ist. Also nicht Teamfähig z. B. Menschen mit Persönlichkeitsstörungen, die auf andere toxisch wirken, und auch krankhaft sich au andere Menschen auswirken. Solche Patienten sind eindeutig hier im Forum unterwegs. Solche Typen werden als Einzelkämpfer alleine gelassen oder als Leiter, und da hast Du dann ganz schnell das Problem, wenn die leiten, dann würden normale Menschen wegrennen... Andere verbrennen... burnout... Deshalb ist das schwierig mit solchen Typen zu arbeiten, klar können manche von denen auch etwas. Aber heutzutage gibt es eigentlich gar keine Projekte mehr, die man ohne Austausch machen kann. Ich frage mich, ob es jemals ohne ging, und dieser Mythos vom Kellerkind ist auch etwas fragwürdig. Ich glaube eher, dass das diese genannten Persönlichkeiten nehmen, um sich ins Rampenlicht mal wieder zu stellen, um von anderen die Leistungen und das Ansehen abzugreifen. Ja manche "Maßnahmen" sind ganz toll solche Typen zu entlarven und dann sollte man auch entsprechend das Projekt kündigen oder die Leute fristgerecht an die frische Luft setzen, um die Allgemeinheit zu erhalten. Ich denke mal entsprechende Reaktionen zeigen allen deutlich auf, wo das Problem wirklich liegt.
Scrum ist genial. Es definiert dass alle Entwickler gleich gut und austauschbar sind. Es definiert eine Velocity so dass man als Management eine Messlatte für ständige Produktivitätssteigerungen hat. Es überlässt alle Verantwortung dem Team und Kunden, da ist man als Management fein taus wenn es wieder mal scheitert. Es erlaubt es, die Definition dessen was eigentlich implementiert werden soll on the fly zusammenzustreichen bis es dem kläglichen Rest entspricht, den man trotz aller Meetings mit dem Haufen Computerspielzocker von denen kein einziger programmieren kann hinbekommen hat, 100% Planerfüllung. Scrum hat Ähnlichkeit mit dem Hype Lean Produktion, das war die Sau aus Japan die man in den 1990er Jahren durch jede Fabrik gejagt hat. Dass Japan inzwischen damit zum Entwicklungsland zurückgefallen ist mit halben Löhnen wie in Deutschland, na ja, weiss hier ja kein Schwein. Scrum schafft dasselbe.
Frank E. schrieb: > Man kann natürlich aussen das Etikett "Scrum" draufschreiben (z.B. um > gegenüber dem Management oder den Aktionären auf den Schlamm zu hauen) > und innen drinnen Stress und Hektik verbreiten und gegen grundlegende > Prinzipien verstossen ... > Das kann sein und schließe ich auch nicht aus. 2008/9 hatte ich bessere Erfahrungen mit Scrum gemacht. Es kann ja auch speziell an den Personen, die gerade involviert sind. > Ich persönlich finde ja den "kleinen Bruder" XP (extreme programming) > wesentlich besser für die Software-Entwicklung geeignet (z.B. "pair > programming"). Sehr schön beschrieben in den Büchern von Robert C. > Martin ("uncle bob", best buddy von Kent Beck: Agiles Manifest). > Das Buch "extreme programming" habe ich mir während des Studiums gekauft. Ich müsste es mal wieder lesen, denn nur Pair Programming blieb mir in Erinnerung. Tatsächlich wird Pair-Programming nur wenig Zeit gegeben, obwohl da ein Greenhorn von einem Erfahrenen, der ich ja mittlerweile bin, sehr gut lernen kann. Aber auch nicht alles kann ich per Pair-Programming umsetzen, gerade dann, wenn man algorithmisch tiefer in einer Materie einsteigen muss. Ich kann im Pair-Programming mal zehn Minuten abschweifen und das Beobachter-Muster erklären, das ist was architektonisches, aber ich kann nicht mal locker aus der Hüfte das große Fass der Graphentheorie aufmachen, Kruskal erklären und erläutern, warum unser konkretes Problem zum Problem mit den minimalen Spannbäumen passt. Ich bin auch zu der Überzeugung gelangt dass in höheren Führungsebenen die Verantwortlichen gar nicht wissen, dass manchmal auch harte algorithmische Nüsse geknackt werden müssen. Die halten alles für Architektur und man müsse nur einen Baustein dem anderen hinzufügen. Die halten die sehr denklastige und kreative Entwicklerarbeit für Fließbandarbeit.
Du diskutierst hier 3 Sachen, die im Grunde nichts miteinander zu tun haben, weil eines das andere nicht impliziert: 1) Verhalten von Jungspunten 2) zu viele Meetings 3) schlechtes Schrum Zu 1) ist zu sagen, daß ich das auch mitbekommen habe: Die Fraktion "Ich habe meine Thesis verteidigt" ist darauf getrimmt, alles perfekt darzustellen, hat aber nicht kapiert, dass sie nicht viel können und noch lernen müssen. Sie sind extrem selbstbewusst, weil sie in ihrem schmalen Studium nichts Anspruchsvolles zu tun hatten. Dass sie keine Konzepte machen, würde ich aber nicht pauschal auf Jugend schieben. Das erlebe ich bei den Erfahrenen auch. Ist eine Frage der Person und Einstellung. Konzepte zu machen, ist bei größeren Projekten absolute Pflicht, leider hacken die meisten Programmierer nur in den Tag hinein und konzeptionieren, während sie Programmieren. Die muss man umerziehen oder aussortieren, d.h. nur Aufgaben geben, die sie allein mit sich abarbeiten können. Zu 2): Dass es zu viele Meetings gibt, liegt an der ineffizienten Gestaltung von Besprechungen und der mangelnden Vorbereitung: Es wird nicht im Vorfeld investiert und damit der Tatsache Rechnung getragen, dass dort mehrere die Daumen drehen, beim Zuhören und die Zeit verstreicht. Das muss effizient laufen, geht aber nicht, wenn jeder unvorbereitet alles aus dem Stehgereif macht. Das aber ist der Fall, weil sie von einem Treff zum Nächsten stolpern. Da deshalb die meetings nicht nachbereitet werden, weil keine Zeit ist, verpufft die Wirkung und verbunden mit der Unfähigkeit, Beschlüsse zu fassen, werden die Themen weitergeschleppt, und wieder aufgewärmt. Da das Folgemeeting aber erst Tage später stattfindet, ist es aus dem Kurzeitgedächtnis raus und die Tiefe der Diskussion muss neu aufgebaut werden. Damit bleibt es immer flach! Zu 3) Scrum wird heute überall angewendet und misachtet, daß es nur dann funktioniert, wenn alle im Team in etwa dasselbe können und das gleiche Knowhow haben. Nur dann macht es Sinn, Aufgaben zu splitten und sich das selbständig aufzuteilen und es auch zusammen zu planen. ist das nicht der Fall, sollte eine kompetente Person die Planung übernehmen, was aber wieder heißt, wie bei Punkt 1 angeführt, Dokumente zu verfassen und Konzepte zu machen. Ich sehe aber das Gegenteil: Die Entwickler treffen sich in einem großen Team, nennen es Scrum, es macht aber jeder was anderes und sie können sich weder gegenseitig helfen, noch den anderen verplanen. Auch da spielt es eine Rolle, wie transparent ein Entwickler arbeitet. Wenn du nicht weißt, welches Konzept seine SW verfolgt, kannst du auch nicht eingreifen oder beihelfen. Scrum wird einfach in vielen Firmen völlig falsch angewendet.
Michael B. schrieb: > Es definiert dass alle Entwickler gleich gut und austauschbar sind. Da liegt der Hase im Pfeffer: Das ist nur selten der Fall! Es gibt 2 unterschiedlich gelagerte Aufgabenpaletten: 1) Forschende und anspruchsvolle sowie breit gefächerte Themen, z.B. die Entwicklung eines neuartigen Geräts mit HW, SW, Mechanik und Software für Datenprozessierung 2) Umsetzende und begrenzt anspruchsvolle, schmal gefächrte Themen in jeweils einem Teilgebiet, wo es auf Effizienz ankommt. In Abteilung 1 brauchst Du breit aufgestellte Leute, die sich stark ergänzen und damit die Breite und Tiefe schaffen. Die müssen flexibel und dynamisch sein. Diese Abteilungen wirken durch Qualität / Kosten. Im Extremfall kann jeder Experte etwas anderes. In Abteilung 2 brauchst Du Leute mit konzentriertem Wissen und eingeübten Methoden, die sehr präzise ihre Aufgaben erledigen, um das Tempo und die Termine zu schaffen. Diese Abteilungen wirken durch Quantität / Kosten. Im Extremfall können alle dasselbe. Nur in der Abteilung 2 macht Scrum mit selbständiger Aufgabenvergabe und Umverteilung der Tätigkeiten Sinn. Dort kannst Du Teilaufgaben so verteilen, wie threads auf einem MultiCore-Prozessor. Je mehr eine Firma forscht, neues entwickelt und breit aufgestellte Leute hat, desto weniger macht Scrum Sinn. Scrum ist am Besten für Zulieferbetriebe und Abteilungen geeignet, die z.B. nur Software für MCUs machen oder sich ums Linux kümmern. Auch Software für IT- und Serverlösungen kann man so managen. Wenn aber eine Kleinfirma oder Entwicklungsabteilung aus 10 Leuten besteht, wo 2 Mechanik, 2 Elektronik, 2 die firmware und 2 das Linux machen und die restlichen beiden PM - dann kriegst du da kein Scum rein. Wie auch?
Es gibt einfach Tätigkeiten, die man gut in kleine Teilchen zerschnippeln kann, und solche, wo man es besser lässt. Hardware ist meist letzteres, ausßer sie besteht aus irgendwelchen Modulen. Eine komplexe Platine sollte man z.B. nicht in kleine Teilbereiche zerschnippeln und welchselweise unterschiedliche Mitarbeiter machen lassen, weil dann die Blöcke nicht aufeinander abgestimmt sind. Was bei Hardware aber zentral ist. Und wenn nicht der gleiche Entwickler die Inbetriebnahme braucht, dauert alles viel länger, weil sich die anderen erst mal einlesen müssen. Außerdem brauchts jemanden der sich ein stimmiges Gesamtkonzept einsetzt. Und dieses pseudo-Scrum das die Firmen gern verwenden, tötet oft jede Motivation, sich persönlich für irgendwas zuständig zu fühlen. Ich musste scho so arbeiten, beim letzten Arbeitgeber. Scrum hat man dort so verstanden, dass die Mitarbeiter den sich immer schneller ändernden Anforderungen agil wie Rehlein hinterherspringen. Seit man das so handhabt, kamen eine Menge teurer Prototypen heraus, aber das Projekt hate bei meinem Weggang schon 2 Jahre Verzögerung. Übrigens nicht wegen der Elektronik. Die Lieferanten und die Fertigung sind immer noch keine "springenden Rehlein" und haben - huch - Lieferzeiten.
[OT] Bernd schrieb: > aus dem Stehgereif Nur, weil mir dieses so oft verwendete und fast genauso oft falsch geschriebene Wort fast das Auge auskratzt: "aus dem Stegreif" verkündeten die berittenen Boten der Herrschenden relativ unwichtige Botschaften. Für diese Botschaften lohnte es sich nicht mal, extra vom Pferd abzusteigen. - https://www.geo.de/geolino/redewendungen/8166-rtkl-redewendung-aus-dem-stegreif - https://www.google.com/search?q=aus+dem+stegreif+machen+redewendung - https://gfds.de/aus-dem-stehgreif/ - https://de.wikipedia.org/wiki/Stegreif [/OT]
:
Bearbeitet durch Moderator
Na Lothar, du zeigst aber Rückrad mit deinem Post. Solche Fehler sind doch Gang und Gebe. Denke ich. Also meine ich. Vom höheren sagen. Wer zu erst kommt, malt zu erst! :) Btw. Rudi R. ist wieder da!
Moin, Lothar M. schrieb: > Nur, weil mir dieses so oft verwendete und fast genauso oft falsch > geschriebene Wort fast das Auge auskratzt Du musst mal ein bisschen tollleranter sein, Der Mensch ist doch keine Maschiiene, die sich immer nur an Stantarts haelt ;-) scnr, WK
Da sind ja gleich 4 Fehler auf einmal drin: Statt Rückrad, Gebe, höheren und malt Lautet es: Rückgrat, Gäbe, hören und mahlt Das klingt ja sonst so, als wenn bei der Ankunft, noch auf die Schnelle hektisch ein Bild gemalt werden muss.
Marcel V. schrieb: > Da sind ja gleich 4 Fehler auf einmal drin: > Ach? Ja sowas. Ich hätte meinen Beitrag vielleicht in Ironie-tags setzen sollen.
Max B. schrieb: > Ach? Ja sowas. Ja, spätestens bei Maschine und Standard habe ich es jetzt auch gemerkt.
Marcel V. schrieb: > Da sind ja gleich 4 Fehler auf einmal drin: Kriegst du für die Fehlersuche wenigstens ein Endgeld?
Le X. schrieb: > Endgeld? Oder schlimmer noch: das allseits beliebte Entgeld. Aber lasst mal stecken: ich schrieb doch, dass das OT ist! Lassen wir die Scrummer wieder zum wohlverdienten Wort kommen.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Lassen wir die Scrummer wieder zum wohlverdienten Wort kommen. Gerne, dann schreibe ich noch einen Punkt dazu: Ich kann mich nicht erinnern, wo es hier von wem verfasst wurde, aber es gab schon eine Diskussion um Scrum, dem man eine interessante Information entnehmen konnte: Scrum ist bereits >20 Jahre alt und die Personen, die es entwickelt haben, taten dies aus ihrer Erfahrung heraus, die sie in ihrer Karriere mit Firmen und Entwicklern sowie Software-Prozessen und -Anforderungen gesammelt hatten. D.h. Die Gründe, sich Scrum auszudenken, beziehen sich Strukturen, die sie in den 1990er-2000er Jahren kennengelernt haben! Konkret waren das schwerpunktmäßig die Entwicklungs-Strukturen in den US-amerikanischen und japanischen Firmen Mitte der 1990er! Die dort tätigen Entwickler hatten wiederum ein Ausbildungsniveau der 1980er-1990er Jahre und hatten mit völlig anderen Problemen bei der SW-Erstellung zu tun. ES gab völlig andere Probleme, andere SW und andere Tools. Jetzt tut man Folgendes: 1) Man verwendet eine Sache, die sich auf 1980er Bildungsniveau bezieht, auf Personen, die heute schwerpunktmäßig zwischen 25 und 35 sind, also zwischen 2000 und 2010 ausgebildet sind, so als habe sich in 30 Jahren nichts geändert. In den frühen Jahren der SW-Entwicklung gab es praktisch keine Informatikausbildung. Das waren alles Selbstlerner. Die meisten SW-Entwickler hatten das nicht gelernt und waren fachfremd. 2) Man wendet es auf Personen des deutschen und europäischen Bildungssystems an, dass sich trotz Bologna noch stark vom US-amerikanischen und speziell dem japanischen System unterscheidet. In Japan studieren die meisten Studenten irgendwas und in beiden Ländern ist die Ausbildung kürzer. Das ist auf DE nicht einfach so zu übertragen. 3) Man verwendet es auch außerhalb der Software und das ist aber unrichtig. Zwar sind auch hierzulande auch heute noch viele Programmierer fachfremde Quereinsteiger ohne Hintergrundausbildung, das ist in der Hardware aber nicht so. Elektro und Mechanikkontrukteure haben fachorientiert gelernt und studiert. Man tut also so, als ob das, was einst woanders, in einer anderen Zeit für andere Personen galt, nun für alle und jeden in jeder Firmen gelten müsse. Das ist nicht nur unlogisch, sondern auch gefährlich, weil es vorhandene - oft bessere - Strukturen zerstört und behindert. Es wird die Individualität untergraben und einer Gleichmacherei untergeordnet. Wer ungeprüft und unreflektiert überall Srum auf jeden anwendet, fördert den Niedergang des ehemaligen guten deutschen Standards hin zu einem weltweiten Mittelmaß. Bologna war der erste Schritt dahin und Scrum ist der Sargnagel.
Marcel V. schrieb: > Dagegen werden Heute Vegetarier groß geschrieben. Vegetarier wurde schon immer groß geschrieben!
Rudi R. schrieb: > ich bin ja eigentlich nur beratend dabei, > (…) > wenn nur diese dämlichen Besprechungen nicht wären Dämliche Besprechungen gibts auch außerhalb von Scrum und wenn du nur beratend dabei bist ist sowas doch genau dein Jobprofil? Also lieber mal die Position wechseln. > Nur geht mir > Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil > intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen > Leuten durchdringen kann. Was hat das mit Scrum zu tun? Klassischer Freitags-Troll.
Torsten R. schrieb: > Marcel V. schrieb: >> Dagegen werden Heute Vegetarier groß geschrieben. > > Vegetarier wurde schon immer groß geschrieben! Heute jedoch nicht.
Bernd schrieb: > 3) schlechtes Schrum Das ist wie mit dem Kommunismus. Er ist überall gescheitert. Aber natürlich nicht weil er schlecht ist. Er wurde immer nur schlecht umgesetzt.
Bernd schrieb: > Das ist nicht nur unlogisch, sondern auch gefährlich, weil es vorhandene > - oft bessere - Strukturen zerstört und behindert. Ja, insbesondere die deutsche Softwareindustrie ist von unerreichtem Weltruhm, und hat sich schon immer durch extreme Innovationskraft und vor allem Ausführungsgeschwindigkeit hervorgetan. Die vielen Beispiele grandios gescheiterter Großprojekte sind legendär... Oliver
Michael B. schrieb: > Heute jedoch nicht. Auch heute werden Vegetarier immer noch groß geschrieben, genau wie damals. Nur damals waren die Vegetarier noch nicht in der Überzahl. Das ist damit gemeint.
Bernd schrieb: > Zu 1) ist zu sagen, daß ich das auch mitbekommen habe: Die Fraktion "Ich > habe meine Thesis verteidigt" ist darauf getrimmt, alles perfekt > darzustellen, hat aber nicht kapiert, dass sie nicht viel können und > noch lernen müssen. Sie sind extrem selbstbewusst Die Leute, mit denen ich gerade zu tun habe, sind gar nicht mehr so jung. Ich kann leider auch nicht deutsch mit ihnen reden und bestimmte Dinge kann ich schlecht abschätzen. Ich weiß ja, was ein deutschen Curriculum beinhaltet, aber die kommen vielleicht nur von einer Coding-School oder so ein Blödsinn. Bei der einen Entwicklerin steht auf LinkedIn geschrieben, bei ihr gehöre Hibernate zum Skillset. Aber wie viel? Ich erlebte dann, wie sie statt Standard-Hibernate zu werden, selber SQL-Create-Statements in Java hinterlegte. Und das scheint mir auch ein kulturelles Problem, dass in anderen Kulturen kräftig geklappert wird, speziell die Amerikaner. Wir hatten mal einen im Projekt, der wirklich nichts konnte, dem wir auch noch verboten, überhaupt noch Code hinzuzufügen. Der haut aber bei LinkedIn auch mächtig auf den Putz und hat 'ne "Direktorenposition". Keine Ahnung, wie sowas geht. > Das > erlebe ich bei den Erfahrenen auch. Ist eine Frage der Person und > Einstellung. Konzepte zu machen, ist bei größeren Projekten absolute > Pflicht, leider hacken die meisten Programmierer nur in den Tag hinein > und konzeptionieren, während sie Programmieren. Da stimme ich zu. Zu mir kommen junge wie alte Entwickler, die mich um Hilfe bitten. Dann geht es sofort in den Source-Code. Hinweise, doch mal ein paar UML-Zeichnungen anzufertigen und vor allem Zustandsüberführungsmodelle, aber besten, bevor sie anfangen, zu programmieren, werden ignoriert. Seltsam. Mich kotzt diese Ignoranz an. > Die muss man umerziehen > oder aussortieren, d.h. nur Aufgaben geben, die sie allein mit sich > abarbeiten können. > Leider nicht immer möglich. > Zu 2): Dass es zu viele Meetings gibt, liegt an der ineffizienten > Gestaltung von Besprechungen und der mangelnden Vorbereitung: Es wird > nicht im Vorfeld investiert und damit der Tatsache Rechnung getragen, > dass dort mehrere die Daumen drehen, beim Zuhören und die Zeit > verstreicht. Das muss effizient laufen, geht aber nicht, wenn jeder > unvorbereitet alles aus dem Stehgereif macht. Das aber ist der Fall, > weil sie von einem Treff zum Nächsten stolpern. Das ist richtig. Ich ließ aber offen, ob das mit Scrum zu tun hat oder nicht. > > Da deshalb die meetings nicht nachbereitet werden, weil keine Zeit ist, > verpufft die Wirkung und verbunden mit der Unfähigkeit, Beschlüsse zu > fassen, werden die Themen weitergeschleppt, und wieder aufgewärmt. Da > das Folgemeeting aber erst Tage später stattfindet, ist es aus dem > Kurzeitgedächtnis raus und die Tiefe der Diskussion muss neu aufgebaut > werden. Damit bleibt es immer flach! > Die Meeting-Kultur finde ich generell ganz schlimm. Man wird regelrecht überfallen. Ich halte es für falsch, eine Entscheidung treffen zu müssen. Ich bin ein denkender Mensch, der auf Papier Pro und Kontra gegenüberstellt, Konzepte entwirft und verwirft. Ich sehe es bei anderen nicht. > Zu 3) Scrum wird heute überall angewendet und misachtet, daß es nur dann > funktioniert, wenn alle im Team in etwa dasselbe können und das gleiche > Knowhow haben. Ich denke, Scrum macht es bestimmten Leuten besonders leicht, sich hinter einem Team zu verstecken. Ich schrieb ja, dass 2008/9 Scrum halbwegs funktioniert hat, es sogar zeitweilig Spaß machte. Das lag daran, weil unsere Kompetenzen nicht weit auseinandergingen und weil die Anwendung simpler war. Das aktuelle Projekt aber erfordert sehr viele unterschiedliche Kompetenzen innerhalb der Softwareentwicklung in einer komplexen Domäne. Ich bin ja selbst aufgeschmissen, wenn ich dann gefragt werden, wie etwas ganz speziell bei uns im Dialog-Framework umzusetzen ist. Hinzu kommt, dass die Entwickler auch noch wie Glucken auf dem Source-Code sitzen, anstatt viele kleine Commits zu pushen, damit jeder Entwickler im Code des anderen stöbern kann. > Nur dann macht es Sinn, Aufgaben zu splitten und sich das > selbständig aufzuteilen und es auch zusammen zu planen. ist das nicht > der Fall, sollte eine kompetente Person die Planung übernehmen, was aber > wieder heißt, wie bei Punkt 1 angeführt, Dokumente zu verfassen und > Konzepte zu machen. > So ist es. Bei uns ist es so, dass ich mehr als zehn Jahre in der Firma bin und die anderen in Summe nicht mal auf sechs Jahre kommen. Ich bin erst später hinzugekommen. > Ich sehe aber das Gegenteil: Die Entwickler treffen sich in einem großen > Team, nennen es Scrum, es macht aber jeder was anderes und sie können > sich weder gegenseitig helfen, noch den anderen verplanen. Auch da > spielt es eine Rolle, wie transparent ein Entwickler arbeitet. Wenn du > nicht weißt, welches Konzept seine SW verfolgt, kannst du auch nicht > eingreifen oder beihelfen. > > Scrum wird einfach in vielen Firmen völlig falsch angewendet. Das kann auch sein. Es wird ohnehin vieles falsch angewendet. Ich habe mal in Privatprojekten test-driven programmiert (TDD). Ich fand die Idee gut, finde sie immer noch gut. Ich schreibe erst den Test und dann die dazugehörige zu testende Einheit. Die Folge davon ist, dass die Schnittstellen recht gut sind, denn was sich in einem Modultest anwenden lässt, ist auch in einem Dialog oder auf einem Server aufrufbar. Ich kenne Entwickler, die haben es noch nie ausprobiert, gucken mich an, als hätte ich sie auf ihre Lieblingsstellung angesprochen. Die entwickeln oft den Dialog und dann die Logik dahinter. Und dann ist mühsam zu testen. Ich erinnere mich, wie ich vor elf, zwölf Jahren mal eine Schnittstelle zu einem Fremdsystem programmieren musste. Wir kommunizierten über Datenbanktabellen. Ich habe das recht schnell programmiert, schöne Tests geschrieben, weit über 80. Dabei unter Anwendung des TestRunners Parameterized, welchen viele Kollegen bis heute nicht kennen oder erst in den letzten vier Jahren begonnen haben, einzusetzen. (Es ist so traurig.) Die Tests liefen ruckzuck ab, weil ich den Seiteneffekt, das Schreiben in die Datenbank und das Lesen daraus, nicht ständig abtesten wollte. Denn das kostet Zeit. Entscheidend ist, dass unsere Empfangsseite mit den Objekten das richtig macht und die richtigen Objekte erstellt. Es funktioniert alles bis auf eine Definitionslücke: Darf man Bestellungen haben, wo jemand von Art A die Menge 0 bestellt? War leider nie spezifiert, ob > 0 oder >= 0. Also banal. Ein Kollege übernahm und er war nicht zufrieden und was machte er? Schrieb weitere Tests, die auch wirklich persistierten. Dann liefen die über 80 Sekunden nicht unter 10 Sekunden ab, sondern brauchten mehrere Minuten. Die guten Schnittstellen wurden da auch noch aufgeweicht. Ich glaube, ich wiederhole mich. Es kann natürlich sein, dass bei uns ein "Pseudo-Scrum" umgesetzt wird und es machen nicht alle Niederlassungen. Was sich bei mir äußerst, ist in weiten Teilen ein Kulturpessimismus. Mir wird von Kollegen auch gesagt, dass Scrum gar nicht zu der Art Software passe, die wir programmieren. Agile Methoden halte ich nicht für falsch. Ich habe damals mit Begeisterung das Buch von Kent Beck gelesen. Das Wasserfallmodell habe ich immer schon für Unsinn gehalten. Es wurde doch mal entwickelt, um aufzuzeigen, wie Softwareentwicklung auf keinen Fall funktioniert. Ich finde bei Design und Planung iterative Herangehensweise sehr sinnvoll und ich gehe auch iterativ vor. Ich fange grob an, liefere Grundfunktionalitäten, so, dass die Kollegen, die von von meiner Arbeit abhängig sind, auch schon mal anfangen können. Es gibt Kollegen und auch Vorgesetzte, die mich zu einer sehr frühen Zeit im Projekt was sehr, sehr spezielle fragen und ob ich mir darüber Gedanken gemacht hätte. Ich bin dann ganz offen und sage, wo es grob hingeht, aber Details könne und dürfe ich nicht nennen, denn es wäre angesichts vieler anderer Aufgaben, einfach noch nicht dran. Ein Beispiel: Man kann in Interface Guide-Lines sehr früh festlegen, wie Buttons angeordnet werden, dass der OK-Button immer links, der Abbrechen-Button immer rechts steht, wo der Nein-Button ist. Das ist vernünftig. Es ist aber schwachsinnig, sehr früh festzulegen, welche drei Buttons in einem ganz speziellen Dialog überhaupt da sein müssen. Das ist zu konkret. Wenn ich mir die "agilen Leitsätze" anschaue, dann fehlt da eine Menge, die ich bei Scrum nicht sehe, bzw. bei dem, was sich bei mir als Crum gebärdet: "Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge" - Ich habe das Gefühl, dass der Sprint und das Sprintende das wichtigste. Hauptsache, alles ist fertig, der Sprint ist abgeschlossen. Schlimm. Individuen spielen keine Rolle. Ich bin bislang überall nur auf Widerstand gestoßen, wenn ich mal vorschlug, dass die Leute einfach mal Buch zur Hand nehmen, sich in etwas einarbeiten und damit spielen. Vor ein paar Jahren arbeitete ich das Buch "Functional Programming in Scala" durch. Damit verbrachte ich meinen Feierabend. Ich habe mich da sehr schön vertieft und auch etwas rausgenommen, selbst wenn ich Scala in der Praxis nicht anwende. Die Kollegen, mit denen ich tun hatte, winkten ab. Bloß keine Bücher, bloß nichts lernen. Ein Fehler unserer Bildung und Ausbildung ist wohl, dass das zweckfreie Agieren verpönt ist. Es wird sich nur in etwas eingearbeitet, wenn ein ganz konkreter Zweck sichtbar ist. Arbeitgeber lassen das ja auch nicht zu. Wenn nichts zu tun war, hätte ich immer noch Ärger bekommen, wenn ich während der Arbeitszeit was anderes gemacht hätte. (Ich habe mir die Zeit einfach genommen.) "Funktionierende Software ist wichtiger als umfassende Dokumentationen" - Dokumentiert wird wenig, daher ist das "bei mir" erfüllt. Aber die Software funktioniert nicht und wenn, allenfalls schlecht. "Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität." - Da möchte man doch glatt Thomas Doll zitieren. Design geht ja bei uns leider den Bach runter. Ich bekomme in Code-Reviews angemecket, ich hätte alten Code nur auskommentiert und nicht gelöscht, während meine Reviews, wo ich anmahne, Konstruktoren mit 20 primitiven Argumenten seine eine gefährliche Stolperfalle für jeden Entwickler und müssten daher ersetzt werden, wirkungslos verpuffen. Vielen Dank übrigens für die Diskussion hier. Ich bin kein Troll, nur weil ich es so aussieht, ob hier jemand nur Dampf ablässt. Ich würde sonst platzen, wenn ich mich nicht dazu äußern würde und das wäre nicht gesund. Ich bin auch kein Experte für Vorgehensmodelle, mit dem Fokus auf dem Team. Mich interessierte sowas nie so sehr, weil ich es nicht organisieren will, sondern lieber selbst immer entwickeln wollte. Und da interessieren mich eher die Vorgehensmodelle, die sich auf den Code beziehen, wie TDD.
Rudi R. schrieb: > Ich würde sonst platzen, wenn ich mich nicht dazu äußern würde und das > wäre nicht gesund. Steve van de Grens schrieb: > Das merkt man :-) Ich habe mir den ellenlangen Text zwar nicht zu Gemüte geführt, aber schon beim runterscrollen wird sofort sichtbar, dass zu dieser Thematik massiver Gesprächsbedarf herrscht.
Moin, Geh' mal raus an die frische Luft, mach nen Spaziergang und iss mal einen Apfel. scnr, WK
Dergute W. schrieb: > Geh' mal raus an die frische Luft, mach nen Spaziergang und iss mal > einen Apfel. Nee, das reicht hier bei weitem nicht. Michael O. schrieb: > Wenn das Team nicht passt oder nur bremst, sollte man sich ein anderes > Team suchen, oder nach ein paar versuchen sich ein eigenes suchen oder > wenn man es gar nicht ertragen kann allein weiter machen. Hab ich vor 30 > Jahren mit angefangen und nie bereut. Genau. Das weite Suchen.
Christoph Z. schrieb: > Genau. Das weite Suchen. Das ist nicht so einfach, wenn so viele Firmen scrum-verseucht sind. Das ist ein Riesenhype, wie eine Flutwelle, der man sich nicht entgegenstellen und der man nicht entkommen kann. Marcel V. schrieb: > dass zu dieser Thematik > massiver Gesprächsbedarf herrscht. Sehe ich ebenso! Problem: SCRUM ist eine heilige Kuh! Es ist in den Hirnen fest eingebrannt wie die Wehrpflicht und "unsere" 5-Jahres-Pläne in der DDR samt ihrer dämlichen Pro-Argumente! Und obwohl jeder wusste und spürte, dass es falsch läuft und unsinnig ist, plappert ein jeder die vorgegebene mainstream Haltung nach! Wenn du nur etwas dagegen gesagt hast, warst du ein Systemgegner! Ok, DDR und die Wehrplicht sind weg. Aber Scrum ist noch da. Warten wir also. Es dauert wahrscheinlich auch weitere 10-20 Jahre, bevor der Spuk vorüber ist. Solange werden wir mit dem Hype noch zu kämpfen haben. Es ist ja auch ein gutes Geschäft für die Dampfplauderer aka Scrum Master. Du musst im Kontext fast nichts können, sondern nur JIRA-Tasks und bunte Zettel verwalten. Ach ja: Kennt wer noch "KANBAN" und "KAIZEN"? Das war vor 30 Jahren DER Hit! Super neu und super geil! Alles, was aus dem fernen Japan kam, wurde blindwütig übernommen. Vor etwa 20 Jahren hatte KANBAN seinen Höhepunkt in Deutschland. Danach merkten einige, dass es für deutsche Produktionslandschaften nicht unbedingt optimal ist und eigentlich dafür gedacht war, die japanische Verschwendungswirtschaft zu entmüllen, die dadurch entstand, dass sich niemand verantwortlich zeigt und Entscheidungen seines Chefs abändert. Heute kennt das hierzulande keine Sau mehr! "Wir" Deutschen leiden an einer Krankheit: Wir müssen immer das nehmen, was von außen kommt. Seien es Pommes, Jeans und Cola oder eben Ami-Methoden. Würde man aber genauer hinsehen, was die Ursachen für die Einführung der Methoden waren, unterbliebe Vieles.
Bernie schrieb: > Seien es Pommes, Jeans Pommes kömmen übrigens aus Belgien: https://de.wikipedia.org/wiki/Pommes_frites Und was jetzt Schlimmes an Jeans ist, weißt nur du alleine. Bernie schrieb: > und Entscheidungen seines Chefs abändert. Du hast offenbar noch nie mit Asiaten speziell aus China, Korea oder Japan zu tun gehabt. Da gilt das Senioritätsprinzip bis zum Exzess. Da ändert niemadn die Entscheidung des Chefs ab. Aber Hauptsache die eigenen Vorurteile gepflegt, gelle.
:
Bearbeitet durch User
Kanban ist ein schönes Stichwort. Ich benutze das in etwa so wie Postits mit allen Aufgaben und Unteraufgaben drauf. Wenn ich zu einem Punkt eine gute Idee habe, arbeite ich ihn einfach ab. In kleinen Teams funktioniert das richtig klasse, ersetzt, wie auch Scrum, aber nicht die Kommunikation im Team. Große Meetings bleiben kurz und knackig wenn vorher mit allen Beteiligten die Details schon geklärt sind, alle Bescheid wissen, und nur noch das Ergebnis verkündet wird. Die Kaffeeküche ist für mich der kreativste Raum im Büro. Dort kommt soviel Information auch und besonders aus unerwarteten Ecken zusammen, dass die Effizienz in der Entwicklung unvorstellbar steigen kann.
Kara B. schrieb: > Du hast offenbar noch nie mit Asiaten Doch, sehr wohl, Ich habe schon in Japan gearbeitet. Du kannst nur nicht richtig lesen: Kara B. schrieb: > Da gilt das Senioritätsprinzip bis zum Exzess. Da > ändert niemadn die Entscheidung des Chefs ab. Das war doch die Aussage! (?) Der Chef entscheidet runter und drückt jeden Fehler ins System. Da niemand rund gemacht werden will, akzeptiert er alles und korrigiert nichts. Damit es funktioniert, wird nochmal parallel gearbeitet, bestellt und gebaut. Daher brauchte Japan ein System, in "dem nur bestellt und gebaut wird, was auch benötig wird". Hierzulande herrschen völlig andere Mechanismen.
Bernie schrieb: > . Die meisten SW-Entwickler hatten das nicht gelernt und waren > fachfremd. Ich hab dazu keine Zahlen (nur eine Meinung 😄): in der Zeit gab es vermutlich deutlich weniger Stellen so dass der Nerd -Anteil (mit durchcodeten Nächten) und der Durchdringung in die Tiefe relativ hoch war. Heute studieren Leute Informatik, die weder Lust noch Erfahrung damit haben. Insgesamt gibt es natürlich wesentlich mehr brillante SW-Entwickler heute. Relativ (also auf n SW-Entwickler in einer Firma bezogen) bin ich mir da nicht sicher. Und bei N Frameworks und Aufgaben ist es vermutlich auch kaum einfacher zu erkennen, ob jemand ein Verständnis von Codierung hat
Bernie schrieb: > Christoph Z. schrieb: >> Genau. Das weite Suchen. > Das ist nicht so einfach, wenn so viele Firmen scrum-verseucht sind. Das > ist ein Riesenhype, wie eine Flutwelle, der man sich nicht > entgegenstellen und der man nicht entkommen kann. Hättest halt mal was ordentliches gelernt :) > Problem: SCRUM ist eine heilige Kuh! Es ist in den Hirnen fest > eingebrannt SCRUM kam und geht, genau wie StudiVZ und Facebook. Steve van de Grens schrieb: > Ist der Artikel Zufall? > https://www.golem.de/news/arbeit-scrum-nervt-2401-180930.html Golemao.
Der Traumjob für euch 80% Meeting 10 % coden 10 % auf die Kollegen koten... Ich glaub es passt über ein im Meeting dann poppeln ... Mein Traumjob ich code den ganzen Tag meine skills im social sector A. Den Traum haben sich hier einige Frührentner und Sozialamtbezieher erfüll, sind dann noch so dreist im Xing Probil eine Firma anzugeben, die seit 30 13 Jahren durch ihre Mitarbeit zu Robert H. Eigentum übergangen ist. Und heute poppeln sie im Forum mit unbefugten Wissen rum. Kennen Sie John Dumbo ? Der war in der Scrum Meeting Hölle 65 bis 75 Minuten um Stück, heute hat es den Kaffelöffel mit Auszeichnung für die kurzen Kaffeepausen. Sein Quellcode finden sie täglich im WC -> Klo um 9:12:34...
Jetzt hat mir auch noch der Hanser Verlag eine SPAM Mail für ein SCRUM Buch geschickt. Langsam wird es gruselig. Merken die nicht, dass der alte Gaul längst tot geritten wurde?
Bruno V. schrieb: > Bernie schrieb: >> . Die meisten SW-Entwickler hatten das nicht gelernt und waren >> fachfremd. > > Ich hab dazu keine Zahlen (nur eine Meinung 😄): in der Zeit gab es > vermutlich deutlich weniger Stellen so dass der Nerd -Anteil (mit > durchcodeten Nächten) und der Durchdringung in die Tiefe relativ hoch > war. > Ich habe in letzter Zeit öfter darüber nachgedacht. Was war früher anders? Zuerst einmal viele Studierte aus Ingenieursfächern und auch aus der Mathematik. Ein Studium trainiert das Aneignen Kenntnissen und Wissen. Ich als Diplom-Informatiker (Beginn des Studiums war 2003) musste viel lernen, d.h. zu Hause sitzen, Bücher durcharbeiten, am Computer Programmierfähigkeiten ausbauen. Ich hatte aber auch schon vor meinem Studium mir einiges selbst beigebracht. Sicherlich gab es hier und da einen Anstupser (bei Basic, bei Pascal), aber C++ habe ich aus eigenem Antrieb erlernt. Und das nimmt mir keiner. Das GoF-Buch habe ich mir vor meinem Studium gekauft. (Ich erinnere mich, dass ich es bei der Bundeswehr dabei hatte, weil ich naiverweise dachte, ich hätte während der Grundausbildung Zeit zum Lesen.) Die Fähigkeit, sich selbständig und systematisch Ding aneignen zu können, ist ja mit das wichtigste, was einen Akademiker ausmacht. Und in meinem Fall begann das ja schon vor dem Studium, aus einer intrinsischen Motivation heraus, und nicht für gute Noten in der Schule. > Heute studieren Leute Informatik, die weder Lust noch Erfahrung damit > haben. > Das wird es sein. Bei mir war das Studium eine Überzeugungstat. Eine beliebte Frage von mir an die neuen Mitarbeiter, die da frisch von der FH kommen, ist die Frage nach Linux, ob sie es denn privat verwendeten. Und dann heißt es, kein Interesse, keine Lust, keine Zeit... Mir ist das ein Rätsel. Viele studieren dann Informatik, weil sie gehört haben, damit könne man gut Geld verdienen. Während mein Studium war es so, dass viele recht gute Programmierkenntnisse schon mitbrachten. Wer ohne Programmierkenntnisse ins Studium startete, hat sehr viel schlechtere Chancen, das Studium zu bestehen. Nun kommen viele meiner Kollegen von der FH, wo schon geringere Anforderungen an das selbständige Lernen gefordert werden. Und der Bachelor tut sein übriges. > Insgesamt gibt es natürlich wesentlich mehr brillante SW-Entwickler > heute. Relativ (also auf n SW-Entwickler in einer Firma bezogen) bin ich > mir da nicht sicher. Und bei N Frameworks und Aufgaben ist es vermutlich > auch kaum einfacher zu erkennen, ob jemand ein Verständnis von Codierung > hat Das denke ich auch. Es gibt aus den oben genannten Gründen immer mehr Mittelmaß. Ich sehe die intrinsische Motivation bei vielen Leuten nicht. Und das frustiert dann ungemein. Vor allem hörte bei mir das Lernen mit dem Studium nie auf. Jedes Jahr kaufte ich neue Fachbücher und arbeitete mehr oder weniger durch. Während des Corona-Winters 20/21 arbeitete ich ein Haskell-Buch durch. Die Sporthallen waren ja geschlossen, also hatte ich für Haskell viel Zeit. Ich merke bei den Kollegen die Defizite immer dann, wenn sie im Code ein Mengenobjekt (In Java üblicherweise das HashSet.) haben und etwas hinzufügen. Es gibt tatsächlich Programmierer, die vorher abfragen, ob das hinzufügende Objekt nicht schon drin sei und nur wenn nicht, fügen sie ein. Das ist für mich ein Zeichen, dass die Person nicht weiß, was 'ne Menge und was sie auszeichnet. Oder wissen die nicht, dass Menge auf Englisch set heißt? Ich finde die Mengentheorie essentiell und wende sie häufig an. Kann ich sicher sein, dass ein Kollege mich korrekt versteht, wenn ich von Differenzmenge, von der Schnittmenge, der Vereiniunsmenge, oder von der Ober - oder Teilmenge spreche? Oder vom kartesischen Produkt? Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum geht: https://www.danisch.de/blog/2024/01/16/scrum/
Rudi R. schrieb: > Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum > geht: https://www.danisch.de/blog/2024/01/16/scrum/ Beim Danisch finde ich toll wenn er über feministen herzieht.
Huebi H. schrieb: Sehr schön und klar: > Die Kaffeeküche ist für mich der kreativste Raum im Büro. Dort kommt > soviel Information auch und besonders aus unerwarteten Ecken zusammen, > dass die Effizienz in der Entwicklung unvorstellbar steigen kann. Wie schön, dass die Orgbanisationswissenschaften die Kaffeeküche noch nicht instrumentalisiert haben. Ciao Wolfgang Horn
Rudi R. schrieb: > aber C++ habe ich aus eigenem Antrieb erlernt. wann hast du denn studiert? C++ wurde bei uns schon 1993 gelehrt.
Hadmut F. schrieb: > Beim Danisch finde ich toll wenn er über feministen herzieht. Was ist so toll daran, wenn jemand über etwas schreibt von dem er nichts versteht?
Bernie schrieb: > wann hast du denn studiert? C++ wurde bei uns schon 1993 gelehrt. Er hat doch sehr ausführlich geschrieben, dass es (zumindest damals) üblich war, schon vor dem Studium intensiv programmieren zu können. Und GoF durchgearbeitet zu haben, erfordert einiges. So wie die Bewerbungs-Mappe zur Kunsthochschule tausende Stunden Erfahrung/Übung brauchen, bei Musik ähnlich. Wer Programmieren erst im Informatikstudium lernt (gibt ja keine Aufnahmeprüfun), kommt damit zwar auch durch, dürfte aber später eher als Consulter oder SAP-Systemberater denn als Informatiker Karriere machen. Im Studium hat man 2 oder 3 Sprachen, an denen man konkrete pattern/Konzepte zeigt.
:
Bearbeitet durch User
Rudi R. schrieb: > Ich finde toll, wie Hadmut Danisch vom Leder zieht, wenn es um Scrum > geht: https://www.danisch.de/blog/2024/01/16/scrum/ Der Typ hat von Softwareentwicklung schon mal gar keine Ahnung, Fricklerniveau auf dem Stand der 90er, so typischer Uni-Werksstudentenbastler. Mal schnell was zusammenfrickelt für die Uni und sich als Held der Softwareentwicklung fühlen. Solche Gestalten kennt man, wenn er seine Entwickleranekdoten von vor 30 Jahren runterleiert. Sein IT-Sicherheitswissen ist erschreckend dünn und allgemein gehalten, wenn er überhaupt mal was zu dem Thema schreibt auf dem er angeblich Experte ist, das ist ein sicheres Zeichen dass er eine aufgeblasene Luftpumpe ist. Ab und an verrät er sich mit seinem epischen Artikeln über Trivialproblemen unter Ubuntu, Puppet,... Seine Ausführungen zur Kryptografie lesen sich genauso, so schreiben Anfänger und selbsternannte Profis aber keine echten Fachleute. Habt ihr von dem mal einen einzigen tiefergehenden Artikel zu seiner angeblichen Expertenwissen gelesen? Das ganze Blog ist nur voller Geschwafel. Ein sicheres Zeichen, dass er nur ein Grossmaul ist, er weiss ja immer alles am besten, die ganze Welt hat sich gegen ihn verschworen, sein heroischer Kampf gegen alle Windmühlen dieser Welt beschreibt er in epischer Breite in jahrelanger Dauerwiederholung. Der Typ hat meiner Ferndiagnose nach eine riesige Psychomacke. Z.T. hat er ja recht mit seine Behauptungen und Erlebnissen aber ein aufgeblasener Schwätzer ist dennoch.
:
Bearbeitet durch User
Er hat schon 1995 eine digitale sprachverschlüsselung gebastelt als wir nicht mal wussten was ein vocoder ist. Wenn man sich im gebiet auskennt ist das ziemlich eindrücklich.
Bruno V. schrieb: > Er hat doch sehr ausführlich geschrieben, dass es (zumindest damals) > üblich war, schon vor dem Studium intensiv programmieren zu können. Also auch bei uns war das üblich, schon vor dem Studium was zu programmieren. Machen ja heute allemöglichen 15-jährigen APP-Programmierer. Deren Problem ist es, ein Konto zu bekommen, um sich Paypal überweisen zu lassen. Wie sehr das von Vorteil ist, sei dahin gestellt. Man unterscheide Programmieren und Software entwickeln. Es gibt Leute die entwickeln täglich Software, schreiben aber keine einzige Zeile Code. Meine Frage war auch eine andere: Seine Aussage war, C++ gelernt zu haben und das sei "neu" gewesen. C++ ist an Hochschulen seit 30 Jahren nicht mehr "neu". Es wurde Mitte der 1980er eingeführt und war Ende der 1980er bereits an einigen Hochschulen wählbar. Spätestens Mitte der 1990er Jahre hatte das jede Hochschule, die ich kenne, im Programm. Natürlich nur Informatik. Die Elektriker blieben freilich beim C. Reichte auch für Prozessoren. Ist heute auch anders.
Bernie schrieb: > Also auch bei uns war das üblich, schon vor dem Studium was zu > programmieren. Machen ja heute allemöglichen 15-jährigen > APP-Programmierer. Deren Problem ist es, ein Konto zu bekommen, um sich > Paypal überweisen zu lassen. > Ich weiß nicht, wie weit verbreitet das ist. Einer unserer Azubis erzählte mir aber, dass er regelmäßig an Coding Challenges teilnimmt. Dort verwendet man irgendwelche Frameworks für kleine Spiele, deren Namen ich schon wieder vergessen habe. Das ist immerhin besser als nichts. Ich musste heute auch zurückdenken, als Delphi sehr populär war. 1998 probierte ich es damit. Ich konnte da schön Oberflächen zusammenklicken, aber ich hatte meine Schwierigkeiten, es mit Leben zu füllen. Ich empfand das nicht sehr als lehrreich und begann später Dialog-Programmierung per Hand. Ich will mal hoffen, dass die jungen Leute auch noch textbasiert und oldschool entwickeln. Entwicklungsumgebungen nehmen einen sehr viel ab und wir müssen bei der Ausbildung darauf achten, dass die Azubis wirklich in die Materie einsteigen und nicht immer nur die IDE die Arbeit machen lassen. Ich konnte mich als Jugendlicher mich stundenlang darin vertiefen, einen Interpreter für Terme (wie z. B. 5+3*10) zu entwickeln. Ich war ja vollkommen unbeleckt, was Grammatiken angeht und vielleicht gerade deshalb war es sehr lehrreich. Heute würde ich das anders entwickeln. Ich habe meine Zweifel, dass meine Kollegen es entwickeln könnten. Sie kämen nicht auf meine damalige Lösung mit einer rekursiven Funktion noch kämen sie nicht auf die, mit antlr/Lex&Yacc etc. zu definieren. > Meine Frage war auch eine andere: > > Seine Aussage war, C++ gelernt zu haben und das sei "neu" gewesen. Die Stelle zeigen Sie mir bitte. Sie werden Probleme haben, weil ich das nie schrieb. Wenn ich 2003 begann zu studieren, kann man mein Alter ungefähr abschätzen. Als C++ eingeführt eingeführt wurde, war ich noch nicht mal geboren.
Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem Entwicklungsmodell zu tun. Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als Hobby programmiert haben und seit mindestens 10 Jahren große Projekte planen und mit Begeisterung und hohen Ansprüchen an die eigene Sourcecodequalität selbst programmieren.
Bri schrieb: > Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem > Entwicklungsmodell zu tun. > > Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als > Hobby programmiert haben und seit mindestens 10 Jahren große Projekte > planen und mit Begeisterung und hohen Ansprüchen an die eigene > Sourcecodequalität selbst programmieren. Dem widerspreche ich nicht, aber es ist ein Problem, wenn diese Leute mit Meetings gequält werden. Ich sehe meine Entwicklerfähigkeiten als weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme, wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit investieren und das Fortentwickeln wäre das beste, dann weiß ich, es geht schief. Denn erstmal will man nicht der Arsch sein, der die anderen nur für Idioten hält. Dann investiert man Zeit, um es zu verstehen, was da programmiert wurde und dann wird zusätzlich viel Zeit und Geld verschwendet für Erweiterungen. Und immer ist das unwohle Gefühl da: Hätte man alles neue gemacht, wäre man günstiger gefahren. Aber das kapieren viele Projektleiter leider nicht. Wir hatten schon mehrfach die Situation, dass Code von Entwicklern komplett weggeschmissen werden musste. Erst kosten die Entwickler Geld und dann geht die Zeit anderer Entwickler drauf, um aufzuräumen und neu machen. Es waren u.a. Festangestellte, wo wir froh sind, dass die weg waren. Externe sind ein gesondertes Problem. Die haben es ja besonders schwer, weil die sich in kurzer Zeit einarbeiten müssen. In der Regel machen die Externen mehr Arbeit als sie bringen. Nur kapieren das die Verantwortlichen auch nicht. Ich habe in den letzten zehn Jahren ca. 10 externe Entwickler in meinen Projekten gehabt. Nur zwei konnten am Ende etwas produktives vorweisen. Scrum lebt ja von der Illusion, dass Entwickler schon alle gleich wären, austauschbare Verschiebemasse und dass Softwareentwicklung etwas ist, was man in Zwei-Wochen-Sprints aufteilen könne. Es gibt aber die Aufgaben, wo man auch länger mal drüber brüten muss, damit es vernünftig wird. Und man muss in Ruhe nachdenken können. Ich habe vor zwei Jahren mal einen Prototypen für einen Algorithmus entwickelt. Obwohl wir in Java entwickeln, habe ich den Prototypen in Python entwickelt, um zu schnellen Ergebnissen zu kommen, denn im Zentrum steht der Algorithmus und nicht die Implementierung. (Das hatte so Spaß gemacht, dass ich sogar nach Feierabend dran arbeitete.) Hundertprozentig wäre in einem Scrum-Umfeld das nicht möglich gewesen, weil es von vielen Leuten nicht gerne gesehen wird, dass jemand Entwicklungszeit aufwendet, was im Endprodukt ja komplett neu entwickelt werden muss, weil anderes Ökosystem. 2010 sprang mal bei uns ein Lean-Berater herum, der uns etwas von Kaizen erzählte. Was für ein Blödsinn. Da wurden Grundsätze entwickelt wie, dass nur die Programmierung, bei der Funktionalität herauskommt, gut ist. Also laut diesem Grundsatz ist Refactoring ein No-Go. Lean mit Kaizen ist ja genauso ein Mode-Blödsinn wie Scrum. Ich finde ja zyklische Vorgehensmodelle ganz sinnvoll und ich verwende diese informell. Kollegen von mir sind auf meine Arbeit angewiesen, dass sie erstmal weiter machen könne. Ich entwickle so, dass die Grundfuntionalität schnell bereitsteht, sodass die anderen weitermachen können und dann widme ich mich dem nächsten Thema (wo andere Entwickler wieder auf Grundfunktionalität warten), wohlwissend, dass ich Monate später die Themen wieder anfassen muss. Damit fahre ich am besten. Meilensteine kann man definieren, aber man sollte mit diesem Zwei-Wochen-Unfug aufhören. Meine Erfahrung ist, das ich das Vertiefen in unwichtigen Details am Anfang unsinnig ist, weil die Spezifikation sich ja noch ändern kann. Viele Dinge kritallisieren sich noch heraus, warum also Energie schwerden. Und wenn man darauf vorbereitet ist, dass es doch wieder anders kommen kann, dann man implizit so, dass man die Sachen schnell umstellen kann. Ich erwähnte ja, dass im aktuellen Projekt Scrum angewendet wird. Da wird ständig darüber gequatscht, dass eine Aufgabe grob in zwei Teilaufgaben aufgesplittet werden kann. Die Quatscherei darüber verschlang schon ein paar Stunden. Nun wird endlich gemacht.
Rudi R. schrieb: > Hundertprozentig wäre in einem Scrum-Umfeld das nicht möglich gewesen, > weil es von vielen Leuten nicht gerne gesehen wird, dass jemand > Entwicklungszeit aufwendet Viele Softwareentwickler (eigentlich alle, die ich kenne), wirken am Arbeitsplatz zeitweise faul, weil sie nicht tippen sondern z.B. Katzenvideos gucken oder Freizeit-Aktivitäten diskutieren. Aber zu hause grübeln und lernen sie oft ganze Wochenenden, um ein Problem ordentlich zu lösen. Ich bin froh darüber, dass meine Chefs das alle wussten. Niemand bekam jemals Ärger, wenn er am Arbeitsplatz mal zeitweise faul zu sein scheinte.
Bri schrieb: > Ob ein Softwareprojekt erfolgreich ist oder nicht hat nichts mit dem > Entwicklungsmodell zu tun. Nein, das stimmt so pauschal nicht. Es macht einen großen Unterschied ob: -Man das x-te Projekt nach Schema F macht (z.B. einen Webshop für ein kleines Unternehmen), was man so oder so ähnlich schon dutzendfach hatte oder ob -Man etwas völlig Neues entwickelt, am besten mit komplexen Anforderungen die man so zum ersten Mal im Leben sieht :-) > Es hängt allein von den 1-3 Leuten im Team ab, die früher schon als > Hobby programmiert haben und seit mindestens 10 Jahren große Projekte > planen und mit Begeisterung und hohen Ansprüchen an die eigene > Sourcecodequalität selbst programmieren. Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn das Requirements Management nichts taugt. Wenn der Vertrieb dem Kunden sonstwas verspricht - aber selbst auf Nachfrage nicht präzise sagen kann, was dem Kunden denn nun alles verkauft wurde - was willste dann machen?
Rudi R. schrieb: > ... > Ich sehe meine Entwicklerfähigkeiten als > weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier > anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme, > wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit > investieren und das Fortentwickeln wäre das beste, dann weiß ich, es > geht schief. Denn erstmal will man nicht der Arsch sein, der die anderen > nur für Idioten hält. Dann investiert man Zeit, um es zu verstehen, was > da programmiert wurde und dann wird zusätzlich viel Zeit und Geld > verschwendet für Erweiterungen. Und immer ist das unwohle Gefühl da: > Hätte man alles neue gemacht, wäre man günstiger gefahren. Aber das > kapieren viele Projektleiter leider nicht. > ... Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum eingenordet oder fliegen halt raus.
Franko S. schrieb: > Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum > eingenordet oder fliegen halt raus Ja. Die nächsten 5 Jahre lebt die Firma von der Cash Cow. Bis ein kleines Nischenprodukt einer anderen Diva zur neuen Cash Cow wird oder die Firma verschwindet.
Mark B. schrieb: > Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn > das Requirements Management nichts taugt. Guter Punkt! Ich habe gerade was Nettes gefunden: https://www.co-improve.com/media/co_programm_agile_hardware_d.pdf Dort tauchen gleich zwei Referenten von 2 Firmen auf, für die ich tätig war! Alle beiden referieren über ihre großartigen Erfolge im Bereich SCRUM und dem Einsatz bei der Hardwareentwicklung. Wenn man sich die Probleme ansieht, die die Firma jeweils hatte und wie ort real gearbeitet wurde, dann weiß man, dass die sich was in die Tasche lügen! Das hat mit den realen Vorgängen, die stattfanden nichts, aber auch rein gar nichts zu tun. Das war eher Chaos- und Problembewätigung. Aber jeder hüpft auf das Pferd auf und spricht von agilen Methoden. Es ist zuweilen lächerlich, was da läuft.
Franko S. schrieb: > Tja solche Entwicklerdiven haben es heute schwer. Die werden mit Scrum > eingenordet oder fliegen halt raus. Ich kenne bei uns in der Framework-Entwicklung eine Diva, die wirklich sehr viele Register der Informatik und Softwarearchitektur zieht. Dessen Software ist 1A und läuft in allen Projekten sehr gut. Problem aber ist, dass anderes Framework unserer Produktepalette von sehr geschwätzigen Teams in Scrum-Sprints zusammengefrickelt werden, was aber so blöd entwickelt wurde, dass die Stärken des Erzeugnisses der Diva gar nicht zu Geltung kommen. Es gibt bei uns grosso modo zwei Möglichkeiten, Projekte umzusetzen. Man setzt nur auf dem auf, was die Diva gemacht, dann gibt es grüne Zahlen. Oder aber man nimmt den Unfug des Entwicklerteams, das seit 14 Jahren an einer Einheitslösung frickelt, dann geht es in die Hose. Das Management kapiert nicht, dass sie bei dem großen Entwicklerteams nur Geld verbrennt. Das ist 'ne heilige Kuh. Ich bin mir sicher, dass das Management die Wichtigkeit dieser Diva gar nicht kennt. Warum ist das Framework der Diva so gut nutzbar? Weil es architektonisch so gestaltet ist, dass man Bausteine austauschen kann. Die Verwendung von Schablonenmethoden und Strategieklassen ist exzessiv. In 95 % der Fälle sind die Default-Strategien korrekt und bei 5 % entwickelt man seine eigene Implementierung. Das Entwicklerteam des anderen Frameworks jedoch geht den Ansatz, dass man alles per Mausklick konkfigurieren können muss und dann versenkt man natürlich Zeit für die Bereitstellung von Schaltern, Konfigurationsoberflächen und Dokumentation und man deckt immer noch nicht zu 100 % alle Kundenwünsche ab, weil es nicht möglich ist. Ich merke auch bei vielen Entwicklungen, dass sich viele gar nicht darüber im Klaren sind, in welcher konzeptuellen Schicht sie sich gerade befinden. Unsere Software hat mehrere Schichten mit mehreren Zuständigkeiten, aber die schleifen ein Konzept von ganz unten nach ganz oben durch. Die würden es sogar hinbekommen, das Konzept Festplattensektor nach ganz oben ins Word-Programm zu schleifen, d.h. der Anwendung kann sich aussuchen, in welchem Sektorenbereich der Festplatte die Datei abgelegt werden soll. Obwohl es richtig ist, dass Dateien in irgendwelche Sektoren gespeichert werden, ist es falsch, dieses Konzept in diese sehr hohe konzeptuelle Ebene zu bringen, weil es da einfach nicht hingehört. Über so grundlegende Dinge muss gewacht und entschieden werden. Es muss Architekten geben, die da zur Not dazwischengrätschen, wenn jemand die Schichtenarchitektur zerstört. Leider passiert das bei uns nicht, weil die Leute im großen Entwicklerteam gar nicht verstehen, dass es Teil ihrer Aufgabe ist. Die erwähnte Diva jedoch muss sich nicht mit diesen Schmalspurarchitekten auseinandersetzen. Ich bin nicht in der Position, aber ich wenn ich in einer wäre und jemand hat einen Vorschlag, dann würde ich grundsätzlich um grundsätzlich um eine schriftliche Ausarbeitung bitten, die folgendes enhält bzw. genüg: 1. Motivation. 2. Vor- und Nachteile. 3. Was zu tun ist. 4. UML-Diagramme über den wesentlichen(!) Aspekt. 5. in ganzen Sätzen, auf Deutsch. 6. Zusammenhängender Text und kein Powerpoint! Nur so kommen Gedanken rüber. Jemanden zu zwingen, etwas zu Papier zu bringen, heißt, dass er sich darüber tiefgründige Gedanken machen muss. Ich kann mich erinnern, wie ich als Student mal ein Architekturpapier erarbeitet hatte, das für meinen damaligen Kenntnisstand gar nicht mal so schlecht war und ich bei der Ausarbeitung schon viel nachgedacht hatte. Die UML-Diagramme sollen mir zeigen, worauf es ankommt. Wenn mir jemand eine Klasse per UML präsentiert, wo dann ca. 25 Attribute auftauchen, der hat's nicht kapiert. Das wichtige sind ja Klassen- und Objektbeziehungen. Auch Objekt-Diagramme sind interessant, um etwas zu illustrieren. Ich kannte mal jemanden, der hat in ArgoUML alle Klassen seiner Software in eine große Zeichnung gequetscht. Ausgedruckt locker A1 oder gar A0. Alle Felder der Klassen waren aufgeführt, aber das wichtige, die Beziehungen der Klassen untereinander, gingen unter. Man sieht dann den Wald vor lauter Bäumen nicht.
Im Team muss man so entwickeln, dass alle Kollegen durch blicken. Mit der Einstellung: "Wenn die anderen das nicht durchblicken sind sie halt zu dumm" kommt man nicht weit. Irgendwann fällt so eine Vorgehensweise dem Management auf, und dann wird die "Diva" gekündigt. Kein vernünftiger Manager macht seine Firma von einem einzelnen Programmierer abhängig.
Rudi R. schrieb: > Die würden es sogar hinbekommen, das Konzept Festplattensektor nach ganz > oben ins Word-Programm zu schleifen, Schönes Bild! Rudi R. schrieb: > Die UML-Diagramme sollen mir zeigen, worauf es ankommt. Das klappt m.E. nur, wenn alle Beteiligten auch wirklich UML sprechen. Sonst unterscheidet es sich kaum von Visio Bubble-Pfeildiagrammen (was OK ist, nur sollte man es dann nicht UML nennen)
Steve van de Grens schrieb: > Irgendwann fällt so eine Vorgehensweise dem Management auf, und dann > wird die "Diva" gekündigt. Kein vernünftiger Manager macht seine Firma > von einem einzelnen Programmierer abhängig. Umgekehrt wird ein Schuh draus: um was herausragendes zu entwickeln, darfst du nicht nur Durchschnitt sein. Alle herausragenden Produkte wurden von Diven (Helden) ersonnen und entwickelt. Die Diva ist die Firma, wer so blöd ist und dem Helden kündigt, killt die Firma Ob ein Apple oder Tesla, ob ein Amazon oder SpaceX (Tom Mueller, nicht Musk), ob eine LED oder OLED, damals hinter Chips wie LM324 oder uA709 oder NE555, hinter jedem grossen Ding steckt eine Diva, denn wenn die Leute nur Durchschnitt sind bleibt halt auch das Ergebnis so. Das verstehen aber der durchschnittliche Manager nicht. Die glauben, mit 9 Frauen bekommt man das Kind in 1 Monat. Scrum klappt wenn du eine Horde Affen verwalten musst und mit einem Haufen Scheisse zufrieden bist. Ich kenne ein schönes Beispiel, wo eine Software, die von 2 Leuten in 2 Jahren entwickelt wurde, dann von einem Scrum-Team neu implementiert werden sollte. Das hat 10 Leute über 10 Jahre beschäftigt und erreichte laut Kundenmeinung nicht die Qualität des Originals. Nicht ohne Grund gehen bergeweise Firmen ein wenn der Gründer stirbt oder der Held kündigt. Was auch immer die für Eigenschaften hatten, es waren herausragende, nicht durchschnittliche.
:
Bearbeitet durch User
Michael B. schrieb: > Alle herausragenden Produkte wurden von > Diven (Helden) ersonnen und entwickelt. > Die Diva ist die Firma, wer so blöd ist und > dem Helden kündigt, killt die Firma In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held gar keiner ist. Hochmut kommt vor dem Fall.
Michael B. schrieb: > Scrum klappt wenn du eine Horde Affen verwalten musst und mit einem > Haufen Scheisse zufrieden bist. Etwas sachlicher formuliert: "Wenn man eine Gruppe von Personen verwalten möchte, deren Aufgabe es ist, eine vordefinierte Leistung zu bringen, die wenig Innovation erfordert". Das ist nämlich das Mißverständnis unseres TE sowie einiger Beitragenden: Rudi R. schrieb: > Dem widerspreche ich nicht, aber es ist ein Problem, wenn diese Leute > mit Meetings gequält werden. Ich sehe meine Entwicklerfähigkeiten als > weit überdurchschnittlich an. Wenn ich auf einem weißen Blatt Papier > anfangen kann, wird's in der Regel gut. Wenn ich was vorgesetzt bekomme, > wo es heißt, diese oder jene Entwickler hätte schon so viel Zeit > investieren und das Fortentwickeln wäre das beste, dann weiß ich, es > geht schief. Du verwechselst hier das Systemdesign, also die Erstellung des Lösungskonzeptes, mit dessen Umsetzung! Mit einem Blatt Papier anzufangen, heißt sich die Lösung als Konzept auszudenken. Scrum in der Entwicklung taugt aber eher für die schnelle Unmsetzung. Das Konzept wurde vom Product Owner schon definiert. Gleichwohl solltest auch du in der Lage sein, die von anderen Leuten erarbeiteten Lösungen zu verstehen und nötigenfalls zu verbessern und / oder mitzubenutzen. Wenn es dir schwer fällt, liegt es entweder an Dir, oder der mangelnden Planung und Doku deiner Kollegen. Meistens ist es beides, denn Leute wie du sind oft die, die nicht in der Lage sind, ein Lösungskonzept zu skizzieren und für andere nutzbar zu machen. Es fällt ihnen beim Umsetzen immer noch was ein, was sie selber gut einpflegen können und daher nicht merken, wie schlecht ihr Konzept anfänglich war. Soll das aber ein Team machen, wird es schwer! Daher haben sie sich Srum ausgedacht, das die Hintertüre für "sich ändernde Anforderungen" offen hält. Das ist auf den ersten Blick gut, führt aber dazu, dass die Systemplaner noch weniger Zeit in ein gutes Konzept investieren, weil das "Ändern" nun Teil der Strategie ist. Die Planungsfaulheit wird also gefördert! Und auch die Umsetzer können jetzt ständig umdisponieren, weil sie es ja dürfen: Alle 2 Wochen wird die Windrichtung geändert. Es wird also immer mehr aus dem Stegreif gearbeitet. Für manche Chaoten ist das prima, weil sie eingebaute Ausreden parat haben und von den unzulänglichen Fähigkeiten der Systemingeniuere profitieren. Scrum bietet ihnen auch die Chance, binnen 2 Wochen alles abzuwehren, was noch nachgefordert wird. Auch das, was von Teammitgliedern in der Zeit aufgedeckt wird. Deshalb begrüßen viele Entwickler Scrum, weil sie die "Vorteile" für sich zu nutzen wissen. Siehe dazu auch diese interessante Diskussion, wie Selbständige von Scrum profitieren: Beitrag "SCRUM und die Arbeitsweise von Selbständigen"
Rudi R. schrieb:
Dann steckt Typen als Architekten in euer Scrumteam. Er gibt das Desing
vor und wacht darüber dass die anderen Hansel das korrekt umsetzen und
nicht aus der Spur laufen.
Steve van de Grens schrieb: > In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held > gar keiner ist. Hochmut kommt vor dem Fall. Sorry, aber das ist Nonsens:jeder ambitionierte Entwickler hält sich für überdurchschnittlich. Und das ist auch gut so. Niemand möchte einen Programmierer, dessen größte Sorge es ist, aufzugfliegen. Aufgabe des Managers ist es, jeden nach seinen Fähigkeiten einzusetzen. Die nicht ambitionierten als Programmierer, die guten in Brot und Butter Projekten und die Diven für wichtige Sachen: Vielleicht verwechselt Du Diven mit denen, die sich so benehmen (die waren es in meiner Laufbahn nie!)
Bruno V. schrieb: > jeder ambitionierte Entwickler hält sich für > überdurchschnittlich Natürlich. Daher geht man nicht nach dem für was er sich hält, sondern nach dem was er erreicht hat. Weiss man natürlich erst retrospektiv. Wobei: bei manchen hat man vorher eine Einschätzung. Die wirklichen Diven (Helden) wissen meist gar nicht, dass sie überdurchschnittlich sind, sondern glauben, die Anderen könnten doch dasselbe.
Michael B. schrieb: > > Die wirklichen Diven (Helden) wissen meist gar nicht, dass sie > überdurchschnittlich sind, sondern glauben, die Anderen könnten doch > dasselbe. Eher ist es so, dass ist es so, dass sie erst im Laufe ihres Berufslebens merken, dass bei Kollegen bestimmtes Wissen schlichtweg fehlt und nicht aufgeholt werden kann. Ich verwendete vor drei, vier Jahren mal den Begriff "topologische Sortierung" gegenüber einem Architekten, denn damit firmierte er. Er konnte mit dem Begriff anfangen. Man möchte doch meinen, zur Softwarearchitektur gehören auch algorithmische Verfahren. Mich deprimiert das. Ich schrieb ja oben, dass ich mich als überdurchschnittlicher Entwickler ansehen. Das liegt an meinem Wissensschatz der Informatik und meinen Fähigkeiten, konkrete Probleme darauf zu projezieren und Probleme zu abstrahieren. Ich merke, dass die Kollegen es nicht verstehen und würde mich am liebsten einigel. Ich kann auch verstehen, wenn jemand seine Gesundheit schützen muss und sagt: Euch erkläre ich es nicht. Hier ist ein Dokument, dort gibt es drei Wikipedia-Artikel. Lies dich gefälligst ein. Ich sehe ja, was ich leiste. Ich mache ich Projekten das, woran in anderen Projekten fünf Leute gemeinsam dran arbeiten. Ich bin sogar noch ohne Allüren. Während andere mit dem Taxi vom Bahnhof kommen oder zum Bahnhof fahren, da nehme ich den ÖPNV. (Tatsächlich gab es bei uns mal eine jüngere Minderleisterin, die nicht mit der Tram zum Bahnhof fuhr, obwohl die Tram keine 20 Minuten braucht und praktisch direkt vor dem Büro startet.) Ein Kollege sagte mal Telefon: "Rudi, das finde ich so toll an dir. Wir schildern ein Problem und du suchst zuerst in deinem Code." - Kann ich mir vorstellen. Ich hatte schon öfter Kollegen, die angepisst reagieren. Habe ich schon mal erzählt, dass ein anderer Entwickler mich angeschrien hat? Ich schrieb ihm freundlich, dass ein bestimmter Teil Code nicht funktionieren könne, ich begründete es auch detailliert. Keine Antwort. Ich sprach ihn zwei Tage später persönlich drauf an. Er reagierte eher abweisend, er würde sich irgendwann mal drum kümmern. Also änderte ich es und schon explodierte er: "Aber der Test hat doch gezeigt, dass es funktioniert." - Dass ein Softwaretest nicht die Abwesenheit von Fehler beweist, hatte er wohl noch nie gehört. Dieser Mensch hatte jahrelang das Projekt mit seinem schlechten Code in die Grütze geritten, ja in die Grütze reiten dürfen, weil oben drüber keine Fachkundigen standen, und den damals jungen Mann an die kurzen Leine nahmen. Wenn ich 'nen Schusslichkeitsfehler einbaue, wenn etwas seltsam ausschaut, und es mir gemeldet wird, dann behebe ich das sofort, denn mir ist klar, dass Fehler möglichst früh behoben werden müssen. Und gerade wenn die Lösung klar ist und das alles nur fünf Minuten braucht, mache ich das sofort oder halt geordnet noch am selben Tag. Und ein Entwickler, der das nicht einsieht, hat seinen Beruf verfehlt. Ein typischer Fehler in der Java-Welt ist, versehentlich einen Enumerate mit einem String zu vergleichen. Da dass konstant falsch ist, kann es kaum das sein, was der Entwickler beabsichtigen konnte. Die statische Code-Analyse findet das schnell. So viele Entwickler ignorieren das einfach. Schon viel zu oft erlebt. Franko S. schrieb: > Dann steckt Typen als Architekten in euer Scrumteam. Er gibt das Desing Das wird nichts. So viel Architektur-Entscheidungen müsse ja gar nicht mehr getroffen werden. Das Problem sind die Entwickler, die vieles falsch verstehen. Ich habe gerade mit Entwickler zu tun, die ständig neue Persistenzklassen aus der Taufe heben, wo ich schon mehr sagte, dass die nicht gebraucht werden, aber es passiert nichts. Ich habe es auch dem Projektleiter und dem Scrum-Master gesagt. Es fehlt dann oft auch der gesunde Menschenverstand. Wenn ich beispielsweise Konstruktoren bei Klassen sehe, wo ca. 20 Primitive als Argumente übergeben werden müssen (für jedes Feld einen), dann verstehe ich nicht, was in diesen Leuten vorgeht. Wollen die, dass die Leute sich verhaspeln? Gibt es ein Verbot am Konstruktor die drei, vier wichtigsten Sachen zu übergeben und ansonsten nimmt man die Setter-Methoden. Und in einer Fabrik kann man ein paar Methoden zum Erzeugen von Objekten dieser Klasse bereitstellen. Ich habe es - so mein Eindruck - mit Entwicklern zu tun, die exakte Regeln brauchen. Mein Hinweis, maximal drei, vier Argumente und nur die wichtigsten, ist schon zu viel Spielraum. Für die gibt es nur: Gar keine Argumente oder alle. Mit Sachen wie: "gesunder Menschenverstand", so ein Konstruktorenaufruf/Methodenaufruf müsse überblickbar sein, erfordert ja eigenständiges Denken und Handeln.
Bruno V. schrieb: > Rudi R. schrieb: >> Die würden es sogar hinbekommen, das Konzept Festplattensektor nach ganz >> oben ins Word-Programm zu schleifen, > > Schönes Bild! > > Rudi R. schrieb: >> Die UML-Diagramme sollen mir zeigen, worauf es ankommt. > > Das klappt m.E. nur, wenn alle Beteiligten auch wirklich UML sprechen. > Sonst unterscheidet es sich kaum von Visio Bubble-Pfeildiagrammen (was > OK ist, nur sollte man es dann nicht UML nennen) Es sollte unter Entwicklern Standard sein, finde ich. Ich habe mich eigenmächtig mal darum bemüht. Ich halte aber auch andere graphische Verfahren für nicht falsch. Was ich aber absolut nervtötend finde, wenn jemand um die Ecke kommt, und mit seiner Grafik nicht in der Lage ist, den Wesenskern zu illustrieren. So der Kommilitone von 2006, der in seinem ArgoUML-Blatt alle seine Klassen unterbrachte und alle Felder der Klassen waren auch angezeigt. Die wichtigen Beziehungen der Klassen untereinandern aber gingen da unter. Dann kann ich mir doch gleich den Code anschauen. Wie ich gesehen habe, ist die UML sogar Teil des Ausbildungsberufes Fachinformatiker für Anwendungsentwicklung.
Rudi R. schrieb: > seinem ArgoUML-Blatt alle seine Klassen unterbrachte und alle Felder der > Klassen waren auch angezeigt. Die wichtigen Beziehungen der Klassen > untereinandern aber gingen da unter. Dann kann ich mir doch gleich den > Code anschauen. Vielleicht konnte er ArguUML nicht bedienen.
Michael B. schrieb: > um was herausragendes zu entwickeln, darfst du nicht nur Durchschnitt > sein. > > Alle herausragenden Produkte wurden von Diven (Helden) ersonnen und > entwickelt. Dem würde ich sogar soweit zustimmen. Aber: Wie viele herausragende Produkte haben denn die Unternehmen dieser Welt tatsächlich? Und wie viele "Brot-und-Butter" Produkte, mit denen ein großer Teil des Umsatzes erwirtschaftet wird? Apple hatte mit dem iPhone die Idee des Jahrhunderts. Kein anderes Gerät hat unser aller Leben so sehr und so nachhaltig beeinflusst. Freilich: Seit dem iPhone kam nichts anderes mehr, was auch nur annähernd so innovativ war. Dennoch verdient die Firma prächtig viel Geld. Braucht man auch geniale Entwickler? Wenn man etwas Geniales entwickeln will, dann schon. Aber noch viel mehr braucht man solide Entwickler, die ihren Job beherrschen ohne unbedingt Genies zu sein. Nicht jede Aufgabe in einer Firma ist super interessant und super kreativ. Dennoch muss die Arbeit erledigt werden.
Mark B. schrieb: > Nicht jede Aufgabe in einer Firma ist super interessant und super > kreativ. Dennoch muss die Arbeit erledigt werden. Bei vielen Produkten wäre es nicht schade, wenn die Arbeit nicht erledigt worden wäre :D
Mark B. schrieb: > Nicht mal der beste Programmierer der Welt kann ein Projekt retten, wenn > das Requirements Management nichts taugt. Wenn der Vertrieb dem Kunden > sonstwas verspricht - aber selbst auf Nachfrage nicht präzise sagen > kann, was dem Kunden denn nun alles verkauft wurde - was willste dann > machen? Also ich hole dann den Michael "laberkopp" B., der im Nachbarthread [1] alle zu "Idioten und Pfeifen" erklärt, die nicht alles vorausplanen können. ;-) [1] Beitrag "Re: SCRUM und die Arbeitsweise von Selbständigen"
Mark B. schrieb: > > Braucht man auch geniale Entwickler? Wenn man etwas Geniales entwickeln > will, dann schon. Aber noch viel mehr braucht man solide Entwickler, die > ihren Job beherrschen ohne unbedingt Genies zu sein. Ja, die braucht es auch. Gibt es aber auch zu wenig. Ich habe schon einige Leute darüber nölen hören, die fachfremd sind, Software entwickeln, aber der Meinung sind, man müsste auf das, was in den schlauen Büchern steht, komplett pfeifen. Es verlangt ja niemand, dass man gleich den nächsten Videokompressionsalgorithmus entwickelt. Aber selbst von einem soliden Entwickler erwarte ich solide Kenntnisse und die sehe ich häufig nicht. Man guckt in leere Augen, wenn das Wort Observer-Muster fällt. Die kennen nur oft nur die in der Firma verwendeten Muster und Idiome. Franko S. schrieb: > Vielleicht konnte er ArguUML nicht bedienen. Das wäre keine Entschuldigung. Er hat sich da offensichtlich nicht bemüht, mehrere Zeichenblätter aufzumachen. Unwichtige Felder konnte man da meines Wissens auch ausblenden. Er hat diese Möglichkeiten nicht gefunden, weil er sie nicht gesucht hat. Und warum hat er sie nicht gesucht? Weil er den Sinn der UML nicht verstanden hat. Der Sinn war nie, bis ins letzte Detail alles zu beschreiben, sondern zu visualisieren, was der Wesenskern der Architektur ist und von Teilen der Architektur ist. Ich glaube, das kommt daher, dass viele gar nicht mehr auf Papier Gedanken bringen, sondern meinen, man müsse unbedingt Werkzeuge wie ArgoUML und Enterprise Architect. Ich hingegen skizziere regelmäßig meine Architekturen auf Papier. Der Traum, das man in einem UML-Tool auf einen Knopf drückt und es kommt gescheiter Code heraus, ist ja auch zerplatzt. Ein T. schrieb: > Also ich hole dann den Michael "laberkopp" B., der im Nachbarthread [1] > alle zu "Idioten und Pfeifen" erklärt, die nicht alles vorausplanen > können. ;-) Man muss wissen, wissen, mit welchem Imponderabilien man leben kann und mit welchen nicht. Ich gestalte Software mit Strategienklassen so, dass da schnell etwas austauschbar gestaltet ist und ich erstmal einen Billig-Strategie implementiere, die halbwegs robust ist und andere Entwickler nicht aufhält. Schlimm finde ich es, wenn in dem Moment, wenn ich noch so viele andere Aufgaben habe, Leute um die Ecke kommen, und die endgültige Strategie stundenlang diskutieren wollen. Da gehört dann auch Selbstbewusstsein hinzu, zu sagen, dass dazu im Moment keine Zeit sei. Ich musste in meinem letzten Projekt mehrfach den Projektleiter kontra geben. Imponderabilien, mit denen man nicht leben kann, sind grundlegende architektonische Entscheidungen. Wenn man weiß, dass etwas suboptimal ist und später auch schwer herausoperierbar ist, sollte man sich genau überlegen, ob es das wert ist. Auch schon mehrfach erlebt. Bestes Beispiel sind BIRT-Report. Ein fürchterliches Framework. Das Versprechen, ein Eclipse-Plugin übernimmt die meiste Arbeit. Nun war die Benutzung dieses Plugins eine Wissenschaft für sich und nach einem kleineren Update des Eclipses oder des Plugins schon wieder inkompatibel. Was ich machen würde, wenn um Statistiken geht: Rohdaten werden gesammelt und weggeschrieben, und man bietet REST-Schnittstellen an, mit denen sich Python Pandas oder R verbinden kann. Bei uns wird zwar nicht mehr BIRT verwendet, denn man hat daraus gelernt, aber man fummelt mit JGraph und Konsorten Zeugs zusammen, wo ich sehe, dass da viel Entwicklerarbeit dahintersteckt, aber mein Ansatz, eine Schnittstelle für einen Profitool zu schreiben, viel besser und schneller wäre. (Ich habe sowas mal geschrieben.) Nur setzt sich diese Idee nur schlecht durch, weil dann wieder Vorbehalte kommen, Java könne man doch und der ganze Nonsens. Die Folge ist aber, dass man falsche Statistiken und Diagramme hat, weil nicht jedem Entwickler klar ist, was ein Durchschnitt ist.
Rudi R. schrieb: > Man guckt in leere Augen, wenn das Wort > Observer-Muster fällt. Die kennen nur oft nur die in der Firma > verwendeten Muster und Idiome. Da gibt es m.E. 2 Arten von "Enttäuschungen": A) Leute, die das Pattern kennen, sich über alle Aspekte vortrefflich austauschen können und letztendlich 0 Erfahrung damit haben. Das wäre OK, dafür wurden sie ja kanonisiert. Problematisch wird es, wenn das Muster dann nur halb auf das Problem passt. B) Leute, die das Pattern nicht kennen, also auch nicht das Vokabular, aber jahrelange Erfahrung bei dessen Implementierung besitzen. Die Pattern waren ja nicht neu sondern beschrieben und benannten Best-Practices, die wie Dein Beispiel schon in Assembler umgesetzt wurden.
Bruno V. schrieb: > B) Leute, die das Pattern nicht kennen, also auch nicht das Vokabular, > aber jahrelange Erfahrung bei dessen Implementierung besitzen. Die > Pattern waren ja nicht neu sondern beschrieben und benannten > Best-Practices, die wie Dein Beispiel schon in Assembler umgesetzt > wurden. Ja nur wenn man die Terminologie beherrscht kann man sich halt schnell und effizient austauschen. Deshalb ist das wichtig. Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben, aber mal zufällig eins implementiert haben bringen einen nicht weiter.
Mark B. schrieb: > Und wie viele "Brot-und-Butter" Produkte, mit denen > ein großer Teil des Umsatzes erwirtschaftet wird? B&B Produkte sind die in die Jahre gekommenen ehemaligen Top-Innovationen. Cyblord -. schrieb: > die noch nie von Pattern gehört haben hör mir blos auf mit "pattern" und anderem Entwicklergedöhns! Rudi R. schrieb: > Imponderabilien Genau die, ja, das sind die Besten. (Ich geh jetzt googlen, was das ist ...)
Bernd schrieb: > B&B Produkte sind die in die Jahre gekommenen ehemaligen > Top-Innovationen. Je nun, irgendwann mal war alles neu. Auch Brot und Butter wurden einst erfunden. Oder vielleicht auch per Zufall entdeckt.
Cyblord -. schrieb: > Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben, > aber mal zufällig eins implementiert haben bringen einen nicht weiter. Wie geht der Spruch? Ein Nicht OO-Entwickler hat Probleme in seinem Programm. Dann kommt ein OO-Fanboi angetanzt und sagt ihm dass das daran läge, weil er keine Pattern nutzt. Dann geht der Fanboi wieder an seinen Rechner und grübelt über seine ProblemFactories.
Franko S. schrieb: > Cyblord -. schrieb: >> Irgendwelche Assembler Frickler die noch nie von Pattern gehört haben, >> aber mal zufällig eins implementiert haben bringen einen nicht weiter. > Wie geht der Spruch? > Ein Nicht OO-Entwickler hat Probleme in seinem Programm. Dann kommt ein > OO-Fanboi angetanzt und sagt ihm dass das daran läge, weil er keine > Pattern nutzt. Dann geht der Fanboi wieder an seinen Rechner und grübelt > über seine ProblemFactories. Pattern sind nicht auf OO beschränkt. Den Rest deiner Ausführungen und Gedanken kann und sollte man sich schenken.
Cyblord -. schrieb: > Pattern sind nicht auf OO beschränkt. Den Rest deiner Ausführungen und > Gedanken kann und sollte man sich schenken. [ ] Das hast den Kern des Spruches erfasst. [X] Einen Rest gibt es nicht. [X] Du bist vermutlich besoffen.
Steve van de Grens schrieb: > In so einem Fall ist es ziemlich ungünstig, wenn der selbsternannte Held > gar keiner ist. Hochmut kommt vor dem Fall. Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das erdet. :-)
Ein T. schrieb: > Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das > aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was > ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das > erdet. :-) Schrödingers Programmierer: Er schreibt im gleichen Projekt sowohl guten als auch schlechten Code. ;-)
:
Bearbeitet durch User
Ein T. schrieb: > Hin und wieder lese ich Quellcode, und manchmal denke ich dann "wow, das > aber mal elegant gelöst" und dann an anderen Stellen "meine Güte, was > ein Unfug". Am Ende sehe ich dann: beide Codestellen sind von mir. Das > erdet. :-) Und wenn du mit der Zeit bei der Betrachtung alter eigener Lösungen immer mehr von der ersten und immer weniger von der zweiten Variante findest, dann kannst du es als Indikator des Alterns ansehen. :)
:
Bearbeitet durch User
(prx) A. K. schrieb: > Und wenn du mit der Zeit bei der Betrachtung alter eigener Lösungen > immer mehr von der ersten und immer weniger von der zweiten Variante > findest, dann kannst du es als Indikator des Alterns ansehen. :) Das Alter funktioniert leider in beide Richtungen... :-)
Rudi R. schrieb: > Ein Projekt, nur mit mir alleine, das wär's doch. Ja du bist der tollte Hecht im Karpfenteich, in Selbstbeweihräucherung bekommst du ne Eins mit Sternchen.
Rudi R. schrieb: > Ein Projekt, nur mit mir alleine, das wär's doch. Vielleicht kann Dir jemand eine Webseite mit Unbekleideten empfehlen, und der Erfolg Deines Projekts wird auf der Hand liegen. Viel Spaß! :-)
Steve van de Grens schrieb: > Im Team muss man so entwickeln, dass alle Kollegen durch blicken. Die Frage ist doch, wie sehr sie durchblicken müssen, um ihre Arbeit zu machen. Kann kann unmöglich alle Details der Überlegungen und Festlegungen der Kollegen durchschauen. Es geht darum, genau das richtige zu wissen und dazu müssen die Teilnehmer aktiv kommunizieren. Solche Dinge sind es, die über den Erfolg eines Teams entscheiden und nicht, ob es nach Scrum geht oder sonst irgendwie. Mit diesem transparenten Arbeiten tun sich aber viele schwer, sondern kommunizieren nur das Eingeforderte und hocken ansonsten auf ihren Lösungen. Auch wenn es keine Absicht ist, haben sehr viele gebildete Akademiker eine Problem mit bildlichen und textbasierten Darstellungen ihrer Überlegungen, sodass es überhaupt erst möglich wäre, das es ein anderer plausibilisert oder gar mitdenkt, bzw irgendwann weiterwickelt. Sie haben auch Probleme einzuschäzen, wieviel sie wann offenbaren und aktiv darstellen müssen, weil sie die Schnittstelle zwischen den Bearbeitern nicht bedienenen können. Oftmals hört man, der hätte ja fragen können. Solches Wirken ist aber nötig und essenziell für eine gute Zusammenarbeit. Wenn das fehlt, läuft nichts. Dagegen hilft auch das Scrummen nicht. Das verschlimmert das Problem eher.
Scrum löst so viel Zustimmung im Management aus weil es eine Steigerung der Produktivität verspricht. Produktivität ist der einzige Maßstab, der für das Management relevant ist. Leider kann das Management die Produktivität bei Software nicht beurteilen. Was ist schell programmieren, wann ist das Arbeitsergebnis Ausschuss oder hochwertig. Das Unwissen wird gemessen in "der Kunde/Anwender ist zufrieden (aka gibt bei uns Geld aus, Umsatz mit dem Softwareprodukt)". Scrum Begriffe werden fehlinterpretiert ( Sprint - alle rennen mit voller Energie und bis zur Erschöpfung zum Ziel, Ticket - zähle die Tickets und du kannst die Produktion von Software quantifizieren, scrum Rollen - Verantwortliche die man zur Rechenschaft zieht wenn der Kunde meckert ( Scrum Master - Termin nicht eingehalten, Programmierer - Bug in Softwarepaket vom Ticket ). Scrum war gedacht um Entwicklungsprozesse zu organisieren durch Experten, Scrum wird benutzt um Entwicklungsprozesse unter Produktivitätszwang zu setzen durch Fachfremde. Der Knoten lässt sich nicht lösen, darum bekommen Programmierer oft kein Gehalt sondern Schmerzensgeld. Das Grundübel lautet immer : ich brauche 1000 Zeilen Code, wer macht das billiger in kürzerer Zeit. Firmen, die ihre eigene Software einsetzen müssen, um Geld zu verdienen, machen nicht automatisch besseren Code, aber sie stehen unter einem Selektionsdruck. Beispiel gaming: 1 Spiel programmieren, das über Jahre Geld bringt oder 100 Casual Games, die nur kurz relevant bleiben. Das eine Spiel muss exzellent sein, die 100 Games können Massenschund sein, müssen es aber nicht.
Das Management ist bei der Softwareentwicklung in folgender Situation gefangen: Vor ihnen stehen 2 Fernseher, auf jedem läuft eine Kochschow, in dem ein Team ein Menü zubereitet. Die eine Show dauert 30min, die zweite Show dauert 45min. In beiden Shows gibt es viel Drama, Action, glückliche Momente. Am Ende muss das Management sagen welches Essen sie auf die eigene Speisekarte bringen und zu welchem Preis. Wie müsste die Begründung aussehen und wie ist die Begründung in der Realität ? Scrum verspricht eine faktenbasierte Bewertung ohne das Essen geschmeckt zu haben.
Scrum wäre längst abgeschafft wenn das Management nicht darin ein Werkzeug für sich selbst sehen würde. Ob scrum für die Entwickler nützlich ist, ist nur zweitrangig.
Solange Scrum das Weisungsrecht fachlicher und disziplinarischer Vorgesetzter nicht vollständig ersetzt, ist Scrum eine Clownshow.
Markus H. schrieb: > Produktivität ist der einzige Maßstab, der > für das Management relevant ist. Na die Qualität und das Ergebnis = Kundenbewertung wird schon auch eine Rolle spielen, denke ich :-) Die Prouktivität ist natürlich die am besten zu bewertende Größe in Sachen Kosten und dem Verhältnis von Verkaufbarkeit, Marktreserve und der Umsatzerwartung und eben den negativ wirkenden Kosten, welche die Rentabilität mindern oder sogar ins Negative verkehren können. Das kann die Geschäftsführung ja direkt sehen, oder sie könnte es jedenfalls: > Leider kann das Management die > Produktivität bei Software nicht beurteilen. Nur auf den ersten Blick! Das lässt sich durchaus machen, wenn man die Zeiten für einzelne Tätigkeiten mitprotokolliert, einschließlich der Kosten und Zeiten für Planung und Gespräche, den Aufwand für Orga, Schulungen und Trainings (auch Scrumtrainings !), aber auch dem Aufwand der späteren Inbetriebnahme und der Fehlerbehebung in Sachen Garantie! Das sind wesentliche Komponenten! Besonders dann, wenn es nicht nur um reine Softwareprodukte geht, sondern um Software oder firmware, die in großen Geräten sitz, die dort die Funktion macht, ist das so, weil sie in der Entwicklung nur einen Teil der Kosten verursacht, aber bei Fehlfunktionen zu enormen Aufwänden und Kosten bei der IB* und der IM* führt. Da zeigt sich, wie wichtig das Kriterium der qualitativ soliden und vollständigen Entwicklung der SW vor deren Entwicklungsgeschwindigkeit und dem Fertigstellungszeitpunkt ist! Was vorneweg nicht eingeplant wurde, wird hinterher sehr viel teuer. Und es zeigt sich, dass man schon bei der Entwicklung auf die IB* und die IM*-Anforderungen Rücksicht nehmen muss. Dazu aber sind viele Entwickler mit der reduzierten Sicht nicht in der Lage. Wenn dann von Außen nicht das Team mit solchen Kriterien versorgt wird, sie also Teil der Aufgabenstellung sind, dann kriegt man aus dem Teamentscheid ein unzureichendes Ergebnis heruas. Genau das zeigt sich durch solche Kostennachbetrachtungen bei Projekten und besonders tritt der Unterschied dann zutage, wenn man wenn diese Daten hat bevor und nachdem etwas an den Prozessen geändert wurde. Soweit das Kunden von mir gemacht haben, hat sich gezeigt, dass sich durch Scrum nichts verbessert hat. Es gab nur mehr Kosten durch Diskussionen. Im Gegenteil: Nicht wenige haben Scrum eben deshalb wieder rausgeschmissen und sich auf die genauere Definition der Ziele durch kompetente(re) Systemingenieure konzentiert, damit die umsetzenden Teams genauere Vorgaben hatten. Es hat sich nämlich gezeigt, dass der große Vorteil von Scum, nämlich das Reagieren auf sich ändernde Wünsche in solchen Projekten extrem nachteilig ist, weil das Zulassen solcher Änderungen immer zu erhöhten Aufwänden und Risiken in späteren Phasen von Projekten führt. Es ist daher besser und effektiver, man setzt den Rahmen genauer und investiert Zeit, um zuverweiden, dass sich Anforderungen mitten drin ändern. ----------------- *IB = InBetriebnahme *IM = InMarktbringung
:
Bearbeitet durch User
Markus H. schrieb: > Das Grundübel lautet immer : ich brauche 1000 Zeilen > Code, wer macht das billiger in kürzerer Zeit. In meinen 1,5 Jahrzehnten in der (Embedded-) Softwareentwicklung, in diversen Positionen, habe ich noch nie einen Manager, einen Projektleiter, einen Kunden oder einen Zulieferer erlebt der sich irgendwas aus lines of code macht. Niemand zählt die loc, niemand verlangt so-und-soviel loc und niemand zahlt nach loc oder lässt sich für loc bezahlen. Überhaupt ist der Begriff in meiner Branche nichtexistent, ich hör das nur dauernd von Heulsusen im Netz.
Rainer Z. schrieb: > Solange Scrum das Weisungsrecht fachlicher und disziplinarischer > Vorgesetzter nicht vollständig ersetzt, ist Scrum eine Clownshow. Heißt das, dass aus deiner Sicht dies ein Ziel sein sollte? - Dass Scrum die Führung ersetzt? Scrum / der ScrumMaster soll sich doch aus dem fachlichen raushalten und keine Aussage dazu machen. Für das Fachliche gibt es keine Vorgaben. Das muss also gänzlich aus der Gruppe kommen. Ich halte das für Theorie. Hat auch noch nirgends funktioniert. Le X. schrieb: > Markus H. schrieb: >> Das Grundübel lautet immer : ich brauche 1000 Zeilen >> Code, wer macht das billiger in kürzerer Zeit. > > In meinen 1,5 Jahrzehnten in der (Embedded-) Softwareentwicklung, in > diversen Positionen, habe ich noch nie einen Manager, einen > Projektleiter, einen Kunden oder einen Zulieferer erlebt der sich > irgendwas aus lines of code macht. Mal abgesehen, dass ich das seltsam finde, dass einer in "1,5 Jahren" diverse Position gehabt haben will, scheint mir das anders gemeint gewesen zu sein: Es geht nicht um eine konkrete Codezeilenzahl. Die kennt der Beauftrager eh nicht im Voraus. Aber sie suchen immer den Billigsten. Die Hauptaufgabe des Programmierens kriegen deshalb gerne die Anfänger, die nichts anderes können.
B. schrieb: > dass einer in "1,5 Jahren" diverse Position gehabt haben will, Er schrub von 1,5 Jahrzehnten. Das sind 15 Jahre, nicht 1,5 Jahre
Wegstaben V. schrieb: > Er schrub von 1,5 Jahrzehnten. ok, überlesen. Dann lassen wir das beiseite. Die Kernfrage bleibt: Soll Scrum den technischen Fachverantworlichen ersetzen? Das Ideal des auf mehrere Personen verteilten Gehirns? Wie ich schon schrieb (seit wann heißt das "schrub") habe ich damit sehr schlechte Erfahrungen gemacht. Das gibt Kompetenzgerangel, Positionskampf und zieht ellenlange Diskussionen über mögliche Lösungen nach sich. Ohne einen technischen Projektleiter, der Verantwortung hat und die Vorgaben macht, geht da nichts.
Neulich in einer Softwarebude: Bieten Scrumberatung für andere Firmen an, entwickeln auch selber Software. Frage: Verwendet ihr auch Scrum und wie? AW: Äh ne das stört nur, wir machen mit Scrum nur Beratung. Wenigstens waren sie ehrlich.
Franko S. schrieb: > Wenigstens waren sie ehrlich. Es ist immer klug, dem potentiellen Konkurrenten Steine in den Weg zu rollen um selbst flinker am Ziel zu sein.
Franko S. schrieb: > Neulich in einer Softwarebude: > Bieten Scrumberatung für andere Firmen an, entwickeln auch selber > Software. Frage: Verwendet ihr auch Scrum und wie? AW: Äh ne das stört > nur, wir machen mit Scrum nur Beratung. Wenigstens waren sie ehrlich. Mal wieder Geschichten ausm Paulanergarten.
Cyblord -. schrieb: > Mal wieder Geschichten ausm Paulanergarten. Der hat noch geschlossen, dehalb wahr.
Cyblord -. schrieb: > Geschichten ausm Paulanergarten. In einem solchen Umfeld dürfte der Scrum-mist erdacht worden sein.
🐻 Bernie - Bär schrieb: > Scrum-mist Keine Ahnung, aber felsenfeste Vorurteile. Du demonstrierst ziemlich gut, was das Problem mit Projektleitern ist, die niemandem zuhören können oder wollen und sich überall einmischen, weil sie alles besser zu wissen glauben. Danke.
Ein T. schrieb: > Keine Ahnung, aber felsenfeste Vorurteile. Erfahrung lieber Mr. T, Erfahrung. Scrum wird wie so vieles was aus den USA kommt, mit einem selbstverständlichen Automatismus gehyped, ohne jegliche Hinterfragung. Das System eignet sich bestenfalls für Ausschnitte der Projektlandschaft und der täglichen Arbeit, nur können das viele Entwickler mit ihrer schmalbandigen Erfahrung nicht erkennen.
🐻 Bernie - Bär schrieb: > das viele Entwickler mit ihrer schmalbandigen Erfahrung nicht erkennen. Was für ein Glück, daß ich nicht immer nur Entwickler war und ein bisschen mehr als nur "schmalbandige Erfahrung" gesammelt habe. Aber auch hier zeigt sich wieder das alte Problem mit der Selbstüberschätzung und -Überhöhung bei manchen Projektleitern, die sich selbst für klüger halten als alle anderen.
Rudi R. schrieb: > Und das scheint mir auch ein kulturelles Problem, dass in > anderen Kulturen kräftig geklappert wird, speziell die Amerikaner. War wohl damals in der DDR auch beliebt. Das kann man sogar heute noch beobachten, und als Sahnehäubchen obendrauf: Verlogenheit. Das muss aber nicht automatisch heißen, die Leute wären unfähig. Man hat nicht viel mehr dagegen, als mit guten Beispiel voranzugehen. Also Sorgfalt da wo sie angezeigt ist, Kompromisse mit allen Beteiligten (nicht nur mit einigen), Liebe zur Qualität usw. Ein anderer Punkt wäre noch Korruption. Ehrlichkeit und Anstand gehören auch zum Leben, nicht nur abkassieren, schummeln oder die Mitmenschen für PlemPlem halten. Einen der besseren Texte dazu gibt es beim Simplicssimus in der ungekürzten Ausgabe wo es ums Würfeln auf einem "Spielplatz" geht. Sehr unterhaltsam, sehr merkwürdig. https://www.projekt-gutenberg.org/grimmels/simpl/simpl220.html
Interessant ist dass es in Big Techfirmen keine grosse Rolle spielt: https://blog.pragmaticengineer.com/project-management-at-big-tech/ Da zählt kein cargo cult sondern nur output.
🐻 Bernie - Bär schrieb: > Die Kernfrage bleibt: Soll Scrum den technischen Fachverantworlichen > ersetzen? Das Ideal des auf mehrere Personen verteilten Gehirns Nein, soll und will es nicht. Scrum ist ausserdem für komplexe Projekte gedacht wo eben nicht schon jeder alle Antworten kennt sondern diese iterativ erarbeitet sollen. Und der projektverantwortliche ist der Product Owner. Der kippt Anforderungen ein & klärt Dinge ab. Ach so... Und Hirn einschalten ist auch noch erforderlich wenn man Scrum einsetzt
https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt.
Franko S. schrieb: > Lest euch das mal durch wenn das jeder genau durch liest - es sind ja an die 100 Punkte - dann vergeht mehr Zeit, als man mit dem besten Scrum jemals wieder reinholen kann :-) A. B. schrieb: > der projektverantwortliche ist der Product Owner. Der kippt Anforderungen Da sehe ich aber ein Problem: Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern praktisch immer ein ganzes Bündel an Personen, das die Anforderungen definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht es deutlich mehr, als einen "product owner". Oder aber das "product" ist nur eine kleine Subkomponente, die wirklich von einer Person gehandhabt werden kann.
Franko S. schrieb: > https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm > Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt Die Seite ist Gold: Einfach mal die Hauptbegriffe durch Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten. Vielleicht öffnet das den Fanboys die Augen.
J. S. schrieb: > A. B. schrieb: >> der projektverantwortliche ist der Product Owner. Der kippt Anforderungen > Da sehe ich aber ein Problem: > > Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern > praktisch immer ein ganzes Bündel an Personen, das die Anforderungen > definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht > es deutlich mehr, als einen "product owner". Oder aber das "product" ist > nur eine kleine Subkomponente, die wirklich von einer Person gehandhabt > werden kann. Er soll das ja auch nicht alleine machen sondern zusammen mit den Leuten erarbeiten die davon Plan haben. Dafür gibt's dann das Product Backlog Refinement z.B. Außerdem kann er solche Aufgaben auch delegieren wenn es sinnvoll erscheint. Er bleibt aber fürs Gesamtergebnis verantwortlich und sollte es in die richtige Richtung lenken. Wie gut die Theorie dann in der Praxis funktioniert sei mal dahingestellt
Rainer Z. schrieb: > Die Seite ist Gold: Einfach mal die Hauptbegriffe durch > Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten. > Vielleicht öffnet das den Fanboys die Augen. "Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine gemeinsame Vision für den Super Circle. Er schafft einen offenen und transparenten Austausch innerhalb des Super Circles und stimmt sich mit internen und externen Stakeholdern des Super Circles ab." klingt für mich teilweise wie Satire. Kann sich da wirklich jemand "vom Fussvolk" mit so einer Sprache identifizieren? Jemand ist da anscheinend in einen englischen Sprach-Topf gefallen und kommt da nicht wieder raus ...
:
Bearbeitet durch User
Rainer Z. schrieb: > Franko S. schrieb: >> https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm >> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt > > Die Seite ist Gold: Einfach mal die Hauptbegriffe durch > Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten. > Vielleicht öffnet das den Fanboys die Augen. Nenne konkrete Beispiele und hau nicht so sinnlos „Alles ist Scheiße“ in den Raum. Dann können wir darüber sprechen, was jeder verstanden hat. PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich erfolgreich, was man von vielen anderen Banken nicht sagen kann…
Franko S. schrieb: > Interessant ist dass es in Big Techfirmen keine grosse Rolle spielt: > > https://blog.pragmaticengineer.com/project-management-at-big-tech/ > > Da zählt kein cargo cult sondern nur output. Das behauptet zwar der von Dir verlinkte Artikel, aber wenn ich dazu einmal die Internet-Suchmaschine meines erträglichsten Mißtrauens bemühe, sieht die Sache ganz anders aus, als der Artikel beinhaltet. Alleine unter den ersten Suchergebnissen finden sich eine Stellenanzeige von Microsoft für einen Scrum Master und ein Artikel über Google Sprints -- weiter habe ich nicht geschaut, weil mir die Sache nicht wichtig genug ist und mir die Behauptungen aus dem Artikel damit bereits widerlegt zu sein scheinen.
J. S. schrieb: > Hoch komplexe Geräte mit diffizilen messtechnischen Methoden erfordern > praktisch immer ein ganzes Bündel an Personen, das die Anforderungen > definiert, weil das Wissen über die halbe Firma verteilt ist. Da braucht > es deutlich mehr, als einen "product owner". Das stimmt. Es braucht dazu aber natürlich auch mehr als einen "Projektleiter" "technischen Fachverantwortlichen", und deswegen wird unbedingt eine Methode zur Kommunikation zwischen diesen Leuten nötig.
Uwe D. schrieb: > PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich > erfolgreich, was man von vielen anderen Banken nicht sagen kann… so so ..... ob das an scrum liegt oder einfach am Markt? https://www.handelsblatt.com/finanzen/banken-versicherungen/banken/deutsche-bank-bestes-ergebnis-seit-15-jahren-aber-anleger-sind-enttaeuscht/28957940.html https://www.handelsblatt.com/finanzen/banken-versicherungen/banken/jahreszahlen-niederlaendische-grossbank-ing-enttaeuscht-mit-ausblick-aktie-buesst-ein/28959120.html fühlt sich eher wie eine Marketingstrategie an.
Uwe D. schrieb: > Dann können wir darüber sprechen, was jeder verstanden hat. Was ist ein Squad? rhf
:
Bearbeitet durch User
Gerhard M. schrieb: > Uwe D. schrieb: >> PS: Im Gegensatz zu vielen anderen Banken ist die ING wirtschaftlich >> erfolgreich, was man von vielen anderen Banken nicht sagen kann… > > so so ..... ob das an scrum liegt oder einfach am Markt? > … > fühlt sich eher wie eine Marketingstrategie an. „Agil“ heißt, schnell auf Richtungsänderungen zu reagieren. Alles mit „Marketing“ zu erschlagen ist ein schwaches Argument. Das WARUM kann ich nicht direkt beantworten, nur befürworten. Siehe: https://www.manager-magazin.de/unternehmen/agiles-arbeiten-wie-radikal-nick-jue-die-bank-ing-umbaut-a-57b3b24d-b6e0-491a-8004-f01e2041691d Oder https://www.wiwo.de/erfolg/management/agiles-arbeiten-wer-nicht-aufpasst-dem-fliegt-das-projekt-um-die-ohren/19988386.html https://entwickler.de/agile/agile-im-konzern-kann-das-funktionieren-001 Nachtrag: Ich liebe die intellektuell Überforderten, die reflexhaft negativ bewerten anstatt in einen Dialog zu kommen.
:
Bearbeitet durch User
Uwe D. schrieb: > Rainer Z. schrieb: >> Franko S. schrieb: >>> https://www.ing.jobs/deutschland/warum-ing/agiles-arbeiten.htm >>> Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt >> >> Die Seite ist Gold: Einfach mal die Hauptbegriffe durch >> Phantasiebegriffe ersetzen und übrige Beschreibung beibehalten. >> Vielleicht öffnet das den Fanboys die Augen. > > Nenne konkrete Beispiele und hau nicht so sinnlos „Alles ist Scheiße“ in > den Raum. Dann können wir darüber sprechen, was jeder verstanden hat. "Der Plumbus ist verantwortlich für das „Was“ (operationale Ebene) in einem Hurtz und für die Maximierung des Wertes der erledigten Arbeit. Der PB legt Ipsum fest und setzt Prioritäten bezüglich der zurückgestellten Arbeit des Hurtz."
Wegstaben V. schrieb: > Rainer Z. schrieb: >> Die Seite ist Gold: Man möge sich vor Augen führen, dass es sich bei der Firma um eine Bank handelt, die virtuell ist, also keine Filialen hat, und die zudem noch in den Niederlanden sitzt, wo viel seltsame Sachen geraucht werden. Die ING hat z.B. in einem Anfall von Größenwahn Anfang des Jahres satte 3,75% Zinsen fürs Tagesgeld ausgelobt und dann festgestellt, dass sie kaum neue Kunden, sondern nur neues Geld bekommen hat, das die Kunden (wie ich auch!) nur im Kreis gebucht haben, weil andere Banken wie die Postbank das auch gemacht haben. Hinzu kommen einige wenige Kunden, die in Brokermanier genau die maximale Anlagesumme von 100.000 eingebucht haben, um sie am 30.6.24 wieder zu entfernen. Jetzt haben sie keinen Effekt müssen aber auf die Einlagen hohe Zinsen zahlen, die ihnen die Gewinne schmälern! Da das Geld- und Kreditgeschäft wegen der Baukrise zusammenbrutzeln und sie kein Goldgeschäft machen, gucken die Holländer jetzt in die Röhre! Als Konsequenz geben sie jetzt nur noch 3,25% und noch weniger. Man sehe sich mal die lustige Werbung mit dem Basketballer Dirk Nowitzki an: Das Schild das er hochhält, ist ein Dummy , über den der neue Zinssatz drübergeblendet wird! Eine einzige Lachnummer! Die Diba wird sich sowieso bald umgucken, weil sie ein großes Automatennetz betreibt und immer weniger Gewinne macht. Mal schauen, was sie ab 1.4. so anbieten, wenn wieder die EZB die Leitzinsen nicht erhöht ...
Es gibt Neuigkeiten zu "meinem" Scrum-Projekt. Meine Warnungen an die richtige Stelle adressiert, haben nun dazu geführt, dass andere Leute mit dem Projekt betraut werden. Es hört nun hoffentlich auf mit der Sprinterei und Scrummerei. Auch der personelle Zusammensetzung des alten Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war. Vielleicht mag ja das Scrum für irgendwelche Casual Games oder Websites vernünftig sein und wer immer Scrum macht und nicht anderes kennt, der wendet Scrum auf jedwedes Problem an.
Rudi R. schrieb: > Auch der personelle Zusammensetzung des alten > Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der > Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war. aber genau da soll Scrum doch eigentlich Abhilfe schaffen, weil nur so unterschiedlich agierende Menschen zusammenarbeiten sollen. Ein gut geformtes und etabliertes Team mit erfahrenen Personen ist auf einander eingespielt, hat für seine Produkte optimierte Prozesse und Abläufe und braucht kein simplifiertes, leicht erlernbares System wie Scrum. Die heutige Fluktuation in den Firmen untergräbt natürlich die Ausbildung eines solchen stabilen System. Da sind die Firmen mit Schuld, die Mitarbeiter nur noch als austauschbare Resource ansehen.
Wegstaben V. schrieb: > "Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine > gemeinsame Vision für den Super Circle. Er schafft einen offenen und > transparenten Austausch innerhalb des Super Circles und stimmt sich mit > internen und externen Stakeholdern des Super Circles ab." > > klingt für mich teilweise wie Satire. Stimmt irgendwie. Müsste man sich etwas ausdenken, um Scrum zu bashen würde es wohl auf so ein buzzword-Denglish hinauslaufen. > Kann sich da wirklich jemand "vom > Fussvolk" mit so einer Sprache identifizieren? Nicht wirklich, aber rein inhaltlich macht es Sinn, wenn man das Denglish in althergebrachte Industriesprache übersetzt: "Lead" -> der Anführende "Super" -> "übergeordnet" "circle" -> "Lenkkreis" "Vision" -> Vorhaben "Purpose" -> Zweck "stakeholder" -> Interessensvertreter Damit hätten wir: Die den übergeordneten Lenkkreis anführende Person(engruppe) macht klare Vorgaben hinsichtlich der Zweckziele an den übergeordneten Lenkkreis selbst, sorgt für einen durchsichtigen Informationsfluss innerhalb desselben und stimmt sich mit den Interessensvertretern ab. Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum. Handelt es sich bei der Personengruppe nur um einen einzigen und bei den Lenkkreisen jeweils um die Abteilungs- und Teamleiter sowie bei den Interessensvertretern um das Produktmanagement, dann haben wir die typische Hierarchie: Es gibt 2 Kreise = Teams, deren Leiter ihrerseits ein Team bilden und ganz oben ist der "Führer". Würde sogar zu 1933 passen :D Im Prinzip ist es das gleiche wie das hier: A. B. schrieb: > Er soll das ja auch nicht alleine machen sondern zusammen mit den > Leuten erarbeiten die davon Plan haben. Dafür gibt's dann das > Product Backlog Refinement z.B. > Außerdem kann er solche Aufgaben auch delegieren wenn es sinnvoll > erscheint. Ja, das berühmte "Product Backlog Refinement"! Wer kennt es nicht? Hat es ja vorher nie gegeben, dass man über ausstehende Projektkenngrößen und Produktmerkmale gemäß des aktuellen und eventuell zuküftigen Plans gesprochen und seine Vorgehensweisen im Projekt angepasst hat. Wurde erst mit Scrum erfunden. Schön dass wir es nun haben.
:
Bearbeitet durch User
wer sagt das es sowas nicht gab? Niemand! Auch Scrum nicht! Scrum strukturiert dir das halt nur und gibt fixe, sinnvolle Termine vor, mit denen das outcome positiv beeinflusst werden kann. Ob du dich dran hälst oder nicht ist immer noch dein Bier. Scrum ist dafür da, Abläufe zu vereinheitlichen und gewisse Dinge & Zeitaufwände einfach sichtbar zu machen. Und nicht das ich Scrum groß verteidigen würde(obwohl ich es nicht per se scheisse finde. Schlecht wirds nur, wenn irgendwo nix funktioniert und dann nur durch die Einführung von Scrum alles supi werden soll. Aber Läden wo das so läuft haben häufig noch ganz andere Probleme) Man sollte aber auch mal festhalten: viele sogenannte "funktionierende & eingespielte" Teams sind das ja auch nicht wirklich. Man rührt halt seit Urzeiten im gleichen Fahrwasser, bloss nix ändern und wenn mir jemand in die Karten schauen kann, bin ich gleichmal angepisst hoch 10 und echauffier mich bisschen und aus meinen eingetrottenen Abläufen will ich mal gleich gar nicht raus
Bernd G. schrieb: > Ein gut geformtes und etabliertes Team mit erfahrenen Personen ist auf > einander eingespielt, hat für seine Produkte optimierte Prozesse und > Abläufe und braucht kein simplifiertes, leicht erlernbares System wie > Scrum. das ist halt auch schon so ein Käse. Scrum ist nicht dafür da Produkte ohne Unbekannte einfach weiter zu warten. Das ist ja genau dafür da, wo es große Komplexität und viele Unbekannte gibt, die man irgendwie einfangen & handlebar machen will. Deine piefige, seit 30 Jahren zusammengefummelte & gut abgehangene Standardsoftware brauch auch kein Scrum mehr. Die kannste am besten gleich mit der Rostschaufel erschlagen
:
Bearbeitet durch User
J. S. schrieb: > Wegstaben V. schrieb: >> "Der Super Circle Lead (SCL) schafft einen klaren Purpose und eine >> gemeinsame Vision für den Super Circle. Er schafft einen offenen und >> klingt für mich teilweise wie Satire. > Stimmt irgendwie. Müsste man sich etwas ausdenken, um Scrum zu bashen > würde es wohl auf so ein buzzword-Denglish hinauslaufen. >> Kann sich da wirklich jemand "vom >> Fussvolk" mit so einer Sprache identifizieren? Sich selbst als Fußvolk zu bezeichnen ist halt kein guter Ausgangspunkt für eine Zusammenarbeit als Team. > Denglish in althergebrachte Industriesprache übersetzt: > "Lead" -> der Anführende > "Super" -> "übergeordnet" > "circle" -> "Lenkkreis" > "Vision" -> Vorhaben > "Purpose" -> Zweck > "stakeholder" -> Interessensvertreter „Lead“ im Sinne von „Erfahren“ „Circle“ im Sinne von „Arbeitsgruppe (zum gleichen Thema)“ „Vision“ im Sinne von „ambitioniertes Ziel eines Unternehmens in der Zukunft“ „Stakeholder“ im Sinne von „die Betroffenen“ > Damit hätten wir: > Die den übergeordneten Lenkkreis anführende Person(engruppe) macht klare > Vorgaben hinsichtlich der Zweckziele an den übergeordneten Lenkkreis Nö, das was hier so belächelt wird ist eine Möglichkeit, übergeordnet mehrere wichtige Projekte zu steuern. Im klassischen Wasserfallmodell setze ich ein Programmanagement auf. > Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum. Das ist eine unzulässige Verallgemeinerung und gibt nicht wieder, was der Hauptzweck von agilen Methoden ist. > A. B. schrieb: >> Er soll das ja auch nicht alleine machen sondern zusammen mit den >> Leuten erarbeiten die davon Plan haben. Dafür gibt's dann das >> Product Backlog Refinement z.B. > Ja, das berühmte "Product Backlog Refinement"! > Wer kennt es nicht? Hat es ja vorher nie gegeben, dass man über > ausstehende Projektkenngrößen und Produktmerkmale gemäß des aktuellen > und eventuell zuküftigen Plans gesprochen und seine Vorgehensweisen im > Projekt angepasst hat. Wurde erst mit Scrum erfunden. Schön dass wir es > nun haben. Im Refinement wird fachlich klargestellt, dass die Entwickler wissen was sie zu tun haben, das sie per Feedback bestätigen, was sie verstanden haben und in der Lage sind, den Aufwand zu schätzen. Zu dem fliegen alle Issues (Arbeitspakte) für das nächste Planning raus, wenn nicht alle Voraussetzungen zur Umsetzung vorliegen. Der Unterschied: Im Wasserfallmodell ist ja schon festgelegt was gebraucht wird, auch der Aufwand wurde vor dem Start der Entwicklung ermittelt. Change Requests gibt es meist deshalb, weil „Besserwisser“ es nicht vorher eben nicht wussten was der Kunde braucht.
Uwe D. schrieb: > Sich selbst als Fußvolk zu bezeichnen ist halt kein guter Ausgangspunkt > für eine Zusammenarbeit als Team Im Team ist ja jeder Hauptling. Uwe D. schrieb: >> Also nix Neues! Typische Struktur aus 1950, nur mit dem Namen Scrum. > > Das ist eine unzulässige Verallgemeinerung und gibt nicht wieder, was > der Hauptzweck von agilen Methoden ist. Der Hauptzweck ist offenkundig nicht dass ein Produkt zur Zufriedenheit des Kunden fertiggestellt wird, denn DAS war 1950 schon Hauptzweck. Agil gilt eher, wie man dem Kunden möglichst lange hinhalten kann um möglichst wenig zu liefern und dafür möglichst viel aus der Tasche zu ziehen, und damit er am Ball bleibt tut man so als ob er in die Arbeit eingebunden ist. Das war 1950 noch nicht so. A. B. schrieb: > Scrum strukturiert dir das halt nur und gibt fixe, sinnvolle Termine vor Tägliches Gequatsche und 3-wöchentliche Milestones, obwohl die Teilarbeitsschritte 1-40 Tage benötigen und der Kunde den Projektfortschritt monatlich sehen will und Auslieferungen halbjährlich (26 Wochen nicht durch 3 teilbar) ? Scrum ist offenkundig von Idioten für Idioten. Wie viele Mitarbeiter warten zum Sprintende damit sie den aktuellen Stand vorführen können und nicht halb-angefangenes unterbrechen müssen bloss weil das idiotische Zeitraster nicht passt.
Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann dein cvs nicht branchen? Oder kopierst du Source Ordner um? 26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch. Nein! Doch! Ohhh! Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß verteidigen wollen, aber einige der Kritikpunkte sind auch ziemlicher Quatsch
A. B. schrieb: > Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann > dein cvs nicht branchen? Oder kopierst du Source Ordner um? > 26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch. > Nein! Doch! Ohhh! > Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß > verteidigen wollen, aber einige der Kritikpunkte sind einfach ziemlicher > Quatsch
A. B. schrieb: > Du kannst nicht weiterarbeiten weil du was vorführen musst? Kann dein > cvs nicht branchen? Oder kopierst du Source Ordner um? > 26 kannst übrigens durch zwei teilen. 2 wöchige Sprints gibt's auch. > Nein! Doch! Ohhh! > Naja, nicht das hier noch der Eindruck entsteht ich würde scrum groß > verteidigen wollen, aber einige der Kritikpunkte sind auch ziemlicher > Quatsch Wenn man wie du offenkundig nie mit Scrum was zu tun hattest... Scrum ist der Quatsch. Vorführen heisst, ein lauffähiges Umfeld bereit zu halten, darin eine bestimmte Sequenz durchzuführen, an der andere Server und Dienste beteiligt sein können. Die Einrichtung dauert, der Umbau auf die nächste Story dauert auch. Fas bait man nicht hin und wieder her und wieder hin und wieder her. Zumindest nicht, wenn man noch klar im Kopf ist.
Du bist echt der geborene Laberkopp. Ist natürlich bei jeder Aufgabe so, dass man eine gesamte Serverfarm dafür herrichten muss. Ist klar. Du bist halt nur an wichtigen Sachen am fummeln dran
Michael B. schrieb: > Vorführen heisst, ein lauffähiges Umfeld bereit zu halten, darin eine > bestimmte Sequenz durchzuführen, an der andere Server und Dienste > beteiligt sein können. Die Einrichtung dauert, der Umbau auf die nächste > Story dauert auch. Fas bait man nicht hin und wieder her und wieder hin > und wieder her. Zumindest nicht, wenn man noch klar im Kopf ist. Ja, wer klar im Kopf ist (oder Faul wie die meisten die verstanden haben wozu Computer erfunden wurden), automatisiert das ganze. Jeder Entwickler muss ja zu jeder Zeit (mit oder ohne Sprint) seine aktuellen Änderungen testen können. Dazu braucht es immer ein Testsystem. Diese Tests sind gefälligst reproduzierbar (Automatisierung, Snapshots, configuration as code, wie auch immer). Dann purzeln hinten log-files, screenshots oder sonst was raus, das man dann "vorführen" kann. Und für alle anderen: Heute ist Freitag, nicht vergessen vor dem Wochenende noch "Push to production" zu machen...
Uwe D. schrieb: > er Unterschied: Im Wasserfallmodell ist ja schon festgelegt was > gebraucht wird, auch der Aufwand wurde vor dem Start der Entwicklung > ermittelt. Change Requests gibt es meist deshalb, weil „Besserwisser“ es > nicht vorher eben nicht wussten was der Kunde braucht. Da gehe ich bedingt mit, nur ist es eben nötig, vor dem Start der Entwicklung eine Aufwandabschätzung zu machen und zu checken, ob man das Projekt überhaupt machen kann. Da liegt doch der Hase im Pfeffer! Wird das unterlassen, läuft man in die "Scrumhölle" hinein und man stellt mittendrin fest, dass man das besser hätte sein lassen sollen.
Michael B. schrieb: > Agil gilt eher, wie man dem Kunden möglichst lange hinhalten kann um > möglichst wenig zu liefern und dafür möglichst viel aus der Tasche zu > ziehen, und damit er am Ball bleibt tut man so als ob er in die Arbeit > eingebunden ist. Das war 1950 noch nicht so. Aber auch da gehe ich mit. Die Offenheit gegenüber Änderungen wird dazu genutzt, keine Festlegungen gegenüber dem Kunden zu machen und ihn damit in die Pflicht zu nehmen, trotz Scrum sofort und verbindlich Vorgaben zu machen, weil es sonst gegen ihn verschleppend verwendet wird. Sehen wir immer wieder. Das Team kommt mit Rückfragen an den PL, der der schickt uns die Fragenliste. 90% von dem hätten sie selber beantworten können, wenn sie einfach nur das Konzept umsetzen und ihren Job machen würden.
A. F. schrieb: > Da gehe ich bedingt mit, nur ist es eben nötig, vor dem Start der > Entwicklung eine Aufwandabschätzung zu machen und zu checken, ob man das > Projekt überhaupt machen kann. Da liegt doch der Hase im Pfeffer! Wird > das unterlassen, läuft man in die "Scrumhölle" hinein und man stellt > mittendrin fest, dass man das besser hätte sein lassen sollen. Na klar, das wird bei agiler Entwicklung natürlich nie gemacht. A. F. schrieb: > Aber auch da gehe ich mit. Die Offenheit gegenüber Änderungen wird dazu > genutzt, keine Festlegungen gegenüber dem Kunden zu machen und ihn damit > in die Pflicht zu nehmen, trotz Scrum sofort und verbindlich Vorgaben zu > machen, weil es sonst gegen ihn verschleppend verwendet wird. Janeeisklaa... es ist natürlich viel besser, bei jeder Änderung erst einmal auszudiskutieren, ob das jetzt ein kostenpflichtiger Change Request ist und was er kosten wird. Das verzögert Projekte kein bisschen... oder so. > Sehen wir immer wieder. Das Team kommt mit Rückfragen an den PL, der der > schickt uns die Fragenliste. 90% von dem hätten sie selber beantworten > können, wenn sie einfach nur das Konzept umsetzen und ihren Job machen > würden. Hach, Geschichten ausm Paulanergarten...
Ein T. schrieb: > Na klar, das wird bei agiler Entwicklung natürlich nie gemacht. Es wird nicht in dem gleichen Maß gemacht, weil man sich die Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten zu können. Der Fehler den viele machen ist, darin einen Vorteil zu sehen: Nur weil Scrum es ermöglicht, auf sich ändernde Anfragen zu reagieren, heißt das nicht, dass sich ändernde Anfragen eine gute Methode sind! Es ist nach wie vor zu vermeiden, dass sich Dinge mitten im Prozess ändern und Entscheidungen, die fällbar wären, ins Projekt hinzuschleppen. Da liegt das Problem von Scum! Die Vorgehensweise erinnert mich sehr stark an Corona, als alle die Masken haben fallen lassen und die Abstände misachteten, nachdem heraus war, dass es ja im Krankenhaus genug Intensivbetten und ECMO-Geräte gibt! Scrum ist die Notlösung, um einen ungeordneten Haufen dahin zu bringen, ungeordnet eintrudelnde Wünsche zu erfüllen. Es ließe sich auch der Vergleich zu einem Multi-Tasking-System ziehen: Weil ein MTS in der Lage ist, mit ungeordneten Anfragen umzugehen, heißt das nicht, dass man alles so aufbauen muss.
A. F. schrieb: > Ein T. schrieb: >> Na klar, das wird bei agiler Entwicklung natürlich nie gemacht. > > Es wird nicht in dem gleichen Maß gemacht, weil man sich die > Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht > sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip > dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten > zu können. Lauter Prosa, angereichert mit Behauptungen und Dingen, die Dich selbst am meisten treiben. > > Der Fehler den viele machen ist, darin einen Vorteil zu sehen: > > Nur weil Scrum es ermöglicht, auf sich ändernde Anfragen zu reagieren, > heißt das nicht, dass sich ändernde Anfragen eine gute Methode sind! Es > ist nach wie vor zu vermeiden, dass sich Dinge mitten im Prozess ändern > und Entscheidungen, die fällbar wären, ins Projekt hinzuschleppen. Noch so ein Klugscheißer der vorneweg alles weiß. Und wieder nur Behauptungen, als wenn das nicht der Regelfall in allen Projekten wäre. Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen. > Die Vorgehensweise erinnert mich sehr stark an Corona, als alle die > Masken haben fallen lassen und die Abstände misachteten, nachdem heraus > war, dass es ja im Krankenhaus genug Intensivbetten und ECMO-Geräte > gibt! Whataboutism… > Scrum ist die Notlösung, um einen ungeordneten Haufen dahin zu bringen, > ungeordnet eintrudelnde Wünsche zu erfüllen. SCRUM ist der entspanntere Weg, unklare Projekte zum Erfolg zu bringen. Kannst Du eigentlich einen Satz ohne Beleidigungen abfassen? > Es ließe sich auch der Vergleich zu einem Multi-Tasking-System ziehen: > Weil ein MTS in der Lage ist, mit ungeordneten Anfragen umzugehen, heißt > das nicht, dass man alles so aufbauen muss. Hör auf Dinge zu vergleichen, von denen Du offensichtlich keine Erfahrung hast.
Uwe D. schrieb: > Lauter Prosa, angereichert mit Behauptungen und Dingen, die Dich selbst > am meisten treiben. Richtig, ich bin der Einzigste, der Scrum kritisch sieht. Das Seltsame ist, dass ich bei fast allen Kollegen Ähnliches höre - es sei denn sie sitzen gerade im SCRUM-Meeting und erstatten dem Master Rapport, oder jemand von der GL hört mit :-) Da stoßen dann alle in dasselbe Horn :-) Uwe D. schrieb: > SCRUM ist der entspanntere Weg, unklare Projekte zum Erfolg zu bringen. Du hast es nicht verstanden. Das Ziel ist es, erst gar keine großen Unklarheiten aufkommen zu lassen, die eines dafür geeigneten Prozesses bedürfen. Selbverständlich hat man in klar denkenden Firmen immer schon auch Methoden gehabt, auf offene Punkte zu reagieren und diese zu managen. Es tun nur viele plötzlich so, als gäbe es das erst durch SCRUM. > Kannst Du eigentlich einen Satz ohne Beleidigungen abfassen? Du solltest nochmals meinen Text mit deinem Vergleichen und summiere, wer hier mit wievielen Beleidungen um sich wirft persönlich angreift. Solche wie dich wären nach solch einem Getexte direkt aus dem Projekt entfernt!
"erstatten dem Master rapport" Auch schon so eine Formulierung die darauf hindeutet, dass bei euch noch andere Sachen schieflaufen als nur Scrum ;) Der ScrumMaster hat eh nix zu entscheiden. Der soll euch helfen eure Scrumprozesse zu optimieren und Ablaufprobleme aus dem Weg zu räumen. Rapporten müßt ihr da nix. Der kann eh nix entscheiden Und wenn das früher alles so top lief, warum habt ihr dann Scrum eingeführt?
A. F. schrieb: > Ein T. schrieb: >> Na klar, das wird bei agiler Entwicklung natürlich nie gemacht. > > Es wird nicht in dem gleichen Maß gemacht, weil man sich die > Bequemlichkeit belässt, eigentlich wichtige und nötige Dinge nicht > sofort zu entscheiden sondern sie auf später vertragt, weil das Prinzip > dazu einlädt, ja erschaffen ist, spät eintrudelnde Anfragen verarbeiten > zu können. Schau, wir entwickeln und verkaufen eine Realtime Stream Processing Business Rule Engine, die überwiegend zur Betrugserkennung und -Prävention in Echtzeit bei Banken und Versicherungen eingesetzt wird. Das ist ein hochkomplexes und obendrein volatiles Umfeld, bei dem niemand -- und auch kein Team -- jeden Entwicklungsschritt detailliert überblicken und schon gar nicht planen kann. Neben den technischen Herausforderungen mit ihrer inhärenten Komplexität sind es aber auch noch externe Faktoren, die unplanbar sind. Das fängt an mit den ständig neuen Betrugsmustern, die die Fachexperten entdeckt haben und die sich nicht immer mit den vorhandenen Funktionen abbilden lassen und endet noch lange nicht bei den unterschiedlichen gesetzlichen und vertraglichen Vorgaben, von Sarbanes-Oxley über DSGVO und HIPAA bis hin zu PCI-DSS, die sich während der Entwicklungs- und Laufzeit des Projekts ändern und an die die Software und / oder ihre Deployments zwangsläufig angepaßt werden müssen. Erschwerend kommt hinzu, daß diese Änderungen meistens interdisziplinär erarbeitet und umgesetzt werden müssen. Sowas kannst Du schon wegen seiner technischen Komplexität nicht planen, auch dann nicht, wenn Du fünfmal so gut bist wie alle Scrumhasser in diesem Thread zusammengenommen. > Der Fehler den viele machen ist, darin einen Vorteil zu sehen: Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit", "Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen. Das ist aber so falsch, daß nicht einmal das Gegenteil richtig ist. Und, ach, weißt Du, woran sich Dein Mangel an Erfahrung und Kenntnis von agilen Methoden mehr als deutlich zeigt? An so blöden Sprüchen wie "sie sitzen gerade im SCRUM-Meeting und erstatten dem Master Rapport", die mit Scrum und anderen agilen Methoden nun wirklich so ganz und gar nichts zu tun haben. Langsam gewinne ich in dieser Diskussion das Gefühl, daß es sich ein wenig wie mit der Whitespace-Sache in Python verhält: wer noch nie mit Python gearbeitet hat (und womöglich sogar noch frühe Versionen von Fortran kennt), für den ist es der schiere Horror -- während andererseits Leute, die ihre Erfahrungen mit Python gesammelt haben, das meistens (wie ich) sogar ziemlich gut und elegant finden, während eine Minderheit (wie einer unserer hiesigen Moderatoren) sagt, daß sie zwar nicht begeistert sind, sich aber daran gewöhnen konnten. Übrigens, nur so ein Hinweis: Deine, sagen wir mal, "robuste" Wortwahl, Dein mangelnder Respekt gegenüber anderen und ihren Meinungen und Deine Rückgriffe auf hinkende Vergleiche und ein Argumentum ad populum beeindrucken mich nicht und sind für mich nur ein Indiz für fehlende Sachargumente. Vielleicht magst Du einmal darüber nachdenken, wie es wohl auf Dich wirken würde, wenn ich es nötig hätte, Dir gegenüber so zu poltern.
Ein T. schrieb: > Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und > Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit", > "Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen. Man munkelt, es gibt solche Projekte in nennenswerter Menge. Nicht nur im Softwarebereich.
Reinhard S. schrieb: > Ein T. schrieb: >> Der Fehler, den Du offensichtlich aus Mangel an Erfahrung mit und >> Kenntnis von agilen Methoden machst, ist, sie mit "Planlosigkeit", >> "Nachlässigkeit" und dem Vermeiden von Verantwortung gleichzusetzen. > > Man munkelt, es gibt solche Projekte in nennenswerter Menge. Nicht nur > im Softwarebereich. Und nicht nur in agilen Projekten.
Ein T. schrieb: > Das fängt an mit den ständig neuen Betrugsmustern ... > unterschiedlichen gesetzlichen und vertraglichen Vorgaben ... Das wären von außen kommende und vor allem neue Anforderungen, die nicht die Vorgaben des aktuell laufenden Produktentwicklung tangieren, sondern eine Fortentwicklung induzieren. Solange eine solche neue Änderung nicht kommt, bleibt es ja bei den zuvor getroffenen Vorgaben, die irgendwo niedergelegt sind und damit geradlinig umgesetzt werden können. Da sehe ich keinen Bedarf für SCRUM, abgesehen davon dass man die technischen Änderungen diskutieren und formulieren muss. Das passiert(e) überall und immer - ganz ohne Spezialvorgehen nach Scrum, oder dass man es so nennt oder noch einen Master braucht, der die Teams moderiert. Sollten solche Änderungen in so großer Dichte kommen, dass sie in die laufende Entwicklung einfließen müssen, dann würde das Produkt ja niemals fertig. Irgendwie muss ja mal ein Strich gezogen werden, was in eine neue SW hinein muss und was erst in die nächste kommt. Also muss man sammeln und die Software-Maturität stufenweise steigern. Eine solche Änderung vom Kunden oder per Gesetz wäre für mich einfach ein REQ-change, der eine neue Produktversion nach sich zieht und ganz konventionell gehandhabt wird. Abgesehen davon, sind von solchen Effekten so ziemlich alle Produkte betroffen, die einen ausreichend langen product life cycle haben und keineswegs etwas Neues oder Ungewöhnliches. In der Medizintechnik kenne ich es gar nicht anders. Da gibt es allenthalben ein neues Gesetz oder eine Zulassungsanforderung, z.B. auch in der Dokumentation. Die wird einfach im Konzept erfasst, aufgeplant, kostengeschätzt und in die SW- bzw HW-Pläne übernommen. Das sind für mich 10-15 Sätze = 1-2h im Doors und weitere 3-4h an den Dokumenten, pro Punkt! Geht relativ stringent durch. Am Ende gibt es ein paar geänderte Dokumente und einige Absätze. Da braucht es auch keine großen Runden, wenn die PL, die das erfassen und umsetzen, die wissen, was sie tun und ihren Job können. Danach wird es in die Teams reingeworfen und die z.B. Softwareentwickler können sich drum kümmern. Da gibt es aber meistens einen einzigen, der das linear und effektiv macht. Auch da braucht es keine Gruppe. Es braucht vor allem keine Orga drum herum und viel Gerede, weil sich innerhalb dieser defiierten Spanne, nichts mehr ändert. Es muss auch kein Sprint definiert werden oder es in den nächsten reingeplant werden, sondern es gibt einen Task, der die Änderung definiert und einen Teamleiter, der anhand von Dringlichkeiten, die Erledigung committed. Bevor die Scrumteams ihre Sprintplanungen gemacht die Scrummaster warmgelaufen sind, hat es einer unserer kompetenten Entwickler schon gemacht, in allen Codes durchgezogen und so sauber und durchsichtig dokumentiert, dass es auch von einem anderen weiter ausgebaut werden kann, falss nochmal etwas kommt, was diese Baustellen betrifft. Das geht, weil wir auf gute Doku achten. Da kann schon der PL sehen, wo überall angepackt werden muss.
A. B. schrieb: > uch schon so eine Formulierung die darauf hindeutet, dass bei euch noch > andere Sachen schieflaufen als nur Scrum ;) Nicht in meinem Geschäftsbereich. Das Scrum läuft im Konzern aber eben nicht überall. A. B. schrieb: > Und wenn das früher alles so top lief, warum habt ihr dann Scrum > eingeführt? Weil da Leute reingekommen sind, die irgendeine Berechtigung für ihr Dasein liefern müssen und deren Hauptqualität eben der Scrum Master Schein und ihre Erfahrung in solchen Teams war.
Ein T. schrieb: > Mangel an Erfahrung mit und > Kenntnis von agilen Methoden machst, Ich beziehe mich definitiv auf die realen Erfahrungen, die ich mit Scrum seit fast 20 Jahren mache. Es bietet in funktionierenden Firmen nichts neues und bewirkt dort, wo keine Inhalte abgestimmt werden, nicht Positives. Dazu kommt die mangelnde Umsetzung, das ist richtig. Es ist aber nun einmal eine Tatsache dass es nirgendwo richtig funktioniert. Ich kann dir jetzt Audi, IAV, MB-Tech und auch die Porsche-Engineering nennen -überall steigen die Kosten und die Softwarequaltiät sinkt. Bei Volksagen und auch der IAV machen inzwischen fast alle Abteilungen Scrum, einige davon schon seit über 10 Jahren. Die Ingenieure dort kennen nichts mehr anderes. Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen - nicht zu letzt aus Altersgründen. Bei einer IAV laufen daher ausschließlich Team- und Projektleiter herum, die Hauptsächlich in meetings sitzen und selber keine technischen Entscheidungen mehr fällen können - weil ihr Haupteinstellungskriterium die "Teamleitererfahrung" und die "PL-Erfahrung" waren, die schon in der Firma aus der sie kamen, nicht funktioniert hat, sonst hätten sie kaum den Job gewechselt. Das Kriterum Nummer 1 ist immer "Scrum" - das Allheilmittel. Auf Inhalte und Erfahrung schauen sie immer weniger. Wie man hört ziehen jetzt einige die Notbremse und lagern SW-Entwicklung ins Ausland aus. Vornehmlich da hin, wo effizient und stabil gearbeitet wird. Konsequenz: Man stellt sich alte und erfahrene Selbständige sowie temporäre Projektleiter ein, die noch in der Lage sind, ein richtiges Pflichtenheft zu schreiben, um dann die Arbeitspakete für dies externen Firmen zu definieren, weil es von den Internen, die nur das große "Gedrängel" können, keiner mehr kann. Scrum mag für solche Softwareabteilungen wie euch einen Vorteil haben, aber in vielen Fällen schafft es mehr Probleme, als es löst.
Uwe D. schrieb: > Noch so ein Klugscheißer der vorneweg alles weiß. Und wieder nur > Behauptungen, als wenn das nicht *der Regelfall in allen Projekten* > wäre. > > Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen. Ja, viele Projekte in vielen Firmen laufen chaotisch und mit großen Verzögerungen. Aber warum ist das so? -Weil der Vetrieb den Kunden das Blaue vom Himmel verspricht, ohne Rücksicht darauf ob/wann dies tatsächlich geliefert werden kann. -Weil manche Angebote so erstellt werden, dass man von vornherein weiß: Die Termine kann man eh nicht halten. Man wird eine Pönale zahlen müssen. Aber wenn man selbst mit dieser Pönale unterm Strich voraussichtklich noch einen Gewinn macht, dann pfeift manch ein Management darauf und unterzeichnet den Vertrag trotzdem. Dumm nur wenn die Verspätung dann noch größer wird. -Weil man im Management glaubt, "Programmieren können die Inder auch, das kaufen wir billig als Dienstleistung ein", bis sich dann herausstellt dass ohne massive Nacharbeit in den teureren Ländern (EU, USA) überhaupt nichts funktioniert. -Weil die Projektmanager keine Ahnung von der Hardware und Software haben, aber meinen sie müssten trotzdem ständig Entscheidungen über HW und SW treffen, ohne die Experten zu fragen worauf man achten muss. -Weil niemand mehr vernünftig eingearbeitet wird. Die Leute sollen gleich bei der Einstellung sofort schon alles können. -Weil es zu viele Hierarchieebenen gibt und ein beträchtlicher Teil an Manpower und somit Geld für sinnloses Reporting verbraten wird, ohne dass dadurch irgendein Mehrwert geschaffen wird.
Franko S. schrieb: > Lest euch das mal durch ohne dass ihr Schreikrämpfe bekommt. Hat ned funktioniert .... war aber absehbar :-D
Mark B. schrieb: > Uwe D. schrieb: >> Schreibe lieber, wie Du das vermeidest, anstatt SCRUM anzuscheißen. > > Ja, viele Projekte in vielen Firmen laufen chaotisch und mit großen > Verzögerungen. Aber warum ist das so? > > -Weil der Vetrieb den Kunden das Blaue vom Himmel verspricht, ohne > Rücksicht darauf ob/wann dies tatsächlich geliefert werden kann. > > -Weil manche Angebote so erstellt werden, dass man von vornherein weiß: > … > … schnipp… Alles super Beispiele, ohne das es an einer Projektmethode oder Framework festgemacht wäre. Tja, es macht mehr Sinn seine Zeit mit Verbesserungen zu verbringen anstatt mit der Suche nach Schuldigen.
:
Bearbeitet durch User
Wenn man so im Internet auf Suche geht, sind anscheinend die Markenzeichen von Management nach Scrum herunterfallende Türbolzen, Räder und was sonst noch so alles verloren werden kann. Es gibt einige Quellen, die besagen, dass man ohne Scrum-Kenntnisse sich gar nicht zu bewerben brauche.
Rudi R. schrieb: > t > was architektonisches, aber ich kann nicht mal locker aus der Hüfte das > große Fass der Graphentheorie aufmachen, Kruskal erklären und erläutern, > warum unser konkretes Problem zum Problem mit den minimalen Spannbäumen > passt. Das muss man auch nicht, wenn man nicht einen ehemaligen Supermarktkassierer danebensitzen hat oder stellt ihr fachfremde Volldeppen ein?
:
Bearbeitet durch User
Uwe D. schrieb: > Alles super Beispiele, ohne das es an einer Projektmethode oder > Framework festgemacht wäre. Tja, es macht mehr Sinn seine Zeit mit > Verbesserungen zu verbringen anstatt mit der Suche nach Schuldigen. Ich habe noch vergessen hinzuzufügen: -Weil man im Management glaubt, dass durch das Hinzufügen einer bestimmten Projektmethode (z.B. Scrum) dann einfach alles glatt laufen würde.
A. F. schrieb: > Das wären von außen kommende und vor allem neue Anforderungen, die > nicht die Vorgaben des aktuell laufenden Produktentwicklung tangieren, > sondern eine Fortentwicklung induzieren. Leider nehmen Gesetzgeber und Vertragspartner selten Rücksicht auf die Planungen von Unternehmen, die ihre Vorgaben umsetzen müssen. > Sollten solche Änderungen in so großer Dichte kommen, dass sie in die > laufende Entwicklung einfließen müssen, dann würde das Produkt ja > niemals fertig. Genau so ist das, das Produkt ist niemals "fertig" (für jede sinnvolle oder wie auch immer geartete Definition von "fertig"). > Eine solche Änderung vom Kunden oder per Gesetz wäre für mich einfach > ein REQ-change, der eine neue Produktversion nach sich zieht und ganz > konventionell gehandhabt wird. Been there, done that, got the t-shirt. Wenn das ein Change Request ist, diskutieren Kunde und Management erst einmal aus, wer dafür bezahlen muß. Dadurch wird die Weiterentwicklung mitunter deutlich ausgebremst, und wenn schließlich eine Entscheidung getroffen wurde, bleibt regelmäßig wenig Zeit für eine sorgfältige, langfristig orientierte Planung und Implementierung. A. F. schrieb: > Ich kann dir jetzt Audi, IAV, MB-Tech und auch die Porsche-Engineering > nennen -überall steigen die Kosten und die Softwarequaltiät sinkt. Und Du denkst, das läge am agilen Projektmanagement? Das halte ich für ein Gerücht. Der Grund ist ein ganz anderer, nämlich, daß an Software zunehmend höhere Anforderungen gestellt werden und sie deswegen immer komplexer wird. KFZ-Elektronik ist heute nicht mehr primär die Motorsteuerung und eventuell noch das ABS, sondern heutige Fahrzeuge sind fahrende Computer, die viele unterschiedliche Sensoren auswerten und mit den so gewonnen Informationen verschiedenste Aktoren ansteuern müssen. Und im selben Maße, wie sich Hard- und Software weiterentwickelt haben, werden sie auch ausgenutzt. Denn eines ist Softwareentwicklung immer, nämlich ein Rattenrennen. In dem Moment, indem jemand eine neue kluge Methode zu ihrer Vereinfachung findet, entwickelt ein anderer auf dieser Basis neue Komplexität, die die vorherige Vereinfachung dann sofort wieder auffrißt. Das hat zunächst einmal überhaupt gar nichts mit irgendeiner Art des Projektmanagement zu tun. Aber sekundär hat das dann doch wieder mit Projektmanagement zu tun, nämlich mit der Frage, wie sich die steigende Komplexität beherrschen läßt. Agile Vorgehensweisen wurden nämlich entwickelt, weil je nach Untersuchung sechzig bis achtzig Prozent aller Softwareprojekte ihre Planungen in Bezug auf Zeit, Budget und / oder Funktionalität gesprengt hatten. Soviel dann übrigens auch zum angeblich überlegenen klassischen Projetmanagement, das ja offensichtlich auch schon oft genug versagt hat. Insofern scheint es mir ein logischer Fehlschluß (post hoc ergo propter hoc) zu sein, alle Probleme in der Softwareentwicklung der zunehmenden Verbreitung agiler Methoden anzulasten. Ockhams Rasiermesser legt nahe, daß die zunehmend komplexen Anforderungen dabei die mit Abstand größte Rolle spielen. > Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit > ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen - > nicht zu letzt aus Altersgründen. Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk und aus etlichen anderen Bereichen.
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.
> Projektmanagement Ich habe vorhin etwas gelesen, was zu diesem Thema passen könnte: https://www.initiative-zukunftsfaehigkeit.de/das-paul-carla-dilemma/
Ein T. schrieb: >> Das Chaos vergrößert sich aber immer mehr, weil diejenigen, die es mit >> ihrem Knowhow zusammengehalten haben, langsam die Firma verlassen - >> nicht zu letzt aus Altersgründen. > > Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal > mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk > und aus etlichen anderen Bereichen. Es hat aber sehr viel mit Management an sich zu tun. Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%. Man weiß sehr wohl, wer wann in Rente gehen wird. Wenn man es dann nicht schafft, eine Weitergabe des Wissens und der Erfahrung von den älteren auf die jüngeren Mitarbeiter zu organisieren, dann hat das Management schlicht und ergreifend versagt.
Mark B. schrieb: > Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%. Das sollte man denken. Ich kann dir aber sagen, daß das bei den meisten Firmen ein echtes Problem ist. Auch unsere Politiker schaffen es ja nicht, zu zählen und ausreichend Lehrer einzuplanen. Die Planstellen wurden erst geschaffen, nachdem der Mangel offenbar wurde. Die Sache ist auch die, dass manche Manager gezielt Fachwissen aus der Firma drängen indem sie alte Erfahrene nicht mehr ersetzen und dann als Alleinentscheider die Aufträge an den Billigsten vergeben zu können, ohne dass ihnen einer reinreden kann. Da kann ich dir eine Firma hier aus Heidelberg nennen, die das so macht. Die Entwicklungsabteilungen werden immer mehr ausgedünnt und wenn überhaupt mit billigen aus dem Ausland bestückt, die über Zeitarbeit beschäftigt werden und indirekt dazu beitragen, das KnowHow in andere Firmen zu übertragen.
Mark B. schrieb: > Ein T. schrieb: >> Auch das hat nichts mit dem Projektmanagement zu tun und nicht einmal >> mit Softwareentwicklung, das kenne ich genau so auch aus dem Handwerk >> und aus etlichen anderen Bereichen. > > Es hat aber sehr viel mit Management an sich zu tun. Darum geht es in diesem Thread aber nicht. > Eine Firma kennt die Altersstruktur ihrer Belegschaft zu 100%. Man weiß > sehr wohl, wer wann in Rente gehen wird. Wenn man es dann nicht schafft, > eine Weitergabe des Wissens und der Erfahrung von den älteren auf die > jüngeren Mitarbeiter zu organisieren, dann hat das Management schlicht > und ergreifend versagt. Hach ja, wenn das nur so einfach wäre... ist es aber nicht. Denn auch das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen, kündigen oder krankheitsbedingt ausfallen. Außerdem hat auch das beste Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich ein adäquater Ersatz für ausscheidende Mitarbeiter findet -- beim heutigen Fachkräftemangel ist das nämlich nicht so einfach, wie Otto Normalelektroniker sich das vorstellt. Aber klar, es ist natürlich immer ganz einfach, wenn immer nur die anderen doof und natürlich immer an allem schuld sind, vor allem natürlich besonders gerne "das Management". Meine persönliche Erfahrung ist, daß es dort genauso viele Nieten, gleichzeitig aber auch genauso viele richtig Leute gibt wie in allen anderen Bereichen auch. Schade, daß Du es Dir dabei so einfach machst, eigentlich würde ich Klügeres und Differenzierteres von Dir erwarten...
Ein T. schrieb: > das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob > ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen, > kündigen oder krankheitsbedingt ausfallen. Es ist bekannt wieviele junge und kinderlose man hat, die in Elternzeit gehen. Das kann man auch statistisch bewerten. Auch Krankheiten lassen sich statistisch einstufen. Das wird auch gemacht. > Außerdem hat auch das beste > Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich > ein adäquater Ersatz für ausscheidende Mitarbeiter findet doch, indem es Marktpreise bezahlt. Firmen möchten nicht ausbilden, sondern sich einfach bedienen und wundern sich, dass andere ihre Mitarbeiter nicht kostenlos hergeben, sondern nur die faulen Eier! Wichtige Mitarbeiter werden nämlich per ehalten und zwar mit dem -> "Gehalt"!!!! > heutigen Fachkräftemangel Die Industrie lamentiert doch permanent wegen dem Mangel sorgt aber durch die Gehaltspoliktik dafür, dass sich fähige Leute etwas anderes suchen. Selbst in der Krise und während der Insolvenzen durch Covid waren sie nicht in der Lage, ihr angebliches Personaldefifiz aufzufüllen! Es sollte niemand eingestellt werden. Es gab allerdings die eine oder andere Firma, die das genutzt hat und investierte! Die haben jetzt einen Vorsprung u.a in KI. Nur eben nicht in Deutschland-Jammerland!
Martin K. schrieb: > Es ist bekannt wieviele junge und kinderlose man hat, die in Elternzeit > gehen. Das kann man auch statistisch bewerten. > > Auch Krankheiten lassen sich statistisch einstufen. Das wird auch > gemacht. > > doch, indem es Marktpreise bezahlt. Firmen möchten nicht ausbilden, > sondern sich einfach bedienen und wundern sich, dass andere ihre > Mitarbeiter nicht kostenlos hergeben, sondern nur die faulen Eier! Jaja, immer sind die anderen schuld. Meine Güte, Diskussionen auf diesem "Niveau" sind so enervierend und ermüdend... und ignorieren vollkommen, daß auch andere Menschen jeweils ihren ganz eigenen Sachzwängen unterliegen, mit denen sie dann irgendwie umgehen müssen. > Wichtige Mitarbeiter werden nämlich per ehalten und zwar mit dem -> > "Gehalt"!!!! Es ist immer sehr angenehm, wenn man sich die Welt so einfach machen kann. Leider hat das wenig mit der Realität zu tun. Für die meisten Menschen, die ich kenne, spielt das Gehalt nur eine vergleichsweise kleine Rolle in einer wesentlich umfangreicheren Gesamtbetrachtung. Die ausufernde Verwendung von Ausrufezeichen ändert daran auch nichts. > Die Industrie lamentiert doch permanent wegen dem Mangel sorgt aber > durch die Gehaltspoliktik dafür, dass sich fähige Leute etwas anderes > suchen. > Selbst in der Krise und während der Insolvenzen durch Covid waren sie > nicht in der Lage, ihr angebliches Personaldefifiz aufzufüllen! Genau, alle doof außer Dir. Hätten wir bloß mal Dich gefragt, das große, allwissende Orakel mit dem totalen Durchblick! Dann würden Milch und Honig fließen und uns allen gebratene Tauben in den Mund fliegen! > Nur eben nicht in Deutschland-Jammerland! rolleyes Wie viel Erfahrung hast Du denn schon im Ausland gesammelt?
Ein T. schrieb: > Darum geht es in diesem Thread aber nicht. Selbstverständlich geht es in diesem Thread unter anderem auch darum, wie man Firmen, Abteilungen, Projekte, Teams managt. > Hach ja, wenn das nur so einfach wäre... ist es aber nicht. Denn auch > das beste Management der Welt hat nur sehr begrenzten Einfluß darauf, ob > ihre Mitarbeitenden in Frührente oder in den Elternschutz gehen, > kündigen oder krankheitsbedingt ausfallen. Außerdem hat auch das beste > Management der Welt nur einen sehr begrenzten Einfluß darauf, wann sich > ein adäquater Ersatz für ausscheidende Mitarbeiter findet -- beim > heutigen Fachkräftemangel ist das nämlich nicht so einfach, wie Otto > Normalelektroniker sich das vorstellt. Man kennt aber die durchschnittlichen Fluktuationsraten. Das ist schon mal ein Anhaltspunkt. Nebenbei bemerkt: Wenn eine Firma eine überdurchschnittliche hohe Fluktuationsrate hat, dann sollte sie sich vielleicht einmal überlegen, wie sie zu einem besseren und attraktiveren Arbeitgeber werden kann. Es ist der Firmenleitung nicht verboten, in diese Richtung zu denken und auch zu handeln. > Aber klar, es ist natürlich immer ganz einfach, wenn immer nur die > anderen doof und natürlich immer an allem schuld sind, vor allem > natürlich besonders gerne "das Management". Niemand wird dazu gezwungen ins Management gehen. Wer diese Verantwortung nicht übernehmen will, der soll es eben sein lassen. Man bekommt in einer Führungslaufbahn mehr Geld als in einer Fachlaufbahn. Dafür kann man auch mit Fug und Recht einen entsprechenden Gegenwert erwarten. Wenn dieser ausbleibt, dann war die Leistung des Managements eben nicht gut. Da gibt es nichts schön zu reden.
Mark B. schrieb: > Wenn dieser ausbleibt, dann war die Leistung des > Managements eben nicht gut. Da gibt es nichts schön zu reden. Leider entlässt dann das Management aber nicht etwa sich selbst, um die firma zu entlasten und zu retten, sondern macht weiter und spart Fachleute ein. Das tut sie so lange, bis gar nichts mehr läuft und der Laden stirbt. Solange haben sie noch gute Zahlen, weil sie Entwicklungsinvestitionen an die Gewinne gekoppelt sind. Und mit diesen Zahlen gehen sie in die nächste Firma.
Ein T. schrieb: > Für die meisten > Menschen, die ich kenne, spielt das Gehalt nur eine vergleichsweise > kleine Rolle in einer wesentlich umfangreicheren Gesamtbetrachtung Das ist interessant! Das erklärt solche Gehälter, wie sie derzeit angeboten werden. Beispiel: ------------------------------------ Machine Learning Engineer Trilogy (Remote) - $60,000/year USD Crossover · München (Remote) Bewerben Sie sich als Erster von 15 3-5 years experiences in machine learning algorithm design MATLAB, Simulink, C++, C# ------------------------------------ So werden momentan Stellen verhökert. Meistens werden damit Leute aus aller Wert angelockt, sich hier niederzulassen. Dass bei den steigenden Kosten irgendwann niemand mehr da ist, der die Steuern aufbringen kann und die Rente bezahlen kann, scheint niemanden zu interessieren. Offenbar ist die Strategie, möglichst große billige Horden anzulernen, die dann mit u.a. Scrum gemanaged werden sollen.
Martin K. schrieb: > - > Machine Learning Engineer > Trilogy (Remote) - $60,000/year USD > Crossover · München (Remote) > Bewerben Sie sich als Erster von 15 > 3-5 years experiences in machine > learning algorithm design > MATLAB, Simulink, C++, C# > ------------------------------------ ML Experte ist der neue HTML-Programmierer.
Mark B. schrieb: > Selbstverständlich geht es in diesem Thread unter anderem auch darum, "unter anderem" ist treffend formuliert :-) Die Diskussion gleitet ab. Eigentlich geht es nur um Scrum ... und dessen Nutzung ist Teil der Betriebsführung, also zweifellos eine Managementfrage. Im speziellen natürlich eine Frage des "Managements" der Abteilung und der fließenden Informationen. Mark B. schrieb: > Nebenbei bemerkt: > Wenn eine Firma eine überdurchschnittliche hohe Fluktuationsrate hat, ... dann hat sich schon einmal grundsätzlich ein Problem, weil sich nirgendwo ein stabiles Team einstellen kann, dass einen funktionierenden Scrum-Prozess formen kann. Rudi R. schrieb: > dass Menschen wie > ich, die einfach nur einer Sache aufgehen wollen, daran durch > Besprechungen und Sozialtänze abgehalten werden. Ich habe gerade mit einem solchen Hansi zu tun, der in seiner Sache voll aufgeht und der ist extrem schwer mit Informationen zu versorgen. Da hilft auch kein Scrum und kein Garnichts. Die Frage ist bei Allem immer, wieviel Besprechungen hat man und wie führt man sie durch. Wenn das Gesagte nur an den Leuten vorbeirauscht, alles ohne Vorbereitung aus der Hüfte gemacht wird, im nichts Wirksames entschieden sondern viel verschoben wird und im Nachhinein keine Zeit ist, das Besprochene aufzuarbeiten -> in Dokumente fließen zu lassen oder sofort umzusetzen, weil man von einer B in die nächste hüpft, dann wird das in der Tat sehr schnell sehr inffektiv. Es kommt daher darauf an, Besprechungen zu planen, nur die zu beteiligen, die auch benötigt werden und die Menge des zu bearbeitenden anzupassen, zu skalieren und zu sequenzialisieren. Das erfordert es z.B. Aufgaben zu aufzuteilen, dass gar nicht erst der Bedarf für so viel Kommunikation entsteht. Wenn die Projektleitung aber nicht stimmt, der Informationsfluss nicht passt, oder manche Leute einfach nicht fähig sind, ordentlich zu arbeiten und voraus zu dokumentieren, muss wegen jedem Krümel ein Meeting her und je mehr da dann wieder mitmachen, desto konfuser wird es meistens. In solche Meetings müssen nur die wenigen hinein, die wirklich entscheiden können, weil sie das relevante Thema selber planen oder bearbeiten und die Entscheidungen anderer brauchen. Daher muss das auch in Scrum-Gruppen so sein und sieht man sich die Strategien dahinter an, dann ist das auch so gedacht! Was ich diesbezüglich eben nur immer sehe, sind riesige Gruppen, wo allemmöglichen Teilthemen besprochen werden, zu deren Verlauf und Stand 3/4 der Anwesenden nichts beitragen können und denen die Besprechung auch keine Information bringt, die sie verwerten könnten. Da gehen dann 20min Diskussion weitgehend nutzlos durch. Diese 20min sind es aber dann, die angeblich fehlen, um einfach mal selber proaktiv den Ablauf einer Software hinzuschreiben, eine Seite zu machen, die andere in 5min durchlesen und in weiteren 10min sukkzessive zu einem fähigen Konstrukt ergänzen könnten, damit dann jeder sein Modul anpassen und die Interaktionen zum Laufen bekommen kann. Stattdessen werden 5 Meetings gemacht werden, mit jeweils 4 Leuten, die eine volle Stunde über die SW-Struktur diskutieren, was sich über 2 Wochen zieht und ein eher schlechteres Ergebnis hat, bei dem Dreifachen der Nettozeit.
J. S. schrieb: > Mark B. schrieb: >> Selbstverständlich geht es in diesem Thread unter anderem auch darum, > … > Die Frage ist bei Allem immer, wieviel Besprechungen hat man und wie > … > Es kommt daher darauf an, Besprechungen zu planen, nur die zu > beteiligen, die auch benötigt werden und die Menge des zu bearbeitenden > anzupassen, zu skalieren und zu sequenzialisieren. Das erfordert es z.B. > Aufgaben zu aufzuteilen, dass gar nicht erst der Bedarf für so viel Ja, wenn die Beteiligten das notwendige Handwerk nicht beherrschen ist es halt Brühe… Egal wie das Framework/Methodik heißt. > In solche Meetings müssen nur die wenigen hinein, die wirklich > entscheiden können, weil sie das relevante Thema selber planen oder > bearbeiten und die Entscheidungen anderer brauchen. > > Daher muss das auch in Scrum-Gruppen so sein und sieht man sich die > Strategien dahinter an, dann ist das auch so gedacht! Nee, ist es nicht und war es nicht. Du machst genau, das was viele an SCRUM nicht verstehen: Es gibt kein „Ober sticht Unter“ und vor allem keinen „großen Plan“. Iterativ arbeiten heißt nicht, große Aufgaben in Pakete zu zerstückeln und wie gehabt auf Personen vom Scrum master verteilen zu lassen. > … > diesbezüglich eben nur immer sehe, sind riesige Gruppen, wo > allemmöglichen Teilthemen besprochen werden, zu deren Verlauf und Stand > 3/4 der Anwesenden nichts beitragen können und denen die Besprechung > auch keine Information bringt, die sie verwerten könnten. Da gehen dann > 20min Diskussion weitgehend nutzlos durch. Nun, der Scrum master ist genau dafür da, das Framework mit Leben zu erfüllen und „planenden Besserwissern“ - insbesondere den Managern - diese Art der Kommunikation abzugewöhnen. Deine Worte wie „..wer etwas beizutragen hat..“ zeigen, dass Du die Chance bzw. Notwendigkeit, nämlich weitere Beteiligte des Teams weiterzuentwickeln (damit sie sich später vertreten können oder dem Team mehr Fähigkeiten geben) nicht siehst. Suche besser nach Lösungen als Schuldige - das macht auch viel mehr Spaß…
Uwe D. schrieb: > Es gibt kein „Ober sticht Unter“ und vor allem > keinen „großen Plan“. Das Fehlen des Plans ist aber letztlich das, was die Ineffizienz ins Spiel bringt. Ein Großteil der Dinge, die es in einem Projekt zu entscheiden gibt, sind nun einmal weitgehend trivial und durchsichtig genug, dass es dazu keine Gruppenentscheidung oder Gruppenkompetenz braucht. Unnötig viele zu involvieren ist damit einfach langwierig und ineffizient. Es macht daher einfach keinen Sinn, alles in Gruppenentscheidungen zu drängen. Uwe D. schrieb: > Nun, der Scrum master ist genau dafür da, das Framework mit Leben zu > erfüllen Das ist wieder so ein typischer nichtssagender Satz. Wie soll er dies denn deiner Meinung nach real tun? Der SM hat nur die Methodenkompetenz in Sachen Scrum, ist aber nur in Ausnahmefällen der Fachmann für die Inhalte. Er kann so die Mitwirkende nur anleiten, wie sie arbeiten und kommunizieren sollen, aber das was müssen sie selber entscheiden. Das was ist sind aber die 90% des Handelns. Wenn dort unnötig Innefizienz hinkommt, ist die durch nichts wieder auszugleichen. Uwe D. schrieb: > Iterativ arbeiten heißt nicht, große Aufgaben in > Pakete zu zerstückeln und wie gehabt auf Personen vom Scrum master > verteilen zu lassen. Dass der Scrummaster die Pakete verteilen soll hat niemand behauptet und würde auch wenig Sinn machen, da er dazu oft nicht in der Lage ist, wenngleich ich genau das auch schon erlebt habe. Der Theorie nach verteilen sich die Mitwirkenden die Aufgaben bekanntlich selber. Da muss man aber jetzt mal genau hinschauen, wie das im Einzelnen passiert und wie das abläuft, wenn es bezüglich der Umsetzung gegenteilige Auffassungen gibt, weil unterschiedliche Wissenstände kollidieren oder gar Interessen aufeinanderprallen, weil jeder gerne die Rosinen picken möchte. Erfahrungsmäß neigen manche sehr wohl dazu, sich die Arbeit leicht zu machen und Unangenehmes anderen zuzuschieben. Ich konnte aus nächster Nähe gerade vor Kurzem sehen, dass jemand deswegen nicht nur das Scrum, sondern die Firma verlassen hat. Es muss auch nicht einmal eine böswillige Strategie dahinter stehen, sondern es reicht, wenn manche in ihrem flow arbeiten, sich Infos ad hoc holen wollen und selber Dinge nur auf Anfrage herausgeben, damit Dinge die synchronisiert laufen müssten, auseinander gehen. Ohne eine Instanz, die das zusammenhält und auch Entscheidungen fällen kann, geht es dann nicht. Das ist allein schon deshalb nötig, weil vielen "unten", wie du es formulierst, der Überblick im Projekt fehlt.
Mir kam es aber mit meiner Aussage eigentlich auf einen anderen Punkt an: Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind, sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende Minute ist, die an anderer Stelle als Problem doppelt und dreifach aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren und ein Konzept zu schreiben, das überhaupt erst einmal als Diskussionsgrundlage fungieren könnte und andere haben keine Zeit, Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand in den Mund" wie es mal jemand formuliert hat. Und ich sehe nicht, wie die Nutzung von Scrum das irgendwie irgendwo geändert hätte. Scrum verbraucht sehr viel Zeit, die es oft nicht einspielt, die aber an anderer Stelle wieder sehr weh tut. Ich sehe mir das nun seit fast 20 Jahren an und meine eigentlich, dass praktisch jeder Entwickler einmal in einer Firma war mehrfach mit Scrum zu tun hatte. Die meisten sollten also damit vertraut sein. Fakt ist aber: Scrum läuft in jeder Firma anders und in vielen Firmen ist es wie eine zweite Arbeitsebene, die man einfach formell erfüllt und abwickelt, weil es so vorgegeben ist, so wie andere Prozesse vorgegeben sind. Praktisch weicht man aufgrund irgendwelcher Notwendigkeiten andauernd davon ab. Oft deklariert man dann das, was man tut und wie man es tut, kurzhand als Scrum. Kürzlich ebenfalls erlebt. Seit 3 Jahren Scrum eingeführt, aber keiner arbeitet tatsächlich danach. Aufgaben wurden vom Product Owner eingeteilt. Natürlich gab es keine Regel, wann man abweichen durfte, bzw. die Deutungshoheit darüber hat man sich passend gegriffen und es sich angenehm ausgelegt. Hinweise auf die Diskrepanz zu dem, was in den Scrum-Schulungen extra vorher noch kommuniziert wurde, kamen nicht positiv an. Es ist dann ein Problem, wenn du zuviel Erfahrungen mit Scrum hast :-) In manchen Firmen sehe ich das sogar wie eine dritte Arbeitsebene, neben der formellen Vorgehensweise in Projekten, wie sie nach internen durch Gesetze regulierten eProzessen offiziell erfolgen soll - Stichwort Dokumentenmanagement, Milestones mit Konzept, Validierung und Verifikation, Auditfähigkeit der Doku, sowie strikter Einhaltung der Unterschriftenkette. Man probiert, irgendwie diese formellen Prozesse einzuhalten, während man noch das Tagesgeschäft an sich abwickelt, etwas reales irgendwie fertigstellt, wobei probiert wird, das irgendwie unter einen Hut zu bringen. In diesem Dreieck springen dann viele hin und her, weil es einfach nicht richtig zusammenpasst und/oder nicht richtig umgesetzt wird. Und genau das lese ich auch aus den Eingangspost heraus. Was sind die Gründe? Ich sehe ein großes Problem darin, eine gewachsene Struktur in einem großen Maßstab umzustellen. Jeder will schon irgendwie, es geht aber wegen der Sachzwänge nicht, weil die anderen das nicht so machen. Der reale Takt ist ein anderer, weil von der großen Masse der Mitarbeiter vorgegeben. Ich vergleiche das gerne mit dem Experiment der riesigen langen Skier, wo 10 Mann mit festgeschraubten Schuhen drinstecken und gleichzeitig laufen sollen. Jeder will auch loslaufen, aber die anderen machen nicht zeitglich mit, sondern beschweren sich, dass man selber nicht läuft. Die Richtung zu ändern, geht gar nicht. Der große Schwarm bewegt sich in Summe zu 99% dort hin, wo die anderen hinsteuern. Für mich folgt daraus ganz klar die Maxime, solche Prozesse und Vorgaben zu Vorgehensweisen wie Scrum entweder richtig oder gar nicht einzuführen und sich ansonsten den Aufwand und den Stress zu sparen. Damit folgt unweigerlich, dass das Einführen nur in einem kleinen überschaubaren Projekt mit einer kleinen Gruppe erfolgen kann und sich das erst einmal manifestieren muss. Mit Hinweis auf das Phänomen der Männer mit den Skischuhen, muss es auch bei solchen kleinen homogenen Gruppen bleiben. Nur wenn das maximal 2-4 Personen sind, können solche Gruppen noch funktionieren und auch effektiv arbeiten. Voraussetzung ist, dass die Stile auch zueinander passen bzw einander angelichen werden. Und es bleibt dabei, dass Aufgaben grundsätzlich gut modularisiert werden müssen und nur dann auf Teams, statt auf Einzelpersonen verteilt werden sollten, wenn es aus Geschwindigkeits- oder Redunanzgründen unbedingt angezeigt ist, um unnötige Überlappungen zu vermeiden. Eine Kompetenzabdeckung lässt sich z.B. sehr viel besser dadurch erzielen, dass man Module auf Teams verteilt und dann manche Kompetenzträger als Einzelpersonen eben in 2 oder 3 Scrum-Teams arbeiten und mitdenken. Der Große Scrum-Haufen, mit allen möglichen Projektteilnehmern, den ich aber meistens sehe, macht jedenfalls keinen Sinn. Dahe gehe ich nicht von weg. Das Gesagte gilt IMO auch für das übergeordnete Denken, um die Module zusammen zu halten und vorausschauende Zeitpläne zu machen. Es hat niemand gesagt, dass diese Projektleitung nur von einer einzigen Personen durchgeführt werden kann und muss. In dem Zusammenhang muss auch hinterfragt werden, ob es bei Entwicklungen ab einer gewissen Komplexität wirklich nur einen einzigen Product Owner geben kann und ob bei übergeordneten Planungen 2 Wochen Sichten sinnvoll sind.
:
Bearbeitet durch User
J. S. schrieb: > Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet > sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind, > sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende > Minute ist, die an anderer Stelle als Problem doppelt und dreifach > aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren > und ein Konzept zu schreiben, das überhaupt erst einmal als > Diskussionsgrundlage fungieren könnte und andere haben keine Zeit, > Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand > in den Mund" wie es mal jemand formuliert hat. Derartige Situationen kennen wir Entwickler vermutlich alle. Aber gerade in solchen Situationen ist eine gute Kommunikation und Koordination unter den Projektbeteiligten besonders wichtig, um weitere Folgekosten zu vermeiden.
Ein T. schrieb: > J. S. schrieb: >> Ich sehe sehr oft in den Firmen, dass die Entwickler voll ausgelastet >> sind, am Anschlag arbeiten und nicht selten sogar überbelastet sind, >> sodass jede Minute, die irgendwo für etwas drauf geht, eine fehlende >> Minute ist, die an anderer Stelle als Problem doppelt und dreifach >> aufschlägt. Da ist dann angeblich keine Zeit, mal 10min zu investieren >> und ein Konzept zu schreiben, das überhaupt erst einmal als >> Diskussionsgrundlage fungieren könnte und andere haben keine Zeit, >> Konzepte, die erarbeitet wurden zu lesen und arbeiten nur "von der Hand >> in den Mund" wie es mal jemand formuliert hat. > > Derartige Situationen kennen wir Entwickler vermutlich alle. Aber gerade > in solchen Situationen ist eine gute Kommunikation und Koordination > unter den Projektbeteiligten besonders wichtig, um weitere Folgekosten > zu vermeiden. Bestimmt kennt Ihr die Geschichte: Ein alter Mann geht durch den Wald und sieht ein paar Waldarbeiter, wie sie beim sägen mächtig schwitzen. Er ruft ihnen zu: „Männer, Ihr müsst innehalten und Eure Sägen schärfen.“ Und die Männer antworten: „Keine Zeit alter Mann, wir müssen sägen!“ Die Kommunikation einschränken und weiter malochen ist einfach falsch, wenn die Ursache für den personellen Engpass nicht beseitigt wird. Da werden Symptome behandelt anstatt Ursachen zu beseitigen. Hat im übrigen nichts mit SCRUM zu tun.
Uwe D. schrieb: > Er ruft ihnen zu: „Männer, Ihr müsst innehalten und Eure Sägen > schärfen.“ > Und die Männer antworten: „Keine Zeit alter Mann, wir müssen sägen!“ > Die Kommunikation einschränken und weiter malochen ist einfach falsch, Also meine Aussage war keines falls "Kommunikation einschränken". Sie lautete im Gegensatz: "Kommunikation durch geeignete Planung und Dokumente verbessern". Das ist inhaltlich das Gegenteil. Um dein Beispiel aufzugreifen, sei das zitiert, was ich dauernd höre und sehe: "Wir haben keine Zeit etwas Besprochenes niederzulegen, zu präsisieren oder zu Ende zu diskutieren - wir müssens ins nächste Meeting". sowie "Wir haben keine Zeit genau zu planen, wir müssen loslegen, um fertig zu werden". Der Rest soll sich dann von selber erledigen oder wird unterwegs gemanaged. D.h. man rennt ohne Abstimmung in den Wald, fängt an zu sägen und stimmt sich als Gruppe von Baum zu Baum ab, was als Nächstes kommt. Im Nachhinein stellt man fest, dass man vergessen hat, genug Sägen mit zu bringen, nicht rechtzeitig Sägeblätter bestellt hat, einige Bäume in der falschen Reihenfolge gesägt wurden, was dan Abtransport anderer behindert hat und man vorher mal hätte schauen sollen, welche Bäume morsch sind und zuerst hätten gefällt werden müssen. Ich habe ein Beispiel dafür, dass das Scrum-Team nach 2.5 monatigem Sägen ohne vorherige Planung - trotz permanenter Absprache mit einem Haufen Schnitzel dastand, die man nicht verkaufen konnte. Ein Beispiel habe ich, dass man einen Wald gar nicht hätte absägen sollen und sogar eines, bei dem das selbst organisierte Team am Ende merkte, dass es im falschen Wald war. Man glaubt das nicht, aber es ist so.
:
Bearbeitet durch User
J. S. schrieb: > Also meine Aussage war keines falls "Kommunikation einschränken". > Sie lautete im Gegensatz: > > "Kommunikation durch geeignete Planung und Dokumente verbessern". Das > ist inhaltlich das Gegenteil. Deine Ausführungen lasen sich, insbesondere nach dem Threadtitel und -Verlauf, zumindest für mich allerdings leider ein wenig anders. > "Wir haben keine Zeit etwas Besprochenes niederzulegen, zu präsisieren > oder zu Ende zu diskutieren - wir müssens ins nächste Meeting". Diese Meetings haben aber durchaus einen tieferen Sinn, nämlich, die Dinge auszudiskutieren, festzulegen und zu dokumentieren. > D.h. man rennt ohne Abstimmung in den Wald, fängt an zu sägen und stimmt > sich als Gruppe von Baum zu Baum ab, was als Nächstes kommt. Das ist dann aber nicht agil, sondern bescheuert. Und es hat auch nichts mit der Projektmanagementmethode zu tun, denn das gibt es ja bei den klassischen Projekten ganz genauso -- und nach meiner Erfahrung sogar noch öfter. Da ist dann nicht die Zeit für eine ordentliche Planung, Lasten- und Pflichtenhefte werden mal schnell hin gebastelt, wichtige Aspekte offen gelassen, schwammig und mehrdeutig formuliert, denn: "wir haben ja keine Zeit". Und bei nötigen Änderungen wird dann alles auf Stopp gestellt, bis Management, Projektleiter und Kunde ausgekaspert haben, wer dafür bezahlt. > Ich habe ein Beispiel dafür, Das Dumme ist halt: wir alle haben Beispiele -- für alles. Fehlgeschlagene agile und genauso auch klassische Projekte, selbstherrliche und inkompetente Manager und Projektleiter, Vertriebsleute die dem Kunden das Blaue vom Himmel herunter versprochen haben, und so weiter, und so fort. Daher nochmal: agile Vorgehensweisen wurden entwickelt, weil (je nach Studie) 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte gescheitert waren, weil sie die projektierten zeitlichen, ökonomischen oder funktionalen Grenzen gesprengt haben. Gleichzeitig hat sich herausgestellt, daß die Projekte an Umfang zunahmen und es häufig gar nicht mehr möglich war, in einem ökonomisch vertretbaren und von einem menschlichen Geist erfaßbaren Rahmen alles bis ins Detail voraus zu planen. Das heißt natürlich nicht, daß agile Projekte immer erfolgreich wären oder klassische Projekte immer zum Scheitern verurteilt wären. Aber in meinen ganz persönlichen Erfahrungen war die Erfolgsquote in agilen Projekten höher, und die Arbeit deutlich entspannter... okay, jedenfalls meistens. :-)
Schön wirds, wenn dann überall wo Scrum (aufgrund der halbherzigen Einführung usw.) nicht oder nur bescheiden funktioniert, SAFE ausgerollt wird. Dann wird gekotzt. Ich stehe Scrum positiv gegenüber und hab auch schon gesehen wie es ganz gut funktioniert hat (wenn man ehrlich war und nicht alles verbogen hat, um Schönheit nach oben zu Faken) Aber bei SAFE hörts auch bei mir auch. In einer Firma wo Scrum schon nicht funktioniert ist das der super-Gau und es geht gar nix mehr.
SAFe wird ja nicht für ein „normales“ (agiles) Projekt genutzt, wohingegen „SAFe“ ja ausdrücklich für sehr große und häufig mehrere parallel laufende Großprojekte mit sehr hoher Komplexität angewendet wird. Zumindest kenne ich es so. Und dann braucht man halt auch passende Werkzeuge und ausgebildete Menschen dafür. Das ist ja nicht anders als in Wasserfallprojekten oder Programmen: Mit Sprüchen und Marketing kommt Niemand ans Ziel.
Ein T. schrieb: > 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte > gescheitert waren Bei Softwareprojekten ist ein dynamisches Umsteuern ja auch leichter möglich. Daher lässt sich Scrum auch dort noch am ehesten wirksam einsetzen. Ich sehe aber, dass es für alles eingesetzt wird. Bei HW geht das gar nicht. Schon wegen Lieferketten, Teilebestellung etc und vielem mehr.
J. S. schrieb: > Ein T. schrieb: >> 60 bis 80 Prozent der klassisch gemanagten Softwareprojekte >> gescheitert waren > Bei Softwareprojekten ist ein dynamisches Umsteuern ja auch leichter > möglich. Daher lässt sich Scrum auch dort noch am ehesten wirksam > einsetzen. Ich sehe aber, dass es für alles eingesetzt wird. Bei HW geht > das gar nicht. Schon wegen Lieferketten, Teilebestellung etc und vielem > mehr. Wie überraschend: Warum sollten Störungen in Wasserfallprojekten besser zu handhaben sein, das musst Du jetzt mal erklären. Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem 2,5-fach über dem Planbudget…
:
Bearbeitet durch User
Uwe D. schrieb: > SAFe wird ja nicht für ein „normales“ (agiles) Projekt genutzt, > wohingegen „SAFe“ ja ausdrücklich für sehr große und häufig mehrere > parallel laufende Großprojekte mit sehr hoher Komplexität angewendet > wird. > Zumindest kenne ich es so. Und dann braucht man halt auch passende > Werkzeuge und ausgebildete Menschen dafür. > Wäre schön. ich hab es nur erlebt, als es betriebsblind ohne Hinterfragung einfach über alles gestülpt wurde. Teams nie die Berührungspunkte miteinander haben, saßen dann im PI rum. Für Unmut sorgte auch, dass an vielen Stellen die Leute fehlen. Wurde nix gemacht. Für SAFe wurden aber plötzlich haufenweise neue Leute eingestellt um die vorgesehenen Rollen zu besetzen. Hat auch für einiges an Unmut gesorgt Kann man sicherlich nicht SAFe per se anlasten, aber wenn so ein Prozess einfach durchgeprügelt wird ohne Punkt und Komma und ohne mal Innezuhalten und zu überlegen, ob es auch nur ansatzweise Sinn ergibt, dann kommt bei SAFe noch größerer Murcs raus als wenn Scrum in der Art & Weise eingeführt wird
A. B. schrieb: > bei SAFe noch größerer Murcs raus als wenn Scrum in der Art > & Weise eingeführt wird Alles was ohne Verstand eingeführt wird, dürfte darunter leiden und scheitern. A. B. schrieb: > wurden aber plötzlich haufenweise neue Leute > eingestellt um die vorgesehenen Rollen zu besetzen. Das kenne ich aus der Firma, für die ich zuvor tätig wurde. Ich war eine der Personen, die in eine neu geschaffene Rolle eingesetzt wurden. Es war keine aktive SCRUM-Rolle aber es war die Folge dessen Einführung und der Neuorganisation der Abteilungen. Ich merkte sehr schnell, daß das Problem der Firma nicht die Projektorganisation sondern einfach die Anzahl der Bearbeiter war. Die neu eingeführten Organisations-meetings raubten ihnen noch mehr Zeit, als es davor schon der Fall war. Als die Firma auf SCRUM umgestellt war, ging es noch holpriger voran. Hat dann auch direkt einer gekündigt.
A. B. schrieb: > [...SAFe...] > > Wäre schön. ich hab es nur erlebt, als es betriebsblind ohne > Hinterfragung einfach über alles gestülpt wurde. Wie erwähnt, erlebt haben die meisten von uns sicherlich schon vieles. Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer einzuschlagen, dann ist das weder die Schuld des Hammers, noch die der Schraube. Und genau wie man mit jeder Programmiersprache besch...eidenen Code schreiben kann -- sogar in Python -- kann man mit jedem Projektmanagement Projekte verkacken.
Ein T. schrieb: > Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer > einzuschlagen, Dann kannst du ein anderes Werkzeug nehmen. Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen zwingt, ist das etwas problematischer mit dem "sich richtig verhalten". Besonders, wenn andere den Hammer nicht zur Seite legen und das Einkloppen der Schrauben zur Maxime erklärt wird. Wenn eine Firma als Beispiel eingeführt, dass alles mit dem Akku-Schrauber zu machen ist, dann hat der Feinwerktechniker verka**t. Er könnte ohne diese Automatismen besser schrauben, schneller und genauer.
A. F. schrieb: > Dann kannst du ein anderes Werkzeug nehmen. > > Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen Eine Struktur ist halt kein Werkzeug. Eine Struktur sagt lediglich, wo man das Werkzeug findet und was für Prozesse man bei der Nutzung beachten muss (UVV-Prüfung gültig?). Wenn du mit der Struktur nicht klar kommst, dann ist das halt so, die Ludolfs haben auch eine andere Struktur als eine VW.
A. F. schrieb: > Ein T. schrieb: >> Aber wenn jemand daran scheitert, eine Schraube mit einem Hammer >> einzuschlagen, > Dann kannst du ein anderes Werkzeug nehmen. Wenn ich eines habe, aber: in meiner Fabel ging es gar nicht um mich. > Wenn aber eine Firma eine Struktur einführt, die dich zum mitmachen > zwingt, ... dann gibt es ein probates Mittel, das sich "Kündigung" nennt.
Moin, Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken der Details... So wie halt früher von guten Ingenieuren der Entwicklungsprozess gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch ihre Details miteinander bedächtig ausgetauscht haben? Ich hatte immer den Eindruck, wir wären ganz gut gefahren mit den etablierten Methoden früherer Zeiten. Ist das wieder mal nach " If it works, break it"? Ist es wirklich ein Vorteil, so hastig vorzugehen? Ich kann mir unter Scrum Bedingungen nicht vorstellen, daß man dort bedächtig und planvoll voranschreiten könnte. Auch ist der Mensch keine Maschine. Wir brauchen auch Pausen zum Überdenken und Reflektion. Auch muß man manchmal Zeit zum Überdenken bei der Problemlösung zur Verfügung haben. Ich würde besorgt sein, in ein Fahrzeug oder Flugzeug zu steigen und wissen, daß Scrum bei der Entwicklung im Spiel war. Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver Rückkopplung? Mich würde wirklich interessen, wie erfahrene ältere Ingenieure über solche Sachen denken, ohne gleich wegen "Eingefahren" beschuldigt werden. Was brauchen wir übrigens soviel Software und embedded Technik in unserem Leben? Ich bekomme zunehmend den Eindruck wir müllen uns mit gängelnder Technik zu in unserem täglichen Leben. Da ist weniger und essenziell besser. Wir sollten alle viel kritischer sein, mit der Adoption von SW Gadgets, die um uns herum sind. Vieles ist, wenn es wirklich darauf ankommt, ziemlich nutzlos. Was mich betrifft gehe ich nach der Devise vor, weniger ist besser und verwende "Tried and True" Philosphie ohne zum Lebensstress beizutragen. Das besorgt das Leben alleine. Und da seid ihr mit Eurer SW Entwicklung auf Steroidbasis und müllt unser Leben mit Technik zu die wir eigentlich nicht wirklich brauchen und man sich wegen der vielen Bugs doch nicht verlassen kann. Und in Technik die mit Sicherheit zu tun hat, sollte ohnehin bewährte Entwicklungsmethodologie vorrangig sein. Ich mag mich vielleicht in einigen Punkten irren; kann man aber wirklich so Vertrauen zum Produkt haben? Wenn ich mir den trivialen Elektronik Müll vor Augen halte, bin ich wirklich froh einen gewissen Abstand halten zu können und nur das Beste heraus zu picken, sozusagen die Rosinen finden, die wirklich das Leben tangentiell bereichern. Welcher Hahn kräht denn nach den Produkten einer zu hastigen Industrie die überhaupt keine Bestandsdauer haben? Ist Scrum das wert? Die modernen Firmen machen sich vielleicht oft was vor und merken erst viel zu spät, daß mit traditioneller Denkweise viel mehr erreicht werden hätte können. Unsere Wirtschaft produziert in der IT und Elektronik fast nur noch "Eintagsfliegen". Die wichtigen Produkte unserer Wirtschaft müssen eben anders angegangen werden. Konsumerprodukte, unter Scrum geschaffen, bringen viel Zweifel auf, weil man als Fachmann einfach wenig Vertrauen zu dieser Arbeitsmethode haben kann. Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise wirklich dauerhafte Erfolge bringen könnte. Man hat ja scheinbar wenig Zeit zum Durchdenken des Designs und guter Dokumentation. In meiner Arbeitspraxis hat mich gute Begleitdokumentation meiner Projektarbeiten oft sehr geholfen oder mir Zeit gespart. Ich bin ein alter Sack, aber ich würde kündigen, wenn ich in solch chaotische Firmen überwechseln oder mich da einfügen müsste. Ich weiß ich werde von Euch was zu hören kriegen. Aber ich vermute, ich habe schon etwas recht. Kopfschüttelnd, Gerhard
Gerhard O. schrieb: > Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise > wirklich dauerhafte Erfolge bringen könnte Für Manager zählen dauerhafte Einnahmen. Und die gibt es mit Scrum, weil der Kunde eingebettet ist in die ständig nur halbfertigen Projekte. Zudem kann der Manager nachweisen wie seine Arbeitsaffen ständig produktiver werden in dem er die Velocity des Scrum als Massstab für das nutzt, was er sowieso nicht versteht. Und die Arbeitsaffen gehen begeistert mit, wurde ihnen doch erzählt wie wichtig sie sind, dass sie sich selbst verwalten, keinen Chef haben sondern ein Team sind. Dass aus dem ganzen Kram nichts ausser Scheisse rauskommt, wie man selbst an den wenigen super finanzierten Projekten wie eBay oder ChefKoch oder AliExpress sieht, spielt keine Rolle. Da muss die erste Seite glänzen, die Monetarisierung funktionieren, und ob 404 oder altes Zeug in den hinteren Ecken spielt keine Rolle.
Re D. schrieb: > die Ludolfs haben auch eine andere > Struktur als eine VW. Die hatten aber eine der Aufgabe angemessene Struktur. Man bekam dort schnell und günstig Ersatzteile und der Verwalter wusste, wo es zu finden war. Bestelle dir bei VW ein Ersatzteil! Dann zahlst du den gesamten Wasserkopf mit. Der ist für viele Dinge aber nicht nötig und nicht angepasst. Zurückkommend auf das Thema bleibt einfach festzustellen, dass Scrum an vielen Stellen zwar offiziell eingeführt ist, aber nur selten passt. Es klappt nicht, weil es dort, wo es funktionieren könnte, nicht gelebt wird und an vielen Stellen eben die falsche Struktur ist. Scrum und Elektronikentwicklung passen nun einmal nicht zusammen. Scrum kannst du bestenfalls dort einsetzen, wo es für gemacht ist, also z.B. für eine SW Truppe, die embedded programmiert und das Projekt so umfangreich ist, dass es nicht einer alleine packt und selber organisiert.
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er es oft nicht, speziell bei komplexen Projekten.
Gerhard O. schrieb: > Ich bin ein alter Sack, aber ich würde kündigen, wenn ich in solch > chaotische Firmen überwechseln oder mich da einfügen müsste. Ich sehe es als sportliche Herausforderung. Solange ich mit halten kann und will, schwimme ich oben. Niemand zwingt mich dazu, meine Produkte selbst zu benutzen oder gar gut zu finden. Ich muss sie nur so bauen (bzw. programmieren), wie andere es haben wollen.
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken > der Details... > > So wie halt früher von guten Ingenieuren der Entwicklungsprozess > gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch > ihre Details miteinander bedächtig ausgetauscht haben? Daran ist nicht prinzipiell etwas falsch, das funktioniert oft wunderbar wenn 15 Leute an einem Projekt arbeiten. Wenn 50 Leute an einem Projekt arbeiten ist es nicht mehr so einfach die Details miteinander bedächtig auszutauschen. Da ergibt es schon Sinn, das Projekt aufzuteilen und die Kommunikation zu organisieren. Das ist ja noch recht einfach, wenn das Projekt in Hardware-Software-Mechanik mit jeweils kleinen Teams aufzuteilen ist, ab einer gewissen Größe ist aber einfach eine weitere Aufteilung nötig. > Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken > der Details... Diese Schritte sollte es natürlich in Scrum auch geben. Sie sind halt auf unterschiedliche Leute aufgeteilt. Der Ausführende kümmert sich dann immer nur um ein Detail, wie dieses Detail ins größere Bild paßt sollte jemand anders überblicken. Gerhard O. schrieb: > Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht > arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver > Rückkopplung? Das Chaos habe ich auch bei den Methoden des letzten Jahrhunderts immer wieder kennengelernt. Das wurde dann durch inoffizielle Strukturen - mal besser, mal schlechter - in den Griff gebracht. Scrum ist halt einer von vielen Versuchen, dieses Chaos durch offizielle Strukturen in den Griff zu bekommen. Und natürlich leidet Scrum an den selben Problemen wie all die anderen Säue die durchs Dorf gejagt wurden. Das Management liest den Werbefolder, um die Details der Umsetzung soll sich jemand anderer kümmern. - Scrum wird oft eingesetzt, wo es keinen Sinn ergibt. - Es fehlt die Unterstützung des Management. z.B. erhalten nicht die richtigen Leute Entscheidungsbefugnisse, die Firmenstrukturen werden nicht angepaßt, ... - Es fehlt die Unterstützung der Ausführenden. Vom Management kommt nur die Vorgabe: setzt Scrum um. Was man sich davon erwartet bleibt ein Staatsgeheimnis. Also setzt man irgendetwas um, das man dann Scrum nennt. Damit das Management zufrieden ist. - Man erwartet sich von Scrum Dinge, für die es höchstens eine Basis darstellt. z.B. Kommunikation: Wenn die Leute die wichtigen Informationen für sich behalten, dann ist es egal, wie viele Besprechungen, und mit wem, stattfinden. Erst vor kurzem bin ich darauf gekommen: Scrum ist angeblich schon seit Jahren in der Firma etabliert. Da habe ich die ganze Zeit nicht das geringste davon bemerkt. Aber irgendwer im mittleren Management konnte das von seiner ToDo-Liste streichen. Und dann fragt man sich, ob Scrum funktioniert? Diese Frage stellt sich oft gar nicht erst.
Steve van de Grens schrieb: > Gerhard O. schrieb: >> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er > es oft nicht, speziell bei komplexen Projekten. Das herauszufinden ist immer wieder ein eigenes Projekt. Es hat halt sowohl Vor- als auch Nachteile, wenn man das gleich mit der Umsetzung zusammen macht.
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? Daß sie mit zunehmender Komplexität immer schlechter und irgendwann gar nicht mehr funktionieren. Lies einfach den Thread.
Gerhard O. schrieb: > Moin, > > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken > der Details... Wenn Du die Kosten übernehmen musst, für alle schief gelaufenen Sachen, die nicht bedacht wurden, die sich inzwischen geändert hatten (seit Erstellung des LH) und dem, was der Kunde eigentlich braucht… dann ändert sich vielleicht Deine Sichtweise. Und jedes neue Jahr, welches das Projekt verschlingt - wegen der CRs - steigern die Kosten - und der Auftraggeber hat immer noch kein Produkt und muss weiter warten… > > So wie halt früher von guten Ingenieuren der Entwicklungsprozess > gehandhabt wurde. War es nicht besser, wenn das Team konkret und logisch > ihre Details miteinander bedächtig ausgetauscht haben? Früher war nicht alles besser - und auch nicht billiger, insbesondere bei Wasserfallprojekten. > Ist es wirklich ein Vorteil, so hastig vorzugehen? Ich kann mir unter > Scrum Bedingungen nicht vorstellen, daß man dort bedächtig und planvoll > voranschreiten könnte. Naja, was hat denn SCRUM (oder agil) mit „hastig“ zu tun? > Ich würde besorgt sein, in ein Fahrzeug oder Flugzeug zu steigen und > wissen, daß Scrum bei der Entwicklung im Spiel war. Du meinst also, das Toyota unsichere Autos baut? > Kann man unter sozialen Firmen Scrum Bedingungen wirklich noch bedacht > arbeiten? Oder entsteht da oft nur graduelles Chaos mit positiver > Rückkopplung? Sorry Gerhard, hast Du persönlich genau diese Erfahrung gemacht? Also ich nicht. Dafür habe ich insbesondere im erfolgreichen Mittelstand zu oft erlebt, wie assozial der Inhaber oder GF mit den Arbeitnehmern umgegangen ist - weil ich das „Gespräch“ noch 50m weiter im Konferenzraum gehört habe. > Mich würde wirklich interessen, wie erfahrene ältere Ingenieure über > solche Sachen denken, ohne gleich wegen "Eingefahren" beschuldigt > werden. Argumente zu bringen doch kein Problem, nur interessiert mich die persönliche Schublade nicht. Also: nicht bewertend und nicht vom Thema abschweifend. > Was brauchen wir übrigens soviel Software und embedded Technik in > unserem Leben? Ich bekomme zunehmend den Eindruck wir müllen uns mit > gängelnder Technik zu in unserem täglichen Leben. Die „Sinnfrage“ hat jetzt aber nix mehr mit SCRUM zu tun. > Und in Technik die mit Sicherheit zu tun hat, sollte > ohnehin bewährte Entwicklungsmethodologie vorrangig sein. Trotzdem wird auch sicherheitsrelevante Software erfolgreich mit SCRUM entwickelt, seit mehr als 10 oder 15 Jahren. > Ich kann mir nicht vorstellen, daß diese chaotische Arbeitsweise > wirklich dauerhafte Erfolge bringen könnte. Man hat ja scheinbar wenig > Zeit zum Durchdenken des Designs und guter Dokumentation. In meiner > Arbeitspraxis hat mich gute Begleitdokumentation meiner Projektarbeiten > oft sehr geholfen oder mir Zeit gespart. Du hast keine Erfahrung mit SCRUM, anders ist Deine Beurteilung für mich nicht zu verstehen. Vielleicht hilfts ja, mal mit erfahrenen SCRUM Anwendern zu sprechen oder über die Schulter zu schauen. Vermutlich wärst Du überrascht, wie zufrieden Kunden sein können und wie konsequent mit „Klugscheißern und Faulpelzen“ umgegangen wird…
Hallo Uwe, Wie ich sehe hast Du Dir die Zeit genommen, meinen "aufgewirbelten Staub" mit dem sachlichen "Besen" wieder in den richtigen Platz fegen zu versuchen:-) Nun ja! Was soll ich darauf antworten? Bei uns geht es noch ohne Scrum zu. Da wir nur acht Entwickler zählen, haben wir uns gut aufeinander eingespielt. Generell läuft alles harmonisch und mehr oder weniger innerhalb der Gefüge und notwendige Erörterungen sind spontan und informal. Ich glaube schon, der Laden läuft. Das Thema ist übrigens hier niemals, nicht einmal ansatzweise, aufgekommen. Allerdings kann sich ein kleiner Betrieb nicht leisten, "unfähig" zu agieren. Da geht es wirklich um technische Klarheit und Sauberkeit. Wenn man alles hier so liest, bekommt man einen sehr widersprüchlichen, chaotischen Eindruck. Ist wahrscheinlich, wie sonst im Internet, mit viel Wahrheit und Unwahrheit vermischt. Möglicherweise mache ich mir ein falsches, oder zumindest ein verzerrtes, Bild davon. Ich weiß es nicht. Man bekommt schon den Eindruck, Scrum ist alles andere als Bedächtigkeit und ruhiges Vorgenen und Ausführung. Zusammen mit den menschlichen Unvollkommenheiten wird da ein düsteres Bild gemalt. Andrerseits bekomme ich von Dir den Eindruck, daß Scrum tatsächlich sehr von den menschlichen Qualitäten des Entwicklungsteams abhängig ist und Unvollkommenheiten stärker zum Ausdruck kommen. Aber da muß die PL sich im Klaren sein, daß sie hier entsprechend organisieren müssen und nicht ein zusammengewürfeltes Team ohne Harmonie. Die Mißtöne machen sich dann sonst sofort bemerkbar. Insgesamt bekommt hier im Forum leider schon allgemein ein sehr negatives Bild von Scrum. Bei Diskussionen über Scrum bekommt den Eindruck einer chaotischen Umgangsatmosphäre ohne daß die Mitglieder in eine gemeinsame Richtung ziehen. Du erwähntest Autos. Nun gut, mein 2006er Toyota war ziemlich perfekt. Mein 2021 Mazda softwaremässig weniger so. Da könnte ich viele, auf eine andere Sichtweise, demonstrierte Einstellungsweise, Verhalten und Inkonsistinenzen aufmerksam machen, die eigentlich nicht vorkommen sollten, die man als Fachmann schon bemerkt. Das Fahrzeug selber ist schon gut. Aber die SW darin, könnte man wesentlich verfeinern und benutzerfreundlicher machen. Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet. Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das verschlingt viel Energie, Zeit und Geld. OK. Ich merke, Deine Einwände sind ehrlich und objektiv und geben Anlass mit den Vorurteilen gegenüber vielleicht sparsamer umzugehen:-) Gruß, Gerhard
:
Bearbeitet durch User
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? Nur der Vollständigkeit halber: Scrum ist auch aus dem letzten Jahrhundert. Es wurde Ende der 1980er Jahre bis Anfang der 1990er Jahre erdacht. Es ist also ein mindestens 30 Jahre alter Hut.
Scrum dient doch in Wahrheit nur dazu Arbeit so kleinteilig aufzudröseln dass ein beliebiger Idiot die Arbeit des anderen übernehmen kann. Das Ganze lässt sich dann auch noch gut tracken und überwachen, sprich man kann die Leute einfacher unter Druck setzen. "Du bist zu langsam, dein Kollege schafft mehr Minitasks in der gleiche Zeit also gib mal Gas du faule Sau". Das ist praktisch die Fliesbandisierung der Kopfarbeiter.
Franko S. schrieb: > dass ein beliebiger Idiot die Arbeit des anderen übernehmen kann. Es reicht nicht, die Aufgabe zu benennen und ihr einen Namen zu geben. Es muss definiert werden, was zu tun ist, wie sie umzusetzen ist und in welche Komponenten sie zu unterteilen ist. Das Ganze dann so, dass es mit den Tätigkeiten und Aufgaben anderer harmonisiert. Das muss so oder so passieren. Auch wenn es die Gruppe selbst definiert, also jeder für sich, müssen die Inhalte der Aufgaben und Lösungen dokumentiert werden. Ohne das geht es nicht. Wird das unterlassen, hilft auch scrum nicht. Dann kann niemand nirgendwo einspringen. Wird das hingegen ausreichend gut gemacht, können andere in die Lücken hinein springen, das ist richtig. Ob es effektiv ist, daß jeder alles vom Projekt ganz genau in der erforderlichen Tiefe kennt, um das im Ernstfall auch wirklich zu leisten, ist eine andere Frage, die sich die Firme beantworten muss. Daß kleinteilige Aufgaben das tracking verbessern, ist auch richtig. Muss aber irgendwie sein, wenn kontrolliert werden soll, wo die Gruppe steht. Zumindest die Gruppe muss wissen, wo sie steht. Allerdings kommt da bei mir eine Frage auf: Sind die Aufgaben, die die Gruppe zur Umsetzung der Lösungen definiert und abarbeitet, vom Scrum Master einsehbar? Oder auch der Geschäftsleitung? Wie sieht es mit den Teilaufgaben und der Zuordnung zu den Personen aus? Ist das von der Teamleitung einsehbar? Dann könnte es zur Beurteilung herangezogen werden, was aber problematisch ist. Bleibt das als Arbeitsdukumentation dauerhaft gespeichert? Könnte es mit einer Software ausgewertet werden, wie lange jeder einzelne an einer Aufgabe dran war? Ich kann mich an einen AG erinnern, der die Protokolle der Mitarbeiter an den Maschinen automatisch ausgewertet hatte und Ärger mit dem Betriebsrat bekam, weil die berechtigen Schutzinteressen verletzt waren. Es war gegen den Datenschutz das elektronisch zu speichern, weil es automatisch auswertbar war. Als Folge mussten die Protokolle ohne den Bearbeiter in SAP gespeichert werden und der Zusammenhang zwischen Person und Protokoll blieb nur als Papier im Ordner. Die Datenbank, die die Fehler und die Maßnahmen an der Anlage protokollierte, wurde auch zusammengestrichen. Die Installationspläne mussten nach einer Weile gelöscht werden, weil durch die Planungen letzterdings die Urlaube und Krankheiten nachvollzogen werden konnten und es offensichtlich war, wie lange jeder Überstunden gemacht hatte. Nachtrag: Ich mache jetzt doch einen Extra Beitrag dazu: Beitrag "verletzt die Arbeit mit SCRUM die Betriebsratsvereinbarungen?"
Gerhard O. schrieb: > Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein > soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet. > Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das > verschlingt viel Energie, Zeit und Geld. Wenn Du Scrum mit fortlaufenden Zieländerungen assoziierst, dann geht das natürlich nicht. Die Koordination der vielen Teil-Arbeiten, neuer Baustellen und alle non-safety-Teile profitieren dagegen genauso viel oder wenig wie SW ohne Safety.
Gerhard O. schrieb: > Hallo Uwe, > > Wie ich sehe hast Du Dir die Zeit genommen, meinen "aufgewirbelten > Staub" mit dem sachlichen "Besen" wieder in den richtigen Platz fegen zu > versuchen:-) Hallo Gerhard, beim letzten Forumstreffen in Dresden saßen viele Meinungen und Persönlichkeiten im Biergarten und konnten mit Respekt und „einfach mal stehenlassen“ viel übereinander erfahren - auch über das jeweilige Arbeitsumfeld. Das ist ein prima Fundament für eine Zusammenarbeit. Du warst damals virtuell dabei ß stimmt‘s? > Wenn man alles hier so liest, bekommt man einen sehr widersprüchlichen, > chaotischen Eindruck. Ist wahrscheinlich, wie sonst im Internet, mit > viel Wahrheit und Unwahrheit vermischt. Möglicherweise mache ich mir ein > falsches, oder zumindest ein verzerrtes, Bild davon. Ich weiß es nicht. Meine These: Halbwissen, Hörensagen und persönliche Meinungen - diametral dazu relativ wenige erfahrene Leute im agilen Umfeld. > Man bekommt schon den Eindruck, Scrum ist alles andere als Bedächtigkeit > und ruhiges Vorgenen und Ausführung. SCRUM bzw. Agil - Schnell die Richtung ändern zu können hat nichts mit oberflächlich, Massenproduktion, Kleinteiligkeit und „Management Tool“ zu tun. Menschen die das behaupten, sind meistens mit keinem Team zufrieden - die stehen nur auf ihrer eigenen Seite. > Zusammen mit den menschlichen > Unvollkommenheiten wird da ein düsteres Bild gemalt. Andrerseits bekomme > ich von Dir den Eindruck, daß Scrum tatsächlich sehr von den > menschlichen Qualitäten des Entwicklungsteams abhängig ist und Jedes Team entsteht durch Arbeit miteinander. Agile Teams funktionieren prinzipiell nicht viel anders als klassische Teams - allerdings gibt es keine Hierarchie. Diese Teams entwickeln weniger Erfahrene aktiv weiter, so dass Abhängigkeiten von Spezialisten abgebaut werden und damit der „Nachwuchs“ gesichert ist. Zudem hat das Team direkten Einfluss auf das Verhalten des Einzelnen: Wer wiederholt nicht das vereinbarte abliefert, der kriegt eins auf den Deckel - warum sollte es mit der Verantwortung/Verbindlichkeit anders laufen? > Du erwähntest Autos. Nun gut, mein 2006er Toyota war ziemlich perfekt. > Mein 2021 Mazda softwaremässig weniger so. Da könnte ich viele, auf eine > andere Sichtweise, demonstrierte Einstellungsweise, Verhalten und Das Vorgehen bei Toyota hat mich stark beeinflusst. Vor allem nicht ständig immer nur auf Probleme zu fixieren, wurde auch immer die Chance betrachtet und wahrgenommen… > Daß Scrum auch in sicherheitsrelevanter SW erfolgreich eingesetzt sein > soll, finde ich übrigens überraschend. Das hätte ich nicht erwartet. > Fast alle unsere Projekte haben sicherheitsrelevante Vorgaben und das > verschlingt viel Energie, Zeit und Geld. Ich selbst kann nur von europäischen Firmen sprechen. Wer schon einmal eine Software mit SIL > 2 mitgebaut hat - oder eine Zertifizierung nach Common Criteria ab EAL3 aufwärts, der weiß das da extrem viel Formalismus, Disziplin und vor allem langer Atem notwendig ist, um erfolgreich (in Quality, Time & Budget) zu sein. Jede Menge Systeme wird genau so und mit SCRUM gebaut. Das betrifft Aviation, Rail, Automotive, Computing… In den Projekten in denen ich arbeite, sind oft mehrere hundert Menschen involviert, verteilt über Europa. Meine Erfahrung ist zu über 80% positiv - es gibt nach wie vor 20% beschissene Projekte - z.B. mit völlig unterfinanzierten Vorhaben (Wolkenkuckucksheim) oder bekloppten Geldgebern, die sozial unfähig sind und ihre Grenzen nicht kennen. Was das Thema Produktivität angeht: Der Kunde hat nach Ende des Sprints ein Produktinkrement, das er sofort verwenden kann. Und das Produkt ist genau so, wie es während der Entwicklung der Kunde selbst definiert hat. Und ich als Dienstleister habe implizit die Teilabnahme und ein Protokoll - nicht ganz unwesentlich bei der Abrechnung. Und es gibt eine belastbare Velocity nach spätestens 3-5 Sprints. Dazu gibt es ein Commitment der Mitglieder des Teams zum Ziel. Durch die enge Zusammenarbeit fällt der ganze Flurfunk weg, denn Transparenz ist Pflicht. Wir erreichen damit eine Abrechenbarkeit von 80-90% in Projekten, der Rest ist für Weiterbildung und die Entwicklung sozialer Fähigkeiten. Lebensqualität: Und ich selbst bin fast immer der Älteste in den Projekten und lebe beruflich entspannt, meine Gesundheit ist nicht in Gefahr und ich lerne sehr gerne von meiner Kollegenschaft - die teilweise deutlich jünger als meine Kinder sind. Beste Grüße aus Dresden, Uwe
Uwe D. schrieb: > Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte > ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem > 2,5-fach über dem Planbudget… Das ist für heutige Großbauprojekte ja schon lächerlich günstig. :-)
Hallo Uwe, Nett von Dir zu hören und Deine Gedanken zum Thema zu lesen. Ja. Unser Meeting hat mir auch gefallen. Müssen wir wieder machen. Grüße, Gerhard
Steve van de Grens schrieb: > Gerhard O. schrieb: >> Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Dazu muss der Auftraggeber wissen, was er braucht. In der Praxis weiß er > es oft nicht, speziell bei komplexen Projekten. Na zumindest auf dem Top-Level weiß der Auftraggeber durchaus sehr wohl, was er braucht. Zum Beispiel: -eine Steuerung für eine Maschine, die 1000 Eisenteile pro Tag biegt -einen Zug, der 500 Passagiere befördert und mindestens 200 km/h fährt -ein Gebäude mit 300 Mietwohnungen à so-und-soviel Quadratmetern Unterhalb des Top-Levels wird es dann schwieriger. Da bräuchte es fähige Leute, die zum Kunden gehen und die Branche verstehen um die es geht. Mit einem guten Verständnis von den Besonderheiten und technischen Bestimmungen der jeweiligen Branche. These: SCRUM existiert vor allem deshalb, weil Vertriebler hauptsächlich nach "kann gut verkaufen" eingestellt werden, nicht nach "versteht tatsächlich die Probleme des Kunden, weil er einfach Ahnung von der Materie hat". Das ist nur halb ironisch gemeint - ich denke, da ist durchaus was Wahres dran.
:
Bearbeitet durch User
Mark B. schrieb: > Uwe D. schrieb: >> Nachtrag: Das Beispiel https://de.wikipedia.org/wiki/Eiffelturm hatte >> ich schon einmal gebracht - lange vor SCRUM und Co. - und trotzdem >> 2,5-fach über dem Planbudget… > > Das ist für heutige Großbauprojekte ja schon lächerlich günstig. :-) Das ist das Hauptsächliche: Löse das Dilemma. Ähnlich ist es bei Projekten wie: Stuttgart 21. Wieviele Bahnhöfe sind denn schon in der Dimension unterirdisch gebaut worden, unter den gegebenen Bedingungen? Waren wirklich die richtigen Gutachter dabei? Wer hat von der Seite Einfluss genommen? Waldschlösschenbrücke Dresden Geplant schon vor dem 1.WK - und gebaut gegen riesigen Widerstand (von vielen Leuten, die da nicht wohnen oder selbstgerecht in ihrem Elfenbeinturm sitzen). Immerhin nur 30% Mehrkosten, vor allem wegen diverser Rechtsstreitigkeiten und damit einhergehender längerer Bauzeit. Und heute? Da reicht ein Experiment mit einem Fahrradweg auf der benachbarten Brücke, dem „Blauen Wunder“, da steht der Verkauf im Umkreis von 1km fast komplett still. Den Zuwachs an Verkehr kann man den umsetzenden Firmen des Bauwerks nicht anlasten. Warum haben denn die „schlauen Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ keinen besseren Vorschlag gemacht? Genau - weil sie es nicht konnten. Vielleicht mal miteinander reden, wer ja ein guter Anfang.
Uwe D. schrieb: > Warum haben denn die „schlauen Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ > keinen besseren Vorschlag gemacht? Den besseren Vorschlag und die untermauerten Warnungen vor schlummernden Herausforderungen wurden sehr oft bereits gemacht. Nur werden diese in der Regel von den Machern, die das Projekt schönmachen, z.B. für die Politik und Haushältern, kaltgestellt. Und das wird sich vermutlich auch in der Zukunft nie ändern.
Mark B. schrieb: > Na zumindest auf dem Top-Level weiß der Auftraggeber durchaus sehr wohl, > was er braucht. Zum Beispiel: > -eine Steuerung für eine Maschine, die 1000 Eisenteile pro Tag biegt > -einen Zug, der 500 Passagiere befördert und mindestens 200 km/h fährt > -ein Gebäude mit 300 Mietwohnungen à so-und-soviel Quadratmetern Das mögen Motivationen, Ziele, Abschätzungen oder was auch immer sein. Meist aber keine harten Fakten. Etwas bisheriges 1-1 ersetzen oder kopieren ist planbar. Z.B. Deine Steuerung, wenn der Vorgänger das gleiche macht. Etwas neues hingegen ist nur vage im Voraus zu durchdenken. Darum baut man Prototypen, egal ob virtuell oder real. Wenn Deine Steuerung früher mechanisch war und jetzt elektronisch, sind möglicherweise mit kleinen Umstellungen die 10-fachen Mengen oder Aufträge mit höheren Anforderungen möglich.
:
Bearbeitet durch User
Uwe D. schrieb: > Wieviele Bahnhöfe sind denn schon in der Dimension > unterirdisch gebaut worden, unter den gegebenen Bedingungen? Kein Einziger! und das hat seinen Grund: Das ist unangemessen gefährlich, aufwändig, langwierig und teuer. Daher gibt es das nicht. Schon Haltestellen für die U-Bahnen werden aus diesen Gründen zögerlich gebaut. Dass in Stuttgart so arg gebaut wurde, hat einfach damit zu tun, dass der Herr Mappus, der damals an der Regierung war, sich ein Prestige-Objekt gönnen wollte. Zudem haben Recherchen inzwischen ergeben, dass dort sehr einflussreiche Unternehmer mit den Grundstücken spekuliert haben und so Profit einfahren konnten, als sie diese der Bahn / der Stadt verkaufen konnten. Es wurde gebaut, weil gebaut werden sollte, obwohl selbst der Architekt damals Einwände gehabt hat und vor Risiken bei den Röhren gemahnt hatte. Das Problem des Wassereinschubs und Aufquellen war hinlänglich bekannt. Die meisten Stuttgarter kannten die Zusammenhänge und wollten das nicht haben. Da aber auch viele von Außerhalb mitwählen durften, wurde ihnen das von aussen aufgezwungen. Soviel zum Thema Gruppenentscheidung.
Uwe D. schrieb: > Wer wiederholt nicht das vereinbarte abliefert, > der kriegt eins auf den Deckel - warum sollte es mit der > Verantwortung/Verbindlichkeit anders laufen? Was bedeutet denn konkret "auf den Deckel"? Wenn die Gruppe entscheidet, wer was zu tun hat, dann gibt es bei der Verteilung immer Verlierer und Gewinner. Da finden sich dann die Grüppchen zusammen und verteilen sich das so, dass sie gut glänzen können und andere die A-Karte haben! Alles erlebt. Uwe D. schrieb: > Diese Teams entwickeln weniger Erfahrene aktiv weiter, Wieso sollte das nur dort zustande kommen? Eine Weiterentwicklung erfordert immer, dass ein Unerfahrener an eine Aufgabe dran kommt, die er noch nicht beherrscht. Wenn man sich das zeitlich leisten kann, dann geht das mit und ohne Scrum. Wenn es keine Hierarchie gibt, gibt es keine neutrale Person, die für eine Balance sorgt. Es ist also nicht automatisch sichergestellt, dass sich alle weiterentwickeln. Da gibt es immer eine Gruppendynamik, die einzelne an den Rand drängt. Das im SCrum alle gleichberechtigt sind, ist ein Ideal. Kann sein, wird aber bei weitem nicht erreicht.
Uwe D. schrieb: > Warum haben denn die „schlauen > Ich-hab-es-ja-schon-vorher-gesagt-Klugscheißer“ keinen besseren > Vorschlag gemacht? > > Genau - weil sie es nicht konnten. Vielleicht mal miteinander reden, wer > ja ein guter Anfang. Die machen immer gute Vorschläge. Und das Beste ist, im Gegensatz zum Hauptprojekt gibt es bei den Alternativkonzepten keine Planungsfehler und Kostensteigerungen, die durchdenken alleine die komplette Komplexität in einem Rutsch, während Teams aus hunderten Ingenieuren einfach zu dumm sind. (Oder die Alternativprojekte haben doch nur den Vorteil, dass sie nicht ausgeführt werden und deshalb auf dem Papier für immer und ewig viel besser und billiger sind?)
K. F. schrieb: > Uwe D. schrieb: >> Wieviele Bahnhöfe sind denn schon in der Dimension >> unterirdisch gebaut worden, unter den gegebenen Bedingungen? > Kein Einziger! und das hat seinen Grund: Das ist unangemessen > gefährlich, aufwändig, langwierig und teuer. Daher gibt es das nicht. > Schon Haltestellen für die U-Bahnen werden aus diesen Gründen zögerlich > gebaut. In Deutschland nur kleinere Bahnhöfe, aber in Europa - in Paris z.B. schon: STATION CHÂTELET-LES HALLES > Die meisten Stuttgarter kannten die Zusammenhänge und wollten das nicht > haben. Da aber auch viele von Außerhalb mitwählen durften, wurde ihnen > das von aussen aufgezwungen. > > Soviel zum Thema Gruppenentscheidung. Es ist meistens so: Wenn es klappt, dann wird stolz gefeiert - wenn es schief geht, dann haben es alle vorher gewusst.. K. F. schrieb: > Uwe D. schrieb: >> Wer wiederholt nicht das vereinbarte abliefert,… > Was bedeutet denn konkret "auf den Deckel"? > Wenn die Gruppe entscheidet, wer was zu tun hat, dann gibt es bei der > Verteilung immer Verlierer und Gewinner. Es gibt eine knackige Ermahnung, dann eine gelbe Karte und bei der nächsten großen Sache fliegt die Person aus dem Team. Warum sollte die Verbindlichkeit höher sein, wenn jemand im nicht agilen Projektumfeld arbeitet? Ehrlicherweise ist es doch fast immer so, dass die Kollegenschaft das kotzen kriegt, wenn es Leute gibt, die einfach so die Zeit rumbringen dürfen und vielleicht noch großkotzig alles besser wissen. > Da finden sich dann die > Grüppchen zusammen und verteilen sich das so, dass sie gut glänzen > können und andere die A-Karte haben! Alles erlebt. Dann ist der SCRUM Master nicht tough… > > Uwe D. schrieb: >> Diese Teams entwickeln weniger Erfahrene aktiv weiter, > Wieso sollte das nur dort zustande kommen? > Eine Weiterentwicklung erfordert immer, dass ein Unerfahrener an eine > Aufgabe dran kommt, die er noch nicht beherrscht. Wenn man sich das > zeitlich leisten kann, dann geht das mit und ohne Scrum. Hatte ich ja geschrieben - es geht auch ohne SCRUM. Im SCRUM Team mache ich es, wenn der Bedarf besteht. Denn der Geldgeber ist dazu verpflichtet, entsprechend qualifizierte Ressourcen zu stellen. Das ist der Standard in meinen Projekten. Selbst externe Dienstleister werden dazu angehalten, ihre Ressourcen aktiv im gemeinsamen Projekt weiterzuentwickeln. Da habe ich optimal Einfluss auf das Ergebnis. Wertschätzung mögen alle.. > Wenn es keine Hierarchie gibt, gibt es keine neutrale Person, die für > eine Balance sorgt. Es ist also nicht automatisch sichergestellt, dass > sich alle weiterentwickeln. Da gibt es immer eine Gruppendynamik, die > einzelne an den Rand drängt. Im SCRUM Team gibt es keine Hierarchie - wer die installiert, will kein SCRUM Team, sondern betreibt Marketing. > Das im SCrum alle gleichberechtigt sind, ist ein Ideal. Kann sein, wird > aber bei weitem nicht erreicht. Dann frage doch mal in der nächsten Retrospektive, warum das so ist… Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem Versagen, Überforderung, fehlende Erfahrung, …
Uwe D. schrieb: > Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem > Versagen, Überforderung, fehlende Erfahrung Das Dogma ist nie schuld, nur die Menschen...
Michael B. schrieb: > Das Dogma ist nie schuld, nur die Menschen... Man merkt schon, wie sehr Du an einer sachlichen Diskussion zur Erweiterung Deines Horizonts interessiert bist. Wenn man sich an Vorurteilen festhalten kann, gewinnt der Tag Struktur und das Leben wird schön einfach.
Michael B. schrieb: > Uwe D. schrieb: >> Das Problem ist nicht SCRUM, sondern die Verhinderer - Angst vor dem >> Versagen, Überforderung, fehlende Erfahrung > > Das Dogma ist nie schuld, nur die Menschen... Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider alle total falsch gemacht.
Cyblord -. schrieb: > Michael B. schrieb: >> Das Dogma ist nie schuld, nur die Menschen... > > Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider > alle total falsch gemacht. Staatlich organisierte Versuche mit Sozialismus und Kommunismus sind bisher allesamt gescheitert, das stimmt. Aber auf einer freiwilligen Basis ist der Kommunismus mitunter sogar in marktwirtschaftlichen Umgebungen erfolgreich, etwa in israelischen Kibbuzen.
Ein T. schrieb: > in israelischen Kibbuzen. Kibuzzim Sollte man erfragen, wie die Macht- und Entscheidungsstrukturen in einem solchen Kibuz gelagert sind und wirken? Soweit mir bekannt arbeiten die gesamtverantwortlich entscheidend und der einzige, der etwas zusagen hat, ist der örtliche Rabbi - vorwiegend in religiösen, aber auch sozialen Fragen. Da ist er so eine Art allround-Ansprechpartner für alles.
Ein T. schrieb: > Wenn man sich an Vorurteilen festhalten Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. Ich habe zu Scrum sogar einen 'Doppelblindtest', also dasselbe Projekt mal mit und mal ohne agile Methoden erlebt. Cyblord -. schrieb: > Wie beim Kommunismus. Der ist ja so super. Nur haben das bisher leider > alle total falsch gemacht. Erklär das mal dem Kommunisten Ein T.
K. F. schrieb: > Ein T. schrieb: >> in israelischen Kibbuzen. > Kibuzzim Wenn man schon klugscheißen will, sollte man es wirklich besser wissen. Im Deutschen ist der Plural "Kibbuze" (bzw. als Dativ "in Kibbuzen") korrekt. Dein hebräischer Plural "Kibbuzim" ist zwar korrekt, aber hebräisch. > Sollte man erfragen, wie die Macht- und Entscheidungsstrukturen in einem > solchen Kibuz gelagert sind und wirken? Soweit mir bekannt arbeiten die > gesamtverantwortlich entscheidend und der einzige, der etwas zusagen > hat, ist der örtliche Rabbi - vorwiegend in religiösen, aber auch > sozialen Fragen. Da ist er so eine Art allround-Ansprechpartner für > alles. Das wäre aber ungewöhnlich, denn die meisten Kibbuze sind säkular orientiert. Der religiösen Kibbuzbewegung gehören nur knapp sechs Prozent der Kibbuze an. Genau wie das mit dem Plural oben würdest Du das aber alles wissen, wenn Du wenigstens den (knappen) Artikel in der deutschsprachigen Wikipedia gelesen hättest. Wenn Du künftig erfolgreicher klugscheißen, es also wirklich besser wissen willst, und zudem englische Sprache verstehend lesen kannst, hat die englischsprachige Wikipedia umfangreichere Informationen. Viel Glück!
Michael B. schrieb: > Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. Es fällt mir außerordentlich schwer, das zu glauben.
Ein T. schrieb: > Michael B. schrieb: >> Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. > > Es fällt mir außerordentlich schwer, das zu glauben. Um so leichter scheinst du an Scrum-Versprechen zu glauben. Bias.
Michael B. schrieb: > Ein T. schrieb: >> Michael B. schrieb: >>> Ich brauche keine Vorurteile, ich kann dank Erfahrung urteilen. >> >> Es fällt mir außerordentlich schwer, das zu glauben. > > Um so leichter scheinst du an Scrum-Versprechen zu glauben. Ach, beruflich entwickle ich jetzt seit über 30 Jahren Software, mal mit und mal ohne agilen Methoden. Meine agilen Projekte waren bis auf wenige Ausnahmen erfolgreicher in der Zielerreichung und trotzdem angenehmer und entspannter. Wenn Dein Auftreten im echten Leben allerdings dem in diesem Forum ähnelt, dann verstehe ich gut, warum agiles Arbeiten bei Dir nicht funktioniert.
Ein T. schrieb: > dann verstehe ich gut, warum agiles Arbeiten bei Dir nicht funktioniert. Tritt dir selbst ans Schienbein und nicht anderen, ich gucke anderen zu wie sie ihr Scrum durchziehen (und weiss nicht ob ich lachen oder weinen soll). Aber Ätzhammeln wie dir, die anderen nur in die Eier treten wollen, sind da sicher richtig aufgehoben
Michael B. schrieb: > Tritt dir selbst ans Schienbein [...] > Aber Ätzhammeln wie dir, die anderen nur in die Eier treten wollen, [...] Armes Schneeflöckchen... Wenn Du gar so empfindlich bist, solltest Du Dir erstmal solche Ausfälle verkneifen: Michael B. schrieb: > Erklär das mal dem Kommunisten Ein T. Das ist übrigens genau das was ich gemeint habe: wer zwar selbst ständig mit Provokationen wie dieser böswilligen Unterstellung um sich wirft, jedoch bei Gegenwind sofort das Mimimöschen gibt, ist mit anderen Menschen inkompatibel und kann deswegen natürlich auch nicht agil arbeiten. Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu begegnen, also andere ernst und ihre Anregungen und Kritiken anzunehmen. Pöbelnde Mimis sind für diese Arbeitsweise offensichtlich denkbar ungeeignet und werden erst kurz eingenordet, und im Wiederholungsfall geräuschlos entfernt.
Ein T. schrieb: > Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu > begegnen Ja aber das ist auch so ein Problem: Diese Gleichberechtigung existiert in der Wirtschaft nicht, dann kann sie auch in SW Teams nicht existieren. Am Ende ist jemand in der Verantwortung dass das Ding fertig wird und tut was der Kunde erwartet und was man verkaufen kann. Und als jemand der diese Verantwortung hat, will ich auch ansagen können was läuft. Kann ich das nicht, nehme ich auch die Verantwortung nicht an. Das Team selbst hat keine Verantwortung. Die können schön auf Augenhöhe coden aber niemand kommt zu denen wenn der Kunde warten muss oder das Ding macht was es will.
Cyblord -. schrieb: > Ein T. schrieb: >> Bei agilen Methoden geht es nämlich darum, einander auf Augenhöhe zu >> begegnen > > Ja aber das ist auch so ein Problem: Diese Gleichberechtigung existiert > in der Wirtschaft nicht, dann kann sie auch in SW Teams nicht > existieren. Du weißt doch, wie Zusammenarbeit in einem Technikerteam läuft: Kompetenz, Erfahrung und die Güte der Vorschläge spielen dabei durchaus eine Rolle. Bei agilen Projekten gewinnt halt (ok: im Idealfall), wer den besten Vorschlag gemacht hat. Das ist einer der wesentlichen und gewünschten Unterschiede zum klassischen Projektmanagement, wo häufig nicht der beste Vorschlag gewinnt, sondern nur der Große Mufti -- egal, wie kompetent er ist oder nicht. > Am Ende ist jemand in der Verantwortung dass das Ding fertig > wird und tut was der Kunde erwartet und was man verkaufen kann. Und als > jemand der diese Verantwortung hat, will ich auch ansagen können was > läuft. Dafür gibt es bei vielen (den meisten?) agilen Methoden eigens eine Rolle, beispielsweise im SCRUM-Framework den sogenannten "Product Owner". Der legt ähnlich wie ein klassischer Projektleiter sogar etwas fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am Besten wissen. Das hat natürlich auch etwas mit Wertschätzung, Vertrauen und Verantwortung zu tun. Der PO muß seinen Kollegen vertrauen (und vertrauen können), daß sie dazu fähig sind, selbständig die beste Lösung für ein Problem finden und umsetzen, oder sich Unterstützung holen zu können -- und natürlich müssen die dann auch die Verantwortung dafür übernehmen. Tatsache ist und bleibt jedoch, daß starre und unflexible Hierarchien keinen Beitrag zur Lösung technischer Probleme leisten, und häufig stehen sie dabei sogar im Weg.
Ein T. schrieb: > Der legt ähnlich wie ein klassischer Projektleiter sogar etwas > fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen > Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und > verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am > Besten wissen. Und genau dafür brauchst du im Team TOP Leute. Und die hast du meist nicht. Weil man heute nur ein paar billige Inder hat, die nur machen was zu 100% irgendwo Step-by-Step beschrieben ist.
Cyblord -. schrieb: > Ein T. schrieb: >> Der legt ähnlich wie ein klassischer Projektleiter sogar etwas >> fest, nämlich was gemacht wird. Im Gegensatz zu einem klassischen >> Projektleiter schreibt er jedoch nicht vor, wie es gemacht wird, und >> verläßt sich anstelle dessen darauf, daß die Fachleute das selbst am >> Besten wissen. > > Und genau dafür brauchst du im Team TOP Leute. Und die hast du meist > nicht. Da habe ich bisher anscheinend das große Glück gehabt, immer mit entweder kompetenten und erfahrenen oder neu- und wissbegierigen Menschen arbeiten zu dürfen. > Weil man heute nur ein paar billige Inder hat, die nur machen was > zu 100% irgendwo Step-by-Step beschrieben ist. Das ist ein kulturelles Ding, sie wollen ihr Gesicht nicht verlieren, darum traut sich niemand, etwas anderes zu machen. Sogar wenn er weiß, daß es eine bessere Lösung gibt, wird ein Inder niemals seinem Vorgesetzten noch seiner Dokumentation widersprechen, nicht einmal verklausuliert.
Ein T. schrieb: > Bei agilen Projekten gewinnt halt (ok: im Idealfall), wer > den besten Vorschlag gemacht hat. Das ist einer der wesentlichen und > gewünschten Unterschiede zum klassischen Projektmanagement, wo häufig > nicht der beste Vorschlag gewinnt, sondern nur der Große Mufti Du zeichnest hier aber ein sehr einseitiges Bild. Es kommt am Ende darauf an, wer zum "Mufti" erhoben wurde. Das sollte ja immer derjenige sein, der die meiste Ahnung hat. Und dass sich "Ahnung" auf mehrere Personen verteilt und es deshalb keinen einzelnen geben kann, der etwas größeres auf die Beine stellt, sollte damit klar sein. Somit stimme ich der Aussage an anderer Stelle zu, dass es keinen einzigen Product Owner geben kann. Ob bei Scrum jetzt damit automatisch der gewinnt, der - wie du annimmst - > den besten Vorschlag gemacht hat ist damit aber noch nicht sicher gestellt! Der Effekt solcher Gruppenentscheidungen ist nämlich, dass immer das akzeptiert wird, was von der Mehrheit verstanden wird. Wenn ein einzelner einen genialen Vorschlag macht, der über dem Level ist, das die Mehrheit noch versteht, kommt er eben nicht durch! Es ist daher nötig, dass die Gruppe nicht über jeden Krümel abstimmt, sondern in den meisten Fragen einfach auch den Entscheidungen des "Mufti" vertraut, wenn sich gezeigt hat, dass diese in der Regel gut sind. Hier steckt aber das Problem: Viele möchten ihre eigenen Vorschläge durchbringen. Wenn die nämlich halbwegs funktionieren, werden die Personen selber zum Mufti, weil die Alternative ja gar nicht getestet wurde. Also werden Seilschaften geschmiedet und heraus kommt, was die Seilschaft befürwortet. Andere Vorschlagsgeber werden schon in der Phase der Entscheidungsfindung weggebissen und unterdrückt! Man sieht solches Verhalten an den sehr mittelmäßigen Entscheidungen in technischen Gremien und politischen Gruppen, wo jeder um die Vormacht streitet, um voran zu kommen. Im Bundestag z.B. "gewinnt" bei Weitem nicht der beste Vorschlag! Es gewinnt der, der den Harbeck am Besten über den Tisch zieht. Und das ist bekannterweise der allseits als mittelmäßig eingestufte Lindner. Er kann sich mit Blockadehaltung und Verhandlungsdruck durchsetzen. Niemand akzeptiert seine Vorschläge, weil man ihn für schlau hält, oder er es gar ist! Das Bundestag ist damit ein Beispiel, dass Scrum in keinster Weise funktiniert.
Ein T. schrieb: > wird ein Inder niemals seinem Vorgesetzten noch seiner > Dokumentation widersprechen, nicht einmal verklausuliert. Das ist auch bei Chinesen sehr ähnlich. Das ist sogar auch in europäischen Ländern weit verbreitet. Es ist ein Beispiel dafür, das Gruppen nicht automatisch richtig arbeiten, wenn nicht jemand auch sicherstellt, dass dort gleichberechtigt agiert wird und jeder dazu angehalten wird, seine Meinung zu postulieren. Oft schiebt sich einer in den Vordergrund und die anderen kuschen. Sie kuschen natürlich sehr gerne auch freiwillig und aus Bequemlichkeit, weil sie so die Verantwortung abgeben, aber in der Gruppe prima mitschwimmen. Und sind wir mal ehrlich: Die Meisten standen schon vor der Entscheidung, derm Boss klarmachen zu müssen, dass er daneben liegt und haben es dann gelassen, um keinen Zoff zu bekommen oder das Vertrauen zu zerstören. Wenn jemand dann sehr dominant ist, drückt er die anderen ungewollte an die Wand. Im Ergebnis sieht man, dass diese dann irgendwann einmal LMAA fahren und sich denken, "ok dann machen wir es so und lassen ihn selber später drüber stolpern". Und ja, auch ich habe das schon gemacht! Lass den Ellenbogentypen reinrasseln.
Und was hat das jetzt alles mit Scrum zu tun? Das sind doch Probleme die es früher genau so schon gab
Ein T. schrieb: > Das ist ein kulturelles Ding, sie wollen ihr Gesicht nicht verlieren, > darum traut sich niemand, etwas anderes zu machen. Sogar wenn er weiß, > daß es eine bessere Lösung gibt, wird ein Inder niemals seinem > Vorgesetzten noch seiner Dokumentation widersprechen, nicht einmal > verklausuliert. Mit dieser Einstellung ist man freilich in internationalen Projekten eher fehl am Platz. Dokumente können Fehler enthalten, und tun dies auch sehr oft. Der richtige Weg ist dann eben diese Fehler zu korrigieren. Wer dazu nicht imstande oder nicht willens ist, der sollte vielleicht einfach einen anderen Job machen?
Um noch mal auf die Eingangsfrage zurückzukommen: Ich arbeite als Entwickler in einem bisher eher traditionell ausgerichteten Unternehmen. Jetzt wird auch bei uns Agile und Scrum vom neuen Management als neueste Sau durch´s Dorf getrieben. Manchmal fühle ich mich wie in einer Sekte! Für den BWLer ist halt alles, was er nicht messen kann, suspekt. Außerdem sind ihm solche Aufgaben suspekt, für die Spezialwissen erforderlich ist, die er nicht durchschaut und wo ihm Fachexperten vom Pferd erzählen können. Begeistert ist er hingegen, wenn er mit Phrasen glänzen kann und "Prozesse optimieren" kann. Die Idee von Scrum ist schnell beschrieben: Eine anspruchsvolle Aufgabe solange in kleinere Aufgäbchen zerlegen, bis sie auf einen Klebezettel passen, mit einer eindeutigen Arbeitsdauer und schließlich einem Fälligkeitsdatum versehen werden können und einem beliebigen und austauschbaren Teammitglied zugewiesen werden können. Dieses "Dumbing down" ist nichts Neues, geschweige denn Originelles. Frederick W. Taylor als Theoretiker und Ford als Unternehmer haben damit schon vor hundert Jahren die Fließbandfertigung möglich gemacht. Ein anderes Beispiel ist McDonalds, die Restaurants betreiben, ohne daß auch nur irgendeiner in einem solchen Laden kochen kann. Mit großem Gewinn habe ich mir die Werke von Gunter Dueck (Bücher und Vorträge auf Youtube) zu Gemüte geführt. Dueck beschreibt, wie Techies auf den Inhalt und die Qualität der Arbeit fokussiert sind, während BWLer rein auf die Prozesse schauen. Er vergleicht Informatiker von Wesen her mit Katzen und BWLer (bzw. Manager) mit Hunden und kommt zum Schluß, daß Agile von Managern eingesetzt wird als Versuch, den Katzen das Apportieren beizubringen. Was die Besprechungen betrifft, so ist es eine Herabsetzung der Entwickler, wenn sie täglich ihr Sprüchlein aufsagen müssen (und dann gar noch gelobt oder geschimpft werden von Leuten, die nicht einmal ein Grundverständnis von Softwareentwicklung haben). Ich zitiere unten aus einem Aufsatz, den ich mit großem Gewinn gelesen habe und wo das wunderbar beschrieben wird. Die implizite Annahme, daß jeder im Team austauschbar ist und im Prinzip jeder die Aufgäbchen gleich schnell und gut machen kann, ist eine Zumutung für jemanden, für den Exzellenz in seinem Bereich das persönliche Ziel ist. Es gilt auch das Parkinsonsche Gesetz der Trivialität: Je trivialer ein Thema ist, desto intensiver und länger die Diskussionen in den "Meetings". Inhaltliche Themen mit einem Mindestmaß an Anspruch wie Einsatz von Entwurfsmustern hingegen treffen auf dummes Schweigen. Und dann diese Anglismen, gewürzt mit deutschen Floskeln, was zu einer völlig stereotypen Audrucksweise führt. "Am Ende des Tages schauen wir uns alle in die Augen und kommen zum Ergebnis, daß wir mehr Commitment gebraucht hätten". Für das Management ist der Gewinn: Das Förderbändchen schnurrt immer und alles ist quantitativ darstellbar. Der Enzwickler entwickelt aber leider die "Scrum Fatigue", weil er gefühlt nur noch am Band steht und kleine Päckchen packt und gar nicht mehr dazu kommt, ein schwierigeres Thema systematisch zu analysieren und dann auf höherer logischer Ebene zu lösen. Das Management will gerne mehr "Velocity" (Story Points geteilt durch Zeit)? Können sie gerne haben, bekommen sie halt mehr Story Points. Gerne können die Techies und BWLer da Katz und Maus spielen! https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/ "Corporate Agile, losgelöst von der Beratungsumgebung, geht noch weiter und geht davon aus, dass die Ingenieure nicht schlau genug sind, um herauszufinden, was ihre internen "Kunden" wollen. Das bedeutet, dass die Arbeit in "User Stories" und "Iterationen" zerlegt wird, die der Arbeit oft das Gefühl nehmen, etwas erreicht zu haben, sowie jede Hoffnung, eine langfristige Vision für die Zukunft zu entwickeln. (...) Es ist bekannt, dass kreative Menschen ihre Kreativität verlieren, wenn sie aufgefordert werden, sich während der Arbeit zu erklären. Genauso verhält es sich 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 auf die Arbeit an atomisierten "User Stories" auf Feature-Ebene verwiesen und darf oft nicht an Verbesserungen arbeiten, die nicht mit kurzfristigen, unmittelbaren Geschäftsanforderungen in Verbindung gebracht werden können (oft von oben heraus). Diese fehlgeleitete, aber gängige Variante von Agile eliminiert das Konzept des Eigentums und behandelt Programmierer als austauschbare, kommerzialisierte Komponenten. (...) Unter Agile häufen sich technische Schulden an und werden nicht angegangen, weil die Geschäftsleute, die das Sagen haben, ein Problem erst sehen, wenn es viel zu spät oder zumindest zu teuer ist, um es zu beheben. Darüber hinaus werden einzelne Ingenieure allein aufgrund der Optik des aktuellen zweiwöchigen "Sprints" belohnt oder bestraft, was bedeutet, dass niemand fünf "Sprints" vorausschaut. Agile ist nur ein gedankenloser, kurzsichtiger "Sprint" nach dem anderen: kein Fortschritt, keine Verbesserung, nur ein Ticket nach dem anderen. (...) Ständige Überwachung der eigenen Arbeit deutet auf mangelndes Vertrauen und einen niedrigen sozialen Status hin, und die statussensibelsten Menschen (selbst wenn sie die besten Arbeiter 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 gerechtfertigt ist?), dann verlieren sie schnell die Motivation." Eine Arbeitsweise wie Scrum ist wahrscheinlich nur sinnvoll in kritischen Situationen, wo schnelles und abgestimmtes Handeln erforderlich ist, etwa bei kurz vor einem neuen Release.
A. B. schrieb: > Und was hat das jetzt alles mit Scrum zu tun? Das sind doch Probleme die > es früher genau so schon gab Es hat deshalb damit etwas zu tun, weil Scrum die bereits vorhandenen und funktionierenden Dinge in einem Prozess für sich vereinnahmt und sie als neu und Scrum-korelliert darstellt, während es die nicht funktionierenden Dinge, als alt, langsam und behäbig darstellt, die jetzt agil sein sollen.
Mark B. schrieb: > Wer dazu nicht imstande oder nicht willens ist, der sollte vielleicht > einfach einen anderen Job machen? Du darfst nicht vergessen, daß es viele Vorgesetzte gibt, die sich nichts sagen lassen wollen und dafür sorgen, dass diejenigen, die ihnen die Fehler vorrechnen, in die Ecke gedrängt werden und nicht hochkommen. Die braven Ja-Sager, die kritiklos und bedingungslos alles machen, was man ihnen sagt, sind da eher beliebt, weil diese Sorte dann oben bleibt und das Ruder in der Hand hält. Aus der Beobachtung kann man sagen, dass diese sich auch oft gegen genau formulierte Dokumente und Konzeptpapiere aussprechen, weil diese ihren Vorgehen, des spontanen Entscheidens widersprechen. Obendrein werden einmal als Vorgabe formulierte Dinge dann zum boomerang, wenn sich herausstellt, dass es ein komplizierter Weg war, der zu Mehrarbeit führte. Die Qualität der Vorgaben des Vorgesetzten wird dadurch nämlich meßbar, was ebenfalls nicht beliebt ist. Es kann damit ein großes Problem sein, wenn durch Scrum oder andere Arbeitstechniken das Team angehalten wird, Aufgaben zu planen und Lösungen zu dokumentieren, weil dann heraus kommt, dass man einen falschen Weg beschritten hat und offenbar wird, wer für die Entscheidungen verantwortlich ist. Da reicht es dann wenn klar ist, daß Müller und Meier für "links" entschieden hatten und Schulze überstimmten, der für "rechts" plädierte. Sollte sich dann zeigen, dass "rechts" besser gewesen wäre, geht aber niemand her und erhebt Schulze zum neuen primären Ideengeber, sondern man schliesst sich Müller und Meier an, die stabil stehen und unterstüzt sie darin, sich die Idee schön zu reden, Schulze als Quertreiber hinzustellen und sorgt sorgt som it dafür, dass Schulze rausgedrängt wird, oder er sich zurückhält.
Wie sagt der Lateiner: Es gibt keinen vom Management oktroyierten Prozess, der aus schlechten Entwicklern gute macht, aber viele Prozesse, die gute Entwickler demotivieren und frustrieren.
Gerhard O. schrieb: > Was ist eigentlich falsch mit den Methoden des letzten Jahrhundert? > > Planung, Lastenheft, Pflichtenheft, Ausarbeitung der Details, Überdenken > der Details... Garnichts. Wir deutschen Ingenieure waren ja eben deswegen so beliebt, weil wir so genau und präzise planen und denken konnten. Es ist halt nur nicht Hipp genug! Und: Weil immer mehr Nichtdeutsche in deutschen Firmen arbeiten, die das nicht kennen und nicht können, müssen die auch irgendwie organisiert werden. Obendrein bildet Deutschland ja auch nur noch bachler mit G8 aus, d.h. die jungen Entwickler kommen mit immer weniger Erfahrung in Firmen. Hinzukommen die, welche keine Hochschulweg beschritten haben und sehr abstrakt denken und mit Texten umgehen können. Es sind durch die Bildungsoffensiven sehr viele ohne ein Abi in die Entwicklunsabteilungen vorgerückt. Vor 20 Jahren war der Schwerpunkt noch auf lang und gut ausgebildeten Leuten, die an Text, und Planungsarbeit gewöhnt waren. Sie mussten genau arbeiten, weil viele Schritte lang und teuer waren, wenn man sie wiederholt hätte. Heute muss alles HopplaHopp gehen - Tempo geht vor Qualität. Da, wo Scrum herkommt, aus "meiner" Welt der Softwareenticklung, ist es besonders krass: Es wird alles nur noch schnell mit buildung blocks zusammengefuhrwerkt, mit Rust verknoddelt und virtualisiert gePythoned. Und dann wird andauernd eine verwanzte und ungetestete Software als Beta an den Kunden rausgehauen.
Ein T. schrieb: > Ach, beruflich entwickle ich jetzt seit über 30 Jahren Software, mal mit > und mal ohne agilen Methoden. Meine agilen Projekte waren bis auf wenige > Ausnahmen erfolgreicher in der Zielerreichung und trotzdem angenehmer > und entspannter. Solange nicht das gleiche Projekt von einer parallelen Gruppe in konventioneller Weise gelöst wurde, kann man keine Aussage treffen, wie SCRUm geholfen und sich niedergeschlagen hat. Softwareprojekte sind untereinander nicht zu vergleichen. ES sind oft kleine Details, die fehlen und die zu einem Fiasko führen. Es sind auch oft strategische Entscheidungen beteiligt, die von neuen Personen in der Leitung anders getroffen werden, die zu anderen Aufwänden führen. Der wichtigste Punkt ist, was an Grundstock in einem Paket schon da ist, wenn die Anforderungen für eine neue SW kommen und was davon verwendet werden soll. Das ist bei jedem Paket völlig anders, d.h. die Voraussetzungen entscheiden über den Erfolg. Scrum- oder nicht-Scrum lässt sich nur beurteilen, wenn 2 gleich große Teams an einer ähnlichen Aufgabe arbeiten, die von 0 beginnen und es somit nur vom Team abhängt, wie gut die Planung läuft und wie die error rate sich darstellt. Von der Qualität der Planung am Anfang hängt es ab, wie gut man hinterher liefern, in Betrieb nehmen und ändern kann. Mein PG hat das schon mal so gemacht und feststellen müssen, dass das SCRUM Team für die gleiche Maturity am Ende fast 20% mehr Mannstunden verbraten hat. Obwohl sie zeitweilig voraus waren. Als Ergebnis zeigte sich, dass eine gute Planung nicht ersetzt werden kann und sich am Ende auszahlt. Der PG hat als Folge den Scrum-Prozess vollständig aus der Firma entfernt. Die SW wird jetzt modular von System-Architekten geplant und linear aufgesetzt. Dann kommen die Selbständigen und Internen und setzen es paketweise um.
Grundsätzlich geht es ja in erster Linie einfach um Komplexitätsreduktion und verbesserte Kommunikation. Worüber wollen wir uns unterhalten? Ganz ähnliche Strategien kann man bei der Evaluation anwenden - wobei da aber ganz vorab grundlegendes Know How, Fleiß und Engagement bestimmender sind. Es (also die Planorientierung) ist ein Versuch, etwas mehr Objektivität und Wiederholbarkeit zu gewinnen und als ein solcher eigentlich ein netter Zusatz, bzw. ein Qualitätsgewinn. Schlecht ist, wenn gewissermaßen das Werkzeug und die Orientierung zum Ziel verkommt. Ein gutes Beispiel ist Emil Pagliarulo mit seiner "KISS" Orientierung. Manchmal reicht das eben nicht, und dann muss man mehr machen, etwas grundlegend anderes machen, selbst hinterfragen nicht vergessen - und innere Kündigung wirkt sich normalerweise auch nicht sonderlich positiv auf das Endergebnis aus. So ganz allein sind die Entwickler mit dem aktuellen Müllhaufen aber nicht, auch die Spiele- und Computerzeitschriften haben ihren (Jubel-) Beitrag dazu geleistet, dass die aktuelle Situation so ist, wie sie nach vielen Jahren sein muss. Viel Déjà-vu halt und kaum Kante -> Gähn. Glücklicherweise haben andere Entwickler die kognitive Kurve einigermaßen hinbekommen - wo man sich dann aber fragt, wie man das (Qualitätsmanagement) unterstützen kann. Eine Engine-Auswechslung z.B. für ES6 wäre schwierig, aber irgendwo auch ziemlich wichtig.
Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Wenn es jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war kein richtiger Sozialismus." Nun ist mir aufgefallen, dass vor 15 Jahren ein Buzzword sehr populär war, nun aber vollkommen verschwunden zu sein scheint: "prozessorientiertes Denken". Damals kam keine Anzeige für ITler ohne dieses Buzzword aus. Das war den BWLern offenbar sehr wichtig. Haben die nun Scrum entdeckt, um die Leute an der kurzen Leine zu führen? Auch bei uns in der Firma gibt es "Prozesse". So arbeitet die EDV-Service-Abteilung nur mit Ticket. Das Ticket-Tool ist unter aller Sau. Geholfen wird einem nur mäßig. Auf die Idee, Standardlösungen ins Intranet zu stellen, kommen die Leute nicht. Nun ist mir aufgefallen, dass dort Externe arbeiten. Ich weiß nicht, wer diese Leute dort stellt. Die brauchen die Tickets offenbar für die Rechnungslegung. Die würden mit proaktivem Vorgehen und Standardlösungen im Intranet ihr Wasser abgraben. Aber der Prozess ist ja schön ordentlich, auch wenn alle schimpfen, dass banalste IT-Probleme Wochen bis zur Lösung brauchen oder gar nicht abgearbeitet werden. Diese Konstruktion haben bestimmt die BWLer verzapft. Ich habe auch Kollegen im Hause, die gehen voll darin auf. Nun hat besagter EDV-Service vor einem Jahr den Drucker in unserem externen Standard nicht stabil zu laufen gekriegt. Der hat häufig Aufträge verschluckt. Ich nahm mich der Sache an, installierte einen Druckertreiber vom Hersteller und seitdem druckt es zuverlässig. Ich stellte eine Standardlösung für alle zur Verfügung, beschrieb das Problem. Wurde angemotzt: "Ticket schreiben und EDV richtig nerven." Ich habe aber keine Lust auf solche Spielchen. Auf die Idee, dass die Arbeit, durchgeführt nach bestem Wissen und Gewissen und mit Leidenschaft, dann am produktivsten sein könnte, auf die Idee kommen die Leute in den höheren Etagen offenbar nicht. Wäre ja zu einfach. Ich mache das schließlich und ich kann für mich reklamieren, mit mehreren guten Idee die Produktivität enorm vorangebracht zu haben. Ich kann jetzt leider nichts ins Detail gehen, aber bei der einen Idee dauerte die Umsetzung 30 min und es hatte sich schon am nächsten Tage für mich persönlich ammortisiert, weil es dumme, wiederkehrende, mauslastige und fehlerträchtige Arbeit unnötig machte. Das ist auch schon 13,5 Jahre her. (Es dankte mir keiner.) Es kam in vielen Projekten seitdem zur Anwendung.
Rudi R. schrieb: > Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird > immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Wenn es > jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich > entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war > kein richtiger Sozialismus." Vielleicht macht ihr Scrum aber wirklich nicht richtig? Ohne jetzt zu wissen, wie "richtig" da geht. Ansonsten ist das hier eh nur ein klassischer Rant-Beitrag ohne tiefergehende Verbindung zum Thema. Ich zitiere auch gerne meinen älteren Beitrag hier: Reinhard S. schrieb: > Rudi R. schrieb: >> ich bin ja eigentlich nur beratend dabei, >> (…) >> wenn nur diese dämlichen Besprechungen nicht wären > > Dämliche Besprechungen gibts auch außerhalb von Scrum und wenn du nur > beratend dabei bist ist sowas doch genau dein Jobprofil? Also lieber mal > die Position wechseln. > >> Nur geht mir >> Teamarbeit auf die Nerven, wo man nicht diskutieren kann, weil >> intellektuelle Gefälle so stark ist, dass ich gar nicht mehr zu manchen >> Leuten durchdringen kann. > > Was hat das mit Scrum zu tun? > > Klassischer (...)Troll.
Mit Scrum brauchst du 3x mehr Personal. Das ist also eine aktive Massnahme gegen Arbeitslosigkeit. Am Freitag noch arbeitslos, am Montag schon Scrum-Master und darf auf Entwicklerpersonal losgelassen werden, ist doch super. Schau dir mal die an, Scrum-masterin: https://www.tiktok.com/@thescrummastery/video/7326188606517775662 Dazu noch der Jiraverwalter, der Backorifficemanger, der Whiteboardcleaner, der Kanbanzettelverwalter, der Scrumkartenmischer,... Damit kann auch noch der nutzloseste Esser in Lohn und Brot gebracht werden, Politiker lieben es. Die Leute wissen ja selber dass sie überflüssig sind: https://www.reddit.com/r/scrum/comments/18kiudx/feel_useless_as_a_scrum_master/?tl=de
:
Bearbeitet durch User
Reinhard S. schrieb: > Vielleicht macht ihr Scrum aber wirklich nicht richtig? Unser mit 50 Jahren an Krebs verstorbener Christ hat auch nur nicht ausreichend viel gebetet. Wenn sie das täten, wüssten sie, dass es nicht 20% langer dauert sondern nie fertig wird, und dass nicht 50% in Palaver draufgeht, sondern jeder Mitarbeiter 90% damit verbringt, nach der Scrum-Kriterien möglichst gut da zu stehen und egal wird, was er wirklich schafft.
Viel Aufwand investieren die Gegner eines Frameworks, um zu erklären, warum es nicht geht. Und es wird lauter Zeug aus dem Ärmel gekramt, der wirklich in jedem Projekt auch auftritt. Und ehrlich, wenn Ihr zu blöd seid ein Daily auf zwei Tage pro Woche einzusparen, dann hat das nichts mit SCRUM oder AGIL zu tun, sondern mit Euer Unfähigkeit als Team oder Euch selber. Unreflektierter Mist wird ständig wiederholt und wird dadurch nicht besser. Wenn es einem nicht gefällt, ja dann lass es. Meine Güte - geht mir das Gejammer auf den Sack.
:
Bearbeitet durch User
Michael B. schrieb: > sondern jeder > Mitarbeiter 90% damit verbringt, nach der Scrum-Kriterien möglichst gut > da zu stehen und egal wird, was er wirklich schafft. Ob er nun versucht nach Scrum-Kriterien gut dazustehen oder nach anderen Kriterien ist doch egal. Was man wirklich schafft zählt eh am wenigsten, grad bei großen Firmen.
Uwe D. schrieb: > Und ehrlich, wenn Ihr zu blöd seid ein Daily auf zwei Tage pro Woche > einzusparen, Oh oh! Solche Abweichungen von der Regel bestraft SCRUM mit einem unausweichlichen Versagen. So steht es in den Büchern. Und so hat es der Consulter phrophezeit.
Martin K. schrieb: > Wir deutschen Ingenieure waren ja eben deswegen so beliebt, > weil wir so genau und präzise planen und denken konnten. Ok, hin und wieder stürzt dabei mal ein Stadtarchiv oder eine Brücke ein, und wir brauchen manchmal vierzehn Jahre für einen Flughafen. Aber immerhin haben wir deutschen Ingenieure alles genau und präzise geplant und gedacht -- nicht wie diese chinesischen Dummköpfe, die einen Flughafen in lediglich elf Monaten hinstellen, ohne jemals Pläne oder Gedanken darauf verschwendet zu haben. :-)
Reinhard S. schrieb: > Rudi R. schrieb: >> Wenn es >> jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich >> entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war >> kein richtiger Sozialismus." > > Vielleicht macht ihr Scrum aber wirklich nicht richtig? Naja, wie denn auch? Dein Vorredner schreibt ja selbst: Rudi R. schrieb: > Ich habe aber keine Lust auf solche Spielchen. Wie soll denn eine agile Methode denn funktionieren, wenn sich einige Leute verweigern, weil sie "keine Lust" darauf haben? Und in diesem Fall betrifft das ja sogar einen der wichtigsten Mitarbeiter des Unternehmens, der in dem "externen Standard" die Druckertreiber installiert...
Uwe D. schrieb: > Unreflektierter Mist wird ständig wiederholt und wird dadurch nicht > besser. Wenn es einem nicht gefällt, ja dann lass es. Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern das nur in anderen Teams beobachtet haben wollen.
Ein T. schrieb: > Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, > die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern > das nur in anderen Teams beobachtet haben wollen. Als Freiberufler kann man sich regelmässig den Scrum-Zoo anschauen.
Ein T. schrieb: > > Rudi R. schrieb: >> Ich habe aber keine Lust auf solche Spielchen. > > Wie soll denn eine agile Methode denn funktionieren, wenn sich einige > Leute verweigern, weil sie "keine Lust" darauf haben? Und in diesem Fall > betrifft das ja sogar einen der wichtigsten Mitarbeiter des > Unternehmens, der in dem "externen Standard" die Druckertreiber > installiert... Eben, weil es nicht gut nicht. Ich weiß nicht, was die Sache mit dem Druckertreiber soll? Da ging es um das Thema mit der Prozessorientierung. Ich habe mich einfach mal hingesetzt und das Problem endgültig gelöst. Sowas nennt man Engagement. Bin eben kein Beamter mit einer Scheißegalhaltung. Und das ist ja das Problem auch mit Scrum: Man erwartet sonst was von diesem Prozess, aber was auf der Strecke bleibt, ist das Lösen des Problems in der Sache. Es genügt eben nicht, einen Prozess zu haben, und jeder füllt seine Rolle im Prozess aus. Ich sehe Parallelen zu Industrialisierung, als man aus Profitgründen die Arbeitsschritte so aufteilte, das jeder nur noch drei Handgriffe zu beherrschen brauchte. Das hat natürlich den Vorteil, der Effizienzsteigerung und auch der Arbeitssicherheit, weil die Leute trainiert sind, genau das eine zu tun. Aber es führte auch zu einer Entfremdung von der Arbeit. Will man das jetzt bei Software auch? Softwareentwicklung ist Geistesarbeit und lässt sich nicht in solchen Happen aufteilen, wie Scrum es verspricht oder wie sich manche Leute das vorstellen. Softwarenentwicklung ist auch keine Fließbandarbeit. Ich komme mit dem zyklomatischen Entwicklungsmodell viel besser zurecht. Ist übrigens auch iterativ und inkrementell. Es ist aber ohne Ringelpitz mit Anfassen, ohne soziale Gruppentänze. Der gesunde Menschenverstand darf eben nie auf der Strecke bleiben. Ein T. schrieb: > Wobei das Beste ja noch ist, daß ausgerechnet jene am Lautesten jammern, > die ihren eigenen Aussagen zufolge gar nicht mit Scrum arbeiten, sondern > das nur in anderen Teams beobachtet haben wollen. Also ich war in der Scrum-Mühle und weil es nicht funktionierte, wird aktuell ein Scrum light gemacht. Auch grober Unfug, aber man geht pragmatisch ran. Scrum ist einfach Murks.
Oben im Text schrieben Leute etwas zu Kaizen und Lean Management. So einen Berater hatten wir auch schon in der Firma, der das etablieren wollte. Und dann gab es Leitsätze für Lean Management in der Softwareentwicklung. Da wurde tatsächlich ausgearbeitet: "Jeder Schritt in der Softwareentwicklung muss neue Funktionalität hinzufügen." Ich empfand das als Absage an Refaktoring, also dass jemand das Gestrüpp mal der beseitigt und der Code sauberer wird. Das war wider alle Erfahrung. Dieser Lean-Quatsch hatte sich nach wenigen Monaten erledigt. Das war vor 14 Jahren. Der Berater von damals hat immer noch seine Beratungsfirma, aber Kaizen/Lean scheint kein Thema mehr zu sein. Der hat aber noch mehrere andere Sachen, wie z. B. Softskill-Geschichten, Führungstraining, Teamtrainig.
Rudi R. schrieb: > Ich sehe Parallelen zu Industrialisierung, als man aus Profitgründen die > Arbeitsschritte so aufteilte, das jeder nur noch drei Handgriffe zu > beherrschen brauchte. Das hat natürlich den Vorteil, der > Effizienzsteigerung und auch der Arbeitssicherheit, weil die Leute > trainiert sind, genau das eine zu tun. Aber es führte auch zu einer > Entfremdung von der Arbeit. Will man das jetzt bei Software auch? > Softwareentwicklung ist Geistesarbeit und lässt sich nicht in solchen > Happen aufteilen, wie Scrum es verspricht oder wie sich manche Leute das > vorstellen. Softwarenentwicklung ist auch keine Fließbandarbeit. Aus der Sicht der Manager ist ein nicht-entfremdeter Arbeitsprozess absolut nichts erstrebenswertes. Nichts fürchten Unternehmer und Manager so sehr wie auf (bestimmte) Mitarbeiter existenziell angewiesen zu sein. Deshalb wird man immer danach streben, die Prozesse so weit zu standardisieren, daß die Mitarbeiter relativ leicht austauschbar sind. Und es ist eine traurige Tatsache, dass BWLer die Softwareentwicklung als Fließbandarbeit verstehen. Ihre Denk- und Rechenkünste sind von der Art "Vier Schreiner bauen 5 Regale in 3 Tagen. Wie viele Regale bauen acht Schreiner in 12 Tagen?" oder "Vier Entwickler machen 12 User Stories in 14 Tagen. Berechnen sie die Velocity". Daß ein fleißiger Dummkopf langfristig mehr Schaden anrichtet als 10 faule Dummköpfe, sehen sie nicht. Die unterschiedliche Denke von Managern und Techies ist tragisch, aber real, genauso wie die Unterschiede von Männern und Frauen in Beziehungen.
Joe schrieb: > Die unterschiedliche Denke von Managern und Techies ist tragisch, aber > real, genauso wie die Unterschiede von Männern und Frauen in > Beziehungen. So ist es. Ich habe auch vorhin Ihren ersten Beitrag nochmal durchgelesen (Wo Sie auf Taylorismus eingehen.) und wollte das noch mal loben. Ich habe in den letzten Wochen auch öfter mal darüber nachgedacht und kam zu dem Schluss, dass es unterschiedliche Wertesysteme sind, die BWLer und Techies unterscheiden. BWLern geht es um Status, Dienstwagen, Hiercharchien, wie viele Leute man unter sich. Techies wollen interessante Aufgabenstellungen und Probleme lösen. Die Arbeit an sich macht Spaß. Natürlich muss auch das Gehalt stimmen, aber die Identifikation mit der Arbeit und der Spaß daran, das sind wichtige Dinge. Die BWLer legen ja ständig ihre Wertmaßstäbe an die Techies an. Ich war mal in einem Asssessmentcenter für IT-ler. Ist nun 15 Jahre her. Die suchten Softwareentwickler, Informatiker. Das Assessmentcenter klopfte aber Selbstdarstellung, Spontaneität und solchen Käse ab, als würden sie einen Verkäufer oder Constultant suchen. Das läuft ja falsch in Deutschland, dass die BWLer (eigentlich nur Kulturfolger) allen anderen ihre Wertmaßstäbe aufzwingen und den Karren an die Wand fahren, weil sie vom Kerngeschäft keine Ahnung haben. Man kann ja in Deutschland nur schwer eine Fachkarriere machen, Spezialist werden. Wird nicht goutiert. Man braucht dann Leute unter sich. Das Fachwissen eines DB-Experten, der fast alle Stellschrauben in Oracle kennt, um das Optimum herauszuholen, wird nicht goutiert. Und wenn er plötzlich Personalverantwortung bekommen soll, um aufsteigen zu können, dann verträgt sich das mitunter mit der Persönlichkeit dieser Koryphäe nicht. Die Techies legen ja auch nicht ihre Wertmaßstäbe an die BWLer an, an irgendwelche Verkäufer, die geschickt den Kunden alles mögliche andrehen. Als Techie (häufig introvertiert) ist man sich bewusst, dass sie auf die anderen (häufig extrovertiert) angewiesen sind, und dass man sich ergänzen kann und muss. Das ist der Fraktion der BWLer nicht bewusst.
Rudi R. schrieb: > Der Berater von damals hat immer noch seine Beratungsfirma, aber > Kaizen/Lean scheint kein Thema mehr zu sein. Der hat aber noch mehrere > andere Sachen, wie z. B. Softskill-Geschichten, Führungstraining, > Teamtrainig. Der hätte früher Wunderelixir an naives Landvolk verkauft und wäre mit seinem Karren über die Jahr- und Bauernmärkte gezogen. Heute sind die Scrummaster, Berater, Trainer und können gerade mal unfallfrei den Rechner einschalten.
Rudi R. schrieb: > Das läuft ja falsch in Deutschland, dass die BWLer (eigentlich nur > Kulturfolger) allen anderen ihre Wertmaßstäbe aufzwingen und den Karren > an die Wand fahren, weil sie vom Kerngeschäft keine Ahnung haben. Die gute Nachricht bzw. der einzige Trost ist vielleicht, daß man als Techie mit Geschäftssinn und Verkaufstalent gute Chancen hat, reich zu werden. "Der Ingenieur ist das Kamel, auf dem der Kaufmann zum Erfolg reitet" Der Kern des Streits ist vielleicht, daß die Manager das Scrum als etwas begreifen bzw. als etwas entdeckt haben, mit dem man die Techies an die Kandare nehmen kann. Der Techie kann jetzt nicht mehr einfach vor sich hintüfteln, sondern wird eingespannt und ist mit Heatmaps, Charts etc. Meß- und beobachtbar. Überflüssig, zu erwähnen, daß Qualität und Kreativität dabei aus dem Fokus geraten.
Also ich werfe mal in die Runde, das SCRUM eigentlich recht hilfreich sein kann, innerhalb eines Unternehmens die Kommunikationsflüsse zu steuern. Richtig angewendet vorrausgesetzt, natürlich und mit Einarbeitungsaufwand verbunden und den richtigen Menschen, an den richtigen Positionen. Passt nicht für alle Typen von Projekten, aber SCRUM für zb Anwendungsentwicklung sollte auch nur ein Entwicklungsstrang sein.Vorentwicklung/Core Entwicklung, die NICHT nach SCRUM arbeitet(oder nur sehr begrenzt die Aktivittäten dokumentiert) und Basis-Frameworks und Architekturen bereitstellt ein anderer. Auch das wurde weiter oben recht treffend beschrieben. Mein Liebling zu den stetigen Änderungen in der Arbeitswelt: https://teamentwicklung-lab.de/forming-storming-norming-performing-1 Das Resumee: Ist nicht einfach Schritt zu halten in der Arbeitswelt, war's noch nie. Habe mich damit abgefunden, das in 20Jahren die Entwickler die Hände über dem Kopf zusammenschlagen, wenn die meinen Code sehen - "Wie konnte der nur..." Offtopic: Der neueste Scheiß ist OKR. Echt hot. Schlussendlich soll das ganze ja dazu dienen, die Ziele eines Unternehmens sichtbar zu machen und komplexe Abläufe zu vereinfachen. DIese großen Ziele werden dann von den Verantwortlichen herunter gebrochen und ausdefiniert. Streng hierarchisch sollte das funktionieren, einen guten Überblick über das Ganze zu bekommen, wenn jeder max. 3 Ziele ausformuliert. Das ist dann SCRUM in anders. Bin mal gespannt. PS: Squad Owner = Team Lead
:
Bearbeitet durch User
Franko S. schrieb: > Als Freiberufler kann man sich regelmässig den Scrum-Zoo anschauen. Alles gut, ich schaue mir derweil den Freiberufler-Zoo an.
Rudi R. schrieb: > Ich weiß nicht, was die Sache mit dem Druckertreiber soll? Dann sind wir schon zu zweit. Ich weiß nämlich auch nicht, was die Sache mit dem Druckertreiber soll. Andererseits hatte ich gehofft, daß Du das wüßtest, schließlich hattest Du die Druckertreiber ja hier eingebracht. > Und das ist ja das Problem auch mit Scrum: Man erwartet sonst was von > diesem Prozess, aber was auf der Strecke bleibt, ist das Lösen des > Problems in der Sache. Es genügt eben nicht, einen Prozess zu haben, und > jeder füllt seine Rolle im Prozess aus. Ein Prozeß allein führt natürlich noch nicht zu einer Lösung. Aber es hatte und hat doch auch niemand behauptet, daß das so wäre. Außer Dir selbst sehe ich niemanden, der diese Erwartung geäußert hätte. Abgesehen davon helfen Prozesse, Wege zu den Lösungen zu organisieren. Das ist kein Alleinstellungsmerkmal agiler Methoden. Deren Alleinstellungsmerkmal ist nur, durch eine verbesserte Kommunikation flexibel auf Probleme und geänderte Rahmenbedingungen reagieren zu können. > und weil es nicht funktionierte, wird aktuell ein Scrum light gemacht. Ah, also beschwerst Du Dich in diesem Thread eigentlich gar nicht über Scrum, sondern über irgendeine seltsame Abart davon. Fassen wir das also mal zusammen: Du machst gar kein Scrum und beschwerst Dich auch gar nicht über Scrum, sondern machst und beschwerst Dich über irgendeine merkwürdige Abwandlung davon. Außerdem verweigerst Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams und beklagst Dich dann darüber, daß die Kollaboration und die Kommunikation mit den Teams nicht funktioniert.
Joe schrieb: > Aus der Sicht der Manager ist ein nicht-entfremdeter Arbeitsprozess > absolut nichts erstrebenswertes. Nichts fürchten Unternehmer und Manager > so sehr wie auf (bestimmte) Mitarbeiter existenziell angewiesen zu sein. Das ist auch absolut richtig so, obgleich es den Technikern manchmal nicht gefällt. Aber zu den Aufgaben eines Management gehört es, die langfristige Überlebens- und Handlungsfähigkeit des Unternehmens sicherzustellen. Eine Abhängigkeit des Unternehmens von einzelnen Mitarbeitern kann fatale Folgen haben, nicht nur für die wirtschaftliche Existenz des Unternehmens, sondern auch für die seiner Mitarbeiter.
Ein T. schrieb: > Ein Prozeß allein führt natürlich noch nicht zu einer Lösung. Aber es > hatte und hat doch auch niemand behauptet, daß das so wäre. Außer Dir > selbst sehe ich niemanden, der diese Erwartung geäußert hätte. Um mal auf dem gleichen "hohen" Argumentationsniveau zu bleiben: Es scheint mir so, als ob du der Einzige bist, der nicht verstanden hat, worauf Rudi hinaus will. Ein Prozess kann auch hinderlich sein beim Lösen von Problemen. Etwa wenn er Probleme falsch aufteilt und den falschen Leuten die falschen Aufgaben zuteilt. Das Scrum wird m.E. u.a. deswegen zurecht kritisiert, weil es Nicht-Techies bestimmen läßt, welche Aufgaben in welcher Reihenfolge bearbeitet werden sollen. In Folge dessen wird das technische Produkt viele Jahresringe von User Stories haben, aber nicht unbedingt optimal durchdacht sein. Eine typische Reaktion auf Kritik an Scrum erinnert in der Tat an die Reaktion auf Kritik am Sozialismus: Es sei ganz einfach nicht der wahre Sozialismus bzw. nicht das wahre Scrum. Dieser Fehlschluss ist bestens auch als False-Scotsman-Fallacy bekannt. Damit zu argumentieren wirkt nicht sehr intelligent. Auch dort, wo die deiner Meinung nach "merkwürdigen Abwandlungen" von Scrum existieren, wird wohl von den lokalen "Imams" fest behauptet werden, es handle sich um das wahre Scrum, nur die Mitarbeiter seien nicht reif dafür. In dem Laden etwa, wo ich arbeite, beschweren sich sehr viele über Scrum - aber derjenige, der das eingeführt hat, wird den Teufel tun, zu sagen, es sei nicht das "wahre" Scrum.
Ein T. schrieb: > Absolut richtig so, obgleich es den Technikern manchmal > nicht gefällt. Aber zu den Aufgaben eines Management gehört es, die > langfristige Überlebens- und Handlungsfähigkeit des Unternehmens > sicherzustellen. Eine Abhängigkeit des Unternehmens von einzelnen > Mitarbeitern kann fatale Folgen haben, nicht nur für die wirtschaftliche > Existenz des Unternehmens, sondern auch für die seiner Mitarbeiter. Genau das meinte ich. Das ist ja das Dilemma: Aus Sorge um die langfristige Überlebens- und Handlungsfähigkeit des Unternehmens treffen Manager Entscheidungen, die nicht in ihre Kernkompetenz gehören. Man will keine "Diven", sondern Leute, die tun, was man ihnen sagt.
Joe schrieb: > Um mal auf dem gleichen "hohen" Argumentationsniveau zu bleiben: Es > scheint mir so, als ob du der Einzige bist, der nicht verstanden hat, > worauf Rudi hinaus will. Ich verstehe möglicherweise besser als Du, worauf er hinauswill: alle doof außer dem Erleuchteten, also ihm. > Ein Prozess kann auch hinderlich sein beim Lösen von Problemen. Etwa > wenn er Probleme falsch aufteilt und den falschen Leuten die falschen > Aufgaben zuteilt. Das Scrum wird m.E. u.a. deswegen zurecht kritisiert, > weil es Nicht-Techies bestimmen läßt, welche Aufgaben in welcher > Reihenfolge bearbeitet werden sollen. Ach, agile Methoden hieven Nichttechniker in Entscheidungspositionen und klassische nicht? Wie absurd. Bist Du der Zweitaccount von Dieter D.?
Joe schrieb: > Genau das meinte ich. Das ist ja das Dilemma: Aus Sorge um die > langfristige Überlebens- und Handlungsfähigkeit des Unternehmens treffen > Manager Entscheidungen, die nicht in ihre Kernkompetenz gehören. Ihre Kernkompetenz ist es, die Überlebens- und Handlungsfähigkeiten des Unternehmens sicherzustellen. Daß das mitunter mit dem kollidiert, was die Techniker wollen, ist zwar bedauerlich, liegt aber in der Natur der Sache, insbesondere auch deswegen, weil das Management nicht nur andere Prioritäten, sondern oft auch einen wesentlich besseren Überblick über die Gesamtsituation hat (und ihn jedenfalls haben sollte). Gutes Manager sagen ihren Technikern allerdings, warum eine Entscheidung gegen sie getroffen werden mußte. > Man will keine "Diven", sondern Leute, die tun, was man ihnen sagt. Man will ohnehin keine Diven. Die zerstören nur erst die Stimmung, dann die Motivation, und am Ende das Team.
Ein T. schrieb: > Ach, agile Methoden hieven Nichttechniker in Entscheidungspositionen und > klassische nicht? Wie absurd. Bist Du der Zweitaccount von Dieter D.? Nein, das ist alles andere als absurd: Der Fokus eines nichttechnischen Produkt Owners auf unmittelbare "Benefits" ist eine systematische Schwäche des Ansatzes. Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir früher mal gesagt hat, daß du irrst? Gerne hingegen zitiere ich kurz aus einem Klassiker: "It has been a significant agile contribution to bring user stories to the forefront. (...) As a basis to development they lead to piecemeal systems, built to handle one function after the other without sufficient attention to the infrastructure." Bertrand Meyer, Agile!, Springer 2014 Ich erspare mir weitere Ausführungen, bevor ich nicht gesehen habe, daß eine Diskussion ohne Unterstellungen und ad hominem Angriffen möglich ist.
Ein T. schrieb: > das Management nicht nur andere > Prioritäten, sondern oft auch einen wesentlich besseren Überblick über > die Gesamtsituation hat (und ihn jedenfalls haben sollte) Ideal sind Kooperationen zwischen visionären Unternehmern und ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus braucht Diven und Kaufleute und Buchhalter.
Joe schrieb: > Ideal sind Kooperationen zwischen visionären Unternehmern und > ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus > braucht Diven und Kaufleute und Buchhalter. Paradebeispiel dafür ist ja gerade Apple mit Steve und Woz.
Cyblord -. schrieb: > Joe schrieb: >> Ideal sind Kooperationen zwischen visionären Unternehmern und >> ebensolchen Techies. Nicht alles ist schwarz oder weiß. Ein Opernhaus >> braucht Diven und Kaufleute und Buchhalter. > > Paradebeispiel dafür ist ja gerade Apple mit Steve und Woz. Jep. Das Traumpaar schlechthin.
Joe schrieb: > Nein, das ist alles andere als absurd: Der Fokus eines nichttechnischen > Produkt Owners auf unmittelbare "Benefits" ist eine systematische > Schwäche des Ansatzes. ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn dort Nichttechniker technische Entscheidungen treffen. Nichtsdestotrotz ist es im Falle von Scrum so, daß der Product Owner zwar so heißt, er aber über keine direkte Weisungskompetenz gegenüber dem Team verfügt. Deswegen ist und bleibt es Aufgabe des Teams, auf eine saubere Infrastruktur zu achten. > Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir > früher mal gesagt hat, daß du irrst? Das ist jemand hier im Forum, der häufig spät in Threads einsteigt, die er nicht gelesen hat, und dann durch absurde Behauptungen auffällt. Wenn Du dieses Forum häufiger nutzt, wirst Du ihm begegnen.
Ein T. schrieb: > ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn > dort Nichttechniker technische Entscheidungen treffen. Nichtsdestotrotz > ist es im Falle von Scrum so, daß der Product Owner zwar so heißt, er > aber über keine direkte Weisungskompetenz gegenüber dem Team verfügt. > Deswegen ist und bleibt es Aufgabe des Teams, auf eine saubere > Infrastruktur zu achten. Ich bin zugegebenermaßen etwas verwundert, weil mir nicht bekannt ist, daß technische Architekturentscheidungen bei "klassischen Ansätzen" ausdrücklich durch Nichttechniker gefällt werden sollen. Kannst Du da was zu zitieren? Zu Scrum habe ich nochmal gegoogelt: https://scrumguide.de/product-owner/ "Der Product Owner ist immer derjenige, der die Interessen aller Beteiligten in Product Backlog Items umwandelt und festlegt, welche davon am wichtigsten sind und daher vom Projektteam zuerst bearbeitet werden müssen. Sowohl das Unternehmen als auch die externen Stakeholder haben zu akzeptieren, dass er diese Entscheidungen trifft. Andernfalls bekommt er nicht genügend Raum, seine Aufgaben gut ausführen zu können." Mit anderen Worten: Der Product Owner entscheidet, was *bis wann* gemacht werden muß und das Entwicklerteam hat nur den Entscheidungsspielraum, wie es umgesetzt wird. Das ist ein Kerngedanke von Scrum - genauso habe ich es mir auch von den Scrum-Typen, die bei uns vor 1 Jahr im Haus rumliefen, bestätigen lassen. Und genau das ist die Krux. Hier liegt konkret eine Schwäche des agilen Ansatzes vor. Bertrand Meyer als Koryphäe für Software Engineering habe dazu ich ja weiter oben schon kurz zitiert. Man kann sich das mit einer Analogie veranschaulichen: Ein Product Owner, der wenig von Statik versteht, würde immer festlegen, was als nächstes am Haus gemacht werden müßte: Diese Woche die Einbauküche, damit die Hausherren schon mal ihr eigenes Essen kochen könnten, nächste Woche dann der Dachstuhl gezimmert, dann die Wasseranschlüsse gemacht, anschließend der Keller gegraben, dann wieder die Fliesen in der Küche usw. usw. >> Ich kenne auch keinen Dieter D. Ist das jemand hier im Forum, der dir >> früher mal gesagt hat, daß du irrst? > > Das ist jemand hier im Forum, der häufig spät in Threads einsteigt, die > er nicht gelesen hat, und dann durch absurde Behauptungen auffällt. Wenn > Du dieses Forum häufiger nutzt, wirst Du ihm begegnen. Nachdem sich die Threads hier auch gerne im Kreis drehen ist es relativ egal, wann man einsteigt. Oder? Absurde Behauptungen habe ich keine aufgestellt. Obwohl ich dir alles mögliche an den Kopf werfen könnte, brauche ich keine Polemik, sondern argumentiere sachlich. Meine Empfehlung wäre, nachzufragen, was der andere gemeint haben könnte, bevor man pöbelt. Insbesondere dann, wenn man selbst immer die "Kommunikation" und "soziale Kompetenz" so hochhält.
Joe schrieb: > Ein T. schrieb: >> ...und würde sich in nichts von klassischen Ansätzen unterscheiden, wenn >> dort Nichttechniker technische Entscheidungen treffen. > > Ich bin zugegebenermaßen etwas verwundert, weil mir nicht bekannt ist, > daß technische Architekturentscheidungen bei "klassischen Ansätzen" > ausdrücklich durch Nichttechniker gefällt werden sollen. Tatsächlich besteht dazu keine zwingende Notwendigkeit (wie das Wort "wenn" in meinem Satz andeutet), aber es kommt in der Praxis ausgesprochen häufig vor. Von allen Projektleitern, mit denen ich im Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen technischen Hintergrund und weitere 20% zwar einen solchen, aber in einem ganz anderen Bereich. > Zu Scrum habe ich nochmal gegoogelt: [...] > [...] genauso habe ich es mir auch von den Scrum-Typen, die bei > uns vor 1 Jahr im Haus rumliefen, bestätigen lassen. Du selbst verfügst also über keinerlei praktische Erfahrungen. > https://scrumguide.de/product-owner/ > "Der Product Owner ist immer derjenige, der die Interessen aller > Beteiligten in Product Backlog Items umwandelt und festlegt, welche > davon am wichtigsten sind und daher vom Projektteam zuerst bearbeitet > werden müssen. Sowohl das Unternehmen als auch die externen Stakeholder > haben zu akzeptieren, dass er diese Entscheidungen trifft. Andernfalls > bekommt er nicht genügend Raum, seine Aufgaben gut ausführen zu können." > > Mit anderen Worten: Der Product Owner entscheidet, was *bis wann* > gemacht werden muß Von "bis wann" steht dort allerdings nichts, und auch nichts davon, daß das Team diese Entscheidungen widerspruchslos akzeptieren müsse. Beides hast Du nur in die gegoogelten Texte hineininterpretiert. Du erwartest hoffentlich nicht, daß ich auf Strohmann-Argumente eingehe, daher nur soviel dazu: der Product Owner gehört selbst zu jenem Team, das gemeinsam entscheidet. Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu verstehen, sogar wenn sie es wollen. Praktische Erfahrung hilft aber meist schnell. > Nachdem sich die Threads hier auch gerne im Kreis drehen ist es relativ > egal, wann man einsteigt. Oder? Absurde Behauptungen habe ich keine > aufgestellt. Hoffentlich kannst Du akzeptieren, daß ich zu beiden Punkten eine andere Position vertrete. Aber so ist es ja leider oft, wenn Gegoogeltes auf die Erfahrungen aus der praktischen Realität trifft.
Joe schrieb: > Man kann sich das mit einer Analogie veranschaulichen: Ein Product > Owner, der wenig von Statik versteht, würde immer festlegen, was als > nächstes am Haus gemacht werden müßte: Diese Woche die Einbauküche, > damit die Hausherren schon mal ihr eigenes Essen kochen könnten, nächste > Woche dann der Dachstuhl gezimmert, dann die Wasseranschlüsse gemacht, > anschließend der Keller gegraben, dann wieder die Fliesen in der Küche > usw. usw. Die Erfahrung hat schon immer den Unterschied gemacht und es ist einfach Glückssache, mit wem man dann schlussendlich im Sandkasten landet. Ein T. schrieb: > Von allen Projektleitern, mit denen ich im > Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen > technischen Hintergrund und weitere 20% zwar einen solchen, aber in > einem ganz anderen Bereich. Sehe ich auch so. Ich finde deine durchgehende Argumentationskette bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt erkennen, der wirklich GEGEN SCRUM spricht. Was mich allerdings etwas stört, ist die Tatsache, das manche Leute sich manchmal so an einer Sache fest beißen und immer auf der eigenen Sichtweise zu dem Thema bestehen. Vermutlich werde ich dafür gelyncht, aber die einzige Differenz die ich beobachten kann zwischen euch zwei ist, das ihr vermutlich aus zwei verschiedenen Unternehmen und somit aus zwei verschiedenen Arbeitswelten kommt. Wieso kann nicht das eine neben dem anderen existieren? SCRUM ist sicherlich nicht das Allheilmittel und passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut geeignet ist und die angwendeten Methoden sinnvoll sind. Geistige Flexibilität ist das, was einen gesunden Menschenverstand ausmacht. Wenn es mir nicht in einem Unternehmen gefällt, wie ich meine Arbeitskraft einbringen kann,dann suche ich mir halt ein Unternehmen wo es mir gut geht. So einfach ist das. Eine Meinung zum Thema SCRUM haben heißt ja nicht, das man sich für das LIcht oder die Dunkelheit entscheiden muss. Wir sind hier nicht in der Kirche. PS. Eine beschissene Architektur können noch so ausgefeilte Methoden nicht kompensieren.
:
Bearbeitet durch User
Ein T. schrieb: > Von "bis wann" steht dort allerdings nichts, und auch nichts davon, daß > das Team diese Entscheidungen widerspruchslos akzeptieren müsse. Beides > hast Du nur in die gegoogelten Texte hineininterpretiert. Du erwartest > hoffentlich nicht, daß ich auf Strohmann-Argumente eingehe, daher nur > soviel dazu: der Product Owner gehört selbst zu jenem Team, das > gemeinsam entscheidet. Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Eine Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und Architekturthemen hin zu "Features" und "Benefits". Und ein Kernmerkmal von Scrum ist die Trennung bestimmter Rollen (auch wenn dann doch alle irgendwie zusammen gehören und ein Team sind). Das ist unzählige Male beschrieben worden. > Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten > Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu > verstehen, sogar wenn sie es wollen. Praktische Erfahrung hilft aber > meist schnell. Praktische Erfahrung ist immer sehr subjektiv und der Satz mit den hierarchisch sozialisierten Menschen ist eine Generalisierung von der Art "Nach meiner Erfahrung aus 5 Ehen nach tendieren Frauen dazu, ..." oder "Als Weltgereister sage ich: Dem Asiaten fällt es mitunter schwer, ...". Was soll man auf solche Einlassungen antworten? Wir reden hier perfekt aneinander vorbei. Ich versuche, den Ansatz durch Studium der theoretischen Beschreibungen zu verstehen - und Du kommst daher in der Art "Da mag vielleicht in der Theorie nicht funktionieren, aber in meiner erlebten Praxis schon". Es gibt genug andere Erfahrungen, die in eine anderen Richtung gehen, und da wird es schon interessant, wenn man sich die Theorie anschaut. Da bleibt der Vergleich mit einer Religion nicht weit. Man studiert hier vielleicht die kanonischen Texte, um zu verstehen. Konfrontiert mit Aussagen aus solchen Texten heißt es dann vom Adepten "Sie dürfen die Texte nicht wörtlich nehmen".
Joe J. schrieb: >SCRUM ist sicherlich nicht das Allheilmittel und > passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges > SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut > geeignet ist und die angwendeten Methoden sinnvoll sind. So wie es da steht, kann ich es natürlich nur unterschreiben. Mein "Beef" mit Scrum geht in die Richtung, daß es gerne als Allheilmittel verschrieben wird, von Managern aufoktroyiert wird und als System verwendet wird, einen kreativen und komplizierten Prozess wie Softwareentwicklung in eine Dauerhektik von kleinen Sprints zu verwandeln. Gunter Dueck vergleicht gerne Manager mit Hunden (Herdentiere und gehorsam) und Techies mit Katzen (Einzelgänger und eigenwillig). Er beschreibt Agile aus einen Versuch der Hunde, den Katzen das Apportieren beizubringen, bzw. als Versuch der BWLer, den Ingenieuren ihre Methoden aufzuzwingen.
Uwe D. schrieb: > Und ehrlich, wenn Ihr zu blöd seid ein Daily auf > zwei Tage pro Woche einzusparen, Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur ihre reine Nettozeit, sondern auch vor- und Nachbereitung und daran hängt es, um die ausgetauschten Infos für andere nutzbar sind, oder nicht und ob das, was man von anderen hört, genutzt werden kann, oder nicht. Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau verschiebt. Die anderen sehen dabei zu, haben aber nichts davon, da sie mit diesen Aufgaben nichts zu tun haben. Am Ende haben 7 Leute 3min berichtet, wo sie stehen und 18 min gewartet. Mit Start Stopp sind dann 20min weg, die man nicht mal so eben wieder reinholt. Wenn dann noch ein paar inhaltliche Fragen geklärt werden, hast du wieder den Fall, dass maximal die Hälfte etwas beitragen kann, während die andere lauscht. Und dann bläht das richtig auf. Diese Meetings laufen sehr oft wie ein Multiprozessorsystem mit 8 Teilnehmern, die abwechselnd einen einzigen Bus belegen, während alle anderen idle sind und Zeit verbraten. Zeit, die man besser nutzen könnte. Der einzige, der etwas davon hat, ist der Projektleiter, der schauen kann, ob die Jungs noch on track sind. Das aber könnte er auch einmal die Woche. Ich halte es daher für zweckmäßiger, dass nur diejenigen an solchen Meetings teilnehmen, die wirklich etwas beizutragen haben oder Entscheidungen treffen müssen, wofür sie andere benötigen. Man kann, wenn man unbedingt den Stand des anderen benötigt, auch selber aktiv ins board schauen und den Stand der Aufgaben ansehen, ohne dass da andere mit geblockt werden. Das gleiche gilt für Infos: Die verteilt man proaktiv in dem Moment, wo sie anfallen zielgerichtet an die 2 die es brauchen und nicht erst an alle und auch nicht erst am nächsten Tag. Auch eine Entscheidung schiebe ich nicht auf den nächsten Tag, wenn ich sie mit einer anderen Person zusammen fällen kann. Es muss nicht jeder zu jedem Zeitpunkt alles mitbekommen! Das ist nur dann nötig, wenn wirklich eine sehr kleine Gruppe an einer größeren Aufgabe dran ist und es viele Fragen und Schnittstellen zwischen den Bearbeitern gibt. Der klassische Fall ist eben eine Gruppe von Programmiereren die ein Paket entwickeln. Für alles andere taugt SCRUM einfach nicht.
Joe J. schrieb: > Sehe ich auch so. Ich finde deine durchgehende Argumentationskette > bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt > erkennen, der wirklich GEGEN SCRUM spricht. Vielen Dank für die Blumen! :-) > Was mich allerdings etwas stört, ist die Tatsache, das manche Leute sich > manchmal so an einer Sache fest beißen und immer auf der eigenen > Sichtweise zu dem Thema bestehen. Vermutlich werde ich dafür gelyncht, > aber die einzige Differenz die ich beobachten kann zwischen euch zwei > ist, das ihr vermutlich aus zwei verschiedenen Unternehmen und somit aus > zwei verschiedenen Arbeitswelten kommt. Ich sehe keinerlei Veranlassung für eine Lynchjustiz, denn mein Eindruck ist das ebenfalls. Allerdings komme ich aus einem... äh, "hybriden" Unternehmen, das heißt, daß wir uns an der Arbeitsweise unserer Kunden orientieren. Darum verwenden wir bei internen Projekten Scrum. Bei Projekten mit direktem Bezug zum Kunden machen wir das, was der Kunde bevorzugt, und je nach Kunde ist es dann eben ein klassischer oder ein agiler Ansatz, in diesem Falle fast immer Scrum. Da es dabei aber immer um dasselbe Kernthema geht -- Betrugsprävention in Echtzeit -- ergibt sich für uns eine recht gute Übersicht, was besser funktioniert, und unsere Erfahrung ist, daß agile Methoden meistens besser funktionieren. > PS. Eine beschissene Architektur können noch so ausgefeilte Methoden > nicht kompensieren. Das "meistens" steht dort aus einem bestimmten Grund, denn gegen Stinker im Projekt helfen Methoden des Projektmanagament leider ebenso wenig wie gegen überhöhte Erwartungen und andere Torpedos, und ebensowenig natürlich gegen verhunzte Architekturen oder ähnliche Probleme. Allerdings ist es agil nach meiner Erfahrung viel häufiger möglich, verhunzte Teilaspekte zu korrigieren. In klassischen Projekten stemmt sich mitunter ein Projektleiter dagegen, weil er die Notwendigkeit als weniger akut bewertet, er den Druck seiner Vorgesetzten zu Fertigwerden bekommt und ihn weitergibt. Wenn ein ganzes Team dahinter steht und erklärt, daß der Umbau jetzt nötig sei, hat das oft eine viel überzeugendere Wirkung auf Vorgesetzte und Kunden als wenn diese undankbare Aufgabe einem einzelnen Projektleiter zufällt.
Joe schrieb: > Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Das Team legt das fest, und der PO ist Teil des Teams. > Eine > Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und > Architekturthemen hin zu "Features" und "Benefits". Und ein Kernmerkmal > von Scrum ist die Trennung bestimmter Rollen (auch wenn dann doch alle > irgendwie zusammen gehören und ein Team sind). Das ist unzählige Male > beschrieben worden. Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. Darüber hinaus betrifft das nicht nur agile Methoden, denn in klassischen Projekten hängen Gedeih und Verderb primär an wenigen Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und Erfahrungen aller Teammitglieder zu nutzen. Selbstverständlich klappt das nicht immer, aber das tun klassische Projekte bekanntlich auch nicht. Ein Grund für die Entwicklung der agilen Methoden war ja schließlich, daß damals je nach Studie 65-75 Prozent der Projekte an ihren Zeit- und / oder Budgetgrenzen gescheitert waren. > Wir reden hier perfekt aneinander vorbei. Ich versuche, den Ansatz durch > Studium der theoretischen Beschreibungen zu verstehen Die meisten der theoretischen Beschreibungen, die ich bisher gehört oder gelesen habe, bestehen im Wesentlichen aus Bullshit-Bingo. Das ist es, was ich meine: ob, wie und wie gut agile Methoden in der Praxis funktionieren, stellt sich erst in der Praxis heraus. Leider lassen sich diese Methoden darum ohne praktische Erfahrungen kaum bis gar nicht seriös beurteilen. Im Wesentlichen ist die Nummer ziemlich einfach: es geht darum, durch eine formalisierte Kommunikation den Informationsfluß und die Zusammenarbeit im Projekt zu optimieren und die Erfahrungen aller Beteiligten zu nutzen. Und ganz unter uns: ich sitze lieber in ein paar gefühlt unnützen Meetings als kurz vor der Ziellinie eines Projekts feststellen zu müssen, daß irgendwie eine wichtige Information verloren gegangen ist und jetzt schnellstmöglich noch eingearbeitet werden muß.
Ein T. schrieb: > Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei > klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. Das ist natürlich richtig - aber auch eine Tautologie. > Darüber hinaus betrifft das nicht nur agile Methoden, denn in > klassischen Projekten hängen Gedeih und Verderb primär an wenigen > Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und > Erfahrungen aller Teammitglieder zu nutzen. Das habe ich wiederum anders erlebt in meinem kurzen Scrum-Leben. Es gibt erfahrerene ITler und weniger Erfahrene. Und leider gibt es keine Arithmetik in der Art "drei Juniors == 1 Senior". Der Kollege, der den Thread aufgemacht hat, hat sich beklagt, daß in den Meetings alle mögliche Betriebsamkeit herrscht, aber wenn er dann einem systematischen Vorschlag macht, etwa den Einsatz bestimmter Entwurfsmuster, dann wird abgepfiffen, weil die eine Hälfte nichts davon versteht und die andere Hälfte gleich in´s nächste Meeting muß. Ähnliche Erfahrungen habe ich auch gemacht. Auf der einen Seite muß jeder zu jedem Ticket in Daily sein Sprüchlein aufsagen (und dabei die anderen langweilen), aber wenn man ein bißchen tiefer geht, dann wird gleich abgepfiffen. "Das sprengt hier den Rahmen. Wenn, dann lade zu einem extra Meeting dazu sein" "So wie unsere Terminkalender sind, geht da frühestens übernächste Woche was". Ähnlich beim Planungspoker: Man soll aus dem Stegreif den Umfang einer bestimmten User-Story benennen. Da komme ich mir vor wie bei einer Schnellversteigerung. Wenn einer eine abweichende Meinung hat, und diese genau begründet, dann, s.o., wird auch abgepfiffen. Was mir abgeht, ist, daß man mal sich einen Tag zu zweit oder dritt in ein Büro zurückzieht und systematisch entwirft. Ich bin selbst jenseits der 50 und Dipl.Inf, könnte also mit dem einen oder anderen Junioren fachsimpeln und dann etwas richtig gutes entwerfen. > Die meisten der theoretischen Beschreibungen, die ich bisher gehört oder > gelesen habe, bestehen im Wesentlichen aus Bullshit-Bingo. Ich habe mir das Buch Agile! von Bertrand Meyer kommen lassen und lese es gerade. Ein fundierteres Werk zu dem Thema scheint es nicht zu geben. Mit Google findet man dann auch, was man als kanonische Skripten bezeichnen könnte, also vielleicht Beschreibungen von Schwaber/Sutherland persönlich. Dann bleiben noch unzählige Fundstellen und Homepages von Beratungsfirmen, also der ganze agile Wirtschaftsraum. Freilich ist das Bullshit-Bingo, habe ich ja weiter oben schon mal angemerkt, daß solche Berater-Leute eine völlig stereotypische Sprechweise haben und manche davon haben mir ehrlich gesagt wie gehirngewaschen gewirkt. Können wir uns darauf einigen, daß Scrum in bestimmten Konstellationen eine gute Sache sein kann: Gutes Team, Aufgaben, die voneinander abhängig sind, die Chance von Junioren, sich regelmäßig Unterstützung abholen zu können. In anderen Situationen ist es Sand im Getriebe: Schwierige Themen, die parallel eingekippt werden, Aufgaben, die jeder in einem Team von Seniors am besten eigenständig lösen kann, und dann nur einmal vorstellen braucht. Insgesamt halte ich Scrum für einen ungeeigneten Weg, um mit der Arbeitsverdichtung umzugehen. "Operative Hektik ersetzt geistige Windstille" fällt mir dazu ein. Und dann noch einer aus dem Agile!-Buch: "What is good, is not new, and what is new, is not good".
Joe schrieb: > Joe J. schrieb: >>SCRUM ist sicherlich nicht das Allheilmittel und >> passt nicht für alle Projekttypen(Ja, ja wir machen dann kein richtiges >> SCRUM, schon klar). Genauso gibt es eben Projekte, wofür SCRUM gut >> geeignet ist und die angwendeten Methoden sinnvoll sind. > > So wie es da steht, kann ich es natürlich nur unterschreiben. > > Mein "Beef" mit Scrum geht in die Richtung, daß es gerne als > Allheilmittel verschrieben wird, Dann ist Dein Problem also nicht Scrum, sondern die Werbung dafür. Werbung sagt aber eher wenig über die Nützlichkeit eines Produktes. > von Managern aufoktroyiert wird Vor dem Hintergrund, daß im klassischen Projektmanagement jedem Projekt ein eigener Manager aufoktroyiert wird, ist das ein besonders lustiger Einwand. > und als > System verwendet wird, einen kreativen und komplizierten Prozess wie > Softwareentwicklung in eine Dauerhektik von kleinen Sprints zu > verwandeln. Ganz im Gegenteil wird der Prozeß kreativer und oft sogar einfacher, wenn die Kenntnisse und Erfahrungen der Beteiligten kombiniert werden. Die Sprints sind auch keineswegs hektisch, sondern nur Zeiträume bis zu Punkten, an denen der jeweils aktuelle Stand der Beteiligten betrachtet und koordiniert wird. Kommst Du wie geplant voran? Haben sich unerwartete Probleme aufgetan? Kannst Du mir helfen, oder ich Dir? Im Prinzip geht es dabei um ähnliche Themen wie die, die klassischerweise der Projektleiter bearbeitet, nur daß die bei agilen Methoden eben gemeinsam angegangen werden.
Ein T. schrieb: > Dann ist Dein Problem also nicht Scrum, sondern die Werbung dafür. > Werbung sagt aber eher wenig über die Nützlichkeit eines Produktes. Das Aufoktroyierte ist das Schlimme. So wie wenn die Dame des Hauses sich bunte Pillen aufschwätzen lässt und von der ganzen Familie verlangt, diese regelmäßig und in großen Mengen einzunehmen.
J. S. schrieb: > Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur > ihre reine Nettozeit, sondern auch vor- und Nachbereitung Huch... > Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master > den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau > verschiebt. ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui.
Joe schrieb: > Ähnliche Erfahrungen habe ich auch gemacht. Auf der einen Seite muß > jeder zu jedem Ticket in Daily sein Sprüchlein aufsagen Es scheinen merkwürdige Vorgehensweisen als "Scrum" bezeichnet zu werden. > Was mir abgeht, ist, daß man mal sich einen Tag zu zweit oder dritt in > ein Büro zurückzieht und systematisch entwirft. Ich bin selbst jenseits > der 50 und Dipl.Inf, könnte also mit dem einen oder anderen Junioren > fachsimpeln und dann etwas richtig gutes entwerfen. Auch in agilen Projekten spricht nichts dagegen, so etwas zu machen. Ich bin übrigens auch über 50 und mache das ziemlich oft. Für Wissensvermittlung und detaillierte Planungen sind die Daily Standups nicht gedacht.
Ein T. schrieb: > Es scheinen merkwürdige Vorgehensweisen als "Scrum" bezeichnet zu > werden. Real existierendes Scrum halt. Eingeführt von realen zertifizierten Scrum***ioten, die saftige Rechnungen schreiben. Wobei wir wieder bei der Frage wären, was Scrum eigentlich ist. *Was kann nicht weglassen, ohne daß es dann kein Scrum mehr ist?* Solange das nicht genau definiert ist, wird uns die No-true-Scotsman-fallacy immer einholen.
Joe schrieb: > Real existierendes Scrum halt. Eingeführt von realen zertifizierten > Scrum***ioten, die saftige Rechnungen schreiben. Dabei ärgert mich nur dass ich selbst nicht so einer bin.
Joe schrieb: > Das Aufoktroyierte ist das Schlimme. Und ein nicht weniger aufoktroyierter Projektleiter, der allen Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger schlimm?
Ein T. schrieb: > Dann sind wir schon zu zweit. Ich weiß nämlich auch nicht, was die Sache > mit dem Druckertreiber soll. Andererseits hatte ich gehofft, daß Du das > wüßtest, schließlich hattest Du die Druckertreiber ja hier eingebracht. Es geht um Ihren Angriff ad hominem in dieser Sache. Die Geschichte mit dem Druckertreiber zeigt eine Problemlösung ohne viel Allüren. Da Sie sich abschätzig äußerten, muss ich davon ausgehen, dass Sie die Nase etwas höher tragen und dies als minderwertige Arbeit ansehen. Was halten Sie eigentlich von Reinigungskräften? Joe J. schrieb: > Ein T. schrieb: >> Von allen Projektleitern, mit denen ich im >> Laufe der Jahre zusammengearbeitet habe, hatten geschätzt 60% keinen >> technischen Hintergrund und weitere 20% zwar einen solchen, aber in >> einem ganz anderen Bereich. > > Sehe ich auch so. Ich finde deine durchgehende Argumentationskette > bisher am schlüssigsten und ich konnte bisher tatsächlich keinen Punkt > erkennen, der wirklich GEGEN SCRUM spricht. Als Projektleiter ist man zwischen den Fronten und dazu muss man kein Techniker sein. Die Persönlichkeitsstruktur vieler MINTler würde dazu auch gar nicht passen, weil die ja fokussiert arbeiten müssen. MINTler sind in der Regel introvertiert, Projektleiter extrovertiert. Ein kluger Projektleiter schaufelt seinen MINTlern die entsprechenden Freiräume für Problemlösungen ein, hält nicht ständig Meetings ab. Softwareentwickler müssen arbeiten können. Meine Scrum-Erfahrungen waren überwiegend negativ, weil vieles nervte. Ein T. schrieb: > Ganz im Gegenteil wird der Prozeß kreativer und oft sogar einfacher, > wenn die Kenntnisse und Erfahrungen der Beteiligten kombiniert werden. > Die Sprints sind auch keineswegs hektisch, sondern nur Zeiträume bis zu > Punkten, an denen der jeweils aktuelle Stand der Beteiligten betrachtet > und koordiniert wird. Kommst Du wie geplant voran? Haben sich > unerwartete Probleme aufgetan? Kannst Du mir helfen, oder ich Dir? Im > Prinzip geht es dabei um ähnliche Themen wie die, die klassischerweise > der Projektleiter bearbeitet, nur daß die bei agilen Methoden eben > gemeinsam angegangen werden. Was ich erlebte, war eher die Dauerhektik. Scrum ist nicht Voraussetzung für kooperatives Arbeiten und auch nicht förderlich. Kooperatives Arbeiten hängt von den Personen ab, von der Unternehmenskultur. Bei uns in der Firma helfen sich die Leute ständig. Kreativität habe ich im Scrum-Prozess wenig bis gar nicht erlebt. Die meisten waren darauf konditioniert, ihr Sprintziel zu erreichen. Für grundsätzliches Nachdenken und Fachsimpeln war keine Zeit. Ich habe auch schon erlebt, wie die Scrum-Masterin ein "Swarming" einberief, und dann konnte alle Entwickler an einem Freitagnachmittag bei jemanden auf den Bildschirm schauen und sie sollten ein Problem lösen. Eine extrem teure Angelegenheit. Und das war künstlich hervorgerufen, weil das Sprintende nahte. Warum nicht einfach unfertiges Committen? Habe ich im Projekt öfter angemahnt: Pusht den Kram, dass es jeder hat. Dann kann jeder, der will, im Source-Code wühlen und den Fehler beheben, eine Erklärung geben, warum es falsch war Es ist doch vollkommener Unfug mit drei, vier Entwicklern gemeinsam auf Source-Code zu schauen und der Herr über Maus u. Tastatur springt ständig erratisch hin und her und ein anderer quatscht ständig rein. Joe schrieb: > Der P.O. legt u.a. auch die zeitliche Prio von Aufgaben fest. Eine > Konsequenz davon ist eine Tendenz zur Fokussierung weg von Domänen- und > Architekturthemen hin zu "Features" und "Benefits". Gut beschrieben und das beschreibt ungefähr das, was ich in dem Projekt erleben durfte, das mich veranlasste, diese Diskussion zu starten. Da griffen die Entwickler gerade das, was gerade genehm war. Für grundsätzliche Dinge war keine Zeit. Für Bug fixing und Refaktorieren auch nicht. Das Projektteam komplett abgelöst. Ich war ja später hinzugekommen und meine Meldung, dass das mächtig scheitern würde, veranlasste, dass es heute andere Leute machen und ich bin dabei. Wir haben heute zwar Sprints, aber kein SCRUM. Einige würden sagen: "Scrum extra light." Ich würde sagen: Es ist Entwicklung mit gesunden Menschenverstand. Die Scrum-Masterin hat übrigens das Weite gesucht. Ein T. schrieb: > Das hängt vom Team ab, dessen Zusammenstellung -- genau wie bei > klassischen Ansätzen auch -- wesentlich für den Erfolg des Projekts ist. > Darüber hinaus betrifft das nicht nur agile Methoden, denn in > klassischen Projekten hängen Gedeih und Verderb primär an wenigen > Einzelpersonen. Agile Projekte dagegen versuchen, die Kenntnisse und > Erfahrungen aller Teammitglieder zu nutzen. Selbstverständlich klappt > das nicht immer, aber das tun klassische Projekte bekanntlich auch > nicht. Ein Grund für die Entwicklung der agilen Methoden war ja > schließlich, daß damals je nach Studie 65-75 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert waren. Es hängt sowohl in agilen als auch in klassischen Ansetzen von den Leuten ab. Und Scrum ist auch nicht einzige agile Modell. Was das Reißen von Zeit- und Budgetgrenzen angeht, da dürfte sich heute nicht viel verbessert haben. Ein T. schrieb: > Auch in agilen Projekten spricht nichts dagegen, so etwas zu machen. Ich > bin übrigens auch über 50 und mache das ziemlich oft. Für > Wissensvermittlung und detaillierte Planungen sind die Daily Standups > nicht gedacht. Ich spricht grundsätzlich nichts dagegen, aber meiner Erfahrung konditioniert Scrum die Entwickler, schnell mal irgendwelchen Pfusch abzuliefern, weil das Sprintende naht. Ich bin ja sogar der Meinung, dass es vielen Entwicklern gut täte, Kolloquien abzuhalten. Es kann doch nicht sein, dass Entwickler durch die Gegend laufen, die nicht wissen, was die Entwurfsmuster Adapter, Beobachter und Dekorierer sind. Es sollten ständig solche Thematiken in angenehmer Atmosphäre behandelt werden. Aber dann kommt die BWLer-Fraktion und meckert, weil das unproduktive Stunden seien. Ein T. schrieb: > Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams > und beklagst Dich dann darüber, daß die Kollaboration und die > Kommunikation mit den Teams nicht funktioniert. Das ist schlichtweg gelogen. Ein T. schrieb: > Allerdings ist mir aufgefallen, daß es hierarchisch sozialisierten > Menschen mitunter schwer fällt, kooperative Kollaborationsmodelle zu > verstehen, sogar wenn sie es wollen. Und das ist schlichtweg Unsinn. Hierarchisch orientierte Menschen werden selten Softwareentwickler. Hierarchie- und Statusdenken wird bei Ärzten, Juristen und BWLer groß geschrieben, während in den Entwicklungsabteilungen flache Hierarchien herrschen und die Leute mit Doktortitel diesen nicht ständnig mit Monstranz vor sich her tragen. Ich habe bzw. hatte Kollegen wie Vorgesetzte, die da nie Aufhebens drum machen bzw. machten. Es sind doch die Entwickler, die sich über Scrum beschweren. Mich interessiert eine Hierarchie nicht, auch keine Hackordnung. Ich will einfach nur das beste geben, lasse mich gerne auch inspirieren, möchte aber auch inspirieren. Da ich häufig einen formell höheren Studienabschluss habe, viel im Eigenstudium dazu lerne und nachweislich produktiver bin, kann man von mir auch was lernen. Man muss mich nur fragen, mein Source-Code ist auch für jeden im Unternehmen einsehbar.
Rudi R. schrieb: > Ein T. schrieb: >> Ich weiß nämlich auch nicht, was die Sache mit dem Druckertreiber soll. > > Es geht um Ihren Angriff ad hominem in dieser Sache. Die Geschichte mit > dem Druckertreiber zeigt eine Problemlösung ohne viel Allüren. Sie beweist aber auch, daß Du Dich aus der Kommunikation und Kooperation mit Deinen Teams herausziehst und Dich weigerst, ihre Kollaborationswerkzeuge zu nutzen. Du wurdest laut Deiner eigenen Aussage dazu aufgefordert, ein Ticket anzulegen, hast dies aber mit der Begründung: "Ich habe aber keine Lust auf solche Spielchen" [1] bewußt und gezielt verweigert. Und deswegen ist meine logische Schlußfolgerung >> Du Dich den Kollaborations- und Kommunikationswerkzeugen Deiner Teams >> und beklagst Dich dann darüber, daß die Kollaboration und die >> Kommunikation mit den Teams nicht funktioniert. auch keineswegs > [...] schlichtweg gelogen. sondern schlicht und ergreifend die Wahrheit, zumindest wenn Du den ganzen Vorgang hier richtig dargestellt hast. Und damit ist meine Aussage dann auch kein persönlicher Angriff, sondern eine simple Tatsachenfeststellung, deren Fundament Deine eigenen Aussagen in diesem Thread sind. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Als Projektleiter ist man zwischen den Fronten und dazu muss man kein > Techniker sein. Die Persönlichkeitsstruktur vieler MINTler würde dazu > auch gar nicht passen, weil die ja fokussiert arbeiten müssen. MINTler > sind in der Regel introvertiert, Projektleiter extrovertiert. Ein kluger > Projektleiter schaufelt seinen MINTlern die entsprechenden Freiräume für > Problemlösungen ein, hält nicht ständig Meetings ab. Softwareentwickler > müssen arbeiten können. Solche Ansichten hatten die schlechtesten Projektleiter meiner Karriere. Ich erspare uns und unseren Mitlesern lieber, näher darauf einzugehen. > Meine Scrum-Erfahrungen waren überwiegend > negativ, weil vieles nervte. Vor allem nerven die, die sich der Zusammenarbeit bewußt entziehen, weil sie "keine Lust auf solche Spielchen" haben -- und dann triumphieren weil sie ja schon immer gewußt haben wollen, daß das alles nicht funktionieren kann. > Was ich erlebte, war eher die Dauerhektik. Komisch, in meinen klassisch geführten Projekten waren der Zeitdruck und die daraus resultierende Hektik immer viel größer -- sogar ohne daß nach Beginn des Projekts Änderungen vorgenommen werden mußten. Meine agilen Projekte sind meistens viel entspannter, und dabei auch auf Veränderungen vorbereitet. > Scrum ist nicht Voraussetzung > für kooperatives Arbeiten und auch nicht förderlich. Wenn man sich dem verweigert, dann funktioniert es natürlich auch nicht. > Ich spricht grundsätzlich nichts dagegen, aber meiner Erfahrung > konditioniert Scrum die Entwickler, schnell mal irgendwelchen Pfusch > abzuliefern, weil das Sprintende naht. Ehrlich, ich habe keine Ahnung, was Ihr da macht, aber mit Scrum hat das wenig zu tun. Wenn ein Entwickler nicht so weit gekommen ist wie das Team gemeinsam geplant hatte, dann ist er auf unvorhergesehene Schwierigkeiten gestoßen, hat darauf schon in den Daily Standups hingewiesen und versucht, dort Hilfe und Unterstützung zu erhalten. Genau dafür sind die Daily Standups ja gedacht. > Es kann doch > nicht sein, dass Entwickler durch die Gegend laufen, die nicht wissen, > was die Entwurfsmuster Adapter, Beobachter und Dekorierer sind. Schlimm, mit was für "Entwicklern" Du Dich herumschlagen mußt. Daß agile Methoden mit schlecht ausgebildeten Pfeifen nicht gut funktionieren, ist allerdings auch nicht verwunderlich, insbesondere dann nicht, wenn sich gleichzeitig die Erfahrenen wie Du der Zusammenarbeit entziehen. Komisch ist allerdings, daß wir unseren "Frischlingen" mitunter erst einmal beibringen müssen, nicht jedes Problem gewaltsam auf Gedeih und Verderb mit Entwurfsmustern der GOF totzuschlagen, und was Antipatterns sind. > Mich interessiert eine Hierarchie nicht, auch keine Hackordnung. Ich > will einfach nur das beste geben, Dann lerne, mit Deinen Teams zu kommunizieren, zu kollaborieren und zu kooperieren. Das heißt zu allererst, die dort verwendeten Kommunikations-, Kollaborations- und Kooperationswerkzeuge und die Methoden nicht nur zu akzeptieren, sondern auch, sie sinnvoll zu benutzen.
Ein T. schrieb: > J. S. schrieb: >> Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur >> ihre reine Nettozeit, sondern auch vor- und Nachbereitung > Huch... > >> Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master >> den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau >> verschiebt. > ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui. Du liest fälschlicherweise einen Widerspruch in meine Aussage hinein, weil du sie nicht verstanden hast: Der erste Teilsatz beschreibt ein Soll, der zweite (leider) das Ist. Diese Diskrepanz führe ich an. Oder anders formuliert: Ein nutzvolles Meeting erfordert immer eine Vorbereitung (egal ob Scrum) was leider oft nicht gegeben ist. Bei den daily meets ist das besonders eklatant, daher wird Zeit verbraten, die oft nutzlos ist. Dies besonders dann, wenn Scrum über mehrere Projektmitarbeiter drüber gezogen wird, die gar nicht an derselben Aufgabe tätig sind, was aber unvollständlicherweise oft der Fall ist. Scrum sollte daher nur zwischen den Personen stattfinden, die wirklich an einem Teilprojekt arbeiten, welches diese enge Abstimmung auch erfordert und dann sollte auch tunlichst über Inhalte gesprochen werden. Den reinen Status Quo über den Stand der Erledigung der Teilaufgaben innerhalb des Teilprojektes muss nicht täglich kommuniziert und getrackt werden. Soweit das tracken sein muss, kann derjenige, gfs der PO, ins scrum tableu schauen, wie er Stand ist, wenn er das unbedingt braucht. Würden die Leute nicht alles und jenes mit Scrum abwickeln wollen und überall und jeden drüberstülpen, dann gäbe es diese "Meeting-Hölle" auch nicht.
J. S. schrieb: > Ein T. schrieb: >> J. S. schrieb: >>> Das ist schnell dahin gesagt, aber die Daily erfordern eben nicht nur >>> ihre reine Nettozeit, sondern auch vor- und Nachbereitung >> Huch... >> >>> Die meisten Daily-Meets sind reine Statusberichte, wo der Scrum-Master >>> den Stand abfragt, Aufgaben abhakt und ein paar Boxen im tableau >>> verschiebt. >> >> ...und dafür brauchst Du eine "Vor- und Nachbereitung"? Ui. > Du liest fälschlicherweise einen Widerspruch in meine Aussage hinein, > weil du sie nicht verstanden hast: Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, jedoch beklagst Du dann gleichzeitig deren Banalität. > Ein nutzvolles Meeting erfordert immer eine Vorbereitung (egal ob Scrum) Dem stimme ich zwar grundsätzlich zu, aber meine "Vor- und Nachbereitung" für ein Daily Standup dauert in der Regel etwa dreißig Sekunden, in denen ich die Frage beantworte, was ich heute vorhabe. Diese Gedanken muß ich mir allerdings ohnehin immer machen, sie sind also nicht verschwendet. > was leider oft nicht gegeben ist. Bei den daily meets ist das besonders > eklatant, daher wird Zeit verbraten, die oft nutzlos ist. Dies besonders > dann, wenn Scrum über mehrere Projektmitarbeiter drüber gezogen wird, > die gar nicht an derselben Aufgabe tätig sind, was aber > unvollständlicherweise oft der Fall ist. Keineswegs. Für meine Kollegen ist es eine wertvolle Information, wenn ich gestern die Server des Kunden X aktualisiert habe und heute die Zertifikate auf den Servern des Kunden Y erneuere. Wenn meine Kollegin Eva (*) erklärt, daß sie heute an den Newslettern für den Kunden Z arbeiten wird, ist das für mich eine sinnvolle Information. Auf diese Weise haben mit je zwei Sätzen von Eva und mir alle Kollegen eine grobe Idee, was wir gerade tun, und inwieweit das Einfluß auf ihre Arbeit haben kann. (*) The names have been changed to protect the innocent. > Scrum sollte daher nur zwischen den Personen stattfinden, die wirklich > an einem Teilprojekt arbeiten, welches diese enge Abstimmung auch > erfordert und dann sollte auch tunlichst über Inhalte gesprochen werden. Inhaltliche Erörterungen gehören auch nicht in die Daily Standups. > Den reinen Status Quo über den Stand der Erledigung der Teilaufgaben > innerhalb des Teilprojektes muss nicht täglich kommuniziert und getrackt > werden. Das gehört ebenfalls nicht in die Daily Standups, sondern in die Tickets. > Soweit das tracken sein muss, kann derjenige, gfs der PO, ins > scrum tableu schauen, wie er Stand ist, wenn er das unbedingt braucht. Ich dachte, Du wolltest Scrum am Liebsten abschaffen? Ohne Scrum hat der PO aber gar kein Scrum-Tableau, und es gäbe auch keinen PO. Und dann? Was wäre Deine Alternative, was schlägst Du vor? > Würden die Leute nicht alles und jenes mit Scrum abwickeln wollen und > überall und jeden drüberstülpen, dann gäbe es diese "Meeting-Hölle" auch > nicht. Wie schon mehrmals hier im Thread angeklungen ist, muß man Scrum und andere agile Methoden schon richtig anwenden, um einen Gewinn daraus zu ziehen. Zu dieser richtigen Anwendung gehört, die Daily Standups kurz zu halten und da eben keine Statusabfragen zu machen. Dafür gibt es andere Werkzeuge, und da arbeiten dann auch nur die Betroffenen zusammen.
Ein T. schrieb: > Dann lerne, mit Deinen Teams zu kommunizieren, zu kollaborieren und zu > kooperieren. Das heißt zu allererst, die dort verwendeten > Kommunikations-, Kollaborations- und Kooperationswerkzeuge und die > Methoden nicht nur zu akzeptieren, sondern auch, sie sinnvoll zu > benutzen. Weil ich bei der Druckproblematik kein Ticket geöffnet habe, ist das jetzt eine Verweigerung von "Kommunikationswerkzeugen"? Interessant. Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits mehrmal machten. Dann druckte es einmal und die nächsten fünf, sechs Druckaufträge wurden verschluckt. Und genau die Kollegin, die mir sagte: "Mach 'nen Ticket auf. Geh die auf die Nerven." War im "prozessorientierten Denken", während ich einfach mal recherchierte, und das mit dem Drucktreiber probierte. Ich habe das Problem zur Freude vieler am Standort endgültig behoben. Der firmeninterne EDV-Service sitzt auch an einem anderen Standort und hat nur seine Checkliste. Die haben auch kein Skin in the Game, weil sie ja unter den dysfunktionalen Drucker nicht litten. Und nur weil mal "Kommunikations-, Kollaborations- und Kooperationswerkzeuge" verwendet, wird es einfach nicht gut. Erst recht nicht, wenn eine Scrum-Masterin einen rammdösig quatscht und Softwareengineering-Themen auf der Strecke bleiben.
Rudi R. schrieb: > Weil ich bei der Druckproblematik kein Ticket geöffnet habe, ist das > jetzt eine Verweigerung von "Kommunikationswerkzeugen"? Ja, natürlich. Ein Ticketsystem ist ein Kommunikationsmedium. Wenn man das nicht nutzt, weil man "keine Lust auf solche Spielchen" hat, dann darf man sich nicht wundern, wenn die Kommunikation nicht klappt. > Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits > mehrmal machten. Das war nicht Deine Begründung in diesem [1] Beitrag. Deine Begründung war dort, daß Du "keine Lust auf solche Spielchen" hast. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Der firmeninterne EDV-Service > sitzt auch an einem anderen Standort und hat nur seine Checkliste. Die > haben auch kein Skin in the Game, weil sie ja unter den dysfunktionalen > Drucker nicht litten. Der Richtige Ansatz (tm) wäre gewesen, die Lösung irgendwo zu dokumentieren, dann für jeden nicht funktionierenden Drucker ein Ticket mit einem Link auf diese Lösung zu erstellen und das Ticket demjenigen zuzuweisen, der sich in diesem Unternehmen um solche Dinge kümmern soll, also in Deinem Fall diesem firmeninternen EDV-Service. > Und nur weil mal "Kommunikations-, Kollaborations- und > Kooperationswerkzeuge" verwendet, wird es einfach nicht gut. Vielleicht ja doch? Probier es doch einfach mal aus. Und selbst wenn nicht: indem Du Probleme, besser sogar noch mit Lösungsansätzen, und im Idealfalle sogar Lösungen über die vorhandenen Werkzeuge kommunizierst, bist Du aus der Nummer jedenfalls 'raus. In Deine, Fall des Druckers dokumentierst Du das Problem und die Lösung, dann legst für jeden nicht funktionierenden Drucker ein Ticket mit einem Hinweis auf diese Dokumentation an und am Ende weist Du das Ticket dem (oder denen) zu, die für solche Aufgaben verantwortlich sind. Danach ist das Problem dann nicht mehr Deines, und wenn es weiterhin nicht richtig funktioniert, weiß jeder, an wem das Problem liegt und wo er Druck machen muß, damit es behoben wird. Und mit genügend Druck von außen könnte sich möglicherweise sogar Euer firmeninterner EDV-Service dazu motivieren lassen, den Kopf aus dem Gesäß zu nehmen und die Arbeit zu machen, für die Euer Arbeitgeber diesen lahmen Haufen bezahlt. > Erst recht > nicht, wenn eine Scrum-Masterin einen rammdösig quatscht und > Softwareengineering-Themen auf der Strecke bleiben. Wie gesagt: ich habe keine Ahnung, was Ihr da macht, aber offensichtlich ist das weder Scrum noch eine andere agile Methode. Und Du hast mir weiter oben dabei auch zugestimmt, als Du hier [2] geschrieben hast: "[...] wird aktuell ein Scrum light gemacht". Mich haben jedenfalls noch nie eine Scrum-Masterin oder ein Scrum-Master "rammdösig gequatscht" und in meinen Projekten ist das Softwareengineering ebenso präsent wie Architektur- und Intrastrukturthemen. [2] Beitrag "Re: Meeting-Hölle/Scrum"
Ein T. schrieb: >> Ich habe da kein Ticket erstellt, weil Kollegen von mir das bereits >> mehrmal machten. > > Das war nicht Deine Begründung in diesem [1] Beitrag. Deine Begründung > war dort, daß Du "keine Lust auf solche Spielchen" hast. Ich habe in der Tat keine Lust auf solche "Spielchen". Denn was da meine Kollegin machte, alle zwei Wochen ein Ticket für die gleiche Sache zu erstellen, sind "Spielchen", weil sie ja ganz bewusst nerven wollte und mich anmotzte, weil ich das Problem einfach löste, anstatt es ihr gleich zu tun. Es ging gar nicht darum, dass ich das Ticketsystem boykottierte erstmaligen Auftreten des Problem ignorierte, sondern nach mehrfachen Auftreten des Problems anfing, auf das Ticketsystem und die dahinter stehenden Leute ignorierte. Deshalb habe ich die Anekdote am 05.10. gebracht und es geht auch daraus hervor, was ich als Spielchen bezeichnete. Sicherlich nicht das Ticketsystem als solches, sondern die Aussage, die EDV richtig zu nerven. Denn genau das hat meine Kollegin gemacht: alle zwei Woche 'nen Ticket schreiben und herummotzen, dass es nicht geht. Anstatt sich bei mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin nerven sollen. Genau das sind Spielchen, Machtspielchen.
Rudi R. schrieb: > Anstatt sich bei > mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und > meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin > nerven sollen. Genau das sind Spielchen, Machtspielchen. Nein, das ist ein Problem in der Firma. Euer EDV-Service hat nichts unternommen und trotzdem lösen sich Probleme und lassen sie gut dastehen, weil halt Leute wie du die Arbeit von denen machen. Was nicht ihre Aufgabe ist, wofür sie nicht bezahlt werden und schlimmstenfalls noch nicht mal Ahnung von haben und alles nur schlimmer machen. Wenn die Firma es nicht schafft, eine ordentliche Arbeitsumgebung mit funktionierenden Werkzeugen hinzustellen ist da einiges schiefgelaufen.
Reinhard S. schrieb: > Euer EDV-Service hat nichts > unternommen und trotzdem lösen sich Probleme und lassen sie gut > dastehen, weil halt Leute wie du die Arbeit von denen machen. Da prallen Mentalitäten aufeinander. Auf der einen Seite der auf die technischen Aspekte fokussierte Techie, der relativ ignorant für politische Konstellationen ist. Auf der anderen Seite Politiker, für die die technischen Probleme nur der Aufhänger für die eigentlichen Themen, nämlich Machtspiele, sind. Das real existierende Scrum eignet sich bestens für politische Spielchen, man hat auch hier alle Möglichkeiten, Koalitionen zu schmieden, Belagerungen, Feinden in der Rücken zu fallen, potemkinsche Dörfer etc. Kenner des wahren Scrum haben nur Spott und Verachtung dafür übrig. Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Mit Hilfe dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden.
Ein T. schrieb: > Joe schrieb: >> Das Aufoktroyierte ist das Schlimme. > > Und ein nicht weniger aufoktroyierter Projektleiter, der allen > Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann > wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger > schlimm? Die erfahrenen Projektleiter, die den fachlichen Rat seiner Mitarbeiter einholten, vor dem Management die Interessen des Teams vertraten, habe ich in guter Erinnerung. Im Gegensatz zu den Denglisch-Phrasen von sich gebender Agilisten, die scheinbar der Meinung sind, alles sei lösbar, wenn man nur den Prozess einhält.
Joe schrieb: > Das real existierende Scrum eignet sich bestens für politische > Spielchen, man hat auch hier alle Möglichkeiten, Koalitionen zu > schmieden, Belagerungen, Feinden in der Rücken zu fallen, potemkinsche > Dörfer etc. Das hat nichts mit Scrum zu tun, das hängt von den Menschen ab. > Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, > Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver > Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Klingt wie ein Werbeprospekt. > Mit Hilfe > dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden. Wenn du diese Merkmale auf Arbeit hast wirst du bzw. das Team auch ohne Scrum Erfolg haben.
Hallo, Ein T. schrieb: > und im > Idealfalle sogar Lösungen über die vorhandenen Werkzeuge kommunizierst, > bist Du aus der Nummer jedenfalls 'raus. und Ein T. schrieb: > Danach ist das Problem dann nicht mehr Deines, und wenn es weiterhin > nicht richtig funktioniert, weiß jeder, an wem das Problem liegt und wo > er Druck machen muß, damit es behoben wird. Man muss sich das mal vorstellen, da kann ein Problem ohne großen Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann kommt jemand und kritisiert das sich der Problemlöser nicht an die (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. So langsam wird mir klar was in der deutschen Industrie schief läuft. Wäre ich der Besitzer des Unternehmens, für das du arbeitest, würde ich dir SOFORT nahelegen deinen beruflichen Wirkungskreis zu verlegen. Leute wie dich, die keine Verantwortung übernehmen wollen um 'raus' zu sein, braucht kein Unternehmen. Joe schrieb: > Das wahre Scrum basiert nämlich auf Gleichheit, Brüderlichkeit, > Flexibilität, Einbeziehung des ganzen Teams, freiwilliger und intensiver > Kooperation und einem kontinuierlichen Verbesserungs-Prozess. Mit Hilfe > dieser Merkmale kann Scrum von anderen Frameworks unterschieden werden. Mit anderen Worten: Scrum funktioniert nur perfekt wenn man den ideale Mitarbeiter hat und die Realität menschlicher Verhaltensweisen völlig ignoriert. Also gar nicht. rhf
Ein T. schrieb: > Und ein nicht weniger aufoktroyierter Projektleiter, der allen > Mitgliedern des Teams dann seinerseits aufoktroyiert, was sie bis wann > wie (und bisweilen auch wo) zu tun haben, das erscheint Dir weniger > schlimm? Es wird immer jemanden geben, der Dir Top-Level Anforderungen vorgibt die Du abzuarbeiten hast. Ob die nun vom Kunden kommen, oder vom Vertrieb in der Firma wo Du arbeitest, aus einer Norm oder sonstwoher. Warum also soll es nicht einen Projektleiter geben, der Dir sagt welche für Anforderungen bis wann umgesetzt sein sollen? Das Problem, das ich bei Scrum sehe ist, dass die Arbeit die ansonsten der Projektleiter macht (Koordinieren und sich abstimmen mit anderen Abteilungen, Stakeholdern etc.) ja nicht auf einmal verschwunden ist. Sondern sie ist nun zum Teil beim Product Owner, zum Teil aber auch bei den Entwicklern. Das heißt, dass die Entwickler weniger Arbeitszeit für ihre eigentliche Arbeit übrig haben. Was spricht gegen eine Arbeitsteilung, in der manche Menschen die Aufgabe haben zu koordinieren, und andere die Aufgabe haben zu entwickeln?
Rudi R. schrieb: > Deshalb habe ich die Anekdote am 05.10. gebracht und es geht auch daraus > hervor, was ich als Spielchen bezeichnete. Sicherlich nicht das > Ticketsystem als solches, sondern die Aussage, die EDV richtig zu > nerven. Denn genau das hat meine Kollegin gemacht: alle zwei Woche 'nen > Ticket schreiben und herummotzen, dass es nicht geht. Anstatt sich bei > mir zu bedanken, dass die Lösung kam, war sie es, die mich anmotzte und > meinte, ich hätte den EDV-Service, der es ja nicht hinbekam, weiterhin > nerven sollen. Genau das sind Spielchen, Machtspielchen. Wenn ein Ticket trotz hoher Priorität und mehrfacher Hinweise nicht bearbeitet wird, wird das zum Vorgesetzten eskaliert. Ihr habt offenbar schwerwiegende Probleme mit Eurer Unternehmenskultur. Wenn Deine Kollegen sich gegenseitig blockieren, muß Zusammenarbeit scheitern. Das hat aber nichts mit agilen Methoden zu tun -- die machen solche Probleme zwar deutlich sichtbar, können und sollen sie aber nicht lösen.
Joe schrieb: > Da prallen Mentalitäten aufeinander. Auf der einen Seite der auf die > technischen Aspekte fokussierte Techie, der relativ ignorant für > politische Konstellationen ist. Auf der anderen Seite Politiker, für die > die technischen Probleme nur der Aufhänger für die eigentlichen Themen, > nämlich Machtspiele, sind. Joe schrieb: > Die erfahrenen Projektleiter, die den fachlichen Rat seiner Mitarbeiter > einholten, vor dem Management die Interessen des Teams vertraten, habe > ich in guter Erinnerung. Im Gegensatz zu den Denglisch-Phrasen von sich > gebender Agilisten, die scheinbar der Meinung sind, alles sei lösbar, > wenn man nur den Prozess einhält. Das Leben muß sehr angenehm sein, wenn man so einfache Welt- und Feindbilder hat. Und wenn Du das ernst meinst, lebe ich anscheinend in einem vollkommen anderen Universum als Du. Viel Glück für Deinen weiteren Lebensweg.
Roland F. schrieb: > Man muss sich das mal vorstellen, da kann ein Problem ohne großen > Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann > kommt jemand und kritisiert das sich der Problemlöser nicht an die > (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. > So langsam wird mir klar was in der deutschen Industrie schief läuft. Locker bleiben, das ist jetzt seine neue Erklärung, am Anfang hatte er nur keinen Bock. Und wenn jeder in der Company sein eigenes Ding macht und das weder dokumentiert noch kommuniziert, endet das im totalen Chaos. > Wäre ich der Besitzer des Unternehmens, für das du arbeitest, würde ich > dir SOFORT nahelegen deinen beruflichen Wirkungskreis zu verlegen. Leute > wie dich, die keine Verantwortung übernehmen wollen um 'raus' zu sein, > braucht kein Unternehmen. Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die ihre Arbeit einfach ignorieren? Du würdest Dich als Besitzer des Unternehmens auch nicht darüber ärgern, daß Du teure Kollaborationswerkzeuge betreibst, die aber von mehreren Deiner Mitarbeitern einfach ignoriert werden? Stattdessen würdest Du lieber jemandem kündigen, der sich darum kümmert, der seine Kollegen mithilfe dieser Werkzeuge dazu bringt, das zu machen, für das Du sie bezahlst... Du hast noch nie ein Unternehmen besessen, oder?
Mark B. schrieb: > Warum also soll es nicht einen Projektleiter geben, der Dir sagt welche > für Anforderungen bis wann umgesetzt sein sollen? Das funktioniert noch weniger. Der Grund für die Entwicklung agiler Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an ihren Zeit- und / oder Budgetgrenzen gescheitert sind.
Roland F. schrieb: > Mit anderen Worten: Scrum funktioniert nur perfekt wenn man den ideale > Mitarbeiter hat und die Realität menschlicher Verhaltensweisen völlig > ignoriert. > Also gar nicht. Beziehungsweise der Prozess der Softwareentwicklung funktioniert einigermaßen, obwohl Scrum eingesetzt wird. Es gibt einmal das Agile Manifest, was hehre Prinzipien beinhaltet. Dann Scrum als konkretes Regelwerk mit Zeremonien und Ritualen. Damit stellt sich die Frage, ob das Einhalten der Form ein Unternehmen automatisch agil macht. Die Frage stellt sich ja auch in anderen Kontexten: Ist einer, der Fastenregeln einhält und Gebete auswendig kann usw., aber geizig und unbarmherzig bleibt, ein frommer Mann geworden? Kann ein Staat, der die Menschenrechte mit Füßen tritt, ein sozialistischer Staat sein? Mich regt es auf, immer herablassend zu hören zu bekommen in der Art "ist ja schon daneben, was bei euch alles als Scrum bezeichnet wird" und das auch noch als Argument zu meinen und anschließend mit anekdotischem Wissen zu prahlen.
Ein T. schrieb: > Das Leben muß sehr angenehm sein, wenn man so einfache Welt- und > Feindbilder hat. Und wenn Du das ernst meinst, lebe ich anscheinend in > einem vollkommen anderen Universum als Du. Viel Glück für Deinen > weiteren Lebensweg. Ich finde ständig polemische Abwertungen und Pauschalisierungen sowie apodiktische Behauptungen in deinen Beiträgen. Dies war nicht geeignet, meine Meinung über Agilisten als parareligiös zu erschüttern.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Wie viele scheitern jetzt daran? Runde 70%?
:
Bearbeitet durch User
Ein T. schrieb: > Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich > über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, > jedoch beklagst Du dann gleichzeitig deren Banalität. Nein du hast es immer noch nicht verstanden! Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet sind. Damit sie effektiv würden, müssten sie länger und intensiver und MIT Vorbereitung sein.
Ein T. schrieb: > Roland F. schrieb: >> Man muss sich das mal vorstellen, da kann ein Problem ohne großen >> Aufwand innerhalb kürzester Zeit aus der Welt geschafft werden und dann >> kommt jemand und kritisiert das sich der Problemlöser nicht an die >> (offensichtlich nicht funktionierende) Kommunikationswege gehalten hat. >> So langsam wird mir klar was in der deutschen Industrie schief läuft. > > Locker bleiben, das ist jetzt seine neue Erklärung, am Anfang hatte er > nur keinen Bock. Und wenn jeder in der Company sein eigenes Ding macht > und das weder dokumentiert noch kommuniziert, endet das im totalen > Chaos. Ich habe mir meinen Beitrag vom 05.10.2024 noch einmal komplett durchgelesen. Aufhänger war "prozessorientiertes Denken", dass BWLer darin das Allheilmittel sehen, wenn nur die Prozesse stimmten. Dass der EDV-Service selten hilfreich ist und viele meckern, schrieb ich auch. Und dass das Druckerproblem nach mehreren Anläufen nicht gelöst war, schrieb ich auch. Ich habe ja gerade nicht mein eigenes Ding gemacht, sondern ein Problem gelöst, das uns alle betraf. Ich habe es dokumentiert und kommuniziert; es ging eine Mail an alle Leute am Standort. Wie sonst hätte jemand motzen können, wenn ich es nicht kommuniziert habe? Das Chaos beginnt, wenn die Leute Dienst nach Vorschrift schieben, nicht mehr mitdenken. Was machen Sie eigentlich, wenn Sie in der Teeküche den Kaffee verschütten? Liegen lassen? Ist ja schließlich Sache der Putzfrau (anderer Prozess!), die vielleicht zweimal pro Woche kommt. Nachdem unsere Putzkräfte im Januar 2022 kündigten, sind wir auf externe Dienstleister angewiesen. Das Unternehmen war froh, die beiden Putzfrauen los zu werden. Nun sind es ja keine Personalkosten mehr, sondern hat 'ne andere Buchungsnummer. Das finden BWLer toll: ein Prozess! Aber was ist die Folge? Die Leistung ist unterirdisch und wir zahlen mehr als für die beiden direkt angestellten Frauen. Das ist vollkommen irre. Und weil das auch noch externe Leute sind, haben wir keine Kontrolle, wer da kommt und alle hatten sie Probleme mit der Alarmanlage.
Ein T. schrieb: > Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, > daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die > ihre Arbeit einfach ignorieren? Du würdest Dich als Besitzer des > Unternehmens auch nicht darüber ärgern, daß Du teure > Kollaborationswerkzeuge betreibst, die aber von mehreren Deiner > Mitarbeitern einfach ignoriert werden? > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu lösen, freue ich mich, wenn ein anderer ITler das Problem löst. Entscheidend ist, dass das Problem aus der Welt ist. > Stattdessen würdest Du lieber jemandem kündigen, der sich darum kümmert, > der seine Kollegen mithilfe dieser Werkzeuge dazu bringt, das zu machen, > für das Du sie bezahlst... Du hast noch nie ein Unternehmen besessen, > oder? Diese Kollegen können nicht machen, für was sie bezahlt werden, weil ein technisches Problem vorliegt. Es hat sich niemand darum gekümmert, dass bestimmte Werkzeuge verwendet werden. Es wurde ja gemacht und man stellte fest, dass es nicht funktionierte, dass das Problem über diesen Weg nicht gelöst wird. Das Denken in Prozessen, wie Sie es vormachen, ist geradezu unternehmeruntypisch. Das gibt's bei angestellten BWLern, die man mit Unternehmern nicht verwechseln sollte.
Rudi R. schrieb: > Das Denken in Prozessen, wie Sie es vormachen, ist geradezu > unternehmeruntypisch. Das gibt's bei angestellten BWLern, die man mit > Unternehmern nicht verwechseln sollte Richtig. An deinem Diskutanten stört mich, daß ständig kolportiert wird: Wenn jeder sich an die Anweisungen von oben halten würde, wäre die Welt ein besserer Ort. So klingt typischerweise ein frischgebacker BWLer. An anderer Stelle ist dann von "hierarchisch sozialisierte Menschen" die Rede, was dann wieder nach linksorientiert/Piratenpartei erinnert. Wird dann mit der Suggestivfrage angereichert "Du hast noch nie ein Unternehmen besessen, oder?", was wohl die Welt in Menschen unterteilt, die mindestens eine Pommesbude besitzen und den großen Rest, inklusive aller BWL Lehrstühle. Die echte Welt braucht letztlich beides, proaktive Mitarbeiter und auch Bürokratie. Was nicht geht, ist eines durch das andere ersetzen zu versuchen.
Hallo, Ein T. schrieb: > Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, > daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die > ihre Arbeit einfach ignorieren? Du lenkst ab. Es geht nicht um die zuständige Abteilung, es geht um deine Kritik an einem Mitarbeiter einer anderen Firma dafür, das er einfach so ein Problem löst ohne sich an die dafür vorgesehene Fehlermeldungsprozedur zu halten. Ein T. schrieb: > Du hast noch nie ein Unternehmen besessen, oder? Und wieder eine Ablenkung, bleib doch einfach beim Thema. Rudi R. schrieb: > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die > Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der > EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu > lösen, freue ich mich, wenn ein anderer ITler das Problem löst. > Entscheidend ist, dass das Problem aus der Welt ist. Dem ist nun wirklich nichts hinzuzufügen, danke Rudi. rhf
Joe schrieb: > Die echte Welt braucht letztlich beides, proaktive Mitarbeiter und auch > Bürokratie. Was nicht geht, ist eines durch das andere ersetzen zu > versuchen. Sehr richtig. Die Menschen ergänzen sich. Das habe ich weiter oben schon beschrieben, dass viele MINTler wissen, dass sie nicht die extrovertierten Rampensäue sind und auch nie sein werden. Sie wissen, dass sie auf die anderen angewiesen sind. Viele BWLer hingegen, die dann die Entscheidungen treffen, sind genau von diesem Typus, dass das von Vorteil sein kann, wenn man im Kundengespräch regelrecht aufgeht. Nun sind diese Leute am längeren Hebel, aber sie verstehen nicht, dass sie ihre Wertmaßstäbe nicht an die oft sehr introvertierten MINTler anlegen können. Ich habe oben schon von meinem Assessmentcenter-Erlebnis geschrieben. Da ging es um eine Entwicklerstelle und wir sollten eine Nachrichtensendung machen. Joe schrieb: > anderer Stelle ist dann von "hierarchisch sozialisierte Menschen" die > Rede, was dann wieder nach linksorientiert/Piratenpartei erinnert. Wird > dann mit der Suggestivfrage angereichert "Du hast noch nie ein > Unternehmen besessen, oder?", Er widerspricht sich selbst, indem er suggeriert, man sei hierarchisch organisiert, wirft aber einem vor, dass man sich in eine Hierarchie nicht einordnet und einfach - jenseits der Prozesse - ein Problem löst. Tatsächlich gebe ich nicht viel auf Hierarchien. Mir geht's um Kompetenzen. Ich bekomme auch täglich Anfrufe von Kollegen, die 'ne Frage haben, weil sie meine Erfahrung und Kompetenz schätzen. Dafür gibt es keinen Prozess. Ich verbuche das noch nicht mal richtig, aber das Unternehmen kommt voran. Warum ich es nicht korrekt verbuche? Der bürokratische Aufwand für eine halbe Stunde hier und da bei etlichen Projekten ist einfach zu hoch. Die ganzen Buchungsungsnummer sind leider durch ein Rechtemanagement mir ohnehin versperrt. Dass es so viele Buchungsnummern gibt, ist auch so eine Ausgeburt der Kontrollsucht der BWLer, die dem irrigen Gedanken anhängen, dass es Projekte und Prozesse gibt und dass da niemand ausschert. Die glauben wirklich, dass ein Entwickler ausschließlich an seinem aktuellen Projekt arbeitet und dass da nie Rückfragen von zum vorherigen Projekt kommen oder dass Kollegen ganz anderer Projekte Hilfe bei bestimmten Thematiken brauchen. Eigentlich ist mein Verhalten und meine Arbeitsmoral genau das, was man sich wünscht: Probleme aus den Weg räumen, die Dinge zuverlässig und mit hoher Qualität erledigen. Ich bekomme ja diese Rückmeldungen. "Dienst nach Vorschrift" kommt für mich nicht in Frage. Ich kann mich damit nicht identifizieren. Die Kollegin, die mich wegen der Druckergeschichte anmotzte, weil ich ihrer Meinung nach auch den EDV-Service hätte triezen sollen, ist allgemein von früh bis spät am Meckern, die ständig aufzählt, wofür sie alles nicht zuständig ist. Ich habe auch schon auf einem Kundenserver einen Drucker eingerichtet. Eigentlich hätte der Kunde das machen müssen, aber wir wollten nicht warten, bis die das gebacken kriegen. Mit lpadmin habe ich das eingerichtet. Dazu wurde unser Account sogar der sudo-Gruppe zugeordnet. Uns war klar, dass ein zu spät eingerichteter Drucker uns viel Geld kostet, weil wir den Drucker testen mussten, einen ZPL-Labelprinter. Ich hatte keine Lust auf Fingerpointing. Wäre abreisen und eine weitere teure Dienstreise (mit Flug, Mietwagen und Hotel) mehrerer Leute besser gewesen?
Reinhard S. schrieb: > Ein T. schrieb: >> Das funktioniert noch weniger. Der Grund für die Entwicklung agiler >> Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an >> ihren Zeit- und / oder Budgetgrenzen gescheitert sind. > > Wie viele scheitern jetzt daran? Runde 70%? Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Die stammen aber von den Marketing Deppen, die nicht-existierendes dem Kunden für morgen versprochen haben. Heute wird ihn nur agil versprochen "wir arbeiten dran und Sie sitzen im Team" bis er dann halt die Reissleine zieht weil ewig nichts rauskommt ausser mock-ups.
J. S. schrieb: > Ein T. schrieb: >> Ich hab' das schon ganz gut verstanden: einerseits beschwerst Du Dich >> über den Zeitaufwand für die Vor- und Nachbereitung der Daily Standups, >> jedoch beklagst Du dann gleichzeitig deren Banalität. > > Nein du hast es immer noch nicht verstanden! > > Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet > sind. Damit sie effektiv würden, müssten sie länger und intensiver und > MIT Vorbereitung sein. Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung sinnvoll.
Rudi R. schrieb: > Ich würde mich als Unternehmenseigentümer über Mitarbeiter ärgern, die > Dienst nach Vorschrift schieben. Ich will Problemlöser. Wenn der > EDV-Service nicht in der Lage ist, ein konkretes Druckerproblem zu > lösen, freue ich mich, wenn ein anderer ITler das Problem löst. > Entscheidend ist, dass das Problem aus der Welt ist. Dieses kleine Problem mag zwar jetzt zunächst gelöst erscheinen, ist es aber langfristig eben leider nicht. Aus unternehmerischer Sicht habe ich allerdings plötzlich ganz andere, wesentlich schwerwiegendere Probleme: 1. einen EDV-"Service", der offensichtliche Probleme mit seiner Kompetenz, einer Überlastung und / oder womöglich sogar seiner Motivation hat, 2. einen EDV-"Service", der mir seine Überforderung oder Überlastung nicht angezeigt hat, so daß ich keine Abhilfe schaffen konnte, 3. einen Externen, der sich -- trotz ausdrücklicher Ermahnung -- nicht an die etablierten Kommunikationsprozesse meines Unternehmens hält. "Oh", sagt da der Dienstleister, "aber ich habe doch eine E-Mail geschickt". Das hilft nur leider nichts. Jetzt ist das Problem zwar erst einmal gelöst. Aber nächstes oder übernächstes Jahr, wenn das Unternehmen gewachsen ist und die Maschine gegen eine größere austauschen muß, weiß niemand mehr von dieser E-Mail. Schon gar nicht die Leute, die ich als Ersatz oder Erweiterung meines EDV-"Service" eingestellt habe, und die diese E-Mail nie erhalten haben. Wenn der Externe seine Lösung ins Ticketsystem geschrieben hätte, das offenbar die vorgesehene Kommunikationslösung des Unternehmens ist, dann wäre diese Lösung auch in vielen Jahren noch leicht auffind- und umsetzbar. Unternehmerisches Denken ist im Wesentlichen nachhaltiges und strategisches Denken. Probleme kurzfristig zu lösen, gehört natürlich dazu und ist ein taktischer Erfolg. Aber mindestens genau so wichtig ist es, Strategien und Lösungen zu etablieren, die dauerhaft funktionieren -- und dem Unternehmen jene Freiräume zu schaffen, die es zur Weiterentwicklung zwingend benötigt. Eine Fokussierung auf kurzfristige Lösungen führt dazu, daß das Unternehmen immer nur denselben Problemen hinterher läuft, die niemals dauerhaft gelöst werden und deswegen immer wieder auftauchen.
Ein T. schrieb: >> Wie viele scheitern jetzt daran? Runde 70%? > > Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber > die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint mir unglaubwürdig.
Roland F. schrieb: > Hallo, > Ein T. schrieb: >> Du würdest Dich als Besitzer des Unternehmens also nicht darüber ärgern, >> daß Du Leute für die Erledigung bestimmter Aufgaben bezahlst und die >> ihre Arbeit einfach ignorieren? > > Du lenkst ab. Keineswegs, warum sollte ich? > Es geht nicht um die zuständige Abteilung, Aber ja doch, es geht natürlich auch darum. Wenn meine Mitarbeiter ihre Arbeit nicht machen, dann muß ich als Unternehmer (oder Vorgesetzter) zuerst einmal herausfinden, warum das so ist, und dann Abhilfe schaffen. Wenn ein externer Dienstleister die etablierten Prozesse nicht einhält und den Informationsfluß in meinem Unternehmen dadurch behindert, muß ich herausfinden, warum das so ist, und dann Abhilfe schaffen. > es geht um > deine Kritik an einem Mitarbeiter einer anderen Firma dafür, das er > einfach so ein Problem löst ohne sich an die dafür vorgesehene > Fehlermeldungsprozedur zu halten. Wie kommst Du darauf, daß meine Kritik beträfe, daß er ein Problem löst? Das ist doch super! Ich kritisiere hingegen etwas ganz anderes: nämlich daß er sich nicht an die etablierten Kommunikationsmethoden hält, die seine Lösung langfristig festhalten, und sie dadurch zukünftig wieder auffindbar machen. > Ein T. schrieb: >> Du hast noch nie ein Unternehmen besessen, oder? > > Und wieder eine Ablenkung, bleib doch einfach beim Thema. Oh, nein, das ist keine Ablenkung. Ganz im Gegenteil hinterfrage ich, ob Du gelernt hast, unternehmerisch zu denken. Wie ich gerade in meinem Beitrag zu [1] geschrieben habe, gehört dazu nämlich ein bisschen mehr als kurzfristige Lösungen zu bejubeln. [1] Beitrag "Re: Meeting-Hölle/Scrum" > Dem ist nun wirklich nichts hinzuzufügen, danke Rudi. rolleyes Ihr ärgert Euch also weder über Mitarbeiter, die ihre Arbeit nicht machen, noch über solche, die den internen Informationsfluß torpedieren. Wow, Eure geduldige Nachsicht möchte ich gerne mal haben.
Michael B. schrieb: > Ein T. schrieb: >> Das funktioniert noch weniger. Der Grund für die Entwicklung agiler >> Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an >> ihren Zeit- und / oder Budgetgrenzen gescheitert sind. > > Die stammen aber von den Marketing Deppen, die nicht-existierendes dem > Kunden für morgen versprochen haben. In einem Artikel des seligen Dr. Dobbs Journal habe ich weiland eine Studie gelesen, die eine Quote von 68 % gescheiterter Projekte angegeben hat. Die Website ist leider offline, und leider kann ich diese Studie auch in der Wayback Machine nicht finden.
Ein T. schrieb: > ich als Unternehmer Bist Du wirklich Unternehmer? Weil, Du klingst wie ein BWLer mit Management und & Orga als Schwerpunktfächer. Ich weiß jetzt nicht, ob deine Beiträge als Satire gemeint sind. Mit dieser Sturheit, immer nur die Prozess-Standardisierung zu verteidigen, verrätst Du eigentlich die Agilität.
Ein T. schrieb: > Eine Fokussierung auf kurzfristige > Lösungen führt dazu, daß das Unternehmen immer nur denselben Problemen > hinterher läuft, die niemals dauerhaft gelöst werden und deswegen immer > wieder auftauchen. Genau das würde ja weiter oben schon angeführt als systematische Schwäche von Scrum, daß es auf oberflächlich und kurzfristige Lösungen abzielt.
Reinhard S. schrieb: > Ein T. schrieb: >> Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber >> die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. > > 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des > geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint > mir unglaubwürdig. Mir erscheint das auch zu hoch gegriffen, aber wie gesagt: es ist schwierig, seriöse und belastbare Daten zu finden. Andererseits sehe ich, daß agile Methoden mittlerweile in vielen Unternehmen benutzt werden, und ihre Verbreitung weiter zuzunehmen scheint. Meine ganz persönliche Vermutung ist, daß das nicht so wäre, wenn diese Methoden keine besseren Ergebnisse erzielen würden als die vorher verwendeten. Die größeren Unternehmen beschäftigen ja sogar eigens Mitarbeiter, sogenannte Controller, deren Aufgabe die ökonomische Überwachung ist. Würde denen nicht auffallen, wenn agile Projekte überwiegend scheiterten, ihre gesetzten Zeit- und Budgetgrenzen überschritten, oder weniger produktiv wären? Klar, das könnte auch alles eine gigantische Verschwörung von Unternehmern, Managern, Betriebswirten und Beratern sein. Solche Leute sind doch, wie hier bereits mehrmals im Thread angedeutet worden ist, grundsätzlich alle ziemlich dämlich und ohnehin nur an Macht, Party und der Unterdrückung von Technikern interessiert. Vielleicht sind die auch alle von einem bislang unbekannten Alienparasiten befallen, oder der Geist von Idi Amin zwingt sie dazu, agile Methoden zu benutzen, wer weiß? :-)
Rudi R. schrieb: > Nun > sind diese Leute am längeren Hebel, aber sie verstehen nicht, dass sie > ihre Wertmaßstäbe nicht an die oft sehr introvertierten MINTler anlegen > können. Die guten Verkäufertypen wissen, daß sie auf die Techniker existentiell angewiesen sind! Eigentlich ist das ganze Thema schon 20 Jahre alt. Aus der Zeit stammt auch eine vielbeachtete soziologische Arbeit zur McDonaldisierung der Gesellschaft. Klar, ein McDonald's ist perfekt organisiert. Aber was macht man, wenn ein Kunde eine französische Zwiebelsuppe haben will? Ein Koch, der bei dem Laden arbeitet, würde sich vielleicht hinstellen und aus dem vorhandenen Käse und Zwiebeln was zaubern. Sehr zum Mißfallen des Managements, versteht sich. Die McDonaldisierung aka Scrum ist auch ein Versuch, dem Fachkräftemangel zu begegnen. Leider fühlt man sich als akademisch ausgebildeter Informatiker bei solchem Zirkus genauso deplatziert wie ein Koch in einem McDonald's.
Ein T. schrieb: > Die größeren Unternehmen beschäftigen ja sogar eigens Mitarbeiter, > sogenannte Controller, deren Aufgabe die ökonomische Überwachung ist. > Würde denen nicht auffallen, wenn agile Projekte überwiegend > scheiterten, ihre gesetzten Zeit- und Budgetgrenzen überschritten, oder > weniger produktiv wären? Difficile est, satiram non scribere. Vielleicht würden die Controller ja beschließen, daß die Projekte eben noch nicht wirklich agil waren?
Ein T. schrieb: > Klar, das könnte auch alles eine gigantische Verschwörung von > Unternehmern, Managern, Betriebswirten und Beratern sein. Solche Leute > sind doch, wie hier bereits mehrmals im Thread angedeutet worden ist, > grundsätzlich alle ziemlich dämlich und ohnehin nur an Macht, Party und > der Unterdrückung von Technikern interessiert. Vielleicht sind die auch > alle von einem bislang unbekannten Alienparasiten befallen, oder der > Geist von Idi Amin zwingt sie dazu, agile Methoden zu benutzen, wer > weiß? :-) Vielleicht braucht es auch gar keine Verschwörungstheorie, sondern nur die Erkenntnis, daß auch Unternehmer, Manager, Betriebswirte und Berater nur Menschen sind, und allgemein eine besondere Mentalität und Sichtweise auf Probleme haben, die sich von der Sichtweise der Techies unterscheidet?
Ein T. schrieb: >> Es wird Zeit für minderwertige delays verbraten, WEIL sie unvorbereitet >> sind. Damit sie effektiv würden, müssten sie länger und intensiver und >> MIT Vorbereitung sein. > > Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. > Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung > sinnvoll. Ja, aber für die ist dann zu wenig Zeit. Das ist meine Beobachtung und Erfahrung. Ich sehe es ja täglich wie es läuft. Es herrscht chronischer Zeitmangel, der dazu führt, dass an anderer Stelle wieder gepfuscht wird. So wenig die 15min auch sein mögen, so sehr fehlen sie dann woanders. Offiziell läuft der Prozess und SCRUM, praktisch wird es dauernd umgangen um irgendwie weiterzukommen. Daher ist es zweckmäßig den formellen Prozess zu verschlanken oder lieber zu kippen, statt dafür Zeit zu verbraten, nur um ihn offiziell einzuhalten.
Ein T. schrieb: > Das funktioniert noch weniger. Der Grund für die Entwicklung agiler > Methoden war, daß -- je nach Studie -- 60 bis 80 Prozent der Projekte an > ihren Zeit- und / oder Budgetgrenzen gescheitert sind. Wie ist denn "gescheitert" definiert? Ist ein Projekt gescheitert, wenn es auch nur einen Tag länger dauert bis zur Fertigstellung als es in der ursprünglichen Deadline vorgesehen war? Es gibt manche Branchen, in denen ist "Scheitern" der Normalfall. Zwei Beispiele: Bauwesen und Eisenbahn. Es gibt nahezu kein Großprojekt im Hoch-/ Tiefbau, in dem die ursprünglich geplanten Termine eingehalten werden. Siehe Elbphilharmonie, Stuttgart 21, Berliner Flughafen, ... Bei der Eisenbahn gilt Ähnliches: Der Kunde will eine neue Straßenbahn, oder eine neue Lok, oder einen neuen Triebzug bestellen. Liefertermin soll in zwei Jahren sein. Jeder Hersteller weiß: Der Termin ist sowieso nicht zu halten. Trotzdem geben Siemens, Alstom, Stadler, Skoda fröhlich ihre Angebote für den Auftrag ab. Warum? Weil man selbst mit der ersten Pönale, die man wegen der verspäteten Lieferung dann zahlen muss, unterm Strich immer noch Geld verdient. Im Bauwesen ist Software-Entwicklung jetzt nicht so relevant, bei der Eisenbahn dagegen umso mehr. Die Funktionen der Fahrzeuge werden zu etwa 70% in Software realisiert. Meines Erachtens existiert auch kein gesicherter Nachweis dafür, dass Projekte durch SCRUM tatsächlich besser laufen. Wenn es den doch geben sollte, so bitte ich um einen Link zu der entsprechenden Quelle.
Gerhard O. schrieb: > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ Lesenswerter Aufsatz, danke. Für mich persönlich fehlt aber die Antwort, warum ein gesundes Team eine Medizin wie Scrum braucht Im Artikel heißt es: "...Wenn das Management die Entwickler im Wesentlichen ignoriert, es feste Fristen gibt, die innerhalb eines vorgegebenen Umfangs eingehalten werden müssen, oder wenn ein gnadenloser Kampf statt eines Teams herrscht, das sich auf das Erreichen desselben Ziels konzentriert, wenn Vorausplanung und Querdenken nicht geschätzt werden, dann wird man irgendwann aufgeben und sich darauf beschränken, nur noch die zugewiesenen Aufgaben zu erledigen. Ich habe das schon erlebt. Aber schieben Sie die Schuld nicht auf Scrum...“ In einem ungesunden Umfeld wirkt Scrum also nicht. Was aber bringt Scrum in einem gesunden Umfeld? Wenn das Management die Entwickler wertschätzt und auf ihren Rat hört, feste Fristen, die innerhalb eines vorgegebenen Umfangs eingehalten werden müssen, zugunsten Qualitätszielen/Vermeidung technischer Schulden zurückstehen müssen, wenn Kooperation und Teamgeist herrscht, wenn Vorausplanung und Querdenken geschätzt werden - was braucht es dann den ganzen Scrum Kram? Die Frage wird so nicht gestellt, obwohl sie m.E. wie der sprichwörtliche Elefant im Raum steht.
Prozesshuber vs Praktiker, das geht noch endlos so weiter. "Du musst erst ein Ticket aufmachen mähmähmäh". Solche Trullen kenne ich auch zur Genüge, nur dass ich das immer als Aussenstehender miterleben darf. Scrumzoo halt, die nächste Stufe ist die Klapse.
Joe schrieb: > was braucht es dann den ganzen Scrum Kram? SCRUM schließt das Management von der Projektarbeit aus. In der SCRUM Welt ist das Management salopp gesagt für die Urlaubsanträge zuständig.
J. S. schrieb: > Ein T. schrieb: >> Daily Standups sind nicht dazu da, tiefergehendes Wissen zu vermitteln. >> Dafür existieren andere Formate, und dafür sind Vor- und Nachbereitung >> sinnvoll. > > Ja, aber für die ist dann zu wenig Zeit. Das ist meine Beobachtung und > Erfahrung. Ich sehe es ja täglich wie es läuft. Es herrscht chronischer > Zeitmangel, der dazu führt, dass an anderer Stelle wieder gepfuscht > wird. So wenig die 15min auch sein mögen, so sehr fehlen sie dann > woanders. Offiziell läuft der Prozess und SCRUM, praktisch wird es > dauernd umgangen um irgendwie weiterzukommen. Daher ist es zweckmäßig > den formellen Prozess zu verschlanken oder lieber zu kippen, statt dafür > Zeit zu verbraten, nur um ihn offiziell einzuhalten. Seit ich kommerzielle Software entwickle, habe ich noch kein einziges Projekt ohne Zeitdruck erlebt. Aber wenn eine tägliche maximal fünfzehn Minuten lange Absprache des Teams eine unüberwindliche Hürde darstellt, hast Du auch mit klassischen Methoden des Projekt- und Teammanagement massive Probleme. Dann ist nämlich auch keine Zeit für die Erstellung ordentlicher Lasten- und Pflichtenhefte, halbwegs realistische Zeit- und Aufwandsplanungen, und die auch in solchen Projekten notwendige Kommunikation vorhanden. Und darunter leiden dann die Qualität des Produkts sowie die Gesundheit und Motivation der Mitarbeitenden. Ich glaube aber, Du mißverstehst da etwas. Denn die Kommunikation unter den Teammitgliedern muß ohnehin stattfinden. In klassischen Projekten gibt es häufig eine Mischung aus geplanten Meetings und dem Flurfunk, was leider mit zunehmender Größe des Teams und zunehmender Komplexität des Projekts immer schlechter funktioniert. In den Meetings müßten dann nämlich drölfzig Themen abgehandelt werden, aber weil alle wieder coden müssen und einige schon ins nächste Meeting müssen, bleibt am Ende immer etwas offen. Außerdem verleiten solche Mammut-Meetings dazu, daß hinterher niemand mehr weiß, was da alles besprochen wurde, es wurde zwar alles gesagt, aber nicht von jedem, und das einzig meßbare Ergebnis ist, daß die Kekse weg sind. BTDT. Der Flurfunk ist sogar noch gefährlicher, weil dabei in den meisten Fällen nur die aktuellsten und spannendsten Themen besprochen werden, nicht alle Teammitglieder dabei und informiert sind, und im Zweifelsfalls bestimmte, aber wichtige Informationen vergessen oder verfälscht dargestellt werden, wie beim bekannten Kinderspiel "Stille Post". Mir wird hier im Thread zu oft nach Kritikpunkten an agilen Methoden gesucht. Letzten Endes müßte es aber seriöserweise nicht nur um eine Kritik an agilen Methoden gehen, sondern vielmehr um den Vergleich mit anderen zur Verfügung stehenden Möglichkeiten. Kennst Du denn eine Methode des Projektmanagements, die ohne Fehl und Tadel ist und für jedes Projekt und Team jeder Komplexität und Größe perfekt funktioniert, und bei der der Zeitdruck geringer wird? Dann sollten wir unbedingt und aller schnellstens ein Manifest darüber schreiben und eine Beraterfirma dafür gründen... :-)
Joe schrieb: > Klar, ein McDonald's ist perfekt organisiert. Aber was macht man, wenn > ein Kunde eine französische Zwiebelsuppe haben will? Ein Koch, der bei > dem Laden arbeitet, würde sich vielleicht hinstellen und aus dem > vorhandenen Käse und Zwiebeln was zaubern. Sehr zum Mißfallen des > Managements, versteht sich. > > Die McDonaldisierung aka Scrum ist auch ein Versuch, dem > Fachkräftemangel zu begegnen. Leider fühlt man sich als akademisch > ausgebildeter Informatiker bei solchem Zirkus genauso deplatziert wie > ein Koch in einem McDonald's. Ja, diese McDonaldisierung ist problematisch. Bei einem Massengeschäft wie McDonald's mag das sinnvoll sein. Und dann wird eben keine Zwiebelsuppe gemacht. Aber das Geschäftsmodell lässt sich nicht auf alles andere übertragen. Aber sie versuchen es. Nun ist Softwareentwicklung für Kunden und Projekte eine hochspezifische Angelegenheit. Die Komplexität der Anforderungen dadurch zu reduzieren, dass man es in möglichst kleine Pakete zerstückelt und in Sprints abfrühstückt, funktioniert einfach nicht.
Mark B. schrieb: > Wie ist denn "gescheitert" definiert? Das haben die Ersteller der betreffenden Studien definiert, die ich aber leider nicht mehr finde. > Meines Erachtens existiert auch kein gesicherter Nachweis dafür, dass > Projekte durch SCRUM tatsächlich besser laufen. Wenn es den doch geben > sollte, so bitte ich um einen Link zu der entsprechenden Quelle. Naja, so ein gesicherter Nachweis müßte dann doch zuerst einmal von dem, der danach verlangt, akzeptiert werden... und warum sollte ich einen -- für jede denkbare Bedeutung der Worte -- "gesicherten Nachweis" erbringen? Ich habe schließlich meine eigenen Erfahrungen, daß meine agilen Projekte viel besser funktionieren und gleichzeitig trotzdem entspannter und angenehmer sind. Das reicht mir. Ich möchte hier niemanden missionieren und spreche deswegen nur für mich, aus meinen und über meine eigenen Erfahrungen -- und denen meiner Kollegen (zumindest wenn ich ihren Aussagen vertrauen darf, woran zu zweifeln ich allerdings keinerlei Anlaß habe). Wenn es Dich wirklich interessiert, dann hast Du doch dasselbe Internet mit denselben Suchmaschinen wie ich auch, kannst dieselben Informationen finden wie ich, und ihnen ganz nach Deinem Belieben ver- oder mißtrauen. Vielleicht ist diese Zuammenfassung [1] verschiedener (dort auch verlinkter) Studien ein Startpunkt für Dich, um Deinen Informationsdurst zu stillen. Ich würde mich freuen, wenn Du am Ende etwas dazu sagen könntest, was Du gefunden hast, und was Deine Meinung bestätigt oder Dich überrascht hat. Danke! [1] https://echometerapp.com/en/scrum-statistics/
Rudi R. schrieb: > Die Komplexität der Anforderungen dadurch zu reduzieren, dass man es in > möglichst kleine Pakete zerstückelt und in Sprints abfrühstückt, > funktioniert einfach nicht. Beziehungsweise die Portionierung selbst ist regelmäßig die eigentliche geistige Arbeit, wogegen die Pakete selbst abzuarbeiten recht anspruchslos ist. In dem Beispiel mit dem McDonalds würde es ganz bestimmt klappen, nach kurzer Zeit eine genießbare Zwiebelsuppe ins Sortiment aufzunehmen. Ein Problem taucht erst wieder auf, wenn einer eine italienische Minestrone haben will. Da braucht es wieder den Koch. Menschliches Wissen ist immer noch kaum durch Prozesse ersetzbar. Nimm 10 Typen von der Straße, kaufe eine medizinische Bibliothek, die besten und teuersten medizinischen Geräte sowie Breitbandverbindung zu ChatGPT. Das ersetzt keinen erfahrenen Arzt. Deswegen finde ich auch das Insistieren darauf, alle Lösungen für die Nachwelt zu dokumentieren, nur bedingt hilfreich. Das Nachschauen in der medizinischen Datenbank macht noch keinen Arzt.
Gerhard O. schrieb: > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ Richtig guter Artikel, danke! :-)
Ein T. schrieb: > Richtig guter Artikel, danke! :-) Holzschnittartig mit wahllos zusammengewürfelten banalsten "Argumenten" die man ja noch nie gehört hat, KI generierter Contentmüll halt. Die Kommentare sind viel besser.
Franko S. schrieb: > Holzschnittartig mit wahllos zusammengewürfelten banalsten "Argumenten" > die man ja noch nie gehört hat, KI generierter Contentmüll halt. Die > Kommentare sind viel besser. Wie süß, ein Troll. :-)
Ein T. schrieb: > Gerhard O. schrieb: >> > https://stackoverflow.blog/2020/06/29/does-scrum-ruin-great-engineers-or-are-you-doing-it-wrong/ > > Richtig guter Artikel, danke! :-) Find ich auch. "Ticket-driven architecture" - Prägnanter kann man die Kritik nicht äußern. Bin glatt neidisch, dass mir dieser Begriff nicht selbst eingefallen ist. "Features over robust code" habe ich auch beobachtet, ebenso "Complicated tasks get deprioritized": Es wird das gemacht, was schnelle und einfache Storypoints verspricht. Ich teile die Kritik in dem Artikel.
Bei Heise schreibt man auch von der "Scrum-Hölle": https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html
Ist halt mies wenn Scrum in ein kaputtes Umfeld eingebracht wird, in der Hoffnung auf Erlösung. Das kann Scrum nicht bieten, wird allerdings oft von Beratern als Lösung verkauft. Ich glaube, Scrum löst überhaupt kein ernsthaftes Problem. Und alle anderen Probleme kann man auch ohne Scrum bewältigen.
Reinhard S. schrieb: > Ein T. schrieb: >>> Wie viele scheitern jetzt daran? Runde 70%? >> >> Es ist leider schwierig, seriöse und belastbare Daten zu erhalten. Aber >> die letzten, die ich gesehen habe, nennen eine Erfolgsquote von 75,4 %. > > 75% der Scrumm-Projekte sollen innerhalb der geplanten Zeit und des > geplanten Budgets bleiben? Mit dem geplanten Funktionsumfang? Erscheint > mir unglaubwürdig. Da hast Du vollkommen: Es scheint nur so. Interessanterweise: andere nachprüfbare Zahlen hast Du nicht, nur „berechtigte Zweifel“. Ha-Ha-Ha. Gemeinsam ist den „Traditionalisten“, dass es Schuldige braucht: BWL‘er, Manager, agile Evangelistenn usw. - und natürlich Abschätzigkeit und Beleidigungen. Die meisten „Argumente“ haben selten etwas mit SCRUM zu tun, denn die Allermeisten Themen treten selbstverständlich in allen (Projektmanagement-) Methoden und Frameworks auf.
Uwe D. schrieb: > Gemeinsam ist den „Traditionalisten“, dass es Schuldige braucht: BWL‘er, > Manager, agile Evangelistenn usw. - und natürlich Abschätzigkeit und > Beleidigungen. Hier ein weiteres Zeugnis des Aufstands der traditionalistischen Code-Affen: (danke für den Link, rudi) https://www.heise.de/blog/Nur-Mut-Endlich-raus-aus-der-Scrum-Hoelle-9860999.html "Die Mehrheit der Kommentare stammt von Entwicklerinnen und Entwicklern, die beklagen, dass Scrum vom Management zweckentfremdet wird, um mehr Kontrolle auszuüben. Scrum wird also nicht so eingesetzt, dass sich ein Team damit selbst organisiert, wie es bei agilen Methoden eigentlich vorgesehen ist, sondern es wird als Projektmanagement-Werkzeug verwendet, dem alles andere untergeordnet wird. Statt "Individuals and Interactions over Processes and Tools" (wie es im agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum dominiert als Prozess alles. Dadurch wird Agilität im Keim erstickt, weil sie offensichtlich nicht gewünscht ist. Die traurige Wahrheit ist, dass in vielen Unternehmen nicht einmal Fake Agile vorherrscht, sondern eine schlimmere Variante: Dark Agile. Dabei geht es nur darum, auf dem Papier gut auszusehen, während Scrum in Wirklichkeit als Kontroll- und Steuerungsinstrument missbraucht wird. Genau das habe ich im letzten Blogpost als die schlimmste Variante beschrieben, wie man Agilität falsch leben kann." Und ich bin stolz, ein Traditionalist zu sein! Freiheit statt Agilismus!
Angehängte Dateien:
Ein T. schrieb: > In einem Artikel des seligen Dr. Dobbs Journal habe ich weiland eine > Studie gelesen, die eine Quote von 68 % gescheiterter Projekte angegeben > hat. Die Website ist leider offline, und leider kann ich diese Studie > auch in der Wayback Machine nicht finden. Da bei Scrum das Ziel während das Projekt läuft beliebig nach unten angepasst werden kann, müsste Scrum immer erfolgreich sein. Notfalls war es halt zum Schluss eine Forschungsarbeit wie es nicht geht. Erschreckend wenn 25% nicht mal das hinbekommen.
Michael B. schrieb: > Da bei Scrum das Ziel während das Projekt läuft beliebig nach unten > angepasst werden kann, müsste Scrum immer erfolgreich sein. Interessante Interpretation! Ich fürchte nur, dass es für diese Auslegung kaum Beifall vom Aufraggeber gibt, da dieser ein Ergebnis haben wollte. Wenigstens kann die Truppe dann sagen, "Hui, wir haben aber wenigstens Scrum erfolgreich betrieben". > Notfalls war es halt zum Schluss eine Forschungsarbeit wie es nicht geht. Na da wäre ich ja gern dabei, wenn das SO! präsentiert wird. :-) Das ursprüngliche Ziel ist ja eigentlich das Einarbeiten von Änderungen und das Finden der jeweils optimalen Lösung mit dem Ziel Kosten, Zeit und Qualität zu optmieren, bzw die Randbedingungen einzuhalten. An der Stelle kann es nicht mehr darum gehen, OB etwas gemacht wird, sondern nur noch WIE . Allenfalls kann man den Findungsprozess zur Machbarkeit eines Systems vorlagern und diese dabei nach Scrum-Richtlinien fahren (wobei ich dann sofort fragen würde, worin der Unterschied zu einer klassischen Machbarkeitsstudie in der Forschung liegen soll). Ein Misch-Masch des Vorgehens und Pendeln zwischen Koncept und Umsetzung und der Weise, dass mittendrin Anforderungen angenommen oder gegeben werden, die die Machbarkeit infragestellen, darf es nicht geben. Für jedes Projekt braucht es eine Vorstudie (und sei es nur ein kurzes Durchdenken der Geschichte durch einen erfahrenen Systemingenieur) die aufzeigt, ob ein System sicher machbar ist, wo es mehrere Wege gibt, welche davon risikoreich sein könnten und untersucht werden müssen und ob man gfs eine Machbarkeiststudie benötigt und was da hinein muss bzw welche Ziele die haben muss. Alle potenziellen show stopper müssen natürlich im Vorhinein geklärt werden, mitsamt Aufzeigen der möglichen minimalen und maximalen Qualität, Kosten und Zeitbedarf der Teillösung. Ab dann kann man entscheiden, ob man ein Risiko nimmt, um Tempo zu bekommen und dann Kosten hinnimmt, oder ob man Zeit investiert zur Sicherstellung und Einleitung von Sparmaßnahmen. Ja, das ist total old style und viel uncooler, als einfach anfangen und drauflos bauen, um dann super gail "Scrum-Zickzack" zu fahren. ES würde aber die eine oder andere Firma schon vor völlig nutzlosen Investitionen und tausenden überflüssiger Funktionen und Änderungen bewahrt haben.
Rudi R. schrieb: > "Complicated tasks get deprioritized": Es wird das gemacht, was schnelle > und einfache Storypoints verspricht. Das halte ich für den entscheidenden Satz! Mit Bezug zu meinem vorherigen Beitrag läuft es aber leider ganz genau so, dass man wichtige Entscheidungen nach hinten schiebt, weil man mit Scrum ein Alibi hat, nicht ausreichend über Anforderungen nachdenken zu müssen, erst einmal loslegen kann, um Tempo aufzunehmen und dann schaut, was man noch so braucht, da man "neue" Anforderungen jederzeit "agil" nachschieben darf. Das System zielt an der Stelle stark in Richtung des optimalen Zeitvektors. Kosten und Qualität sind noch nicht genau definiert. Die Umsetzer in der Truppe rüsten sich gegen viele potenzielle Anforderungen mit aufwändigen Universallösungen, Zusatzfunktionen und allem Möglichen, das am Ende keiner aber braucht und nur Zeit und Geld verbrät. Das System schwenkt daher zur Startphase bereits stark in Richtung des Qualitätsvektors, vorwiegend Unterrichtung "Menge und Funktionsumfang". Mittendrin kriegt dann einer mit, dass die Kosten explodieren und versucht Sparlösungen zu initiieren und untersuchen zu lassen. Dann werden Alternativen gesucht und diskutiert, die Zeit verbraten und kaum Qualität bringen. Am Ende wird wenig gespart, die Qualität sinkt, weil Funktion oder Güte weggelassen wird. Irgendwann merkt dann einer, dass die Zeit wegläuft und das Gesamtsystem wird versucht, in Richtung Zeit zu drehen und idealerweise den Kostenvektor beizubehalten. Damit braucht es schnell irgendwelche teuere Zwischen- oder Sonderlösungen, um überhaupt etwas hinzubekommen. Am Ende ist kein Geld und keine Zeit mehr, alles fertig zu bauen, weil die Zwischenlösungen Zeit und Budget verbraten haben und es fällt für das Zielsystem noch mehr Qualität und Funktion weg. Als Ergebnis gibt es ein System, das teuer und schlechter ist, als das Machbare, aber dennoch mehr Zeit verbraucht hat und völlig inkosistent gebaut ist, da die jeweiligen Entscheidungen zwischen Qualität, Zeit und Kosten einem jeweils zeitlich veränderlichen Verktor unterworfen wurden: Komponenten, die früh geplant und gebaut wurden, sind weitgehend vollständig, auch einigermaßen günstig gebaut, haben aber eine eher geringe Qualität, da man schnell drauf los gelegt und wenig geplant hat. Viel fehlt, sie hätten nochmal überarbeitet werden sollen, was dann aber nicht mehr passierte. In Einzelfällen sind sie so untauglich, dass sie ersetzt werden müssen oder aber die Qualität des Systems nach unten ziehen, wenn sie genutzt werden. Komponenten, die mittendrin geplant und gebaut wurden, sind mehr als vollständig, oftmals total überplant und überdesigned. Sie sind zwar ebenso noch ziemlich effektiv gebaut und produziert und haben auch eine eher hohe Qualität, sind aber relativ viel zu teuer, weil ein Teil der Funktionen gar nicht benötigt wird und ein weiterer Teil nicht genutzt werden kann, da hintere Komponenten abgespeckt werden mussten. Komponenten, die gegen Ende geplant und gebaut wurden, haben den höchsten und besten Funktionsumfang, da am Genauesten bekannt ist, was gebraucht wird. Sie sind aber entweder extrem teuer, weil sie mit teueren Sonderlösungen und Zukauf arbeiten, um Zeit reinzuholen, oder sie leiden unter dem Kostendiktat und werden funktionell abgespeckt, womit sie die einst geplanten Funktionen des Gesamtsystems noch mehr einschränken. Das trifft insbesondere auf schnell dahin gezimmerte Zwischenlösungen zu, die schnell für eine Messe oder Präsentation gemacht werden, weil die normale Zeitschiene geplatzt ist. Diese besitzen dann eine noch geringe Qualität, als jene der Gruppe 1. Weder sie noch die Originale können aber nochmal überarbeitet werden. Komponenten dieser letzter Gruppe leiden auch an den Randbedingungen, die durch die zu schlecht geplanten ersten Komponenten gesetzt wurden.
:
Bearbeitet durch User
J. S. schrieb: > kaum Beifall vom Aufraggeber Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei rauskommt.
Joe schrieb: > Statt "Individuals and Interactions over Processes and Tools" (wie es im > agilen Manifest formuliert ist) passiert genau das Gegenteil: Scrum > dominiert als Prozess alles. Das beobachte ich auch. Entwickler werden zu Implementieraffen abgestempelt. Ich sage es nicht, aber denke es bei vielen Entwickler: Warum machst du dir das Leben zu schwer? Es fehlt bei vielen die Reflektion darüber, was sie da fabrizieren. Ich erlebe Entwickler, die sich es schaffen, 20 mal praktisch den gleichen Codeblock hintereinander zu schreiben. Die Codeblöcke unterscheiden sich minimal und systematisch. Auf die Idee, 'ne Funktion zu zimmern, kommen die nicht. Ich sehe das Monate später, weil ich irgendwas anpassen muss, irgendeinem Bug auf der Spur bin. Und ich darf dann erstmal refaktorieren. Hätte er die Funktion direkt am Anfang gezimmert, hätte er viel Zeit gespart und die Bugs auch nicht fabriziert, weil ja 20 Code-Blöcke schwerer zu überblicken als 20 Funktionsaufrüfe und die Funktion selbst. Ich habe es ja oben irgendwo mal geschrieben: Ich bin der Überzeugung, dass Entwickler besser werden, wenn sie regelmäßig ihr Zeug diskutieren, am besten in lockerer Runde. Ich habe kürzlich erlebt, wie ich Wochen auf die Entwicklung eines Kollegen wartete. Vor zwei Wochen wurde sie in den Hauptzweig gemergt. Da war vieles falsch und ich durfte refaktorieren. Er hat viel komplizierte Zeilen hintereinander geklöppelt, anstatt gut händelbare Funktionen zu entwickeln. Zum Refaktorieren nehme ich gerne den Emacs wegen seiner Tastaturmakros. Das geht dann fix und der Werksstudent hat nicht schlecht gestaunt. Ich bin auch der Meinung, dass das, was der Kollege über Wochen entwickelte, in einem Drittel der Zeit hätte entwickelt werden können, wenn er wichtige Designprinzpien wie KISS und DRY verwendet hätte. Jetzt ist es so, dass man in die Spezifikation vom Kunden schauen kann (es geht um eine Schnittstelle), und die in den dortigen Tabellen beschriebenen Nachrichtentypen kann man nun praktisch direkt in den Code übernehmen, denn die Argumente meiner Funktion entsprechen zufällig auch der Reihenfolge der Spalten in den Tabellen: Name, Länge, Typ, Wert. Ich erinnere mich noch mit Grausen, was ein Kollege in meiner alten Firma gezimmert hatte. Er fing an, eine Schnittstelle zu programmieren. Dann folgte eine ähnliche Schnittstelle und kopierte er die Implementierung der ersten Programmierung, passte diese an. Das machte er ca. 40 mal. Ich kam frisch von der Uni und sagte, da müssen wir ran. Der Chef skeptisch, er war dagegen, weil er das in seinem Scrum nicht vorgesehen hat. Ich habe eine gemeinsame Oberklasse entwickelt und sehr, sehr viel Code eingespart. Es stellte sich heraus, dass ein Bug drin war. Nun war der Bug aber auch vorher drin, ca. 40 mal! Nach dem Refaktorierungen nur noch einmal. Behebung ging schnell. Es soll mir keiner erzählen, dass besagter Kollege den Bug in allen 40 Klassen behoben hätte. Und man stelle sich vor, der Entwickler hätte von Anfang von DRY beherzigt. Er hätte initial viel Zeit gespart und ich hätte keine Refaktorierung machen müssen. Das war so offensichtlich, aber ich war der Buhmann. Schlechte Entwickler sind das Problem und das Niveau hebt man an, wenn Raum für Diskussionen und Weiterbildung geschaffen wird. Ich finde es auch immer wieder erstaunlich, dass viele Entwickler sich auch nicht trauen, eine Funktion rekursiv zu formulieren. Oft geht das einher mit hoher Eleganz und Verständlichkeit. Ich habe mit besagten Werksstudenten eine Funktion geschrieben (im Zuge des Refaktorierens), in der Rekursion auftrat. Er wollte es sich schon ganz kompliziert machen, aber es mit der Rekursion sehr schnell abgefrühstückt. Ich hoffe, er lernt davon. Joe schrieb: > Und ich bin stolz, ein Traditionalist zu sein! Freiheit statt Agilismus! Ich denke, Agilität ist nicht unbedingt falsch, da sie ja Personen über Prozesse stellt. Die Scrum-Hektik ist das Problem. Ich sehe mich weder als Traditionalist noch als Progressiven. Ich bin ein Anhänger des gesunden Menschenverstandes. Der Entwickler steht im Mittelpunkt und er muss seine Fähigkeiten ständig ausbauen. Und ich kann jedem Entwickler raten, regelmäßig auszuscheren und mal etwas zweckfremdes zu machen, sich intellektuell mit der Softwareentwicklung zu beschäftigen. Bücher gibt's genug. Habe ich schon mal geschrieben, dass ich von einem Kollegen angeschrien wurde? Ich schrieb ihm ganz freundlich, dass Teile seines Codes unter gewissen Umständen nicht funktionieren können. Ich hätte das gerne diskutiert, ich hätte ihm geholfen, es zu beheben. Er meinte, wenn er Zeit fände. Dann gingen zwei, drei Wochen ins Land. Er schien überlastet. Ich änderte den Code, weil es gemeinsamer Code ist und wir eine gemeinsame Veranwortung dafür haben, als Team. Dann sah er es, platzte rein und schie mich an: "Warum hast du das geändert? Mein Code funktioniert! Die Tests zeigen es!" - Er hatte offenbar noch nie gehört, dass Tests die Fehlerfreiheit von Code nicht zeigen können. Rückblickend muss ich sagen: Er war so ein typischer Entwickler, der einfach drauflos programmierte, nicht reflektierte und deshalb irgendwann ins Schwimmen kam und er letztendlich unterging. Er verließ das Unternehmen wenige Monate später. (Auf LinkedIn sehe ich, dass er heute "Certified Scrum Product Owner" ist.) Ich wusste damals auch nicht, dass er nur Fachinformatiker war, während ich mit einem Diplom aufwarten konnte, vielleicht aber nicht seine Berufserfahrung hatte, aber sehr wohl mehr Programmiererfahrung. Was mir auch aufgefallen ist. Mir sind schon mehrfach Leute begegnet, die mich davon abhalten wollen, etwas auf meine Art zu programmieren oder etwas zu refaktorieren, indem sie mit so Schlagwort wie 80:20 kommen, also Pareto. Dass 20 % zu 80 % des Ergebnisses beitragen und ich mich da nicht so hineinsteigern solle. Nun ist das ein Totschlagargument, weil man ja nicht wissen kann, auf welcher Seite man gerade entwickelt. Außerdem bezahlt der Kunde nicht für 80 %, sondern für 100 %, also muss man auch für die fehlenden 20 % etwas entwickeln. Und es sollte ingesamt sehr effizient und vernünftig passieren, egal ob es für die 20 % oder für die 80 % sind. Daher ist Code-Qualität so wichtig, darum sind KISS und DRY so wichtig, oder auch das Demeter-Prinzip. Das anzusprechen, ist als theoretisch verpönt und ich spüre geradezu die Abneigung dagegen. weil man eventuell nachdenken muss. Bei vielen Menschen stelle ich fest, dass die Angst davor haben, wenn sie mit Niveau konfrontiert werden. Viele Menschen in meinen Altern wehren sich mit Händen und Füßen dagegen, mal in ein klassisches Konzert zu gehen, denn die Musik könnte ja fordernd sein.
Rudi R. schrieb: > Was mir auch aufgefallen ist. Was mir aufgefallen ist: Softies schimpfen gerne über andere Softies... ;-) Rudi R. schrieb: > Viele Menschen in meinen Altern wehren sich mit Händen und Füßen > dagegen, mal in ein klassisches Konzert zu gehen, denn die Musik könnte > ja fordernd sein. Na dann schick sie mal in ein zeitgenössisches Konzert. Das ist garantiert fordernd.
:
Bearbeitet durch Moderator
Michael B. schrieb: > J. S. schrieb: >> kaum Beifall vom Aufraggeber > > Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die > Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei > rauskommt. Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die Prioritäten verschiebt?
Uwe D. schrieb: > Michael B. schrieb: >> J. S. schrieb: >>> kaum Beifall vom Aufraggeber >> >> Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die >> Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei >> rauskommt. > > Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in > der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die > Prioritäten verschiebt? Eben dann ist er schuld und kann die Schuld nicht bei die Firma suchen die sein Projekt umsetzen sollte.
Ich glaube hier gibt es ein Verständnisproblem: Uwe D. schrieb: > Michael B. schrieb: >> J. S. schrieb: >>> kaum Beifall vom Aufraggeber >> >> Der sitzt bei Scrum ja mit im Boot, der hat allem zugestimmt und die >> Entwicklung so begleitet, dass er mit Schuld ist, wenn so wenig bei >> rauskommt. > > Es geht nicht um Schuld, sondern Mitsprache. Und wenn der AG nicht in > der Lage ist sein Produkt zu beschreiben oder 1.000x ändert oder die > Prioritäten verschiebt? Seit wann sitzt der Auftraggeber im SCRUM Team? Und seit wann leitet der irgendetwas? Der sitzt in einer anderen Firma, gfs einer anderen Abteilung und will nur das Ergebnis. Leiten sollten sich das Scrum Team doch angeblich komplett selber?
Martin K. schrieb: > Seit wann sitzt der Auftraggeber im SCRUM Team? Er stellt den Product Owner im Team. .
Michael B. schrieb: > Martin K. schrieb: >> Seit wann sitzt der Auftraggeber im SCRUM Team? > > Er stellt den Product Owner im Team. Wer macht denn sowas?
Ein T. schrieb: > Michael B. schrieb: >> Martin K. schrieb: >>> Seit wann sitzt der Auftraggeber im SCRUM Team? >> >> Er stellt den Product Owner im Team. > > Wer macht denn sowas? Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG gestellt wird.
Rudi R. schrieb: > Tatsächlich wird Pair-Programming nur wenig Zeit gegeben, > obwohl da ein Greenhorn von einem Erfahrenen, der ich ja > mittlerweile bin, sehr gut lernen kann. Genau darum funktioniert Scrum bei dir nicht. Du bist halt ein Erfahrener, da haben die kleinen Kinder nix verloren und vergeuden nur deine Zeit. Wieso die überhaupt deine Luft atmen dürfen, weißt du bis heute nicht.
Mark B. schrieb: > Es gibt manche Branchen, in denen ist "Scheitern" der Normalfall. Zwei > Beispiele: Bauwesen und Eisenbahn. Es gibt nahezu kein Großprojekt im > Hoch-/ Tiefbau, in dem die ursprünglich geplanten Termine eingehalten > werden. Siehe Elbphilharmonie, Stuttgart 21, Berliner Flughafen, ... Garnicht so groß, ist hier im Straßenbau der Normalfall. Die Freigabe der sanierten Kreisstraße 90 verzögert sich leider um 5 Wochen, weil unerwartete Bodenverhältnisse vorgefunden wurden. Die Sanierung der Brücke Bahnhofstraße konnte leider noch nicht wie geplant fertiggestellt werden, weil Bohrungen auf unerwartete Hindernisse stießen. Der Ausbau der B79 verzögert sich auf unbestimmte Zeit, weil ... Das sind keine Flughäfen, sondern wenige km Straße! Ich habe den Eindruck, dass die Planer durchweg mit Unfähigkeit glänzen.
Ein T. schrieb: > Michael B. schrieb: >> Martin K. schrieb: >>> Seit wann sitzt der Auftraggeber im SCRUM Team? >> >> Er stellt den Product Owner im Team. > > Wer macht denn sowas? Stopp: Unter Auftraggeber verstehe ich nicht den PO, sondern eher das PM oder eine externe Firma. Uwe D. schrieb: > Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG > gestellt wird. D.h. der funkt euch dann ständig die Anforderungen rein? Dann sind die Aufwände ja nicht kalkulierbar. Wie läuft das dann mit Verrechnung? Stundenbasis, wenn sich was tut? Für mich als Selbständigen scheidet das total aus. Es braucht eine eng umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. Sie dazu auch: Beitrag "SCRUM und die Arbeitsweise von Selbständigen"
Martin K. schrieb: > Für mich als Selbständigen scheidet das total aus. Es braucht eine eng > umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. Für dich ist damit Scrum auch völlig unrelevant. Du machst geliefert wie bestellt ein Wasserfall oder V Modell.
Rudi R. schrieb: > Es gibt Neuigkeiten zu "meinem" Scrum-Projekt. Meine Warnungen an die > richtige Stelle adressiert, haben nun dazu geführt, dass andere Leute > mit dem Projekt betraut werden. Es hört nun hoffentlich auf mit der > Sprinterei und Scrummerei. Auch der personelle Zusammensetzung des alten > Teams war ja ungünstig, weil da kaum jemand länger als zwei Jahre in der > Firma war, d.h. viele Domänen- und Frameworkwissen einfach nicht da war. > Vielleicht mag ja das Scrum für irgendwelche Casual Games oder Websites > vernünftig sein und wer immer Scrum macht und nicht anderes kennt, der > wendet Scrum auf jedwedes Problem an. Das schrieb ich im Februar. Das neue Team ist etabliert, arbeitet seit April. Was hat sich nicht geändert: 1. Es gibt Sprints. Was hat sich geändert: 1. Es gibt viele kleine Commits. 2. Es wird schnell zusammengeführt, was die Entwickler programmieren. Das Gluckenproblem ist größtenteils weg. Das Gluckenproblem hatten wir bei einem Entwickler, der wochenlang an einer Sache arbeitete, anstatt schon mal etwas zu pushen, dass ich mir das hätte mal anschauen können. Ich erwähnte ja, dass ich viel refaktorieren musste. 3. Es gibt weniger Besprechungen. Es gibt eine wöchentliche Besprechung von einer knappen Stunde. Das war's. 4. Es gibt keine ausufernden Sprintplanungen. Wir hatten ja zuvor eine Scrum-Masterin, die tagelang herausarbeitete, welche Tasks im nächsten Sprint sein müssen. Das war ja genau diese Besprechungen, die mich so ankotzten, denn in der Zeit hätte ich ja vieles schon machen können. 5. Es gibt kein Sprint-Ziel. Wenn man was nicht schafft, ist es auch wurscht. Die zu mir zugwiesenen Tasks sind so allgemein formuliert, dass eine Definition of Done schon schwierig ist. 6. Gesunder Menschenverstand ist wieder eingekehrt. 7. Es macht wieder Spaß.
Heißt das nun, ihr habt Scrum faktisch abgeschafft, oder modifiziert? Das hier: Rudi R. schrieb: > 1. Es gibt Sprints. passt irgendwie nicht zu dem: Rudi R. schrieb: > 5. Es gibt kein Sprint-Ziel. Kingt nach ziellosem Entwickeln. Wodurch definiert sich dann ein Sprint? Zeitraster? Michael B. schrieb: > Martin K. schrieb: >> Für mich als Selbständigen scheidet das total aus. Es braucht eine eng >> umrissene Aufgabe, die so wie bestellt auch abgearbeitet wird. > > Für dich ist damit Scrum auch völlig unrelevant. So sehe ich das auch.
Martin K. schrieb: > Ein T. schrieb: >> Michael B. schrieb: >>> Martin K. schrieb: >>>> Seit wann sitzt der Auftraggeber im SCRUM Team? >>> >>> Er stellt den Product Owner im Team. >> >> Wer macht denn sowas? > > Stopp: Unter Auftraggeber verstehe ich nicht den PO, sondern eher das PM > oder eine externe Firma. Dein Verständnis bildet nur eine Möglichkeit ab. Selbstverständlich kann der Endkunde auch der Auftraggeber sein. Vielleicht in Deiner bisherigen Welt nicht. Beispiel: Fraunhofer IPK entwickelt ein Messtool für Schmelzanlagen (Glas). Das ist natürlich kein Serienprodukt. > > Uwe D. schrieb: >> Habe ich regelmäßig, auch in Großprojekten, das der PO durch den AG >> gestellt wird. > D.h. der funkt euch dann ständig die Anforderungen rein? > Häh? Der PO legt die Anforderungen zusammen mit seinem Fachleuten fest schreibt diese in EPICS/FEATURES/USER STORIES und bespricht diese mit dem SCRUM Team im Refinement… Der PO legt fest was wichtig ist und gibt die Marschrichtung vor. Du hast den Sinn und Nutzen offenbar nicht verstanden. Und wenn der Endkunde - aka Auftraggeber - sagt STOPP, dann ist es eben so. Wir bekommen die Sprintziele bezahlt und müssen diese natürlich auch wie vereinbart liefern (inkl. State of the art). Und natürlich behalten wir als AN eine Beratungspflicht, falls der PO etwas ziemlich „blödes“ will - das ist ja aber das normalste Ding. Gesetzliche Regeln gelten natürlich auch bei SCRUM.
:
Bearbeitet durch User
Rudi R. schrieb: > 3. Es gibt weniger Besprechungen. Es gibt eine wöchentliche Besprechung > von einer knappen Stunde. Das war's. > 6. Gesunder Menschenverstand ist wieder eingekehrt. > 7. Es macht wieder Spaß. Als ich das gelesen habe, habe ich mir erstmal gedacht, dass du tatsächlich als Person in einer modernen Welt in der Software-Entwicklung völlig ungeeignet bist. Man kann das ja kurz zusammenfassen: 3. Die lassen mich endlich in Ruhe, ich kann meinen Kram machen so, wie ich es schon immer gemacht habe! Damals war es gut! Okay, heute knacken meine Knochen, und meine Haut kriegt immer mehr Falten, aber DAMALS WAR ES GUT! 6. Ich habe es schon immer besser gewusst, die anderen sind alle dumm, was für ne Versammlung von modernen Wichsern, ICH ICH kann es! Zu 7.: Deine Bude geht den Bach runter. Wer nicht in der Lage ist, vernünftige Konzepte wie Scrum, Scrum 2, Kanban etc. nicht nur zu lesen, sondern zu verinnerlichen, da würde ich als Geschäftsführer eine möglichst knappe Abfindung auf die Kündigung drauf legen, um solche Leute los zu werden. Und ich würde auch darauf schauen, Kunden, die so ticken, ebenfalls nach und nach abzustoßen.
Carsten P. schrieb: > Genau darum funktioniert Scrum bei dir nicht. Du bist halt ein > Erfahrener, da haben die kleinen Kinder nix verloren und vergeuden nur > deine Zeit. Wieso die überhaupt deine Luft atmen dürfen, weißt du bis > heute nicht. Endlich mal jemand der das versteht. Mein Chef meint immer man müsse auch mit Low Performern arbeiten und redet immer was von "weniger Arroganz" usw. Unverständlich!
:
Bearbeitet durch User
Cyblord -. schrieb: > Endlich mal jemand der das versteht. Mein Chef meint immer man müsse > auch mit Low Performern arbeiten und redet immer was von "weniger > Arroganz" usw. Unverständlich! So unverständlich ist es gar nicht, falls du das ernst gemeint hast. Manche Leute kleben halt an ihrem Job wie in einer Behörde. Da wurde schon immer alles genau so gemacht, wieso sollten wir denn da was ändern, da könnte ja jeder Dahergelaufene kommen und mir sagen, dass ich mich zu ändern habe. Es soll Leute geben, die Depressionen bekommen haben bei einer Umstellung von Fax auf E-Mail. Der Unterschied, um aufs Thema zu kommen, zwischen Meeting und Scrum -- oder zwischen Individuen und Teams ist, dass in einem guten Team nicht darum geht, wer schuldig ist an einem Fehler, sondern darum, gemeinsam das Ziel zu erreichen. In einem klassischen Unternehmen braucht man Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in Geld umzurechnen und sie dann rauszuschmeißen. In einem modernen Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Und statt dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um Tests und Automatisierung in der Software-Entwicklung, damit das keinem mehr passiert. So habe ich das jedenfalls zB bei der DATEV kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. Das hat aber auch viel mit Charakter zu tun, unter anderem einem so guten Selbstbewusstsein, dass man dazu steht, auch mal Mist zu bauen. Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den Vorgesetzten. Und genau dann kann man auch ein paar Steine mitschleppen, die im Team genau diesen einen Job machen und geistig nicht mehr willens sind, etwas Neues zu machen. Das Team ist dann flexibel genug und kann das kompensieren.
:
Bearbeitet durch User
Carsten P. schrieb: > dass in einem guten Team nicht > darum geht, wer schuldig ist an einem Fehler, Du hast aber schon mitbekommen, dass das Aufarbeiten von Fehlern ein integraler Bestandteil des SCRUM-Prozesses ist? Es geht ja vor allem um die inhaltliche Verbesserung der Zusammenarbeit, z.B. Art und Umfang der Kommunikation, die Menge der vorgelagerten Konzeptarbeit, Aufwand für Prüfungen am Arbeitsplatz vor der Weitergabe an Kollegen. Dafür reserviert Scrum ja sogar Termine im Prozess. Da kommt man um Kritik an Falschem nicht herum. Und: Carsten P. schrieb: > die Fehler auf andere zu schieben, und fixt sie einfach. Es geht nicht ums "Verschieben", sondern um das "Benennen". Wenn man von Teammitgliedern ein ständiges Lernen und sich-Verbessern fordert, braucht es auch Anhaltspunkte dafür. Spontanes Kompensieren kann man für schnelle ad hoc Tätigkeiten nutzen, wenn schnell eine Lösung her muss. Mal eben aber an den Tasks anderer herumdoktern, widerspricht auch irgendwo der Scrum-Strategie. So entsteht ja wieder ein Chaos nach dem Motto jeder macht alles und vorgelagerte Taskplanungen werden konterkariert. Ein stillschweigendes Korrigieren kann sogar dazu führen, dass das System immer mehr dahin geht, weil sich einige angewöhnen, "schnell" zu arbeiten und die Fehlersuche auf andere verlagern.
Carsten P. schrieb: > In einem klassischen Unternehmen braucht man > Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in > Geld umzurechnen und sie dann rauszuschmeißen. In einem modernen > Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler > behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Und statt > dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um > Tests und Automatisierung in der Software-Entwicklung, damit das keinem > mehr passiert. So habe ich das jedenfalls zB bei der DATEV > kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht > jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört > einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. (...) > Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal > passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den > Vorgesetzten. Ich lese das sorgfältig - aber es bleibt für mich die Frage, wozu ein "modernes Unternehmen", das bereits eine gute Fehlerkultur und Teststrategie hat, dann so ein Scrum braucht. Genausowenig wie ein gute Ehe die ganze Branche der Eheberater braucht und auch auf irgendwelche stereotypen Rituale und Zeremonien scheissen kann.
Moin, beinhalten Eure Scrum Mitglieder auch Kollegen von der HW Seite? Oder arbeitet man nur mit geprüfter, fertiger Elektronik Baugruppen-HW? Arbeiten die Kollegen da manchmal noch in parallel um HW zu optimieren oder zu debuggen? Wie sieht da die Zusammenarbeit diesbezüglich aus und laesst sich das auf einen gemeinsamen Nenner bringen? Diesen Aspekt habe ich hier noch nicht bemerkt. Finde ich aber wichtig. Gruß, Gerhard
:
Bearbeitet durch User
Carsten P. schrieb: > So unverständlich ist es gar nicht, falls du das ernst gemeint hast. > Manche Leute kleben halt an ihrem Job wie in einer Behörde. Da wurde > schon immer alles genau so gemacht, wieso sollten wir denn da was > ändern, da könnte ja jeder Dahergelaufene kommen und mir sagen, dass ich > mich zu ändern habe. Es soll Leute geben, die Depressionen bekommen > haben bei einer Umstellung von Fax auf E-Mail. Es geht nicht um das Kleben an einem Job. Es geht auch nicht behördenartig zu. Nur weil etwas nue ist, ist es nicht besser. Das hat man in der SW-Entwicklung immer und immer wieder erlebt. Und was ist die Quintessenz daraus: Sei ein guter Entwickler und verbessere dich stetig. Setze deinen Verstand ein. Methodik entwickelt keine Software. Es ist der denkende Mensch. Die Methode bringt weder die richtigen Algorithmen noch die richtige Architektur hervor. > > Der Unterschied, um aufs Thema zu kommen, zwischen Meeting und Scrum -- > oder zwischen Individuen und Teams ist, dass in einem guten Team nicht > darum geht, wer schuldig ist an einem Fehler, sondern darum, gemeinsam > das Ziel zu erreichen. In einem klassischen Unternehmen braucht man > Controller, um auf Menschen zu zeigen, um ihre persönlichen Fehler in > Geld umzurechnen und sie dann rauszuschmeißen. Es sollte jedem bewusst sein, dass da eine gewisse Effizenz ist. Niemand hat Verständnis mit Sohnemann, wenn man ihn drei Aufgabe gibt: Post einwerfen, Lebensmittel einkaufen und den Anzug aus der Reinigung zu holen, er aber dreimal in die Stadt fährt, obwohl Reinigung, Briefkasten und Supermarkt direkt beieinander stehen. > In einem modernen > Unternehmen braucht man sie nicht, weil das Team gemeinsam den Fehler > behebt, eingedenk dessen, dass jeder mal nen Bug eincheckt. Dieses Bewusstsein gibt es auch in klassischen Unternnehmen. Wenn man aber Zeit verballert und alles in Sprints kaputtschnürt, dann bleibt wenig Zeit für Fehlerbehebung. > Und statt > dann Fingerpointing zu betreiben, kümmert sich so ein gutes Team um > Tests und Automatisierung in der Software-Entwicklung, damit das keinem > mehr passiert. Fehler muss man ansprechen, sonst gibt es ja keine Verbesserung. > So habe ich das jedenfalls zB bei der DATEV > kennengelernt. Da gibt es keine Obstschalen für alle, und man geht nicht > jeden Abend Tanzen wegen erzwungener Gemeinschaft, sondern man hört > einfach auf, die Fehler auf andere zu schieben, und fixt sie einfach. Hat nichts modernen Unternehmen zu tun. > Das hat aber auch viel mit Charakter zu tun, unter anderem einem so > guten Selbstbewusstsein, dass man dazu steht, auch mal Mist zu bauen. Ja, richtig. > Und wenn sich alle dieser Tatsache bewusst sind, dass das halt allen mal > passiert, gibt es kein "DUUU bist schuld!" mehr, auch nicht von den > Vorgesetzten. > Fände ich nicht schlimm. Man lernt für gewöhnlich aus Fehlern, also muss man sie benennen. Wie oft habe ich als Entwickler in den letzten 30 Jahren falsches programmiert. Da schließe ich die Zeit als 12-jähriger ein, als ich mit QBasic programmiert habe, aber natürlich auch später, als ich längst Senior-Entwickler war. > Und genau dann kann man auch ein paar Steine mitschleppen, die im Team > genau diesen einen Job machen und geistig nicht mehr willens sind, etwas > Neues zu machen. Das Team ist dann flexibel genug und kann das > kompensieren. Scrum ist ja nichts neues, sondern schon wieder 20 Jahre alt und meines Erachtens gescheitert. Scrum ist die Illusion, die jedem noch so inkompetenten Entwicklerteam einflüstert: "Tschakka, ihr schafft das."
> Carsten P. schrieb: > konterkariert. Ein stillschweigendes Korrigieren kann sogar dazu führen, > dass das System immer mehr dahin geht, weil sich einige angewöhnen, > "schnell" zu arbeiten und die Fehlersuche auf andere verlagern. Stillschweigend sollte man natürlich nicht korrigieren. Es gibt ja mehrere Arten von Fehlern: 1. Schussligkeitsfehler. Man erkennt ja am Code drumherum, dass der Entwickler sowohl fachlich, algoirithmisch und architektonische auf der Höhe ist oder nicht. Ich korrigiere dies, schreib 'ne Mail an den Entwickler. Es gibt Leute, die dann austicken. Diese sind dann bei mir dann unten durch. Ich habe auch schon solche Korrekturen und Mails an meinem Code erlebt, war aber nicht am Austicken, obwohl die Person hätte erkennen müssen, dass es nur ein Schussligkeitsfehler ist, es aber eine Belehrung gibt hinsichtlich der anderen Archtitektur, Algorithmus usw. Womit wir zur nächsten Fehlerart kommen. 2. Fehler hinsichtlich der Architektur, des Designs und des Algorithmus. Da muss man dann auch schon weiter ausholen und das würde ich persönlich besprechen. Leider ist es so, dass vielen diese Themen komplett abhold sind. Wenn ich erkläre, bitte nicht Polling implementieren, sondern das Beobachter-Muster einsetzen, dann stoße ich da schon an Grenzen. 3. Fachliche Fehler gibt es auch noch, wenn jemand die Spezifikation falsch verstanden hat. Sollte man klären wie 2., aber das Kompetenzgefälle ist da nicht so groß, als dass sich jemand gekränkt fühlt könnte. Ich habe auch schon erlebt, dass jemand einen kleinen Algorithmus 1:1 umsetzte, einen Fehler meinte erkannt zu haben, ohne aber verantwortungsbewusst es ohne diesen Fehler zu implementieren. Der Fehler war eine triviale Definitionslücke. Ich weiß rückblickend nicht, ob er schon mit manchen Leuten im Clinch lag und vielleicht deshalb das Unternehmen verließ. Mir kam das seltsam vor und ich mag es auch nicht, wenn jemand seinen Verstand an der Garderobe abgibt, oder ob da schon ein Vermeidungsverhalten vorlag, weil irgendwas vorgefallen ist. Er traute sich vielleicht gar nicht mehr, den Fehler selbst anzusprechen oder einfach eigenmächtig die Definitionslücke zu schließen. Das wäre in der Tat ein kulturelles Problem, wenn die Chefs/Projektleiter einschüchternd auf die Leute einwirken. Aber das kann Scrum weder abstellen noch wird es durch Scrum befördert. Wir hatten ja wirklich auche inen Projektleiter, der bei manchen Leuten (v.a. beim Kunden) gut ankam, aber auch seine persönlichen Defizite hatte und möglicherweise aufgrunddessen, dass er nur Quereinsteiger war (Elektrotechniker, ohne Algorithmenkompetenz), Diskussionen schnell abwürgte. Ich Anekdote habe ich ja schon mal erzählt, dass er aus dem Bauch heraus eine Entscheidung traf, wo ich dann sagte: "Wollen wir das nicht mal diskutieren?" Denn ich sah sofort Probleme. Er war zur Diskussion nicht bereit, ein Entwickler setzte es um und ich habe die ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte.
Cyblord -. schrieb: > Das ist wie mit dem Kommunismus. Er ist überall gescheitert. Aber > natürlich nicht weil er schlecht ist. Er wurde immer nur schlecht > umgesetzt. Naja, einerseits kann man vergessen dass sich jeder nur so viel nimmt wie er braucht, weil jeder will immer mehr haben und wenn dort im Regal Brot, Kohl und Schokoriegel liegen, dann würde sich der erste seinen Einkaufskorb mit allen Schokoriegeln voll machen und die anderen bekommen dann nur noch Brot und Kohl. Der Kommunismus funktioniert aber eben nur genau dann, wenn man Ressourcen im Überfluss hat. Und das nicht weil man dafür im Überfluss leben muss, es geht dabei einfach nur um die Leute welche dabei immer an der Spitze sind. Das sieht man auch an Berlin, die Sozis dort geben das Geld mit beiden Händen aus und können ohne Länderfinanzausgleich nicht ein Jahr überleben, weil es ihnen einfach aus den Fingern rinnt. Die geben aber auch Millionen für nutzlose Projekte aus, zum Beispiel die Straßen welche sie verbarrikadieren und dort temporär Bäume in Pflanzkübel auf die Straße stellen. Die Autofahrer müssen dann Umwege fahren und verpesten die Luft, sorgen für mehr Lärm und Verkehr in anderen Straßen. Ich wette die Leute von SPD oder Grünen leben dort und wollen ihre Ruhe haben, deshalb packen sie da für ein paar Millionen Euro diese Pflanzkübel hin.
Gerhard O. schrieb: > Arbeiten die Kollegen da manchmal noch in parallel um HW zu optimieren > oder zu debuggen? > > Wie sieht da die Zusammenarbeit diesbezüglich aus und laesst sich das > auf einen gemeinsamen Nenner bringen? Wir machen Hardware und Software. Während der Woche schafft jeder was er kann, stimmt sich mit den Leuten ab die für seine Arbeit notwendig sind und am Freitag setzt man sich noch mal zusammen, das kann aber in Fällen wo viel geklärt werden muss dann über mehrere Stunden gehen, so dass man dann auch mal erst 21 Uhr wieder zu Hause ist. Meist hat man die Dinge aber schon während der Woche besprochen und am Freitag wird quasi alles rekapituliert und für die nächste Woche geplant. Etwa jeden Monat trifft man sich mit dem Auftraggeber, aber das ist eigentlich auch dynamisch und je nach Notwendigkeit. Es müssen auch nicht alle mit dabei sein. Scrum hatten wir zwar in der Uni beim Projektmanagement, aber in der Art nutzt man es bei uns nicht. Änderungen werde sofort umgesetzt, denn man will ja keine Zeit damit verschwenden sinnlose Dinge zu tun. Wir sitzen aber quasi alle in einem Raum, die Firma ist nicht so groß und die Kommunikation ist einfach. Wenn irgend etwas ist, dann kommt man mal kurz rüber und klärt das. Das finde ich so gut, habe aber auch nie in einer wirklich großen Firma gearbeitet und weiß nicht wie es da so ist.
Rudi R. schrieb: > Scrum ist ja nichts neues, sondern schon wieder 20 Jahre alt und meines > Erachtens gescheitert. So hart würde ich es nicht formulieren, aber man muss sich eingestehen, dass so wie Scrum vielfach betrieben wird, nichts Neues gebracht- und auch keine Probleme behoben hat. Wenn als Beispiel der Informationsaustausch unter den Teammitgliedern nicht funktioniert, dann wird das mit Scrum meistens schlechter, weil alle denken, dass das ja hetzt geregelt ist. Man befolgt die Scrum-Regeln und nimmt an den meetings teil und alles ist gut. Rudi R. schrieb: > ein Entwickler setzte es um und ich habe die > ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. > Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte. Das ist ein schönes Beispiel. Jeder macht was er will und man arbeitet gegen- statt miteinander. Bevor man so irgendwas einführt und mit Begriffen wie "Dynamik" und "Agilität" um sich wirft, um die Performance zu steigern, müssen zunächst die basics gelegt werden, d.h. die Mitarbeiter dazu angehalten werden, zu einem gemeinsamen Arbeitsstil zu gelangen. Wenn das nicht der Fall ist, kriegtst du nichts zusammen.
Joe schrieb: > Ich lese das sorgfältig - aber es bleibt für mich die Frage, wozu ein > "modernes Unternehmen", das bereits eine gute Fehlerkultur und > Teststrategie hat, dann so ein Scrum braucht. Genausowenig wie ein gute > Ehe die ganze Branche der Eheberater braucht und auch auf irgendwelche > stereotypen Rituale und Zeremonien scheissen kann. Auf die einzelne Persönlichkeit von einem "idealen" Entwickler bezogen hast du absolut Recht. Ich sehe Scrum oder auf noch weniger starre Regeln basierte Konzepte wie Scrumban da auch positiv. Nochmals auf die DATEV bezogen, wo ich es eben so kennengelernt habe, gab es auch mal Streit über Themen, ob eine private Variable mit _-Präfix oder ohne definiert werden sollte und ob "this." geschrieben werden sollte oder nicht (C#). Ich sage es mal so: Wenn Teams sich über solche Dinge streiten, muss das Produkt echt gut sein, denn sonst hätten die Leute Anderes zu tun ;-) Anders herum geht es aber so: Wenn Individuen sich nichtmal an Scrum gewöhnen können, ist das Projekt schon zum Scheitern verurteilt. Wenn sie es alle miteinander im Sinn von einem Miteinander können, braucht man Scrum nicht mehr oder nur als Maßstab an der Wand, ohne dass man sich da jeden Morgen treffen und messen muss. Dann sollte die Entwicklungsumgebung die Arbeit strukturieren, etwa "Oh, Bug, mein Thema, den nehm ich mir und fixe ihn!" Ich kann nur nochmals von der DATEV erzählen. In dem Team damals habe ich den Projektleiter angequatscht, ob ich (externer Mitarbeiter) zwei Stunden für das Thema LINQ und ForAll kriegen kann. Er sagte "ja, klar!", alle waren da, manche waren danach angestrengt und haben Nachfragen gestellt, und nachdem dann alle bereit waren, das Konzept zu antizipieren, wurde der gesamte Code innerhalb von 3 Monaten doppelt so schnell und auch noch zuverlässiger trotz Parallelisierung. Und der eine Kollege, der sich partout nicht beteiligen wollte, hat sein Zeug gemacht wie bisher, und niemand hat in seinen Code gehackt, um sein Ego nicht zu beißen. Das Projekt ist an diesem einen nicht gescheitert. Aber klar, wenn du viele solche Totalverweigerer im Team hast, die nur Fingerpointing betreiben wollen, um ihren Arsch zu retten, hilft Scrum auch nicht. Hier kommt es freilich auch sehr auf die Teamleitung und die höheren Ebenen an. Bei der DATEV war es damals nach meinen Erfahrung von Team zu Team so oder so, aber darüber hatten sich schon Strukturen etabliert, die diese Team-Orientierung absolut unterstützt haben.
:
Bearbeitet durch User
Carsten P. schrieb: > Anders herum geht es aber so: Wenn Individuen sich nichtmal an Scrum > gewöhnen können, ist das Projekt schon zum Scheitern verurteilt. Wenn > sie es alle miteinander im Sinn von einem Miteinander können, braucht > man Scrum nicht mehr oder nur als Maßstab an der Wand, ohne dass man > sich da jeden Morgen treffen und messen muss. Wenn Du von "an Scrum gewöhnen" sprichst: Man kann sich an viel gewöhnen, es bleibt halt die Frage, wie sinnvoll die Zeremonien sind. Im Manifest heißt es, "Individuals and Interactions over Processes and Tools". Man braucht doch solche blöden festen Zeremonien wie z.B. Retrospective nicht. In dem Sinne, daß man nach jedem Sprint einen festen Termin geblockt hat, wo alle unbedingt ihren Senf dazu geben müssen, was sie am letzten Sprint gut fanden und was nicht. Stell Dir ein Eheberater vor, der einen Prozess vorschreibt, wo die Familie jede Woche am Samstag etwas zusammen macht. Anschließend muss jedes Mitglied vom Nesthäkchen bis zum "Familienoberhaupt" sagen, was es toll fand und was nicht. Der Mann hat der Frau einmal morgens und einmal abends ein Kompliment zu machen und umgekehrt. Für das Thema Haushaltsgeld wird einmal im Monat eine Stunde geblockt. Aber natürlich gibt es auch Freiheiten: Der Mann darf Donnerstag und Sonntag zum Stammtisch und die Frau zweimal die Woche ihre Freundinnen zum Kaffeekränzchen treffen. (Die "Sei-Spontan-Paradoxie" von Watzlawick lässt grüßen). Will damit sagen: Man muss diesen Scrum-Käfig doch nicht haben! Wenn man sich abstimmen will, greift man zum Telefonhörer, wenn man Probleme hat, wendet man sich an einen Kollegen und wenn etwas blöd gelaufen ist, dann setzt man sich zusammen und redet darüber. Wenn das schon nicht klappt, dann klappt auch Scrum nicht. Erzwungene feste Termine nerven, ich habe weiter oben schon das Parkinsonsche Gesetz der Trivialität erwähnt, nachdem es unmöglich ist, im großen Kreis über anspruchsvollere Themen zu sprechen.
Joe schrieb: > Zeremonien Wahrscheinlich die treffendste Beschreibung: Projekte mit 2 oder 30 Beteiligten, Anfänger oder Experten oder Jahresammler, Bekanntes oder Innovatives, Write only vs. 20 Jahre support, IG-Metall-Disney vs. Startup, ... Wenn ein paar gute Leute dabei sind und machen dürfen, gelingt es meist trotz Scrum, mit unfähigen Diven, unmotivierten Anfängern oder zu vielen Köchen vielleicht nur wegen. Zeremonien, die typische blinde Flecken ans Licht bringen, die aber nie Selbstzweck sein dürfen.
Robert K. schrieb: > Rudi R. schrieb: >> ein Entwickler setzte es um und ich habe die >> ganze Implementierung Wochen später ersetzt, das sie nur Ärger machte. >> Und ich ersetzte sie durch jene, die ich von Anfang an im Sinn hatte. > > Das ist ein schönes Beispiel. Jeder macht was er will und man arbeitet > gegen- statt miteinander. Nein, das ist kein schönes Beispiel für "jeder macht, was er will", wenn du damit mich gemeint haben willst. Ich habe eine Fehlkonstruktion behoben. Eine Fehlkonstruktion, die durch durch abgehobenes Treffen von Entscheidungen enstanden ist, und dabei den Fachmann (also mich!) zu übergehen. Die Fehlentscheidung sorgte wochenlang für heißlaufende Telefondrähte und wurde dann durch mich behoben. Woher die Fehlentscheidung kam, das habe ich während nicht offen thematisiert. Da geht's auch Gesichtswahrung und Loyalität. Ich wurde ja angepflaumt, warum es nicht funktionierte. Die Implementierung des Kollegen entsprach prinzipiell der Vorgabe, war also nicht falsch. Die Vorgabe war falsch. Ich habe später aber auch keine Lorbeeren kassiert, weil ich die Chose reparierte.
Rudi R. schrieb: > Nein, das ist kein schönes Beispiel für "jeder macht, was er will", > wenn du damit mich gemeint haben willst. Ich habe eine Fehlkonstruktion > behoben. Eine Fehlkonstruktion, die durch durch abgehobenes Treffen von > Entscheidungen enstanden ist, und dabei den Fachmann (also mich!) zu > übergehen. Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, und wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig einschreiten können. Insofern ist Dein Beispiel in meinen Augen ein sehr gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu Informationsverlusten kommen kann, die es mit einer agilen Vorgehensweise nicht gegeben hätte.
Uwe D. schrieb: > Ich selbst kann nur von europäischen Firmen sprechen. Wer schon einmal > eine Software mit SIL > 2 mitgebaut hat - oder eine Zertifizierung nach > Common Criteria ab EAL3 aufwärts, der weiß das da extrem viel > Formalismus, Disziplin und vor allem langer Atem notwendig ist, um > erfolgreich (in Quality, Time & Budget) zu sein. > > Jede Menge Systeme wird genau so und mit SCRUM gebaut. Das betrifft > Aviation, Rail, Automotive, Computing… Meiner Erfahrung nach werden jede Menge Systeme TROTZ SCRUM gebaut. Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die Sicherheit des Produkts erhöht wird. Das einzige, was sich immer weiter erhöht, ist der Preis und wir haben in der Industrie mittlerweile einen Bürokratisierungsstand erreicht, der uns bald nach und nach vom Markt fegen wird! Der ganze Kram nennt sich "agil", ist aber eigentlich eine sehr formalistische und höchst unflexible Geschichte, die erkennbar für die Führung von vielen unselbstständigen Entwicklern in Form eines Mikro-Managements entwickelt wurde. Ich komme eigentlich ursprünglich aus der Forschung und Vorentwicklung. Dort ist man es gewohnt, Dinge eigenständig zu planen und zu entwickeln, auch in Gruppen. Auf geänderte Rahmenbedingungen konnte man sehr schnell reagieren und insbesondere sich selbst frei organisieren. Das konnten die Leute, weil sie genau das gelernt haben, schon im nicht-verschulten Studium. Seit vielen Jahren in der Serienentwicklung lief das ähnlich. Produkte wurden in immer besserer Qualität in annehmbarer Zeit entwickelt. Und das bei mehreren Kunden gleichzeitig, die nicht nur unterschiedliche Anforderungen hatten, sondern auch zu ganz verschiedenen Zeiten ihre Serienanläufe, Inbetriebnahmen, Fehler-Reports usw. Dazwischen Akquisen, Abstimmungen, seriennahe Vorentwicklung, damit auch für die nächste Produktgeneration genügend Fleisch da ist, womit man Konkurrenten ausstechen kann. Dieser SCRUM-Quark dagegen ist Gleichmacherei; flexible und eigenverantwortliche, ergebnisorientierte Arbeit (wo jede verdammte Stunde irgendein Kunde die ganze alberne "Sprint"-Planung durch irgendeine Anfrage, Error-Report, Akquise in den Abfluss spülen kann) wird durch sogenannte "agile" Prozesse ersetzt, die vielleicht für einfache Entwicklungs-Fließbandarbeit durch unselbstständige Entwickler geeignet sind, aber nicht für Firmen mit sehr hohen Lohnkosten, die sich allein durch etwas mehr Innovation am Markt halten können.
Gastino G. schrieb: > Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die > Sicherheit des Produkts erhöht wird. 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. 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.
Gastino G. schrieb: > Meiner Erfahrung nach werden jede Menge Systeme TROTZ SCRUM gebaut. So kann man das stehen lassen und hinzufügen, dass viele Projekte trotz signifikanter Abweichungen von Scrum (im positiven wie im negativen Sinne) kurzerhand trotzdem als nach Scrum durchgeführt deklariert werden, weil ein solcher Prozess drüber gestülpt und durchgeführt wurde. Die Befürworter sehen das als Bestätigung des System, obwohl der Erfolg des Projekts ohne Scrum besser- und vor allem billiger gewesen wäre. Der allgemeine Tenor ist aber immer noch Pro-Scrum und zwar firmen- abteilungs- und projektweit, daher ist dagegen nur schwer anzugehen. Es sind noch zu wenige Firmen, die nach Jahren mit Scrum die Auswirkungen gesehen und auch wirklich mal ein screening von Kosten und Nutzen gemacht haben, und es dann wieder rausgeworfen haben. Es wird noch dauern, bis sich Srum wirklich gesetzt hat und nur dort eingesetzt wird, wo es funktionieren kann. Dazu passt dieser Beitrag von oben:
Ein T. schrieb: > Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich > für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, In der Tat. Für mich auch. Allerdings: > wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum > Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand > anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig > einschreiten können. Das wäre die Frage ob er da wirklich gefehlt hat, denn das Übergehen ist bei einem Mehrheitsentscheid des Teams oft die Regel. Die eigentlich richtige Idee dahinter ist die angenommene Gruppenintelligenz, die den Einzelfehler verhindern soll. Das funktioniert natürlich nur, wenn die Gruppe diese Kompetenz auch hat! Das ist aber bei Weitem nicht der Fall und gilt nur für kleine GRuppen und daher funktioniert Scrum eben nur bei homogenen Gruppen ähnlichen Knowhows. Ansonsten setzt sich immer nur die durchschnittlich intelligente Lösung durch, die alle noch überblicken, und die gute Lösung des Fachmanns nicht, weil er alleine dasteht. Wie oben auch eingeworfen, zieht damit die durchschnittliche Entwicklerschaft die Leitung runter, statt hoch! > Insofern ist Dein Beispiel in meinen Augen ein sehr > gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu > Informationsverlusten kommen kann, die es mit einer agilen > Vorgehensweise nicht gegeben hätte. Da sehe ich einen Interpretationsfehler deinerseits: In diesem Beispiel zeigt es sich ja gerade, dass es nicht der Informationsverlust ist, sondern mangelnde Kompetenz. Scrum wurde auf eine zu heterogene Gruppe angewendet, wo es nicht funktionieren kann. Gastino G. schrieb: > wird durch sogenannte "agile" Prozesse ersetzt, die vielleicht für > einfache Entwicklungs-Fließbandarbeit durch unselbstständige Entwickler > geeignet sind, genau das!
J. S. schrieb: > Gastino G. schrieb: >> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >> Sicherheit des Produkts erhöht wird. > > Das ist aber jetzt ein von Scrum losgelöstes Thema, Natürlich ist das alles ganz alleine Scrum schuld. Genau wie an den beiden Weltkriegen, Tschernobyl, Fukushima und der Versenkung der Rainbow Warrior, das war alles Scrum! (Aufmerksame Beobachter hätten das allerdings schon vorhersehen können, als Scrum den armen Jesus gekreuzigt hat.)
Ein T. schrieb: > Das Übergehen von Leuten mit den entsprechenden Kompetenzen hört sich > für mich jetzt aber sehr sehr nach "jeder macht, was er will" an, und > wenn Du bei dem "abgehobenen Treffen" anwesend gewesen wärst oder zum > Beispiel in einem Scrum Daily Standup davon erfahren hättest, daß jemand > anders an Deinem Fachgebiet arbeiten soll, dann hättest Du rechtzeitig > einschreiten können. Insofern ist Dein Beispiel in meinen Augen ein sehr > gutes Beispiel dafür, wie es ohne die Verwendung von agilen Methoden zu > Informationsverlusten kommen kann, die es mit einer agilen > Vorgehensweise nicht gegeben hätte. Ich habe ja davon erfahren. Ich fragte doch: "Wollen wir das nicht mal diskutieren?" Dann kann man Pros und Kontras eruieren, was ich übrigens für mich ja auch immer still mache, wenn ich für ein Probleme mehrere Lösungsansätze im Sinn habe. Der Projektleiter, der nicht diskutieren wollte, war sich seiner Sache zu bewusst und lag dann gründlich daneben. Das würde ich auch nicht als Fehler der Organisation ansehen, sondern als sein persönliches Defizit. Agile Methoden verhindert das nicht und begünstigen das auch nicht. Das ist vollkommen unabhängig. Es ist eigentlich immer schlau, die Fachleute, die im Saft stehen, zu fragen. Nicht so, wie es Politiker oder Manager tun, die sich Alibis verschaffen wollen (z. B. für Massenentlassungen), sondern es geht um richtige Befragung. Und man lässt es die Entwickler entwickeln, die hinterher auch Skin in the Game haben. Ich war der mit Skin in the Game, der wochenlang dieses Theater ausbaden musste. Der Entwickler bzw. der Entscheider waren weg. bzw. haben den Kopf eingezogen. Das ist mir schon öfter aufgefallen. Ich musste vor vier Jahren für Projekt eine Feature implementieren. Und es gibt dann immer ganz schlaue Projektleiter, die dann über den Flurfunk mitkriegen, sowas wurde doch schon mal in einem anderen Projekt umgesetzt. Also hat sich ein anderer Entwickler hingesetzt, der vom fremden Projekt, der kein Skin in the Game hatte. Es funktioniert nichts. Es wurde regelrecht gepfuscht. Es wäre besser gewesen, ich hätte mich der Sache von Anfang an angenommen. Es war in jedem Falle nur viel Konfiguration und ein bisschen Programmierung. Der Entwickler war dann auch noch so frech und behauptete, dass ich falsch liege und sein Zeug schon funktioniere. Ich bin regelrecht gewarnt, wenn ich höre: "Lass uns das doch mal von X übernehmen." Weil es bislang immer so war: Die Zeit, zu verstehen, was der andere gemacht hat, dann erkennt man, dass es Murks ist und das ganze Bug fixing verschlingt so viel Zeit. Und dann programmiert man es komplett neu und richtig. Oft erlebt und immer mit dem faden Beigeschmack: Man hätte so viel Zeit gespart, wenn man es direkt selbst gemacht hätte.
J. S. schrieb: > Das wäre die Frage ob er da wirklich gefehlt hat, denn das Übergehen ist > bei einem Mehrheitsentscheid des Teams oft die Regel. Daß die Fachleute übergangen werden, kann natürlich immer und überall geschehen. Aber wenn die Fachperson sich in der Gruppe geäußert hat und trotzdem übergangen worden ist, kann man sie hinterher nicht mehr dafür verantwortlich machen. Und alle in der Gruppe wissen das auch! > Das funktioniert natürlich nur, wenn die > Gruppe diese Kompetenz auch hat! Wenn die Gruppe vornehmlich aus Inkompetenten besteht, die das Fachwissen und die Erfahrung der Kompetenten weder anerkennen noch berücksichtigen, dann kann die ganze Angelegenheit ohnehin nicht funktionieren. Da helfen dann auch agile Methoden nichts. Die sind schließlich kein Allheilmittel, auch wenn die Feinde von agilen Methoden das gerne als Strohmann-Argument mißbrauchen. Dann nutzen allerdings auch die hierarchischen Ansätze genau gar nichts. Huch!
Ein T. schrieb: > Dann nutzen allerdings > auch die hierarchischen Ansätze genau gar nichts. Doch, wenn nämlich die Vorgaben von der fachkompetenten Person kommen. Das ist ja eben der Punkt: Wenn es nicht die Gruppe ist, die eine homogene Kompetenz hat, dann kann es eben auch die Gruppe nicht entscheiden, sondern es muss die einzelne Person tun.
J. S. schrieb: > Es wird noch dauern, bis sich Srum wirklich gesetzt hat und nur dort > eingesetzt wird, wo es funktionieren kann. Angesichts der Tatsache, daß eine ganze Branche davon lebt, das Wunderelixier Scrum zu vertreiben, wird es sicherlich noch lange brauchen, bis es Gesunden nicht mehr verschrieben wird.
Joe schrieb: > Angesichts der Tatsache, daß eine ganze Branche davon lebt, das > Wunderelixier Scrum zu vertreiben, Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, damit sie dann bitter darüber weinen können, daß sie weder das Eine noch das Andere sind und sein können. Und selbstverständlich kann ein jedes Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich lösen kann und von windigen Figuren angepriesen wird, natürlich nur unnützer, überflüssiger Mist sein. Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und fachliche Substanz hinter solchen "Argumentationen" steckt. Nicht zuletzt deswegen mag ich mich jetzt aus diesem ebenso langwierigen wie langweiligen Geplänkel zurückziehen und mich konstruktiveren, sinnvolleren und vergnüglichen Tätigkeiten widmen. Vielen Dank, habt einen schönen Tag.
J. S. schrieb: J. S. schrieb: > Gastino G. schrieb: >> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >> Sicherheit des Produkts erhöht wird. > > Das ist aber jetzt ein von Scrum losgelöstes Thema In der Tat: Scrum und agil ist das genau Gegenteil von SIL. Bei SIL (z.B . 61508) sind die Anforderungen von Anfang an klar und unverhandelbar. Die verwendeten Techniken und Verfahren müssen bekannt und erprobt sein. (Das viel zu viel Papier generiert wird, ist auch meine Erfahrung. "Form" ist halt deutlich einfacher zu erstellen und zu prüfen als "Inhalt" und so werden die meisten Dokument "write only")
Ein T. schrieb: > Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im > Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und > fachliche Substanz hinter solchen "Argumentationen" steckt. Nicht > zuletzt deswegen mag ich mich jetzt aus diesem ebenso langwierigen wie > langweiligen Geplänkel zurückziehen und mich konstruktiveren, > sinnvolleren und vergnüglichen Tätigkeiten widmen. Vielen Dank, habt > einen schönen Tag. Ich wünsche Dir auch eine schöne Zeit. Aber ehrlich gesagt finde ich es keinen so großen Verlust, wenn Dein "Geplänkel" wegfällt. Habe Deine Beiträge nochmal von Anfang an überflogen und finde fast nur ad hominem-Repliken, Anekdotisches und Prahlen wie "ich als Unternehmer" und Überspitzungen. Rabulistik nannte man das mal (1). Ich habe nichts gefunden, was in einer Diskussion produktiv wäre, kein Konzedieren, daß der "Gegner" auch mal einen Punkt gemacht hat. Beispiel: > Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von > ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, > damit sie dann bitter darüber weinen können, daß sie weder das Eine noch > das Andere sind und sein können. Der Punkt ist doch, daß Scrum regelmäßig als Allheilmittel angepriesen wird. Wie Schlangenöl. Ein "Feind" von Scrum wird man für viele alleine dadurch, daß man sagt, daß es eben kein Allheilmittel ist, sondern in vielen Fällen auch wirkungslos oder gar ungesund ist. Das wirkt wie religiöser Eifer. > Und selbstverständlich kann ein jedes > Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich > lösen kann und von windigen Figuren angepriesen wird, natürlich nur > unnützer, überflüssiger Mist sein. Das ist ein typisches Beispiel für beleidigtes Werfen eines Strohmann-Arguments. Es wurde ja konzediert, daß Scrum *in bestimmten Konstellation* nützlich und wertvoll sein kann. (1) https://www.frag-machiavelli.de/arthur-schopenhauer/ https://de.wikipedia.org/wiki/Eristische_Dialektik
Bruno V. schrieb: > Das viel zu viel Papier generiert wird, ist auch meine Erfahrung. > "Form" ist halt deutlich einfacher zu erstellen und zu prüfen als > "Inhalt" und so werden die meisten Dokument "write only") So ganz write only ist das ja nicht. Man muss zwei Dinge trennen: a) die politisch motivierten Vorgaben, die von außerhalb kommen und die man einfach beachten muss, ob man sie mag oder nicht. Die müssen eben rein, formuliert, beachtet und getestet werden. b) die Dinge, die technisch in ein Produkt fließen sollen, weil die GL das möchte oder es eine Kunde haben will. Auch da gibt es eben unveränderliche Dinge, an denen nicht gerüttelt werden soll und je genauer und präzisier diese formuliert sind, desto besser. Besser vor allem auch für den Leistungserbringer, weil ihm dann keine Mängel oder Fehler vorgehalten werden können. Ab da kommt dann eine Umsetzung und die Mitwirkung des Lieferanten und damit gfs. auch Scrum (u.a. wenn die liefernde Abteilung die Entwicklung ist und die Vorgaben des System engineerings umsetzen soll, darf). Hier ist Dynamik und Freiraum gegeben, der gefüllt werden muss. Ich sehe da nicht notwendigerweise ein Diskrepanz zwischen SIL und Scrum: Ein gesundes System Engineering ist in der Lage, die SIL-Vorgaben so umzusetzen und aufzubereiten, dass sie leistbar werden. Dazu braucht es eben nach den Lastenheften / formalen Spezifikationen eben belastbare Konzepte. Darauf kommt es an. Und die können und dürfen durchaus von Teams erarbeitet werden und damit auch mittels Scrum. Der Knackpunkt bei SIL und anderen ähnlich gelagerten Projekten ist eben, dass der Anteil der Vorgaben sehr hoch und der Freiraum eng definiert ist, wodurch sich auch eine stringente Umsetzung ergibt, während Scrum eigentlich dafür gedacht ist, die offenen, unklaren und veränderlichen Entscheidungen zu managen. Scrum eignet sich in SIL-Projekten daher hauptsächlich bei technischen Umsetzung einer SW oder firmware, nicht aber der HW und noch weniger der Systemdefinition. Würde man Scrum wirklich nur dort einsetzen, wo es passt und wofür es gedacht wäre, gäbe es weniger Diskrepanzen und Kritik daran.
War früher einfacher. "Kommste mit eine Rauchen?" Selbst ohne Idealformat ist es schwierig, die Leute auf einen kleinsten gemeinsamen Nenner zu bekommen - oder auf den dann selber auch noch einzusteigen. Ideal ist sowieso oft problematisch und lebensfremd Statistisch Normal kann auch OK sein. Kommt sowieso häufiger vor als man denkt. Funktional dagegen spielt ein wenig in einer anderen Liga. Man vergleiche z.B. einen VW Käfer mit einem aktuellen Formel 1 Wagen. Stört doch gar nicht, wenn die letzteren gut performen.
Bruno V. schrieb: > J. S. schrieb: > > J. S. schrieb: >> Gastino G. schrieb: >>> Gerade im Bereich SIL wird sehr viel "Papier" generiert, ohne dass die >>> Sicherheit des Produkts erhöht wird. >> >> Das ist aber jetzt ein von Scrum losgelöstes Thema > > In der Tat: Scrum und agil ist das genau Gegenteil von SIL. Bei SIL (z.B > . 61508) sind die Anforderungen von Anfang an klar und unverhandelbar. > Die verwendeten Techniken und Verfahren müssen bekannt und erprobt sein. Nö, wir haben zertifizierte Software gemäß EN50128 agil gebaut und geliefert.
Uwe D. schrieb: > Nö, wir haben zertifizierte Software gemäß EN50128 agil gebaut und > geliefert. Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat allerdings wenig zu tun mit dem, was die meisten unter agil verstehen.
Bruno V. schrieb: > Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat > allerdings wenig zu tun mit dem, was die meisten unter agil verstehen. Und das wiederum hat nichts mit dem zu tun, was Scum unter "agil" versteht.
Bruno V. schrieb: > > Natürlich kannst Du die "agil" bauen. "Top down" und "V-Modell" hat > allerdings wenig zu tun mit dem, was die meisten unter agil verstehen. Beides hat auch seine Berechtigung und schließt agil nicht aus. Bei einem abgeschlossenen Modul, das über drei Wochen entwickelt wird, hilft so ein "Mini-V" für sich ganz persönlich. Und es ist gut, dass man die Aufgabenstellung intellektuell durchdringt bevor man in die Tasten haut. Scrum ist die große Illusion, dass man darauf verzichten kann, dass alle Entwickler gleich gut sind, dass jeder alles programmieren. Die Scrum-Seuche zieht gerade durch mein Unternehmen. Nun hört man weiteren Standorten, die es satt haben. Es wird zu viel gequatscht und fehlt die Zeit für die eigentliche Aufgabe. Ein Team treibt es so exzessiv, dass die Besprechungen von 15 Mann einberufen, in denen nur zwei Leute qualifiziert etwas zum Thema beitragen können. Mal sehen, wie lange der Unsinn noch anhält. Ein T. schrieb: > Es ist immer wieder erbaulich, daß die agilen Methoden ausgerechnet von > ihren Feinden als "Wunderelixir" und Allheilmittel gepriesen werden, > damit sie dann bitter darüber weinen können, daß sie weder das Eine noch > das Andere sind und sein können. Und selbstverständlich kann ein jedes > Produkt, das nicht restlos alle Probleme dieser Welt augenblicklich > lösen kann und von windigen Figuren angepriesen wird, natürlich nur > unnützer, überflüssiger Mist sein. Nein, es wird nicht von den Kritikern als Wunderelixier angepriesen. Vielleicht wird der Gegenseitige unterstellt, dass sie es als Wunderelixier anpreisen, aber das hat angesichts der allgegenwärtigen Propaganda für Scrum ja auch eine Berechtigung. Diesen Eindruck kann man haben. Auf die Kritikpunkte wird ja von der Befürworterseite gar nicht eingegangen. Es heißt dann nur: "Ihr macht's falsch." > > Der intellektuelle Tiefgang dieser sich bereits seit geraumer Zeit im > Kreis drehenden "Diskussion" läßt erahnen, welche sachliche und > fachliche Substanz hinter solchen "Argumentationen" steckt. In meinem Falle stecken 16 Jahre Berufserfahrung dahinter. Ich kenne es ohne Scrum, ich kenne es mit Scrum. Und Scrum ist eindeutig nervtötender und setzt falsche Anreize. Das wichtigste ist immer noch der gesunde Menschenverstand. Und man sollte nie vergessen, dass Softwareentwicklung eine intellektuelle Tätigkeit ist. Und diese Sprinterei für schnelle Ergebnisse ist schädlich, wenn man das Programmierte Wochen später wieder wegschmeißen darf. Man darf und sollte planen, damit man sich mittel- und langfristig Programmierarbeit spart. Wenn ich von mich ausgehe: Ich kann gut wiederkehrende Muster erkennen und wenn ich etwas für A entwickle, merke ich: "Mensch, das kann ich für B, C und D so ähnlich auch anwenden." Dann programmiere ich das so, dass ich es auch weiternutzen kann. Da kommen dann Schablonenmethoden und Strategieklassen zum Einsatz. Manchmal brauche ich aber nicht mal das, weil ich das Problem allgemeiner formuliere, dafür die Lösung schreibe. Ich bin da recht gut. Ich merke auch, wie meine Kollegen sich 'nen Krampf programmieren, weil sie nicht in der Lage sind, den gerichteten Graphen für die Topologie-Beschreibung in unserer Anwendung zu nutzen. Wo ich 'ne halbe Stunde und fünf Zeilen Code brauche, sitzen die mitunter Tage und schreiben halbe Romane. (Ich scherze nicht, es ist mitunter wirklich so.) Im agilen Manifest steht als erstes: "Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge". Und genau das vermisse ich in der Scrum-Praxis. Ich glaube, das oben schon geschrieben zu haben: Das wichtigste ist, dass die Entwickler hinzulernen. Und dann sollte man doch das Sprintziel mal beiseite lassen und zwei Tage vermeintlich unproduktives tun, mal was ausprobieren, mal was lesen, mal etwas verstehen, vielleicht eine generischere Lösung von mir. In dem Bereich unserer Projekte, in dem arbeite, bin ich hoch produktiv. Mir wurde schon mehrfach attestiert, dass ich die Arbeit mache, wo in anderen Projekten fünf Leute dran sitzen. Und das kommt ja daher, weil ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen als den Prozess, als das Werkzeug. Ich durchdenke eine Problemstellung, bringe etwas zu Papier. Ich defäkiere dann aufs Sprintziel, aber ich sehe am Horizont ja die Abnahmetermine, die durch mein Vorgehen nicht gefährdet, sondern gesichert werden. Ich kann meine Vorteile auch außerhalb meiner Domäne ausspielen. Ein Kollege sollte im aktuellen Projekt etwas programmieren, aber er brauchte Wochen. Die Aufgabenstellung war einfach und es gab eine Spec vom Kunden: eine Schnittstellenbeschreibung. Er geht das durch und kodiert das runter. Ich hingegen würde mir überlegen, wie ich das Convenientmethoden verpacken kann, die mir die einzelnen Nachrichtenbausteine simpel beschreiben. Dann mache ich das für ein, zwei Nachrichtentypen händisch, merze noch ein paar Fehler aus, aber beim Rest würde ich die Tabellen aus der Spec in den Emacs kopieren und mir das alles per Tastaturmakros zurechtrücken. Leider war es da schon zu spät. Aber ich habe Tastaturmakros angewandt, um zu refaktorieren. Der Kollege hat gestaunt, wie fix ich bin. Da ich bei uns die Azubis betreue, sehe ich, wenn die von ihrer Arbeit abschweifen und etwas vermeintlich unproduktives tun. Ich finde es gut. Der eine Azubi hat den Spacemacs ausprobiert, ist nun zu Doom Emacs gewechselt. Es gefällt mir, dass er sich da reinfuchst. Lieber heute ein bisschen Zeit dafür aufbringen und dann später enorm viel Zeit sparen. Tastaturmakros zeige ich den Azubis gerne, in der Hoffnung, sie zu inspirieren. Und natürlich gibt es dieses Feature auch in anderen Editoren. Wenn jemand den Vim genauso bedienen kann wie ich den Emacs, ist daran doch nichts auszusetzen. In einem Scrum-Prozess wäre dafür keine Zeit.
Rudi R. schrieb: > In dem Bereich unserer Projekte, in dem arbeite, bin ich hoch produktiv. > Mir wurde schon mehrfach attestiert, dass ich die Arbeit mache, wo in > anderen Projekten fünf Leute dran sitzen. Und das kommt ja daher, weil > ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen > als den Prozess, als das Werkzeug. Ich durchdenke eine Problemstellung, > bringe etwas zu Papier. Ich defäkiere dann aufs Sprintziel, aber ich > sehe am Horizont ja die Abnahmetermine, die durch mein Vorgehen nicht > gefährdet, sondern gesichert werden. Ich glaube Dir das sofort und gebe Dir bei dem Ganzen auch Recht, aber... es ist der totale Luxus, ein Management zu haben, welches solchen Einzelkämpfern wie Dir vertraut und diese machen lässt. Normalerweise mißtraut man den Techies, denkt, das sie irgendetwas vor sich abstrahieren und overengineeren, was keinen praktischen Nutzen hat, aber den Spieltrieb des Nerds befriedigt - wenn man sie lässt. Die Lösung von Scrum ist dann ja, daß der Product Owner mit der Businessbrille entscheidet, an was gearbeitet wird. Man will die teure Ressource "Entwickler" an die Kandare nehmen und kontrollieren, mit was sich die Techies beschäftigen. Daß wie beschrieben die Unterschiede bei den Skills riesig sind, stört nur die Abstraktion der Manager, daß Programmieren ein Standardtätigkeit ist, die mess-, skalier- und planbar ist. Agil bleibt damit in den meisten Fällen ein Käfig für die Entwickler, eine totale Verplanung der Zeit der Techies. Und es wird das Losbasteln bevorzugt, weil es gleich sichtbare Ergebnisse bringt. Der Ausdruck "Ticketgetriebe Architektur" bringt es schon auf den Punkt.
Rudi R. schrieb: > Scrum ist die große Illusion, dass man darauf verzichten kann, dass alle > Entwickler gleich gut sind, dass jeder alles programmieren. Ich denke nicht, das diese Illusion an Scrum hängt oder erst mit Scrum entstanden ist. > Und das kommt ja daher, weil > ich mir die Frechheit rausnehme, mich als Individium wichtiger zu nehmen > als den Prozess, Du widersetzt dich den Firmenanweisungen? :D
Rudi R. schrieb: > Nun meckern bei uns in der Firma die nächsten über Scrum. Berichtet wird > immer das gleiche: 50 % der Arbeitszeit geht für Gebabbel drauf. Ich mag Dir nicht zu Nahe treten, aber wenn 50% Eurer Arbeitszeit für "Gebabbel draufgehen", dann arbeitet Ihr entweder an extrem komplexen Aufgaben, oder irgend etwas in Eurer Kommunikation ist kaputt. Die Defekte in Eurer Kommunikation können an Scrum liegen, müssen sie aber nicht. > Wenn es > jetzt wieder heißt: "Dann macht ihr Scrum nicht richtig.", dem will ich > entgegen, dass das die Lieblingsausrede der Sozialisten ist: "Das war > kein richtiger Sozialismus." Das ist eine schöne Anekdote, aber kein Argument. > Auch bei uns in der Firma gibt es "Prozesse". So arbeitet die > EDV-Service-Abteilung nur mit Ticket. Das Ticket-Tool ist unter aller > Sau. Mir sind schon viele Ticket-Werkzeuge begegnet, aber kein gutes. > Nun ist mir aufgefallen, > dass dort Externe arbeiten. Ich weiß nicht, wer diese Leute dort stellt. > Die brauchen die Tickets offenbar für die Rechnungslegung. Das ist ein Mißbrauch des Ticketsystems. Tickets dienen der Kommunikation und nicht dem Controlling.
Mike J. schrieb: > Der Kommunismus funktioniert aber eben nur genau dann, wenn man > Ressourcen im Überfluss hat. Das ist nicht richtig, der Kommunismus funktioniert, allerdings nicht auf einer (zwangsweise durchgesetzten) staatlichen Ebene. Auf einer zivilrechtlichen Ebene funktioniert der Kommunismus in israelischen Kibbuzen recht gut. Aber: die Kibbuzim sind ein freiwilliger Teil des Kibbuz, sie werden nicht gezwungen und können gehen, wenn und wann sie wollen.
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.
Sheeva P. schrieb: > as könnte die klügste Aussage im ganzen Thread sein. Danke. Nicht zwangsläufig! Es ist absolut legitim, Prozesse infrage zustellen, wenn sie für eine Situation einfach nicht passen oder falsch angewendet werden und nach Aktenlage wird keine andere Methode der Projektorganisation so oft falsch appliziert, wie das scrum System. Und es wird falsch interpretiert! Hier geht es schon los: Rudi R. schrieb: > scrum ist die große Illusion, dass man darauf verzichten kann, dass alle > Entwickler gleich gut sind, dass jeder alles programmieren. Das ist eigentlich oft anders herum: Scrum setzt voraus, daß alle gleich kompetent sind, weil sie sonst kein Team bilden können, welches sich die anstehenden Teilaufgaben aufteilt, da sich die Aufgaben nämlich von selber verteilen. Jeder macht das was er kann und andere können ihm da weder helfen noch reinreden. Somit liegt eine klassische Separation vor und Scrum ist wirkungslos. Und noch ein Beispiel: Rudi R. schrieb: > Nun hört man > weiteren Standorten, die es satt haben. Es wird zu viel gequatscht und > fehlt die Zeit für die eigentliche Aufgabe. Hier wird Scrum an einer Stelle eingesetzt, wo ohnehin schon Zeitknappheit herrscht und somit der Versuch, ein qualitativ besseres Ergebnis durch Einsatz von Organisation nach hinten losgeht, weil jede Minute dieser versuchten Organisation die Zeit für das Eigentliche wegnimmt. Wenn man Scrum einführt, muss auch die Zeit dafür reserviert werden. Und auch das ist völlig falsch: > Ein Team treibt es so exzessiv, dass die Besprechungen von 15 > Mann einberufen, in denen nur zwei Leute qualifiziert etwas > zum Thema beitragen können. In Besprechungen können ohnehin nicht mehr als 5 Personen effektiv kommunizieren und größer darf ein Scrum Team gar nicht sein. Wenn die Qualifikation zu weit auseinander ist, kann zur Lösung der Aufgaben kein Scrum Team herhalten, sondern es müsste hierarchiert werden. Wahrscheinlich ist es aber so, dass die Personen in dieser 15er Gruppe alle etwas anderes bearbeiten und nichts miteinander zu tun haben. Das ist ein typisches Beispiel für das formelle Festhalten an Scrum und dem gleichzeitg stattfindenen Verstoßen dagegen. So wird tatsächlich massig Zeit verschwendet, die dann logischerweise fehlt. Scrum darf kein Selbstläufer werden, sondern der Zeitaufwand muss in einem gesunden Verhältnis zum Tun stehen. Wer mehr als 20% seiner Zeit für Orga und Abstimmung (egal nach welcher Methode) verwendet, muss da mal schauen, ob er das verbessern kann. Da läuft nämlich was gewaltig schief. Es muss vor allem aus den Köpfen heraus, alles und überall nach der gleichen Methode abwickeln zu wollen. Das kann nicht gutgehen!
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.
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.