Wie kann man bei agilen Softwareentwicklungsprojekten Kosten berechnen/ budgetieren?

Question

Wie berechnen Sie Ihren Kunden in einem Projekt mit agiler Methodik?

Pro Stunde? Dann muss vor dem Projekt ein großes Maß an Vertrauen aufgebaut werden.

Pro Iteration? Es wird eine Menge Budgetentscheidungen geben, die Zeit brauchen können.

Pro Projekt? Wie kann man das tun, wenn man den Umfang nicht kennt? Das Wesen des agilen Ansatzes besteht darin, keinen großen Entwurf/keine große Spezifikation im Voraus zu erstellen.

Answer 1

Sie stellen Ihrem Kunden die Kosten auf der Grundlage der in Ihrem Vertrag festgelegten Bedingungen in Rechnung, die sich von denen eines herkömmlichen Festpreisvertrags leicht unterscheiden. Nennen wir das einen agilen Vertrag.

Einige Optionen werden von Alistair Cockburn in Agile Verträge .

Eine weitere großartige Ressource ist 10 Verträge für Ihr nächstes agiles Softwareprojekt von Peter Stevens.

Mary Poppendieck hat auch großartig Material zu diesem Thema. Siehe wendigeVerträge , Workshop zu agilen Verträgen , Verträge Auszug aus Lean Software Development , Schlanke Verträge . Mehr aquí .

Answer 2

Die kurze Antwort lautet: Sie werden es nicht tun. Es gibt ein paar Dienstleistungsunternehmen, die auf diesem Gebiet Fortschritte machen, aber es ist ein schwieriger Weg. Sie müssen in der Lage sein, die Methodik zu verkaufen und den Kunden davon zu überzeugen, dass Sie liefern können.

Die Kunden wollen nicht riskieren, für eine Lösung zu bezahlen, die nie geliefert wird.

Typische Lösungsansätze für dieses Problem sind die Kosten, die nicht überschritten werden. Wenn Sie jedoch den Umfang nicht kontrollieren können, tragen Sie das gesamte Risiko.

Kurz gesagt, Sie suchen nach Kunden, die sich für T&M-Verträge (Time and Materials) entschieden haben, bevor Agile zur neuesten Modeerscheinung wurde (ich gehöre zu dieser Modeerscheinung, aber es ist nur einer in einer langen Reihe von Entwicklungsprozessen. Es wird immer mehr Aspekte geben, und in ein paar Jahren wird eine Variante davon einen anderen Namen haben).

Answer 3

Wenn sich Ihr Kunde bereits für die Anwendung einer agilen Methodik entschieden hat, dann haben Sie einen vernünftigen Rahmen für die Preisverhandlung pro Iteration. Das wissen Sie zum Beispiel:

1. Wie lang die Iteration sein wird.
2. Wie viele Personen an der Iteration mitarbeiten werden (und wie hoch ihr Anteil ist).
3. Ein ungefährer Arbeitsumfang.
4. Ein Verfahren für die Lieferung und Abnahme.

Das sind sehr viel mehr Anhaltspunkte für Preisentscheidungen als bei den meisten Festpreisverträgen.

---

Wenn es sich bei der agilen Methodik um einen rein internen Entwicklungsprozess handelt, an dem der Kunde nicht beteiligt ist, dann wird sie wahrscheinlich kaum Auswirkungen auf die Preisverhandlungen zwischen Anbieter und Kunde haben. Es gibt ein Argument, das besagt, dass ein Prozess, bei dem der Kunde nicht mindestens einmal pro Iteration in die Festlegung des Umfangs und der Erwartungen einbezogen wird, überhaupt nicht agil ist.

Was Marks Bemerkung betrifft, so gibt es ein sehr gängiges Preismodell, das auf Festpreisverträgen mit lose definiertem Umfang und optimistischen Zeitplänen basiert. Ein häufiges Ergebnis ist, dass sowohl der Lieferant als auch der Kunde feststellen, dass ihr anfänglicher Optimismus unangebracht war. Beide verhandeln dann aus einer schwachen Position heraus über die Dinge, die ihnen wirklich wichtig sind, und beide sind am Ende unzufrieden.

Einige der Techniken, die bei der Verwaltung dieser Art von Verträgen gut funktionieren, ähneln denen, die bei der Verwaltung von agilen Verträgen eingesetzt werden (häufige Lieferung, Kuhhandel über Umfang, Prioritäten und Preis, offene Kommunikation usw.) Der Hauptunterschied besteht darin, dass diese Techniken nicht in die ursprüngliche Vereinbarung integriert sind und der Vertrag möglicherweise nicht flexibel genug ist, um alle diese Techniken zu berücksichtigen.

