Diese Fallstudie wird sich von anderen Fallstudien unterscheiden. Sie wird nicht so glänzend und herrlich sein, aber wir finden, dass es wichtig und interessant ist, sie mit anderen zu teilen.

Lassen Sie uns darauf eingehen.

1. Anfrage

Die Anfrage kam von einem Freund in Norwegen, der bereits zuvor unser Kunde war.

Die Aufgabe bestand darin, eine Integration zwischen zwei Apps herzustellen. Eine davon war ein riesiges webbasiertes Managementsystem für Verwaltung und Qualitätsmanagement — nennen wir es App A. Die andere war eine mobile App, die so konzipiert war, dass der Benutzer wirklich schnell und mühelos Daten von einer Baustelle sammeln konnte — wir nennen es App B.

Die Integration bestand darin, die von B gesammelten Daten zur weiteren Verarbeitung nach A zu übertragen.

2. Fundamente

Als Rocksoft haben wir ein Team gebildet, das für die Entwicklung verantwortlich ist, und dann hatten wir Kickoff-Meetings mit dem Vertreter des Kunden.

Wir haben begonnen, beide Anwendungen in dem für unsere Integration erforderlichen Umfang zu testen. Wir haben uns die Anwendungsfälle, die wir behandeln wollten, genauer angesehen.

Oberflächlich betrachtet schien die Lösung einfach zu sein. Wir mussten einen einfachen Dienst entwickeln, der für die Kommunikation zwischen den beiden Systemen verantwortlich ist.

Nach einem tieferen Verständnis der Systeme und ihrer Fähigkeiten entdeckten wir die wichtigsten Fragen und Punkte, auf die es zu achten galt, wie z. B.: Datensynchronisierung, Modellunterschiede, Identifier-Mapping, Ausfallsicherheit beider Systeme.

Nach dieser Diagnose vereinbarten wir Treffen mit Vertretern beider Anwendungen, in die der Dienst integriert werden musste. Ziel der Treffen war es, die Form der Kommunikation zwischen den Systemen zu vereinbaren und Antworten auf Zweifel und potenzielle Probleme zu finden, die sich aus der Analyse ergaben.

3. Was ist vor dem geplanten Start passiert?

Nachdem wir die wahrscheinlichsten Anwendungsfälle mit den Ingenieuren beider App-Anbieter gründlich besprochen hatten, teilten wir unseren Standpunkt zur Komplexität des Projekts mit.

Es war Freitagabend, als wir eine Antwort vom Kunden erhielten. Es hieß im Grunde: „Hey, vielen Dank für die bisherige Zusammenarbeit. Die Schätzung ist fünfmal so hoch wie unser Budget. Wir müssen das Projekt beenden, bis wir einen zahlenden Kunden für diese Integration gefunden haben.“

4. Wie kann man solche Missverständnisse (und Enttäuschungen) vermeiden?

Wenn Sie mit einem Problem zu einem Softwarehaus kommen und ein Budget dafür haben, teilen Sie es sofort mit. Das gilt sowohl für agile als auch für Wasserfallprojekte. Vielleicht ist die gewünschte Funktion nicht so einfach zu implementieren, wie Sie denken?

Sie müssen keine Angst davor haben, das Budget einem agilen Team mitzuteilen. Wenn es wirklich agil ist, können Sie die Arbeit jederzeit beenden.

Wenn Sie einen Festpreis benötigen, zahlen Sie aufgrund der Marge, die ein Entwickler zu jedem Festpreisprojekt hinzufügen muss, wahrscheinlich mehr als nötig.

Aber es gibt noch einen anderen Artikel, der die beiden Methoden beschreibt:“Agile gegen Waterfall„.