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

Fallbeispiele wie es nicht funktioniert

  1. Thema

Neues Thema Ansicht wechseln


  1. Fallbeispiele wie es nicht funktioniert

    Autor: bark 14.01.19 - 09:30

    Ich glaub hier wird eine Reihe von Menschen geben die das verteufeln.
    Aber nicht merken, dass die Probleme daher kommen, dass sie agile Methoden nicht richtig eingesetzt haben.
    Es reicht halt nicht zu sagen es gibt jetzt sprints und alles kommt in Tickets.

  2. Re: Fallbeispiele wie es nicht funktioniert

    Autor: chromax 14.01.19 - 09:41

    Das stimmt. Das was man an Flexibilität gewinnt, muss man mit einer harten und unerbittlichen Regelkonformität bezahlen. Aber das ist schwer, denn wie erwähnt kommen von allen Seiten noch "kleine Vorschläge". Da muss man knallhart blocken, auch von gut zahlenden Kunden. Und da liegt oft schon das Problem.

    An der Stelle mit dem Klickdummy hab ich zusammengezuckt, denn das ist oft das "Tor zur Hölle", denn Kunden werden sehr kreativ wenn sie erst mal etwas sehen.



    1 mal bearbeitet, zuletzt am 14.01.19 09:42 durch chromax.

  3. "nicht richtig eingesetzt"

    Autor: demon driver 14.01.19 - 09:46

    bark schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub hier wird eine Reihe von Menschen geben die das verteufeln.
    > Aber nicht merken, dass die Probleme daher kommen, dass sie agile Methoden
    > nicht richtig eingesetzt haben [...]

    Einerseits mag das in manchen Fällen so sein, andererseits ist das aber auch immer die Ausrede der Fans, egal worum es geht – wenn was nicht klappt, haben's die Leute bloß nicht richtig gemacht/verstanden/eingesetzt...

  4. Re: Fallbeispiele wie es nicht funktioniert

    Autor: Targi 14.01.19 - 09:59

    bark schrieb:
    --------------------------------------------------------------------------------
    > Ich glaub hier wird eine Reihe von Menschen geben die das verteufeln.
    > Aber nicht merken, dass die Probleme daher kommen, dass sie agile Methoden
    > nicht richtig eingesetzt haben.
    > Es reicht halt nicht zu sagen es gibt jetzt sprints und alles kommt in
    > Tickets.

    Seit Jahrzehnten schaue ich mir Entwicklungsmodelle in der Software-Entwicklung an. Wasserfallmodell, V-Modell, Pair-Programming, Code and Fix, Plan Driven, Scrum. Projekte sind erfolgreich oder scheitern unbabhängig vom verwendeten Modell, aber immer erklären einem beim Scheitern die Befürworter, dass man es nur falsch eingesetzt hätte.
    Nach 20 Jahren in dem Bereich ist meine Erfahrung, dass Softwareentwicklung immer auf "Gewurschtel" hinausläuft. Inzwischen nennt man das "agil" und hat es ein Stück weit akzeptiert, was ich schon als Fortschritt sehe. Alle Systeme, an die man sich sklavisch halten soll, versprechen mehr, als sie halten. Vieles klingt gut, solange es während Schulungen oder Vorlesungen fernab der Realität präsentiert wird, im echten Geschäft sind Dogmen selten hilfreich. Das galt fürs Wasserfallmodell damals genauso wie für Scrum heute. Was es braucht, sind gute Projektleiter, gute Entwickler, sowie eine realistische Abschätzung, was mit Zeit und Budget möglich ist.

  5. Re: Fallbeispiele wie es nicht funktioniert

    Autor: co 14.01.19 - 11:45

    Wir haben hier vor 2 Jahren mal schnell auf Scrum umgestellt, alles, was nicht agil ist, war plötzlich alt und bäh und verpönt.
    Wir haben nicht wirklich einen Scrum Master und der Product Owner ist völlig überfordert mit seiner Aufgabe. Ob wir jemals ganz fertig werden, weiß ich nicht, denn obwohl wird schon recht weit mit der ursprünglich gestellten Aufgabe sind, reißen wir gerade den halben Unterbau weg, weil das die bessere Idee. Es ist ein Gewurschtel und wir leben agile Entwicklung so, dass es eben nie fertig wird, weil immer was grundlegend neues dazu kommt, bevor das alte, funktionierende, beim Kunden angekommen ist.

  6. Re: "nicht richtig eingesetzt"

    Autor: Trollversteher 14.01.19 - 11:58

    >Einerseits mag das in manchen Fällen so sein, andererseits ist das aber auch immer die Ausrede der Fans, egal worum es geht – wenn was nicht klappt, haben's die Leute bloß nicht richtig gemacht/verstanden/eingesetzt...

    Ist ja auch meistens so -
    Gerade bei agilen Methoden wie Scrum, die ja weit entfernt davon sind, ein starres Regelwerk auf jede Art von Projekten pressen zu wollen. Das sind nur *Vorgaben*, an denen man sich orientieren kann, aber um im Praxisalltag funktionieren zu können, müssen diese Prozesse den Gegebenheiten flexibel angepasst werden. Und den Ausdruck "Fans" finde ich hier bei diesem Thema ohnehin völlig fehl am Platz. Wer professionell denkt und arbeitet, sollte immer in der Lage sein, die richtigen Werkzeuge und Prozesse für eine konkrete Aufgabe wählen zu können, und nicht plötzlich überall Nägel sehen, nur weil man gerade einen tollen neuen Hammer in der Hand hält. Das kann im Einzelfall sogar bedeuten, dass man sich bewusst *gegen* eine agile Methode entscheidet, weil sie eben nicht zur Projektstruktur/natur passt.

  7. Re: Fallbeispiele wie es nicht funktioniert

    Autor: Trollversteher 14.01.19 - 12:03

    Wenn Du in Scrum und anderen Methoden ein "System, an das sich alle sklavisch halten müssen" siehst, hast Du (oder die Entscheider, unter denen Du leiden musstest) schon grundsätzlich etwas falsch verstanden, denn darum geht es ja gerade *nicht*. Und im Grunde sagst Du es ja im letzten Satz selbst: Es hängt von sämtlichen Beteiligten ab, ob ein Projekt erfolgreich zu Ende gebracht wird, die beste und tollste agile Methode scheitert, wenn die Beteiligten die Umsetzung verbocken. Aber wenn es richtig angepackt und umgesetzt wird und auf das Projekt passt, sind imho agile Methoden den klassischen Methoden wie dem berüchtigten Wasserfallmodell bei Weitem vorzuziehen.

  8. Re: "nicht richtig eingesetzt"

    Autor: demon driver 14.01.19 - 13:50

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Einerseits mag das in manchen Fällen so sein, andererseits ist das aber
    > auch immer die Ausrede der Fans, egal worum es geht – wenn was nicht
    > klappt, haben's die Leute bloß nicht richtig
    > gemacht/verstanden/eingesetzt...
    >
    > Ist ja auch meistens so -

    Beweis durch Behauptung, oder hast du dafür belastbare Daten?

    > Gerade bei agilen Methoden wie Scrum, die ja weit entfernt davon sind, ein
    > starres Regelwerk auf jede Art von Projekten pressen zu wollen. Das sind
    > nur *Vorgaben*, an denen man sich orientieren kann, aber um im Praxisalltag
    > funktionieren zu können, müssen diese Prozesse den Gegebenheiten flexibel
    > angepasst werden.

    Scrum ist bei aller "Anpassbarkeit" immer auch ein Korsett.

    > Und den Ausdruck "Fans" finde ich hier bei diesem Thema
    > ohnehin völlig fehl am Platz.

    Mitnichten. Es ist kein Zufall, dass Rhetorik, Argumentationsmuster und Missionierungsbedürfnis bei Agile-Verfechtern den Fans und Advocacy-Gruppen beliebiger anderer Sphären mitunter frappierend ähneln.

    > Wer professionell denkt und arbeitet, sollte
    > immer in der Lage sein, die richtigen Werkzeuge und Prozesse für eine
    > konkrete Aufgabe wählen zu können, und nicht plötzlich überall Nägel sehen,
    > nur weil man gerade einen tollen neuen Hammer in der Hand hält.

    Das war jetzt beispielsweise ein typischer Fall von (hier allerdings alter, langweiliger, sich in Allgemeinplätzen erschöpfender) "Rhetorik" und "Missionierungsbedürfnis"...

    > Das kann im
    > Einzelfall sogar bedeuten, dass man sich bewusst *gegen* eine agile Methode
    > entscheidet, weil sie eben nicht zur Projektstruktur/natur passt.

    Zum einen das. Zum anderen ist "anders" nicht automatisch "besser". Das gilt insbesondere für "Agile" nach meinem Eindruck wesentlich öfter, als seine Verfechter zuzugeben bereit sind. Weil es im Einzelfall womöglich auch eben einfach gar nichts so großartig anderes ist, als das, was im Unternehmen schon praktiziert wird, bisher bloß ohne hippe Labels und mit weniger Korsett.

  9. Re: Fallbeispiele wie es nicht funktioniert

    Autor: ubuntu_user 14.01.19 - 13:54

    co schrieb:
    --------------------------------------------------------------------------------
    > Wir haben hier vor 2 Jahren mal schnell auf Scrum umgestellt

    ich würde sagen, habt ihr nicht.

    > Wir haben nicht wirklich einen Scrum Master und der Product Owner ist
    > völlig überfordert mit seiner Aufgabe.

    > so, dass es eben nie fertig wird, weil immer was grundlegend
    > neues dazu kommt, bevor das alte, funktionierende, beim Kunden angekommen
    > ist.

  10. Re: "nicht richtig eingesetzt"

    Autor: Trollversteher 14.01.19 - 14:03

    >Beweis durch Behauptung, oder hast du dafür belastbare Daten?

    Nö, aber langjährige Erfahrung in den unterschiedlichsten Projekten...
    Hätte ja auch die Gegenfrage stellen können - Deine Aussage, es läge in der Regel nicht an der Umsetzung sondern das seien nur "Ausreden Fans" ist ja genau so wenig durch belastbare Daten belegt.

    >Scrum ist bei aller "Anpassbarkeit" immer auch ein Korsett.

    Nicht mehr, als jede andere Art der Projektplanung/Durchführung auch - das Korsett ist immer nur so eng, wie man es sich selber macht. Und völliges "Laissez Fair", bei dem jeder unkoordiniert macht was er will, ist sicher in keinem Fall besonders effizient.

    >Mitnichten. Es ist kein Zufall, dass Rhetorik, Argumentationsmuster und Missionierungsbedürfnis bei Agile-Verfechtern den Fans und Advocacy-Gruppen beliebiger anderer Sphären mitunter frappierend ähneln.

    Das mag es geben, das ist aber imho generell einer bestimmten unprofessionellen, dogmatischen Grundhaltung geschuldet und nicht ein spezielles Problem von Befürwortern agiler Methoden.


    >Das war jetzt beispielsweise ein typischer Fall von (hier allerdings alter, langweiliger, sich in Allgemeinplätzen erschöpfender) "Rhetorik" und "Missionierungsbedürfnis"...

    Eigentlich habe ich Dir damit nur zugestimmt, aber da Du so in Deinem Rausch bist ist Dir das nicht mal aufgefallen. So langsam kommt mir der Verdacht, als ob Du selbst zu einer Einstellung neigst, die Du hier anderen unterstellst - nur eben von der anderen ("Hater" statt "Fanboy") Seite.

    >Zum einen das. Zum anderen ist "anders" nicht automatisch "besser". Das gilt insbesondere für "Agile" nach meinem Eindruck wesentlich öfter, als seine Verfechter zuzugeben bereit sind. Weil es im Einzelfall womöglich auch eben einfach gar nichts so großartig anderes ist, als das, was im Unternehmen schon praktiziert wird, bisher bloß ohne hippe Labels und mit weniger Korsett.

    Ich habe nie behauptet, dass "anders automatisch besser ist", im Gegenteil - Wie gesagt, was Du hier beschreibst/kritisierst ist nicht das typische Verhalten von Verfechtern der agilen Methodik, sondern ideologische Engstirnigkeit und einer gewissen "Modehörigkeit", die es in allen Bereichen gibt (auch bei der Wahl konkreter Werkzeuge wie Apis, Betriebssysteme oder Sprachen) und die unabhängig von der konkreten Methode ist.

    Und wenn Menschen mit so einer unprofessionellen, ideologisierten oder von "hippen Moden" getriebenen Grundeinstellung dann meinen "Scrum machen" zu müssen, weil es eben gerade alle machen, die "hipp" sein wollen, und das Ganze dann, absehbar, den Bach herunter geht, dann liegt es eben *doch* an den Beteiligten und nicht der Methodik an sich.



    1 mal bearbeitet, zuletzt am 14.01.19 14:07 durch Trollversteher.

  11. Re: Fallbeispiele wie es nicht funktioniert

    Autor: Clown 14.01.19 - 14:05

    chromax schrieb:
    --------------------------------------------------------------------------------
    > Da muss man
    > knallhart blocken, auch von gut zahlenden Kunden. Und da liegt oft schon
    > das Problem.
    >
    > An der Stelle mit dem Klickdummy hab ich zusammengezuckt, denn das ist oft
    > das "Tor zur Hölle", denn Kunden werden sehr kreativ wenn sie erst mal
    > etwas sehen.

    Hm, das klingt für mich eigenartig.
    Schließlich *soll* das agile Modell ja ermöglichen, dass der zahlende Kunde (also der, der letzten Endes die Rechnungen und Gehälter bezahlt :D) auch recht kurzfristig Änderungen postulieren kann ohne die gesamte Entwicklung über den Haufen zu schmeißen.

    Blizzard: "You guys don't have phones?" ~ Bethesda: "You guys don't have friends?" ~ EA: "You guys don't have wallets?"

  12. Re: Fallbeispiele wie es nicht funktioniert

    Autor: Trollversteher 14.01.19 - 14:10

    >Hm, das klingt für mich eigenartig.
    >Schließlich *soll* das agile Modell ja ermöglichen, dass der zahlende Kunde (also der, der letzten Endes die Rechnungen und Gehälter bezahlt :D) auch recht kurzfristig Änderungen postulieren kann ohne die gesamte Entwicklung über den Haufen zu schmeißen.

    Dass das aber nur innerhalb gewisser Grenzen funktioniert, und ggf. erhebliche Kosten an Zeit und Ressourcen verursacht, sollte man dem Kunden in diesem Fall dann auch eindeutig klar machen können.

  13. Re: "nicht richtig eingesetzt"

    Autor: demon driver 14.01.19 - 14:57

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    [...]
    > >Das war jetzt beispielsweise ein typischer Fall von (hier allerdings
    > alter, langweiliger, sich in Allgemeinplätzen erschöpfender) "Rhetorik" und
    > "Missionierungsbedürfnis"...
    >
    > Eigentlich habe ich Dir damit nur zugestimmt, aber da Du so in Deinem
    > Rausch bist ist Dir das nicht mal aufgefallen. So langsam kommt mir der
    > Verdacht, als ob Du selbst zu einer Einstellung neigst, die Du hier anderen
    > unterstellst - nur eben von der anderen ("Hater" statt "Fanboy") Seite.
    [...]

    Touché. Da hatte ich tatsächlich in der Eile nicht mal richtig gelesen.

  14. Re: "nicht richtig eingesetzt"

    Autor: Trollversteher 14.01.19 - 15:09

    >Touché. Da hatte ich tatsächlich in der Eile nicht mal richtig gelesen.

    Kann ja mal passieren, und ist mir hier auch schon mehr als einmal passiert - wichtig ist nur, dass man, wie Du, dann auch Fehler eingestehen kann - also alles gut, ich denke, wir beiden liegen eigentlich mit unseren Meinungen auch gar nicht so weit auseinander ;-)

    (Und sorry für den etwas überzogenen "Hater/Fanboy" Vorwurf, der war eindeutig übertrieben).

  15. Re: "nicht richtig eingesetzt"

    Autor: demon driver 14.01.19 - 15:38

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > (Und sorry für den etwas überzogenen "Hater/Fanboy" Vorwurf, der war
    > eindeutig übertrieben).

    Kein Problem, no offence taken...

  16. Re: Fallbeispiele wie es nicht funktioniert

    Autor: Hotohori 14.01.19 - 18:43

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > co schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Wir haben hier vor 2 Jahren mal schnell auf Scrum umgestellt
    >
    > ich würde sagen, habt ihr nicht.
    >
    > > Wir haben nicht wirklich einen Scrum Master und der Product Owner ist
    > > völlig überfordert mit seiner Aufgabe.
    >
    > > so, dass es eben nie fertig wird, weil immer was grundlegend
    > > neues dazu kommt, bevor das alte, funktionierende, beim Kunden
    > angekommen
    > > ist.

    Bei dem beschriebenen Resultat würde ich das auch so sagen. Ihr habt versucht umzustellen und seid dann irgendwo völlig falsch abgebogen.

  17. Re: Fallbeispiele wie es nicht funktioniert

    Autor: merlinhst123 14.01.19 - 21:59

    Erstens ist Scrum nur eine agile Vorgehensweise neben Kanban, XP usw.
    Und zweitens hängt der Projekterfolg i.d.R. nicht alleine von der Vorgehensweise ab sondern eher von den Randbedingungen ("muss schnell fertig werden", "haben wir schon immer so gemacht", "frag nicht so viel", "ich will das so" etc.) Die Idee von Agile ist, dass Probleme ggf früher sichtbar werden und einfacher darauf reagiert werden kann ("inspect and adapt"). Gerade bei Wasserfall stürzt ja gerne mal gleich der ganze Plan für die nächsten Monate zusammen. Wobei es auch genug Leute gibt, die Wasserfall nicht verstanden haben :)

  18. Re: Fallbeispiele wie es nicht funktioniert

    Autor: 0xDEADC0DE 15.01.19 - 08:35

    co schrieb:
    --------------------------------------------------------------------------------
    >Es ist ein Gewurschtel und wir leben agile Entwicklung so,
    > dass es eben nie fertig wird, weil immer was grundlegend
    > neues dazu kommt, bevor das alte, funktionierende, beim
    > Kunden angekommen ist.

    Agile Entwicklung bedeutet, dass man sich schnell an Probleme oder neue Situationen anpassen kann und nicht erst bis zu Ende implementiert und dann der Kunde die Software zum ersten mal sieht und sich denkt: Das habe ich mir darunter aber nicht so vorgestellt, es tut nicht was es soll und ist umständlich zu bedienen.

    Agile bedeutet den Stakeholder frühzeitig einzubinden und die Software so zu gestalten, wie es der Kunde vorgesehen hat, was nicht heißt, dass sie dann super wird: You get what you pay for... ;)

    Agile bedeutet aber NICHT, dass man dadurch ständig neue Features reinpackt! Man schließt erst mal die Entwicklung einer Version ab und neue Features, die nachträglich gewünscht werden, kann man zwar gleich in der ersten Version mit einbauen, sollte das aber besser nicht. Denn sonst kommt man nie zum Ende. ;)

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Eurowings Aviation GmbH, Köln
  2. Modis GmbH, Bonn
  3. Netze BW GmbH, Karlsruhe
  4. Bayerische Hausbau GmbH & Co. KG, München

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-77%) 13,99€
  2. 4,60€
  3. 26,99€
  4. 2,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Magischer Dieb trifft mogelnden Doktor