Answer 4

Meine 2c als nicht-agiler Praktiker... auf der Suche nach mehr Wissen...

Wenn Sie ein bestimmtes Projekt für einen Kunden durchführen, müssen Sie den Umfang des Projekts kennen, um einen Kosten- und Zeitplan aufstellen zu können. Die Kosten für die Erstellung dieses Arbeitsumfangs sind in den meisten Fällen Teil der Entdeckung des Projekts. Entweder nehmen Sie einen Teil davon in Kauf, um den Auftrag zu erhalten, oder Sie stellen ihn in Rechnung (explizit oder implizit) In diesem Fall können die Projektkosten ausgearbeitet und vereinbart werden. In diesem Fall wird das Projekt in der Regel in verschiedene Phasen aufgeteilt.

Auch wenn agile Methoden iterativ sind und keine vollständige Spezifikation erfordern, so ist doch zumindest ein Ziel erforderlich. Es muss eine Form von grundlegender Spezifikation/Anforderung geben. Es kann sein, dass Sie das Projekt in kleinere Ziele aufteilen und die Kosten entsprechend ansetzen müssen.

Ich vermute, dass die Iterationen eher mit der Entwicklungsmethodik zu tun haben, d.h. mit dem Erreichen der Ziele?

Wenn es keine ausreichenden Spezifikationen gibt, um einen genauen Kostenvoranschlag zu erstellen, würde ich sagen, dass ein "Kostenvoranschlag" erstellt werden sollte, aber die Arbeit sollte nach Stundensatz abgerechnet werden, da ich davon ausgehe, dass sich die Entscheidungen, die im Rahmen des Projekts getroffen werden, bei jeder Iteration stärker ändern werden.

Answer 5

Ich habe gesehen, dass es gut funktioniert, wenn man in 2 Phasen vorgeht:

Phase 1) Anfangsphase (Timeboxed)

Eine zeitlich begrenzte Anfangsphase mit dem Kunden, um den Umfang des Projekts zu bestimmen. (Ein einmonatiger intensiver Beginn für ein Projekt, dessen Dauer auf ein Jahr geschätzt wird, ist in etwa richtig). Die Ergebnisse dieser Phase sind ein komplettes Backlog mit großen User Stories, eine Schätzung der Durchsatzrate pro Entwicklerpaar und Parameter zur Schätzung der Projektkosten auf der Grundlage der Anzahl der Entwickler und der Gemeinkosten für größere Teams.

Die Anfangsphase bietet einen nützlichen Kostenvoranschlag, der während der gesamten Phase 2 verfolgt werden kann, eine klare gemeinsame Vision für Auftraggeber und Auftragnehmer sowie die Möglichkeit für beide Seiten, das Projekt zu beenden. Es handelt sich dabei nicht um ein Upfront-Design, die Stories sind gerade detailliert genug, damit ein leitender Entwickler/Tester relative Größen zuweisen kann.

Phase 2) Lieferung (Zeit und Material)

Ein Liefervertrag auf der Grundlage von Zeit und Material, mit Budgetvoranschlägen auf der Grundlage der Ergebnisse der Anfangsphase. Das Vertrauen, das in Phase 1 aufgebaut wurde, ist entscheidend für das Gelingen dieses Projekts. Da in Phase 1 die relative Größe des gesamten Rückstands ermittelt wurde, ist es durch die regelmäßige Messung des tatsächlichen Durchsatzes möglich, die voraussichtliche Durchsatzrate für den Rest des Rückstands mit immer genaueren Schätzungen des Budgets und des Liefertermins einfach und häufig zu melden. Der Lieferant sollte beauftragt werden, diese Statistiken mindestens alle zwei Wochen zu melden, wobei der Kunde die Möglichkeit hat, jederzeit auszusteigen.

Durch die Bezahlung nach Zeit und Material steht es dem Kunden frei, den Umfang und die Proirität des Rückstands zu ändern, und er hat somit die Kontrolle über das Budget. Er wird dazu angehalten, die Projekte mit der höchsten Priorität und dem höchsten Risiko zuerst zu bearbeiten, und da er jederzeit aus dem Projekt aussteigen kann, sollte er jederzeit eine positive Investitionsrendite erzielen.