Agile Softwareentwicklung: Wie reagieren Sie * finanziell * auf sich ändernde Benutzeranforderungen?

Es gibt eine Sache, die ich mich immer gefragt habe, wenn ich über all diese "agilen Entwicklungsaufgaben" hier auf SE und anderen Websites gelesen habe:

Im "traditionellen" Software-Engineering sind Sie

1. die Anforderungen des Benutzers sammeln,
2. eine Spezifikation schreiben, die auf diesen Anforderungen basiert,
3. Geben Sie es dem Kunden und stellen Sie ihm die bisher geleistete Arbeit in Rechnung.
4. Erstellen Sie ein (grobes) technisches Design, damit Sie die Kosten für die Implementierung abschätzen können.
5. Geben Sie dem Benutzer ein Preisangebot für die Implementierung,
6. Warten Sie, bis der Kunde die Spezifikation unterschrieben hat und das Angebot annimmt.
7. entwerfen, implementieren, testen,
8. Rechnung.

Wenn sich während des Prozesses die Anforderungen ändern, senden Sie ein Angebot (mit einem Preis) für die gewünschten Änderungen (oder machen es kostenlos, wenn die Änderung klein ist, Sie mögen den Kunden und der Kunde tut es nicht zu oft). .

Wie funktioniert dies (finanziell) in einem agilen Projekt, in dem häufige Anforderungsänderungen Teil des Prozesses sind?

• Schreiben Sie für jede Designänderung ein Angebot? (Wäre das nicht ein ziemliches Durcheinander?)
• Oder verhandeln Sie einen Festpreis und hoffen, dass der Kunde die Anforderungen nicht zu oft ändert? (Könnte riskant sein, ich kenne Kunden, die diese Gelegenheit nutzen, um jahrelang neue Funktionen anzufordern, bevor sie akzeptieren, dass das Projekt abgeschlossen ist.)
• Oder stellen Sie dem Kunden nur die Gesamtzeit in Rechnung? (Könnte für den Kunden riskant sein, der die Kosten nicht im Voraus kennt.)

In einer idealen agilen Welt vereinbaren Sie im Voraus einen Preis und eine Anzahl von Stunden, jedoch keinen Umfang. Der Kunde entscheidet, welches Produkt mindestens nützlich ist, und nicht das Produkt, das er wirklich möchte, und dies sollte deutlich unter der vereinbarten Stundenzahl liegen.

Dann liefern Sie iterativ zu ihnen und sie ändern ihre Meinung, was sie wollen, aber Sie überschreiten nie die vereinbarte Stundenzahl. In der Theorie und oft auch in der Praxis erhalten sie das Produkt, das sie wirklich brauchen, und nicht das Produkt, das sie wirklich wollen.

Und wenn sie Ihnen nach dem ursprünglich vereinbarten Wert weitere Stunden bezahlen möchten, ist das auch in Ordnung. Wenn Sie den Fortschritt durch Story Cards, Greenhopper oder was auch immer sichtbar machen, können Sie dem Kunden jedes Mal, wenn er etwas Neues hinzufügt, deutlich machen, welche Funktionen er verliert (oder zumindest depriorisiert) ein Stopp für leichtfertige Veränderungen.

Hierbei sind zwei Risiken zu beachten. Erstens kann der Kunde verängstigt sein, wenn er Agility nicht von vornherein verstanden hat. Es scheint, als ob er das ganze Risiko eingeht. Nur die Erfahrung zeigt, dass er nicht wirklich ist.

Die zweite ist, dass sie während des gesamten Prozesses beschäftigt sein müssen, sonst verlieren alle. Viele Kunden verstehen nicht, wie engagiert sie sein müssen, bis es zu spät ist.

Aber wenn Sie es als Unternehmen gut genug erklären, ist jeder ein Gewinner.

Einige Menschen versuchten zu geben Lösungen Beweglichkeit zu verwenden , bei Festpreisprojekten in der Vergangenheit. Ich persönlich denke, das ist im Allgemeinen nicht möglich.

