Können wir besser erklären, dass Unternehmen die Softwareentwicklung kostengünstiger gestalten und zugleich die Qualität erhöhen können? Also im Prinzip nur dadurch, dass ihre Softwareteams den Auslieferungsprozess automatisieren? Also letztlich.

Klingt wie ein falsches Versprechen, ist es aber nicht. „Fail Fast“ macht die Software besser. Und es hat den neben effekt, dass „früh erkannte Fehler“ einfacher zu beheben sind.

Fortunately, there’s a simple technique that will dramatically reduce the number of these bugs in your software. It won’t reduce the overall number of bugs, at least not at first, but it’ll make most defects much easier to find. The technique is to build your software to “fail fast.”

Martin Fowler „Fail Fast“ – https://www.martinfowler.com/ieeeSoftware/failFast.pdf

Auf Führungsebene wird eine entsprechende Kennzahl verkannt. Fataler Weise. In der Praxis konnten wir nachweisen, dass eine Überwachung der „Delivery Frequency“ oder Auslieferungsfrequenz zu besserer Qualität führt und signifikate Kosten spart. Reduzierung der Entwicklungszeit und -kosten ist schließlich das Ziel.

Eine theoretische Argumentation folgt direkt aus der reinen Lehrer der agilen Softwareentwicklung. Martin Fowler – ein Unterzeichner des agilen Manifests – beschreibt Continuous Integration und Continuous Delivery im Detail in einem sehr lesenswerten Blogartikel.

Integrationsaufwand wird unterschätzt

Während der Planung wird der Integrationsaufwand vom gesamten Team unterschätzt. Nicht einbezogen wird, dass bei steigender Anzahl an parallel entwickelter Features die Anzahl der Integrationskonflikte steigt. Führt nur ein Viertel der parallel entwickelten Features zu Konflikten, die je in ungefähr 0,5h bis 2,5h (je nach Komplexität) aufgelöst werden können, wird klar, wieso dieser Faktor leicht unterschätzt wird.

Potentiale und Steuerungsmöglichkeiten im Management

Selbst innerhalb vieler Entwicklungsteams ist oft nicht klar, dass der Aufwand, verschiedene Änderungen letztlich zusammenzuführen, erheblich ist. Fehler fallen erst spät im Entwicklungsprozess auf. Das macht diese Fehler aufwändig zu beheben. Teilweise muss wochenalter Code seziert werden und die Fehlerursache zu finden. Selbst bei guter Codequalität kann das schnell mal 20% der Teamkapazität blockieren.

Selbst wenn das Release Management gut ist, also diese 20% je Release eingeplant wird und so eine pünktliche Lieferung gesorgt ist (in den meisten Fällen leistet das Management genau das nicht), könnten 20% eingespart werden. Das bedeutet: In schlimmen Fällen fließen mehr als 10.000€ an Teamkosten nicht in das Produkt. Sondern sind verschwendete Kosten. Und erzeugen Frust bei Kunden und Entwicklern. Es muss einen anderen Weg geben, die Softwareentwicklung kostengünstiger zu gestalten.

Annahmen im Modell

Unser Modell macht einige konservative Grundannahmen basierend auf Erfahrungswerten:

• Ein niedrig angesetzter Stundensatz von 45€ pro Entwickler
• Ein Releasezyklus von 4 Wochen
• Eine durchschnittliche Entwicklungszeit von 13 Stunden je Feature
• Eine Wahrscheinlichkeit von 25%, dass Konflikfehler bei der Integration auftreten

Desweiteren setzen wir an, dass die Behebung eines Fehlers, bei der Integration vieler Änderungen gleichzeitig, optimistische 2,5 Stunden benötigt. Fehler bei kleineren Änderung können Entwicklungsteams in durchschnittlich etwa 0,5 Stunden auflösen.

Fazit: Rechner zeigt einfach, wie Softwareentwicklung kostengünstiger wird

Der Rechner zum Einsparungspotenzial von Lieferautomatisierungen kann möglicherweise ein Bewusstsein im Management schaffen, wie fast die gesamte teuere Kapazität eines Teams in Nutzen umgesetzt werden kann und damit jeden Monat tausende Euros eingespart werden können. Den Rechner zum Einsparungpotenzial finden Sie direkt auf unserer Startseite https://www.kehrwasser.com.