Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte ich das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden. Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch einfach mal am Anfang einer Entwicklung einen Anforderungskatalog erstellen können - dann könnte man sich diesen modernen Unsinn sparen und jeder weiß, was realistisch zu tun ist. Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu managen....
Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-) https://www.scaledagileframework.com/ Grüsse, René
Aber es funktioniert doch! Bin mir sicher, dass Boing das komplett umgesetzt hat. Nicht nur bei der 737 MAX, sondern auch beim Starliner: https://www.msn.com/en-us/news/technology/nasa-faults-boeing-for-critical-software-defects-in-starliner/ar-BBZLxkm Also zumindest konnte man einen Bug beheben, als der Starliner schon im Weltall war. Gut, die Sache dass die Uhrzeit unerheblich (mehrere Stunden; 6?) daneben war ist immer noch so. Aber im Weltall gibt es ja auch keine Zeitzonen. Also unerheblich! Kommt dann im nächsten Release. Morgen.
Unglaublich schrieb: > Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte ich > das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden. René H. schrieb: > Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur > beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-) Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und soll. Man hört aber immer die Entwickler heulen dass das alles so zäh und ineffizient sei. Dann kann man es doch Abteilungsintern wieder abschaffen. Oder hört man wie meistens nur den geringen Teil der Entwickler schreien und der größere Teil ist damit erfolgreich?
Kai schrieb: > Bekommen das die Entwickler von oben > vorgegeben Genau so geht das, bei uns hatte sich der CEO mal ein Buch darüber gekauft. Jetzt haben wir alle diesen Bockmist an der Backe......
Kai schrieb: > Wie wird Scrum eigentlich gelebt? Bekommen das die Entwickler von oben > vorgegeben und müssen so arbeiten oder einigen sich die Abteilungen > intern darauf das mal zu versuchen? Dachte Scrum sei ein moderner und > agiler Stil wobei jeder selbstorganisiert und freier arbeiten kann und > soll. Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten. Die finden das alle total geil und leben das. Die wollen das und bringen das aktiv voran. Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal den Rasen mähen muss. Fehlt mir da ein Gen? Ich bin nicht älter als die. Das ist ja nicht nur die Arbeitsweise (Scrum etc.), sondern alles wird in höchst unübersichtlichen Tools verpackt, die auch noch mal mega viel Zeit fressen. Da ist man (mit einem kleinen Produkt) noch in der Entwicklung und verpackt das alles in Release und Sub Releases bla bla bla... wenn ich zusammenzähle werden hier ca. 10 verschiedene Tools nur zur Organisation verwendet, welche gar nichts mit der Entwicklung an sich zu tun haben. Da wäre mir sogar eine Exceltabelle lieber, als das...
Kai schrieb: > wobei jeder selbstorganisiert und freier arbeiten kann Selbstorganisierte Selbstausbeutung. Kai schrieb: > Oder hört man wie meistens nur den geringen Teil der Entwickler schreien > und der größere Teil ist damit erfolgreich? Wer nix besseres kennt ist zufrieden. Kai schrieb: > Wie wird Scrum eigentlich gelebt? Klar, wenn ein idealisiertes Modell in der Realität nicht funktioniert ist nicht das Modell sondern die Realität schuld. Ergo: Die Realität abschaffen. Wie sagte Einstein mal so treffend: "Man sollte Dinge so einfach wie möglich machen, aber nicht einfacher"
Unglaublich schrieb: > Da wäre mir sogar eine Exceltabelle lieber, als das... Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert! Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu drücken!
arbeitsloserArbeitsloser schrieb: > Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich > Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert! > > Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu > drücken! Ist schon in Ordnung mit professionellen Tools zu arbeiten. Aber dieser Zustand hier ist für mich nicht mehr lange tragbar.
arbeitsloserArbeitsloser schrieb: > Oh ja bitte mehr Excel Tabellen, am besten mit 1000 Makros welche sich > Daten aus 10 verschiedenen Dateien holen! Alles undokumentiert! > > Und den Leute schön antrainieren aufs "Makro aktivieren" Knöpfchen zu > drücken! wurden wir nicht dazu erzogen mit GEM GUI usw.? wer mag denn noch Befehlszeilen eintippen? ich jedenfalls nicht. Ich bin auch froh das ich meine flachen Teller im Schrank immer blind an der selben Stelle finde, dumm halt wenn die bessere Hälfte meint mal umräumen zu müssen, dann landet die Pizza auf einem tiefen Teller. Scrum liest sich im Wiki nicht schlecht, sowas hatte ich vor 25 Jahren schon in der Prüfentwicklung ohne diesen Fachbegriff, jeder entwickelte seine SW Module, am Freitag beim gemeinsamen Frühstück wurden die untereinander getauscht und so profitierten ALLE davon. Der Informatiker goß das noch in ein passendes Konzept und Doku. Nur der "Chef" verstand nicht warum am Freitag unsere Pausen so lange dauerten, das waren die "Teammeetings". Die Zeit beim Frühstück wurde aber mehrfach wieder eingespart weil es keine parallel Entwicklungen gab.
Naja, wenns sich um ein Prj. mit ein paar Mannstunden handelt, ist der Overhead nicht gerechtfertigt. Im Gesamtkontext sehr sinnvoll, weil meist gar nicht so wirklich klar ist, was entwickelt werden soll. Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip. Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel. Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft wird dann doch alles wieder umgeschmissen?
Unglaublich schrieb: > Hier sitzen nur junge dynamische Mitarbeiter, alle max. 35 Jahre alt und > viele erst ein paar Jahre aus der Uni. Manche auch noch Werksstudenten. Jung, dynamisch, erfolglos... > Fehlt mir da ein Gen? Nein, Du bist nur intelligenter, als die Lemmingmasse.
soso schrieb: > Im Prinzip ist Scrum reines Kommunikationsmanagement. Agil ist hip. > > Richtig angewandt, ist dies bei großen Projekten eig. das kleinere Übel. > Denn wieviel Zeit geht für Projektplanung im Detail drauf und wie oft > wird dann doch alles wieder umgeschmissen? Das sehe ich überhaupt nicht so. Ich bin jetzt seit ca. 20 Jahren in der Softwareentwicklung und fand es noch nie so unproduktiv und frustrierend wie seit der Einführung von SCRUM. Für mich ist inzwischen klar, dass SCRUM bzw. die agile Arbeitsweise hauptsächlich einer gewissen Gruppe von Anforderern dient - nämlich denen, die es damals schon nicht drauf hatten, ihre Anforderungen klar zu definieren und immer schon dagegen waren, dass Projektbudget für Dokumentation und Analyse verbraucht wird. Und die Entwickler, die heute neu dazukommen, haben Analyse und "Systementwicklung" ebenfalls absolut nicht drauf. Die können garnix anderes mehr, als aus dem Kopf in Konsole zu programmieren und im ewigen Hin- und Her mit dem Anforderer ultralangsam ans Ziel kommen. Erfolgversprechender als ein Wasserfallmodell? Ja klar - wenn man nix kann, auf jeden Fall. Denn sonst kommt man mit dem Wasserfallmodell erst gar nicht so weit, dass die Programmierer mal aktiv werden. Das einzig tolle daran: Ich kann jetzt ca. 1/3 meiner wöchentlichen Arbeitszeit in Meetings, Dailys, Telefonkonferenzen und JIRA-Pflege verbringen. Sitze also im Grunde nur rum und kassiere dafür genauso viel Geld, wie für eine vernünftige Systemanalyse. Absolut lächerlich. Meine persönliche Konsequenz: Ich distanziere mich weiter von meiner Arbeit und schraube meinen eigenen Anspruch runter. Das Produkt hat hier eindeutig an Bedeutung verloren... wichtiger ist, dass alle vom PO an aufwärts ihre Häkchen machen können und bunte Bilder sehen. "Guck mal - die neue Software!!! Sie hilft uns zwar nicht weiter aber sie ist fertig."
Kai schrieb: > Oder hört man wie meistens nur den geringen Teil der Entwickler schreien > und der größere Teil ist damit erfolgreich? Ich bin auch kein großer Fan davon, ich hätte auch lieber Requirements die ich abhaken kann und dann zufrieden bin. Dennoch, wenn man einigermaßen weiß, was man tun muss, damit das Projekt ein Erfolg wird, ist es am Ende egal. Dann präsentiere ich meine Fortschritte eben Scrum-kompatibel in 2 Wochen großen Häppchen. Dann sind die Scrummaster zufrieden, dass ich selbst einen längerfristigen Plan verfolge muss der nicht wissen.
endwiggler schrieb: > Dann sind die Scrummaster zufrieden, dass ich selbst einen > längerfristigen Plan verfolge muss der nicht wissen. Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in der Firma am Kicker fachsimpeln.
Wolle schrieb: > Erfolgversprechender als ein Wasserfallmodell? Dann stell mal bitte das Wasserfallmodell für Facebook auf. Oder e-Bay. Oder allein einmal die vollständigen Requirements für Facebook -- und zwar alle bis .. sagen wir mal heute. Und zwar mit dem Wissen von 2004. Wenn Du es etwas kleiner haben möchtest: Nimm als Gedankenexperiment einmal die vollständigen Requirements eines Forums (wie dieses hier), und die Umsetzung mittels Wasserfallmodell.
Beitrag #6141130 wurde von einem Moderator gelöscht.
Unglaublich schrieb: > endwiggler schrieb: >> Dann sind die Scrummaster zufrieden, dass ich selbst einen >> längerfristigen Plan verfolge muss der nicht wissen. > > Uhuh, ganz ganz schlechte Teammoralbildung Nö, mein (Entwickler-)Team ist ja eingeweiht. Der Scrummaster gehört nur nicht dazu, zu diesem Team.
Unglaublich schrieb: > einfach mal am Anfang einer Entwicklung einen Anforderungskatalog > erstellen können Ist doch durch Srum abgedeckt. Leider hat alles in Scrum beschissene, irreführende, "moderne" Bezeichnungen und es werden haufenweise Nebelkerzen geworfen. Bullshitbingo ist schon das richtige Wort dafür. So findet sich der Anforderungskatalog in Form des "Backlogs" (zusammen mit ein paar anderen Dingen). Noch beschissener ist die Terminologie wenn es darum geht die Anforderungen zu präzisieren und aktuelle Änderungen einzuarbeiten. Backlog Grooming und Refinement. Als ob es zum Hundefriseur geht :-( Dass zum Backlog Grooming und Refinement gar nicht das ganze Team antreten muss wird gerne übersehen und so werden Teams Woche für Woche mit sinnlosen Monologen über Backlog-Items gequält. Erst dann fühlt sich der Product Owner groß, stark und mächtig. "Jetzt müssen sie mir alle mal zuhören, jetzt red i". Product Owner ist noch so ein beschissener Scrum Term. Dem Product Owner gehört gar nicht das Produkt. Er ist nur Herr über den Anforderungskatalog, hat den gefälligst ranzubringen, aktuell zu halten, die Anforderungen zu priorisieren und dem Team Rede und Antwort zu stehen wenn Anforderungen unklar sind. Statt dessen wird Product Owner gerne als Ehrentitel an einen Manager vergeben der von der Technik (und damit den Anforderungen) keine Ahnung hat und seinen Arsch nicht hoch bekommt. > - dann könnte man sich diesen modernen Unsinn sparen > und jeder weiß, was realistisch zu tun ist. > Da braucht man wirklich bald einen Scrummaster, Jedes Team "braucht" einen Scrummaster. Kleine Teams notfalls in Teilzeit oder als Doppelfunktion Entwickler / Scrummaster. > um ein kleines Team zu > managen.... Der Scrummaster managed nicht das Team. Vereinfacht gesagt, er schützt den Prozess. Er hat keine Vorgesetztenfunktion sondern steht im Dienst des Teams.
Michael Gugelhupf schrieb: > Der Scrummaster managed nicht das Team. Vereinfacht gesagt, er schützt > den Prozess. Im übertragenen Sinn: Er stellt sicher dass die ISO-9000 bzgl. SCRUM eingehalten wird :-)
Unglaublich schrieb: > Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch > einfach mal am Anfang einer Entwicklung einen Anforderungskatalog > erstellen können Was meinst du, warum Software seit der Erfindung und zunehmenden Verbreitung von Scrum und anderen agilen Methoden so viel schlechter geworden ist. Gestern durfte ich jemandem helfen, dessen Thunderbird nach dem Update vom 28.1. keinen 'Senden' Knopf mehr hat. Im 'Neue Nachricht erstellen' Fenster gibt es gar nichts mehr, kein Menü, keine Knöpfe, nur Adresszeile und Textfeld. Immerhin ergab eine Suche im Web die Lösung: Alt drücken. Dummerweise gibt es das Problem schon mindestens seit 2013, immer wieder, aber man ist bei Mozilla zu blöd es zu beheben. Daß bei dem Update die Knöpfe wie 'Antworten' auf der Nachrichtenliste vom Kopfbereich in die Vorschau gewechselt sind, muss auch an einem Entwiggler mit kleinem Hirn aber quadratmetergrossem Bildschirm liegen. Auf normalen Bildschirmen kann man sich gar keine Vorschu anzeigen lassen, so verschwenderisch geht Thunderbird mit dem Bildschirmplatz um. Dumm nur, daß auf die Art der Knopf beim Update auch verschwunden ist. Immerhin kann man ihn dort in die noch weiter oben liegende Button-Bar konfigurieren. Es ist weitgehend egal wo du hinguckst: Überall wird Software schlechter. Selbst mein Auto hat Bugs, durch die es den Funkschlüssel 'vergisst', was die Markenwerkstatt durch einen 1900 EUR teuren Wechsel de Funkempfängers beheben will, weil sie nicht weiss, wie man das Vergessen rückgängig macht, sondern glaubt die Hardware wäre defekt.
Das ganze Leben ist umständlich und kompliziert. Vor allem eins - anstengend. Meistens wird man mit Arbeit zugemüllt und hat keinen Einblick oder kein Interesse für die Tätigkeit des PL zB, der dafür sorgt, dass das Projekt zusammengehalten wird. Noch ein zusätzlicher Prozess, na Danke. Dennoch. Würde sagen unter dem Strich ist dies eine Verbessserung, vor allem von der Kommunikation. Die meisten, die sich hier auslassen über Scrum haben vor 10 Jahren darüber geschimpft, dass die Leute nicht miteinander reden und/oder die wichtigen Informationen nicht durchdringen. Ein Backlog ersetzt im Übrigen nicht das Pflichtenheft und auch nicht die Dokumentation des Projekts.
soso schrieb: > vor allem von der Kommunikation. Leute die vorher nicht miteinander reden (und auch zuhören) tun das auch nicht wirklich in verordneten Meetings. Planungs /Änderungszyklen, priorisierte ToDo oder Taskliste, regelmäßige Meetings (bis hin zu täglichen kurzen Statusmeetings wenns gerade mal brennt) usw. usf gabs/gibts auch alles schon vor und ohne SCRUM und agile development. Es gab nur keine so hippen Namen dafür.
:
Bearbeitet durch User
Unglaublich schrieb: > Gerade wieder eine Stunde Sprint / Meeting hinter mir. Fast hätte > ich das Bullshitbingo gewonnen. Soll wohl sowas wie Scrum sein / werden. > > Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch > einfach mal am Anfang einer Entwicklung einen Anforderungskatalog > erstellen können - dann könnte man sich diesen modernen Unsinn sparen > und jeder weiß, was realistisch zu tun ist. > Da braucht man wirklich bald einen Scrummaster, um ein kleines Team zu > managen.... Ein Scrum meeting sollte < 15 min dauern
Hinweisgeber schrieb: > Ein Scrum meeting sollte < 15 min dauern Das ist das daily. Es gibt diverse verschiedene Arten von Meetings.
René H. schrieb: > Ich hatte mein Sprint Planning Meeting gestern und kann Dir nur > beipflichten. Aber glaub mir, es geht noch schlimmer: SAFe :-) > > https://www.scaledagileframework.com/ > > Grüsse, > René Wow! "Epic Owners" "Learn-Agile Mindset" "Agile-Release-Train" Ich werde Epic owner!
Name: schrieb: > Wow! > "Epic Owners" > "Learn-Agile Mindset" > "Agile-Release-Train" > > Ich werde Epic owner! Ja, es ist ein "pain". Ich verbringe mindestens 20% meiner Arbeitszeit mit diesem Mist. Soviele Meetings hatte ich meinem ganzen Leben nie.
Name: schrieb: > Ich werde Epic owner! Ist das gleiche wie bei AISLER (Beitrag "Ask me anything, Fertigung bei AISLER"). Lauter buzzwords, bunt und hauptsächlich Luft. Wenn es Klärungsbedarf gibt, frag ich halt einen Kollegen und zwar zeitnah und nicht erst Freitags. Und wenn es was zu erklären gibt, dann erklär ich es ihm und nicht denen die nichts damit zu tun haben und nichts damit anfangen können. Und wenn es Alle was angeht, dann genügt ein "Setzen wir uns zusammen". Wenn das jetzt in einem festen Zeitraster besser sein soll, dann ist mir klar, warum die Montagsbesprechnungen hier so völlig sinnlos waren und ich mich durch häufiges gähnen und Aufforderung zur Kürze selbst rausgekick hab. War ja eh nichts für mich dabei. Mir geht's einfach am Arsch vortbei wie die Buchhaltung SAP bedienen soll oder Netzwerkkabel beim Kunden X unbedingt grau sein müssen. Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue und unverständliche Begriffe für die. Kindergarten!
Hahaha, da bin ich ja froh, dass mein langjähriger Kollege und ich nicht die Einzigen sind, die sich über Sinn und Unsinn dieser 'modernen' Prozesstools amüsieren. Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich dann morgen mache. Ich bete meine Story also runter (wobei ich mir ziemlich sicher bin, dass - wenn sie denn noch zuhören - die meisten überhaupt nichts mit der Nummer und der Kurzbezeichnung anfangen können) und mache dann die Augen wieder zu .... ;) Scrum wird wie üblich von Unwissenden oben aufgezwungen, Scrum Master ist bei uns einer aus dem 'Entwicklerteam'. Technisch inhaltlich soll nichts besprochen werden, nur der Fortschritt des Projekts und die grünen Häckchen für die Vorgesetzten sind wichtig. Aktuelle, technische Probleme hinterher in P2P-Gespräch geklärt ... nein besprochen werden. Ich sehe das wie einer meiner Vorredner - wenn sich die Firma so einen Blödsinn leisten kann ... dann soll sie das. Die Konsequenz ist, dass ich nicht mehr mitdenke, nur noch stumpfsinning meine Punkte abarbeite und danach nach Hause gehe und mich mit letzter Kraft jeden Tag neu auf die Arbeit schleppe. Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder zu zweit die komplette Steuergeräte-SW entwickelt (incl. Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das eine nicht ohne das andere laufen kann und kannte die ganze Funktionalität aus dem Kopf, weil das unser 'Kind' war. Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das verlangt und niemand fühlt sich verantwortlich. 30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit gemacht haben. Und welche Pfosten finden diesen 'modernen' Weg gut : Die, die nach zig Jahren C-Programmierung Zeiger nicht benutzen, weil sie die nie richtig verstanden haben und auch privat nicht eine Minute programmieren oder gar mal irgendeine Hardware-Entwicklung gemacht haben. Aber sagen wir müssen sofort alle Kraftwerke und den privaten Autoverkehr abschaffen und all solchen Schwachsinn ohne den Kopf vorher einzuschalten. Noch Fragen ??? Schöne neue Welt (Aldous Huxley) lässt grüßen ... weiter so X(
Nick M. schrieb: > Aber Schneeflocken brauchen wohl eine Anleitung wie sie mit Kollegen > umgehen sollen. "Kollegial" und "Zusammenarbeit" sind wohl völlig neue > und unverständliche Begriffe für die. > > Kindergarten! Zustimmung in den meisten Punkten. Außer in einem: Ich mach den Affenzirkus in den Firmen jetzt seit 25 Jahren mit, und gemeckert über die Jungen Leute wurde schon immer gleich viel. Wer behauptet, in seiner Firma wäre das besser, lügt. Dazu war ich schon in zu vielen Firmen, um das noch glauben zu können ;-) Wir waren damals halt "die no future Generation", und "aus denen wird eh nie was". Lieblingsspruch: "Nimm die Hände aus den Hosentaschen, sonst wachsen sie fest". Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am Handy rumwischen. Geändert hat sich tatsächlich fast gar nichts. Fakt ist, dass sich Leute kurz nach oder in der Pubertät für Arbeit nur selten begeistern können.
Name: schrieb: > Geändert hat sich tatsächlich fast gar nichts. Fakt ist, dass sich Leute > kurz nach oder in der Pubertät für Arbeit nur selten begeistern können. gibt zu jeder Zeit sone und solche, ich hatte schon mit 12 einen Compi zusammengebaut, Schaltpulte mit noch 220V gebaut wusste wo man den Lötkolben anfasst und nach dem Studium und nach der Arbeit am PC daheim auf dem ST die Prüfprogramme weitergeschrieben. Wer sein Hobby zum Beruf macht muss nie wieder arbeiten.
:
Bearbeitet durch User
Name: schrieb: > Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am > Handy rumwischen. Ja und nein. Ich versteh dich schon. Aber es gibt Leute die man mal schwach anreden kann ohne dass sie in Tränen ausbrechen. Sondern kurz nachdenken, lächeln und dann drauf reagieren. Zurücklächeln und damit ist das dann erledigt. Und das kenn ich auch so aus meiner "Jugend".
Joachim B. schrieb: > Wer sein Hobby zum Beruf macht muss nie wieder arbeiten Entschuldige bitte - aber den Spruch kann ich nicht mehr hören. Arbeit ist für mich Arbeit (O.K. ich tue gerne, wofür ich bezahlt werde) - aber Hobby ist für mich anders. Damit verdiene ich nicht meine Brötchen mit den entsprechenden Zwängen dahinter - da mache ich etwas rein aus Interesse / Spaß an der Freude. Das sind 2 Paar Schuhe. O.K, wenn Du ein reicher Erbe bist und/oder kein Geld verdienen musst mag das anders aussehen. Ich vergaß die Künstler - aber nur wenige können sich mit ihrer "Kunst" den Lebensunterhalt verdienen oder gar reich werden. Wenn die zu Lebzeiten in den "Geldstrudel" kommen machen die auch nur noch das das, was gefragt ist. Oder sie sind dann so berühmt, dass auch eine Wanne - von ihnen halb mit Fett gefüllt - als Kunst angesehen wird :-).
:
Bearbeitet durch User
Matthias Döpke schrieb: > Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich > gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich > dann morgen mache. Du arbeitest also in mindestens drei (großen) Teams gleichzeitig: > Ein Daily Scrum Meeting sollte < 15 min dauern Oder Euer Scrummaster -- oder Ihr selbst -- brecht nicht rechtzeitig ab.
Achim H. schrieb: > Du arbeitest also in mindestens drei (großen) Teams gleichzeitig: Es ist ein Team an 2,5 Standorten .... Eines der Scrums dauert alleine 30min ....
Name: schrieb: > Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am > Handy rumwischen. Scrum hat mit der Jugend nichts zu tun. Das ist eine Management Idee und im Grundsatz von der Idee nicht mal schlecht. Hat sich nicht der Scrum „Erfinder“ davon distanziert weil daraus nur ein Management Werkzeug wurde und die Grundidee komplett weg gebügelt wurde? SAFe ist aber eine Idee von findigen Wirtschaftler wie man sie Scrum Zitrone noch mehr auspressen kann. Scrum of Scrum ist Schwachsinn in Potenz.
:
Bearbeitet durch User
Beitrag #6141568 wurde von einem Moderator gelöscht.
Beitrag #6141570 wurde von einem Moderator gelöscht.
Matthias Döpke schrieb: > Wir sitzen jeden Tag 45min und quatschen darüber welche JIRA-Story ich > gestern bearbeitet habe, welche heute drankommt und evtl. noch was ich > dann morgen mache. > Ich bete meine Story also runter (wobei ich mir ziemlich sicher bin, > dass - wenn sie denn noch zuhören - die meisten überhaupt nichts mit der > Nummer und der Kurzbezeichnung anfangen können) und mache dann die Augen > wieder zu .... ;) Wenn es niemanden interessiert, warum redet ihr dann so lange? "Ich arbeite an $TICKETBEZEICHNUNG. Ich denke damit heute fertig zu werden und kümmere mich dann um $TICKETBEZEICHNUNG2." Dauert 30 Sekunden. Nächster. Alternativ: "Ich arbeite an $TICKETBEZEICHNUNG. Meine Arbeit wird unerwartet behindert durch XY." XY kann z.B. unerwartete Komplexität sein. Oder eine unklare Spezifikation. Oder Abhängigkeit zu einem Fremdsystem, das ständig zusammenbricht. Oder dass du alle 5 Minuten Besuch von irgendjemandem bekommst. Oder dass dein Rechner zu wenig RAM für die Simulation hat. Das zu sagen sollte jetzt auch nicht ewig dauern, sondern in 2 Minuten erledigt sein. Jetzt kennen alle das Problem und das Team kann entscheiden, was man macht: Es trotzdem irgendwie durchziehen, irgendwas anderes probieren, das Ticket zurück ins Backlog. Was auch immer. Euer Scrum-Master hat auch die Aufgabe, Probleme zu lösen. Ich kenne z.B. ein Team, dessen Scrum-Master Öffnungszeiten durchgesetzt hat. Klar wusste auch ohne Scrum jeder, dass die ständigen Störungen Kacke sind. Aber es war halt ein Mimimi-Problem einzelner Entwickler, die sich nicht gegenüber anderen Abteilungen durchsetzen konnten. Das Problem an Scrum ist das selbe wie in allen Meetings: Die Laberblafasel-Attitüde. Klar fühlt es sich gut an, eloquent 5 Minuten oder auch länger über seine aktuelle Arbeit und was man nicht alles tolles macht zu reden. Und je länger andere schon gelabert haben, umso mehr Zeit hat man, sich seinen Auftritt und was man noch alles erzählen will, zurechtzulegen. Dass es nicht hilft seht ihr. Warum ändert ihr es nicht? Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern! Legt halt in der nächsten Retrospektive fest, das jeder im Daily zuerst diesen einen formelhaften Satz von oben sagen muss. Und wenn er dann weiterredet ohne was zu sagen: unterbrecht ihn. > Scrum wird wie üblich von Unwissenden oben aufgezwungen, Scrum Master > ist bei uns einer aus dem 'Entwicklerteam'. Das könnte ein Problem sein. Oder sogar 3. > Technisch inhaltlich soll nichts besprochen werden, nur der Fortschritt > des Projekts und die grünen Häckchen für die Vorgesetzten sind wichtig. Grüne Häkchen für Vorgesetzte muss es im Sprint nicht geben. Die helfen nicht bei der Entwicklung. Wenn ein Vorgesetzter während des Sprints quengelt - schickt ihn zum Scrum-Master oder PO. Wofür gibt es diesen Proxy? Klar kann der Scrum-Master auch einen Burndown-Chart malen und grüne Häkchen reporten. Das ist aber keine Aufgabe fürs Daily, das kann er ganz allein machen.
René H. schrieb im Beitrag #6141570:
> Wie dunkel? :-)
Erst Du :-)
Hugo H. schrieb: > René H. schrieb: >> Wie dunkel? :-) > > Erst Du :-) Rapid Prototyping. Das Team organisiert sich selbst. Jeder im Team ist in der Lage jeden Task zu "erfüllen". Tägliche Lieferungen (bzw. jedes commit/push) stellt sicher das der Code kompilierbar ist. Die QA kann jedes neu implementiertes Feature sofort testen (wenn es den eine QA gibt). Faktum ist aber leider, dass man den Bockmist auf alles versucht abzuwälzen. Selbst in ein Maintenance Team von 8 Produkten. Das jeder alles kann ist ebenfalls Bullshit in der heutigen Technologie Welt ist das nicht realistisch. Die Daylies ziehen sich in der Regel unnötig in die Länge, weil der Scrummuster eine Pfeife ist und kein Plan hat. Die Sprint Planning sind dann noch schlimmer. Unnötiges Geschwafel.
:
Bearbeitet durch User
Hugo H. schrieb: > Erst Du :-) Damit meinte ich: Hugo H. schrieb im Beitrag #6141568: > René H. schrieb: >> die Grundidee Die möchte ich gerne erklärt haben :-) Was "rapid prototyping" ist weiß ich - lebe ich (sofern es um Dialog-orientierte Entwiclungen geht).
Angehängte Dateien:
-
Scrummaster.jpg
9,5 KB
Unglaublich schrieb: > Ich stehe nur gelangweilt daneben und überlege mir, wann ich wiedermal > den Rasen mähen muss. > > Fehlt mir da ein Gen? Nein, dir fehlt überhaupt nichts, geht mir genau so. Ich wünschte Scrum würde bei uns "abgeschafft" werden. Ich weiß gar nicht warum man sich täglich 15min hinstellen muss und über das redet, was sowieso klar ist. Ich mein wir sitzen alle im selben Raum und quatschen den ganzen Tag über die kack Software. Okay, ich gebe zu der PL weiß es nicht, aber muss der alles wissen? Er steht trotzdem da und hört sich alles an. lol. Der PL!!! Man sieht deutlich welche Prioritäten er scheinbar hat. Egal. Ich stehe so da und erzähle meist mein JIRA-Ticket so, dass es ja keine Nachfragen gibt oder mir noch Hilfe angeboten wird. "Ich bearbeite gerade JIRA-Ticket ABC, es geht um XYZ, ich werde voraussichtlich Freitag fertig und schnappe mir dann JIRA-Ticket DEF." Schön unter dem Radar bleiben. Wie zu DDR-Zeiten Leute. ;-)
Matthias Döpke schrieb: > Vor 25 Jahren haben wir mit wenigen Leute Riesen-Projekte gestemmt oder > zu zweit die komplette Steuergeräte-SW entwickelt (incl. > Hardwareabsprache) ... wir machten HW, SW, System und wussten, dass das > eine nicht ohne das andere laufen kann und kannte die ganze > Funktionalität aus dem Kopf, weil das unser 'Kind' war. > Heute ist alles in einzelne Abteilungen aufgesplittet, weil ASPICE das > verlangt und niemand fühlt sich verantwortlich. > 30 Leute bekommen in 4 Jahren nicht die Arbeit (ok, damals gabs kein > AUTOSAR und solchen Quatsch) hin, die wir damals in einem Jahr zu zweit > gemacht haben. Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder ohne Scrum. PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer sich und laestern dann in Online Foren.
BonusGekoppeltAnGewinn schrieb: > Nur armselige Wuerstchen machen auf dicke Hose und pupsen nur heisse Luft :-)
Beitrag #6141669 wurde vom Autor gelöscht.
BonusGekoppeltAnGewinn schrieb: > PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger > gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten > und Wissen weiterzugeben. Wenn sie im JIRA einen Task oder Story erfassen und mir Assignen dann mache ich das sehr gerne. Merkst Du was?
BonusGekoppeltAnGewinn schrieb: > PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger > gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten > und Wissen weiterzugeben. Nein feuert die Person die solche Honks eingestellt hat. > Nur armselige Wuerstchen behalten alles fuer > sich und laestern dann in Online Foren. Das sind Grundlagen, man keine Zeit denen das Laufen beizubringen, das lernt man in der Ausbildung/Studium. Wer solche Pfeifen einstellt gehört sofort gefeuert.
Also ich finde Scrum super. Bin selbst Certified Scrum Master und finde die Methodik toll - sofern sie zum Team und Projekt passt. In der Realität konnte ich aber leider noch kein einziges echtes Scrum-Projekt beobachten. Denn die Methodik ist ja recht streng vorgegeben. Stattdessen werden meist die dysfunktionalen Prozesse umetikettiert: * Kein Plan, ständige Änderungen... => "Agil" * Schwachsinnige Meetings => "Daily" Etc. Scrum is a Meme schrieb: > Er steht trotzdem da und hört sich alles an. lol. Der PL!!! Man sieht > deutlich welche Prioritäten er scheinbar hat. Typisch - bei Scrum gibt's keinen Projektleiter. Ist also nicht Scrum sondern eine Fassade um die eigene Unfähigkeit zu verschleiern. Mein Teamkollege rührt beim Kunden auch immer die Selbstbeweihräucherungstrommel wie agil wir doch mit Scrum arbeiten. Die Kunden rollen heutzutage nur noch mit den Augen (wird wohl Zeit für eine neue Sau), aber amüsieren sich dann wenn ich dabei mitmache.
René H. schrieb: > BonusGekoppeltAnGewinn schrieb: >> PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger >> gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten >> und Wissen weiterzugeben. > > Wenn sie im JIRA einen Task oder Story erfassen und mir Assignen dann > mache ich das sehr gerne. > > Merkst Du was? Natürlich brauche ich dann noch eine Nummer für die Zeiterfassung. Ich kann dann den Zeitaufwand des Kollegen Weiterbildung im Jira Schätzen (schätze das mal ;-)) und im nächsten Sprint einplanen. Und genau so läuft das, nicht anders. Für Team Kollegialität lässt Scrum keinen Raum. No Way!
Beitrag #6141724 wurde von einem Moderator gelöscht.
Unfassbar schrieb: > Jira ist der Vorhof der Hölle! Treffender lässt sich das wohl nicht ausdrücken. +1
René H. schrieb: > Natürlich brauche ich dann noch eine Nummer für die Zeiterfassung. Ich > kann dann den Zeitaufwand des Kollegen Weiterbildung im Jira Schätzen > (schätze das mal ;-)) und im nächsten Sprint einplanen. Und genau so > läuft das, nicht anders. Für Team Kollegialität lässt Scrum keinen Raum. > No Way! "Du sollst 100% deiner Zeit auf eingeplante Tickets verbuchen" hört sich nicht nach Scrum sondern nach Erbsenzählermethodik an.
Jan H. schrieb: > Erbsenzählermethodik Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks nicht in der "Estimated Time" abhandle werden Fragen gestellt.
:
Bearbeitet durch User
Hugo H. schrieb: > aber den Spruch kann ich nicht mehr hören tut mir leid Hugo H. schrieb: > (O.K. ich tue gerne, wofür ich bezahlt werde) ich habe ca. 99% meines Arbeitsleben gerne das gearbeitet was mir Spass macht, es nie als Bürde gesehen, nie beim Ende Klingeln das Werkzeug in die Ecke geworfen, Zeit Überstunden extra bezahlt, Sonntag, war mir egal. Das Geld musste nur etwas mehr als reichen, solange ich damit gut lebte war es für mich OK. Nachteil reich bin ich nicht geworden, aber macht reich glücklich? Hugo H. schrieb: > O.K, wenn Du ein reicher Erbe bist und/oder kein Geld verdienen musst > mag das anders aussehen. nö, musste immer arbeiten! auch als Student.
:
Bearbeitet durch User
Hugo H. schrieb: > Hugo H. schrieb: >> Erst Du :-) > > Damit meinte ich: > > Hugo H. schrieb: >> René H. schrieb: >>> die Grundidee > > Die möchte ich gerne erklärt haben :-) > > Was "rapid prototyping" ist weiß ich - lebe ich (sofern es um > Dialog-orientierte Entwiclungen geht). Jetzt Du! :-)
René H. schrieb: > Wenn ich meine Tasks nicht in der "Estimated Time" abhandle werden > Fragen gestellt. Deshalb sollte man auch immer kräftig over-estimaten. Auch so eine Bewältigungsstrategie bei Diagnose Scrum
René H. schrieb: > Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks > nicht in der "Estimated Time" abhandle werden Fragen gestellt. Scrum verlangt doch gar keine "Estimated Time". Empfohlen wurde mir beispielsweise eine Kategorisierung nach T-Shirt-Größen. Und es ist auch nicht nötig seinen Sprint mit Tasks vollzuknallen. Aber ich kenne ja die Realität auch bei uns. Der schlaue Projektleiter, den es bei Scrum ja gar nicht geben sollte, lässt sich die Aufwände auf Viertelstunden genau schätzen, drückt noch ein bisschen weil die faulen Programmierer ja sicher gepuffert haben und knallt den Sprint dann mit der theoretischen Iststundenanzahl voll. Scrum steht drauf obwohl es ziemlich das Gegenteil der Philosophie ist.
blöde meetings haben mich erst jetzt erwischt, da sitzt man und gibt seine Kenntnisse zum Besten und keiner nimmt diese auf oder arbeitet danach, es wird ALLES anders gemacht was man auf Grund seiner Erfahrung vorschlägt und weswegen man eingeladen wurde und es ist egal. Diese "meetings" hätte ich nicht mehr gebraucht.
Joachim B. schrieb: > Das Geld musste nur etwas mehr als reichen, solange ich damit gut lebte > war es für mich OK. Nachteil reich bin ich nicht geworden, aber macht > reich glücklich? Nein, alleine nicht, aber man muss sich aufgrund seiner Passion trotzdem nicht ausbeuten lassen. Ich bin für gutes Geld für gute Arbeit (die auch Spaß machen darf), ich finde, das ist kein Widerspruch.
Joachim B. schrieb: > Hugo H. schrieb: >> (O.K. ich tue gerne, wofür ich bezahlt werde) Unrecht hat Hugo aber nicht. Ich programmiere seit ich 12 bin. Es ist eine Leidenschaft und deshalb mache ich das auch heute noch gerne (fragt nicht wie lange das her ist :-)). Es sind die Umstände die einem das madig machen, nicht nicht die Sache. Darauf war ich ehrlich gesagt nicht vorbereitet. Jetzt ist es halt so. Ich zieh das noch ein paar Jahre durch bis ich es mir leisten kann in Rente zu gehen (oder ausgemustert werde, was wahrscheinlicher ist).
Qwertz schrieb: > Ich bin für gutes Geld für gute Arbeit (die auch > Spaß machen darf), ich finde, das ist kein Widerspruch. dafür, ich fand das Geld das ich bekam immer gut (OK heute denke ich hätte besser sein können). René H. schrieb: > Es sind die Umstände die einem das madig machen, nicht nicht die Sache. stimmt, vor allem in meinen 1% Jobs, da wollte und war ich halt schnell wieder raus, alles in Allem keine schlechte Bilanz, ich denke Andere mussten ab und an viel länger miese Jobs machen in Ihrem Arbeitsleben als nur 1%.
Jan H. schrieb: > In der Realität konnte ich aber leider noch kein einziges echtes > Scrum-Projekt beobachten. Denn die Methodik ist ja recht streng > vorgegeben. Stattdessen werden meist die dysfunktionalen Prozesse > umetikettiert Oje, das Geschwafel eines Scrum-Fanboys. So wie das Geschwafel eines Sozialismus-Funktionärs. Merke: ein Verfahren, was nicht zur realen Welt passt, hat in der realen Welt nichts verloren. Das gehört höchstens in Märchenbücher.
René H. schrieb: > Jan H. schrieb: > Erbsenzählermethodik > > Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks > nicht in der "Estimated Time" abhandle werden Fragen gestellt. Estimated time einfach höher ansetzen.
MaWin schrieb: > Oje, das Geschwafel eines Scrum-Fanboys. > > So wie das Geschwafel eines Sozialismus-Funktionärs. > > Merke: ein Verfahren, was nicht zur realen Welt passt, hat in der realen > Welt nichts verloren. Das gehört höchstens in Märchenbücher. Seine Welt in einfache Schubladen zu klassifizieren ist menschlich, aber taugt selten als absolute Wahrheit.
Dennis schrieb: > René H. schrieb: >> Jan H. schrieb: >> Erbsenzählermethodik >> >> Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks >> nicht in der "Estimated Time" abhandle werden Fragen gestellt. > > Estimated time einfach höher ansetzen. Tja, das wird dann durch das Team angezweifelt: "Low Performer". Hmmmm....
:
Bearbeitet durch User
René H. schrieb: > Tja, das wird dann durch das Team angezweifelt: "Low Performer". > > Hmmmm.... Muss schon ein Scheiß team sein... Von meinem Team kommt höchstens dann beim Scrum planning Einspruch, wenn ich mich zu übernehmen drohe. Auf einen gestressten Kollegen der das Verhältnis von eingeplanten zu erledigten User Stories ruiniert hat nämlich keiner Bock. Das der Scrum master niemals selbst einschätzen kann wie groß ein einzelner Task ist ist jedem klar. Daher immer niedrig ansetzen, bisschen Fachchinesisch hilft um die Aufgaben jede für sich wie eine praktisch unmögliche Aufgabe wirken zu lassen. Dann während des Sprints noch extra Aufgaben einbuchen, das macht Eindruck und man kriegt die Dinge die wirklich getan werden müssen am product owner vorbeigeschmuggelt.
Unglaublich schrieb: > Unfassbar, was da für Zeit und Energie bei drauf geht. Man hätte auch > einfach mal am Anfang einer Entwicklung einen Anforderungskatalog > erstellen können - dann könnte man sich diesen modernen Unsinn sparen > und jeder weiß, was realistisch zu tun ist. Seit irgendjemand vor gefühlt 15 Jahren beschlossen hat, dass SCRUM etwas gutes ist und alle Probleme löst, hechelt dem jeder hinterher. Ich kenne das von meiner Tätigkeit aus dem Automotive-Sektor, dem ich vor Jahren schon den Rücken gekehrt habe. Entwicklung in Software gleicht heute einem großen Gruppenbasteln, wobei Gruppe als heilig angesehen wird, da Team das große Ziel ist. Gleichzeit wird das Teamdenken nachhaltig gestört. Dies ist ein klassisches Beispiel: Solches Denken ist die weit verbreitete Reaktion der SCRUM-Politik: Bewerber schrieb: > Daher immer niedrig ansetzen, bisschen Fachchinesisch hilft um die > Aufgaben jede für sich wie eine praktisch unmögliche Aufgabe wirken zu > lassen. Dann während des Sprints noch extra Aufgaben einbuchen, das > macht Eindruck und man kriegt die Dinge die wirklich getan werden müssen > am product owner vorbeigeschmuggelt. Weiteres Tun ist das Zurückhalten von potenziellen Gefahren und Problemen, um noch etwas in der Hinterhand zu haben, wenn Verzug droht. Dann zieht man einfach das Problem und lässt den PO grübeln und neu disponieren. Damit sind alle Sprinttermine wieder offen. Damit geht das Eigentliche jeder guten Teamleistung in die Binsen.
:
Bearbeitet durch User
BonusGekoppeltAnGewinn schrieb: > Jaja frueher war alles besser.... NICHT! Ich kenne niemanden, der wieder > gerne in den 90ern leben will. Da muss man schon von gestern sein. Mit > so jemanden kann man auch nicht gut zusammenarbeiten, egal ob mit oder > ohne Scrum. > > PS: Wenn die Frischlinge in deiner Abteilung nicht wissen wofuer Zeiger > gut sind, dann ist es an den alten Hasen sie ordentlich einzuarbeiten > und Wissen weiterzugeben. Nur armselige Wuerstchen behalten alles fuer > sich und laestern dann in Online Foren. Vielen Dank für die lieben Worte ... ein netter Zeitgenosse :) Ich nehme gerne Dinge an die Innovation und echte Vorteile bringen ... ich programmiere heute auch nicht mehr in Assembler ;) Die Frischlinge sind leider keine, sondern teilweise (fast) mein Alter. Sie haben aber weder Ahnung von Software, noch Hardware ... meinen aber Prozesse und moderne Tools lösen alle Probleme von selbst. Sie implementieren Code, ich teste den und gebe den wegen Fehlern zurück. Dann kommen solche Leute und möchten von mir möglich exakt wissen, wo sie was ändern müssen. Hat nichts mit dem Thema zu tun ... aber komischerweise sind genau solche Pfeiffen die, die auf solchen modernen, unbrauchbaren Mist stehen und ganz toll finden (z.B. modellbasierte Entwicklung - ohne zu verstehen was die Blöcke im Hintergrund überhaupt genau tun). Das sind auch die Mitarbeiter die als erste bei jeder Gelegenheit der Arbeit fernbleiben ... Ich helfe gerne und gebe mein Wissen weiter, aber es gibt Menschen die sind einfach unbelehrbar ... ;)
Matthias Döpke schrieb: > Noch Fragen ??? Eher nicht. Aber ich verstehe Dich vollkommen. Mein Beileid. AG Wechsel?
Name: schrieb: > Heute sinds halt die "Schneeflocken", die "nix aushalten", und "nur am > Handy rumwischen. Nette Geschichte: letzten Winter laufe ich hier durch die Stadt. Kaum Fußgänger unterwegs. Ich sehe so 40m vor mir einen Schulbub (Grundschule) auf mich zukommen. Gehweg war an der Stelle so 3-3,5m breit. Mitten auf dem Weg stand ein temporäres Strassenschild (die unten mit diesen Platten beschwert sind). Der Bub geht auf mich zu, guckt dabei nur auf sein Handy. Ich schaue nach unten, nach einigen Sekunden wieder nach vorne. Er sitzt hinter dem Schild auf dem Hosenboden, rappelt sich langsam auf und greift mit der rechten Hand an die Stirn. Ich musste acht geben, dass ich nicht losgelacht habe. Meine Eltern hätten gesagt: "Pass uff wo 'de hi'latschst!"
Tilo R. schrieb: > Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern! Typischer Bullshit. In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner Karriere arbeitet und sich wichtig macht. So wild herumlaufende Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab. Soll es in Scrum nicht geben? Ja, FML. Ist nicht die Schuld von Scrum? Ja, FML. Eine Methode, die nicht robust genug ist so etwas auszuhalten, und Scrum hält es nicht aus, ist nun mal scheiße. > Grüne Häkchen für Vorgesetzte muss es im Sprint nicht geben. Die helfen > nicht bei der Entwicklung. Doch, die muss es geben, wenn der Chef sagt es muss sie geben. > Wenn ein Vorgesetzter während des Sprints > quengelt - schickt ihn zum Scrum-Master oder PO. Ha, ha, ha. Der Begriff "abhängiger Beschäftigter" sagt dir was? > Wofür gibt es diesen > Proxy? Damit zwei Leute mehr schönen Ehrentitel haben und von einer Karriere träumen können. > Klar kann der Scrum-Master auch einen Burndown-Chart malen und grüne > Häkchen reporten. Das ist aber keine Aufgabe fürs Daily, das kann er > ganz allein machen. Dann müsste er ja mal selber arbeiten und denken. Ist doch viel einfacher dass das Team "mal schnell" unter Aufsicht des Scrummasters malt und Häckchen macht. Das spart dem Scrummaster noch dazu den Aufwand die Ergebnisse separat im Team zu kommunizieren. War ja jeder dabei und "involved".
Unglaublich schrieb: > endwiggler schrieb: >> Dann sind die Scrummaster zufrieden, dass ich selbst einen >> längerfristigen Plan verfolge muss der nicht wissen. > > Uhuh, ganz ganz schlechte Teammoralbildung. Vielleicht solltet ihr mal > häufiger zusammen in der Kantine Mittagessen gehen oder abends noch in > der Firma am Kicker fachsimpeln. Genau, Abends am Kicker. Warum nicht gleich auf die Familie scheißen und direkt neben, oder besser, in die Firma einziehen.
Beitrag #6142110 wurde von einem Moderator gelöscht.
René H. schrieb: > Jan H. schrieb: >> Erbsenzählermethodik > > Das ist die unweigerliche Konsequenz von Scrum. Wenn ich meine Tasks > nicht in der "Estimated Time" abhandle werden Fragen gestellt. Und? Dann beantwortest du die Frage eben. Oder fehlen dir die Cojones, um zu sagen "ich hab mein Arbeitspensum leider nicht fertig gekriegt wegen XYZ"? Genau dieses Feedback ist der Sinn der Retrospektive, um mit der Zeit die Abschätzungen zu verbessern. Und stell dir vor, das hat auch nix mit Scrum zu tun, derartiges Feedback macht auch ohne Scrum Sinn. Woher soll der Vorgesetzte oder der Rest des Teams denn sonst wissen, dass es irgendwo hakt? René H. schrieb: > Tja, das wird dann durch das Team angezweifelt: "Low Performer". Tja, wenn du dich durch sowas fertig machen lässt... Wahrscheinlich verschweigst du auch immer schön, wenn du hinter dem Zeitplan bist, und kompensierst das dann durch kräftig Überstunden, denn der Projektleiter darf ja auf keinen Fall mitkriegen dass der Zeitplan zu eng war? Sehr gut, denn dann wird er ihn beim nächsten mal gleich noch enger gestalten, denn es hat ja funktioniert. Michael Gugelhupf schrieb: > Tilo R. schrieb: >> Ihr seid das Scrum-Team - ihr könnt die Spielregeln ändern! > > Typischer Bullshit. > > In Realität wird dem Ganzen ein Manager oder eine andere Aufsichtsperson > übergestülpt, die natürlich seine Existenz rechtfertigen muss, an seiner > Karriere arbeitet und sich wichtig macht. So wild herumlaufende > Programmierer ganz ohne Aufsicht können die meisten Firmen nicht ab. > > Soll es in Scrum nicht geben? Ja, FML. > Ist nicht die Schuld von Scrum? Ja, FML. "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, deswegen ist Scrum kacke!!1elf" Sounds legit.
René H. schrieb: > Joachim B. schrieb: >> Hugo H. schrieb: >>> (O.K. ich tue gerne, wofür ich bezahlt werde) > > Unrecht hat Hugo aber nicht. Ich programmiere seit ich 12 bin. Es ist > eine Leidenschaft und deshalb mache ich das auch heute noch gerne (fragt > nicht wie lange das her ist :-)). > Es sind die Umstände die einem das madig machen, nicht nicht die Sache. > > Darauf war ich ehrlich gesagt nicht vorbereitet. Jetzt ist es halt so. > Ich zieh das noch ein paar Jahre durch bis ich es mir leisten kann in > Rente zu gehen (oder ausgemustert werde, was wahrscheinlicher ist). Entwickler die Entwicklen mit Basteln verwechseln ist die Spezies, die in Firmen den größten Schaden anrichten. Das sind zwei völlig verschiedene Dinge. Da kommt meist nichts dabei raus. Das sind dann die "tollen" "Programme" für die es keine Doku gibt, keinen Projektplan, keine Tests und die massig Bugs enthalten. Weil "Programmieren ja soviel Spass macht", lässt man den "lästigen Beikram" weg oder die Kollegen machen. Dass Softwareentwicklung mit Programmieren wenig zu tun hat, wissen solche Bastler oft nicht. Bin Hardwerker, aber auch hier gibts diese Spezies. Auch ich bastle in der Freizeit an Elektronik rum. Die Tätigkeit hat mit Hardwareentwickeln nur wenig gemeinsam. Wenn doch: Herzliches Beileid für die Kollegen :-(
vn nn schrieb: > Genau dieses Feedback ist der Sinn der Retrospektive, um mit der Zeit > die Abschätzungen zu verbessern. Nein, der Sinn ist, dass man die Leistung jeder Person genau kontrollieren, bewerten und bemaßen kann, jederzeit und möglichst fein granuliert. So wie man das am Fliessband kann. Und genau das will der BWLer, Chef und Controller. Genau deshalb ist die Chefetage ja auch so geil auf das SCRUM Zeugs, zusätzlich ist es noch ein Marketing Argument. Meine Devise: Wenn man ständig kurze Sprints macht und dann wieder prüft wie weit man gekommen ist, dann ist man deutlich langsamer und schneller erschöpft, als wenn man kontinuerlich langsamer joggt. Oder hast du schon mal gesehen, daß jemand mit kurzen Sprints einen Marathon gewonnen hat? Und wenn ich unsere SCRUm Teams hier sehe (nein, ich bin zum Glück in keinem) dann sind sie weder schneller noch besser in ihrer Arbeit, aber unzufriedener.
:
Bearbeitet durch User
vn nn schrieb: > "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, > deswegen ist Scrum kacke!!1elf" Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht 100% idealen Umgebung sofort zusammenbricht. > Sounds legit. Wie alt bist du? 12?
Scrum wurde von China oder den USA erfunden um uns endgültig zu ruinieren. Mein Arbeitgeber hat es auch eingeführt, seitdem kommt nixhts mehr raus .....
Name: schrieb: > Das sind dann die "tollen" "Programme" für die es keine Doku gibt, > keinen Projektplan, keine Tests Klingt wie die allseits bei Kunden und Chefs beliebten schnell erstellten Prototypen. Es kann gar nicht schnell genug gehen. Und meistens bliebt es dann beim Provisorium, denn für alles andere ist ja kein Geld da, läuft a, irgendwie. Es ist nicht der basteldnde Entwickler, der so geil darauf ist. Und gerdae Scrum manifestiert diese (Fehl-)Entwicklung: im ersten Sprint den Prototypen und dann kontinuierlich 'verbessern'.
Michael Gugelhupf schrieb: > Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht > 100% idealen Umgebung sofort zusammenbricht. Nö. MaWin schrieb: > Und gerdae Scrum manifestiert diese (Fehl-)Entwicklung: im ersten Sprint > den Prototypen und dann kontinuierlich 'verbessern'. Das hat doch nichts mit Scrum zu tun. Völlig unabhängig von der Methodik kann ich mich dafür entscheiden einen Prototypen wegzuwerfen oder nicht.
MaWin schrieb: > Und meistens bliebt es dann beim Provisorium, denn für alles andere ist > ja kein Geld da, läuft a, irgendwie. Bei den Scrumprojekten werden dann solange die Anforderungen runter- geschraubt bis ein "minimal verkaufsfähiges Produkt" entsteht. Hab ich alles schon erlebt.
hbl schrieb: > "minimal verkaufsfähiges Produkt" Nennt sich "minimum viable product" Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so einem "minimal viable system" herum, das der Nachfolger eines von 4 Personen (incl. mir) entwickelten Produktes werden soll. Wir hatten damals 3 Monate bis zur Installation beim ersten Kunden.
Udo S. schrieb: > Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so > einem "minimal viable system" herum, das der Nachfolger eines von 4 Ich kenne das ! Da sollte etwas ersetzt werden, im Endeffekt konnte das neue nicht einen Bruchteil des Altsystems. Damit fahren die Burschen dann auch noch zu einem Keykunden, der hat sie zum Glück raus- geschmissen. Aber immerhin ist das ganze mit agilen Methoden entwickelt. Bei meinem Arbeitgeber läuft das nur noch so. Nichts kommt mehr raus.....
Udo S. schrieb: > hbl schrieb: >> "minimal verkaufsfähiges Produkt" > > Nennt sich "minimum viable product" Nein, minimum marketable product. Minimum viable product ist das mindeste was man dem Kunden für eine erst evaluation in die hand drücken kann um festzustellen ob es in die richtige Richtung geht.
Udo S. schrieb: > Eins unserer Scrum Teams bastelst schon seit eineinhalb Jahren an so > einem "minimal viable system" herum, das der Nachfolger eines von 4 > Personen (incl. mir) entwickelten Produktes werden soll. > Wir hatten damals 3 Monate bis zur Installation beim ersten Kunden. Kenn ich... Seit mehr als 10 Jahren versucht ein 10 mal grösseres Team mit Scrum ein altes Produkt durch einen Nachfolger zu ersetzen (der zu Beginn zwar mal besser, vor allem schneller sein sollte, aber inzwischen wurden alle Anforderungen gestrichen, man ist froh wenn er dasselbe kann und nicht langsamer läuft), der damals (vor 2000) in 2 Jahren von 2 Leuten ohne Scrum realisiert wurde und sich seit dem gut verkauft.
:
Bearbeitet durch User
Michael B. schrieb: > aber inzwischen wurden alle > Anforderungen gestrichen, man ist froh wenn er dasselbe kann und nicht > langsamer läuft), der damals (vor 2000) in 2 Jahren von 2 Leuten ohne > Scrum realisiert wurde und sich seit dem gut verkauft. Ich hab geschafft und du bist nix Mentalität. Immer die gleiche Leier. Echt amüsant die Diskussion zu verfolgen, wobei etliche Klischees erfüllt werden. Jungs, setzen 6;-9
soso schrieb: > Ich hab geschafft und du bist nix Mentalität. Und ? So ist die Welt. Einige können es, und Andere können eben nix. Deine Mentalität ist: "Wenn man es nur hart genug anstrengt, gibt es Nichts, was man nicht erreichen könnte ? Bullshit, passend zum Bingo.
soso schrieb: > Ich hab geschafft und du bist nix Mentalität. Es gibt überall bessere und schlechtere Leute. Sicherlich auch bessere als man selbst .... Aber wenn gerade Leute die noch nicht einmal herkömmlich vernünftig arbeiten können, meinen mit neuen Techniken und Tools könne man fehlende Kenntnisse (manchmal sogar Basics) und Fähigkeiten wettmachen, irren sie gewaltig. Wenn man Scrum wenigstens sinnvoll anwenden würde, aber damit nur Zeit totzuschlagen und Motivation von Mitarbeitern zusätzlich zu rauben, macht keinen Sinn. Oft sind es halt nicht die Leute die gut führen und vernüftig und zielstrebig arbeiten die so etwas einführen oder/und leiten, sondern genau die anderen. Darum ging es in diesem Blog ... und offenbar stimmen die meisten der Poster in der Meinung überein - was natürlich nicht repräsentativ ist ;)
hbl schrieb: > endgültig zu ruinieren. Mein Arbeitgeber hat es auch > eingeführt, seitdem kommt nixhts mehr raus ..... Scrum-Guru:"Ja dann macht ihr es nicht richtig!!! Ich kenn mich aus!" Ist das selbe Geschwätz wie beim "Kein Wahrer Schotte": https://de.wikipedia.org/wiki/Kein_wahrer_Schotte
Platzwart schrieb: > Ist das selbe Geschwätz wie beim "Kein Wahrer Schotte": > https://de.wikipedia.org/wiki/Kein_wahrer_Schotte Der Hinweis auf Religionen in dem Wikipedia Artikel passt gut. Ich glaube SCRUM ist so ein bischen was wie eine Religion für manche. Wie gesagt, man kann so arbeiten, aber meins ist es nicht und was ich gesehen habe wird es oft für mehr Überwachung und zur Beurteilung von Personen eingesetzt und die Produkte werden dadurch nicht besser. Die Motivation ist bei vielen eher schlechter, nicht bei allen.
Name: schrieb: > Entwickler die Entwicklen mit Basteln verwechseln ist die Spezies, die > in Firmen den größten Schaden anrichten. Du verwechselst das mit "Dummlaberern" - davon gibt es mehr als genug. Ich zumindest habe nicht mit Entwicklern zu tun, die das Entwickeln mit Basteln verwechseln.
Michael Gugelhupf schrieb: > vn nn schrieb: >> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, >> deswegen ist Scrum kacke!!1elf" > > Nein, Scrum ist kacke, weil Scrum nicht robust ist und in einer nicht > 100% idealen Umgebung sofort zusammenbricht. Wasserfall und V-Modell sind auch kacke, weil die nicht robust sind und in einer nicht 100% idealen Umgebung sofort zusammenbrechen. Oder was macht man da, wenn zu einem späteren Zeitpunkt noch Requirements dazukommen? Der ganze Thread ist ein Lamentieren, wie furchtbar doch alles ist und dass früher alles besser war. Stimmt ja auch :-) Die Dilbert-Comics beschreiben genau das selbe Bullshit-Bingo und kommen aus einer Zeit, als noch nicht die ganze Branche mit Scrum und agile durchseucht war. Also erzählt mir nicht, dass die Probleme ausschließlich an Scrum liegen. Auch früher schon gab es immer wieder Hypes und neue Konzepte, die in der Theorie toll waren, halbgar über ein bestehendes Unternehmen gestülpt aber nicht richtig funktioniert haben.
:
Bearbeitet durch User
Tilo R. schrieb: > Wasserfall und V-Modell sind auch kacke, weil die nicht robust sind und > in einer nicht 100% idealen Umgebung sofort zusammenbrechen. > Oder was macht man da, wenn zu einem späteren Zeitpunkt noch > Requirements dazukommen? Darüber reden und entsprechenden Zusatzaufwand abstimmen. Ist das bei Srcum anders? Tilo R. schrieb: > Also erzählt mir nicht, dass die Probleme > ausschließlich an Scrum liegen. Nein - die werden dadurch aber auch nicht weniger - eher mehr. Wenn ich nicht von Anfang eine genaue Vorstellung davon habe, wie "mein Haus" aussehen soll - wie will ich mich dann iterativ nähern ohne deutlich mehr (gegenüber welcher Schätzung? Einem pauschalen Maximalbetrag?) zu investieren und mein Ziel zu erreichen? Ich habe nichts gegen Scrum - außer dass es instrumentalisiert und bürokratisiert wird (offiziell natürlich anders - dynamisch - dargestellt). Wie geschrieben lebe ich "rapid prototyping" (bei Dialog-orientierten Entwicklungen) - das ist nichts wesentlich anderes - nur ohne Bürokratie. Tilo R. schrieb: > Auch früher schon gab es immer wieder Hypes und neue Konzepte, die in > der Theorie toll waren, halbgar über ein bestehendes Unternehmen > gestülpt aber nicht richtig funktioniert haben. Ja - die sind auch alle eines stillen Todes gestorben :-). Scrum - ruhe in Frieden :-)
:
Bearbeitet durch User
Ich war mal kurz in einer kleine Firma, da gab es mehr Projektentwickler/leiter, Scrum-Master, Product-Owner, Schwaller-Priest,... als reine Entwickler. Drei Entwickler, ein Student der seine Abschlussarbeit dort machte, ein Azubi und eine Teilzeitfrau die ich nie gesehen habe, die hat glaube ich Design oder sowas gemacht, GUIs aufgemöbelt, Icons gemalt. Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des selben products. Der Eine von denen (der war zertifizierter Scrotum Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in dem Laden installiert hat. Ich war dort nicht mal ein Monat. Einer dieser Schwätzer ist ja schon schlimm aber wenn die du die im Rudel den ganzen Tag um dich rum hast, da drehste durch. Das ist wie im Kindergarten, malen nach Zahlen, Software entwickeln mit Scrum. Sprint, daily, product owner, user story, backoffice,... immer wenn ich diese Begriffe höre zucke ich sofort zusammen und muss an diese Firma denken.
Dick Boutsos schrieb: > Sprint, daily, product owner, user story, backoffice,... immer wenn ich > diese Begriffe höre zucke ich sofort zusammen und muss an diese Firma > denken. Klingt traumatisch :-)
Dick Boutsos schrieb: > Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des > selben products. Der Eine von denen (der war zertifizierter Scrotum > Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper > gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in > dem Laden installiert hat Das ist heutzutage leider üblich geworden! Waren früher die Fertigungsleute die Arbeitshuren die man ausbeuten musste sind es heute die Programmierer! Diese sogenannte Networking ist eine massive Seuche für die, die noch etwas leisten und für den Betrieb sowieso! Fakt ist, mit Bullshitbingo, Networking und viel Geschwafel geht es die Erfolgsleiter nach oben! Wer nicht mitspielt hat schon verloren! Oben angekommen ist der Erfolg der Firma bzw. der Arbeitsweise egal, geht man halt woanders hin! Dieser Wahnsinn hat system! Zack ist die nächste Firma am Abgrund! Leider nicht so schnell, daß es sich rumspricht, aber dennoch real! Die größten Posauner mit der niedrigsten Kompetenz in den wichtigsten Belangen zeigen, wo es lang geht! Leider habe ich wohl ein Zuviel an Kompetenz, und zuwenig Dummschwätz... deshalb komm ich übers Brötchenbacken auch nicht hinaus!
Tilo R. schrieb: > Oder was macht man da, wenn zu einem späteren Zeitpunkt noch > Requirements dazukommen? Eine neue Rechnung an den Auftraggeber schreiben, was sonst ?
MaWin schrieb: > Tilo R. schrieb: >> Oder was macht man da, wenn zu einem späteren Zeitpunkt noch >> Requirements dazukommen? > > Eine neue Rechnung an den Auftraggeber schreiben, was sonst ? Neue Requirements bedeuten in jedem Modell dass selbe. Änderungen. Das kann Agile nicht besser und nicht schlechter auffangen als andere Modelle. Scrum war nicht dafür gedacht die Arbeitsleistung des Teams und einzelnen Personen zu kontrollieren und zu messen, aber dafür wird es verwendet und das ist nun mal ein Faktum. In der Realität wird es dafür missbraucht, damit auch die faulen ihre Ärsche hochbekommen. Darunter haben aber alle zu leiden, mit eben den bereits erwähnten vielen Meetings. Das ist kein Klagen, dass ist eine Kritik an der Methode und wie sie verwendet wird!
René H. schrieb: > Neue Requirements bedeuten in jedem Modell dass selbe. Änderungen. Das > kann Agile nicht besser und nicht schlechter auffangen als andere > Modelle. Ich würde schon sagen, dass die agilen Modelle (sofern halbwegs tauglich gelebt) schon etwas besser auf wechselnde Anforderungen reagieren können. Da man nicht so weit in die Zukunft plant, muss man bei Änderung von Anforderungen nicht soviel Planungen "wegwerfen". Außerdem ist eine engere Einbindung des Kunden vorgesehen (idealerweise ist ja das Ergebnis jedes Sprints vom Kunden ausprobierbar, ob das in die Richtung geht, die er sich vorgestellt hat). Dadurch kommen Änderungswünsche eher => lassen sich noch besser integrieren als wenn man im V-Modell defakto alles fertig hat bevor der Kunde das erste mal was zu sehen bekommt. Natürlich gibt's das nicht ohne Nachteile, dadurch das man nicht alles im Vorfeld durchplant, muss man öfter was wegwerfen was im Nachhinein so nicht mehr passt (und das auch politisch akzeptiert sein). Am Ende ist es halt ein Werkzeug, und das muss zum Problem passend gewählt werden. Habe ich ein Projekt, wo die Anforderungen wirklich bekannt sind (z.B. Programmierung der Steuerung einer "konventionellen" Waschmaschine), ist was agiles einfach dämlich. Ist klar, dass sich die Anforderungen ändern, sei es weil das Projekt innovativ ist, so das der Kunde/die Nutzer erst beim Testen wirklich merken was sie (anders) wollen oder so lang läuft, dass klar ist, dass die Rahmenbedingungen sich ändern (irgendwas Konzernweites, Projekt über Jahre. Da ist klar, das zwischendurch sich 48 juristische Rahmenbedingungen ändern, 12 Firmen integriert und abgestoßen werden und das "irgendwie" die Anforderungen beeinflusst), dann kann agil sinnvoll sein. Sonst hat man nach 4 Jahren ein Produkt, was gut gewesen war vor 5 Jahren als die Anforderungen erhoben wurden, aber im aktuellen Umfeld einfach keinen Sinn mehr ergibt.
:
Bearbeitet durch User
René H. schrieb: > Neue Requirements bedeuten in jedem Modell dass selbe. > Änderungen. Das kann Agile nicht besser und nicht > schlechter auffangen als andere Modelle. Vielleicht solltest Du mal mit Deiner alten Tradition brechen und DOCH mal einen Blick in ein Buch werfen. Das "Agile Manifest" würde sich eignen.
Udo S. schrieb: > Der Hinweis auf Religionen in dem Wikipedia Artikel > passt gut. Ich glaube SCRUM ist so ein bischen was > wie eine Religion für manche. Ich fühle mich eher an den Marxismus erinnert... oder nehmen wir besser Cholesterin, das ist (scheinbar!) nicht so politisch: Ancel Keys hat seinerzeit eine Korrelation zwischen Cholesterinspiegel und Herz- infarktrate gefunden und dieses Ergebnis publiziert. Prompt kamen die Marktschreier und behaupteten: "Cholesterin löst Herzinfarkte aus!" Millionen Menschen quälten sich mit cholesterinarmer Ernährung, obwohl die Chemiker WISSEN , dass der Cholesterinspiegel nur minimal von dem mit der Nahrung aufgenommenen Cholesterin abhängt -- das meiste produziert der Körper selbst. Cholesterinsenker sind ein RIESIGER Markt, damit werden jedes Jahr Milliarden gescheffelt. Dumm nur, dass bisher niemand wirklich zuverlässig weiss, wovon der körper- eigene Cholesterinspiegel abhängt und was ein Eingriff von außen bewirkt. (Es gab beispielsweise Studien, die einen Zusammenhang zwischen zu niedrigen Cholesterin- spiegel und Demenz nahelegen.) Trotzdem werden fleissig Cholesterinsenker verschrieben... Und das Schlimmste: Außer ein paar akademischen Gehirn- wichsern interessiert sich NIEMAND dafür, was Keys wirklich geschrieben hat -- denn gerade, wenn er sich geirrt hat, sollte man ihm nur das als Irrtum anlasten, was er tatsächlich behauptet hat, und nicht das, was ihm von seinen unkundigen Jüngern angedichtet wurde...
Johannes F. schrieb: > Habe ich ein Projekt, wo die Anforderungen wirklich bekannt sind (z.B. > Programmierung der Steuerung einer "konventionellen" Waschmaschine), ist > was agiles einfach dämlich. Warum? Wenn du das agile Manifest liest ist die Änderung von Anforderungen nur ein kleinerer Teil der Idee. Wenn die anderen Rahmenbedingungen passen kann Scrum auch bei Projekten mit vollständig bekannten Anforderungen sinnvoll sein. Vielleicht möchte sie Hardwareentwicklung ja eine lauffähige Zwischenversion haben um das Schleudern oder EMV zu testen.
Johannes F. schrieb: > Ist klar, dass sich die Anforderungen ändern, sei es > weil das Projekt innovativ ist, so das der Kunde/die > Nutzer erst beim Testen wirklich merken was sie > (anders) wollen oder so lang läuft, dass klar ist, > dass die Rahmenbedingungen sich ändern (irgendwas > Konzernweites, Projekt über Jahre. Da ist klar, das > zwischendurch sich 48 juristische Rahmenbedingungen > ändern, 12 Firmen integriert und abgestoßen werden > und das "irgendwie" die Anforderungen beeinflusst), > dann kann agil sinnvoll sein. Du sprichst hier nebenbei aus, was ungefähr 90% der Kritiker hier in A,S&B ihr Leben lang ein Geheimnis bleiben wird: Es ist ein intrinsisches Merkmal eines Projektes, dass am Anfang ein Wissensdefizit vorliegt. Genau das Wissensdefizit ist es, was ein Projekt zum Projekt macht -- wüsste man am Anfang schon alles, wäre es ein einfacher Auftrag.
Dick Boutsos schrieb: > Von den Dampfplauderern gab es mind. 12. Z.t. waren mehre owner des > selben products. Der Eine von denen (der war zertifizierter Scrotum > Master) konnte gut den Chef beschwatzen, dass noch mehr solche Kasper > gebraucht würden und der nach und nach seine ganzen Kumpels dadurch in > dem Laden installiert hat. Das ist aber kein SCRUM-Problem. Solche Schwätzer haben wir hier auch. Nennt sich "Innovationsabteilung". Deren "geniale Ideen" dürfen normale Entwickler nicht kritisieren oder kommentieren, denn Cheffe hat sich dort als Teamleiter dort installiert und fasst Kritik entsprechend als persönlichen Angriff auf. Er liebt Selfies vor Patantanträgen, die öffentlich aushängen. Keine einzige der "Innovationen" jemals zu einem Produkt geführt. Seit 5 Jahren nur teures Scheitern, oft an der Physik. Wenn nich daran, dann daran, dass deren Schmarrn viel zu teuer ist. Die haben 5(!) Jahre lang keine, aber auch gar keine einzieg Idee irgenwie in ein Produkt überführen können. Nichts. Da wird nichts davon verkauft. 0,000€ verdient, Millionen ausgegeben. Inzwischen dürfen sie glücklicherweise kein Geld mehr ausgeben, oder sonstige Ressourcen nutzen. Irgendwer hat also was gemerkt. Langsam wird man dort sichtlich nervös. Ich fürchte schlimmes, den Cheffe wird die Leute vermutlich in die Entwicklung drücken, und wir müssen die mitziehen. Darum wälze ich schon Stellenazeigen. --> Die Schwätzerseuche ist ein größeres Problem in der Wirtschaft, als der Wandel in der Fahrzeugindustrie je sein könnte... --> Für heutige Chefs zählt oft nur Geschwätz. Leistung ist irrelevant. Traurig.
Jan H. schrieb: > Johannes F. schrieb: >> Habe ich ein Projekt, wo die Anforderungen wirklich >> bekannt sind (z.B. Programmierung der Steuerung einer >> "konventionellen" Waschmaschine), ist was agiles >> einfach dämlich. > > Warum? Wenn du das agile Manifest liest ist die > Änderung von Anforderungen nur ein kleinerer Teil > der Idee. ... aber m.E. der entscheidende. > Wenn die anderen Rahmenbedingungen passen kann Scrum > auch bei Projekten mit vollständig bekannten > Anforderungen sinnvoll sein. Vielleicht möchte sie > Hardwareentwicklung ja eine lauffähige Zwischenversion > haben um das Schleudern oder EMV zu testen. Ich würde zwischen "iterativ" und "agil" unterscheiden. Iteratives Vorgehen ist praktisch immer sinnvoll (siehe Winston W. Royce: "Do it twice"). Dass Agilität bei vollständig bekannten Anforderungen sinnvoll sein soll, erschließt sich mir erstmal nicht.
Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde. Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes Tätigungsfeld suchen. Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt? Bitte zu machen und löschen, danke.
Scrummaster schrieb: > Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird > aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde. > Immerhin hat sich diese agile Arbeitsmethode weltweit mit großen Erfolg > durchgesetzt. Ewig gestrige Schwätzer sollen sich halt ein anderes > Tätigungsfeld suchen. Krieg, Landmienen, Folter und Krankheit haben sich auch weltweit durchgesetzt und sind erfolgreich...
Scrummaster schrieb: > Ich gehe doch mal stark davon aus, dass auch die Forumleitung im Stile > von Scrum organisiert ist. Wurde die Löschung schon im Backlog vermerkt? Siehe oben...Was mir gerade klar wird, der Tenor ist: René H. schrieb: > Das ist kein Klagen, dass ist eine Kritik an der Methode und wie sie > verwendet wird!
Scrummaster schrieb: > Kann mal endlich jemand diesen unredlichen Thread löschen? Hier wird > aktiv Werbung gegen Scrum gemacht, was ich nicht in Ordnung finde. Klingst ein bischen wie Trump, der kann Kritik auch nicht leiden und hält sich für besser als Gott. SCNR Egon D. schrieb: > Ich fühle mich eher an den Marxismus erinnert... oder > nehmen wir besser Cholesterin, das ist (scheinbar!) > nicht so politisch: Dein Beispiel passt ganz gut. SCRUM als Idee ist ja nicht das Problem, im Endeffekt unterscheidet es sich nicht so viel von guten Projekten die ich erlebt habe bevor hier irgendwer SCRUm kannte. Mich nervt nur das starre Konzept das drüber gestülpt wird, was dazu führt dass zumindest ein Teil der Leute Scheuklappen aufsetzt. Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage ich mich wohin das Hirn verschwunden ist. Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck aufzubauen um mehr Leistung aus den Leuten zu quetschen und die Verantwortung bei Problemen von oben nach unten zu schieben.
:
Bearbeitet durch User
vn nn schrieb: > um mit der Zeit die Abschätzungen zu verbessern Während mwn beum Hausbau weiss, wie lange es dauert Stein auf Stein zu stellen, ist eine Fehlersuche eben eine Suche. Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen zu finden. vn nn schrieb: > "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, > deswegen ist Scrum kacke!!1elf" Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit heilen, bete mehr.
Udo S. schrieb: > Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck > aufzubauen um mehr Leistung aus den Leuten zu quetschen Ob mit oder ohne SCRUM: Wenn Dein Kollege den Job sauber in der Hälfte der Zeit schafft, dann sollte Dir das zu denken geben. Aber meist sind es doch nur die Dummschwätzer, denen ihr Code nach einer statt drei Wochen Arbeit beim ersten Start um die Ohren fliegt. Von denen muss man sich nicht drängen lassen.
Wir sind in einem Projekt auch agil unterwegs. In meinem SW-Subteam leben wir das nicht mehr wirklich, da es doppelte Arbeit ist. Detaillierte Planungen und Regelmeetings im Team und mit anderen Parteien werden weiterhin benötigt, um Prozessforderungen (intern und von den Kunden) zu erfüllen. Ich habe in zwei aufeinanderfolgenden Demos (3 Wochen dazwischen) mal den Versuch gemacht, genau die gleichen Ergebnisse zu präsentieren (auf Grund anderer Themen war tatsächlich auch kein Fortschritt da, aber das habe ich verschwiegen). Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal wurde ich sogar noch für den Fortschritt gelobt ^^
Agiler schrieb: > Das wurde von den Product Ownern aber nicht bemerkt - beim zweiten mal > wurde ich sogar noch für den Fortschritt gelobt ^^ Genau dazu habe ich mal eine Frage: SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden vorzulegen, damit der zeitnah eingreifen und lenken kann. Aber wie sieht das in der Realität aus? Sind die Verantwortlichen beim Kunden wirklich so realitätsnah und wissen, was gebraucht wird? Oder sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken für die Besprechungen aufweist. Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch SCRUM real erfolgreicher?
Udo S. schrieb: > Egon D. schrieb: >> Ich fühle mich eher an den Marxismus erinnert... oder >> nehmen wir besser Cholesterin, das ist (scheinbar!) >> nicht so politisch: > > Dein Beispiel passt ganz gut. SCRUM als Idee ist ja nicht > das Problem, im Endeffekt unterscheidet es sich nicht so > viel von guten Projekten die ich erlebt habe bevor hier > irgendwer SCRUm kannte. Ja, klar, aber... > Mich nervt nur das starre Konzept das drüber gestülpt > wird, was dazu führt dass zumindest ein Teil der Leute > Scheuklappen aufsetzt. ...das "starre Konzept" ist ein intrinsisches Problem, das jeder agilen Methodik -- und jeder Projektmethodik überhaupt -- innewohnt: Man versucht, das, was gute Leute intuitiv können und richtig machen, explizit als Regelsatz zu formulieren. Wenn jetzt ein Anfänger diese Regeln liest, ohne den Erfahrungshintergrund dazu zu kennen, kommt natürlich Mist heraus, weil er sich an formalen Details aufhängt und das Prinzip dahinter nicht versteht. Dazu kommt noch, dass die Erfinder der Agilität m.E. die Interessenkonflikte zwischen Management, Projekt- leitung und Indianern ziemlich blauäugig behandeln. > Wenn ich sehe dass ein Team hier 3 Tage munter > weiterentwickelt, obwohl klar ist daß sich eine > wesentliche Anforderung geändert hat, weil man ja > "mitten im Sprint" ist, und da keine Änderungen > erlaubt sind, dann frage ich mich wohin das Hirn > verschwunden ist. Naja, das sehe ich nicht ganz so. Ist ein weites Feld. > Und eben die Tatsache das SCRUm massiv dazu genutzt > wird Druck aufzubauen um mehr Leistung aus den Leuten > zu quetschen und die Verantwortung bei Problemen von > oben nach unten zu schieben. Richtig -- das ist der eigentlich ärgerliche Punkt. Die agile Gilde muss sich den Vorwurf gefallen lassen, dass sie dieses Problemfeld unterschätzt hat.
Udo S. schrieb: > Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl > klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja > "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage > ich mich wohin das Hirn verschwunden ist. Das kann (nicht muss!) durchaus sinnvoll sein. Die Geschäftswelt ist teilweise leider schlimmer als ein Kindergarten. Erlaube einmal eine Änderung während des Sprints, und schon kommen täglich "dringende wesentliche" Änderungen. Kommt natürlich stark auf die Kultur an.
Egon D. schrieb: > René H. schrieb: > >> Neue Requirements bedeuten in jedem Modell dass selbe. >> Änderungen. Das kann Agile nicht besser und nicht >> schlechter auffangen als andere Modelle. > > Vielleicht solltest Du mal mit Deiner alten Tradition > brechen und DOCH mal einen Blick in ein Buch werfen. > Das "Agile Manifest" würde sich eignen. Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum Master. Ich bin gegenüber Neuem immer erst mal offen und Neutral. Bilde mich auch weiter. Und wie bereits geschrieben, ich finde Scrum nicht grundsätzlich schlecht. Richtig eingesetzt. Wie jedes andere Werkzeug auch. Also, Egon, belehr mich nicht!
Beitrag #6143463 wurde von einem Moderator gelöscht.
Beitrag #6143466 wurde von einem Moderator gelöscht.
René H. schrieb: > Egon D. schrieb: >> René H. schrieb: >> >>> Neue Requirements bedeuten in jedem Modell dass selbe. >>> Änderungen. Das kann Agile nicht besser und nicht >>> schlechter auffangen als andere Modelle. >> >> Vielleicht solltest Du mal mit Deiner alten Tradition >> brechen und DOCH mal einen Blick in ein Buch werfen. >> Das "Agile Manifest" würde sich eignen. > > Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter > Scrum Master. In der Tat: Das glaube ich wirklich nicht! :) Der praktische Unterschied zwischen einem einfach nur iterativen Vorgehen und einer agilen Vorgehensweise ist ja GERADE der, dass die schrittweise Annäherung AUCH die Anforderungen einschließt und also den Kunden einbezieht. Die agile Methodenwelt ist ja eine Reaktion auf die Erfahrungstatsache, dass späte Änderungen eben NICHT vollständig vermeidbar sind -- also versucht man, den Spieß umzudrehen: Wenn Änderungen ohnehin nicht vermeidbar sind, dann richten wir all unsere Arbeitsabläufe darauf aus, dass wenigstens die Kosten für diese Änderung möglichst niedrig bleiben. Dass das als Einladung zum Missbrauch aufgefasst werden kann, hatten die Vordenker der Agilität wohl nicht aus- reichend auf dem Schirm...
Egon D. schrieb: > Dass das als Einladung zum Missbrauch aufgefasst werden > kann, hatten die Vordenker der Agilität wohl nicht aus- > reichend auf dem Schirm... Vor allem auch nicht, dass ganze Horden von Beratungs und Schulungsunternehmen alle Entscheider/Geschäftsleitung mit den tollsten Versprechungen zumüllen um Umsatz zu machen. Sind diese Horden dann (teilweise) wieder gegangen wird doppelte Produktivität erwartet, was bei vorher funktionierenden Prozessen die nicht SCRUM waren natürlich Schwachsinn ist. Durch die komplette Umkrempelung wird es dann erst mal zu weniger Produktivität kommen.
Udo S. schrieb: > Mich nervt nur das starre Konzept das drüber gestülpt wird, was dazu > führt dass zumindest ein Teil der Leute Scheuklappen aufsetzt. > Wenn ich sehe dass ein Team hier 3 Tage munter weiterentwickelt, obwohl > klar ist daß sich eine wesentliche Anforderung geändert hat, weil man ja > "mitten im Sprint" ist, und da keine Änderungen erlaubt sind, dann frage > ich mich wohin das Hirn verschwunden ist. Die Frage ist völlig berechtigt. Hirnmangel oder Lesemangel. Man kann einen Sprint auch mittendrin einfach abbrechen. Formal können das zwei Spieler: 1) Der PO bricht den Sprint ab weil das Ziel des Sprint obsolet ist. 2) Der Scrummaster bricht im Namen des Teams den Sprint ab weil das Team von irgendwas die Schnauze voll hat. Die dritte Variante ist nicht offiziell: 3) Das Team bricht den Sprint unter Umgehung des Scrummasters ab weil es von irgendwas und dem Scrummaster die Schnauze voll hat. Natürlich wird das alles in der Praxis nicht gemacht. 1) bedeutet der PO muss verstehen was seine Rolle ist und Verantwortung übernehmen, nicht zuletzt für die Zusatzkosten und die verschwendete Arbeit die der Abbruch und die radikale Änderung der Anforderung mit sich bringt. Statt dessen mogelt sich der PO lieber durch um beim Chef nicht blöd dazustehen. 2) und 3) entspricht einem kleinen Streik, einer Arbeitsverweigerung. Dann bricht das ganze Kartenhaus um das Scrumteam zusammen, von wegen selbstorganisierend und alle Freiheiten. Dann werden Leute auf höheren Hierarchieebenen richtig böse. Wer zahlt bestimmt die Musik und das ist letzten Endes nicht das Scrumteam. So bricht Scrum dann mal wieder in der harten Realität des Arbeitslebens zusammen. Nebenbei bemerkt, der hier herum turnende zertifizierte(!) Scrummaster hätte Antwort 1) und 2) sofort geben müssen. Das sollte er auf der Schule für kleine Scrummaster gelernt haben.
Ach ja, Agile und Scrum. Das Interessante ist, das bei meinem ehemaligen AG (Ausland, 20 hochqualifizierte Tech-"Bros", 2 Produktmanager, die selber Vollblutingenieure waren) völlig ohne Kotzen und relativ effizient funktioniert. Wenig Verwaltungsoverhead, konzentriertes Arbeiten. "Agile Light" funktioniert ganz gut. Nun habe ich hier im Team (1 Dutzend) einen Agile-"Coach" und einen nicht-technischen PM sowie PO. 120% Scrum. Alle 2 Wochen: 4x2h Scrum-"Zeremonien" und 1x1h Inter-Team-"Review", dazu jede andere Woche 2x2h "Refinement" und 5x0.5h "Daily" sowieso. Da wird dann sinnlos an Tickets rumgeschnitzt nach dem Motto "1 Arbeitspaket von 12h lässt sich in 3 Arbeitspakete zu 4h unterteilen, die von verschiedenen Leuten bearbeitet werden, lasst uns das jetzt kleinlabern und dann von Leuten, die keine Ahnung haben und nicht am Thema interessiert sind, schätzen lassen". Bis heute haben die nicht verstanden, dass ein wertschöpfender Entwicklungstask von 6h bei Unterteilung in 2x3h mindestens 8h dauert und dass somit prinzipiell mit Schnipseltickets alles länger dauert als die Summe der "Storypunkte" vermuten ließe. Und dann wundern sie sich, wenn die Monate ins Land gehen.
Egon D. schrieb: >> Und eben die Tatsache das SCRUm massiv dazu genutzt >> wird Druck aufzubauen um mehr Leistung aus den Leuten >> zu quetschen und die Verantwortung bei Problemen von >> oben nach unten zu schieben. > > Richtig -- das ist der eigentlich ärgerliche Punkt. Die > agile Gilde muss sich den Vorwurf gefallen lassen, dass > sie dieses Problemfeld unterschätzt hat. Läuft doch alles nach Plan. Agile wurde zuerst dem Management verkauft und dann unter die Leute gebracht.
Framulestigo schrieb: > SCRUM ist ja mit der Zielsetzung angetreten, möglichst früh Ergebnisse > beim Kunden abzuliefern. Sprints sind ja auch nicht dazu da, schneller > zu arbeiten, sondern kleinere Ergebnisse möglichst früh dem Kunden > vorzulegen, damit der zeitnah eingreifen und lenken kann. > > Aber wie sieht das in der Realität aus? Meiner Erfahrung nach sehr sehr mau. Es mag in anderen Firmen, in anderen Branchen Kunden geben die das Spiel mitmachen. Der Kunde will sich doch gar nicht ständig mit der Softwareentwicklung befassen. Wollte er das würde er die Software selber entwickeln, nicht kaufen. Wer soll denn jede Woche vom Kunden aus die letzten Entwicklungen begutachten (Demo)? Ein teurer Manager? Der hat doch keine Ahnung. Der weniger teure Spezialist, der dann jede Woche einen Tag ausfällt? Der Praktikant, der billig ist aber nicht weiß was benötigt wird? > Sind die Verantwortlichen beim > Kunden wirklich so realitätsnah und wissen, was gebraucht wird? Wer weiß was gebraucht wird hat häufig nicht die Verantwortung. Entscheidungen behält sich das Management vor, besonders solche, die Geld kosten. > Oder > sind das auch nur Frackträger, deren Terminplan noch die nötigen Lücken > für die Besprechungen aufweist. Nein, weil der Kunde nicht gar nicht erst kommt. Egal ob Manager, Spezialist oder Praktikant. > Kurz: Wird der Kunde beim Einfangen seiner eigenen Anforderungen durch > SCRUM real erfolgreicher? Wenn er mitspielen würde vielleicht. Was funktioniert ist eine Art gemeinsame Entwicklung. Das ist ein altes Konzept noch aus XP-Zeiten, der On-Site Customer. Scrum hat sowieso die Hälfte von XP (schlecht) kopiert. Der Kunde stellt für die Entwicklung einen Mitarbeiter (Spezialisten) ab, der Teil des Entwickler-Teams wird. Es muss aber wirklich ein Spezialist sein, nicht der Praktikant. Wenn das Interesse der beteiligten Firmen groß genug ist, z.B. ein gemeinsames Produkt zu dem die Software gehört, dann funktioniert das. Ansonsten scheitert auch das.
Bei vielen Projekten ist der Kunde die Fachabteilung oder das eigene Management.
Beitrag #6144028 wurde von einem Moderator gelöscht.
Beitrag #6144039 wurde von einem Moderator gelöscht.
Egon D. schrieb: > In der Tat: Das glaube ich wirklich nicht! :) > Der praktische Unterschied zwischen einem einfach nur iterativen > Vorgehen und einer agilen Vorgehensweise ist ja GERADE der, dass die > schrittweise Annäherung AUCH die Anforderungen einschließt und also den > Kunden einbezieht. Ja, alles korrekt. In einer schöner theoretischen Welt. Die Welt ist aber nicht so. Scrum ist eine gute Sache wenn ein neues Projekt/Produkt entwickelt wird in einem Team. Es ist aber untauglich für Maintenance. Da braucht es kein agil. Scrum wird missbraucht! Und das ist der Punkt.
Michael Gugelhupf schrieb: > Nebenbei bemerkt, der hier herum turnende zertifizierte(!) Scrummaster > hätte Antwort 1) und 2) sofort geben müssen. Das sollte er auf der > Schule für kleine Scrummaster gelernt haben. Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum Master! Ich bin und bleibe Entwickler.
Beitrag #6144051 wurde von einem Moderator gelöscht.
Beitrag #6144057 wurde von einem Moderator gelöscht.
Beitrag #6144096 wurde von einem Moderator gelöscht.
Beitrag #6144113 wurde von einem Moderator gelöscht.
Beitrag #6144114 wurde von einem Moderator gelöscht.
Beitrag #6144117 wurde von einem Moderator gelöscht.
Beitrag #6144122 wurde von einem Moderator gelöscht.
Bin vom Entwickler zum Product Owner "aufgestiegen" und grundsätzlich funktioniert es ganz gut bei uns. In den Sprints arbeiten die Entwickler eigenständig ihre Tasks ab. Daily Standups gibt und gab es bei uns sowieso schon immer, da wir eine aktive "Kaffeekultur" haben... Grundsätzlich bin ich als PO für die technische Entwicklung voll verantwortlich. Ich behalte den Überblick, kenne die Architektur und bereite das Backlog vor. Die Kommunikation mit dem Kunden und Anforderungen übernimmt zu 2/3 der Produkt Manager, der mich dann bei Bedarf mitnimmt. Es gibt bei uns alleridngs aus Prozessgründen auch Projektmanager, die kümmern sich allerdings nicht um technische Details der Entwicklung, sondern um die Planung der Auslieferungen, Inbetriebnahmen, Vertragsdetails... von denen kommt dann als Rückmeldung zum PM und PO, dass Kunde X eine Anlage zum Zeitpunkt Y bekommt und diese Features (bzw. diese Version) von der Software dort eingesetzt werden soll. Ich denke es gibt ein paar "Fallen", in die traditionelle Projektmanager, die Mikromanagement bis ins kleinste Detail perfektioniert haben, treten und damit dann Scrum aktiv zerstören (ist dann aber Quatsch, dass Scrum dann nicht robust genug ist -> jeder Prozess kann aktiv zerstört und umgangen werden) - Das Team muss selbstorganisiert sein: Ich als PO "assigne" nicht direkt Tasks bzw. nur in Ausnahmefällen (dringender Bug). In den Planning Meetings kommt vom Team die Rückmeldung, wer was macht, wenn ich das Backlog für den Sprint zeige. Bei uns hat sich das sowieso schon eingespielt, da die Entwickler natürlich Spezialisierungen haben und der eine oder andere immer Tasks in diese Richtung macht. - Überplanung der Backlog-Items: Ich schreibe in die Backlog-Items, was ich am Ende "in der Hand haben will". Den Lösungsweg muss der Entwickler bringen. Im klassischen PM kommt der Lösungsweg oft "von oben" und der Entwickler muss es dann auf die Spezifikation genau umsetzen. Das geht gegen den Gedanken von Scrum. - Nach jedem Sprint muss die Software/Hardware ein Stück weiter sein: Das Backlog für einen Sprint muss so aufbereitet sein, dass nach dem Sprint die Software "ein wenig mehr" an Funktionalität hat, als davor. Das ist die Aufgabe vom PO, das sicher zu stellen. Wenn diese drei Merkmale nicht erfüllt sind, dann kann man wohl wirklich von "bullshit-bingo" sprechen...
René H. schrieb: > Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum > Master. René H. schrieb: > Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum > Master! Ich bin und bleibe Entwickler. Ohne böse Worte - jetzt besser? :-)
Hugo H. schrieb: > René H. schrieb: >> Ha! Du wirst es nicht glauben, ich bin sogar zertifizierter Scrum >> Master. > > René H. schrieb: >> Halt, stopp!! Ich machte die Zertifizierung. Ich bin kein aktiver Scrum >> Master! Ich bin und bleibe Entwickler. > > Ohne böse Worte - jetzt besser? :-) Böse Worte sind mir grundsätzlich Wurscht wenn sie berechtigt sind. In diesem Fall waren sie es nicht. Allgemeine Entspannung?
BTW: ich poste hier mit meinem Rufzeichen. Mein AG liest hier übrigens auch mit. Lügen ist da nicht.
PO schrieb: > Grundsätzlich bin ich als PO für die technische Entwicklung voll > verantwortlich. Ich behalte den Überblick, kenne die Architektur und > bereite das Backlog vor. Wenn das gegeben ist, und Du als PO das wie den Entwicklern überlassen kannst, dann ist das schon ideal. Da würde auch andere Verfahren laufen. Schlimm ist, wenn der PO nur Manager ist ohne fachlichen Durchblick ("ihr seid die Fachleute"). Leider ist das oft so, dass PO und Co der Karriereweg für jene ist, die in der Entwicklung scheitern.
Beitrag #6144565 wurde vom Autor gelöscht.
Beitrag #6144573 wurde vom Autor gelöscht.
PO schrieb: > Ich denke es gibt ein paar "Fallen", in die traditionelle > Projektmanager, die Mikromanagement bis ins kleinste Detail > perfektioniert haben, treten und damit dann Scrum aktiv zerstören Sorry, aber mein Eindruck hier bei uns ist, dass bei den SCRUM Teams viel mehr "Mikromanagement" betrieben wird, weil jede Aufgabe zwanghaft versucht wird in maximal kleine Teilaufgaben zu zersplittern. Wenn eure Projektmanager "Mikromanagement" betrieben haben, dann sollten sie sich eine andere Aufgabe suchen. Ich bin hier völlig frei meine Aufgaben so zu erledigen wie ich (und die anderen Projektmitarbeiter) es für richtig halten, das Projektmanagement gibt nur die Rahmen und das grobe Lastenheft vor und erhält vom Entwicklungsteam zusammen mit dem Produktverantwortlichen eine Zeitabschätzung möglichst incl. Risikobewertung. Klar knirscht es da auch mal, oder der Kunde kippt spät Änderungen rein und sieht nicht ein dass es dann länger dauert, aber genau dann ist der Projektmanager gefordert. Und das funktioniert völlig ohne starres SCRUM Korsett.
Udo S. schrieb: > Wenn eure Projektmanager "Mikromanagement" betrieben haben, > dann sollten sie sich eine andere Aufgabe suchen. Genau. Und wer nicht mit einer vollständigen Kenntnis des C-Standards geboren wird, soll Bäcker werden -- und nicht Programmierer. Schulen, Universitäten, Ausbildung wird sowieso überschätzt. Kein Mensch mus je irgendwas lernen -- entweder er kann es, oder es hat sowieso keinen Sinn. > [...] > Und das funktioniert völlig ohne starres SCRUM Korsett. Das bedeutet nur, dass Eure Führungskräfte gut und fähig sind -- und nicht, dass SCRUM generell schlecht ist. Alle Vorgehensmodelle und Methodiken sind sowieso nur ein Versuch, die Dinge explizit zu formulieren und lehrbar zu machen, die gute Leute intuitiv richtig machen. Das ist im Ansatz erstmal nicht falsch.
Beitrag #6144708 wurde von einem Moderator gelöscht.
Beitrag #6144753 wurde von einem Moderator gelöscht.
Beitrag #6144884 wurde von einem Moderator gelöscht.
Beitrag #6144896 wurde von einem Moderator gelöscht.
Beitrag #6144910 wurde von einem Moderator gelöscht.
Scrum funktioniert eben nicht überall und zwanghaft alles in das Framework reinzupressen macht einfach keinen Sinn. Leider wird Scrum häufig zum Mikromanagement missbraucht und dient häufig dazu, dass man eine Art Fabrikarbeit etabliert, die Entwickler zu Implementierern degradiert. Besonders bei großen Konzernen ist das oft der Fall, weil man dort alles möglichst in kleine übertragbare Aufgaben verpacken will. Wenn man aber vernünftig "agile" arbeitet, funktioniert es auch recht gut. Nur meistens nicht so wirklich mit Scrum. Man braucht aber auch die richtigen Leute dafür. Der lernresistene 9to5 Arbeiter ist denkbar ungeeignet für richtiges "Agile". Jemand, der gegen alles neue kämpft und destruktiv ist kann eben nichts sinnvolles beitragen. Die Idee dahinter ist ja eigentlich, dass man Hierachien abbaut und nicht alles vorkaut. Scrum ist so ein Mittelding, irgendwie braucht man die ganzen Wasserköpfe noch (oder sogar mehr) und irgendwie kann man damit werben agil zu arbeiten. Wasserköpfe behalten ihre unnötigen Jobs und Entwickler bekommen das Gefühl agil zu sein, nur bringen tut es effektiv halt nix.
Beitrag #6144941 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Alle Vorgehensmodelle und Methodiken sind sowieso nur ein > Versuch, die Dinge explizit zu formulieren und lehrbar zu > machen, die gute Leute intuitiv richtig machen. Sehe ich ganz genauso !!! ;)
Bei uns testet der Kunde tätsächlich die einzelnen Releases .. d.h. nicht der Kunde selbst - die haben oft keine Ahnung von der Materie. Das machen Subauftragnehmer wie üblich heute - Entwicklungsdienstleister. Abartig in welche Richtung das heute läuft ... Aber die Dienstleister testen dann Releases die Wochen zurückliegen, da sie wohl mit der Arbeit ned hinterher kommen oder was immer. Die Folge : Wir müssen dann Schwächen in Releases suchen, die schon längst überarbeitet wurden und folglich verlieren wir eine Menge Zeit, um alte Hardware- und Softwarestände wieder einzurichten und dann dort Fehler zu suchen und zu korrigieren ... obwohl mit denen gar nicht mehr gearbeitet wird, da sie nur ein Zwischenstand waren. Die neue Hard-/Software arbeitet möglicherweise schon anders, so dass die Probleme dort gar nicht auftreten würden. Wir haben früher ebenfalls abschnittsweise entwickelt und die entsprechenden Abschnitte getestet. Ich denke mal es erklärt sich von selbst, dass ein engagierter Entwickler seinen Kram selbst auf Herz und Nieren testet und so viel Ehre hat ein 'sauberes' Produkt abzuliefern.
Und früher ohne Prozesse haben wir Kundenwünsche in wenigen Stunden umgesetzt getestet und 2 Tage später hatte der Kunde das auf dem Steuergerät zum Testen und war sehr zufrieden. Heute bei all den modernen Prozessen mit viel mehr Leuten, aber Scrum, Controll-Board und all dem Blödsinn dauert es Wochen bis wir überhaupt Anstalten machen Fehler oder Änderungen zu bearbeiten, der Kunde ist ärgerlich und wir unmotiviert ... :D
MaWin schrieb: > vn nn schrieb: >> um mit der Zeit die Abschätzungen zu verbessern > > Während mwn beum Hausbau weiss, wie lange es dauert Stein auf Stein zu > stellen, ist eine Fehlersuche eben eine Suche. > Gib mir deine Abschätzung wie lange du brauchst, die Nadel im Heuhaufen > zu finden. Nein? Doch! Oh! Genau deswegen wird einem normalerweise keiner den Kopf abreißen, wenn man als Softwareentwickler mal seine Zeiteinschätzung nachträglich korrigieren muss. Egal ob mit Scrum, oder ohne. Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine Bastelbude? MaWin schrieb: > vn nn schrieb: >> "Meine Firma behauptet Scrum zu machen obwohl sie das gar nicht tut, >> deswegen ist Scrum kacke!!1elf" > > Ewiges wiederholen macht den Satz nicht richtiger. Wenn du nur richtig > tief religiös bist, wird Gott dich von Krwbs, Vorona und Dummheit > heilen, bete mehr. Dein Posting macht leider absolut keinen Sinn. Überraschung, wer hätte das gedacht...
Udo S. schrieb: > Und eben die Tatsache das SCRUm massiv dazu genutzt wird Druck > aufzubauen um mehr Leistung aus den Leuten zu quetschen und die > Verantwortung bei Problemen von oben nach unten zu schieben. Ob dein Chef ein Arsch ist oder nicht, wird sich wohl durch die Verwendung von Scrum (oder sonst irgendeinem Prozess) nicht ändern. Entweder er ist einer, dann wird er immer einen Weg finden, Druck aufzubauen, oder er ist eben keiner.
vn nn schrieb: > Egal ob mit Scrum, oder ohne. > Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang > du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine > Bastelbude? Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft gemacht wurden) und Dinge, die nicht abschätzbar sind, z.B. manchmal Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen Projektes wenn man den sporadischen Absturz nicht findet oder patchen kann.
Beitrag #6145887 wurde von einem Moderator gelöscht.
A. S. schrieb: > vn nn schrieb: >> Egal ob mit Scrum, oder ohne. >> Oder willst du damit sagen, dass dein Chef nicht wissen will, wie lang >> du voraussichtlich für XYZ brauchen wirst? Was seid ihr denn für eine >> Bastelbude? > > Jedes Projekt hat Dinge, die abschätzbar sind (weil sie schon oft > gemacht wurden) und Dinge, die nicht abschätzbar sind, z.B. manchmal > Fehlersuche. Da kann man dann gerne verschiedene Wege skizzieren und > denen verschiedene Zeiten (Aufwände, Prioritäten, Leute) zuordnen, aber > es dauert halt so lange, wie es dauert. Bis hin zur Aufgabe des ganzen > Projektes wenn man den sporadischen Absturz nicht findet oder patchen > kann. Genau das ist es, was ich die ganze Zeit sage. Und in jedem Projekt ist es üblich, seinen Vorgesetzten über sowas im Bilde zu halten. Außer a) Bastelbude, er will es gar nicht wissen b) keine Eier dem Chef zu sagen dass man hinter dem Zeitplan ist. c) cholerischer Vorgesetzter wirfst jeden beim geringsten Fehlschlag raus. In allen drei Fällen hilft nur ein Jobwechsel, bei a) und c) zu einer Firma wo nicht gebastelt wird und es eine ordentliche Fehlerkultur gibt, bei b) in eine Branche wo man keine Eier braucht.
BTW, wenn es "sporadische, unauffindbare Abstürze" gibt, die ein ganzes Projekt zum scheitern bringen, läuft auch was falsch...
Nachdem die meisten hier scheinbar was gegen Scrum & Co haben, mal die konstruktive Gegenfrage: Welche Softwareentwicklungsmodelle funktionieren den besser bei Projekten wo die Anforderungen sich im Laufe des Projektes ändern können (innovativ, lang laufend usw.)? Und das meine ich für "ernsthafte" Projekte, also wo nicht mehr "rede halt mit meinen Kollegen im gleichen Zimmer" ausreicht.
DrFounder schrieb: > Kanban Laut der allwissenden Müllhalde: "Kanban weist viele Gemeinsamkeiten mit dem agilen Managementframework Scrum auf, steht jedoch in keinem zwingenden Verhältnis zu diesem. Weder muss man zuerst Scrum einsetzen, bevor man Kanban einführt, noch schließen sich beide Ansätze komplett aus. In gewisser Weise lässt sich Scrum als eine mögliche Implementierung von Kanban ansehen. Der Hauptunterschied zwischen beiden Ansätzen besteht darin, dass Scrum ein team-zentrierter Ansatz ist und Kanban primär die Wertgenerierung entlang der Wertschöpfungskette optimiert. " Kannst du mir erläutern, wie das die bei der Ähnlichkeit die ganzen angesprochenen Kritikpunkte adressiert werden?
Johannes F. schrieb: > Kannst du mir erläutern, wie das die bei der Ähnlichkeit die ganzen > angesprochenen Kritikpunkte adressiert werden? Kanban finde ich besser, weil weniger Meetings als mit Scrum. Den oben zitierten Satz von Dir verstehe ich nicht. Zu komplizierten Syntax :-).
Matthias Döpke schrieb: > Egon D. schrieb: >> Alle Vorgehensmodelle und Methodiken sind sowieso nur ein >> Versuch, die Dinge explizit zu formulieren und lehrbar zu >> machen, die gute Leute intuitiv richtig machen. > > Sehe ich ganz genauso !!! ;) +1!
Beitrag #6146485 wurde von einem Moderator gelöscht.
Die neueste Quintessenz: Die Tools funktionieren gar nicht richtig. Man packt seine Dokumentationen und Workflow in Tools, die ihre Daten in Clouds parken. Werden die morgen abgeschaltet, dann wars das. Dann auch außerhalb Meetings endlose Kommentare und Diskussionen, wie man was auf dem Backlog anlegt, ob das noch in den Sprint passt, dass "du dafür ja nur noch x Tage Zeit hast". Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in - zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc. kümmert. Bei einer 8 mann Bude. Weil da keiner für diese belanglosen Dinge Zeit hat oder es nicht tun darf? Pervers. Ich schreibe jetzt Bewerbungen...
Unglaublich schrieb: > Zusätzlich muss jetzt ein Devop eingestellt werden, der sich in - > zugegebenermaßen in Teilzeit - um das Netzwerk, um E-mail Accounts etc. > kümmert. DAS ist kein Devop, das ist ein Sysadmin. Devops ist, wenn das gleiche Team Aministration und Entwicklung macht (um die Zielkonflikte zwischen Betrieb und Entwicklung zu reduzieren). Das mit den Bewerbungen klingt allerdings gut, so viel "Bullshit-Bingo" und wenig "echtes Umsetzen" da anklingt.
Beitrag #6152523 wurde von einem Moderator gelöscht.
Die Managementmethode Scrum wird heute mit agiler Unternehmensführung gleichgesetzt, also einer Art Ideologie des richtigen Führens, in der Menschen freier, selbstbestimmter und zufriedener sind. Wenn man aber nach der hintergründigen Wahrheit sucht, dann stößt man schnell darauf, was dieses Scrum wirklich ist: eine Managementmethode zur Effizienzsteigerung in bester tayloristischer Tradition. Dort wird keine Transformation geboren, sondern kleine Projektchen werden effizient abgewickelt. Alles andere ist ein attraktiver Anstrich.
Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der Projektentwicklung reine Lotterie war, ob man denn als Kunde das bekommt, was man meint, bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen Fehler finden.
Framulestigo schrieb: > Da es in der Zeit vor SCRUM mit 40% Fehlquote bei der > Projektentwicklung > reine Lotterie war, ob man denn als Kunde das bekommt, was man meint, > bestellt zu haben, kann ich in dem Gedanken "Effizienzsteigerung" keinen > Fehler finden. Das wird heute dadurch kompensiert, dass SCRUM Projekte 10mal so lange dauern wie damals und im Endeffekt das vielfache von vergeigten Entwicklungen, die man ggf. mal neu startet, kosten.
In Zeiten von Corona werden jetzt die fehlenden Teammitglieder, die im Homeoffice zu Hause hocken, per Videoschalte in die täglichen Meetings zugeschaltet. Unfassbar..
Unfassbar schrieb: > In Zeiten von Corona werden jetzt die fehlenden Teammitglieder, die im > Homeoffice zu Hause hocken, per Videoschalte in die täglichen Meetings > zugeschaltet. Unfassbar.. Na und? Gut so, mein Team ist zu 100% remote und meine Produktivität ist erheblich gestiegen, da ich entscheide, ob mich jemand stört. Nur unser SCRUM-Master hat Probleme. Langeweile!
Beitrag #6214531 wurde von einem Moderator gelöscht.
Was bei uns so auffällt... Wo man früher im Wasserfall Servicetöpfe hatte bei uns hatte und kleine Dinge immer Mal "einfach so" mitgemacht hat, also meist technische Sachen, kommt heute immer nur "müssen wir dann Mal mit ins Sprint planning mitnehmen". Da hat der fachlich zentrierte Productowner natürlich kein Bock auf technische Themen.. also geht das drumherum so langsam aber sicher den Berg herunter. Und man lähmt sich wo es nur geht. Man versteckt sich förmlich hinter scrum...
Rainer Zufall schrieb: > Da hat der fachlich zentrierte Productowner natürlich kein Bock auf > technische Themen.. Dann müsst ihr es ihm beibringen, dass sich das sonst langfristig rächt. Dann werden solche Themen auch höher priorisiert.
Jo... sollte man meinen.... aber die Leute blicken es halt nicht. Ist halt wie so eine Aktiengesellschaft. Hauptsache schnelle Rendite - mit den langfristigen Problemen können sich dann die nächsten rumschlagen... Es gibt sogar ein festgelegtes Budget von 20% je Sprint was in Technik investiert werden muss. Wird halt nur permanent übersteuert, oder es wird irgendein Crap als "das ist doch wohl Technik!" definiert.... man schiesst sich halt gerne selber ins Knie.... mir egal. Ich nehme es zum Glück nur von außen wahr.
Echte Projektmanager managen unabhängig davon was gerade hipp ist, jedes Projekt als <Fortran-Äquivalent in Projektmanagement>.
:
Bearbeitet durch User
Rainer Zufall schrieb: > festgelegtes Budget von 20% je Sprint was in Technik investiert werden muss ? Beispiel?
A. S. schrieb: > ? > Beispiel - Update Framework Version - Optimierungen grundsätzlicher Natur - einführen neuer Dinge wie zentralisiertes Logging, verbessern Monitoring - erneuern von Dingen wie Authentifizierungsverfahren, Laufzeitmonitoring - Upgrade von Betriebsmodell Application Server auf virtueller Maschine vs. Betrieb im Cluster Usw. Usw. Halt so Dinge neben fachlichen usecases die für den Kunden keine direkte Sichtbarkeit haben....
PO schrieb: > - Nach jedem Sprint muss die Software/Hardware ein Stück weiter sein: > Das Backlog für einen Sprint muss so aufbereitet sein, dass nach dem > Sprint die Software "ein wenig mehr" an Funktionalität hat, als davor. > Das ist die Aufgabe vom PO, das sicher zu stellen. "ein wenig mehr, als zuvor"? Das kann es wohl kaum sein. Mit der Mentalität kämst du in der Medizintechnik nicht weit. Erforderlich sind klare Vorgaben, was zu einem bestimmten Zeitpunkt fertig sein soll, denn nur so kannst du abschätzen ob du im Zeitplan bist. Hört sich sehr nach Wursteln an ...
Vor allem muss ich mir immer den Scheiss der anderen Mitglieder ahören, der mich überhaupt nicht interessiert und ich auch gar nichts mit anfangen kann und der für meine Arbeit auch vollkommen unwichtig ist. Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander tauschen können, da muss der Raketentechniker auch schon mal eine Uhr zusammenbauen ????
Robert K. schrieb: > Erforderlich sind klare Vorgaben, was zu einem bestimmten Zeitpunkt > fertig sein soll, denn nur so kannst du abschätzen ob du im Zeitplan > bist. Was willst du denn machen, wenn der Kunde selber nicht weiß, was er will, braucht und bezahlen kann? Ich meine: Wer leidet denn nicht darunter wenn alle drei Wochen der Vertriebler dazwischenquäkt, daß das ab jetzt alles anders gemacht werden muß weil er dem Kunden das so versprochen hat?
Unglaublich schrieb: > Vor allem muss ich mir immer den Scheiss der anderen Mitglieder > ahören, der mich überhaupt nicht interessiert und ich auch gar nichts > mit anfangen kann und der für meine Arbeit auch vollkommen unwichtig > ist. Aber man soll ja bei Scrum die Mitarbeiter lustig untereinander > tauschen können, da muss der Raketentechniker auch schon mal eine Uhr > zusammenbauen ???? Das hängt von der Homogenität des Teams ab, ob das funktioniert. Der Gedanke bei Scrum geht wohl tatsächlich in die Richtung, dass jeder im Team alles kann, und die Leute im Team ohne Probleme beliebig untereinander austauschbar sind. Ich würde aber auch behaupten, dass das in der Praxis wohl häufig so nicht funktionieren kann. Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben müsst, da von oben vorgegeben).
Qwertz schrieb: > Ich würde aber auch behaupten, dass das > in der Praxis wohl häufig so nicht funktionieren kann. Was durchaus funktioniert, ist, daß jemand, der NICHT im Designprozess drinsteckt, wertvolle Denkanstöße liefern kann. Ich jedenfalls finde prinzipiell nichts Schlechtes daran, anderen meine Designentscheidungen zu erklären oder "Warum hast du das so gemacht"-Fragen zu beantworten. Und manchmal sieht jemand anderes ja doch etwas, an das man selber noch gar nicht gedacht hat. Und andersrum finde ich die Probleme anderer oft deutlich einfacher (und interessanter) als die meine eigenen. Übrigens ein wichtiger Grund für mich, mich in Foren herumzutreiben. Übrigens völlig unabhängig davon, ob man nach Scrum arbeitet oder nicht. Ich habe diese Arbeitsweise immer noch nicht kennengelernt und keine Ahnung wie das wirklich zugeht. Qwertz schrieb: > Wenn es für dich vollkommen unwichtig ist, was die anderen Kollegen so > täglich machen, ist das ein deutliches Zeichen dafür, dass ihr einen > falschen, nicht für Eure Bedürfnisse passenden Prozess lebt (bzw. leben > müsst, da von oben vorgegeben). Oder das jemand einfach nicht in ein Team mit zwei oder mehr Mann reinpasst. ;)
Wühlhase schrieb: > Was durchaus funktioniert, ist, daß jemand, der NICHT im Designprozess > drinsteckt, wertvolle Denkanstöße liefern kann. > Ich jedenfalls finde prinzipiell nichts Schlechtes daran, anderen meine > Designentscheidungen zu erklären oder "Warum hast du das so > gemacht"-Fragen zu beantworten. Das erfordert aber, dass der Tippgeber etwas davon versteht. Aber wie soll ein Elektroniker in der grossen Runde ein Programm hinterfragen? Das könnten die Softwareker doch nicht einmal untereinander: Wenn ich sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten. Das ist vollkommen oberflächlich. Ich kenne die Runden aus Erfahrung und sehe, was bei rumkommt. Viel oberflächlich schnell dahin gesagtes.
M. W. schrieb: > Wenn ich > sehe, wie wenig die Softwareentwicklung an Konzepten macht, sind die gar > nicht in der Lage ad hoc in einem meeting irgend etwas zu beantworten "Eng ist die Welt, und das Gehirn ist weit. Leicht beieinander wohnen die Gedanken, doch hart im Raume stoßen sich die Sachen" [Schiller] das mit den Konzepten wird regelmäßig überbewertet: Klar, wenn ich eine abgeschlossene Funktionalität habe (die Funktion sin() z.B.), dann mache ich in 10% der Zeit die Beschreibung der Schnittstelle inklusive Tests und Doku, und lasse den Programmierer dann machen. Das gleiche gilt für viele Web-Anwendungen, HALs oder Treiber. Deshalb setzt man dort zum Codieren auch Programmierer ein. Wenn ich jedoch wirklich etwas neues schaffe, für ein neues Produkt neue Features, dann sind Konzepte maximal ein Plan nach Sunzi: "Der Beste Plan versagt beim ersten Feindkontakt". Oder modern: Vergiss den Plan, Planung ist alles. Ein echtes SW-Projekt, wo nicht nur Programmierer dransitzen, ist wie das Einräumen eines Geschirrspülers oder das Einrichten eines Lagers: Ja, man stellt sich das so oder so vor, und am Anfang macht man auch wie geplant, doch dann kommen halt Teile in der falschen Größe oder im falschen Verhältnis und das hätte man ja alles kommen sehen müssen. Nein hätte man nicht. Am Ende räumt man immer mehr wieder um, gruppiert was heute sinnvoll ist und wirft einige der besten Ideen über Board, weil sie sich nicht bewähren. Und spätestens beim dritten Projekt geht das umso besser, je weniger man schon in Beton gegossen hat. Wände, die man schon "für die Ewigkeit gebaut und getestet" eingebaut hat, reißt man ungern ein und behilft sich lieber mit dubiosen Workarounds. Das, und genau das ist der Grund für agile Programmierung, egal ob 2 erfahrene Entwickler in XP mit Verachtung als Prutscher durch Kollegen und Chefs, als Scrum oder als ungeliebter Chef, der "immer wieder mit Änderungen" kommt.
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.