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

Agil als Arbeitsweise von Dienstleistern

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 Ansicht wechseln


  1. Agil als Arbeitsweise von Dienstleistern

    Autor: HOS 31.08.21 - 13:54

    Da ich aus dem Einkauf komme ist für mich bei den ganzen agilen Methoden das größte Problem das man es nicht ordentlich einkaufen kann. Anforderungen gibt es keine bzw. nur so high level das man auf der Basis keine ordentliche Ausschreibung machen kann und Agil häufig nur ein Tool ist um den Kunden explodierende Kosten aufzuhalsen.

    Einfach die Manntage verhandeln? Ja das geht. Aber Lieferant A arbeitet ordentlich und effizient und Lieferant B weist seine Leute an nur 4 Stunden Tage zu machen bzw. 4 Stunden für Kunden A (voll bezahlt) und 4 Stunden für Kunden B (voll bezahlt) zu leisten. Reines Glücksspiel. Wenn es um siebenstellige Beträge geht, dann ist das keine akzeptable Vorgehensweise und die Kosten durch schlechte Lieferanten sind viel höher als die Nachteile des Wasserfallmodelles.

    Deswegen sehe ich es als tolles Tool für interne Entwickler an, die auch ein Interesse haben das Projekt schnell UND erfolgreich fertigzustellen.

    Denn mache ich dann einen Festpreis, wird geschludert und das Ergebnis kann leiden. Ohne Festpreis explodieren die Kosten gerne mal ohne einen triftigen Grund sondern nur um den Kunden auszupressen.


    Habt ihr Erfahrungen bzw. Ideen wie man das Problem lösen kann? Ohne Lösung rate ich meinen internen Kunden von solchen Anbietern ab.



    1 mal bearbeitet, zuletzt am 31.08.21 13:55 durch HOS.

  2. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: deefens 31.08.21 - 14:12

    4 Stunden werden als voller Manntag abgerechnet?

  3. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: HOS 31.08.21 - 14:27

    Wie willst du es nachverfolgen? Ist aber ein generelles Problem bei Beauftragung von Consultants. Wie oft ist denen in Gesprächen schon rausgerutscht das sie noch schnell an einem anderen Thema arbeiten müssen etc...

  4. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: osch@d 31.08.21 - 14:47

    Wenn man agil ernst nimmt, dann kauft man auch agil ein: man macht einfach kein Projekt über 1 Mio. Euro, wo ja das Deliverable gar nicht definiert werden kann.

    D.h. im Einkauf bucht man 2 Monate und achtet auf Übergabefähigkeit des Projekts. Das bedeutet, dass der Build und Deploy-Prozess beim Kunden liegen muss, nicht beim Anbieter. Das ist die einzige Möglichkeit Kontrolle auszuüben. Nach jedem Monat (oder 4 Wochen) werden die Lieferungen geprüft durch den Kunden.

    Ist das Delta zu groß, wird gekündigt und der Dienstleister hat noch 4 Wochen Zeit die Übergabe vorzubereiten.

    Baut der Dienstleister zuviel Scheiße, wird er auch agil ersetzt. Man hat somit als Einkäufer eine permanente Drohung plaziert und daher entsteht beim Dienstleister nur selten das Gefühl, dass er die Beine hochlegen kann.

  5. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: ThorstenMUC 31.08.21 - 15:05

    Die Herausforderung bei Festpreisen ist, dass man gerade bei umfangreichen Projekten in denen z.B. eine Lösung im Laufe von 20 Monaten entwickelt und eingeführt werden soll eigentlich heute schon exakt spezifzieren muss, was umgesetzt werden soll und was die Abnahmekriterien sind.

    Nur - meist kann man das heute noch nicht im Detail beschreiben (und es ist ein irrsinniger Aufwand) - der Kunde kennt zum Ausschreibungszeitpunkt ja noch nicht mal die Softwarelösung, mit der das Projekt am Ende umgesetzt wird... wie soll er da Details spezifizieren?
    Und - wie sicher ist es, dass die heute geplante Lösung in 20 Monaten überhaupt noch zum sich bis dahin teils veränderten Geschäftsabläufen passt?

    Wenn ein Kunde heute bei einem großen Projekt auf Fixpreis besteht muss man als Anbieter folgendes einkalkulieren:
    - Sehr hoher Presales-Aufwand, um die Detailspezifikation auszuarbeiten und exakte Abnahmekriterien zu definieren und zu verhandeln
    - Abweichungen von diesen Spezifikationen führen zu hohen Change-Kosten, welche wiederum durch den Presales/Spezifikationsprozess müssen und deshalb Zeit/Aufands-intensiv sind.

    Diesen Aufwand und das Risiko des Fixpreis muss der Anbieter mit einkalkulieren... dazu gibt es einen großen Verwaltungs-Overhead für den ganzen "Papierkram"...

    Fixpreis funktionier ganz gut bei überschaubaren, abgegrenzten Projekten (ok - das war eigentlich redundant)... aber wenn das Geschäft des Kunden volatil ist und schon die Anforderungen nicht klar definiert werden können bleibt sinnvoll eigentlich nur ein agiles Vorgehen oder zumindest eine Umsetzung in Zwischenschritten (Prototyp - Anforderungen überprüfen/erweitern - Pilot-Implementierung - nochmal Überplanen - Rollout - kontinuierliche Weiterentwicklung).

    Es kommt auf das Zwischenmenschliche (bzw. ZwischenUnternehmerische) an... wenn beide Seiten fair spielen und Vertrauen herrscht kommt man mit beiden Methoden gut voran... sobald eine Seite versucht die andere zu übervorteilen geht das idr. nicht langfristig gut und wird sehr viel teurer.

  6. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: Trockenobst 31.08.21 - 16:28

    HOS schrieb:
    --------------------------------------------------------------------------------
    > Habt ihr Erfahrungen bzw. Ideen wie man das Problem lösen kann? Ohne Lösung
    > rate ich meinen internen Kunden von solchen Anbietern ab.

    Das Problem ist doch schon, dass die Aufträge meistens so wild in ihrer Vorraussagen sind das man kaum vernünftig Ansagen machen kann. Können dreissig normale Server sein, können aber auch zwanzig normale und zehn so richtig teure sein. Vielleicht braucht ihr zehn Leute im Support, kann aber durch Sommerferiendruck auch sein dass man schnell 20 mehr braucht.

    Agile beseitigt nicht die Risiken. Keiner wird 20 Server auf Verdacht bestellen oder 10 Leute mehr beschaffen, die er dann nicht braucht. Man will aber durch Festpreise eine Sicherheit, die man nicht fordern kann. Deswegen werden die Firmen alle etwas flunkern und die Leute etwas über verkaufen.

    Der einzige wirkliche moderne Ansatz den ich gesehen habe ist, dass - was immer das Projekt umsetzen soll, als erstes ein Prototyp von Anfang bis Ende auf Zielhardware deployed wird. Der kann z.B. keine Userrechte, keine komplexen Masken, aber die Kernaufgabe (z.B. Daten aus verschiedenen Kundendatenbanken zusammenfassen und daraus Rechnungen zu erstellen) ist schon möglich. Dann sieht man dass der Prozess allgemein funktioniert. Wieviel kostet der Server, wie überlastet ist er, klappt das mit den Anbindungen. Danach wird das wieder Iterativ neu ausgeschrieben für den zweiten Teil das alles richtig umzusetzen. Man weiß ja schon das es funktioniert.

    Also anstelle 1 Mio oder 2 Mio zu "garantieren" fängt man mit 300-500T Schritten an und geht an den Kern der Aufgabe. Wenn die Kernfunktion nachweislich funktioniert, geht man zum nächsten Schritt. Das reduziert das Risiko bei allen, es werden belastbare Daten erzeugt, die eine bessere Planung ermöglichen. In einem Fall kam raus, dass die Kundendatenbank nur alle drei Tage ein Update bekam, das war natürlich für tägliche Rechnungen nicht möglich. "Hat keiner gewusst!" klar. Es hat dann drei Monate beim Kunden gedauert das zu ändern. Nach regulärem Prozess wäre das drei Monate vor dem Live Datum passiert, mit Konventionalstrafe und allem, da wäre die große Panik ausgebrochen. Kein Agile und Fixpreis schützt einem vor sowas.

  7. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: HOS 31.08.21 - 20:26

    Dann bist du aber schon an einen Lieferanten gebunden der sich melkt. Denn während der Entwicklung wechseln geht nicht. Ne ne. Das wird nix.

  8. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: Trockenobst 01.09.21 - 04:47

    HOS schrieb:
    --------------------------------------------------------------------------------
    > Dann bist du aber schon an einen Lieferanten gebunden der sich melkt. Denn
    > während der Entwicklung wechseln geht nicht.

    So haben wir große Projekte gemacht, die bis heute in großen Firmen mit vielen Shops laufen.
    Weil der erste Schritt ja nur ein "Durchstechen" bzw. Prototyp ist, fängt man beim zweiten Schritt eigentlich Neu an, aber weiß sehr genau was funktioniert und was nicht. Da kann man z.B. mit PHP beginnen und es auf Java/.net heben. Der eine Lieferant kann das eine, das andere aber nicht.

    Wer natürlich überall nur Buschräuber sieht und schlecht in dieser Art der iterativen Planung ist, muss eben auch in diesem "Zustand" des ewigen Krieges leben. Dann 1 Million planen, für 1,5 gemelkt werden. Mehr als Vorschläge kann man nicht machen. Aber es gibt eben die Teams, die von der ersten Liga in die Kreisliga plumpsen, obwohl jeder sich total aufarbeitet. Nur eben an den falschen Dingen mit den falschen Methoden.

  9. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: gadthrawn 01.09.21 - 06:38

    osch@d schrieb:
    --------------------------------------------------------------------------------
    > Wenn man agil ernst nimmt, dann kauft man auch agil ein: man macht einfach
    > kein Projekt über 1 Mio. Euro, wo ja das Deliverable gar nicht definiert
    > werden kann.
    >
    > D.h. im Einkauf bucht man 2 Monate und achtet auf Übergabefähigkeit des
    > Projekts. Das bedeutet, dass der Build und Deploy-Prozess beim Kunden
    > liegen muss, nicht beim Anbieter. Das ist die einzige Möglichkeit Kontrolle
    > auszuüben. Nach jedem Monat (oder 4 Wochen) werden die Lieferungen geprüft
    > durch den Kunden.
    >
    > Ist das Delta zu groß, wird gekündigt und der Dienstleister hat noch 4
    > Wochen Zeit die Übergabe vorzubereiten.
    >
    > Baut der Dienstleister zuviel Scheiße, wird er auch agil ersetzt. Man hat
    > somit als Einkäufer eine permanente Drohung plaziert und daher entsteht
    > beim Dienstleister nur selten das Gefühl, dass er die Beine hochlegen kann.


    Problem ist, das die Software nach hinten raus immer komplexer wird. Du hast zwar dein Deliverable. Aber da Dokumentation ja langweilig ist und untergeordnet ist die meist eher mies. Das relativ schlecht dokumentierte Projekt wird weitergegeben. Irgend eine komplexe Software, bei der man den ungefähren Verlauf recherchieren muss um zu wissen, das warum wir drin ist.
    Nächstes Team, andere bevorzugte Arbeitsweise, Stile etc PP. Die ja als wichtiger geworden wie ein Unternehmensstil.
    Wechselsatz du, müssen sich die neuen länger in das Altprojekt einarbeiten um zu sehen, was sie nutzen können, und... Natürlich war als Refakturiering nötig ist. Machst du das ein paar Mal bekommst du einen Frankenstein als Programme die wieder schlecht wartbar werden .

    Eine der Hauptprobleme ist eben die überweise Zeit für das Gesamtprojekt. Hat du insgesamt kein zeitliches Ziel, kannst du theoretisch unendlich lang kreativ sein ohne der Fertigstellung wirklich Nähe zu kommen. Eine schöne Aussage war Mal: wenn wir ein Projekt klassisch geplant hätten, wäre es nie zustande gekommen, da am Anfang der Aufwand klar gewesen wäre- bei agil würde das Projekt zumindest gestartet.

    Projekte sind aber normalerweise nicht dazu da, nur gestartet zu werden. Die Ergebnisse die man bei scrum beispielsweise alle vier Wochen hat sind zwar etwas, aber nicht dass wir die Endanwender eigentlich arbeiten.

    Das klassische: Projekt gilt als gescheitert, will es außerhalb der Ressourcen/Geld/Zeit fertig wurde ist ja nicht behoben. Die Komplexität der Software ist weiterhin da, die Projekte werden durch scrum und Co keinen Tag kürzer. ( Eher sogar länger, da man später mehr ändert, wenn dann doch auffällt, das eine Komponente von früher eigentlich ein bottleneck ist auf das man mehr Sorgfalt hatte verwenden müssen. Refaktoring als Chance und gut ist halt ein Zeitfresser).

    Wenn früher ein Projekt als gescheitert gegolten hatte, weil es drei statt zwei Jahre dauerte, gilt es bei agil als erfolgreich, das die zwei Jahre als Ziel gar nicht wichtig sind.

    Das agile Manifest ist etwas, was versucht hat, programmierten eher als Kunst zu setzen. Viele Programmierer sind aber eben Durchschnitt oder darunter. Wirklich kreative gibt es viel weniger, auch wenn sich viele so sehen. Und da muss dann eben nur eine SchnittstellenBeschreibung abgearbeitet und wie dünne andere auch implementiert werden und nicht agil noch Mal bei kreativ ausgetobt werden, will man eine bessere Idee hat. Daraus entstehen dann meist nur Zig andersartig programmierte Schnittstellen, alle individuell, großer, später schlecht wartbar Mist.

    Scrum als Steuerungselement funktioniert besser, wenn man es in etwas wie das v-Modell einbindet, bei welchem eben Projektaufwand klarer ist und generelle Architektur festgelegt wird.

    Fast ist ja auch das lustige: in den Beitrag wird geschrieben, das die Entwickler Dank scrum einen Monat unberührter Zeit haben.... Das haben sie bei den klassischen Modellen ja eben auch. Wenn sie innerhalb des Monats ständig neue Anfragen bekommen, ist es kein klassisches Projektmodell. Dann ist der Scrum master als Schnittstelle und blockiert zum Teil der klassische Projektleiter, der genau diese Aufgabe hat.

    Übertragen wird es auf den Bau: der einfache Programmierer ist ein klassischer Mauer. Der schimpft hin und wieder wie viel besser er es als der Vierarbeit machen könnte. Über Hitze und Überstunden, Zeitdruck. Agil ersetzt den Vorarbeiter. Hitze, Überstunden, Zeitdruck bleiben, der Mauer sie nun aber mehr können. Kann er meist aber nicht. Sonst wäre er wahrscheinlich schon längst Vorarbeiter geworden.

  10. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: bw71236196231 02.09.21 - 21:14

    @HOS
    Wir sind Dienstleister und arbeiten nach einem "agilen Festpreis". Nein richtig agil ist das nicht, aber es klappt ganz gut. Und 100% Scrum ist auch nicht möglich. Wichtig ist :
    Jeder Sprint wird getrennt geschätzt und beauftragt. Der Kunde stellt einen PO und wir auch. Wir als DL schätzen die Stories die der Kunde schreibt. Teilweise schreiben wir auch. Wir schätzen aber Personentage und nicht Storypoints (zu abstrakt und nicht kalkulierbar). Wir wissen die Verfügbarkeit vor dem Sprint, also zb 50 PT. Dann hat der 3 Wochensprint max. 50 PT, soviel paßt dann rein.
    Damit es funktioniert muss aber ein sehr großes Vertrauen das sein. Und der Kunde wird teil des Teams, nimmt also auch an den Terminen teil.

  11. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: bw71236196231 02.09.21 - 21:18

    Ach ja, wie mussten die Fachabteilung schulen bzgl Scrum und Agil. Und wir haben einen Projektleiter der auf die Abrechnung achtet, also klassisches Projektmanagement.

  12. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: SasX 02.09.21 - 22:53

    HOS schrieb:
    --------------------------------------------------------------------------------
    > Deswegen sehe ich es als tolles Tool für interne Entwickler an, die auch
    > ein Interesse haben das Projekt schnell UND erfolgreich fertigzustellen.

    > Habt ihr Erfahrungen bzw. Ideen wie man das Problem lösen kann? Ohne Lösung
    > rate ich meinen internen Kunden von solchen Anbietern ab.

    In dem Dreieck "Kosten", "Zeit" und "Umfang" ist es typisch für agile Projekte, dass Kosten und Zeit gut geplant werden können, jedoch der Umfang nur geschätzt werden kann (alle drei bekommst du nicht). Wenn du also von vornherein den klaren Umfang haben möchtest, dann landest du bei etwas wie Wasserfall, dann sind aber Kosten und Zeit nur geschätzt.

    In einem agilen Umfeld sind ja Änderungen willkommen, somit kann sich der Umfang ebenfalls jederzeit ändern. Wenn der Umfang aber ganz klar fixiert ist, dann wählst du eventuell das falsche Modell für das, was du möchtest.

  13. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: Dakkaron 03.09.21 - 15:59

    Hab ich auch schon gesehen. Da beschwert sich ein Externer, der theoretisch voll für uns arbeiten sollte, dass er noch ganz viele Meetings heute hat. Aber von unserer Firma war keins dabei... Tja.

  14. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: Dakkaron 03.09.21 - 16:08

    Ich hab eine Antwort, die du nicht gern hören wirst:

    Kauf keine Softwareentwicklung.

    Bau dir ein Team aus Internen auf, notfalls unterstützt von <50% Externen.

    Eines der größten Probleme bei längerfristiger Softwareentwicklung ist Wissen. Ist das Projekt halbwegs groß, kannst du damit rechnen, dass es einige Leichen im Keller liegen hat. Vor allem, wenn das Projekt von einer externen Firma gebaut wurde, wo die Entwickler wissen, dass sie für Dinge wie Wartbarkeit oder Langzeitstabilität nicht bezahlt werden.

    Leute, die lange an dem Projekt arbeiten, kennen diese Leichen. Ihre Effektivität ist oft um mehr als das 10-fache höher, als die irgendeines neuen Entwicklers, den du stattdessen dort hin setzt.

    Bei Internen ist die Fluktuation (gesetzt, das Arbeitsklima passt) üblicherweise deutlich geringer als bei Externen. Das heißt, Wissen bleibt länger in der Firma. Das heißt, Projektentwicklung läuft besser, stabiler, vorhersehbarer.

    Wenn du mit Externen Geld sparen willst, dann zahlst du dafür später und auf andere Weise wieder drauf.

  15. Re: Agil als Arbeitsweise von Dienstleistern

    Autor: NoGoodNicks 04.09.21 - 22:45

    Dakkaron schrieb:
    --------------------------------------------------------------------------------

    > Leute, die lange an dem Projekt arbeiten, kennen diese Leichen. Ihre
    > Effektivität ist oft um mehr als das 10-fache höher, als die irgendeines
    > neuen Entwicklers, den du stattdessen dort hin setzt.

    Bei gutem Projektmanagement ist das eher 3-5, keine 10. Aber der Sprung ist doch gewaltig.

    > Bei Internen ist die Fluktuation (gesetzt, das Arbeitsklima passt)
    > üblicherweise deutlich geringer als bei Externen. Das heißt, Wissen bleibt
    > länger in der Firma. Das heißt, Projektentwicklung läuft besser, stabiler,
    > vorhersehbarer.
    >
    > Wenn du mit Externen Geld sparen willst, dann zahlst du dafür später und
    > auf andere Weise wieder drauf.

    Das wollen die Erbsenzähler im Management leider nicht hören. Die Erfahrung lässt sich nicht so einfach quantifizieren, wie sie es gern hätten. Scheint aber der moderne Lauf der Dinge zu sein. Die Ingenieure werden aus den Management-Rängen verdrängt, stattdessen kommen BWLer bzw. Bindestrich-BWLer und geht es abwärts.

  1. Thema

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. Full Stack Software Developer (m/f/d)
    Lufthansa Technik AG, Hamburg
  2. Agile Coach (m/w/d)
    Haufe Group, Freiburg im Breisgau
  3. Inhouse Consultant Reporting (w/m/d)
    Schwarz Produktion Stiftung & Co. KG, Weißenfels
  4. Fachspezialist Informationssicherheit (w/m/d)
    Frankfurter Sparkasse, Frankfurt am Main

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499€
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de