Laden...

Fixpreis und Agilität

Erstellt von nhantruong vor 12 Jahren Letzter Beitrag vor 12 Jahren 5.494 Views
N
nhantruong Themenstarter:in
6 Beiträge seit 2011
vor 12 Jahren
Fixpreis und Agilität

Hallo zusammen

Ich bin neulich mit dem Thema "Fixpreise und Agile Methoden" beschäftigt und möchte Feedback von Euch bekommen, denn Ihr habt ja Praxis-Erfahrungen mit Softwareprojekten gemacht. Meine Fragen lauten:

  1. Fixpreis und Agile - Passt das eigentlich zusammen?
  2. Inwiefern kann man AGILE in Fixpreisprojekten einführen?
  3. Welche Probleme sind vorzusehen?

Vielen Dank im Voraus.
Nhan

6.911 Beiträge seit 2009
vor 12 Jahren

Hallo,

Ralfs Blog-Post Widerspruch gegen das Schätzen finde ich da ganz passend.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

N
nhantruong Themenstarter:in
6 Beiträge seit 2011
vor 12 Jahren

Hallo gfoidl

Danke für den Link. Mir gefällt der Artikel sehr, besonders dessen Gliederung: Einführung - 82% der Textlänge, These - 11%, Fazit - 7% 😉

Ralf widerspricht die Aufwandsschätzung. Ich glaube, er trennte Softwareentwicklung von Business. Dies stimmt ja nicht in Wirklichkeit. Der Begriff "Softwareindustrie" sagt schon was. Hier geht es auch um Business. Ohne Auftraggeber gibt es keinen Vertrag, keine Softwareprojekte.

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo nhantruong,

Ich glaube, er trennte Softwareentwicklung von Business.

nein, das sehe ich nicht so. Er schlägt bloß einen anderen Ansatz vor. Das kommt am besten in diesem Kommentar von ihm zum Ausdruck:

Dem Kunden sagst du, dass er soviel Geld ausgeben kann, wie er mag. Er hat volle Budgethoheit.

Und du wirst nie nachverhandeln mit ihm. Er weiß vom ersten Tag an, was es kostet. Es wird nie teurer.

Und du sagst ihm, dass er jeden (!) Tag den Kurs ändern kann, wenn er will. Er ist somit maximal flexibel.

Und er kann jederzeit abbrechen und bekommt die vollen Rechte am Code.

Und du arbeitest die ersten 3 Wochen umsonst, wenn er sich bis dahin entschließt, abzubrechen, weil er unzufrieden ist. (No questions asked - aber es wäre natürlich schön, wenn er trotzdem sagen würde, warum er abbricht.)

Ich finde es nicht verwunderlich, dass man für einen radikal geänderten Software-Entwicklungsprozess (Agilität) ein (radikal) geändertes Businessmodell braucht.

herbivore

N
nhantruong Themenstarter:in
6 Beiträge seit 2011
vor 12 Jahren

Hallo herbivore

Ein radikal geändertes Businessmodell scheint wenig Chance zu haben, denn

Der Trend zu fest kalkulierbaren Kosten – zum Beispiel durch Fixpreis-Projekte und Servicepakete – hält unvermindert an. So wird 2011: Drei Fragen an Martin Wunderli, Trivadis

Habt Ihr ja Kunden, die freiwillig die agile Arbeitsweise und die Abrechnung nach Aufwand adoptieren wollen?

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo nhantruong,

Der Trend zu fest kalkulierbaren Kosten – zum Beispiel durch Fixpreis-Projekte und Servicepakete – hält unvermindert an.

Der Vorschlag von Ralf Westphal steht dem nicht entgegen. Ralf Westphal sagt ja gerade:

Er [der Kunde] weiß vom ersten Tag an, was es kostet. Es wird nie teurer.

Ich sehe also keinen Widerspruch. Das einzige was nicht feststeht, ist der Leistungsumfang. Den Leistungsumfang schon zu Anfang festzulegen, kollidiert aber mit agile Entwicklung. Wäre der Leistungsumfang genau festgelegt und würde die Entwicklung das einzige Ziel haben, diesen definierten Leistungsumfang ohne Änderungen zu realisieren, wäre die Entwicklung nicht mehr agil.

Mit anderen Worten, von mindestens einem der Ziele Festpreis, definierter Leistungsumfang und agile Entwicklung muss man sich verabschieden. Alle drei zusammen gehen nicht. Egal wie blöd du das findest, egal wie blöd der Kunde das findet und egal sehr du oder der Kunde mit dem Fuß stampft. 😃

Wenn die Kunden agile Entwicklung wollen, dann müssen sie auch die Konsequenzen tragen. Wenn sie dazu nicht bereit sind, dann wollen sie agile Entwicklung eben doch nicht. Waschen ohne nass zu werden geht nicht.

herbivore

