{"id":687,"date":"2023-07-27T10:23:27","date_gmt":"2023-07-27T08:23:27","guid":{"rendered":"https:\/\/www.kehrwasser.com\/blog\/?p=687"},"modified":"2023-07-31T12:59:10","modified_gmt":"2023-07-31T10:59:10","slug":"das-simulationsmodell-hinter-unserem-automatisierungsrechner-softwareentwicklung-kostenguenstiger","status":"publish","type":"post","link":"https:\/\/www.kehrwasser.com\/blog\/2023\/07\/27\/das-simulationsmodell-hinter-unserem-automatisierungsrechner-softwareentwicklung-kostenguenstiger\/","title":{"rendered":"Das Simulationsmodell hinter unserem Automatisierungsrechner"},"content":{"rendered":"

K\u00f6nnen wir besser erkl\u00e4ren, dass Unternehmen die Softwareentwicklung kosteng\u00fcnstiger gestalten und zugleich die Qualit\u00e4t erh\u00f6hen k\u00f6nnen? Also im Prinzip nur dadurch, dass ihre Softwareteams den Auslieferungsprozess automatisieren? Also letztlich.<\/p>\n

Klingt wie ein falsches Versprechen, ist es aber nicht. „Fail Fast“ macht die Software besser. Und es hat den neben effekt, dass „fr\u00fch erkannte Fehler“ einfacher zu beheben sind.<\/p>\n

Fortunately, there\u2019s a simple technique that will dramatically reduce the number of these bugs in your software. It won\u2019t reduce the overall number of bugs, at least not at first, but it\u2019ll make most defects much easier to find. The technique is to build your software to \u201cfail fast.\u201d<\/p>\nMartin Fowler „Fail Fast“ – https:\/\/www.martinfowler.com\/ieeeSoftware\/failFast.pdf<\/a><\/cite><\/blockquote>\n

Auf F\u00fchrungsebene wird eine entsprechende Kennzahl verkannt. Fataler Weise. In der Praxis konnten wir nachweisen, dass eine \u00dcberwachung der „Delivery Frequency“ oder Auslieferungsfrequenz zu besserer Qualit\u00e4t f\u00fchrt und signifikate Kosten spart. Reduzierung der Entwicklungszeit und -kosten ist schlie\u00dflich das Ziel.<\/p>\n

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.<\/a><\/p>\n

Integrationsaufwand wird untersch\u00e4tzt<\/h4>\n

W\u00e4hrend der Planung wird der Integrationsaufwand vom gesamten Team untersch\u00e4tzt. Nicht einbezogen wird, dass bei steigender Anzahl an parallel entwickelter Features die Anzahl der Integrationskonflikte steigt. F\u00fchrt nur ein Viertel der parallel entwickelten Features zu Konflikten, die je in ungef\u00e4hr 0,5h bis 2,5h (je nach Komplexit\u00e4t) aufgel\u00f6st werden k\u00f6nnen, wird klar, wieso dieser Faktor leicht untersch\u00e4tzt wird.<\/p>\n

Potentiale und Steuerungsm\u00f6glichkeiten im Management<\/h4>\n

Selbst innerhalb vieler Entwicklungsteams ist oft nicht klar, dass der Aufwand, verschiedene \u00c4nderungen letztlich zusammenzuf\u00fchren, erheblich ist. Fehler fallen erst sp\u00e4t im Entwicklungsprozess auf. Das macht diese Fehler aufw\u00e4ndig zu beheben. Teilweise muss wochenalter Code seziert werden und die Fehlerursache zu finden. Selbst bei guter Codequalit\u00e4t kann das schnell mal 20% der Teamkapazit\u00e4t blockieren.<\/p>\n

Selbst wenn das Release Management gut ist, also diese 20% je Release eingeplant wird und so eine p\u00fcnktliche Lieferung gesorgt ist (in den meisten F\u00e4llen leistet das Management genau das nicht), k\u00f6nnten 20% eingespart werden. Das bedeutet: In schlimmen F\u00e4llen flie\u00dfen mehr als 10.000\u20ac 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\u00fcnstiger zu gestalten.<\/p>\n

Annahmen im Modell<\/h4>\n

Unser Modell macht einige konservative Grundannahmen basierend auf Erfahrungswerten:<\/p>\n