Abo
  1. Foren
  2. Kommentare
  3. Wirtschaft
  4. Alle Kommentare zum Artikel
  5. › Agilität: Wenn alle bestimmen, wo…

Codequalität

  1. Thema

Neues Thema Ansicht wechseln


  1. Codequalität

    Autor: Jolla 29.10.18 - 10:39

    Ich bin kein Entwickler, aber beim Lesen des Artikels stellt sich bei mir direkt die Frage, wie das mit der Codequalität bei all der Agilität ist. Klar, man kann das gut machen (in der Theorie). Aber wie ist das in der Praxis unter Berücksichtigung des Faktor Mensch? In wie vielen Fällen bleibt die Codequalität gleich oder wird sogar besser bei den agilen Methoden? Gefühlt würde ich sagen, dass das eher zur Schlamperei verführt.

  2. Re: Codequalität

    Autor: Muhaha 29.10.18 - 10:50

    Jolla schrieb:
    --------------------------------------------------------------------------------
    > Ich bin kein Entwickler, aber beim Lesen des Artikels stellt sich bei mir
    > direkt die Frage, wie das mit der Codequalität bei all der Agilität ist.

    Ist genauso gut oder schlecht wie bei anderen Projekt-Methoden

    > Klar, man kann das gut machen (in der Theorie). Aber wie ist das in der
    > Praxis unter Berücksichtigung des Faktor Mensch?

    Nicht jeder kann agile, nicht jeder will agile. Wenn Du Agile Methoden verwenden willst, musst Du entsprechend dafür geeignete Teams haben, die dieses Prinzip auch leben wollen. Entwickler, die einfach wie gewohnt stur nach Projektplan abarbeiten wollen, die keine Lust haben mit anderen Menschen zu kommunizieren, sind dafür wenig geeignet, bzw. dürfen in solchen Teams keine leitenden Positionen einnehmen, dürfen nur ausführen.

    Wenn man das nicht berücksichtigt, verursachen Scrum und Co. nur Chaos, Unruhe, miesen Code und Stress für alle Beteiligten. Agile Methoden sind daher kein simples Allheilmittel, welches man einfach der gesamten Entwicklungsabteilung von oben verordnen kann. Man muss schon wissen, was man da tut.

  3. Re: Codequalität

    Autor: Trockenobst 29.10.18 - 10:56

    Jolla schrieb:
    --------------------------------------------------------------------------------
    > Praxis unter Berücksichtigung des Faktor Mensch? In wie vielen Fällen
    > bleibt die Codequalität gleich oder wird sogar besser bei den agilen
    > Methoden? Gefühlt würde ich sagen, dass das eher zur Schlamperei verführt.

    Der Kunde hat wirre Vorstellungen und diese werden Codifiziert, von Story zu Story. Man macht vielleicht hier und da verbesserungen, Code-Rewrites etc. Aber irgendwann reicht man zu einem Punkt wo man die Engine neu schreiben muss. IE -> Edge, Mozilla Browser in Rust etc.

    Die meisten Kunden wollen das selten bezahlen, also wird das Produkt - wenn man Glück hat - 5-10 Jahre im Markt gehalten, die Keyentwickler gut bezahlt damit sie bleiben. Und dann mit einem großen Tamtam Geld besorgt und einfach komplett neu geschrieben.

    Ich habe SAP Projekte mit allen Varianten der Projektführung mitbekommen, das Ging so: Cobol Dialekt, Java, dann C# Bridge (FÜRCHTERLICH) jetzt wieder Java. Alle 5 Jahre werden ca. 100 Funktionen der Abrechnung im medizinschen Bereich neu entwickelt, jetzt mit Cloud. Die Abhängigkeiten der Module von Konfigurationen; Rechtlichen und Fachlichen Weiterentwicklungen sind so schlimm, dass das anbasteln an alten Code keinen Sinn macht.

    Bezahlt wird das aber eben nur Strategisch. Es ist ganz selten dass man Storypoints dafür bekommt, große Module zu ändern. Das muss man manchmal hintricksen, in dem man viele unoffensichtliche Bugs nicht fix und es dann dem Kunden beim Integrationstest auf die Füsse fällt, aber diese Art der schweinepriestigen Projektführung lehne ich ab.

    Auch im Wasserfall bekommt man für fehlgeplante Codebase kein Geld. Ist ja schon vor Wochen im Konzept geklärt dass man das nicht machen muss.

  4. Re: Codequalität

    Autor: Klausens 29.10.18 - 11:01

    Gibt beide Effekte.
    Auf der einen Seite kann mehr Schlamperei entstehen.
    Oder auch ganz ohne gewollt schlampen zu wollen: Keine Ahnung was zum Schluss aus dem Code eigentlich werden soll.

    Auf der anderen Seite ist man bei Agil viel mehr gezwungen den Brocken Arbeit in kleine überschaubare, abgeschlossene Bröckchen aufzuteilen, was wiederum gut für die Codequalität ist.
    Auch die Gewissheit, dass die Codestelle, die man gerade schreibt beim nächsten Mal wahrscheinlich ein ganz anderer in den Händen hat motiviert einen, was halbwegs vernünftiges zu hinterlassen.



    1 mal bearbeitet, zuletzt am 29.10.18 11:05 durch Klausens.

  5. Re: Codequalität

    Autor: ubuntu_user 29.10.18 - 11:12

    Trockenobst schrieb:
    > Der Kunde hat wirre Vorstellungen und diese werden Codifiziert, von Story
    > zu Story.

    > Auch im Wasserfall bekommt man für fehlgeplante Codebase kein Geld. Ist ja
    > schon vor Wochen im Konzept geklärt dass man das nicht machen muss.

    naja im Prinzip hast du ja zwei Modelle:
    1.) Scrum: Entwurf 1.0 -> Feedback+neue Funktion -> Entwurf 1.1. usw.
    2.) Wasserfall: Langer Enwicklungszyklus

    bei 1.) leidet natürlich die Architektur, wenn der Kunde immer nur stückenweise mit Informationen rauskommt. Außerdem verleitet das dazu eben nur auf business value zu gucken und zu frickeln. bei 2.) hast du dann was, was der Kunde gar nicht wollte, denn er wusste es ja auch nicht und das release verschiebt sich immer weiter nach hinten, während man bei scrum auch schonmal releases mit weniger features machen kann.

    Im Prinzip hängt aber die Codequalität mehr vom Team ab und Designentscheidungen.
    Ich würde z.B. nie mehr eine WPF-Anwendung machen, sondern eigentlich immer web+service. dann hat man auch meistens gleich die mobilen Varianten abgefrühstückt und kann besser Testen.

  6. Re: Codequalität

    Autor: birdy 29.10.18 - 11:53

    Ich schließe mich den Vorschreibern an.
    Die Projektmethode und die Code-Qualität haben nur wenig miteinander zu tun.

    Bei Agilität wird zwar in kleinen Schritten gearbeitet. Was durchaus zu einem "durchwachsenem" Design führen kann. Andererseits wird im agilen Umfeld mehr Wert auf Code Qualität, Refactoring etc. gelegt (Stichwort technical excellence).

    Es kommt auf das Team (und dem Umfeld) an, was dann überwiegt.

  7. Re: Codequalität

    Autor: ubuntu_user 29.10.18 - 12:09

    birdy schrieb:
    --------------------------------------------------------------------------------
    > Bei Agilität wird zwar in kleinen Schritten gearbeitet. Was durchaus zu
    > einem "durchwachsenem" Design führen kann. Andererseits wird im agilen
    > Umfeld mehr Wert auf Code Qualität, Refactoring etc. gelegt (Stichwort
    > technical excellence).

    würde ich nicht zwingend sagen.
    ich würde eher sagen, dass weniger entwickelt wird, was der Kunde nicht braucht

  8. Re: Codequalität

    Autor: MickeyKay 29.10.18 - 12:47

    Jolla schrieb:
    --------------------------------------------------------------------------------
    > Ich bin kein Entwickler, aber beim Lesen des Artikels stellt sich bei mir
    > direkt die Frage, wie das mit der Codequalität bei all der Agilität ist.
    Das Team erarbeitet ganz zu Anfang (wenn man mit Scrum anfängt) u.a. die sogenannten "Definition of Done" (DoD). Hier wird beschrieben, welche Kriterien erfüllt sein müssen, damit eine Story am Ende des Sprint als fertig angesehen werden kann. Im Normalfall würde ich hier erwarten (und unsere Teams machen das auch so), dass Codequalität und durchgeführte Code-Reviews durch andere Entwickler des Teams hier einen festen Platz haben.
    Bei uns läuft das sogar soweit, dass ein Entwickler seinen Code nicht einmal in GIT einreichen kann, wenn die Unittests nicht oder mit weniger als 100% Abdeckung durchlaufen. Würde er es können, würde er damit die Arbeit der anderen Kollegen direkt sabotieren, da sich diese nun mit seinem schlechten Code rumschlagen müssen.
    So gesehen hat die Agilität in unserem Unternehmen die Code-Qualität sogar stark verbessert (auch wenn hier noch viel zu tun ist, denn die Qualität wird im Schnitt nur so gut, wie es die Kenntnisse der Reviewer erlauben).

  9. Re: Codequalität

    Autor: birdy 29.10.18 - 13:10

    MickeyKay schrieb:
    --------------------------------------------------------------------------------
    > Jolla schrieb:
    > Das Team erarbeitet ganz zu Anfang (wenn man mit Scrum anfängt) u.a. die
    > sogenannten "Definition of Done" (DoD).

    Im Idealfall ja. In der Praxis aber wird DoD entweder gar nicht erstellt. Oder aber es wird ignoriert.

    > Bei uns läuft das sogar soweit, dass ein Entwickler seinen Code nicht
    > einmal in GIT einreichen kann, wenn die Unittests nicht oder mit weniger
    > als 100% Abdeckung durchlaufen. Würde er es können, würde er damit die
    > Arbeit der anderen Kollegen direkt sabotieren, da sich diese nun mit seinem
    > schlechten Code rumschlagen müssen.
    > So gesehen hat die Agilität in unserem Unternehmen die Code-Qualität sogar
    > stark verbessert (auch wenn hier noch viel zu tun ist, denn die Qualität
    > wird im Schnitt nur so gut, wie es die Kenntnisse der Reviewer erlauben).

    Wobei aber Continuous Delivery bzw. Pull-/Merge- Requests auf bei einem Nicht-Agilen Prozess verwednet werden können. Und auch dort seine Vorteile ausspielen würde.

  10. Re: Codequalität

    Autor: mnementh 29.10.18 - 14:01

    Muhaha schrieb:
    --------------------------------------------------------------------------------
    > Jolla schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich bin kein Entwickler, aber beim Lesen des Artikels stellt sich bei
    > mir
    > > direkt die Frage, wie das mit der Codequalität bei all der Agilität ist.
    >
    > Ist genauso gut oder schlecht wie bei anderen Projekt-Methoden
    >
    > > Klar, man kann das gut machen (in der Theorie). Aber wie ist das in der
    > > Praxis unter Berücksichtigung des Faktor Mensch?
    >
    > Nicht jeder kann agile, nicht jeder will agile. Wenn Du Agile Methoden
    > verwenden willst, musst Du entsprechend dafür geeignete Teams haben, die
    > dieses Prinzip auch leben wollen. Entwickler, die einfach wie gewohnt stur
    > nach Projektplan abarbeiten wollen, die keine Lust haben mit anderen
    > Menschen zu kommunizieren, sind dafür wenig geeignet, bzw. dürfen in
    > solchen Teams keine leitenden Positionen einnehmen, dürfen nur ausführen.
    >
    > Wenn man das nicht berücksichtigt, verursachen Scrum und Co. nur Chaos,
    > Unruhe, miesen Code und Stress für alle Beteiligten. Agile Methoden sind
    > daher kein simples Allheilmittel, welches man einfach der gesamten
    > Entwicklungsabteilung von oben verordnen kann. Man muss schon wissen, was
    > man da tut.
    Japp. Im Endeffekt sind agile Methoden nur ein weiterer Hammer im Werkzeugkasten. Wenn man weiß wie man das Ding verwendet und es für passende Aufgaben einsetzt, dann kann es zu Verbsserungen führen: am Quelltext, bei der Wartbarkeit, bei der Arbeitsplanung. Aber es gilt bei jedem Werkzeug der alte Spruch: 'A fool with a tool is still a fool'.

  11. Re: Codequalität

    Autor: a user 29.10.18 - 14:46

    Jolla schrieb:
    --------------------------------------------------------------------------------
    > Ich bin kein Entwickler, aber beim Lesen des Artikels stellt sich bei mir
    > direkt die Frage, wie das mit der Codequalität bei all der Agilität ist.
    > Klar, man kann das gut machen (in der Theorie). Aber wie ist das in der
    > Praxis unter Berücksichtigung des Faktor Mensch? In wie vielen Fällen
    > bleibt die Codequalität gleich oder wird sogar besser bei den agilen
    > Methoden? Gefühlt würde ich sagen, dass das eher zur Schlamperei verführt.
    Cdoequalität steigt nur, wenn man sich an die agilen Methoden auch konsequen hält.
    Agile Methoden wie Scrum funktionieren nur, wenn man sie strikt einhält. Das agile wird aber gerne von vielen auf die Umsetzung verstanden, aber die ist damit nicht gemeint.

    Scrum als Methodik ist nciht agil und soll es auch nciht sein. Es sorgt aber dafür, dass man agil auf die Kundenwünsche und Ansrpücje reagieren kann.

    Mit strikten regeln schaft man ein agil reagierendes Team.

    Aber es wird gerne agil auf alles angewendet und dann wird das aufwiches der Regeln als "agil" bezeichnet. Das ist einfach nur bullshit.

  12. Re: Codequalität

    Autor: lestard 29.10.18 - 15:42

    Meiner Erfahrung nach ist die Code-Qualität bei Agilen Projekten höher als bei Wasserfalligen.
    Die meisten Entwickler wollen durchaus gute Qualität abliefern. Aber dafür braucht es auch die Zeit, z.B. um noch Refactorings durchzuführen und Code-Reviews abzuhalten usw.
    Bei agilen Projekten kann man sowas leichter einplanen und sich die Zeit dafür nehmen. Bei Wasserfall-Projekten gibts dagegen einen feste Termin, der i.d.R. auch reichlich knapp gewählt wurde. Da wird natürlich als erstes an der Code-Qualität gespart. Das ist zumindest meine Erfahrung.

  13. Re: Codequalität

    Autor: Avalanche 30.10.18 - 10:34

    > Mit strikten regeln schafft man ein agil reagierendes Team.

    Das ist der Kernpunkt: man braucht klar definierte Regeln, die von allen Seiten auch verbindlich eingehalten werden müssen. Auch wenn es paradox klingt: je strikter diese Regeln, um so flexibler kann dann in der Praxis das Gesamtsystem agieren und reagieren (und das ist ja auch das, was man letztendlich in der Praxis auch optimieren sollte).



    1 mal bearbeitet, zuletzt am 30.10.18 10:34 durch Avalanche.

  14. Re: Codequalität

    Autor: MickeyKay 08.11.18 - 16:04

    birdy schrieb:
    --------------------------------------------------------------------------------
    > Im Idealfall ja. In der Praxis aber wird DoD entweder gar nicht erstellt.
    > Oder aber es wird ignoriert.
    Dann wird halt nicht richtig nach Scrum gearbeitet bzw. der Scrum-Master macht einen schlechten Job.
    Das ist aber keine Eigenschaft des Prozesses, wenn die Mitarbeiter sich nicht an selbst aufgestellte Regeln halten.

  1. Thema

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Schaeffler Technologies AG & Co. KG, Nürnberg
  2. MAGELLAN Rechtsanwälte Säugling und Partner mbB, München
  3. MVZ Labor Ludwigsburg GbR, Ludwigsburg
  4. Technische Universität Darmstadt, Darmstadt

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-63%) 16,99€
  2. 3,99€
  3. 4,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Change-Management: Die Zeiten, sie, äh, ändern sich