E
395 Beiträge seit 2007
vor 12 Jahren

Waschen ohne nass zu werden geht nicht.

*hust* deo... 😛

MfG Paul

T
708 Beiträge seit 2008
vor 12 Jahren

Der Vorschlag von Ralf Westphal steht dem nicht entgegen. Ralf Westphal sagt ja gerade:

Er [der Kunde] weiß vom ersten Tag an, was es kostet. Es wird nie teurer.

Diese Aussage verstehe ich schlicht und ergreifend nicht.

Der Kern von Ralf´s Artikel ist, dass man keine verbindlichen Zeit- und Aufwandsschätzungen abgeben kann. => Klar, das erleben (wir) Entwickler jeden Tag.
Mal zahlen wir die verschätzte Differenz, mal der Kunde. Wenn das alles so schrecklich wäre wie Ralf beschreibt, wären alle SW-Unternehmen pleite.

Exerzieren wir das durch: Ein Kunde hat 10.000,- und möchte ein Textverarbeitungsprogramm.
Man kommuniziert seinen Stundensatz und fängt an. Nun sind die ersten 2.000€ verbraten.

Im wöchentlichen Report wird klar, das der Kunde MS Word erwartet, aber man gerade so ein Notepad abliefern kann.
Nun ist der Kunde sauer und steht vor dem selben Problem wie immer: Zahle ich jetzt mehr oder wage ich einen Neuanfang. Reicht mir der Funktionsumfang so aus? Repariere ich das Auto noch ein letztes Mal oder lohnt diese Investition nicht mehr?!?

Der entscheidende Vorteil für den Entwickler ist die Sicherheit, die mit dem System auf unserer Seite steht. Nach der klassischen Methode hätten wir eigentlich das Risiko.

Da nur leider der Markt die Regeln bestimmt und selten der Anbieter, denke ich nicht das dieses System rigeros durchführbar ist. (Außer man heißt Steve Jobs und hat die Gelddruckmaschine erfunden)

Persönlich nutze ich die Methoden nach Aufwand zu berechnen (Das geht aber nur mit eine Angabe des maximalen Zeit-/Kosten-rahmens) oder einem Festpreis.
Wenn ich mich zeitlich verkalkuliere habe ich einen schlechten Job bei der Planung gemacht. Ist der Kunde unzufrieden mit dem Ergebnis und erwartet einen anderen Funktionsumfang (kostenlos natürlich) dann habe ich bei der Spezifikation versagt.

Sicherlich gibt es etliche Beispiele, die nicht im Vorhinein planbar sind. Dazu muss man dann Machbarkeitsanalysen abstimmen um den unbekannten Faktor zu minimieren.
Oft verkalkuliert man sich. Aber immer in beide Richtungen 😃

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo trib,

Diese Aussage verstehe ich schlicht und ergreifend nicht.

klarer kann eine Aussage kaum sein. 😃 Und widerlegt hast du sie auch nicht. Du hast nur zutreffend beschrieben, dass sich die verbleibende Unsicherheit verlagert, nämlich auf den Funktionsumfang. Der ist nicht fix. Und natürlich kann hier eine Enttäuschung für den Kunden lauern.

Ich denke nicht, dass die Aussage von Ralf so gemeint ist, dass der Kunde jetzt hingeht und sich im Stillen Kämmerchen denkt, Word kostet - ich weiß es ehrlich gesagt nicht - sagen wir einfach fiktiv 500 Euro - der tatsächliche Betrag ist letztlich egal -, ich will was individuelles, das kostet z.B. beim Schreiner durchaus mal den Faktor 10, also liebe Firma, schreib mir mal mein persönliches Word für 5000 Euro. Sondern natürlich wird und muss sich die Firma mit dem Kunden im Dialog auf einen groben Rahmen und Eckpunkte einigen. Und natürlich müsste die Firma schon im Vorfeld sagen, dass ein persönliches Word für 5000 Euro nicht zu machen ist.

Da nur leider der Markt die Regeln bestimmt

Das ist unbestritten. Das bedeutet aber nicht, dass es keine Kunden gibt, die die Vorteile eines agilen Vorgehens sehen und die Konsequenzen akzeptieren. Ich stimme dir zu, dass man als Anbieter nicht seine Vorstellungen gegen den Willen der Kunden durchsetzen kann. Aber man kann durchaus so ein Angebot machen und schauen, ob der Kunde darauf eingeht.

herbivore

799 Beiträge seit 2007
vor 12 Jahren

Wenn ich mich zeitlich verkalkuliere habe ich einen schlechten Job bei der Planung gemacht.

Eine der Kernaussagen ist ja auch, dass man hier nicht kalkuliert sondern schätzt. Und das in dem Schätzwert ein imanenter Fehler lauert: Niemand weiß vorher wirklich wie es läuft.

