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

Missverständnisse?

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. Missverständnisse?

    Autor: gochnad 23.05.22 - 13:49

    "Missverständnisse" hab ich wohl auch, die konnte der Artikel leider nicht ausräumen.

    Klar verstehe ich, dass es für den Kundenberater eine ganz tolle Sache ist, wenn er im Verkaufsgespräch zu jeder Frage sagen kann "da müssen wir uns noch gar nicht festlegen, wir arbeiten ja agil".

    Aber jeder der ne Weile in der IT arbeitet, kennt wohl so Projekte, die 20 Jahre im Einsatz sind, wo von 7 Generationen Entwicklern ständig neue Features angeflanscht wurden, nie irgendwelche Altlasten entfernt wurden, so dass ein unentwirrbarer Filz von Code entstanden ist und man sich nicht traut, irgendwo etwas anfassen, weil die Nebenwirkungen unabsehbar sind.
    Man möchte es nur wegwerfen und bei Null starten.

    "Agile" kann man so einen Zustand nun viel schneller hinbekommen. Wenn sich im Laufe des Projektstarts die Prioritäten und Grundannahmen mehrfach verschieben und nachträglich ungeahnte Features gefordert werde, wie sollen dann grundsätzliche Dinge wie die Modellierung der Datenbankstruktur, noch passen?

    Man müsste nach jeder Änderung der Anfordungen eigentlich wieder von vorne beginnen.
    Wenn man das täte, würde agile Software SEHR viel teurer werden, also tut man das natürlich nicht. Folglich wird rumgeflickt und angeflanscht, schließlich ist man ja auch die ganze Zeit am "sprinten", wer hätte da Zeit, irgendwas zu überdenken, das doch "schon fertig" war.
    So hat man den schrecklichen Filz, der sonst 20 Jahre zum Wachsen brauchte, schon nach 8 Monaten.
    Nur dank immer schnellerer Hardware und 3 Lagen Caching, die drübegelegt werden, ist so ein Projekt überhaupt benutzbar. Aber von "gut" kann eigentlich keine Rede sein.
    Und "Spaß" macht das auch nur der ersten Generation von Codern, die Sprint für Sprint Todos abhaken und Erfolgserlebnisse haben.
    Wer da später einzelne Bugs finden und fixen muss, wird kaum froh werden.

    Im Artikel steht was von "immer komplexeren Problemen". Mag sein.
    Aber ist es wirklich schlau, wenn man ein Teil der Komplexizität einfach ignoriert, um schnell "was zu haben, das schon Mal irgendwas macht"?
    Beispielsweise Datenschutz, also zb unterschiedliche Rollen und Zugrifssrechte auf Daten: wenn man das nicht von vorne herein andenkt, sondern irgendwann später nachträglich einbauen will, wird das Gefrickel. "Fehlerfrei" ensteht so wohl kaum ...

  2. Re: Missverständnisse?

    Autor: egal1234 23.05.22 - 13:55

    gochnad schrieb:
    --------------------------------------------------------------------------------
    > "Missverständnisse" hab ich wohl auch, die konnte der Artikel leider nicht
    > ausräumen.
    >
    > Klar verstehe ich, dass es für den Kundenberater eine ganz tolle Sache ist,
    > wenn er im Verkaufsgespräch zu jeder Frage sagen kann "da müssen wir uns
    > noch gar nicht festlegen, wir arbeiten ja agil".
    >
    > Aber jeder der ne Weile in der IT arbeitet, kennt wohl so Projekte, die 20
    > Jahre im Einsatz sind, wo von 7 Generationen Entwicklern ständig neue
    > Features angeflanscht wurden, nie irgendwelche Altlasten entfernt wurden,
    > so dass ein unentwirrbarer Filz von Code entstanden ist und man sich nicht
    > traut, irgendwo etwas anfassen, weil die Nebenwirkungen unabsehbar sind.
    > Man möchte es nur wegwerfen und bei Null starten.
    >
    > "Agile" kann man so einen Zustand nun viel schneller hinbekommen. Wenn sich
    > im Laufe des Projektstarts die Prioritäten und Grundannahmen mehrfach
    > verschieben und nachträglich ungeahnte Features gefordert werde, wie sollen
    > dann grundsätzliche Dinge wie die Modellierung der Datenbankstruktur, noch
    > passen?
    >
    > Man müsste nach jeder Änderung der Anfordungen eigentlich wieder von vorne
    > beginnen.
    > Wenn man das täte, würde agile Software SEHR viel teurer werden, also tut
    > man das natürlich nicht. Folglich wird rumgeflickt und angeflanscht,
    > schließlich ist man ja auch die ganze Zeit am "sprinten", wer hätte da
    > Zeit, irgendwas zu überdenken, das doch "schon fertig" war.
    > So hat man den schrecklichen Filz, der sonst 20 Jahre zum Wachsen brauchte,
    > schon nach 8 Monaten.
    > Nur dank immer schnellerer Hardware und 3 Lagen Caching, die drübegelegt
    > werden, ist so ein Projekt überhaupt benutzbar. Aber von "gut" kann
    > eigentlich keine Rede sein.
    > Und "Spaß" macht das auch nur der ersten Generation von Codern, die Sprint
    > für Sprint Todos abhaken und Erfolgserlebnisse haben.
    > Wer da später einzelne Bugs finden und fixen muss, wird kaum froh werden.
    >
    > Im Artikel steht was von "immer komplexeren Problemen". Mag sein.
    > Aber ist es wirklich schlau, wenn man ein Teil der Komplexizität einfach
    > ignoriert, um schnell "was zu haben, das schon Mal irgendwas macht"?
    > Beispielsweise Datenschutz, also zb unterschiedliche Rollen und
    > Zugrifssrechte auf Daten: wenn man das nicht von vorne herein andenkt,
    > sondern irgendwann später nachträglich einbauen will, wird das Gefrickel.
    > "Fehlerfrei" ensteht so wohl kaum ...


    problematisch finde ich auch, dass man refactoring/Sachen richtig machen quasi im Nachteil ist. Es kann dann immer jemandem im Team geben, der das schneller verspricht und man dann Tests + Refactoring weglässt.
    auch gibts dann wenig struktur. Wenn dann das feature gearde ein anderer Entwickler implementiert, sieht das dementsprechend anders aus. Statisch oder dynamisch gelinkt? entscheidet derjenige der es gearde implementiert. Kennt dann ggf. ja die anderen projekte nicht.
    oder er macht was mit dlopen... oder man flanscht das woanders dran. ist man meistens dann sogar noch schneller fertig.

  3. Re: Missverständnisse?

    Autor: /mecki78 23.05.22 - 13:57

    gochnad schrieb:
    --------------------------------------------------------------------------------
    > Aber jeder der ne Weile in der IT arbeitet, kennt wohl so Projekte, die 20
    > Jahre im Einsatz sind, wo von 7 Generationen Entwicklern ständig neue
    > Features angeflanscht wurden, nie irgendwelche Altlasten entfernt wurden,
    > so dass ein unentwirrbarer Filz von Code entstanden ist und man sich nicht
    > traut, irgendwo etwas anfassen, weil die Nebenwirkungen unabsehbar sind.
    > Man möchte es nur wegwerfen und bei Null starten.
    >
    > "Agile" kann man so einen Zustand nun viel schneller hinbekommen.

    Eben nicht, denn echte Agile Entwicklung fordert "ständige Refaktorierungen". Das also alter Code nicht über Jahre hinweg nicht angefasst wird gibt es da nicht. Genau dieser Zustand, dass man sich nicht traut etwas anzufassen, soll dadurch vermieden werden. Deswegen auch Unit Tests, die sofort verraten, wenn man beim Umbau oder beim Entfernen von Altlasten etwas gebrochen hat bzw. die einem sofort sagen, dass man eben nichts gebrochen hat. Write once, never touch again ist nicht agil, das ist das genaue Gegenteil von agil und mit einer der Gründe, warum agil überhaupt erschaffen wurde.

    Das ist mit ein Grund dafür, warum SCRUM z.B. keine echte agile Entwicklung ist, weil z.B. genau diese ständige Refaktorisierung nicht vorgesehen ist:

    https://forum.golem.de/kommentare/software-entwicklung/agile-softwareentwicklung-einfach-mal-so-drauflos-programmiert/scrum-ist-verarsche/153302,6254782,6254782,read.html#msg-6254782

    Diese ist aber genauso wichtig wie "Kontinuierliche Integration" , "Continuous Delivery" und alles, wirklich alles testbar zu machen und dann auch wirklich zu testen.

    /Mecki

  4. Re: Missverständnisse?

    Autor: gochnad 23.05.22 - 14:45

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Eben nicht, denn echte Agile Entwicklung fordert "ständige
    > Refaktorierungen". [..] Deswegen auch Unit
    > Tests, die sofort verraten, [..]

    Naja, es gibt Ansätze wie Test driven devlopment, die das fordern.
    Das hat doch wenig damit damit zu tun, ob man nun einem "agilen" Prozess arbeitete, oder die Software erst plant und dann erstellt?



    > Das ist mit ein Grund dafür, warum SCRUM z.B. keine echte agile Entwicklung
    > ist,

    ok, vielleicht ist theoretisches, "echtes" Agiles Arbeiten ja ganz ok.
    Ich kritisiere das real existierende. Und da sieht es oft so aus, dass man schon weiss, was es maximal kosten darf und wann es spätestens fertig sein soll. Aber nach Prioritäten oder Details gefragt, will man sich ganz agil bis kurz vor Schluss nicht festlegen.

    Erschreckend oft habe ich festgestellt, dass wenig Vorstellungskraft besteht (oder auch nur Wille, sich was vorzustellen), wenn man drüber spricht, wie etwas funktionieren wird. Dann heisst es: mach doch mal, dann besprechen wir das.

    Wenn man ständig was programmiert, nur um dann zu erfahren, "ne, so hab ich mir das nicht vorgestellt". Muss es natürlich viel teurer werden, als wenn man es in einem Gespräch vorab herausgefunden hätte.
    Zum Ausgleich wird an anderer Stelle gespart. Refactoring? Wieso, geht doch. Erstmal feature x Implementieren, damit der Kunde die nächste Rechnung bezahlt.

  5. Re: Missverständnisse?

    Autor: egal1234 23.05.22 - 15:11

    gochnad schrieb:
    --------------------------------------------------------------------------------
    > Zum Ausgleich wird an anderer Stelle gespart. Refactoring? Wieso, geht
    > doch. Erstmal feature x Implementieren, damit der Kunde die nächste
    > Rechnung bezahlt.

    dann spart man sich das refactoring und das management wird belohnt weil man kosten gespart hat

  6. Re: Missverständnisse?

    Autor: /mecki78 23.05.22 - 19:19

    gochnad schrieb:
    --------------------------------------------------------------------------------
    > Naja, es gibt Ansätze wie Test driven devlopment, die das fordern.
    > Das hat doch wenig damit damit zu tun, ob man nun einem "agilen" Prozess
    > arbeitete, oder die Software erst plant und dann erstellt?

    Doch, hat es. Die Idee hinter agil ist, dass du agil bist, daher der Name. Wenn du alles vorher planst und dann den Plan abarbeitest, dann ist dabei nichts agil. Es wird nicht dadurch agil, dass du den Plan in Sprints abarbeitest. Agil heißt du bist flexibel und beweglich, d.h. du planst nicht die komplette Route von Start zum Ziel, sondern du planst immer nur die nächsten paar Schritt, schaust dann an wie weit du gekommen bist und passt dann ggf. die Route an. Das ist die ganze Idee hinter dem agilen Konzept.

    Ich hab das hier mal versucht auf das Mauern einer Mauer zu übertragen:

    https://forum.golem.de/kommentare/software-entwicklung/agile-softwareentwicklung-einfach-mal-so-drauflos-programmiert/scrum-ist-verarsche/153302,6254782,6255125,read.html#msg-6255125

    Zugegeben, der Vergleich hinkt etwas, da man eine Mauer nicht schnell mal refactoren kann, man muss sie abreißen und neu bauen und daher habe ich hier so getan, als ob man die bisherige Mauer einfach so stehen lässt, aber ich denke die Idee ist nachvollziehbar. Und wen du etwas ändern musst, weil du sonst nicht rechtzeitig fertig wirst oder aber das Endergebnis nicht wie gewünscht aussehen wird, dann musst du natürlich meistens auch bereits geschriebenen Code nochmal anfassen.

    Und diese Agilität darf dann auch künftig nicht verloren gehen, denn auch wenn irgendwann mal Version 1.0 draußen ist, dann will man ggf. für 2.0 einige Dinge anders machen als bisher und dann darf Umbauen kein Tabu sein. Es geht eben nicht darum, bloß keinen bisherigen Code noch einmal anzufassen, sondern es geht darum, flexibel zu sein und wenn bisheriger Code anders funktionieren muss, damit bestimmte Features umgesetzt werden können, dann musst du natürlich bisherigen Code nochmal anfassen.

    Natürlich sollst du nicht unnötig Code anfassen müssen, aber dann musst du Code auch so schreiben, dass dies nicht nötig ist. Wenn ich eine Funktion schreibe, die z.B. Base64 Encoding macht und sie macht das korrekt und sie macht das schnell, warum genau sollte ich die jemals wieder anfassen müssen? Im Idealfall hat man irgendwo am Ende immer in sich abgeschlossene Units (Funktionen, Klassen, etc.), die man nie wieder anfassen muss. Aber diese brauchen auch Glue-Code, der die App Logik abbildet und da sich diese oft ändert, muss man diesen Code natürlich immer wider anfassen.

    Und wenn man alten Code anfassen muss, dann sollte man ihn auch immer aufräumen wo nötig. Denn tut man das nicht, dann wird die weitere Entwicklung mit jeder Iteration immer langsamer und langsamer. Und das liegt nicht im Interesse von irgendwem, weder im Interesse des Entwicklers, noch im Interesse seines Arbeitgebers, noch im Interesse des Auftraggebers.

    Siehe hierzu:

    https://youtu.be/7EmboKQH8lM?t=1534

    und

    https://youtu.be/Qjywrq2gM8o&t=1551s

    Wer Entwicklern kein Refactoring erlaubt, der killt die Produktivität seines Teams und wenn er das tut, dann darf er sich nicht beschweren, wenn Features, die 3 Tage dauern sollten am Ende 3 Wochen dauern, weil hätte er Refactoring erlaubt, dann hätten sie nur drei Tage gedauert.

    Refactoring ist wie jeden Tag ein bisschen seinen Arbeitsplatz aufräumen. Das kostet jeden Tag vielleicht 10% der Arbeitszeit, aber dafür ist dein Arbeitsplatz immer aufgeräumt und produktiv. Machst du es nicht, dann sparst du jeden Tag 10% Arbeitszeit, aber dein Arbeitsplatz wird immer unaufgeräumter und deine Arbeit als Folge immer unproduktiver.

    Und irgendwann stehst du vor einem großen Problem: Du kannst jetzt deinen Arbeitsplatz aufräumen, aber das wird ewig dauern und ist Null produktiv, weil in der Zeit wo du das machst arbeitest du faktisch nichts. Oder aber du machst es nicht, um lebst damit, dass eben alles ewig dauert, weil du nichts findest und im Chaos versinkt.

    Kurzsichtige Manager oder Auftragsgeber sagen "Ich zahle dich doch nicht dafür, dass du deinen Arbeitsplatz aufräumst", aber die Antwort ist "Doch! Genau das tust du!" Denn nur mit einem aufgeräumten Arbeitsplatz kann ich vernünftige Arbeit leisten und du willst doch, dass ich vernünftige Arbeit leiste, oder? Du zahlst mich, um vernünftige Arbeit zu leisten und die kann ich nur dann leisten, wenn mein Arbeitsplatz aufgeräumt ist und da der Grund warum er durcheinander kommt die geleistete Arbeit ist, gehört auch das Aufräumen dazu. Du kannst nicht erwarten, dass ich das kostenlos in meiner Freizeit tue. Der Schreiner macht auch die Werkstatt sauber, nachdem er an deinem Tisch gearbeitet hat und auch das ist Arbeitszeit, das ist keine Freizeit. Ansonsten dauert der Tisch 5x so lange und wird 5x so teuer und das liegt sicherlich nicht im Interesse des Auftraggebers.

    /Mecki

  7. Re: Missverständnisse?

    Autor: gochnad 23.05.22 - 20:51

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > gochnad schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Naja, es gibt Ansätze wie Test driven devlopment, die das fordern.
    > > Das hat doch wenig damit damit zu tun, ob man nun einem "agilen" Prozess
    > > arbeitete, oder die Software erst plant und dann erstellt?
    >
    > Doch, hat es. Die Idee hinter agil ist, dass du agil bist, daher der Name.

    agil ist agil, das hab ich nicht bestritten.
    Aber ob man vollumfänglich Unit-Tests einsetzt oder nicht, das hat wenig damit zu tun, ob man auch scrum einsetzt, oder erst nen Wasserfall plant.
    Sinnvoll wär's, keine Frage, ist aber nicht automatisch dasselbe.

    > Zugegeben, der Vergleich hinkt etwas, da man eine Mauer nicht schnell mal
    > refactoren kann, man muss sie abreißen und neu bauen und daher habe ich
    > hier so getan, als ob man die bisherige Mauer einfach so stehen lässt,

    vielleicht hinkt es weniger als du denkst. Wenn du dem Maurer nach einer ursprünglichen "Vision" eines 2..3 stöckigen Hauses oben angekommen eröffnest, dass die Pläne sich geändert haben und die tragende Wand nun 15 Stockwerke tragen muss, wird er ggf alles erst abreißen müssen. Oder alternativ irgendwelche hässlichen Betonstützen daneben stellen.
    Ähnlich kannst du auch bei Software die Prämissen so ändern, dass das gewählte Framework nicht mehr passt, die grundlegende Datenstruktur neu designt werden muss, sprich: am Besten alles von Grund auf neu machen.
    Oder es wird hässliches Frickelwerk.

    Leider ist es in der Regel nicht mal so, dass einer kommt und sagt "die Pläne haben sich geändert".
    Es heist nur, ok, mach mal noch ein Stockwerk drauf. Und dann noch eins, ...
    Wenn du Glück hast, hat irgendwo einer vermerkt: "geplant sind 2..3 Stockwerke, ich leg das vorsichtshalber mal so aus, dass es 5 Etagen trägt. Dann kannst du das anbringen, sobald jemand die 6. Etage verlang. In der Regel gibt so ne doku aber auch nicht, es will keiner mehr wissen, was mal vereinbart oder "visioniert" wurde, weil ja meist alles nur mündlich gequatscht wird.
    Dazu ja auch die rituellen Meeting, wo alle gefälligst zu selben Zeit am selben Ort sein müssen, damit man bloß nix schriftlich festhalten muss, sondern rumlabert und sich später nicht mehr erinnert.
    Aber die Coder sind schuld, dass sie nicht dokumentiert haben, klar. Und schuld, dass sie nicht genauso agil die Software ändern können, wie ein Manager seine Meinung ändern kann.

    > Es geht eben nicht darum, bloß keinen bisherigen Code noch einmal
    > anzufassen,

    Darum ging es mir auch nicht. Mir geht es darum, dass manch Code so verfrickelt ist, dass man handlungsunfähig wird.
    Das liegt teils an unerfahrenen Codern, teils aber auch an Management etc. Und wird in der Regel schlimmer, je öfter sich Grundannahmen und Prioritäten geändert haben.

    Wenn dein Maurer anfängt, für ein Lustschloss zu mauern und mittendrin ändern sich die Vorgaben und es soll plötzlich eher ne belangerungsfeste Burg werden, dann wird das am Ende weder schön, noch besonders stabil, und hat irgendwelche Ecken, deren Zweck keiner mehr versteht.
    Jetzt tausch die Maurer noch jedes Jahr einmal aus, erzähl jeder Generation ein bisschen was anderes, worum es geht und lass das 15 Jahre so laufen ... Und dann darfst du dich gerne wundern, wenn das "keiner mehr anfassen will" ;-)

    > Wer Entwicklern kein Refactoring erlaubt, der killt die Produktivität
    > seines Teams und wenn er das tut, dann darf er sich nicht beschweren, wenn
    > Features, die 3 Tage dauern sollten am Ende 3 Wochen dauern, weil hätte er
    > Refactoring erlaubt, dann hätten sie nur drei Tage gedauert.

    Das Problem ist doch, dass das Refactoring heute 2 Wochen kostet und erst Mal nix bringt, ausser vielleicht kleinen Geschwindigkeitsvorteilen.
    Dass es in der Zukunft eventuell mal 3 Wochen sparen könnte, interessiert doch keinen Manager, der auf seinen Quartalsabschluss schielt.

  8. Re: Missverständnisse?

    Autor: chseidel 23.05.22 - 21:41

    > ok, vielleicht ist theoretisches, "echtes" Agiles Arbeiten ja ganz ok.
    > Ich kritisiere das real existierende. Und da sieht es oft so aus, dass man
    > schon weiss, was es maximal kosten darf und wann es spätestens fertig sein
    > soll. Aber nach Prioritäten oder Details gefragt, will man sich ganz agil
    > bis kurz vor Schluss nicht festlegen.

    Das ist der Managementfehler des falschen Optimierungsansatzes. Ein Klassiker In Deutschland.

    Ein gut bekanntes Problem kann man vorab planen und Kosten optimieren. Macht jeder Handwerksmeister.

    Wenn aber ins unbekannte, komplexe implementiert wird (und dazu gehört z. B. alles Interaktive) dann ist eine feste und kommunizierbare Zielvirstellung wichtig. Darauf aufbauend kann man sich der Lösung Stück Weise nähern. Optimiert wird dabei durch z. B. Scrum das Verständnis des Auftraggebers was möglich ist und was nicht, das Verständnis des Teams was zu tun ist, das Verständnis zwischen Team und Auftraggeber und damit die Produktivität. Und das Risiko, was sinnfreies zu Implementieren sinkt.
    >
    > Erschreckend oft habe ich festgestellt, dass wenig Vorstellungskraft
    > besteht (oder auch nur Wille, sich was vorzustellen), wenn man drüber
    > spricht, wie etwas funktionieren wird. Dann heisst es: mach doch mal, dann
    > besprechen wir das.

    Ja, ein Knackpunkt. Der Auftraggeber und alle an Konzept und Realisierung Beteiligten müssen sich klar sein, was in welcher Reihenfolge warum implementiert wird. Wir sehr gerne vergessen.
    >
    > Wenn man ständig was programmiert, nur um dann zu erfahren, "ne, so hab ich
    > mir das nicht vorgestellt". Muss es natürlich viel teurer werden, als wenn
    > man es in einem Gespräch vorab herausgefunden hätte.

    Gute Auftraggeber (PO) sind in der Tat rar.
    Auch wird oft der Fehler gemacht, das Team und Auftraggeber erst garnicht in Kontakt treten.

    > Zum Ausgleich wird an anderer Stelle gespart. Refactoring? Wieso, geht
    > doch. Erstmal feature x Implementieren, damit der Kunde die nächste
    > Rechnung bezahlt.

  9. Re: Missverständnisse?

    Autor: egal1234 24.05.22 - 10:53

    gochnad schrieb:
    --------------------------------------------------------------------------------
    > vielleicht hinkt es weniger als du denkst. Wenn du dem Maurer nach einer
    > ursprünglichen "Vision" eines 2..3 stöckigen Hauses oben angekommen
    > eröffnest, dass die Pläne sich geändert haben und die tragende Wand nun 15
    > Stockwerke tragen muss, wird er ggf alles erst abreißen müssen. Oder
    > alternativ irgendwelche hässlichen Betonstützen daneben stellen.

    genau das ist ja das Problem. Wahrscheinlich ist sowas ja nicht definiert. es wird ja nur gesagt, dass aktuelle sprintinkremente funktionieren, d.h. sitzen die Fenster richtig, ist die neue Mauer gearde.
    Und die alte Wand funktioniert ja, hat ja bisher auch funktioniert.
    Der zuständige Maurer ist inzwischen nicht mehr da und dokumentiert ist ja nur das nötigste, da Kommunikation mit dem Kunden wichtiger ist.

  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. (Senior) IT Professional Client Systems (m/w/d)
    ALDI International Services SE & Co. oHG, Mülheim an der Ruhr
  2. Oracle Apex Entwickler (m/w/d) für IT Service und Digitalisierung
    Wilma Immobilien GmbH, Ratingen
  3. Softwareentwickler C# für Laborgeräte - Partikelmesstechnik (m/w/d)
    Microtrac Retsch GmbH, Haan (Home-Office möglich)
  4. Java-Entwickler / Software Developer, z. B. Informatiker / Fachinformatiker (w/m/d)
    emsys VPP GmbH, Oldenburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Humankind für 27,99€, Two Point Hospital für 7,50€, Endless Legend für 6,50€)
  2. (u. a. Tales of Arise - Ultimate Edition für 46,99€, For Honor für 6,99€, Sword Art Online...
  3. 12,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de