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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?"
:
Bearbeitet durch User
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
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.