Warum wir bei unserer Produktentwicklung einen iterativen Ansatz verfolgen

Daher verfolgen wir einen iterativen Softwareentwicklungsansatz. Dies macht sich wie folgt direkt für unsere Kunden bemerkbar:
Für einige unserer Kunden, die es gewohnt sind mit traditioneller On-Premise-Software zu arbeiten, kann dieser Entwicklungsansatz auf den ersten Blick verwirrend wirken. Diese Kunden erwarten weniger häufige Releases, die dann auch auf Kundenseite umfangreich vorbereitet werden müssen, um sicherzustellen, dass die Software nach dem Update weiterhin zuverlässig funktioniert. Solche Releases sind typisch für Software, die mit einem wasserfallartigen (linearen) Ansatz entwickelt wird. Updates für solche Software werden oft unregelmäßig veröffentlicht, zum Beispiel „ungefähr zweimal im Jahr“. Dementsprechend enthalten sie sehr umfangreiche Änderungen, die schwer nachzuvollziehen sind und das erwartete Verhalten der Software unter Umständen radikal ändern. Solche Updates können aufgrund ihrer Komplexität dazu führen, dass die Software das Anwendungsszenario des Unternehmens nicht länger unterstützt. Im schlimmsten Fall sorgt dies für Chaos in den Betriebsabläufen.
Dementsprechend sind Kunden, die an wasserfallartige Releases gewöhnt sind, besorgt, dass jedes Softwareupdate zu Problemen führen kann. Um auf Nummer sicher zu gehen, fragen solche Kunden häufig umfangreiche Versionsinformationen vor jedem Softwareupdate an und überprüfen genau, was sich verändert hat, bevor ein Release „live geht“.
In diesem Artikel gehen wir auf diese Vorbehalte im Detail ein und erklären, warum wir denken, dass unser iterativer Entwicklungsprozess unseren Kunden den größten Mehrwert bietet.
Iterative Softwareentwicklung ist mehr als nur ein Trend. Für unsere Kunden und uns bietet der Ansatz weitreichende praktische Vorteile.
Die regelmäßige Veröffentlichung von Änderungen in jeweils überschaubarer Größenordnung verringert das Risiko, dass kritische Fehler von der Qualitätssicherung nicht entdeckt werden, da Entwickler gezwungen sind, ihre Arbeit in kleine, übersichtliche Teilaufgaben herunterzubrechen. Zudem fallen Fehler, die sich in ein Release schleichen, typischerweise auf, bevor eine zusätzliche Funktionalität auf Basis des fehlerhaften Programmcodes implementiert wird. Natürlich unterlaufen auch uns Fehler. Aber der iterative Entwicklungsansatz erlaubt es uns, die Anzahl und das Ausmaß der Fehler signifikant zu reduzieren – bei gleichbleibenden Kosten für die Qualitätssicherung. Und je weniger Fehler sich in ein Release einschleichen, desto schneller können wir die Fehler, die auftreten beheben, um uns anschließend wieder auf die Weiterentwicklung unserer Produkte zu konzentrieren.
Kurze Releasezyklen ermöglichen es uns, Features direkt dann zu veröffentlichen, wenn sie einen ersten Nutzen für einen Kunden bieten. Erweiterungen und Verbesserungen der User Experience folgen oft in späteren Releases. Damit steht unseren Kunden der wichtigste Mehrwert des Features so schnell wie möglich zur Verfügung. Zudem erhalten wir früh Feedback und können somit bei der Produktentwicklung besser auf die Anforderungen unserer Kunden eingehen.
Obwohl einige Features beim initialen Release nicht optimal sind, können sie immer direkt zur Lösung von Business-Problemen bei unseren Kunden beitragen. Das Release eines minimalen Features ist in der Regel besser als gar kein Release. Zudem minimiert die Veröffentlichung von Änderungen in kleinen Schritten die Anzahl von radikalen Änderungen („breaking Changes“). Im Gegensatz zu traditioneller Business-Software enthalten unsere Releases nur in Ausnahmefällen breaking Changes, die dann mit entsprechender Vorlaufzeit angekündigt werden. Alle weiteren Informationen zu einem Release stellen wir unseren Kunden zum Zeitpunkt der Veröffentlichung zur Verfügung.
Durch das Unterteilen von Entwicklungsprojekten in kleine, klar abgegrenzte Arbeitspakete, die so schnell wie möglich veröffentlicht werden, verringert sich das Risiko von Kommunikations- und Spezifikationsproblemen. Ein abgeschlossenes Feature entspricht niemals dem initialen Konzept am Whiteboard. Traditionelle Entwicklungsprozesse beginnen mit einer umfangreichen Spezifikationsphase, in der umfangreiche Dokumente zur Anforderungsdefinition erstellt werden. Diese Dokumente werden nach Abschluss der Phase als final angesehen. In der Praxis verringert sich die Qualität der initialen Spezifikation mit steigender Komplexität des beschriebenen Objekts. Dahingegen erzwingen frühe und regelmäßige Releases einen Realitätscheck, der dabei hilft, falsche Annahmen zeitnah zu revidieren.
Wir sind nicht die einzige Organisation, die diese Vorteile sieht. Generell sind sich Experten einig, dass iterative Softwareentwicklung der bisher beste Ansatz zur Software-Produktentwicklung in modernen Organisationen ist. Nichtsdestotrotz arbeiten wir natürlich weiterhin an unseren Release- und Qualitätssicherungsprozessen, um die Produktqualität und Customer Experience weiter zu verbessern. Falls Sie Fragen zu unserem Release- und Entwicklungsansatz haben, kontaktieren Sie gerne das Signavio- Support-Team unter support@signavio.com.
Unser Entwicklungsteam veröffentlicht neue Versionen unserer Produkte in regelmäßigen Abständen:
In der Zukunft planen wir, die Release-Frequenz für unsere Software-as-a-Service-Produkte weiter zu erhöhen, um unseren Kunden Features und Fehlerbehebungen noch schneller zur Verfügung zu stellen.
Sie finden unsere Versionsinformationen auf unserer Website unter https://www.signavio.com/de/release-notes/.
Folgen Sie @Signavio auf Twitter, um Benachrichtigungen über alle Produkt-Updates zu erhalten.