Scrum eignet sich insbesondere für Produkt-Software-Unternehmen und wird in Dienstleistungsunternehmen weniger eingesetzt.

Sie können in Ihren Projekten etwas Flexibilität einsetzen, wie z. B. Iterationen, tägliche Stand-Ups, Burndorn usw., aber ich kann Ihnen versichern, dass Sie, wenn Sie eine bestimmte Menge von Dingen zu einem bestimmten Preis anbieten und weniger liefern als im Vertrag vorgesehen, Du wirst ein Problem haben.

Bitte nicht Agility à toutes les sauces servieren . Wir müssen die geeignete Lösung für ein gegebenes Problem verwenden.

Dies hängt nicht wirklich mit der agilen Programmierung oder dem von Ihnen verwendeten Modell zusammen. Ich arbeite als Freiberufler, benutze eine Mischung aus Wasserfall und V-Modell, habe aber immer noch das gleiche Problem: Was ist, wenn der Kunde während der Detailplanung etwas ändern möchte? Was ist, wenn er während der Implementierung Änderungen vornimmt?

Welchen Ansatz Sie verwenden müssen, hängt vom Kunden und Ihren Beziehungen ab.

Wenn ein Kontakt für alles, was Sie für diesen Kunden tun, ein Muss ist, weil Sie wissen, dass er versucht, nicht zu zahlen, wenn er kann, oder er versucht, Sie zu verklagen, wann immer dies möglich ist, müssen Sie für jeden ein Angebot erstellen winzige Änderung der Anforderungen. Es ist kein Chaos: Wenn Sie gut organisiert sind, ist es möglicherweise nicht zu schwierig, eine neue Anforderung während der Entwicklung zu berücksichtigen. Es ist jedoch mit Sicherheit ein Zeit- und Geldverlust, und es ist ziemlich seltsam, ein Änderungsangebot zu unterzeichnen, dessen Umsetzung zwei Stunden in Anspruch nimmt.

Für andere Kunden ist der Ansatz, der gut funktioniert, der folgende:

• Geben Sie bei der Unterzeichnung des ersten Angebots die geschätzten Kosten und die maximalen Kosten an. Geschätzte Kosten bedeuten rechtlich nichts: Es ist nur eine Schätzung. Die maximalen Kosten haben gesetzlichen Wert: Wenn Sie sagen, dass das Produkt für Ihren Kunden 3.000 USD kostet und es Sie schließlich 3.157,24 USD kostet, muss der Kunde immer noch 3.000 USD bezahlen. In der Praxis liegen die tatsächlichen Kosten in den meisten Fällen unter dem angegebenen Höchstwert und näher an Ihrer Schätzung.

• Wenn der Kunde eine Anforderung ändern möchte, schätzen Sie deren Kosten und vergleichen Sie sie mit den tatsächlichen Kosten und dem tatsächlichen Status. Wenn Sie das Produkt fast fertiggestellt haben und die tatsächlichen Kosten 2.108,36 USD betragen und die Kosten für die Änderung auf 150 USD geschätzt werden, tun Sie es einfach. Wenn andererseits die Gefahr besteht, dass das Maximum erreicht wird, teilen Sie Ihrem Kunden mit, dass Sie die Gesamtkosten gemeinsam neu bewerten müssen.

Agil und 'Write a offer' scheint ein Gegensatz zu sein :) - Letzteres ist kein produktives Software-Engineering: D

Okay, jetzt haben wir den Witz aus dem Weg - zurück zur Realität.

"Wie funktioniert es in Agile ?" - Der Vertrag kompliziert die Dinge, aber ich hoffe, es klar zu machen. Agile basiert auf dem Prinzip von "Vertrauen" und "Zusammenarbeit", was bedeutet, dass der Kunde jederzeit und überall Änderungen vornehmen kann und versteht, dass dies ein bisschen mehr kosten kann oder, wenn es nicht aufdringlich ist, möglicherweise ohne zusätzliche Kosten.

