Sie müssen agile Projekte mit einem festen Budget verwalten? So geht's.

Die Art der agilen Softwareentwicklung bedeutet, dass man nicht alle Details der zu entwickelnden Software im Voraus kennen kann. Das kann die Vorhersage eines genauen Budgets erschweren. Wie Jon Last, Head of UK Delivery bei NashTech, erklärt, gibt es jedoch Möglichkeiten, ein hohes Maß an Budgetsicherheit zu gewährleisten, ohne die Projektflexibilität oder die Qualität des Endprodukts zu beeinträchtigen.

Wie bringen Sie ein festes Projektbudget mit einer sich schnell verändernden Welt in Einklang?

Jedes Softwareentwicklungsprojekt muss widersprüchliche Anforderungen ausgleichen. Die häufigsten sind Zeit, Kosten, Funktionen und Qualität – aber der Versuch, alle vier zu Beginn eines Projekts festzulegen, ist im Allgemeinen unrealistisch. Das wäre vielleicht in einer perfekten Welt möglich, in der sich die geschäftlichen Anforderungen nie ändern, alles im Voraus klar ist und nie Probleme auftreten – aber wir leben nicht in einer solchen Welt!

Glücklicherweise sind sich die meisten Unternehmen heute darüber im Klaren, weshalb die agile Entwicklung zum bevorzugten Mittel für Entwicklungsteams geworden ist, um auf die sich ändernden Anforderungen des Unternehmens reagieren zu können. Agilität ermöglicht es Ihnen, die typischen Herausforderungen der modernen digitalen Organisation anzunehmen:

Erkennen und Fördern von Veränderungen
Zusammenarbeit und Lernen fördern
Schnellerer Wertzuwachs

Gleichzeitig fördert Agile das Lean Thinking, das davon abhält, alles im Voraus zu spezifizieren. Eine Folge davon ist, dass das Team in der Regel keine Schätzung erstellen wird, die die Erstellung eines Basisbudgets ermöglicht.

Wie können Sie also ein genaues Budget vorhersagen, wenn Sie noch nicht im Detail wissen, was Sie bauen wollen?

NashTech hat Erfahrung darin, Kunden bei der Verwaltung von Projekten mit festen Budgets zu helfen. Unsere Responsive Offshore Agile Delivery (ROAD)-Methode und unsere Engagement-Modelle bieten ein höheres Maß an Budgetsicherheit, ohne die Agilität des Projekts oder die Qualität des Endprodukts zu beeinträchtigen. Wir unternehmen die folgenden wichtigen Schritte.

1. Legen Sie ein realistisches Budget fest, das auf einer groben Schätzung der Größenordnung des lebensfähigen Mindestprodukts beruht.

In der Regel beginnen wir mit der Durchführung von Anforderungsworkshops, um eine erste Reihe von Themen und Funktionen zu definieren. Wir verwenden eine Reihe von Techniken (z. B. die MoSCoW-Methode der Priorisierung), um diese Epen und Funktionen zu kategorisieren und zu entscheiden, welche davon Teil des Minimum Viable Product (MVP) sein sollen, um die anfänglichen und grundlegenden Bedürfnisse der Benutzer zu erfüllen.

Im Rahmen des MVP empfehlen wir, zwischen den Themen und Funktionen zu unterscheiden, die gut definiert und verstanden sind, und denen, die unsicher oder schwieriger zu verstehen sind. Diese Arbeit ist von entscheidender Bedeutung für die Bestimmung der potenziellen Budgetspanne für das MVP, da komplexe und schwer verständliche Epen mit einem höheren Maß an Unsicherheit behaftet sind und somit eine Erhöhung des Budgetkoeffizienten bewirken.

Parallel dazu empfehlen wir die Durchführung von technischen Workshops, um die Anforderungen zu erfassen und zu definieren, wie die Lösung aussehen soll, um sie zu erfüllen. Auf diese Weise können wir Bereiche mit technischen Risiken in der vorgeschlagenen Lösung ermitteln, was wiederum die Budgetspanne beeinflusst.

Wir kombinieren dann die Erkenntnisse über das spezifische Projekt des Kunden mit unserer umfangreichen Wissensbasis zur Schätzung, um eine Schätzspanne für den Aufwand zu berechnen, der für die Bereitstellung des MVP erforderlich ist. Die Schätzung wird in Personentagen ausgedrückt, umgerechnet in die Anzahl der Entwicklungssprints eines typischen NashTech-Scrum-Teams.

