1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Agile…

SCRUM ist Verarsche

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema


  1. SCRUM ist Verarsche

    Autor: /mecki78 23.05.22 - 13:49

    Hört bitte endlich auf SCRUM mit agiler Entwicklung gleichzusetzen. SCRUM ist der Versuch agile Entwicklung in ein Korsett der klassischen Entwicklung zu zwängen, also der Versuch ein Spagat zwischen beiden Welten zu machen, um agile Entwicklung Managern schmackhafter zu machen, die nur klassische Entwicklung kennen oder verstehen und ansonsten Angst haben, die Kontrolle zu verlieren, wenn Entwickler anfangen agil zu entwickeln.

    Das Problem dabei ist, dass SCRUM an vielen Stellen die Ideen und Konzepte der agilen Entwicklung verletzt, eben um dieses Spagat hinzubekommen und am Ende weder Fisch noch Fleisch ist, denn es tut so als wäre es voll agil, in Wahrheit aber ist es klassische Entwicklung mit agiler Methodik und das ist nicht das, was die Erfinder der agilen Entwicklung im Hinterkopf hatten, als sie diese Idee entwickelt haben. Genau dieses Korsett ist das, wovon sich die Väter der agilen Entwicklung eigentlich lösen wollten.

    Schon die Wikipedia sagt:

    "Scrum (englisch für „Gedränge“) ist ein Vorgehensmodell des Projekt- und Produktmanagements"

    Projekt- und Produktmanagement sind aber Begriffe aus dem Management, nicht Begriffe aus der Entwicklung! Bei der Entwicklung, also bei dem was Entwickler tun, geht es nicht um Projekt- und Produktmanagement, sondern eben um Produktentwicklung. Und diese soll agil sein. Ob das Management darüber agil ist oder nicht kann dem Entwickler so was von egal sein, weil ihn das nicht interessieren muss, solange er seine Arbeit rein agil durchführen darf.

    SCRUM ist ein Rückschritt in der agilen Softwareentwicklung und ein sehr schlechtes Beispiel für die Umsetzung deren Konzepte. Die Idee ist es Entwicklern zu verkaufen, dass man voll agil Entwickelt und die Entwickler aktiver als bisher in die Planungs- und Entscheidungsprozesse eingebunden sind, wenn sie in Wahrheit nur ein paar agile Konzepte oberflächlich nutzen und genauso wenig zu sagen haben wie vor der Umstellung.

    Viel mehr geht es darum Entwicklern die Schuld zuweisen zu können, denn wenn es schief geht, dann ist der Entwickler schuld, der aber in ein Korsett gezwungen wurde, in dem er kaum etwas hätte viel anders machen können, als er es gemacht hat. Das ist ein bisschen so wie wenn du zwischen A, B, C oder A, C, B oder C, B, A oder B, A, C oder C, A, B oder B, C, A wählen darfst und jede dieser Wahlmöglichkeiten am Ende zum gleichen Endergebnis führen wird, nur auf einem anderen Weg und somit im gleichen Maße scheitern wird. Denn nur zwei der drei zu wählen oder statt eines der drei Option D zu wählen war zu keinem Zeitpunkt eine wählbare Option und nur das hätte dann aber wirklich einen Unterschied bewirkt. Aber genau letzteres wäre bei echter agiler Entwicklung eben möglich gewesen und nur dort ist es dann legitim dem Entwickler eine falsch Wahl anzukreiden, weil nur dort hatte er auch wirklich eine echte Wahl.

    Um auf agile Entwicklung umzustellen, muss eine Firma nicht ihre komplett Struktur umstellen. Faktisch kann alles oberhalb des Entwicklerteams genauso bleiben wie es aktuell ist und immer war. Ein Wechsel zu agile Entwickler kann rein auf der untersten Ebenen erfolgen.

    Das einzige wovon sich Manager verabschieden müssen ist die Vorstellung, dass Dinge passieren, nur weil sie sie einfordern. Das galt aber auch schon nicht für die klassischen Modelle, weswegen ja regelmäßig Deadlines gerissen wurden und Software im unfertigen oder Beta-Zustand geliefert wurde, bei der dann versprochene Features komplett fehlten oder nicht brauchbar funktionierten.

    Agile Entwicklung bringt Continuous Delivery und somit die Möglichkeit nicht mehr an feste Deadlines und feste Feature-Sets gebunden zu sein, aber ein Unternehmen muss das nicht nach außen hin nutzen. Gerade bei SCRUM ist das eh oft nicht der Fall, weil dort ja erst nach einer bestimmten Anzahl von Sprints und einer bestimmte Menge an abgearbeiteten Stories released wird, was umso mehr zeigt, das SCRUM eigentlich keine echte agile Entwicklung ist, sondern diese nur in das Korsett einer nicht-agilen Entwicklung zwängt und dann kann man sich das ganze auch gleich schenken und nur auf unterster Ebene agil werden.

    /Mecki

  2. Re: SCRUM ist Verarsche

    Autor: Lord Gamma 23.05.22 - 14:57

    Oder, wie James Coplien sagt:

    "Let's be clear. Agile comes from Scrum. Scrum doesn't come from Agile. And Agile is not the important part of Scrum. TPS is - the Toyota Production System. Agile is kind of the very modern, superficial, unproven set of cute things that keep people from having to take responsibility for stuff. Scrum is about accountability, responsibility, planning, discipline. It is not laid-back California guitar playing programming. So many people misunderstand this..."

  3. Re: SCRUM ist Verarsche

    Autor: /mecki78 23.05.22 - 18:30

    Lord Gamma schrieb:
    --------------------------------------------------------------------------------
    > Agile is kind of the very modern, superficial, unproven set of cute
    > things that keep people from having to take responsibility for stuff.

    Nur dass das Agile Manifest, auf dem die ganze Idee basiert, schon Anfang der 70er Jahre verfasst wurde und damit ca. 50 Jahre alt ist.

    Und was Verantwortlichkeiten angeht, so geht es hier darum, dass Entwickler nicht für etwas verantwortlich gemacht werden sollen, dass zu keinem Zeitpunkt in ihrer Verantwortung lag. Denn bei den klassischen Modellen entscheidet alles das Management und glaubt, nur weil sie sagen, dass das so zu laufen hat, wird das auch so laufen. Aber nur weil ich sage, dass ein Maurer am Tag 1 km Mauerwerk zu bauen hat, wird das nicht passieren, weil es einfach komplett unrealistisch ist und kein Maurer der Welt so viel Mauerwerk pro Tag bauen kann. Und wenn dann nicht das eintritt, was das Management gefordert hat, dann ist der Entwickler schuld, ungeachtet der Tatsache, dass die Forderungen komplett unrealistisch waren, die Termine unmöglich zu halten und der Entwickler keinerlei Mitspracherecht bei irgend etwas hatte.

    Du sagst nicht dem Maurer, wann eine bestimmte Mauer fertig zu sein hat, sondern du zeigst dem Maurer was du haben möchtest und fragst dann wie lange das dauert. Oder aber du sagst dem Maurer, dass du etwas bis nächste Woche Dienstag brauchst, dann musst du aber dem Maurer die genaue Ausgestaltung überlassen, dann wird er dir schon was bis Dienstag da hinstellen. Du kannst also den Umfang vorgeben oder du kannst die Zeit vorgeben, aber du kannst nicht beides vorgeben, denn du bist kein Maurer und hast überhaupt keine Ahnung von dessen Arbeit.

    Das Problem ist, dass du in beiden Fällen von Anfang an einen finalen Plan für Zeit oder Aussehen der Mauer haben musst und dann von diesem Plan nicht mehr abweichen darfst, ansonsten stimmt die Schätzung bzw. Planung des Maurers nämlich nicht mehr. Aber genau diesen Plan hat man in der Softwareentwicklung selten bis nie, sobald das Projekt eine bestimmte Größe übersteigt.

    Agiles Mauern hingegen funktioniert so:

    Du sagst dem Maurer nur, was so grob der Plan ist (die Vision), aber es gibt keine genaue Vorgabe wie die Mauer jetzt exakt auszusehen hat oder wann genau sie fertig sein muss. Und dann sagst du dem Maurer "So, und jetzt mach mal zwei Tage wie du es für richtig hältst". Und in zwei Tagen kommst du dann die Mauer anschauen, d.h. du siehst wie sie aktuell aussieht und wie weit der Maurer in der Zeit gekommen ist und jetzt hast du drei Möglichkeiten:

    1) Du bist mit Aussehen und Fortschritt zufrieden, dann sagst du ihm "Gefällt mir, mach mal die nächsten vier Tage so weiter, dann schauen wir nochmal".

    2) Du bist mit dem Fortschritt nicht zufrieden und änderst das Design, z.B. sagst du, er soll die Mauer 10% niedriger oder 25% weniger dick machen, weil das natürlich Zeit einspart. Und dann lässt du den Maurer nochmal zwei Tage mit dem neuen Vorgaben arbeiten und schaust ob jetzt der Fortschritt eher deinen Vorstellungen entspricht.

    3) Du bist mit der Mauer an sich unzufrieden und schlägst vor, die Mauer anders zu gestalten, z.B. sie dicker zu machen, was natürlich mehr Zeit kosten wird. In zwei Tagen kommst du nochmal schauen, ob die Mauer jetzt so aussieht, wie du es dir vorstellst und wie negativ sich das auf die Geschwindigkeit auswirkt.

    Oder ganz vereinfacht gesagt: Du "managst", denn das ist das, was ein Manager tun sollte. Aber du managst eben nicht, indem du komplett unsinnige Vorgaben machst und die Schuld für deine Fehlentscheidungen auf andere abwälzt, weil das hat nichts mit managen zu tun, das ist nur herumkommandieren und die Verweigerung für eigenen Entscheidungen einzustehen. Die Aufgabe eines Managers ist es, vorhandene Ressourcen bestmöglich zu verteilen und eine vernünftige Balance zwischen Qualität und Quantität zu finden.

    Das was den Managern dabei nicht schmeckt und warum sie behaupten dass jetzt niemand mehr Verantwortung übernimmt, ist die Tatsache, dass sie auf einmal selber Verantwortung übernehmen müssen, so wie sie es eigentlich schon immer hätten tun müssen. Sie können nicht länger den Entwickler für Deadlines verantwortlich machen, die nicht eingehalten werden oder erwarten, dass Entwickler 16 Stunden pro Tag arbeiten und freiwillig Überstunden ohne Ende schieben, damit die lächerliche Vorgabe des Managers erfüllt wird. Sie müssen die Kapazitäten ihrer Entwickler so einsetzen, dass am Ende was sinnvolles bei raus kommt und wenn das nicht der Fall ist, dann haben sie selber und nicht die Entwickler versagt.

    > Scrum is about accountability, responsibility, planning, discipline.

    Womit es sich dann aber nicht von Entwicklung vor Scrum unterscheidet, denn was bitte davon war vor Scrum nicht auch schon die eigentliche Anforderung an das Management?

    /Mecki

  4. Re: SCRUM ist Verarsche

    Autor: Lord Gamma 23.05.22 - 19:02

    Ja, Scrum ist ziemlich regulativ und eignet sich nicht für alle Projekte. Es ist iterativ und der Fokus liegt auf Produktivität statt auf Exploration, also ursprünglich mehr TPS als generelle Agilität.

  5. Re: SCRUM ist Verarsche

    Autor: Serenity 24.05.22 - 08:20

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Hört bitte endlich auf SCRUM mit agiler Entwicklung gleichzusetzen. SCRUM
    > ist der Versuch agile Entwicklung in ein Korsett der klassischen
    > Entwicklung zu zwängen, also der Versuch ein Spagat zwischen beiden Welten
    > zu machen, um agile Entwicklung Managern schmackhafter zu machen, die nur
    > klassische Entwicklung kennen oder verstehen und ansonsten Angst haben, die
    > Kontrolle zu verlieren, wenn Entwickler anfangen agil zu entwickeln.

    Sowas von falsch. Scrum ist definitiv nicht ein Spagat zwischen zwei Welten, weil Scrum Rollen einführt (und aufzwängt) die es vorher nicht gab. Die beste und oft diskutierteste Thema ist, ob der Product Owner ein Projektleiter oder ein Produktmanager ist. Je nachdem wen du fragst, kriegst du immer andere antworten heraus.

    > Das Problem dabei ist, dass SCRUM an vielen Stellen die Ideen und Konzepte
    > der agilen Entwicklung verletzt, eben um dieses Spagat hinzubekommen und am
    > Ende weder Fisch noch Fleisch ist, denn es tut so als wäre es voll agil, in
    > Wahrheit aber ist es klassische Entwicklung mit agiler Methodik und das ist
    > nicht das, was die Erfinder der agilen Entwicklung im Hinterkopf hatten,
    > als sie diese Idee entwickelt haben. Genau dieses Korsett ist das, wovon
    > sich die Väter der agilen Entwicklung eigentlich lösen wollten.

    Du hast Scrum ja überhaupt nicht verstanden... von Agil will ich mal nicht anfangen.

    > Schon die Wikipedia sagt:
    >
    > "Scrum (englisch für „Gedränge“) ist ein Vorgehensmodell des
    > Projekt- und Produktmanagements"

    Vorgehensmodelle sind keine Prozessdefinition, nur so zur Info.

    > Projekt- und Produktmanagement sind aber Begriffe aus dem Management, nicht
    > Begriffe aus der Entwicklung! Bei der Entwicklung, also bei dem was
    > Entwickler tun, geht es nicht um Projekt- und Produktmanagement, sondern
    > eben um Produktentwicklung. Und diese soll agil sein. Ob das Management
    > darüber agil ist oder nicht kann dem Entwickler so was von egal sein, weil
    > ihn das nicht interessieren muss, solange er seine Arbeit rein agil
    > durchführen darf.

    Genau, weil in der Entwicklung man keinen (Projekt-)Leiter braucht und niemanden der definiert, was zu tun ist *rolleyes*

    > SCRUM ist ein Rückschritt in der agilen Softwareentwicklung und ein sehr
    > schlechtes Beispiel für die Umsetzung deren Konzepte. Die Idee ist es
    > Entwicklern zu verkaufen, dass man voll agil Entwickelt und die Entwickler
    > aktiver als bisher in die Planungs- und Entscheidungsprozesse eingebunden
    > sind, wenn sie in Wahrheit nur ein paar agile Konzepte oberflächlich nutzen
    > und genauso wenig zu sagen haben wie vor der Umstellung.

    Du weißt ehrlich gesagt nicht, was agil bedeutet.
    Der Rest ist einfach zu hart falsch... Bisschen wie eine Diskussion mit einem Flat-Earther.

  6. Re: SCRUM ist Verarsche

    Autor: luke93 24.05.22 - 11:00

    Man kann darüber vermutlich endlos philosophieren, im Kern geht es bei agiler Entwicklung um Erhöhung der Transparenz und Veränderungsgeschwindigkeit. Alles drumherum dient alleine diesen Zielen, sprich das Framework ist jeweils nur Mittel zum Zweck.

  7. Re: SCRUM ist Verarsche

    Autor: Hallonator 24.05.22 - 11:59

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Sowas von falsch. Scrum ist definitiv nicht ein Spagat zwischen zwei
    > Welten, weil Scrum Rollen einführt (und aufzwängt) die es vorher nicht gab.
    Stimmt, man brauchte vorher keinen Scrummaster, der den Prozess überwacht.

    > Die beste und oft diskutierteste Thema ist, ob der Product Owner ein
    > Projektleiter oder ein Produktmanager ist.
    Scrum führt keinen "Product Owner" ein. Es gibt nur einer vorher in ähnlicher Form existierenden Rolle einen neuen Namen. An dieser Rolle hat sich bei meinem alten Arbeitgeber nach der Scrum-Einführung echt nichts geändert.

  8. Re: SCRUM ist Verarsche

    Autor: Serenity 24.05.22 - 18:17

    Hallonator schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Sowas von falsch. Scrum ist definitiv nicht ein Spagat zwischen zwei
    > > Welten, weil Scrum Rollen einführt (und aufzwängt) die es vorher nicht
    > gab.
    > Stimmt, man brauchte vorher keinen Scrummaster, der den Prozess überwacht.
    >
    > > Die beste und oft diskutierteste Thema ist, ob der Product Owner ein
    > > Projektleiter oder ein Produktmanager ist.
    > Scrum führt keinen "Product Owner" ein. Es gibt nur einer vorher in
    > ähnlicher Form existierenden Rolle einen neuen Namen. An dieser Rolle hat
    > sich bei meinem alten Arbeitgeber nach der Scrum-Einführung echt nichts
    > geändert.

    Und welche Rolle soll das vorher gewesen sein?
    Produkt Manager ist es nicht
    Projektleiter auch nicht.

  9. Re: SCRUM ist Verarsche

    Autor: /mecki78 25.05.22 - 11:11

    luke93 schrieb:
    --------------------------------------------------------------------------------
    > im Kern geht es bei
    > agiler Entwicklung um Erhöhung der Transparenz und
    > Veränderungsgeschwindigkeit.

    So für sich ist diese Aussage leicht missverständlich.

    Der Vorteil von Continuous Delivery und Continuous Integration ist, dass man jederzeit genau sehen kann, wo man in der Entwicklung steht, weil es immer etwas gibt, das man begutachten kann.

    Auch beim Wasserfallmodell kann ich Entwickler täglich berichten lassen, was sie so getan haben und was sie als nächstes tun werden und auch dort kann ich dem Management jederzeit vollen Einblick und vollen Zugang zu der aktuellen Entwicklung geben; nur das bringt hier oft nichts zu sehen, denn bis man einen Zustand erreicht, wo irgendwas lauffähig wird oder wo man tatsächlich schon die App nutzen oder testen kann, vergehen halt Wochen bis Monate. Wer also nicht versteht, was die Entwickler erzählen, der kann sich auch nichts darunter vorstellen und sich auch kein Bild davon machen, wo man aktuell in der Entwicklung steht. Es geht hierbei also weniger um Transparenz, sondern mehr Veranschaulichung gegenüber Nicht-Entwicklern.

    Und Veränderungsgeschwindigkeit ist auch missverständlich, denn es kommt weniger auf die Geschwindigkeit an, sondern viel mehr auf die Tatsache, dass Änderungen überhaupt möglich sind. Bei den klassischen Modellen gebe ich einen Auftrag nach Plan und der wird dann stur abgearbeitet. Agile Entwicklung heißt hingegen, ich plane immer nur kurz in die Zukunft, schaue mir dann die Arbeit an und kann dann neue Entscheidungen treffen oder vorhandene revidieren. So etwas sehen klassische Modelle gar nicht vor.

    /Mecki

  10. Re: SCRUM ist Verarsche

    Autor: /mecki78 25.05.22 - 11:26

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Sowas von falsch. Scrum ist definitiv nicht ein Spagat zwischen zwei
    > Welten, weil Scrum Rollen einführt (und aufzwängt) die es vorher nicht gab.

    Natürlich gab es diese Rollen vorher schon. Es gab schon immer jemand, der für die Ausgestaltung des Produktes verantwortlich war und den Weg der weiteren Entwicklung vorgegeben hat, der hieß halt nur nicht Product Owner, sondern Chef, Projektleiter, Abteilungsleiter, usw. Und es gab schon immer einen Team Leiter, der zusammen mit dem Team die Entwicklung geplant und die Umsetzung der Pläne überwacht hat hat, der hieß nur nicht Scrum Master, sondern Teamleiter, Gruppenleiter, Teammanager, etc.

    > Du hast Scrum ja überhaupt nicht verstanden...

    Nein, du hast es nicht verstanden, wie du schon anhand der falschen Aussagen zu den Rollen belegst. Auch du hast dich von dem Konzept vernaschen lassen.

    Ich habe bereits agil entwickelt, da gab es den Begriff SCRUM noch gar nicht. Und als jemand der drei SCRUM Bücher gelesen, zwei mehrwöchige SCRUM Schulungen besucht und mehrere große Unternehmen bei der Umstellungen ihrer Entwicklung auf SCRUM begleitet hat, und der schon länger agil entwickelt als du wahrscheinlich überhaupt entwickelst (sofern du überhaupt ein Entwickler ist, was ich schon für fraglich halte), brauche ich mir von einem Grashüpfer wie dir, der einfältig genug ist sich vom SCRUM Fake einlullen zu lassen, sicherlich nicht anhören müssen, was ich alles angeblich nicht verstanden habe. Du bist mal wieder Dunnning Kruger at its best!

    /Mecki

  11. Re: SCRUM ist Verarsche

    Autor: /mecki78 25.05.22 - 11:28

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Und welche Rolle soll das vorher gewesen sein?

    Die Rolle der Person, die vorher dem Entwicklerteam gesagt hat, was es als nächstes am Produkt ändern soll oder wie ein neues Produkt auszusehen hat.

    /Mecki

  12. Re: SCRUM ist Verarsche

    Autor: Serenity 25.05.22 - 11:40

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > > Du hast Scrum ja überhaupt nicht verstanden...
    >
    > Nein, du hast es nicht verstanden, wie du schon anhand der falschen
    > Aussagen zu den Rollen belegst. Auch du hast dich von dem Konzept
    > vernaschen lassen.

    xD xD xD xD xD xD xD xD xD xD xD xD
    Lies bitte mal den Scrum Guide... damit solltest du mal anfangen.

    > Ich habe bereits agil entwickelt, da gab es den Begriff SCRUM noch gar
    > nicht. Und als jemand der drei SCRUM Bücher gelesen, zwei mehrwöchige SCRUM
    > Schulungen besucht und mehrere große Unternehmen bei der Umstellungen ihrer
    > Entwicklung auf SCRUM begleitet hat, und der schon länger agil entwickelt
    > als du wahrscheinlich überhaupt entwickelst (sofern du überhaupt ein
    > Entwickler ist, was ich schon für fraglich halte), brauche ich mir von
    > einem Grashüpfer wie dir, der einfältig genug ist sich vom SCRUM Fake
    > einlullen zu lassen, sicherlich nicht anhören müssen, was ich alles
    > angeblich nicht verstanden habe. Du bist mal wieder Dunnning Kruger at its
    > best!

    (x) DOUBT

    Aber du kannst es ja leicht belegen. Poste doch mal deine Nachweise der Zeritifkate. Oder waren das alles nur udemy Kurse xD ?



    1 mal bearbeitet, zuletzt am 25.05.22 11:42 durch Serenity.

  13. Re: SCRUM ist Verarsche

    Autor: Serenity 25.05.22 - 11:48

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Und welche Rolle soll das vorher gewesen sein?
    >
    > Die Rolle der Person, die vorher dem Entwicklerteam gesagt hat, was es als
    > nächstes am Produkt ändern soll oder wie ein neues Produkt auszusehen hat.

    Ist das der Jobtitel, den man hat xD xD xD

    Du bist lustig... gefällkt mir. Freue mich schon auf den nächsten Witz

  14. Re: SCRUM ist Verarsche

    Autor: Hallonator 25.05.22 - 15:52

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > /mecki78 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Serenity schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Und welche Rolle soll das vorher gewesen sein?
    > >
    > > Die Rolle der Person, die vorher dem Entwicklerteam gesagt hat, was es
    > als
    > > nächstes am Produkt ändern soll oder wie ein neues Produkt auszusehen
    > hat.
    >
    > Ist das der Jobtitel, den man hat xD xD xD
    >
    > Du bist lustig... gefällkt mir. Freue mich schon auf den nächsten Witz

    Wieso lustig? Stimmt doch.

    Bei meinem ersten Arbeitgeber war der Titel einfach "Geschäftsführer".

  15. Re: SCRUM ist Verarsche

    Autor: Serenity 25.05.22 - 17:11

    Hallonator schrieb:
    --------------------------------------------------------------------------------
    > Serenity schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > /mecki78 schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Serenity schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Und welche Rolle soll das vorher gewesen sein?
    > > >
    > > > Die Rolle der Person, die vorher dem Entwicklerteam gesagt hat, was es
    > > als
    > > > nächstes am Produkt ändern soll oder wie ein neues Produkt auszusehen
    > > hat.
    > >
    > > Ist das der Jobtitel, den man hat xD xD xD
    > >
    > > Du bist lustig... gefällkt mir. Freue mich schon auf den nächsten Witz
    >
    > Wieso lustig? Stimmt doch.
    >
    > Bei meinem ersten Arbeitgeber war der Titel einfach "Geschäftsführer".

    Jetzt mal ernsthaft: Glaubst du wirklich, dass der Geschäftsführer eines mittelständischen Unternehmens einem Entwickler sagt, was er zu tun hat?

  16. Re: SCRUM ist Verarsche

    Autor: Dakkaron 25.05.22 - 21:11

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Lord Gamma schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Agile is kind of the very modern, superficial, unproven set of cute
    > > things that keep people from having to take responsibility for stuff.
    >
    > Nur dass das Agile Manifest, auf dem die ganze Idee basiert, schon Anfang
    > der 70er Jahre verfasst wurde und damit ca. 50 Jahre alt ist.
    >
    > Und was Verantwortlichkeiten angeht, so geht es hier darum, dass Entwickler
    > nicht für etwas verantwortlich gemacht werden sollen, dass zu keinem
    > Zeitpunkt in ihrer Verantwortung lag. Denn bei den klassischen Modellen
    > entscheidet alles das Management und glaubt, nur weil sie sagen, dass das
    > so zu laufen hat, wird das auch so laufen. Aber nur weil ich sage, dass ein
    > Maurer am Tag 1 km Mauerwerk zu bauen hat, wird das nicht passieren, weil
    > es einfach komplett unrealistisch ist und kein Maurer der Welt so viel
    > Mauerwerk pro Tag bauen kann. Und wenn dann nicht das eintritt, was das
    > Management gefordert hat, dann ist der Entwickler schuld, ungeachtet der
    > Tatsache, dass die Forderungen komplett unrealistisch waren, die Termine
    > unmöglich zu halten und der Entwickler keinerlei Mitspracherecht bei irgend
    > etwas hatte.

    Etwas schwach von einem Entwickler, auch im Wasserfall, wenn er eine unrealistische Deadline unkommentiert schluckt. Ich persönlich hab immer von Anfang an klar kommuniziert, wenn etwas nicht rechtzeitig schaffbar ist. Und bei der Frage, ob wir nicht doch die unrealistische Deadline machen können, hab ich immer geantwortet "Ja, können wir schon, aber dann wirst du dem Kunden erklären müssen, warum wir die Deadline nicht geschafft haben".

    Hab damit noch nie Probleme mit unrealistischen Deadlines gehabt. Wer nicht für sich und seine Position einsteht, der braucht sich auch nicht wundern, wenn es der Manager auch nicht tut.

    > Du sagst nicht dem Maurer, wann eine bestimmte Mauer fertig zu sein hat,
    > sondern du zeigst dem Maurer was du haben möchtest und fragst dann wie
    > lange das dauert. Oder aber du sagst dem Maurer, dass du etwas bis nächste
    > Woche Dienstag brauchst, dann musst du aber dem Maurer die genaue
    > Ausgestaltung überlassen, dann wird er dir schon was bis Dienstag da
    > hinstellen. Du kannst also den Umfang vorgeben oder du kannst die Zeit
    > vorgeben, aber du kannst nicht beides vorgeben, denn du bist kein Maurer
    > und hast überhaupt keine Ahnung von dessen Arbeit.
    >
    > Das Problem ist, dass du in beiden Fällen von Anfang an einen finalen Plan
    > für Zeit oder Aussehen der Mauer haben musst und dann von diesem Plan nicht
    > mehr abweichen darfst, ansonsten stimmt die Schätzung bzw. Planung des
    > Maurers nämlich nicht mehr. Aber genau diesen Plan hat man in der
    > Softwareentwicklung selten bis nie, sobald das Projekt eine bestimmte Größe
    > übersteigt.

    Also besser weder Schätzung noch Plan haben. Gute Idee.

    > Agiles Mauern hingegen funktioniert so:
    >
    > Du sagst dem Maurer nur, was so grob der Plan ist (die Vision), aber es
    > gibt keine genaue Vorgabe wie die Mauer jetzt exakt auszusehen hat oder
    > wann genau sie fertig sein muss. Und dann sagst du dem Maurer "So, und
    > jetzt mach mal zwei Tage wie du es für richtig hältst". Und in zwei Tagen
    > kommst du dann die Mauer anschauen, d.h. du siehst wie sie aktuell aussieht
    > und wie weit der Maurer in der Zeit gekommen ist und jetzt hast du drei
    > Möglichkeiten:
    >
    > 1) Du bist mit Aussehen und Fortschritt zufrieden, dann sagst du ihm
    > "Gefällt mir, mach mal die nächsten vier Tage so weiter, dann schauen wir
    > nochmal".
    >
    > 2) Du bist mit dem Fortschritt nicht zufrieden und änderst das Design, z.B.
    > sagst du, er soll die Mauer 10% niedriger oder 25% weniger dick machen,
    > weil das natürlich Zeit einspart. Und dann lässt du den Maurer nochmal zwei
    > Tage mit dem neuen Vorgaben arbeiten und schaust ob jetzt der Fortschritt
    > eher deinen Vorstellungen entspricht.
    >
    > 3) Du bist mit der Mauer an sich unzufrieden und schlägst vor, die Mauer
    > anders zu gestalten, z.B. sie dicker zu machen, was natürlich mehr Zeit
    > kosten wird. In zwei Tagen kommst du nochmal schauen, ob die Mauer jetzt so
    > aussieht, wie du es dir vorstellst und wie negativ sich das auf die
    > Geschwindigkeit auswirkt.
    >
    > Oder ganz vereinfacht gesagt: Du "managst", denn das ist das, was ein
    > Manager tun sollte. Aber du managst eben nicht, indem du komplett unsinnige
    > Vorgaben machst und die Schuld für deine Fehlentscheidungen auf andere
    > abwälzt, weil das hat nichts mit managen zu tun, das ist nur
    > herumkommandieren und die Verweigerung für eigenen Entscheidungen
    > einzustehen. Die Aufgabe eines Managers ist es, vorhandene Ressourcen
    > bestmöglich zu verteilen und eine vernünftige Balance zwischen Qualität und
    > Quantität zu finden.

    Lass mal zusammenfassen: Es geht darum, dass die Grundstruktur eines großen Projekts geschaffen wird, von der die Ausgestaltung des gesamten Projekts abhängt (auf die Mauer kommt die Decke, der Putz, die Bilder und die Hängeschränke für die Küche).

    Du hast einen konkreten Plan, wie diese Mauer aussehen soll, und welchen Spezifikationen sie entsprechen soll. Unklar ist nur der Zeitaufwand.

    Also sagt man dem Maurer "Mach mal bitte was mit Ziegelsteinen grob in die Richtung."

    Nach einer gewissen Arbeitszeit und kräftigem Materialaufwand (ein Maurer schafft in zwei Tagen schon ziemlich viel) kommt man dann hin und sagt "Jetzt reiß mal bitte alles ein und kauf schmalere Ziegel".

    Bin ich froh, dass du kein Baumeister bist ;)

    Gleiches trifft auch auf Programme zu.

    Dedizierte Prototypen machen ist eine gute Idee. Erzwingen, dass aus einem komplett falschen Prototypen irgendwie den Grundstock eines mehrjährigen Projekts zu machen ist... unschlau.

  17. Re: SCRUM ist Verarsche

    Autor: mussichmalloswerden 27.05.22 - 08:25

    Scrum an sich ist keine schlechte Idee. Es gibt eine Grundstruktur der Organisation als Startpunkt. Das team muss mit der Zeit daraus seinen eigenen Workflow entwickeln.

    Aber Software Projekte kranken meiner Meinung nach an ganz anderen Stellen.

    Erstens wird oft das Requirements Engineering komplett weggelassen, weil man denkt man könne mit Scrum ja immer alles agil verändern.

    Das zweite große Issue sind Manager, die versprechen Dinge in bestimmten Timelines zu liefern ohne vorher mal mit den Developern zu sprechen oder gar ein Requirements Engineering, einen POC oder sonst was zu machen um zu sehen ob so ein Versprechen überhaupt gegeben werden kann.

    Das dritte Problem ist, das man oft meint, ein Entwickler müsste zeitlich genau abschätzen können wie lange es dauert etwas zu entwickeln, dass es noch nicht gibt. Wenn du noch nicht weißt was ein Backstein ist und welche Werkzeuge du brauchst kannst du eben nicht schätzen wie lange es dauert eine Mauer zu bauen.

    Das sind aber keine Probleme die mit Scrum gelöst werden können. Nur wird Scrum als Allheilmittel verstanden diesen Kram zu lösen.

    BTW haben CD und scrum auch nichts miteinander zu tun. Nur weil das oben irgendwer erwähnte.

  18. Re: SCRUM ist Verarsche

    Autor: Hallonator 30.05.22 - 09:07

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Hallonator schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Serenity schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > /mecki78 schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Serenity schrieb:
    > > > >
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > >
    > > > > -----
    > > > > > Und welche Rolle soll das vorher gewesen sein?
    > > > >
    > > > > Die Rolle der Person, die vorher dem Entwicklerteam gesagt hat, was
    > es
    > > > als
    > > > > nächstes am Produkt ändern soll oder wie ein neues Produkt
    > auszusehen
    > > > hat.
    > > >
    > > > Ist das der Jobtitel, den man hat xD xD xD
    > > >
    > > > Du bist lustig... gefällkt mir. Freue mich schon auf den nächsten Witz
    > >
    > > Wieso lustig? Stimmt doch.
    > >
    > > Bei meinem ersten Arbeitgeber war der Titel einfach "Geschäftsführer".
    >
    > Jetzt mal ernsthaft: Glaubst du wirklich, dass der Geschäftsführer eines
    > mittelständischen Unternehmens einem Entwickler sagt, was er zu tun hat?

    Mein aktuelles Unternehmen hat 100 Mitarbeiter und der eine Geschäftsführer ist Product Owner. Kannst du dir das nicht vorstellen oder hast du eine andere Definition von Mittelstand als Wikipedia?

    Ich weiß echt nicht, in was für einer Welt du lebst. Was glaubst du denn, was Entwickler gemacht haben als es noch kein Scrum gegeben hat? Das, worauf sie selbst Lust hatten?

  19. Re: SCRUM ist Verarsche

    Autor: Serenity 30.05.22 - 15:24

    Hallonator schrieb:
    --------------------------------------------------------------------------------
    > Mein aktuelles Unternehmen hat 100 Mitarbeiter und der eine Geschäftsführer
    > ist Product Owner. Kannst du dir das nicht vorstellen oder hast du eine
    > andere Definition von Mittelstand als Wikipedia?
    >
    > Ich weiß echt nicht, in was für einer Welt du lebst. Was glaubst du denn,
    > was Entwickler gemacht haben als es noch kein Scrum gegeben hat? Das,
    > worauf sie selbst Lust hatten?

    Nochmal: Der Geschäftsführer definiert deine Arbeitspakete, schreibt die Tickets, kontrolliert und überwacht deine Arbeit und macht zusätzlich noch andere Themen als Geschäftsführer?

    Ich glaube, du lebst in einer verkehrten Welt.... Schonmal was von einem Projektleiter gehört? Oder Produktmanager? Lies mal, was ich vorher geschrieben habe, statt es zu ignorieren.
    Ich hoffe für dich, du musst dir nie einen neuen Job suchen....

  20. Re: SCRUM ist Verarsche

    Autor: Hallonator 30.05.22 - 16:50

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > Hallonator schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Mein aktuelles Unternehmen hat 100 Mitarbeiter und der eine
    > Geschäftsführer
    > > ist Product Owner. Kannst du dir das nicht vorstellen oder hast du eine
    > > andere Definition von Mittelstand als Wikipedia?
    > >
    > > Ich weiß echt nicht, in was für einer Welt du lebst. Was glaubst du
    > denn,
    > > was Entwickler gemacht haben als es noch kein Scrum gegeben hat? Das,
    > > worauf sie selbst Lust hatten?
    >
    > Nochmal: Der Geschäftsführer definiert deine Arbeitspakete, schreibt die
    > Tickets, kontrolliert und überwacht deine Arbeit und macht zusätzlich noch
    > andere Themen als Geschäftsführer?
    100 Punkte für den Kandidaten!

    > Ich glaube, du lebst in einer verkehrten Welt....
    Ok, doch keine Punkte für den Kandidaten :(

    > Schonmal was von einem Projektleiter gehört? Oder Produktmanager?
    Ja. Und jetzt? Soll ich zu meinem Geschäftsführer geben: "also laut so einem vorlauten Bengel aus dem golem Forum musst du einen Produktmanager einstellen und deine PO-Aufgaben an den übertragen" :D

    > Lies mal, was ich vorher
    > geschrieben habe, statt es zu ignorieren.
    Wozu? Mehr als, dass du einen sehr beschränkten Horizont hast, steht in deinen Posts doch nicht.

    > Ich hoffe für dich, du musst dir nie einen neuen Job suchen....
    Hat beim letzten mal drei Wochen gedauert.

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Pricing Specialist (m/w/d)
    Habasit GmbH, Raum Eppertshausen
  2. Spezialistin Supportmanagement (m/w/d)
    Stadtwerke München GmbH, München
  3. Softwareentwickler Java (m/w/d)
    Techniker Krankenkasse, Hamburg
  4. IT Information Security Analyst (m/w/d)
    Hirschvogel Holding GmbH, Denklingen

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 21,37€ mit Gutscheincode TROOPERS
  2. (stündlich aktualisiert)
  3. (u. a. Switch Sports für 39,99€, Chocobo GP für 26,09€)
  4. 6,79€


Haben wir etwas übersehen?

E-Mail an news@golem.de