Was bedeutet das? Dies bedeutet, dass der Vertrag festlegt, dass wir (der Kunde) einen anfänglichen Kostenvoranschlag und die +/- Abweichung in% festlegen, die wir verarbeiten können, z. B. ein Gebot von 100.000 USD, aber ich bin bereit, bis zu 120.000 USD zu gehen (dies KANN NICHT sein) Teil des Vertrages, aber im Kopf des Kunden).

Wenn nun eine Designänderung eintritt, gehen Sie agil mit der Schätzung und Planung um - Sie stellen Ihr Team zusammen und fragen sie nach dem „Story Point“, der die Komplexität der Faktorisierung der Änderungen einschätzt. Aufgrund einer Geschwindigkeitsschätzung können Sie diese multiplizieren und eine Zeitplanschätzung abgeben. Es sollte relativ einfach sein, die Kosten pro Story-Punkt zu ermitteln, wenn Sie das Team und seine relativen Gehälter kennen (bitte nicht über das Gehalt von JEDEM Durchschnittslohn mitteln, da Sie den Durchschnittsfehlern unterliegen).

Müssen Sie mit den Finanzdaten zum Kunden zurückkehren? NEIN. Nicht unbedingt. Sie lassen diese vom Kunden priorisieren und an der richtigen Stelle im Backlog einfügen. Jetzt, da Sie die Größe des Rückstands kennen (sollten Sie dies nicht bereits tun) und anhand der Finanzdaten (Kosten pro Story-Punkt) wissen, welche Anforderungen mit niedriger Priorität mit dem angegebenen Budget möglicherweise nicht umsetzbar sind. Zeigen Sie ihnen den neu priorisierten Rückstand mit der Schätzung der ausführbaren Funktionen gemäß Vertrag. Dann lassen Sie SIE entscheiden, ob sie bereit sind, mehr zu zahlen, um mehr zu bekommen, wenn Sie dort ankommen. Wenn sie es kostenlos haben wollen, nehmen Sie Stellung und sagen ihnen, dass es mehr kostet.

Dies sollte helfen, ohne dass Sie ständig auf Finanzdaten zurückgreifen müssen, wenn Sie dieses Diagramm irgendwo für den Kunden sichtbar haben.

Hoffe das hilft!

Die Erfahrung anderer Leute wird wahrscheinlich variieren, aber eine Art und Weise, wie ich es gesehen habe, ist im Großen und Ganzen die gleiche wie Ihre "traditionelle", mit ein paar Dingen, die zu beachten sind:

1. Etwas Aufwand für Änderungen einbauen (z. B. 10%)
2. Große Änderungen oder Änderungen an Aggregaten und Rechnungen, die über die integrierten Kosten hinausgehen, separat bewerten und in Rechnung stellen (ein gutes, wenn auch nicht programmierbares Beispiel ist die Entwurfsarbeit, bei der die anfänglichen Kosten häufig beispielsweise 3 Revisionen und nachfolgende Revisionen oder möglicherweise Gesamtwiederholungen umfassen extra)

Auch agile Projekte beginnen oft als "Kernelement" und drehen sich von dort aus nach Bedarf modular (ich habe gesehen, dass dies bei den Projekten, an denen ich beteiligt war, ziemlich viel passiert ist). Sie beginnen also mit einem Kernprodukt, sagen wir, es ist eine Kartenanwendung. Die erste Implementierung ist lediglich eine Karte, die sich auf Ihren aktuellen Standort bezieht (was der Kunde ursprünglich bestellt hat).

Der Kunde entscheidet dann, dass er Pin-Drops bestimmter Attraktionen in Ihrer Nähe haben möchte. Okay, das ist ein ziemlich großes Stück (relativ gesehen), also rechnen Sie es als neues "Modul" oder als Bestellung ab. Änderungen an Dingen wie der Farbe oder dem Design dieser Stifte werden in die Kosten dieser Bestellung einbezogen. Anweisungen und Überlagerungen sind eine weitere Bestellung, da sie erst angefordert wurden, nachdem die andere Bestellung ausgeführt wurde, und so weiter und so fort.