Die Zeiten des alten Wasserfallmodells sind jedoch längst vorbei. Doch der modernere Ansatz von Scrum mit seinen zwei- bis sechswöchigen festen Sprints (die potenziell Zeit verschwenden) schützt die Entwickler nicht davor, das falsche Produkt zu entwickeln. Lassen Sie uns die Rechnung auf der Grundlage eines 4-wöchigen Sprints machen. Nehmen wir an, ein Unternehmen mit 50 Entwicklern arbeitet Vollzeit an seinem Softwareprodukt. Wenn 75 % der Zeit auf die Entwicklung neuer Funktionen entfallen, sind das insgesamt 6.000 Stunden, die während eines dieser Sprints für neue Funktionen aufgewendet werden.
Das ist eine Menge Arbeit und Zeit, die Sie investieren, bevor Sie ein Feedback erhalten.
Natürlich gibt es interne Feedback-Mechanismen, aber am Ende des Tages zählt das Urteil der Kunden. Es gilt, die Zeit zwischen Entwicklung und Bereitstellung zu minimieren.
Unser Ziel ist es, alle neuen Funktionen zu veröffentlichen, sobald sie die Qualitätssicherung bestanden haben. In der Tat streben wir eine Veröffentlichung an – zumindest für unsere Release Candidate-Kunden – sobald das Minimum Viable Product einer bestimmten Funktion die Qualitätssicherung bestanden hat.
In der Praxis wird dies mit Hilfe des Kanban-Prozesses erreicht, bei dem jede Funktion unseren Entwicklungsprozess der Analyse, Entwicklung und des Testens unabhängig von anderen Funktionen durchläuft. Für jede Funktion wird ein neues Installationspaket erstellt, das sofort eingesetzt werden kann.
Dadurch wird die Verschwendung im Entwicklungsprozess minimiert und es bleibt mehr Zeit für die Entwicklung großartiger Funktionen, was zu einem besseren Produkt für die Kunden führt.
