Falko und Luca unterhalten sich mit Veit Joseph von der DATEV. Er befaßt sich dort mit der systematischen Umsetzung und Weiterentwicklung von Qualitätssicherung und Teststrategien.
Mit ihm verhandeln wir shift left, was es bedeutet und wie man es umsetzt. Weiter sprechen wir über Testpyramiden und Test-Eistüten, und vor Allem die Wandlung von QS als Abschnitt des Prozesses zu QS als intrinsischer Eigenschaft des Prozesses.
In dieser Podcast-Episode wird der Fokus auf die „Shift Left“-Bewegung in der DevOps-Praxis gelegt, die für eine frühere Einbeziehung der Qualitätssicherung im Entwicklungsprozess steht. Veit Josef, ein Requirements Engineer, erklärt die Notwendigkeit dieser Verschiebung und diskutiert die technischen und organisatorischen Herausforderungen, insbesondere in Bezug auf Teststrategien und Teamdynamiken. Es wird betont, dass erfolgreiche DevOps eine ausgewogene Berücksichtigung von Entwicklung, Betrieb und Qualitätssicherung erfordert, um effiziente und effektive Ergebnisse zu erzielen.
Inhalt
- Einführung und Hintergrund des Gastes, Veit Josef
- Persönliche Definition von DevOps durch Veit Josef
- Diskussion über den Blogpost „Shift Left, nie mehr schlaflos in DevOps“
- Bedeutung und Umsetzung von „Shift Left“ in der Qualitätssicherung
- Veränderungen in DevOps durch Cloud-Native-Anwendungen
- Herausforderungen und Lösungsansätze im Kontext von On-Premise- und Cloud-Anwendungen
- Bedeutung von DevOps-Praktiken für größere Unternehmen
- Diskussion über Testing-Strategien, inklusive Testpyramide und Test-Eistüte
- Integration von Qualitätssicherung in alle Phasen der Softwareentwicklung
- Rolle von verschiedenen Teammitgliedern im Shift-Left-Prozess
- Auswirkungen von Shift Left auf Teamstrukturen und -prozesse
- Diskussion über den Einfluss von Tools und Technologien in DevOps
- Die Notwendigkeit von Kommunikation und Zusammenarbeit zwischen Entwicklungs- und Betriebsteams
Shownotes
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
DevOps. Auf die Ohren und ins Hirn.
Ein Podcast rund um DevOps.
Von Dierk Söllner, Falko Werner und Luca Ingianni.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni, Dierk Söllner und Falko Werner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns kulturelle, organisatorische und technische Aspekte.
Heute haben wir als Thema, warum die DevOps 8 links beginnen muss.
Also die Unendlichkeit beginnt links, habe ich mir erklären lassen.
Zu Gast dafür, um uns das zu erklären, haben wir Veit Josef, der Requirements Engineer ist bei der Dativ
und sich da allerhand Gedanken zu dieser Art von Topologien gemacht hat.
Veit, willkommen. Schön, dass du da bist.
Ja, schön, dass ich da sein darf. Danke für die nette Anmoderation.
Es stimmt übrigens nur zum Teil.
Ich bin aktuell Requirements Engineer bei der Dativ.
Also ja, da habe ich als Requirements Engineer angefangen.
Ich hatte vorher vor der Dativ noch ein bisschen Background, vielleicht auch als Product Owner oder Application Manager
und bin jetzt mittlerweile aber seit, naja, zwei Jahren folge ich einer neuen Passion, die da heißt
Qualitätssicherung und vor allem Qualitätssicherung von Online- oder von Cloud-Native-Anwendungen.
Und das vielleicht kurz noch zur Einordnung einer zentralen Position bei der Dativ.
Also ich bin nicht direkt in einem der…
Ja, es sind doch irgendwie 250 plus minus x Produkte, die wir so im Portfolio haben.
Nicht in einem dieser Entwicklungsteams, sondern ja, wie gesagt, in einer zentralen Position.
Und wir sehen viele der Produkte und vor allem der neueren Entwicklungen an uns vorbeikommen, zwangsläufig.
Und bei diesem vielen Vorbeikommen kriegt man viel mit und will aber auch viel mitgeben.
Und genau da bewege ich mich gerade ein bisschen.
Sehr schön.
Dann bevor wir uns als eigentliches Thema machen.
Wir haben ja eine Tradition in diesem Podcast, dass wir jeden Tag…
…den Gast nach seiner persönlichen Definition von DevOps fragen.
Und das Schöne daran ist, dass jeder Recht hat.
Insofern, Veit, was ist denn deine persönliche Definition von DevOps?
Ich weiß gar nicht, ob ich jetzt überrascht tun soll oder ob ich eigentlich weiß, dass diese Frage auf mich zukommt.
Also ich würde mich tatsächlich so ein bisschen an der Lexikon oder vielleicht auch an der Wikipedia-Definition halten wollen.
Also ein Team wird durch Nutzung oder gemeinsame Nutzung von Werkzeugen, Entwicklungswerkzeugen im weitesten Sinne und auch Vorgehen,
aber auch die Infrastruktur und Prozesse, die es vielleicht schon gibt, die sie aber dann gemeinsam nutzen, in die Lage versetzt,
Gesamtverantwortung für die Entwicklung und den Betrieb eines Produkts zu übernehmen.
Und neben den Vorteilen, die man sich damit erkauft, also sowas wie, ich kann Software und Produkte kontinuierlicher, schneller und stabiler entwickeln,
werden dabei noch, und das habe ich jetzt ganz oft schon gemerkt, vor allem in so größeren Unternehmen,
wie Data, würde ich jetzt sagen, einfach mal…
Zumindest in die Mitte der Bandbreite einordnen, kann mit so einem Vorgehen oder mit DevOps an sich auch ganz gut so gewachsene Organisationsstrukturen,
man spricht ja da gerne auch von Silos, nicht niederreißen, aber zumindest denen ganz gut begegnen und die Hürden ein bisschen tiefer setzen.
Und auch so, weil ich gerade Prozesse angesprochen habe, so bürokratische Verkrustungen so ein Stück weit auch auflösen.
Auch dabei hilft es.
Sehr schön. Und insofern, wir haben dich eingeladen, weil wir an einem Blogpost von dir vorbeigekommen sind,
den wir recht interessant fanden, der da hieß Shift Left, nie mehr schlaflos in DevOps.
Erzähl doch mal, was war denn dein Witz dabei?
Ja, so witzig ist es vielleicht gar nicht, aber DevOps, zumindest in der Dativ, ist, soweit ich es beurteilen kann,
also es ist, glaube ich, nicht die erste DevOps-Welle, die durch die Dativ gleitet, aber zumindest eine ganz große jetzt.
Und das spielt uns in der zentralen QS auf der einen Seite in die Karte, auf der anderen Seite geht das so ein bisschen vor allem aus unserer zentralen Anspruchshaltung,
muss man schauen, dass man nicht die Ziele, die wir verfolgen, damit irgendwie so ein bisschen dagegen schießt, sage ich mal.
Und bei uns, so meine Beobachtung, war es ganz oft so, dass man sehr gerne neue Wellen ganz oben reitet und sich erst mal darauf konzentriert,
was bringt denn jetzt diese neue Orientierung oder diese zusätzliche Orientierung?
Ich muss vielleicht davor wegschicken noch, die Dativ befindet sich gerade in einem relativ großen Change, sage ich mal.
Was unser Portfolio anbelangt, also diese 250 plus X-Produkte, die ich vorhin mal angesprochen habe,
die sind hauptsächlich On-Premise-Anwendungen, also die bei unseren Kunden und Kundinnen, Kanzleien größtenteils, Steuerberater installiert werden
und die natürlich großen Release-Zügeln unterliegen, da kommt mal da im halben Jahr oder einem Jahr eine CD oder eine DVD raus.
Und jetzt ist man aber der Meinung und der gleichen Meinung bin ich auch, dass wir ganz viele unserer Anwendungen oder Prozesse,
in die Cloud heben müssen, um es jetzt mal ganz einfach zu beschreiben.
Und da ist DevOps natürlich, sage ich mal, bietet ein ganz reichhaltiges Portfolio an Dingen und Methoden und Vorgehensweisen, die das möglichst gut unterstützt auch.
Aber wie ich gesagt habe, Dinge, die ich beobachte, sind, wenn etwas vielleicht neu ist oder man es gerade irgendwie hoch hält und vielleicht auch hoch jubelt,
ich will nicht gegen DevOps schießen, aber das führt oft dazu, dass man sich auf diese neuen Sachen vor allem einschießt.
Okay, was?
Diese schöne neue DevOps-Welt. Jetzt haben wir auch Ops in der Entwicklung mit drin.
Jetzt können wir auch über Dinge reden wie, weiß ich nicht, jetzt schmeiße ich mal ein paar Begriffe um mich,
A-B-Testing, Kern-Release, Blue-Green-Deployment und was mir alles verbindet, vor allem mit der rechten Seite der DevOps 8,
Monitoring as a Service und solche Geschichten.
Und vergiss dabei oftmals, bewusst oder unbewusst, dass wir ja auch, das ist ja eine 8 und ich habe ja nicht umsonst gesagt, die beginnt links,
dass wir halt eine linke Seite auch haben.
Und da vielleicht in der Vergangenheit geprägt durch, wie wir aufgestellt waren mit On-Premise-Anwendungen, Dinge getan haben,
die uns in der neuen Welt, will ich es mal benennen, also in der Online-Welt, so nicht mehr funktionieren und so auch nicht mehr helfen würden.
Und wenn wir uns jetzt nur auf den rechten Teil konzentrieren würden, dann würden wir den linken noch mehr außer Acht lassen und wir würden in eine Schieflage geraten.
Weil ich glaube schon, ich nenne es immer gerne das System DevOps, dass das ein System ist, das nur funktioniert, wenn wir die beiden Seiten irgendwie,
und das hat ganz unterschiedliche…
Die Perspektive, wenn die beiden Seiten möglichst in Balance halten.
Und eine Balance entsteht eben mal nicht, wenn ich mich nur auf eine Seite konzentriere und die andere vielleicht so ein bisschen neben links liegen lasse,
sondern ich muss schon schauen, dass ich da im Gleichschritt marschiere, sozusagen.
Um noch den Bogen zu spannen zu dem Titel.
Ich wollte damit zeigen, ich habe natürlich mich eines besonders schwarzen Szenarios bedient, sage ich mal.
Nämlich, wenn man jetzt irgendwie, okay, jetzt haben wir auch Betrieb, den wir verantworten.
In unserem Produktentwicklung.
Was passiert denn eigentlich, wenn die Hotline klingelt oder wenn irgendwelche Monitoring-Systeme anschlagen, irgendwelche Alerts aufpoppen,
weil wir Dinge detektiert haben, Fehlnutzung oder Fehlersituationen.
Wir müssen ja damit umgehen und im Zweifel, wann passieren die Dinge?
Ja, nicht um Dienstag irgendwie 14 Uhr, wo noch alle in Kraft und Saft sind, sondern im Zweifel am Wochenende.
Und irgendjemand erwischt es, der hat heute das Notfall-Handy irgendwie neben dem Bett liegen und muss reagieren.
Und damit uns solche Situationen nicht passieren oder dass wir eine gute Strategie haben, um mit solchen Situationen, wenn sie denn passieren, umgehen zu können,
wollte ich sagen, lass uns erstmal links auch investieren, damit wir eben das Risiko, dass rechts irgendwas schiefläuft, minimieren können.
Beziehungsweise gute Vorgehensweisen haben, um da rechts auch agieren zu können.
Und so ist es zu dem Titel gekommen.
Aber jetzt müssen wir, ich glaube, jetzt müssen wir nochmal einen Schritt zurück machen und unsere Hörer so ein bisschen einsammeln.
Wovon wir hier eigentlich die ganze Zeit reden, von irgendwelchen Achten mit links und rechts und so.
Es geht natürlich um diese berühmte liegende Acht, dieses Unendlichkeitssymbol, das ganz gerne verwendet wird in der DevOps-Literatur.
Und das hat logischerweise zwei Seiten, eine linke und eine rechte.
Und auf der rechten Seite vor Ort ist DoFight, diese ganzen Dinge, Release, Deployment, Monitoring, Ops.
Also auch das, wenn man…
Wenn man es sich linear vorstellen würde und nicht als liegende Acht, dann würden wir auch sagen, das ist halt so das Strom ab.
Also das Richtige, das Betriebsseitige.
Und auf der linken Seite steht bei dir dann so Dinge wie Code und Plan und Test und Build.
Also die Dinge, die traditionell eher so in Richtung der Entwicklungswelt gehen.
Also vielleicht mit der Grenze da, wo das Produkt zum Kunden übergeht, sage ich mal.
Das ist vielleicht die rechte Seite und davor, das ist die linke Seite, ja.
Genau. Und die Prämisse deines Artikels ist ja wohl die, dass…
erfolgreich sein zu können in einer DevOps-Welt, man seinen Fokus mehr auf diese linke Seite legen muss,
dass man bereits früher in diesem DevOps-Wertstrom auf Qualität achten muss, für Qualität sorgen muss.
Habe ich das so richtig wiedergegeben?
Ja, ist natürlich unfair, weil wir reden ja über eine Acht und dazu sagen, ich muss irgendwie…
Wo ist denn eigentlich der Anfang in der Acht und warum muss ich da denn beginnen?
Aber ja, das ist letztendlich die Aussage.
Vielleicht noch ein bisschen differenzierter, wenn ich nicht ein gutes Level oder eine gute Qualität auf dem Bereich habe,
der eben vor einem Release ist, in der Planungsphase, in der Implementierungsphase, auch in der Testphase,
dann werde ich auf der rechten Seite im Monitoring und im Weitläufigen in der Operations halt meine Probleme bekommen.
Ja, das ist ganz interessant.
Auch insofern, als Falk und ich uns heute Vormittag zusammengesetzt haben, um ein Call for Papers zu beantworten,
der DevOps Enterprise Summit, wo es um genau sowas ging, da haben wir so ein bisschen Rückschau gehalten auf Kunden von uns
und wie deren Erfahrungen so waren und was wir irgendwie als Gemeinsamkeit, egal wie groß oder klein der Kunde ist
oder in welcher Branche er sich bewegt, wenn diese Ausgangs…
Wie soll ich sagen?
Wenn keine Klarheit besteht bereits beim Losmarschieren, dann kommt halt hinten auch nur irgendwas sehr Unscharfes,
im Zweifelsfall sehr Instabiles und womöglich auch nicht besonders Werthaltiges dabei,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
weil es ist ja nicht so, dass man sich da so ein bisschen in die Hand nehmen kann,
und man muss ganz ehrlich sagen, das ist natürlich jetzt nichts Neues,
das haben die DevOpsler sich jetzt nicht irgendwie ausgedacht oder sowas,
sondern, meine Güte, das ist halt irgendwie so ein Klassiker, das sind halt so Sprüche wie Garbage in, Garbage out,
oder das sind Dinge, die aus Richtung Lean kommen, aus Richtung Toyota Produktionssystem kommen,
wo ja auch schon von vornherein gesagt wurde, daher kommt hier dieser Begriff Shift Left,
je früher man für Qualität sorgen kann, desto mehr wird man Strom ab davon profitieren.
Ja, eine Fehlzeit.
Eine Fehlüberlegung bereits in der Spezifikationsphase aufzudecken und zu sagen,
naja, das war jetzt irgendwie unüberlegt, das zu korrigieren braucht nur einen Federstrich,
dann spezifiziere ich es halt um, zack, bumm, fünf Minuten später ist das Ding erledigt,
während wenn in der Kehrseite das erst auffällt, wenn das Produkt beim Kunden ist und der Kunde sagt,
was soll ich denn damit, ja, dann ist es natürlich irgendwie blöd,
dann habe ich potenziell, so wie du beschrieben hast, viele Monate in den Sand gesetzt,
bis die DVD endlich mal beim Kunden ist und dann bringt sie nichts und dann habe ich keinen Wert geliefert,
und alle haben irgendwie reichlich Torte im Gesicht.
Genau, und vielleicht noch als Ergänzung, du hast ja schon gesagt, das ist alles ein alter Hut,
also da wäre ich keinem mehr hinterm Ofen vorloggen, wenn ich sage,
Dinge, die uns später auffallen, sind teurer.
Wir in der Dativ, also ich will nicht sagen, dass wir irgendwie anfangen, Dinge neu zu erfinden oder so,
das müssen wir nicht tun, also es gibt genügend Standards, Vorgehensweisen, wie meinetwegen Shift Left,
auch wie DevOps, die müssen wir nicht tun.
Das ist eine große Herausforderung.
Aber ich glaube schon, dass wir in der Dativ mittlerweile eine Reife erreicht haben,
die uns nicht nur an den Punkt bringt, solche Dinge nutzen zu können,
sondern auch an den Punkt gebracht hat, zu sagen, okay, und was müssen wir aber aus den Dingen tun,
wie müssen wir sie adaptieren, um sie verwenden zu können,
dass sie in unsere Gegebenheiten, in unsere Anforderungen passt.
Und das ist bei einem Shift Left, den treiben wir vielleicht nicht weiter,
aber wir führen ein paar Perspektiven noch expliziter aus, wenn ich die mal kurz erwähne,
also so Dinge wie, wir sprechen ganz gern auch mal vom Shift Left Left,
also der Shift Left sagt, ja, verlagere die Aktivitäten, die QS-Aktivitäten nach vorne in deinem Zyklus,
entwicklungsbegleitend, aber neben diesem entwicklungsbegleitenden Testen ist es uns noch explizit wichtig,
dass wir auch Dinge in der Planphase QS-Aktivitäten dort ansiedeln,
heißt im Detail, BDD, 3MU-Gespräch sind da so Stichworte, dass eben auch eine QS-Perspektive bei der Definition von Anforderungen,
oder von vor allem testbaren Anforderungen eben auch mit reingebracht wird.
Also das ist uns ganz wichtig, dass wir diese Anspruchshaltung verfolgen,
aber auch so Dinge wie, das schwingt ja auch mit, aber wir sagen es nochmal explizit, Komplexität reduzieren.
Also das frühe entwicklungsbegleitende Testen, vor allem mit isolierten Testobjekten,
das reduziert nun mal die Abhängigkeiten, die man sich bei verteilten Architekturen unweigerlich auflegt.
Und wenn ich da von isolierten Testobjekten spreche,
dann meine ich eben nicht nur irgendwie die isolierte Klasse im Unit-Test,
sondern eben auch das autonome Testen von Microservice in der eigenen Anwendung,
Frontend gegen Backend, das automatisierte Testen von Schnittstellen,
das Testen von Gesamtanwendungen, wo ich dann Zweit- und Drittdienste,
die ich per Abhängigkeit mir angebunden habe, irgendwie durch Service-Virtualisierung isoliere.
Also auch das ist uns ganz wichtig über solche Dinge, die in so einem Shift-Left drinstecken,
aber die wir halt explizit machen.
Und das meine ich mit Adaptieren und auf unsere Gegebenheiten und Anforderungen auch schwingen.
Ein Stück weit anpassen.
Was bedeutet denn Shift-Left für einzelne Teammitglieder?
Also auch noch ein bisschen Kontext.
Der Dativ ist es ja so, dass wir, ich sag mal, Rollen sehr ausgeprägt nutzen in Entwicklungsteams.
Also es gibt eben nicht nur den PO, den Scrum Master, sondern Entwicklungsteams,
sondern es gibt den Test-Ingenieur, es gibt den Security-Ingenieur, es gibt den Architekten,
es gibt den UX-Designer, es gibt den User-Researcher.
Und das ist natürlich kontraproduktiv.
So ein bisschen, wenn wir, Stichwort, wir verteilen QS-Aktivitäten nach vorne im Entwicklungsprozess,
wenn wir diese Aktivitätenverteilung immer nur an einer Person festmachen würden
oder an einer Rolle festmachen würden.
Weil, was wir in der Dativ schon auch propagieren, ist das Stichwort Whole-Team-Quality.
Sprich, es ist nicht mehr eine Person, eine Rolle im Team verantwortlich für QS,
geht jetzt noch weniger als vorher, weil es ist nicht mal, okay, ich warte, bis Entwicklung fertig ist
und dann teste ich.
Sondern es müssen ganz viele Dinge auch vorher und entwicklungsbegleitend passieren.
Sondern ein ganzes Team ist verantwortlich für die Qualität seines Produkts,
für die Qualitätssicherung, fürs Testen des Produkts.
Und das hat natürlich ganz unterschiedliche Auswirkungen für die einzelnen Personen im Team.
Für jemanden, der eher auf der Business-Seite ist, sich um Anforderungen kümmert,
der sollte sich möglichst früh auch in die Position begeben, sich auseinandersetzen zu wollen
mit Programmierung, also mit dem Software-Ingenieur und mit dem Test-Ingenieur,
um eben, wie ich es vorhin beschrieben habe, auch testbare Anforderungen zu haben.
Eben nicht nur seine Anforderungen über den Zaun zu werfen und wird schon sich jemand drum kümmern
und das auch testen, sondern von vornherein sich Gedanken zu machen,
wie wir sie dann auch umsetzen und testen können.
Für einen Software-Ingenieur heißt das natürlich, er ist nicht nur stupide am Programmieren.
Dinge wie TDD sind noch ein Stück weit wichtiger, noch höhere Ansprüche an Entwickler,
auch auf Qualität zu achten.
Und für den Test-Ingenieur heißt es, so ist mein Dafürhalten vor allem in einem moderneren Online-Entwicklungsumfeld,
er wird auch ein Stück weit sich technischer orientieren müssen.
Es geht nicht mehr nur darum, da ist jemand, der spezifiziert Testfälle und hat eine Checkliste und testet manuell,
sondern es geht vor allem darum, Stichwort auch BDD, Stichwort Clue-Code erzeugen,
Stichwort Code-Implementierung, Programmierung, Testfälle auch lesen zu können.
Also, dass auch die Menschen, die in der Disziplin Test-Ingenierung unterwegs sind, ein Stück weit technischer werden.
Also, es hat für jeden auch unterschiedliche Auswirkungen.
Das Mantra, was über allem schweben sollte, ist,
was ich vorhin schon gesagt habe, Whole-Team-Quality.
Also, jeder ist verantwortlich am Ende für die Qualität des Produktes.
Bis hin zum Product-Owner, der sich, und das passiert hier und da doch nochmal,
eben nicht so leicht aus der Verantwortung rauskommt im Sinne von Funktionalität vor Qualität.
Also, auch da muss natürlich ein Stück weit Umdenken stattfinden.
Also, Qualität vor Funktionalität, wenn man den letzten Satz zumindest nochmal aufgreift.
Das können wir uns nicht leisten, Veit.
Nicht schwarz oder weiß.
Leider ist es ja, wie so oft im Leben immer,
die Grautöne, aber das Ganze unterliegt natürlich schon irgendwie einer Kosten-Nutzen-Abwägung.
Aber man muss halt einfach auch feststellen,
dass mit der schönsten Funktionalität,
wenn die nicht mit der entsprechenden Qualität geliefert wird,
dann bringt mir das Ganze nichts.
Also, in mir schlägt ein ganz tiefes Herz für so Dinge wie die ISO 25010,
Softwarequalitäten oder Qualitäten in Softwareprodukten,
Qualitätsanforderungen, Qualitätsszenarien.
Sowas ist mir ganz wichtig.
Und deswegen würde ich immer sagen, ja, ja, Qualität vor Funktionalität,
aber am Ende kauft der Kunde ganz oft eben auch erst,
mal nur Funktionalität und setzt dann schwer drauf,
dass die Qualität auch stimmt.
Stichwort irgendwie Kano-Modell, Basis- und Leistungsmerkmale.
Da erwartet er einfach, dass die in eine entsprechende Qualität kommen.
Aber wenn wir sie nicht liefern können,
dann zerschellen die Erwartungen an der Realität.
Auch schade.
Zumal es da ja auch das zweite Argument gibt,
wenn du entsprechende Qualität entwickelst,
dann kannst du es dir überhaupt erlauben,
in dieser Geschwindigkeit Funktionalität bereitzustellen.
Also wollt ihr jetzt sagen,
wir haben Qualität und Funktionalität und das soll funktionieren?
Hilft ja nix.
Muss es nur gut verkaufen, ne?
Ja, da sagst du was Wahres, glaube ich, Veit,
weil ganz häufig, deswegen habe ich ja vorhin so sarkastisch gesagt,
das können wir uns nicht leisten.
Qualität ist viel zu teuer.
Der Wert von Qualität erschließt sich halt vielleicht nicht auf den ersten Blick.
Ich meine, jeder mag natürlich gerne Produkte, die gut funktionieren,
aber dann ist dir das Hemd doch irgendwie näher als die Hose
und sagst, nee, nee, das Feature muss jetzt noch zur Tür raus.
Das müssen wir jetzt noch in den Sprint reinkriegen irgendwie.
So was kann man schon mal machen, dass man technische Schulden aufbaut,
dass man vielleicht auch organisatorische Schulden oder sowas aufbaut an der Stelle.
Aber man muss halt wissen, was man sich damit so gerade einfängt.
Da führt halt irgendwie kein Weg dran vorbei, ist mein Eindruck.
Ja, und technische Schulden werden nie weggehen.
Es wird nicht ohne gehen.
Aber du musst handlungsfähig bleiben.
Du brauchst Handlungsoptionen, wenn Dinge dir um die Ohren fliegen.
Und diese Handlungsoptionen,
die, um mal wieder irgendwie zum Pudels Kern zurückzukehren,
die muss ich mir auf der linken Seite in der DevOps 8 einfach schaffen.
Durch eine adäquate Qualitätssicherung,
durch Transparenz über die unterschiedlichen Entwicklungsstufen hinweg.
Was wird wo wann getestet?
Wie kann ich isoliert an meine Service, an meine Funktion rankommen?
Weil nur, dass ich am Ende weiß, okay, da ist jetzt was kaputt gegangen.
Wenn ich nicht weiß, wo was kaputt gegangen ist,
und wenn ich nicht weiß, wer, wann, wo was gedreht hat,
dann wird die Fehlerursachenanalyse irgendwelche Logs durchwälzen.
Das wird dich auffressen.
Dann bist du nicht handlungsfähig.
Und dann verschiebt sich alles Weitere auch.
Weil ich meine, du musst erst mal den Fehler beheben,
bevor du das nächste Feature hinterher schieben kannst.
Im Normalfall.
Und allein darum geht’s.
Insofern ist es ja eigentlich bezeichnend.
Falk und ich haben im Zusammenarbeit mit der DASA,
der DevOps Agile Skills Association,
ein Training verfasst,
das heißt DevOps Specify and Verify.
Und das heißt ja nicht zum Spaß so,
sondern das soll wirklich genau das auch ausdrücken,
was du gerade eben vorgetragen hast,
weil dass das zwei Seiten derselben Medaille sind,
dass ich, so wie du es vorher gesagt hast,
dass ich diese sogenannten Three Amigos da haben muss.
Wenn ich also ein neues Feature ausdenke und spezifiziere,
dann muss ich einen Spezifikatör da haben,
wie auch immer du ihn nennst, Product Owner oder sowas.
Ich muss den Entwickler haben,
der gleich mit mir da ist,
der gleich mitredet.
Ich muss einen Tester haben,
der gleich mitredet und jeder bringt seine eigene Perspektive ein,
die notwendig ist,
damit hinterher auch tatsächlich gute Qualität dabei rauskommt.
Und um das gleich vorweg zu sagen,
ich habe auch gar nichts dagegen,
wenn du fünf, drei Amigos einlädst,
wenn das notwendig ist, um da Klarheit zu erschaffen.
Genau, dann kommen wir ja letztendlich auch gleich zum Punkt Wert.
Wenn du Qualität hast und jemanden, der diese nutzt,
dann kannst du natürlich Wertschöpfung betreiben.
Und dann hast du den Kunden,
der auch wirklich zufrieden mit dem Produkt ist,
finde ich letztendlich mal eine ganz nette Folge im Gedanken.
Im Skript habt ihr sowas geschrieben wie die Testpyramide,
eine Geschichte von Bäumen und Eistüten.
Da kenne ich mich mit Testen nicht so sehr aus.
Ich bin ja nur so ein komischer Entwickler und so,
Architekt teilweise noch.
Aber was sind denn so Bäume und Eistüten?
Erzählt mal.
Ja, ich hatte ja eingangs erwähnt,
also man sieht viel in so einer zentralen Position.
Und man sieht vor allem,
und das hat auch,
äh,
erklärbare Hintergründe,
Stichwort On-Premise-Anwendungen,
dass die viel zitierte Testpyramide,
und jetzt bin ich vielleicht erst mal bei der von,
von Cone mit den drei Stufen,
dass die oftmals umgedreht ist und eine Eistüte ist.
Also sprich, ich habe doch viel mehr Aufwände
oder Ressourcen, die ich in die Stufen stecke,
bei denen ich eigentlich möglichst wenig investieren sollte,
weil sie teuer sind, sage ich mal.
Stichwort automatisiertes Testen über die Oberfläche
eines integrierten Systems.
Also mal kurz einen Schritt zurück machen und sagen,
wie schaut denn so eine Testpyramide aus
und wie schaut eine Testeistüte aus?
Möchtest du den Schritt machen oder soll ich den Schritt machen?
Wenn dir das lieber ist, dann mache ich den.
Also passt auf, liebe Hörerinnen und Hörer.
So eine Testpyramide nach Mike Cone,
die stellt da Tests auf verschiedenen Ebenen.
Ganz unten hat man Unit-Tests,
wir alle kennen die, das sind sehr, sehr kleinräumige Tests,
die häufig mit einem sehr hohen Detaillierungsgrad
ganz kleine Elemente eines Produkts abtesten.
Dazwischen habe ich dann Integrationstests,
Servicetests, nenn sie wie du möchtest,
die schon auf etwas größerer Ebene sind,
wo jeder einzelne Test größere Abschnitte des Produkts überstreicht,
bis hin zu Systemtests, Abnahmetests,
funktionellen Tests,
die dann wirklich an der Oberfläche sich befinden
und sehr, sehr große Abschnitte der ganzen Applikation
auf einmal durchtesten.
Und der Mike Cone sagt eben,
du sollst im Vergleich weitaus mehr Unit-Tests haben
als am anderen Ende der Welt.
Am Ende der Pyramide, da wo sie spitz zusammenläuft.
Systemtests, Abnahmetests, funktionale Tests,
einfach weil solche großräumigen Tests viel, viel kostspieliger sind,
tendenziell vielleicht auch ein bisschen instabiler sind.
Wenn irgendwo in dieser langen Funktionskette irgendwas verändert wird,
nicht mal unbedingt kaputt geht, sondern einfach nur anders ist,
dann fliegt dir vielleicht ein Test um die Ohren
und dann bist du eben die ganze Zeit am Hinterherlaufen.
So, das ist jetzt erstmal die Testpyramide.
Vielleicht, Veit, möchtest du weitermachen mit der Test-Eistüte?
Also kann ich gerne auf dem Modell,
was du uns und auch den Zuhörer in den Kopf gesetzt hast.
Wie du schon gesagt hast,
eine Pyramide ist unten am breitesten und oben spitz.
Und die Pyramide sagt nichts anderes als genau das Gegenteil.
Also ich habe wenig Unit-Tests.
Ich habe wenig Tests auf der integrierten Ebene
von zwischen vielleicht Services oder bei Schnittstellen oder Systemen,
sondern ich habe ganz viel meiner Aufwände.
Vor allem, wenn es darum geht, Funktionalität zu testen.
Auf der obersten Ebene, auf Akzeptanz-Test-Ebene,
auf System-Integrations-Test-Ebene und da dann,
und das ist ja immer so die Krux an der ganzen Geschichte,
über die Oberfläche.
Ich meine klar, es gibt Tools, Frameworks,
Oberflächentests auch zu automatisieren.
Aber du hast ja schon angesprochen,
dass es meistens relativ instabil,
weil Änderungen, die tief unten stattfinden,
große Auswirkungen oben zeigen.
Und schon bist du wieder in der Situation,
irgendwie deine Tests wieder neu aufzustellen
oder deine Automatisierung anzupassen.
Und, das ist ja genau das, was wir im Shift-Left propagieren,
wir wollen ja schnelles Feedback.
Wenn du immer erst im integrierten System deine Tests fährst,
dann bist du weit weg vom schnellen Feedback,
weil da bist du relativ nah an, eigentlich wollen wir releasen.
Das, was da jetzt rauskommt,
naja, lass das mal irgendwie ins Backlog packen.
Oder ist das jetzt wirklich so dringend, was da passiert?
Oder ja, ist es? Na gut, dann müssen wir noch mal
die ganze Kette zurückgehen.
Und das ist so was,
was wir uns ja mit der Eistüte vorstellen, sozusagen.
Was nicht gut ist.
Ja, vielleicht sollte man an der Stelle auch erwähnen,
dass zum Beispiel ein Freund von mir,
der sehr viel mit Serverless macht,
der sehr stark die Desintegration von Diensten vorantreibt,
noch weiter als Microservices,
bis hin zu eben wirklich Funktionen,
die einzeln ausgeführt werden.
Und der sagt, lustigerweise, er macht kaum Systemtests
und er macht aber auch kaum Unit-Tests,
sondern er hat einen Test, was denn, Rhombus?
Ich glaube, das ist dann ein Test Rhombus, oder?
Mit ganz, ganz vielen Integrationstests.
Ja, genau.
Also, das ist das, was er macht,
das ist das, was er macht in der Mitte.
Weil er sagt, das ist das,
wo es bei dieser Art von Systemen dann regelmäßig knallt.
Genau, das ist das, was ich dann immer,
was ich dann mir immer so als Baum,
immer so als Bild male.
Ganz unterschiedlich.
Da kann auch mal ein Baum sein,
der in der Mitte irgendwie dicke Äste hat
und oben eher weniger.
Oder er hat einen dicken Stamm und wird oben wieder spitzer,
hat aber in der Mitte, was du gesagt hast,
mit Integrationstests irgendwie eine große Ausprägung.
Genau.
Und so sieht das dann auch auf die Pyramiden, sag ich mal.
Sondern das sieht immer so ein bisschen anders aus.
Ja, kommt auch auf die Architekturen,
die Anforderungen des Produkts dann an.
Ich will noch eine Perspektive mehr dazugeben,
weil das ist bei uns immer ganz interessant.
Wenn wir nämlich Shift Left sagen,
meinen wir damit auch immer,
und das sagen wir dann manchmal auch explizit,
Shift Down.
Also nicht nur orientiere dich nach links,
entwicklungsbegleitend,
sondern schau noch mal auf die Pyramide
und bitte konzentriere dich auch nach unten,
damit das noch mal ein bisschen mehr propagiert wird.
Wir sind uns einig,
das ist das Ziel.
Ich habe hier irgendwie x-tausend Unit-Tests.
Muss nicht Perfektion sein,
sondern wahrscheinlich liegt die weit irgendwo mittendrin.
Aber es darf halt auch nicht sein,
dass ich meine ganzen Aktivitäten oben versammelt habe.
Haben wir ja schon ausführlich diskutiert, warum nicht.
Man kann das schon machen.
Hat halt Nachteile.
Genau.
Aber haben wir eigentlich schon hinreichend gut erklärt,
warum wir uns jetzt so auf diese Testpyramide versteifen
und dass sie eine Pyramidenform haben möge
und keine Eistütenform?
Ich meine, ist doch alles okay,
denn es ist halt eine Testeistüte.
Warum ist das denn jetzt wichtig,
dass das pyramidenförmig ist?
Also, ich glaube,
wir haben zumindest den ein oder anderen Aspekt schon angesprochen,
weil eben, wenn es eine Eistüte ist,
wenn wir Dinge auf oberen Ebenen, Integrationsstufen tun,
die uns teuer zu stehen kommen, länger laufen,
wir bestimmt kein Fast Feedback in jeglichem Sinne haben werden,
instabil sind.
Also, ich glaube, wir haben genügend Aspekte genannt,
warum ich das zumindest
in verteilten Architekturen für keine gute Idee halte.
Was ist dafür notwendig, um da hinzukommen?
Keine Eistüte zu haben, meinst du?
Ja, genau.
Also, wie kommt man quasi von wo auch immer man startet
zu einer guten Testpyramide?
Also, eine gute Basis,
um jetzt nicht unbedingt bei Adam und Eva anfangen zu wollen,
aber ist eine Teststrategie zu haben
und sich zu überlegen, wo machen meine Tests am meisten Sinn?
Und das muss nicht unbedingt heißen,
dass alle nach unten purzeln, die Pyramide entlang,
sondern sich tatsächlich zu überlegen,
was kann ich wo am besten testen?
Und da immer als oberste Prämisse sich vorzuführen ist,
wo kann ich mein Testobjekt am einfachsten, am besten isolieren?
Und wenn ich eine Schnittstelle habe,
und es gibt ja auch genügend Frameworks,
und ich benutze jetzt PACT,
um Consumer-Driven Contract Testing zu machen,
dann mache ich das halt da.
Wenn ich die Möglichkeit nicht habe,
dann schaue ich halt, ob ich meinen Service irgendwie
auf einer anderen Stufe isolieren kann gegen was anderes.
Also, sich zu überlegen, wo kann ich am besten isolieren?
Wo kann ich die Techniken, die es gibt, am besten anwenden?
Und da dann einfach den Test zu fahren
und das möglichst nach unten orientiert.
Aber Startpunkt, mach dir Gedanken über eine Teststrategie.
Schnapp dir deine Anwendungsarchitektur
und schneide klein von System über Produkt über Service
über Funktion über Klasse und schau, wo du das testen kannst.
Kleinschneiden ist, glaube ich, so ein Thema.
Architektur mit ins Boot holen gefällt mir.
Also, sowohl von der Dokumentation her,
als auch die Architekten gegebenenfalls
auch mal mit ins Team zu holen.
Und da dann in vier Augen, acht Augen, wie auch immer,
Gespräch ein Stück in die Tiefe zu gehen
und so isolierte Testobjekte zu bekommen.
Ist das Thema Microservices bei euch auch ein Thema?
Unbedingt. Also, Stichwort, wir wollen in die Cloud,
um das jetzt mal irgendwie so ganz profan zu nennen.
Wir haben eine sogenannte Technologieleitlinie
und die gibt mehr oder weniger
Microservice-Architektur vor.
Und deswegen ist auch unsere Pyramide
oder die Testpyramide entsprechend adaptiert worden.
Wir reden zum Beispiel von der Integrationsstufe,
die heißt Microservice.
Also, in der Anwendung zum Beispiel Frontend isoliert
von dem Backend testen zu können
oder Backend-Service 1 isoliert
von dem Backend-Service 2 testen zu können.
Also ja, ist bei uns ein Thema, ist mehr oder weniger
auch eine architekturelle zentrale Vorgabe so zu entwickeln.
Ja, dann hat man ja relativ schöne isolierte Objekte,
die man auch gut mit einfachen Schnittstellen ansprechen kann.
Wenn man die Arbeiten vorneweg,
Stichwort Domain Driven Design, die gut getan hat, ja.
Genau.
Und ich möchte noch mal kurz auf das zu sprechen kommen,
was wir vorhin gesagt haben über die Testpyramide.
Und weil nämlich schlussendlich,
um das noch mal auf den Punkt zu bringen,
wenn ich eine Test-Eistüte habe und viele großräumige Tests habe,
die, wie du sagtest, lang laufen,
die tendenziell bestimmt auch erst spät überhaupt lauffähig sind,
weil dafür einfach schon sehr, sehr viel da sein muss,
dann mache ich ja faktisch nichts anderes,
als Shift-Right.
Also genau das, was wir nicht wollen.
Ich verschiebe mein Feedback nach hinten,
sowohl wann ich das erste Mal so einen Test erfolgreich laufen lassen kann,
weil überhaupt genügend da ist, was getestet werden kann,
als auch die Dauer eines einzelnen Testlaufs,
die ja bei einem Systemtest, wenn es schlecht läuft,
auch mal ein paar Stunden betragen kann.
Das ist natürlich unglücklich.
Insofern, das ist mir ganz wichtig, da noch mal darauf rauszukommen,
warum reden wir über diese ganzen Sachen?
Warum machen wir dieses Shift-Down, wie du es nanntest?
Weil das eine Voraussetzung ist,
damit wir überhaupt ein erfolgreiches Shift-Left hinkriegen können,
dass wir also erfolgreich so früh wie möglich uns Feedback holen können
über das, was wir zu tun hier gerade im Begriff sind.
Und da sind wir jetzt auch wieder bei den Three Amigos.
Du holst dir Feedback vom Tester,
noch bevor die erste Codezeile geschrieben ist,
bevor überhaupt ein Test überhaupt Sinn machen würde,
sondern du lädst ihn direkt ein, wenn du spezifizierst.
Das ist doch die Idee dahinter.
Ja, und ein Zusatz noch, was völlig realitätsfremd wäre,
zu sagen, wir wollen überhaupt keine Tests auf oberen Stufen haben.
Ich brauche die natürlich nach wie vor.
Irgendwann will ich ja auch mal meine Anwendung in einem Geflecht,
in einem Prozess vielleicht auch testen können,
zusammen mit anderen Anwendungen,
und will sehen, wie die harmonieren, ob die konsistent sind,
ob die weichen Faktoren wie gefühlte Performance gegeben sind.
Aber das sind halt dann manuelle, explorative Tests vielleicht
und eher weniger automatisierte.
Eine Sache, die man bei der Gelegenheit vielleicht auch ansprechen muss,
ist, vergangenes Jahr war ich auf einem QS-Tag
und eine Frau hat dort einen sehr interessanten Vortrag gehalten,
in dem sie referiert hat über die Ergebnisse von einer Entwicklerumfrage.
Die war jetzt nicht besonders repräsentativ vielleicht.
Da gab es halt irgendwie Laufkundschaft.
Das wurde irgendwie, glaube ich, auch zusammen gemacht
mit High-Z-Developer und so.
Also es gab da bestimmt so eine gewisse Selbstauswahl.
Aber nichtsdestotrotz, was sie referiert hat, war unter anderem,
dass faktisch man momentan in der Industrie ein Shift-Right beobachtet.
Dass also Testen nach hinten geschoben wird.
Dass es weggeschoben wird.
Dass es irgendwie auf einmal vielleicht weniger das Problem von Entwicklern ist.
Also genau das Gegenteil dessen, worüber wir jetzt die ganze Zeit sprachen, Veit.
Wie stehst du dazu?
Hast du das auch vielleicht beobachtet in Diskussionen mit anderen?
Ist das eine Strömung, die du vielleicht wahrnimmst,
gerade wenn du jetzt neue Entwickler anheuerst?
Erzähl mal was dazu.
Also ich würde nicht so weit gehen, zu sagen,
dass das jetzt irgendwie eine Strömung ist.
Das würde ich ganz gern so Menschen wie der Kollegin überlassen,
die das da auch vorgetragen hat.
Aber ist natürlich schon zu beobachten.
Das ist das, was ich eingangs erwähnt hatte,
dass jetzt durch DevOps auch Impulse kommen,
die einen dazu verleiten, zu sagen,
na ja, gut, lass doch mal jetzt mal die schöne neue Welt rechts ausprobieren
und da vielleicht schauen, ob wir da nicht Dinge,
die wir eigentlich früher tun sollten,
in einer anderen Art und Weise einfangen, abfangen können.
Das ist halt leider ein Irrglaube.
Und von daher würde ich das so ein bisschen bestätigen wollen,
dass man das schon merken kann.
Also deswegen sagte ich ja auch,
für uns ist es Fluch und Segen zugleich,
jetzt über DevOps und dergleichen Dinge nachzudenken,
für uns jetzt in der zentralen Position, in der zentralen QM,
weil wir ja schon seit Jahr und Tag auf den Shift Left pochen.
Das ist ja jetzt nichts Neues.
Aber es wird halt noch mal ein bisschen erschwert,
wenn der Wind eher von der anderen Seite weht sozusagen,
von der rechten Seite.
Was fällt für euch alles unter Shift Right, rechte Seite rein?
Ist das nur betriebliche Themen?
Geht das auch in Richtung Security?
Geht das auch noch weiter, Governance generell?
Also ich habe da vor allem jetzt erstmal die ja schon Operations-Themen
oder auch die technologischen Themen auf dem Schirm
und auch die Monitoring-Themen oder so Sachen wie Feature-Toggling,
Can I Release, A-B-Testing.
Also die anderen Perspektiven, die du gerade noch reingebracht hast,
vor allem Governance ist natürlich auch spannend.
Da hätte ich jetzt aber gerade spontan gar keine Hinweise dazu.
Ja, aber DevSecOps ist ja ein Thema, was immer mal wieder diskutiert wird.
Wäre jetzt so ein Gedanke, wie kriegt man nicht nur funktionale
und vielleicht nicht funktionale Themen getestet,
so automatisiert, dass man sie halt recht früh auch im Prozess
regelmäßig nachtesten, Regression und Co. im Griff hat,
sondern dass man halt auch Security-Tests,
die vielleicht im Nachgang irgendwo Pentests,
vielleicht auch in Richtung statischer Analyse von Komponenten
und Vulnerability-Tests in die Continuous-Delivery-Pipelines mit reinzieht
und so halt auch in Richtung Links bewegen kann.
Es ist ganz interessant, dass du jetzt vor allem Stichwort
Vulnerabilities und statische Code-Analyse ansprichst,
weil deswegen bin ich gar nicht auf dich angesprungen,
weil wir das tatsächlich in der Dativ auch schon haben.
Also das ist ja auch ein Thema.
Also da laufen Dinge wie Widesource oder Fortify in,
jetzt bei uns der Jenkins-Pipeline, automatisiert mit.
Stichwort Penetrationstests, ja, das scheint mir immer,
da scheint noch irgendwie ein Stück weit Weg zu sein,
die zu automatisieren und das ist doch meistens immer noch
großer manueller Aufwand, soweit ich das beobachten kann.
Aber ja, macht das natürlich Sinn, das auch irgendwie links zu etablieren.
Das ist ja der Punkt, dass man sich mal so ein bisschen austauschen
und kennenlernt auch in so einer Folge
und die Gedanken mit Stichworten alleine vielleicht nicht reichen,
sondern Beispiele, die ganz hilfreich sind, finde ich auch so.
Wir hatten ja gerade auch so ein bisschen darüber philosophiert,
warum das irgendwie alles so in Richtung Tools zu gehen scheint
und in Richtung eben der rechten Seite dieser linken Acht.
Und meine persönliche Vermutung ist dann an dieser Stelle auch immer,
dass so Technologie halt irgendwie vergleichsweise harmlos ist.
Die tut ja keinem weh, so ein Jenkins, der ist gleich installiert,
da muss keiner an sich selbst zweifeln oder seine Herangehensweisen ändern
oder seine Verhaltensweisen ändern.
Sondern das kann man einfach mal machen.
Aber der wirkliche Wert, glaube ich, kommt eben genau aus den Dingen,
die viel weiter links passieren, nämlich da, wo Leute miteinander interagieren,
wo man gemeinsam versucht, überhaupt zu verstehen,
was das Produkt ist, das man da bauen sollte.
Und wenn man das gut macht, dann ist der aktive Schritt
des irgendwie geschweiften Klammern-Tippens und so,
meine Güte, das ist ja dann gemessen daran gar nicht mehr so wild.
Insofern gefiel mir das, was wir hier auch in unseren Notizen drinstehen haben,
einer Prozess-QS, dass man schauen soll, dass Qualität nicht nur daraus erwächst,
dass ich jetzt, keine Ahnung, halt eine Testsuite laufen lasse,
sondern dass da eine Vielzahl von ineinandergreifenden Aktivitäten stattfinden müssen,
als eine ganze Kette, als Resultat, der dann etwas hochqualitatives hinten rausfällt.
Und als ganz wichtiger Aspekt von dem, was du jetzt gerade gesagt hast,
um das noch zu ergänzen, bei uns gibt es immer das geflügelte Wort,
wir müssen mal zum Äußersten gehen und miteinander reden.
Am Ende ist es genau immer das, das kann dir kein Tool abnehmen,
das kann dir keine Vorgehensweise abnehmen.
Du kannst dir mit so Dingen wie einem 3-Amigo-Gespräch zumindest die Rahmenbedingungen schaffen,
dass man auch zusammenkommt, um miteinander reden zu können,
wenn man es anders nicht schafft. Aber darauf kommt es am Ende an.
Und darauf kommt es noch mehr an, wenn Dev und Ops,
wenn die unterschiedlichen Menschen, Prozesse, Kollegen zusammenwachsen sollen,
ja, Herrgott, dann müssen wir reden miteinander.
Und dann sollten wir es möglichst oft und viel tun.
Und ein Tool, ja, da bin ich bei dir, das ist dann am Ende auch schnell eingekauft,
wenn der Geldbeutel groß genug ist.
Ja, wie kriegt ihr dieses Reden hin zwischen Dev und Ops?
Werden da echt Teams zusammengewürfelt, die dann halt vorher einzelne Teams waren?
Werden die Teams dann nicht zu groß?
Oder wie geht ihr mit solchen Themen um wie Bereitschaft, Port und Co.?
Ja, das ist natürlich eine gute Frage, die ich so im Detail gar nicht wirklich beantworten kann,
weil ich da dann doch ein Stück weit zu weit weg bin.
Ich weiß, es ist noch nicht Teams oder die Anzahl der Produkte und die Anzahl der Teams, die wir haben,
da sind wahrscheinlich die wenigsten wirklich als DevOps-Team unterwegs.
Das sind jetzt Dinge, die erst erwachsen müssen, mit denen man sich genau,
das sind genau die Herausforderungen, die du beschreibst.
Kann man einfach die Leute zusammenwerfen und dann ist das plötzlich ein neues Team?
Was kauft man sich ein mit Operations? Stichwort Rufbereitschaft und solche Themen.
Das zieht ja noch viel weitere Kreise.
Stichwort irgendwie Betriebsrat und Arbeitszeitvereinbarung und Sonstiges.
Das sind alles Dinge, die besprochen, die diskutiert werden müssen, die jetzt gerade erst entstehen.
Also wird spannend sein, das zu verfolgen.
Am Ende, um es mir da auch ein bisschen leicht zu machen, schreibt man gerne überall drüber,
Whole Team Quality und die betrifft dann natürlich Menschen, die sich eher im Ops zurechtfinden,
genauso wie Menschen, die eher im Dev-Bereich sind.
Aber natürlich ist, das wissen wir ja auch, Größe von arbeitsfähigen Teams auch begrenzt.
Man muss schon schauen, wie man das gut hinbekommt.
Ich sehe das schon kommen, Veit.
Wir müssen dich noch mal zu einer Architektur-Folge einladen,
wo wir diese Themen dann en Detail diskutieren können.
Oh, ich will aber nicht in fremden Gewässern fischen.
Aber können wir uns gerne überlegen, ja.
Ja, oder bringst halt einen Architekten mit. Ist ja auch okay.
Oder das, genau.
Ja, noch einfacher.
Sehr schön.
Veit, was haben wir vergessen?
Was musst du ganz dringend den Hörerinnen und Hörern noch mitteilen?
Oh, das ist natürlich sehr überraschend.
Jetzt muss ich gerade mal rekapitulieren.
Eigentlich haben wir tatsächlich nichts vergessen.
Das kannst du ja alles dann schneiden.
Aber vielleicht kann man einfach …
Also, wenn du mich fragst, was wir vergessen haben.
Wir haben eigentlich nichts vergessen.
Wir können aber eine Aussage vielleicht noch mal ganz dick unterstreichen,
die wir auch schon am Anfang propagiert haben.
Nicht unbedingt, dass DevOps links beginnt.
Aber vielleicht, dass …
Und ich will auch nicht so weit …
Na gut, vielleicht streise ich das noch mal.
Weil ich weiß aus unserem Vorgespräch, dass du gesagt hast,
hier geht es nicht darum, das irgendwie in Balance zu halten,
sondern wir müssen links erst richtig machen, damit rechts auch funktioniert.
Ja, das habe ich gesagt.
Aber ich glaube, was du immer wieder mal propagiert hast,
da bin ich auch sehr mit dabei.
Nämlich, man muss es einfach überall machen.
Es gibt niemanden, der sich da zurücklehnen kann und sagen kann,
nicht mein Problem.
Ja, sonst funktioniert Whole-Team-Quality nicht.
Wenn sich ein Teil der Acht irgendwo rausnimmt,
ob das in der Anforderung, ob das in der Entwicklung,
ob das im Betrieb ist, ob das Support oder sonst wo steht,
jeder hat einen Beitrag dazu zu leisten,
damit Qualität wirklich Ende-zu-Ende funktioniert.
Und deswegen gibt es, glaube ich, auch in dem Training,
was du vorhin erwähnt hattest, so eine schöne Folie,
liegende Acht und dann Test hier, Test hier, Test hier.
Und zwar an allen Stellen von der Acht, ringsherum.
So ähnlich ist es halt, wenn Qualität funktionieren soll.
Das ist übrigens hochinteressant,
weil ich glaube, so ähnlich, so eine Folie,
die gibt es auch bei uns, ja.
Also von daher …
Ja.
Also von daher volle Zustimmung.
Ja, dann …
Sehr schön.
Haben wir es, glaube ich, oder?
Ich glaube auch.
Ich glaube, das wird eine ganz tolle Folge
oder ist eine ganz tolle Folge geworden.
Veit, vielen Dank, dass du da warst.
Danke, dass ich da sein durfte.