Mobile-Games-Auslese
Magischer Dieb trifft mogelnden Doktor

Ein Dieb mit Dolch in Daggerhood, dazu ein (historisch verbürgter) Arzt in Astrologaster sowie wunderschön aufbereitetes Free-to-Play-Mittelalter in Marginalia Hero: Golem.de stellt die spannendsten neuen Mobile Games vor.
Von Rainer Sigl

  1. Hyper Casual Games 30 Sekunden spielen, 30 Sekunden Werbung
  2. Mobile-Games-Auslese Rollenspiel-Frühling mit leichten Schusswechseln
  3. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS

Doom Eternal angespielt: Die nächste Ballerorgie von id macht uns fix und fertig
Doom Eternal angespielt
Die nächste Ballerorgie von id macht uns fix und fertig

E3 2019 Extrem schnelle Action plus taktische Entscheidungen, dazu geniale Grafik und eine düstere Atmosphäre: Doom Eternal hat gegenüber dem erstklassigen Vorgänger zumindest beim Anspielen noch deutlich zugelegt.

  1. Sigil John Romero setzt Doom fort

Ada und Spark: Mehr Sicherheit durch bessere Programmiersprachen
Ada und Spark
Mehr Sicherheit durch bessere Programmiersprachen

Viele Sicherheitslücken in Software sind auf Programmierfehler zurückzuführen. Diese Fehler lassen sich aber vermeiden - und zwar unter anderem durch die Wahl einer guten Programmiersprache. Ada und Spark gehören dazu, leider sind sie immer noch wenig bekannt.
Von Johannes Kanig

  1. Das andere How-to Deutsch lernen für Programmierer
  2. Programmiersprachen, Pakete, IDEs So steigen Entwickler in Machine Learning ein
  3. Software-Entwickler Welche Programmiersprache soll ich lernen?

  1. Thüringen: Mehr unangekündigte Datenschutzkontrollen in Unternehmen
    Thüringen
    Mehr unangekündigte Datenschutzkontrollen in Unternehmen

    Bei der Vorstellung seines Tätigkeitsberichtes kündigte der Datenschutzbeauftragte aus Thüringen an, Unternehmen stärker zu kontrollieren - auch unangekündigt. Zur Not werde er sich mit Hilfe der Polizei Zugang verschaffen.

  2. Entwicklungsplattform: Gitlab 12 setzt auf Security
    Entwicklungsplattform
    Gitlab 12 setzt auf Security

    Mit der aktuellen Version 12 der Entwicklungsplattform Gitlab wollen die Entwickler "Sicherheit zu einem automatisierten Teil des Release-Zyklus" machen. Dazu gibt es Funktionen, die den Umgang mit Sicherheitslücken und Patches vereinfachen soll.

  3. GE: Smarte Lampe mit 11- bis 13-stufigem Resetverfahren
    GE
    Smarte Lampe mit 11- bis 13-stufigem Resetverfahren

    Smart Home muss nicht immer smart sein. Vor allem, wenn es mal Probleme gibt. Eines der komplexesten Verfahren zum Zurücksetzen eines Leuchtmittels hat sich GE ausgedacht. Zählung nach dem Mississippi-Prinzip inklusive.


  1. 15:01

  2. 15:00

  3. 13:50

  4. 12:45

  5. 12:20

  6. 11:49

  7. 11:37

  8. 11:25