1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › 20 Jahre Agiles…
  6. Thema

Agil hatte nie eine konkrete Bedeutung

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

Neues Thema Ansicht wechseln


  1. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: dEEkAy 01.09.21 - 00:05

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > /mecki78 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > Das Problem bei konkreten Sachen ist aber ja meist, dass die nicht
    > überdauern.
    > Jetzt mal nen Beispiel: 100% Testabdeckung und die Entwickler sollen TD
    > entwickeln.
    > Jetzt gibts ne KI, die dir die Tests generiert. Schon ist das mehr oder
    > weniger für die Tonne.
    > (auch wenn ich weiß welche Probleme das alles mit sich bringt)
    >
    > > "Individuen und Interaktionen mehr als Prozesse und Werkzeuge"
    > >
    > > Ja, klingt schön. Aber was heißt das konkret? Was soll jetzt irgendwer
    > > konkret tun, weil ich ihm das gesagt habe? Was bitte ist die
    > > Handlungsanweisung hier? Wie soll ein Manager mit dieser Forderung bitte
    > > umgehen?
    >
    > naja im Prinzip ist das agile Manifest das Interface und das Konkrete die
    > Implementierung. D.h. man müsste sagen wir nehmen SCRUM und implementieren
    > das nach A(giles)M(anifesto) 3.1 oder so.
    > Aber jetzt das Beispiel:
    > "Individuen und Interaktionen mehr als Prozesse und Werkzeuge"
    > Meistens ist das ja so:
    > pbs.twimg.com
    > und der Entwickler ist meistens ruhig, weil eher introvertiert, sonst wäre
    > er kein Entwickler geworden.


    Ein Entwickler muss nich unbedingt introvertiert sein, auch wenn ich selbst als Entwickler nicht extrovertiert bin. Das Problem ist nur folgendes: Man findet Bugs, meldet diese wie es sich gehört, gibt die Info weiter. Bekommt dann die Info zurück man solle es doch auf Prio x/y/z setzen, damit wäre man noch releasefähig und könne den Code wie geplant raushauen. Gefixt wird später, später kommt aber nie.

  2. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: ubuntu_user 01.09.21 - 07:12

    dEEkAy schrieb:
    --------------------------------------------------------------------------------
    > Ich würde ja so gerne clean und agil arbeiten, es wird einem aber nicht
    > ermöglicht. Also schludert man halt die dirty Variante hin, die nächste
    > Deadline steht eh schon und der Code muss in x Tagen raus, komme was
    > wolle.
    >
    > Ich glaub man merkt, dass ich leicht gefrustet bin.

    liegt ja meistens an den Entwicklern...
    im prinzip hast du immer streikbrecher, die das hinfuschen und dann alle anderen schlecht aussehen lassen, die sorgfältig arbeiten.
    Das fehlt halt auch in dem agilen manifest

  3. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: ubuntu_user 01.09.21 - 07:14

    dEEkAy schrieb:
    --------------------------------------------------------------------------------
    > Ein Entwickler muss nich unbedingt introvertiert sein, auch wenn ich selbst
    > als Entwickler nicht extrovertiert bin. Das Problem ist nur folgendes: Man
    > findet Bugs, meldet diese wie es sich gehört, gibt die Info weiter. Bekommt
    > dann die Info zurück man solle es doch auf Prio x/y/z setzen, damit wäre
    > man noch releasefähig und könne den Code wie geplant raushauen. Gefixt wird
    > später, später kommt aber nie.

    ja. deswegen musst du halt lügen.
    fixt den bug und schreibst das auf feature x/y/z
    hinterher sind dann alle froh, wenn das alles bugfrei läuft.
    problem sind dann streikbrecher im team, die keine tests schreiben und features liefern

  4. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: LeeRoyWyt 01.09.21 - 10:49

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Und programmieren ist immer Mathematik, denn eine CPU kann nur Mathematik,
    > am Ende sind alles mathematische Operationen. Aber bezahlt wird man dafür
    > Probleme zu lösen und Probleme zu lösen ist wie Rätsel lösen, man muss das
    > Problem verstehen und sich eine Lösung erarbeiten, das macht ein
    > Programmierer. Und weil er dabei aber gewisse kreative Freiheiten hat, die
    > er sinnvoll nutzen muss, ansonsten kommt unlesbarer oder unwartbarer Code
    > bei raus, ist es eben auch zu einem gewissen Punkt Kreativität.

    Ich habe schon soooo viele Mathematiker getroffen, die genau das dachten, aber nicht verstanden haben, das Programmieren eher wie eine Fremdsprache ist. Kannst du nicht die Vokabeln und hast keine Ahnung von Syntax, nützt dir das beste Theorem zur Beschreibung des Problems exakt null komme nix. Ja, es gibt Probleme, die sind mathematischer Natur, aber es gibt auch eine Unmenge an Herausforderungen im Alltag eines Programmierer, die viel mehr mit der Arbeit eines guten Übersetzers zu tun haben. Daher ist die Aussage "alles sind mathematische Operationen" mindestens genauso frei von jedem praktischen Realitätsbezug, wie dies hier dem agilen Manifest so rundheraus unterstellt wird, nur weil es keine konkreten Handlungsanweisungen für die schlauen Mathematiker enthält.

  5. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: /mecki78 01.09.21 - 11:18

    dEEkAy schrieb:
    --------------------------------------------------------------------------------
    > Ich würde ja so gerne clean und agil arbeiten, es wird einem aber nicht
    > ermöglicht.

    Unternehmen wollen immer Ergebnisse sehen und wer schneller Ergebnisse liefert ist in deren Augen ein toller Entwickler. Der Punkt ist, ich habe "schneller" gesagt, nicht "besser".

    Aus meiner Sicht entsteht der sauberste Code durch TDD (Test Driven Development). Zuerst einmal überlegt man sich, welches Ziel man erreichen will. Dann schreibt man Tests, die nur dann erfolgreich sein werden, wenn man dieses Ziel erreicht hat und dann schreibt man den Code und zwar nur gerade genau so viel Code wie nötig ist, dass alle Tests erfolgreich durchlaufen und wenn sie das tun, dann hat man das definierte Ziel erreicht und das Spiel geht von vorne los mit dem nächsten Ziel.

    TDD verhindert dass man mehr Code schreibt als nötig (also über das Ziel hinaus schießt), es verhindert das man Code schreibt, der das Ziel nicht erreichen wird (weil man immer ganz gezielt auf das Ziel zusteuert) und es verhindert, das man nicht testbaren Code schreibt (weil die Testbarkeit durch den Test bereits vorgegeben ist).

    Das Problem ist: Wenn ich erst einmal nur Tests schreibe, die am Anfang auch alle fehlschlagen werden, weil es den Code noch nicht gibt der nötig ist, damit sie es nicht tun, dann habe ich nichts vorzuweisen. Die Tests sieht man nicht im fertigen Produkt, ein Fortschritt ist durch die Tests nicht erkennbar. In der gleichen Zeit schreibt jemand anderes den eigentlichen Code, der zwar komplett ungetestet, ggf. sogar untestbar ist, aber er hat eben was vorzuweisen. Seine Arbeit ist also Hui, meine ist Pfui.

    Dass seine Arbeit dem Unternehmen langfristig mehr Geld kosten wird, das wird nicht gesehen, denn Manager sind extrem kurzsichtig. Das liegt nicht zuletzt daran, dass Probleme ggf. erst auftreten, nachdem der Manager schon lange woanders arbeitet und daher nicht seine Problem sein werden. Der Manager schaut auf seine Karriere, nicht auf das Wohl seines Arbeitgebers, weil den kann man jederzeit wechseln. Er muss also Erfolge vorweisen und das am besten gestern. Und "wir schreiben Code, der auch in 10 Jahren noch brauchbar sein wird" ist kein Erfolg. "Wir haben das Feature in 2 Wochen fertig bekommen" ist ein Erfolg und nach dem "wie" fragt keine Sau.

    > Also schludert man halt die dirty Variante hin, die nächste
    > Deadline steht eh schon und der Code muss in x Tagen raus, komme was
    > wolle.

    Auch hier gibt es IMHO nur einen sinnvollen Ansatz: Rapid Prototyping.

    Rapid Prototyping heißt, man entwickelt kein fertiges Produkt, man entwickelt immer nur einen Prototyp, der aber immer Release-Qualität aufweist. Der wird dann begutachtet und entweder weiter entwickelt oder man entscheidet, dass er gut genug ist und der nächste Release wird. Man verbessert das Produkt also iterativ in kleinen Schritten (SCRUM nennt das Sprints, aber von SCRUM halte ich gar nichts, wie man vielleicht schon gemerkt hat).

    In jeder Iteration hat das Management immer die Wahl zwischen zwei Optionen:

    1) Der nächste Prototyp wird einen vorgegebenen Featureumfang aufweisen. Dann aber darf das Management keine zeitliche Deadline vorgeben. Die Entwickler können nicht sagen wie lange es dauern wird (bestenfalls sehr grob), aber sie garantieren den gewünschten Featureumfang. Dauert es dem Management zu lange, dann können sie die Entwicklung jederzeit stoppen, sie müssen sich nur im klaren sein, dass es nicht so lange dauert, weil Entwickler zu langsam arbeiten, sondern weil sie einen zu großen Featureumfang oder zu teurer Features gefordert haben!

    2) Der nächste Prototyp wird zu einem vorgegebenen Zeitpunkt fertig werden. Dann aber darf das Management keinen Featureumfang voraussetzen. Die Entwickler können nicht sagen, wie viele der ganzen Features sie in der vorgegebenen Zeit schaffen werden. Sie garantieren nur, dass zum vorgegebenen Zeitpunkt ein releasebarer Prototyp vorliegt und der wird so viele Features enthalten, wie in der Zeit machbar war. Reicht dass dem Management nicht, dann muss das Management eben mehr Zeit zu Verfügung stellen für mehr Features.

    Entweder oder. Das Management kann die Zeit oder den Featureumfang vorgeben, aber nicht beides! Das ist die Heisenbergsche Unschärferelation der Software Entwicklung.

    Das verstehen aber Manager genauso wenig und bilden sich ein, sie können sagen "das und das und das Feature muss bis dann fertig sein" und das funktioniert nur wenn man irgendwo/irgendwann anfängt Abstriche in der Qualität zu machen. Also leidet die Codequalität oder es fehlen Tests und beides wird sich langfristig ganz böse rächen.

    /Mecki

  6. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: /mecki78 01.09.21 - 11:21

    LeeRoyWyt schrieb:
    --------------------------------------------------------------------------------
    > Ja, es gibt Probleme, die sind mathematischer Natur, aber es gibt auch eine
    > Unmenge an Herausforderungen im Alltag eines Programmierer, die viel mehr
    > mit der Arbeit eines guten Übersetzers zu tun haben.

    Deswegen habe ich ja auch drei Punkte genannt und Mathe war nur einer davon.

    /Mecki

  7. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: /mecki78 01.09.21 - 11:23

    notuf schrieb:
    --------------------------------------------------------------------------------
    > Ob agile funktioniert oder nicht, damit befassen
    > sich Universitäten.

    Und genau die haben den von mir genannten Test bzgl. der Teamgröße gemacht in Rahmen einer Studie zu diesem Thema. Ich habe nur leider den Link nicht gespeichert und konnte auf die Schnelle keine Referenz zu der Studie finden (wobei ich zugebe, dass ich das auch nur ca. 5 Minuten lang versucht habe).

    /Mecki

  8. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: /mecki78 01.09.21 - 12:02

    ubuntu_user schrieb:
    --------------------------------------------------------------------------------
    > eine große Armee zu führen ist genauso einfach wie eine kleine, es ist
    > lediglich eine Organisierungssache

    Darum geht es nicht. Mit Führung hat es nichts zu tun.

    > Man muss ja auch gucken was man parallelisieren kann. Wenn alle
    > frontend-entwickler warten bis das backend fertig ist, bringen mehr
    > frontend-entwickler ja auch nichts...

    Auch das ist nicht das Problem.

    Das Problem ist, dass wenn die Arbeitsleistung eines Entwicklers alleine 100% ist (Basislinie), dann ist diese Arbeitsleistung nur noch 90%, wenn er in einem Team mit 4 Leuten arbeitet. Selbst bei perfekter Organisation ist das so. Und wenn das Team 8 Leute hat, dann ist sie vielleicht nur noch 80%.

    Die konkreten Zahlen oben habe ich frei erfunden, ich weiß nicht genau wie stark der Abfall ist, aber dazu gibt es sehr detaillierte Studien. Die Gründe dafür liegen in der Psychologie. Als Teil eines Teams fahren Menschen automatisch ihre Arbeitsleistung zurück, da es in einem Team ja nicht mehr so sehr auf den einzelnen ankommt und die Einzelleistung in der Teamleistung aufgeht.

    Und das hat nichts mit Softwareenwicklung zu tun. Lass 3 Leute Erde mit Schaufeln und Schubkarren von A nach B transportieren. Dann lass 6 Leute das gleiche tun. Achte dabei genau wie viel Erde jeder einzelne bewegt hat und du wirst sehen, bei 6 Leuten ist es weniger pro Kopf.

    Das kennt man auch aus dem Sport. Zwei Fußballteams stehen sich gegenüber, beide in etwa gleich stark. Nachdem alle Wechsel durch sind, fällt in einem Team ein Spieler wegen Verletzung aus und ein anderer bekommt einer rote Karte. Auf einmal heißt es 11 gegen 9. Das Team mit 9 sollte jetzt hoffnungslos unterlegen sein, muss es aber nicht. Manchmal gewinnt sogar das kleinere Team dann am Ende. Und wenn man fragt wie das möglich ist, dann heißt es "Um die Ausfälle zu kompensieren, haben wir eben 110% gegeben", aber das ist quatsch, kein Mensch kann mehr als 100% leisten. Faktisch haben sie vorher eben nur 70% gegeben und jetzt wo das Team kleiner geworden ist und es auf die Leistung des einzelnen mehr ankam, da haben sie dann eben 90% gegeben und konnten somit den Leistungswegfall kompensieren.

    Menschen sind von Natur aus faul. In der Biologie leistet kein Lebewesen mehr als es leisten muss, denn das wäre Energieverschwendung. Also taxieren Lebewesen immer wie viel Leistung wirklich nötig ist und fahren ihren Einsatz zurück, wenn sie der Meinung sind, dass problemlos tun zu können, ohne ihr angestrebtes Ziel zu gefährden.

    Eine Variation davon ist: Zeitfenster werden fast immer aufgebraucht. Sage ich dir, du sollst etwas machen, ohne dir ein Zeitfenster vorzugeben, dann brauchst du vielleicht 3 Tage. Angenommen, ich hätte dir aber gesagt, du musst das in 6 Tagen fertig sein, wie lange hättest du dann gebraucht? 3 Tage? Die meisten Menschen hätten dann 6 Tage gebraucht oder zumindest 5. Denn auch hier gilt: Sobald die Menschen sehen, dass sie das locker im Zeitfenster schaffen, fahren sie ihre Arbeitsleistung zurück, wenn sie keinen Vorteil davon haben, früher fertig zu werden.

    /Mecki

  9. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: /mecki78 01.09.21 - 12:09

    dEEkAy schrieb:
    --------------------------------------------------------------------------------
    > Gefixt wird später, später kommt aber nie.

    Unit Tests werden auch später geschrieben.
    Der Code wird auch später aufgeräumt.
    Und optimieren kann man ja auch später noch.

    Und wenn man fragt, wann genau später ist, dann heißt es "Wenn wir dafür Zeit haben".

    Nur warum sollten wir jemals dafür Zeit haben? Was genau für ein Zeitpunkt soll das denn sein, wo man keine neuen Features mehr braucht und es keinen Grund mehr gibt was neues zu releasen? Wenn man mal so viel Geld verdient hat, dass man nicht mehr weiß wohin damit? Als ob das jemals eintreffen würde und selbst wenn es eintrifft, egal wie viel Geld man schon verdient hat, man wird immer mehr verdienen wollen.

    /Mecki

  10. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: ubuntu_user 01.09.21 - 15:20

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ist, dass wenn die Arbeitsleistung eines Entwicklers alleine
    > 100% ist (Basislinie), dann ist diese Arbeitsleistung nur noch 90%, wenn er
    > in einem Team mit 4 Leuten arbeitet. Selbst bei perfekter Organisation ist
    > das so. Und wenn das Team 8 Leute hat, dann ist sie vielleicht nur noch
    > 80%.
    >
    > Die konkreten Zahlen oben habe ich frei erfunden, ich weiß nicht genau wie
    > stark der Abfall ist, aber dazu gibt es sehr detaillierte Studien. Die
    > Gründe dafür liegen in der Psychologie. Als Teil eines Teams fahren
    > Menschen automatisch ihre Arbeitsleistung zurück, da es in einem Team ja
    > nicht mehr so sehr auf den einzelnen ankommt und die Einzelleistung in der
    > Teamleistung aufgeht.

    ja ist okay mit den Zahlen.
    Idealerweise sagst du dann aber du machst den Abschnitt und du den. Und wenn man merkt dass das nicht geht, sollte man eben weniger Leute dran setzen und die Leute was anderes machen lassen. Meistens würde das ja gehen

  11. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: Trockenobst 01.09.21 - 19:17

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das Problem ist: Wenn ich erst einmal nur Tests schreibe, die am Anfang
    > auch alle fehlschlagen werden, weil es den Code noch nicht gibt der nötig
    > ist, damit sie es nicht tun, dann habe ich nichts vorzuweisen.

    Genau aus dem Grund muss man IMHO etwas andere Wege gehen. Während es schon Traktoren mit GPS Steuerung gibt wo man nur noch den Start Knopf drückt und das Ding Stunden seine perfekten Runden dreht, ist Entwickeln trotz moderner Stacks immer noch eine Menge Handarbeit.

    Die Kollegen sitzen an einem Finanzprodukt, da wird für CRUD Operationen nun 70% Code Generierung genutzt. Da gibt es ein Modell, die Tabellen und eben die Tests. Fixes gibt es nur am Generator. Die anderen 30% sind der wirkliche Business Case. Einige Workflows haben 30-40 Schritte mit komplexen juristischen Vorgaben. Sehr viel Transparenz ist notwendig. Auch da wird sehr viel vom Modell zur Gui generiert. Man braucht die eine Wahrheit, nicht die Interpretation der Wahrheit auf vielen Schichten. Das klappt einfach nicht mehr.

    Die alte Plattform hat von Datenobjekt zur Webgui 10 Schichten. Die neue nur 4. Die alte Plattform ist praktisch unwartbar geworden, nach vier Teams und komplett neuen Chefs.

    > zuletzt daran, dass Probleme ggf. erst auftreten, nachdem der Manager schon
    > lange woanders arbeitet und daher nicht seine Problem sein werden

    Der Manager mag so denken, aber seine Chefs die vielleicht auch Anteile am Unternehmen haben, eigentlich nicht. Z.B. haben sie jetzt beim großen IT Supporter 5 Top Admins mit entsprechenden Gehältern eingestellt. Diese sollen in Zukunft 80% der Basis-Unix-Distributionen für bestimmte Projekte liefern. Nach über 10 Jahren haben sie einfach eingesehen, dass dieses "jede Abteilung kämpft für sich" einfach nicht mehr läuft.

    >einen sinnvollen Ansatz: Rapid Prototyping.

    Das ist der einzige Ansatz der bei unscharfen, vielmoduligen Projekten überhaupt noch funktioniert. Und trotzdem sehen viele den Sinn immer noch nicht.

    Bei langfristige Projekten mit 100 Leuten und gewissen Deadlines war es schon Normal, dass man sich alle sechs Monate zusammensetzt und darüber diskutiert ob man noch das Geld für das Feature ausgibt oder lieber die Konventionalstrafe runter diskutieren kann. Als Freelancer kann ich darüber lachen wenn sie mir mal wieder freies Budget geben, aber ich merke zunehmend das die selbst erkennen wie Kacke das ist. Prototypen in Node oder PHP sind stark im kommen. Schauen wir doch erst mal was wir wirklich wollen. Gute Entwicklung.

    Inzwischen gibt es bei einigen DAX Firmen z.B. die Pflicht, bei bestimmten Themen wie Security und Datenmodellierung mit einer Kerngruppe zu sprechen und welche vorgegeben Stacks es schon gibt. Die sind in einem Fall aus allen Wolken gefallen als sie gemerkt haben dass ein Millionenbetrag für einen Clon ausgegeben worden ist weil ein Projekt sich geweigert hat PDF Reports einzubauen. Am Ende war es übliches Organigramm Mobbing. Da hat dann der Chef mit dem Aktienpaket gesagt, das nächste Mal hagelt es nicht blaue Briefe sondern Kündigungen.

  12. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: Daniel-Son 03.09.21 - 07:30

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > dEEkAy schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich würde ja so gerne clean und agil arbeiten, es wird einem aber nicht
    > > ermöglicht.
    >
    > Unternehmen wollen immer Ergebnisse sehen und wer schneller Ergebnisse
    > liefert ist in deren Augen ein toller Entwickler. Der Punkt ist, ich habe
    > "schneller" gesagt, nicht "besser".
    >
    > Aus meiner Sicht entsteht der sauberste Code durch TDD (Test Driven
    > Development). Zuerst einmal überlegt man sich, welches Ziel man erreichen
    > will. Dann schreibt man Tests, die nur dann erfolgreich sein werden, wenn
    > man dieses Ziel erreicht hat und dann schreibt man den Code und zwar nur
    > gerade genau so viel Code wie nötig ist, dass alle Tests erfolgreich
    > durchlaufen und wenn sie das tun, dann hat man das definierte Ziel erreicht
    > und das Spiel geht von vorne los mit dem nächsten Ziel.
    >
    > TDD verhindert dass man mehr Code schreibt als nötig (also über das Ziel
    > hinaus schießt), es verhindert das man Code schreibt, der das Ziel nicht
    > erreichen wird (weil man immer ganz gezielt auf das Ziel zusteuert) und es
    > verhindert, das man nicht testbaren Code schreibt (weil die Testbarkeit
    > durch den Test bereits vorgegeben ist).
    >
    > Das Problem ist: Wenn ich erst einmal nur Tests schreibe, die am Anfang
    > auch alle fehlschlagen werden, weil es den Code noch nicht gibt der nötig
    > ist, damit sie es nicht tun, dann habe ich nichts vorzuweisen. Die Tests
    > sieht man nicht im fertigen Produkt, ein Fortschritt ist durch die Tests
    > nicht erkennbar. In der gleichen Zeit schreibt jemand anderes den
    > eigentlichen Code, der zwar komplett ungetestet, ggf. sogar untestbar ist,
    > aber er hat eben was vorzuweisen. Seine Arbeit ist also Hui, meine ist
    > Pfui.
    >
    > Dass seine Arbeit dem Unternehmen langfristig mehr Geld kosten wird, das
    > wird nicht gesehen, denn Manager sind extrem kurzsichtig. Das liegt nicht
    > zuletzt daran, dass Probleme ggf. erst auftreten, nachdem der Manager schon
    > lange woanders arbeitet und daher nicht seine Problem sein werden. Der
    > Manager schaut auf seine Karriere, nicht auf das Wohl seines Arbeitgebers,
    > weil den kann man jederzeit wechseln. Er muss also Erfolge vorweisen und
    > das am besten gestern. Und "wir schreiben Code, der auch in 10 Jahren noch
    > brauchbar sein wird" ist kein Erfolg. "Wir haben das Feature in 2 Wochen
    > fertig bekommen" ist ein Erfolg und nach dem "wie" fragt keine Sau.
    >
    > > Also schludert man halt die dirty Variante hin, die nächste
    > > Deadline steht eh schon und der Code muss in x Tagen raus, komme was
    > > wolle.
    >
    > Auch hier gibt es IMHO nur einen sinnvollen Ansatz: Rapid Prototyping.
    >
    > Rapid Prototyping heißt, man entwickelt kein fertiges Produkt, man
    > entwickelt immer nur einen Prototyp, der aber immer Release-Qualität
    > aufweist. Der wird dann begutachtet und entweder weiter entwickelt oder man
    > entscheidet, dass er gut genug ist und der nächste Release wird. Man
    > verbessert das Produkt also iterativ in kleinen Schritten (SCRUM nennt das
    > Sprints, aber von SCRUM halte ich gar nichts, wie man vielleicht schon
    > gemerkt hat).
    >
    > In jeder Iteration hat das Management immer die Wahl zwischen zwei
    > Optionen:
    >
    > 1) Der nächste Prototyp wird einen vorgegebenen Featureumfang aufweisen.
    > Dann aber darf das Management keine zeitliche Deadline vorgeben. Die
    > Entwickler können nicht sagen wie lange es dauern wird (bestenfalls sehr
    > grob), aber sie garantieren den gewünschten Featureumfang. Dauert es dem
    > Management zu lange, dann können sie die Entwicklung jederzeit stoppen, sie
    > müssen sich nur im klaren sein, dass es nicht so lange dauert, weil
    > Entwickler zu langsam arbeiten, sondern weil sie einen zu großen
    > Featureumfang oder zu teurer Features gefordert haben!
    >
    > 2) Der nächste Prototyp wird zu einem vorgegebenen Zeitpunkt fertig werden.
    > Dann aber darf das Management keinen Featureumfang voraussetzen. Die
    > Entwickler können nicht sagen, wie viele der ganzen Features sie in der
    > vorgegebenen Zeit schaffen werden. Sie garantieren nur, dass zum
    > vorgegebenen Zeitpunkt ein releasebarer Prototyp vorliegt und der wird so
    > viele Features enthalten, wie in der Zeit machbar war. Reicht dass dem
    > Management nicht, dann muss das Management eben mehr Zeit zu Verfügung
    > stellen für mehr Features.
    >
    > Entweder oder. Das Management kann die Zeit oder den Featureumfang
    > vorgeben, aber nicht beides! Das ist die Heisenbergsche Unschärferelation
    > der Software Entwicklung.
    >
    > Das verstehen aber Manager genauso wenig und bilden sich ein, sie können
    > sagen "das und das und das Feature muss bis dann fertig sein" und das
    > funktioniert nur wenn man irgendwo/irgendwann anfängt Abstriche in der
    > Qualität zu machen. Also leidet die Codequalität oder es fehlen Tests und
    > beides wird sich langfristig ganz böse rächen.

    Danke, dass das mal jemand schreibt. Ich bin zwar kein Entwickler aber Software-Tester/Manager und ich finde es immer spannend wie oft diese Rolle in Scrum/Agile vernachlässigt wird bzw. teils in der Form gar nicht berücksichtig wird. So ist es in meiner Firma nun auch, dass ein Tester sich in Scrum selbst erfinden darf und über die elendige Überzeugungsarbeit gegenüber dem Team, PM oder dem Management rede ich mal gar nicht. Testen kostet nur Zeit und Geld, dass am Ende aber releasefähige Sachen rauskommen, die kaum bis gar keinen Supportaufwand erzeugen, sieht natürlich keiner. :)

    Ich habe mir mal den Auszug aus einem Kommentar im Web geborgt und beschreibt das Recht gut: "Allerdings werden sowohl im Agilen Manifest als auch in der Scrum-Beschreibung die Testaktivitäten sowie die Testorganisation vernachlässigt. Es werden zwar die Ansätze des Test Driven Development oder der Continuous Integration empfohlen, doch ein systematisches Testvorgehen wird nicht beschrieben. Die Testaktivitäten und die Testorganisation spielen aber eine entscheidende Rolle für den Erfolg der agilen Methoden."

    In einem großen Projekt hat die Rolle des Testers nur vernünftig Platz gefunden indem wir in einer Ready of Defintion & Done das genau definiert haben. Ich selbst bin kein klassischer Entwickler, was in der Rolle m.M. auch wichtig ist, um einen anderen Blickwinkel zu haben. Btw. kann ich jedem nur nahe legen eine vernünftige Def. of Rdy & Done zu definieren. Und ja es kostet im Vorfeld einiges an Zeit, zahlt sich am Ende dann aber aus, weil für alle Beteiligten genau definiert ist, was wann und wie zu tun ist. Hat uns in einem sehr Feature-Getriebenen Projekt sehr geholfen, zum Ende hin wurde dann aber leider die zu viel investierte Zeit negativ ausgelegt und das Projekt in Frage gestellt, weil es länger gedauert hat, obwohl sowohl die Code- und Produkt-Qualität Top war, was am Ende sehr frustrierend war für das Team. Sehr schade, dass hier das Management nicht den Weitblick hat das zu erkennen.
    Und klar kann jeder jetzt sagen, wir erledigen das mit rein automatisierten Tests usw, aber wer definiert was getestet werden soll!? ;)

    Würde mich mal interessieren, wie ihr so eine Rolle des Testers integriert habt, falls es das in euren Teams überhaupt gibt!?

  13. Re: Agil hatte nie eine konkrete Bedeutung

    Autor: Dakkaron 03.09.21 - 15:48

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Und kein Programmierer sollte jemals den gleichen Code zweimal schreiben
    > müssen, denn wenn es den Code schon gibt, warum nimmt man dann nicht den
    > existierenden Code? Programmierer sollten also immer nur neuen Code
    > schreiben, den es noch nicht gibt, um Probleme zu lösen, für die es nicht
    > schon eine fertige Lösung gibt. Nicht 10%, 100% von dem was ein
    > Programmierer schreibt ist neuer Code, ansonsten hat irgendwer eine der
    > wichtigsten Grundregeln verletzt: DRY! Don't Repeat Yourself!

    Da kommt der 2. agile Leitsatz zur Hilfe:

    > Funktionierende Software ist wichtiger als umfassende Dokumentationen

    Das führt dann dazu, dass man als Entwickler, besonders wenn man eine Technologie neu verwenden soll (eine Library, ein neues Projekt, ...), erst mal graben und ausprobieren darf, weil es keine Dokumentation gibt. "Der Code ist ja selbst-dokumentierend."
    Und damit hat man einfach direkt doppelten Code und Mist, weil sich keiner die Mühe gemacht hat, eine halbwegs intelligente Anleitung zu schreiben.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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. (Senior) Android Software Engineer*
    IAV GmbH, Berlin, Gifhorn
  2. Android-Entwickler (m/w/d) - Connected Car
    e.solutions GmbH, Ingolstadt
  3. Manager Informationssicherheit / Datenschutz Erzeugung (w/m/d)
    EnBW Energie Baden-Württemberg AG, Stuttgart
  4. IT-Professional / Bioinformatiker (m/w/d)
    Bayerisches Landeskriminalamt, München

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 12,49€
  2. 1.000€ MMOGA-Gutschein gewinnen
  3. 4,89€


Haben wir etwas übersehen?

E-Mail an news@golem.de