Darüber hinaus bewerten wir das Projekt anhand eines “Unsicherheitskegels”, der auf dem Reifegrad und den damit verbundenen Risiken basiert:

Die Anforderungen
Die technische Architektur
Eine allgemeine Risikobewertung der Entwicklungsumgebung – einschließlich Faktoren wie die Erfahrung mit der Anwendung agiler Prozesse in früheren Projekten

Die Anzahl der Entwicklungssprints wird dann mit dem Koeffizienten aus der Unsicherheitsbewertung multipliziert, um die minimale und maximale Anzahl von Sprints und damit die Kostenspanne für die Bereitstellung des MVP-Umfangs zu berechnen.

Wir sind uns natürlich bewusst, dass unsere Kunden möglicherweise andere Ansätze verfolgen wollen. Wir arbeiten mit Ihnen zusammen, um von Anfang an zu vereinbaren, was “MVP-Umfang liefern” bedeutet. Darüber hinaus liefern wir während der gesamten Lieferphase Input und Feedback zu den Optionen und ihren Auswirkungen, wenn sich Ihre geschäftlichen Anforderungen und Prioritäten als Reaktion auf die Kundenwünsche ändern.

2. Liefern Sie das Minimum Viable Product durch eine Reihe von Sprints und prognostizieren Sie die verbleibende Zeit

Wir empfehlen, bei der Sprintplanung nur die User Stories zu berücksichtigen, die für das MVP ein Muss sind, und die anderen im Product Backlog zu belassen.

Wir schlagen außerdem vor, die Bereitstellung von Funktionen zu planen, mit denen die primären Konzepte und Hauptabläufe so früh wie möglich getestet werden können, um funktionale und technische Risiken und Ungewissheiten zu ermitteln und zu beseitigen. Wenn man dies frühzeitig tut, besteht eine gute Chance, einfachere Bereiche zu beschleunigen oder Gespräche über eine Verringerung des Umfangs zu ermöglichen, bevor es zu spät ist, um größere Auswirkungen zu vermeiden.

Schnelles Feedback bei Agile bedeutet, dass eine Änderung der Prioritäten schnell akzeptiert wird und neue Ideen und Anforderungen leicht hinzugefügt werden können. Ebenso können veraltete Konzepte mit geringen oder gar keinen Kostenfolgen entfernt werden. Es ist von entscheidender Bedeutung, eine rücksichtslose Disziplin aufrechtzuerhalten, so dass nur echte “Must-haves” übrig bleiben.

Natürlich ist das Feedback des Kunden – durch die Teilnahme an Stand-ups, Sprint-Demonstrationen und Retrospektiven – von entscheidender Bedeutung, um Missverständnisse aufzudecken und den Prozess kontinuierlich zu verfeinern und zu optimieren. Anschließend wird der ursprüngliche Plan anhand des Lieferdurchsatzes (Velocity) bewertet. Tatsächliche Unter- oder Überschätzungen der Story Point-Lieferung werden dann verwendet, um das wahrscheinliche Lieferdatum und die Kosten des aktuellen MVP neu zu kalibrieren.

Dieser wachsende Bestand an empirischen Daten wird dann die Grundlage für die Extrapolation der voraussichtlichen Zeit und Kosten des gesamten Anforderungsrückstands bilden.

Wie NashTech helfen kann

Die Einhaltung des Budgets bei agilen Projekten bringt eine Reihe von Herausforderungen mit sich. Wir kennen diese Herausforderungen und haben unseren Ansatz angepasst, um sie zu bewältigen, indem wir den Schwerpunkt auf Dialog, Verfeinerung und Iteration legen – und das alles zunehmend auf der Grundlage aktueller Informationen, je weiter ein Projekt fortschreitet.

Unser Ansatz führt zu einer ersten Schätzung mit einem Vertrauensniveau, das auf den zu Beginn verfügbaren Informationen basiert, und stützt sich auf unser empirisches historisches Wissen. Wir bieten einen Rahmen für die ständige Neukalibrierung von Schätzungen und unterstützen die Entscheidungsfindung des Unternehmens hinsichtlich der Prioritäten des Projektumfangs zum frühestmöglichen Zeitpunkt.

Um herauszufinden, wie NashTech Ihrem Unternehmen dabei helfen kann, die Budgetsicherheit agiler Projekte zu verbessern, ohne Kompromisse bei der Umsetzung einzugehen, besuchen Sie unsere
Software-Entwicklungsdienstleistungen
oder senden Sie eine E-Mail an info@nashtechglobal.com und ein Mitglied des Teams wird sich mit Ihnen in Verbindung setzen.