Change-Management
Die Zeiten, sie, äh, ändern sich

Einen Change zu wollen, gehört heute zum guten Ton in der Unternehmensführung. Doch ein erzwungener Wandel in der Firmenkultur löst oft keine Probleme und schafft sogar neue.
Ein Erfahrungsbericht von Marvin Engel

  1. IT-Jobs Der Amtsschimmel wiehert jetzt agil
  2. MINT Werden Frauen überfördert?
  3. Recruiting Wenn das eigene Wachstum zur Herausforderung wird

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

Alexa: Das allgegenwärtige Ohr Amazons
Alexa
Das allgegenwärtige Ohr Amazons

Die kürzlich angekündigten Echo-Produkte bringen Amazons Sprachassistentin Alexa auf die Straße und damit Datenschutzprobleme in die U-Bahn oder in bisher Alexa-freie Wohnzimmer. Mehrere Landesdatenschutzbeauftragte haben Golem.de erklärt, ob und wie die Geräte eingesetzt werden dürfen.
Von Moritz Tremmel

  1. Digitaler Assistent Amazon bringt neue Funktionen für Alexa
  2. Echo Frames und Echo Loop Amazon zeigt eine Brille und einen Ring mit Alexa
  3. Alexa Answers Nutzer smarter Lautsprecher sollen Alexa Wissen beibringen

  1. BDI: Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre
    BDI
    Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre

    Die deutsche Industrie will keine Vertrauenswürdigkeitserklärung von den 5G-Ausrüstern einholen müssen. Diese Erklärungen seien wirkungslos, gefragt sei dagegen Cyber-Resilienz.

  2. Watch Parties: Twitch ermöglicht Streamern Filmabende mit Followern
    Watch Parties
    Twitch ermöglicht Streamern Filmabende mit Followern

    Gemeinsam im kleinen oder großen Kreis einen Spiefilm oder eine TV-Serie per Streaming anschauen: Das können Influencer künftig auf Twitch - vorerst allerdings nur in den USA.

  3. Smartspeaker: Belauschen mit Alexa- und Google-Home-Apps
    Smartspeaker
    Belauschen mit Alexa- und Google-Home-Apps

    Mit verschiedenen Tricks gelang es Sicherheitsforschern, Apps für Google Home und Amazons Alexa zu erzeugen, die Nutzer belauschen oder Phishingangriffe durchführen. Die Apps überstanden den Review-Prozess von Google und Amazon.


  1. 18:53

  2. 17:38

  3. 17:23

  4. 16:54

  5. 16:39

  6. 15:47

  7. 15:00

  8. 13:27