Das Software-Unternehmen nicht pleite gehen liegt vorallem auch daran, dass es keine Alternative gibt. Bananensoftware ist ja noch immer sehr weit verbreitet.

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
N
nhantruong Themenstarter:in
6 Beiträge seit 2011
vor 12 Jahren

Hallo herbivore, trib und der-schlingel

Danke für Eure Antworten.

Wenn ich mit den Meinungen von herbivore und der-schlingel einverstanden wäre, würde ich die Anbieter, die mehr als bereit sind, Fixpreisprojekte zu bieten, für unprofessionell und unverantwortlich. Obwohl sie die inherente Problematik mit Fixpreis, also die präzisen anfänglichen Abschätzung, kennt und erlebt haben, wollen sie sie ignorieren und möglichst viele Verträge gewinnen.

X(

49.485 Beiträge seit 2005
vor 12 Jahren

Hallo nhantruong,

wie schon gesagt, schließen sich Fixpreis und Agilität gegenseitig nicht aus. Insofern verstehe ich deinen Einwand bezüglich der Unprofessionalität und Unverantwortlichlichkeit nicht.

BTW: Mir kommt kein Verhalten langsam etwas trollhaft vor. Egal was wir sagen, du bist am "Motzen", weil es dir nicht passt.

herbivore

799 Beiträge seit 2007
vor 12 Jahren

Meine persönliche Meinung ist, dass ein Projekt zu einem Fixpreis und einem Fixtermin auf jeden Fall Ressourcen frisst.

Entweder leidet darunter die Qualität, die Pünktlichkeit oder das "Menschenmaterial".

Oder um eine uralte PM-Weisheit zu rezitieren:

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
N
nhantruong Themenstarter:in
6 Beiträge seit 2011
vor 12 Jahren

Ich dachte, mit AGILE kann man ja alle 3 fangen: Gut, Schnell und Günstig.

799 Beiträge seit 2007
vor 12 Jahren

Falsch gedacht 😉

As a man thinketh in his heart, so he is.

  • Jun Fan
    Es gibt nichts Gutes, außer man tut es.
  • Erich Kästner
    Krawutzi-Kaputzi
  • Kasperl
M
153 Beiträge seit 2010
vor 12 Jahren

Die Frage lautet ja auch: Was bedeutet denn agil in der konkreten Kunden- und Vertragsbeziehung? Agil bezüglich der Vorgehensweise, agil im Hinblick auf die Entwicklungsweise (z. B. frühe Prototypen, häufige Auslieferungen) oder agil bezüglich des zu entwickelnden Umfangs? Oder eine Kombination davon?

Die meisten Kunden wird es herzlich wenig interessieren, wie das interne Entwicklungsmodell des Dienstleisters aussieht. Er kauft einen gewissen Funktionsumfang zu einem gewissen Preis und erwartet eine Lieferung zum zugesagten Termin. Agilität kommt schon deshalb ins Spiel, weil das Pflichtenheft meist genug Raum für Interpretationen lässt und das eine oder andere zudem vergessen wurde. Und auf Entwicklerseite ist Agilität gelebte Entwicklungskultur.

Agilität setzt immer einen festen Grundrahmen voraus, in dessen Grenzen agil gehandelt werden kann. So ist es zum Beispiel nicht unüblich eine Grundfunktionalität fest zu vereinbaren und dem Kunden das Recht einzuräumen, während des Projektes aus einer Liste vorher besprochener Anforderungen auszuwählen. Dann entweder im Rahmen eines vereinbarten Werkpreises oder per Aufpreisliste.

Auch bei agilen Modellen gibt es feste Bezugsgrößen. Bei Scrum zum Beispiel das Backlog, das vom "Product Owner" priorisiert und einzelnen Sprints zugeordnet wird. Die Zuordnung ist agil, auch die Aufteilung auf das Team. Über den Inhalt des Sprints wird aber (im Normalfall) nicht mehr diskutiert.

Ich würde das magische Dreieck von "der-schlingel" noch um differenzieren wollen (zum magischen Viereck). Gut bedeutet sowohl : Gut (= Qualität) und Viel (=Funktionsumfang). Es ist klar, dass es hinsichtlich der Qualität feste Größen geben muss, weil Qualität auch Kosten und Zeit bedingt.

Zu guter Letzt hängt es auch von der Vorgeschichte zwischen Kunden und Dienstleister ab. Hat das Modell in der Vergangenheit schon funktioniert? Besteht ein gesundes Vertrauensverhältnis? Besteht die Bereitschaft beider Seiten zu Kompromisse? Die Liste ließe sich weiter fortführen.

Ich selbst bin recht unglücklich über den inflationären Umgang mit dem Begriff "Agil", der oft genug noch als seligpreisend und allumfassend verkauft wird. Und so gibt es nur eine sichere Erkenntnis: Agil ist zunächst nur ein Adjektiv. Es kommt immer darauf an, was man daraus macht.