Tino, Das ist ein super schönes Beispiel, vor allem, weil ich auch einfach ein absoluter Liebhaber von Analogie bin. Also du hast mich heute für den Rest des Tages bezuckert, das ist. Bezuckert ist ja auch geil. Coding Buddies, Dein Podcast rund um Softwareentwicklung und aktueller Tech News. Herzlich Willkommen. Halli Hallo und herzlich Willkommen zur neuen Folge vom Coding Buddies Podcast. Es ist wieder Zeit für eine neue Folge und damit begrüße ich natürlich meinen Werten.
Podcast Kollegen und besten Freund Tino, Wie geht es? Schöne Einleitung. Hi Fabi, Grüße dich. Mir geht's super, mir geht's super, sehr schön, ich hab Bock, die Sonne scheint ausnahmsweise mal wieder, also eben gerade ist die Sonne quasi rausgekommen, wo wir gesagt haben, wir nehmen Podcast auf, das ist ein. Zeichen. Das ist sowas. Von ein Zeichen. Ich hatte jetzt hier aufhören müssen, wir sollten lieber das Wetter draußen genießen. Nein, nein, nein, ich hatte.
Letztens einen Regenbogen auf dem Arm, krass, oder? Was? Ja. Hast du dir so raufgemalt oder wie? Nein. Kennst du das mit so n prisma mäßig so durchs Fenster, so weißt du und dann weißt du. Ich dachte, du hast so vielleicht n neues Tattoo, oder? Was oder Regenbogen? Aber nur so ne auch. Cool so. 1 zum Draufkleben weißt. Ja, so genau, genau zum Wegwischen da ja cool. Also erstmal freut mich, dass du auf jeden Fall so n klebe, Tattoo hast, oder? Dann sag doch mal, was wollen
wir denn heute machen? Ja, wir wollen ja jetzt noch mal n bisschen. Wir hatten ja in der in Teil 1 quasi von oder im letzten Teil von den Metriken Performance Metriken hatten wir ja schon mal angefangen darüber zu reden, wie man Performance messen kann oder besser gesagt, wie man sie vielleicht nicht messen sollte und hatten ja dann so n kleinen Cliffhanger, weil wir einfach auch gesagt haben, OK, die Folge war schon ganz schön lang und lass doch vielleicht einfach
noch mal n bisschen. Das Splitten, weil sonst haben wir hier Spielfilmlänge ne Podcast Folge. Ja, da sind wir nicht ausschweifend geworden, aber haben ne Weile drüber gesprochen. Auf jeden Fall genau. Ist ja auch, ist ja auch n interessantes Thema absolut. Wir wollen ja jetzt noch mal oder wollen jetzt sozusagen die zweite Runde einleiten oder den nächsten Teil der Metriken der Performance Metriken in Angriff
nehmen und zwar. Wie man es denn vielleicht machen könnte, weil wir ja schon darüber gesprochen haben, was jetzt vielleicht nicht so optimal wäre. Und wir können ja erst mal kurz noch mal einen kleinen Recap geben. Was hatten wir besprochen, was ist nicht so gut, dann dann können wir ja reinsteigen oder einsteigen in ja, das neue Thema. Genau also. Als Erstes hatten wir ja über die Metrik Lines of Code oder Logical Lines of Code
gesprochen. Ist auch schon ne relativ alte Metrik, die ja im Prinzip besagt, dass die Produktivität eines Developer daran gemessen wird, wieviel Zeilen Code geschrieben werden. So am Tag dann gab es wie gesagt auch noch so ne Erweiterung, dass man sagt, OK man zählt nur die logischen Zeilen, dass halt sowas wie meinetwegen.
Geschweifte Klammern in Java als Beispiel so für Scopes nicht mitgezählt werden, weil das eher so ne Syntaxgeschichte ist und keine semantische Logik sozusagen dadurch reinkommt. Aber es hat halt einfach die Schwäche, das haben wir glaube ich auch oder hoffe ich auch gut aufgezeigt, dass man daran halt nicht wirklich. Auch die Codequalität messen kann und die Produktivität am Ende.
Weil ich kann natürlich ne Funktion in mehreren Art und weisen umsetzen mit vielen Zeilen Code und es passiert am Ende das gleiche wie ne schön knappe und wartbare Lösung, die auch verständlich ist mit der gleichen. Business Logik dahinter sage ich mal und das zeigt halt schon auf, dass natürlich dann Entwickler A mit der größeren Lösung nicht wirklich produktiver war als Entwickler B mit der kleineren und kompakteren Lösung.
Ich glaube, dass das sollte eigentlich klar sein, dass das relativ, also dass man relativ schnell merkt, hey das das funktioniert nicht und das hat man allgemein halt auch, wenn man sich mit solchen Themen beschäftigt gemerkt und das auch relativ schnell verworfen, können mir vorstellen, dass es bei manchen immer noch so eine. Kleine Rolle spielt aber ich hoffe es ehrlich gesagt. Nicht wäre auf jeden Fall
wünschenswert. Genau, und dann hatten wir ja noch die Velocity, die Geschwindigkeit, die wir auch hinreichend diskutiert haben und auch gesagt haben, was denn so vielleicht die Schwachstellen sind an dem ganzen Ding. Also wir hatten ja gesagt, dass das eher zur Planung.
Genutzt werden kann als zur Performance Messung, weil einfach auch das Maß Geschwindigkeit auch ein relatives Maß einfach auch von verschiedenen Teams ist und kein absolutes Maß um eine Performance zu messen und das im Endeffekt auch einfach schaden kann am Ende wenn man das Ganze falsch nutzt auch einfach dem der Zusammenarbeit zwischen verschiedenen Teams kann das Schaden und.
Als dritten Punkt hatten wir noch die Auslastung oder die Utilisation, wo wir auch gesagt haben oder besprochen haben, dass wenn man jetzt eine zu hohe Utilisation hat, also wenn jetzt zum Beispiel jede Person im Team 100% ausgelastet ist, dann hat man halt einfach keine Zeit mehr für ungeplante Arbeit, was im Normalfall auch dazu führt, dass normale Aufgaben einfach übermäßig lange dauern. Und genau also.
Wenn dich das, liebe Zuhörerin, oder lieber Zuhörer, wenn du jetzt hier einschaltest und sagst, hey, ich hab Teil 1 ja gar nicht gehört, hör gerne rein, wenn du Lust hast. Da haben wir das Ganze auf jeden Fall genau. Wir warten dann an dieser Stelle hier und dann schaltest du einfach hier wieder ein und dann geht es weiter. Genau, ja, man kann ja auch sagen, dass also noch mal so als Recap das. Diese Metrik natürlich einfach die Schwäche haben, dass man sich sehr stark auf den Output
konzentriert. Das heißt, man möchte was messbares haben, also irgendwas, was man ja zwar trotzdem virtuell, aber irgendwie greifen kann, beispielsweise abgeschlossene Tickets oder sichtbare neue Zeilencode, oder zu sehen, jeder Entwickler hat genug Tickets und ist 100% ausgelastet, da ist keine Zeit mehr über, ja, also um die 3 jetzt noch mal so zusammenzufassen, aber das Problem ist ja diese Konzentration auf dem Output.
Sorgt ja nicht dafür, dass man wirklich eine wahre Produktivität erreicht, weil man sie ja wie gesagt relativ schnell faken oder manipulieren kann, weil es halt einfach nicht da drauf geschaut wird, was denn der Outcome dahinter ist. Also wir haben ja ganz viel vom Mehrwert gesprochen in der 1. Folge, weil das ja eigentlich das Entscheidende ist.
Zum Beispiel Lines of Code noch mal als kleines Beispiel, eine Funktion hat 30 Zeilen und der Mehrwert von dieser Funktionalität ist genauso hoch wie bei einer. Implementierung dieser Funktion mit 3 Zeilen und da würde ja dann wie gesagt die Lines of Code metric schon wieder quasi failen, weil der Outcome am Ende gleich ist.
Und genauso ist es ja auch mit den Tickets oder halt auch mit der Kapazität. Genau, und das ist natürlich dann auch, wenn man jetzt wirklich versucht, Metriken zu nutzen, die Anschlagen, um Performance zu messen oder Metriken zu haben, um genau. Dieses Ziel zu erfüllen, vielleicht auch sich zu verbessern. Dann ist es halt wichtig, auf diesen Outcome zu achten und nicht auf den Output, wie du meintest.
Und es ist auch durchaus wichtig, dass man eben guckt, dass man einen globalen Outcome erzielt. Also im Endeffekt sagt Okay die Teams, die wir haben, die zum Beispiel auch zusammenarbeiten, weil oft ist es ja so, dass Teams auch miteinander arbeiten müssen. Die sollen nicht gegeneinander antreten oder sich nicht gegenseitig ausspielen, sondern halt eben zusammenarbeiten und am gleichen Strang zielen, um eben das große Ziel am Ende zu erfüllen. Ja, sehr wichtiger.
Und das sind eigentlich auch genau die wichtigen Punkte. Und wenn man jetzt überlegt okay welche Möglichkeiten gibt es denn jetzt zu sagen, wie könnten wir zum Beispiel das ganze
Messen? Dann gibt es im Endeffekt würde ich jetzt mal einordnen, 2 große verschiedene Themengebiete oder Punkte, zum Beispiel einmal ein Maß für die für das Tempo der Lieferung der Software, also wie schnell kann Software geliefert werden, da gehen wir gleich dann noch mal ein bisschen genauer drauf ein und ein Maß für die Stabilität, also wie stabil läuft deine Software, ne, das eine ist sozusagen.
Ja, wirklich. Das Messen des Tempos, wie schnell wird die Software von also aus also ausgeliefert? Da gehen wir wie gesagt gleich noch mal drauf ein und halt wie fehleranfällig oder stabil ist die Software und daran an diesen 2 Punkten kann man das messen und ich würde gerne mit dir einfach mal für beide Punkte 2 verschiedene Metriken oder Maße wie man das so nennen möchte diskutieren. Ja, Maße klingt komisch, aber es könnte sogar richtig sein.
Ja, guter Punkt. Wichtig hierbei ist, weil du meintest so die Geschwindigkeit der Auslieferung ist derzeit nicht gleichzusetzen mit der Entwicklungsgeschwindigkeit, wie wir sie jetzt im ersten Punkt hatten mit der Velocity, sondern halt wirklich im Prinzip, wie lange dauert es um auch zum Beispiel ne neue Version einer Software rauszubringen? Habe ich dich da richtig? Verstanden genau.
Also das wäre zum Beispiel der Punkt Delivery Lead Time nennt sich das Ganze und da geht es sozusagen um die, ich finde das als ich das das erste Mal gehört habe oder davon gelesen habe, fand ich erstmal so was ist denn jetzt so eine Lead Time ne also was soll das heißen so also auslieferungszeit was kann man sich darunter vorstellen und ich fand eigentlich so die beste Beschreibung oder die beste Vorstellung davon ist.
Dass, wenn man sagt, OK, man nimmt die Zeit, wo ein Kunde sagt, Ich möchte jetzt zum Beispiel das und das haben ne also irgendwie n Feature oder ne Software oder ne Anwendung was auch immer und dann die Zeit bis zur Auslieferung von dieser Software sag ich jetzt einfach mal ganz allgemein und aber unter dem Gesichtspunkt, dass auch der Kunde zufrieden ist. Ne ja und das? Große Problem an der ganzen Geschichte ist, oder? Das sind eher so 2 Teile.
Zum einen ist es die Zeit, wo man das Produkt ja designed und versucht zu validieren, dass es genau das Produkt am Ende auch ist, was es sein soll, also dass es in die richtige Richtung geht, dass man zum Beispiel, man kommt ja meistens erst mal in das Gespräch, ich möchte gerne eine App haben, das.
Die soll das und das können. Und dann sagt man ja okay okay, also die soll das und das können, aber dann dann werden vielleicht noch Edge Cases sich überlegt oder solche Sachen und natürlich ist es auch immer noch die Frage, kennst du ja selber so wie soll das ganze Aussehen am Ende und das sind ja sehr sind so Punkte, die sind sehr variabel und das ist so Part 1, aber diesen Part. Von dieser, von dieser Gesamtauslieferung, der zählt eigentlich, bei den kann man
nicht so gut messen, das heißt, den Klammern wir vielleicht mal aus an der Stelle und sagen, OK, wir fokussieren uns auf den zweiten Teil, also sozusagen wirklich, wo man sagt, jetzt ist der Umfang geschaffen, man weiß, welche Richtung das gehen soll, und wir messen sozusagen für diese Delivery Lead Time die Zeit. Wo wir sagen, wie lange dauert das Ganze, das zu implementieren, zu testen und zu Delivern, also zum Beispiel. Zu deployen.
Ne, das ist so der Punkt. Also man kann das ja auch mit einer kleinen Analogie gleichwertig beschreiben, wenn man sagt, beispielsweise, Liebe Zuhörer, du hättest n Themenvorschlag für unseren Podcast und schreibst du uns ne Mail, dann wäre das ja im Prinzip genau die Zeit zwischen du schickst die Mail. Und du kannst diese Folge hier im Podcast hören, weil wir müssten ja quasi auf die Mail
reagieren. Dann kommt wieder dieser erste Teil, der schwer messbar ist und das wäre es auch in dem Fall. Wir müssen uns das Thema, denn was du vorgeschlagen hast anschauen. Vorbereiten und damit auseinandersetzen und dann kommt wieder eine gut messbare Zeit, indem man sagt, OK, jetzt können wir diese Folge aufnehmen, vielleicht noch bearbeiten, hochladen und dann ist auch klar, wann sie veröffentlicht wird.
Im Prinzip also nur mal so, um vom technischen kurz wegzugehen, ist es im Prinzip genau die gleiche Metrik, die man da verwenden könnte, um zu sagen, wie lange dauert es von diesem Wunsch der Hörerinnen und Hörer bis zur Ausstrahlung der Folge. Tino, Das ist n super schönes Beispiel, vor allem weil ich auch einfach n absoluter Liebhaber von Analogie bin. Also du hast mich heute für den Rest des Tages bezuckert, das ist. Bezuckert ist ja auch geil.
Und vor allen Dingen ist es auch ein indirekter Aufruf. Liebe, zuhören, liebe Zuhörer, falls du einen Themenvorschlag hast, dann meld dich gerne und dann messen wir doch glatt mal diese Zeit ganz. Genau finde ich auch sehr gut.
Ja, und vor allem was ich halt gut finde bei dieser Analogie ist diese variable Zeit, weil es kann ja zum Beispiel sein, dass wir schon von diesem Thema unglaublich viel Ahnung haben oder vielleicht eher weniger Ahnung haben, also ist die Zeit halt variabel, weil du nicht genau wissen. Deswegen lässt sich das halt auch im Vorfeld schlecht abschätzen. Einfach. Richtig aber finde ich sehr gutes Beispiel.
Und auf jeden Fall. Der Punkt ist ja, wenn man jetzt zum Beispiel sagt, EY wir also diese Lead Time, die wenn du sagst, du möchtest eine Performance messen, dann ist diese Lead Time natürlich klein zu halten, also dass man halt sagt okay, wie können wir es denn schaffen, die Zeit von von der Anforderung die gestellt wurde bis hin zur Auslieferung an den Kunden nenne ich es jetzt einfach mal, wie schnell ist, wie lange dauert das und natürlich möchte man dann sagen
ja gut, die Performance ist natürlich besser. Wenn diese Zeit kleiner ist und es ist natürlich auch zusätzlich, kommen ja auch gute, also gute Sachen noch on top. Also wenn du sagst diese Zeit ist kürzer, dann hast du es ermöglicht dir auch einfach ein viel, viel schnelleres Feedback, also sagen wir mal dieser Unterschied zwischen ich habe eine Anforderung. Ne zum Beispiel sagst du jetzt ey, ich möchte jetzt gerne ne neue Podcast Folge haben.
So ne wie du gerade meintest und wir bringen diese Podcast Folge raus und es dauert aber n halbes Jahr so und wir machen vorher wir wir sagen OK das ist cool wir wir am besten wir machen ne ganze Serie über dieses Thema weil es so viel ist und dann nach einem nach einer also wir drehen alles ab nach einem halben Jahr. Bringen wir dann sozusagen alle Podcast folgen hintereinander raus und nach der ersten Podcast Folge kommt das Feedback. Ja, das ist ja ganz schön blöd
diese Reihe, ne, das wäre natürlich total bescheuert, weil. Wo wir beim Stichwort konstruktives Feedback sind. Okay ich wollte es ein bisschen abkürzen, aber ich verstehe. Sagen wir jetzt, was am Thema vorbei. Das klingt nicht ganz so drastisch. Ja, also sehr gut. Immer auf jeden Fall auch auf konstruktives Feedback achte.
Ja OK, das muss ich kurz sabbeln also, aber was ich beide ist ist, dass du natürlich, wenn du sozusagen diese diese Auslieferungszeit kurz hältst und sagst, OK, ich hab jetzt n ne ich ich, ich warte nicht so lange und warte vielleicht auch bevor ich den anderen, also alle anderen folgen in diesem Beispiel, was ich gerade angefangen hab, aufnehme.
Dann kann man einfach auch viel schneller, wenn man diese kurze Auslieferungszeit hat, kann man viel schneller dieses Feedback bekommen vom Kunden und am Ende halt auch besser die Richtung oder die Weichen stellen in welche Richtung es eigentlich gehen soll und das ist im Endeffekt natürlich ein sehr sehr wichtiger Punkt und wünschenswert und auch eine Motivation dahinter, wieso es auch von Vorteil ist diese.
Delivery Lead Time eben zu minimieren und die dadurch halt zum Beispiel dieses Maß für eine Performance zu erhöhen. Ja, und außerdem ist es für ein developer Team auch super spannend, sowas für sich selbst zu wissen. Also zum Beispiel auch, wie lange dauert es denn, wenn ich jetzt n neues Feature entwickel? Und irgendwie codeabänderung
mache oder neuen Code schreibe. Wie lange dauert es denn, bis der produktiv am Ende in der Software läuft, beispielsweise also dass er entwickelt wurde, integriert wurde und so weiter bis es dann halt wirklich übers Deployment hinten raus produktiv ist? Ist ja auch spannend, da quasi das zu analysieren, zu messen und vielleicht auch Flaschenhälse zu finden. Ja, auf jeden Fall. Das ist auch ein guter Punkt, vor allem gerade wenn du sagst, Flaschenhälse oder Fehler zu finden ist.
Gerade wenn du frisch etwas hast, woran du gearbeitet hast und es tritt eventuell ein Fehler auf. Und wie gesagt, man kommt ja leider nicht drumherum, dass einfach Fehler irgendwann mal unterlaufen, dann ist es ja einfach so, dass man auch viel, viel schneller in der Lage ist, weil es halt noch frisch ist, weil diese Auslieferungszeit nicht so lange her ist. Dass man diese Fehler auch schneller finden kann, und das ist natürlich auch ein sehr, sehr wichtiger Punkt an dieser Stelle.
Ne, also wenn du zum Beispiel keine Ahnung abends ins Bett gehst und überlegst, was du morgens gefrühstückt hast, dann wirst du das wahrscheinlich noch wissen, aber wenn du dir überlegst, was du vor einem Monat zum Frühstück gegessen hast, also ich weiß es nicht, ich weiß nicht, wie es dir geht, aber. Also bei mir ist es eigentlich relativ einfach, weil mein Frühstück meistens ein Kaffee ist. Also ich würde, wenn ich jetzt wetten müsste, würde ich sagen Kaffee.
Und am Wochenende, das vor einer vor, weiß ich eben im März, am Wochenende erstes Wochenende im März. Kam auch ein Kampf. Da wird wahrscheinlich was dazugegeben, aber das kann ich dir nicht sagen. Okay, hast du mich überzeugt, hast du mich überzeugt. Nein, aber auf jeden Fall. Ich glaube, man kann sich das vielleicht so ganz gut vorstellen, was ich interessant finde, ist und was sich auf jeden Fall auch jeder gerne mal fragen kann, Liebe zuhören und lieber zura, wenn du dir zum
Beispiel sagst okay, ich glaube. Also angenommen du arbeitest in irgendeinem Umfeld, wo zum Beispiel sowas auch eine Rolle
spielt. Wenn nicht, kannst du dich trotzdem einfach mal fragen und einfach mal überlegen oder mit Raten, was denn vielleicht zum Beispiel eine Zeit wäre, die gut wäre um zu sagen wie schnell ist denn sozusagen diese Zeit von vom Stellen der Anforderungen bis zum bis zur Auslieferung an den Kunden oder bis zur Umsetzung bis zur fertigen Umsetzung. Wie lange das zum Beispiel bei dir dauert oder wie lange es vielleicht dauern sollte.
Je nachdem also kannst dich das eine das andere Fragen, beides Fragen und da also als kleine kleiner Anreiz kann man ja zum Beispiel sagen, ist es gut, wenn es zum Beispiel kleiner als eine Stunde wäre, kleiner als ein Tag zwischen einem Tag und einer Woche, zwischen einer Woche und einem Monat oder vielleicht sogar ein bis 6 Monaten oder größer als 6 Monaten, ne, also das eine haben wir glaube ich schon indirekt schon mal ein bisschen gespoilert, dass es das nicht ist.
Aber man kann sich ja vielleicht mal so. Überlegen, bis wohin es noch an ein gutes Maß wäre. Ja. Können wir ja vielleicht dann noch mal auflösen das Ganze. Es ist natürlich auch immer sehr projektabhängig. Also es gibt, glaube ich. Grenzwerte, wo man sagen kann, da drüber ist nicht gut, das haben wir ja wie gesagt auch schon so ein bisschen angeteasert, aber trotzdem so gerade in dem kleinen Bereich ist es dann irgendwann auch projektabhängig glaube ich.
Also da gibt es halt keine, das hast du auch so schön gesagt. Also allgemeine Lösung. Das muss man dann halt so ein bisschen zuschneiden auf die Gegebenheiten, die man hat, beispielsweise wenn ich jetzt sage, ich möchte das innerhalb von einem Tag ausrollen, ich krieg die Anforderung morgens und nachmittags vorm Feierabend ist das erledigt, sozusagen, ist natürlich wünschenswert, aber ist dann halt auch immer die Frage, was für Anforderungen da beispielsweise reinkommen, wie
umfangreich die sind, ne? Aber ansonsten ist das finde ich n sehr cooles Gedankenspiel. Was ich auch gerne selbst mache. Man muss nur realistisch dabei bleiben, also weißt du, dass man halt wirklich auf seine eigenen Gegebenheiten guckt und dann sich überlegt, kriege ich das noch kleiner oder oder bin ich vielleicht viel zu groß, dann krieg ich es auf jeden Fall noch kleiner oder bin ich schon nah am Optimum, sag ich mal.
Ich würde das auf jeden. Fall n sehr spannendes Gedankenspiel. So. Ich würde das auf jeden Fall gerne am Ende einfach mal auflösen mit einem bestimmten Hintergrund auch. OK. Ich bin gespannt, was man natürlich dabei auch betrachten kann oder was da so n bisschen
Hand in Hand spielt. Ist dann halt auch diese Deployment Frequency, also quasi wie oft deploye ich denn Updates für meine Software, was ja auch so n bisschen daraus resultiert, quasi wie schnell ich zum Beispiel diese Feature wünsche umsetzen kann, aber man kann sich natürlich auch fragen, wie oft möchte ich dann wirklich ein Update rausgeben? Ja und also will ich jetzt zum Beispiel jede Änderung deployen
oder sag ich? Nein, meine Frequenz ist eher einmal die Woche, einmal Monat oder einmal im Quartal. Aufwärts gibt es ja alle Varianten, je nach Software. Wie siehst denn du das da oder wie wie betrachtest du das? Ja, ich finde das. Ich finde das auf jeden Fall auch interessant oder spannendes Thema, weil das kommt ja so ein bisschen aus dieser, aus dieser Batch size, ne, also sozusagen, wie groß ist ein Arbeitspaket, nenne ich das jetzt mal, was man
betrachten möchte. Ne und das eine ist natürlich, um das noch mal n bisschen abzugrenzen. Das eine ist, wenn ne Anforderung reinkommt, wie schnell schaffe ich es oder wie lange dauert es bis es ausgerollt ist. Es kann aber natürlich auch sein, dass du riesengroße Batch sizes hast und sagst, OK ich krieg das aber trotzdem hin, diesen diesen diesen großen Haufen an Arbeit innerhalb von kürzester Zeit zu Delivern geht
natürlich auch. Aber weil du meintest, es spielt meistens natürlich Hand in Hand, ist es natürlich von Vorteil zu sagen Okay, lass uns mal versuchen Aufgaben in kleine Teile zu zu zerstückeln und das ist aber schwierig zu messen, zu sagen, was ist denn eine kleine Aufgabe und genau aus diesem Grund hat man sich dann, wie soll man sagen, sozusagen als als Maß. Dann diese Deployment Frequency genommen um ja dann zu sagen okay wenn du kleine Teile hast
oder kleine Aufgabenpakete, dann hast du wahrscheinlich auch ein gutes Maß. Also wenn du sozusagen eine gute Deployment Frequency hast, hast du ein gutes Maß an deiner Batch size, weil du normalerweise das dann auch Hinkriegst. Quasi kleine Teile immer zu zu delivern sozusagen.
Nur hier muss ich auch noch mal anmerken, ich finde, das ist auch sehr projektspezifisch, weil beispielsweise wenn du jetzt das Ganze hinsichtlich einer Website im Frontend betrachtest, macht es natürlich Sinn, so Updates schnell rauszubringen, also dass du da oft deployst, weil das dann halt Änderungen an der Website sind, die wahrscheinlich auch wünschenswert sind, hoffentlich aber wenn ich jetzt zum Beispiel eine große Software habe, irgendeine Desktop application.
Sei es ja zum Beispiel unsere Geliebten Jet Brains IDES. Da würde ich jetzt so große Features schon sammeln und dann beispielsweise quartalsweise rausbringen, finde ich da halt auch gut, wie sie es machen, dass du es halt einfach ein bisschen bündelst. Es wird ja wahrscheinlich unter der Haube trotzdem integriert sein, aber es geht ja dann quasi um die Delivery am Ende und dass man sagt okay ich Bündel das
eher anstatt. Das also ich kann mir vorstellen, oder ich weiß nicht wie es bei dir ist, aber ich als Anwender würde ich jetzt jede Woche oder jeden Tag irgendwie n Update mit ganz kleinen Änderungen kriegen, dann würde ich es auch einfach nicht. Machen. Ja, dieses Update. Ja, ich weiß schon, also. Weil irgendwann denkt man sich so, na ja, es muss schon genug neue Funktionalität drin sein, dass es sich lohnt zu updaten.
Also es ist natürlich gleichzeitig wiederum die Frage, wenn ich jetzt zum Beispiel n Hotfix hab, weil n Bug drin ist, dann will ich es natürlich so schnell wie möglich ausrollen, da sollte dann wieder ne hohe Frequenz herrschen, da will ich ja nicht sagen, Leute haben wir erkannt, kein Problem. Im nächsten Quartal gibt es ne neue Version und da ist es gefixt. Wär natürlich absoluter worst case halt ne. Ja, es ist natürlich dann auch wieder die Frage, wie du auch, wie du auch meinst.
Wie gesagt, man muss es differenzieren. Man kann ja auch differenzieren, wo ist denn jetzt sozusagen der Kundenscope? Ne, du kannst ja theoretisch auch sagen, OK, der dein Kundenscope liegt wirklich beim Kunden, beim Endkunden oder zum Beispiel beim Stakeholder, das ist ja auch noch mal vielleicht dann so n genau kleiner kleine Möglichkeit das auf bestimmten Ebenen zu betrachten.
Aber was ich auch wieder interessant finde, die Frage dahinter, die man sich wieder stellen kann ist wie hoch oder wie gut ist es denn oder wo ist denn ein gutes Maß zu sagen, wie hoch sollte denn die Deployment Frequency sein. Man sagt mehrmals am Tag oder einmal die Stunde bis einmal am Tag so in dem in dem Bereich einmal am Tag bis einmal die Woche, einmal die Woche bis einmal Monat, einmal Monat bis alle 6 Monate oder sogar. Größer als 6 Monate, ne.
Also da kann man ja auch noch mal gucken. OK, einfach dieses Gedankenspiel noch mal bis zum Ende der Folge sich auch überlegen, vielleicht OK, was wäre denn ein gutes Maß, wo man sich vielleicht aufhalten sollte, ne um sozusagen von einer sehr guten Performance sprechen zu können. Ja OK, ich bin gespannt auf dich, aber dann lass uns doch mal zum Thema Stabilität kommen, weil es auch n riesen Punkt ist. Ja, wir haben ja jetzt wirklich so über Performancemetriken
gesprochen. Ja, wie schnell kann man was ausliefern et cetera, aber wichtig oder auch ja nicht nur wichtig, sehr wichtig, auch aus meiner Sicht ist natürlich, wie stabil läuft diese ganze Entwicklung und da gibt es ja zum Beispiel die. Mean time to recover, die ich immer sehr spannend finde, ist abgekürzt ein mtt r. Manche sagen auch Repair, also Recover oder Repair.
Das kann man sich glaube ich aussuchen und sollte die gleiche Metrik beschreiben und ich sag mal so, gerade in komplexeren Systemen, also wenn man ein größeres Projekt hat, eine umfangreiche Pipeline dahinter läuft, viele Automatisierungen, dann ist es irgendwann und gerade auch wenn viele. Developer daran arbeiten ist es einfach irgendwann Fakt, dass
Fehler passieren. Also es lässt sich einfach nicht vermeiden und ich finde es auch gut zu sagen vom Kopf her Fehler passieren, sie werden passieren und jetzt ist aber für uns wichtig, wie schnell erkennen wir diese Fehler und vor allem wie schnell können wir diese Fehler beheben, also quasi unser System sage ich mal gerät in einen Fehler zustand. Und wie lange brauchen wir, um wieder n grünes Licht zu haben? Also wie lange brauchen wir, um uns davon zu erholen?
Deswegen diese Recover und das find ich halt super spannend das Thema und auch auf jeden Fall wert sich das mal genau zu überlegen. Ja, definitiv. Also ich find es jetzt noch mal ganz interessant, zum Beispiel der der Punkt um so ne kleine Analogie zu bringen, ne, also angenommen du bist jetzt zum Beispiel zu Hause und. Dein Router hat einen Fehler, keine Ahnung. So und dann kannst du dir natürlich hinstellen.
Ich vermute mal, dass unterschiedliche Menschen unterschiedliche Ansätze haben, um das Ganze sozusagen wieder auf die Beine zu stellen, dass du sagst okay, ich habe wieder Internetzugriff zu Hause, wenn du zum Beispiel sagst okay, es gibt eine Person, die sich denkt, der Router geht nicht, was soll ich machen, da sind mir halt die Hände gebunden, ich warte einfach bis es wieder geht.
So, ja. Die nächste Person sagt, ich Ruf jetzt sofort beim Kundenservice an, sagt hier der Router geht irgendwie nicht, weiß nicht was ich machen soll und der Kundenservice sagt dann ja, dann probieren sie doch mal den Router an und wieder auszuschalten.
So es dauert geht vielleicht n bisschen schneller als die erste Variante und die dritte Variante wäre dann zum Beispiel ja gut, keine Ahnung, ich probier erst mal Router vom Strom zu nehmen, stecken wieder rein und hoffentlich funktioniert es nach 5 Minuten wieder so nach dem Motto ne also nur mal so vom vom vom Vergleich her, dass du sagst OK. Wie schnell kriegst du ein System, was du irgendwie brauchst? Zum Beispiel im Internet zu
Hause wieder auf die Beine? Also gut, das kann natürlich jetzt auch sein, dass du wirklich eine Störung hast oder so, aber was ich meine ist, das wäre jetzt sozusagen das Maß zu sagen, je kürzer die Zeit, um dein System wieder auf die Beine zu stellen, wieder hinzukriegen, desto besser. Weil das zeigt natürlich auch, dass im Fehlerfall klar ist, was zu tun ist. Also das spiegelt ja auch
sämtliche. Praktiken wieder, zum Beispiel Monitoring, Logging, alles, was da so auch hinsichtlich Def Ops ne Rolle spielt, wollen wir ja auch noch in unserer Def Ops Reihe behandeln. Also liebe zuhoher Liebe Zuhoher sei gespannt da drauf, weil das sind halt wichtige Mechanismen und Verfahren um diese Zeit zu minimieren, weil du hast halt 2 Möglichkeiten, entweder du ärgerst dich, dass alles rot ist, nichts geht mehr und rennst panisch im Kreis.
Oder du weißt genau, was in diesem Fall zu tun ist, weil du dich halt mit diesen Themen auseinandergesetzt hast und schaffst es halt, dich schnell zu erholen davon. Das heißt, dass die MTTR da halt gering ist. Und das ist ja auch absolut wünschenswert. Und das resultiert meistens daraus, dass klar ist, Fehler passieren. Das habe ich jetzt als Mindset und ich weiß, was zu tun ist. In dem Fall superwichtiger.es
geht. Ja, auch nicht nur, um Ausfälle zum Beispiel, sondern es geht ja auch um Leistungsbeeinträchtigungen. Also es kann ja durchaus sein, dass ein System zum Beispiel merklich langsamer wird und als normal. Und dann kann man sich natürlich auch fragen, OK, woran liegt es denn jetzt zum Beispiel ne? Ich finde so ein einfaches, aber gutes Beispiel ist zum Beispiel, wenn du sagst, du hast einen Server und du hast einen gewissen Traffic auf diesem Server.
Das heißt zum Beispiel 1000 Leute greifen im Normalfall immer auf diesen Server zu und dafür bist du gewappnet. Wenn jetzt aber aus unerfindlichen Gründen auf einmal 5000 Leute 10000 20000 Leute auf diesen Server zugreifen, dann kann es natürlich dazu kommen, dass es vielleicht auch irgendwie. Blacks gibt ne, das ist irgendwie, dass die Performance von dem Server die Antwort Performance sozusagen halt einfach nachlässt.
Und da ist es dann halt natürlich die Frage OK wie schnell erkennt man, dass es daran liegt, dass die Leistung beeinträchtigt wird und wie schnell kann man etwas dagegen tun, dass diese Leistung eben dann nicht mehr beeinträchtigt ist. So als Beispiel noch mal und ich finde, was ich auch super spannend finde und das will ich jetzt nur ganz kurz mal anschneiden, aber was?
Theoretisch. Gerade für sowas hilft um diese Mean Time to Recover auch zu trainieren, ist beispielsweise sind sogenannte Game Days, wo man wirklich in seinem Projektprodukt, wie man das jetzt auf wie man den Scope jetzt stecken möchte, einfach mal sagt. Man sorgt dafür, dass bestimmte Systeme ausfallen gezielt, ohne dass es die anderen aber merken und man sozusagen das in einem Kontrollierten. Umkreis oder einem kontrollierten Bereich diese Ausfälle erzeugt, um sozusagen n
Stresstest zu machen. Wie schnell es dauert, bis die Systeme alle wieder laufen oder die Fehler gefunden wurden. Ja. Das ist find. Ich n sehr cooler Punkt. Ja find ich auch n sehr cooles Konzept auch und ich hab das selber auch leider noch nie so erleben dürfen, aber ich würde das auf jeden Fall gerne mal. Gerne mal machen. Ich glaube zum Beispiel so einige große Firmen machen das ja auch. Ja, ich glaub Netflix ist da auch n gutes Beispiel die das ja
auch regelmäßig machen. Ich glaub also ich weiß jetzt nicht genau, man munkelt da so n bisschen wie es genau funktioniert, aber die haben ja glaub ich ihre Chaos Monkeys aber irgendwie so heißen die doch ne und zufällig an einem gewissen Zeitpunkt an einer zufälligen Stelle wird dann halt
quasi n Fehler ausgelöst und. Dadurch, dass quasi diese Awareness geschaffen ist in allen Teams, dass es sie treffen kann, sind sie halt auch immer vorbereitet da drauf und können halt in diesen Fällen schnell reagieren und das ist halt eigentlich ne sehr sehr coole Sache, weil das ist nämlich auch der Knackpunkt bei so einem Game Day.
Wenn du den groß ankündigst und jeder hat in seinem Kalender n Termin eingestellt bekommen, dass es dann und dann ist, dann wird es halt leider nicht viel bringen. Ach, das ist nicht schlimm. Heute ist es eh. Schlimm? Ja, ich hab eh Urlaub. Oder dann Urlaub machen. Ja, genau, genau es. Ist eh keiner da. Das ist ja. Die Recovery Time von 3 Wochen Urlaub oder so na gut okay, aber ich denke es sollte klar sein wie wichtig diese Metrik ist.
Bei allem Spaß hier. Ganz kurz, noch bevor wir jetzt vielleicht zur nächsten und letzten Metrik kommen, würde ich wieder gerne noch mal die Frage in den Raum werfen. Ne, was ist eine gute oder ein guter Wert für diese Metrik? Das kann man sich auch noch mal wieder Fragen, zum Beispiel? Als Rahmen kleiner, eine Stunde kleiner Tag oder irgendwie sowas zwischen dem Tag und einer Woche. Ich glaube alles was darüber geht ist auf jeden Fall schon mal. Das sollten wir auf jeden Fall
ausschließen. Also die die 3 Wochen Jahresurlaub sind jetzt schon ausgeschlossen, oder was? Ja das. Geht nicht. Leider, leider. Okay. Ausgeschlossen. Ja gut, ich bin gespannt, was du
dazu noch sagst. Ich würd mal auf die letzte Metrik eingehen, ne wir haben die schon wieder ne fortgeschrittene Zeit hier, fabi müssen wir jetzt auch mal ranhalten jetzt los geht es und zwar die Change Fail rate find ich halt auch sehr spannend im Prinzip wie oft ja wie wie kann man sagen also wie hoch ist denn der Prozentsatz von Änderungen die Fehler verursachen also die schieflaufen. So kann man das glaub ich am einfachsten ausdrücken.
Also angenommen, alle Entwickler entwickeln die Software weiter, die Änderungen werden eingepflegt, alles läuft super und so jedes x te mal passiert aber n Fehler in diesem ganzen Prozess und daraus entsteht ja dann im Endeffekt dann die Change Fail Rate und da kann man ja dann gucken wie hoch ist die denn, weil es wäre ja jetzt ich glaube das ist logisch, aber um es mal direkt zu sagen, wenn jede zweite. Oder jede zweite Änderung zu Riesenfehlern führt, dann ist
das nicht gut. Das ist ja so. Wie was man als Kind früher gelernt hat, weißt du so, als Kind kriegst du irgendwann so als Baby oder so. Kleinkind kriegst du, wenn man so n Glas hingestellt und was erstmal schmeißt du es um, dann kriegst du erstmal ja ihr das du du du böse, böse und so weiter ne bis du dann irgendwann lernst. OK dieses Glas ne muss man nehmen darf man nicht ausschütten und muss man dann auch zum Mund führen und trinken.
So und mittlerweile würde ich sagen, ist die Change Failrate, das heißt jedes Mal wenn du dir was zum Trinken eingießt und das trinkst ist eigentlich sehr sehr gut im Normalfall im Normalfall ja. Das stimmt. Also da wurde genug Gefailed sozusagen, dass das denn funktioniert hat, aber ja, im Prinzip kann man sich das daran auch ganz gut vorstellen. Ja, ja, ich will die mehr weg damit okay. Aber also das ist im Endeffekt genau der Punkt, also dass man diesen Prozentsatz hat.
Also ich Committee irgendwas, das wird sozusagen online gestellt, nenne ich es jetzt einfach mal so und dann also verfügbar gemacht, diese Änderung und wie viele oder wie oft zum Beispiel auf 100 Changes, wie viele Fehler resultieren daraus, es geht ja jetzt auch nicht darum, dass man sagt, jetzt macht man einen Change und. Und du merkst dann irgendwann ja vor einem Jahr oder so ist noch
ein Fehler drin. Also es geht dann wirklich um die Deploys, jetzt eine Änderung und und diese Änderung erzeugt die einen Fehler sozusagen indirekt resultierend auf diesem diesem, also diesem Change, ja. Genau da kann man. Sich natürlich auch wieder Fragen, ja. Wo ist denn vielleicht eine Gute, ein guter Prozentsatz? In welchem Bereich sollte man sich da aufhalten, um auch gut dabei zu sein und das ganze auch realistisch? Betrachtet genau, weil sonst. Wäre die Antwort einfach?
0. Das stimmt, das stimmt. Aber wir können ja mal kurz zusammenfassen. Also wenn man jetzt sagt, okay, wir wollen gerne gucken, dass
wir vielleicht. Maße oder Metriken nutzen um die Performance also wie gut ist deine Software, wie gut entwickelst du deine Software und auch natürlich auch in puncto wie in welchem Tempo entwickelst du deine Software, kann man natürlich mit reinziehen, sollte man auch nicht ganz außer 8 lassen, haben wir jetzt einmal die Metriken Delivery Lead Time. Deployment Frequency im Bereich des Tempos ne. Also da würde ich auch zum Beispiel gucken, wenn man jetzt zum Beispiel Def und Ops, also
def Ops was du vorhin angesprochen hattest, Trend, dass man sagt, OK, das liegt schon eher im Scope von Development. Und dann natürlich das Maß der Stabilität, also Punkt 3 und 4 ist dann die Mttr, die Mean Time to Recover und die Change Failrate und das sind zum Beispiel auch wieder 2 Punkte beziehungsweise diese Master Stabilität fällt dann wenn man es wieder im Bereich DEV OPS betrachtet eher unter Operations. Ja, also zum größeren. Teil sagen wir es mal so.
Ja, auf jeden Fall. Also nicht komplett, aber wie gesagt, Dev Ops in der Gesamtheit. Ist ja dann sozusagen eh zusammen. Also das wie gesagt diese Reihe, die gibt es ja auch noch, die wird auch. Noch fortgeführt, da freu ich mich auch schon auf die nächsten Folgen und ich glaub das ist auch n gutes Stichwort, weil ich würd jetzt sagen, dass wir an der Stelle jetzt hier das Thema Metriken ausführlich besprochen haben. Die Auflösung fehlt noch.
Nee, die machen wir dann in der. Nächsten Folge so richtig als Cliffhanger. Nein, hau sie raus los, komm also was auf jeden Fall. Was ich dazu sagen muss?
Es gibt ein Buch, das heißt Accelerate, das können wir auch gerne in den Shownotes verlinken, um einfach mal, falls es jemand interessiert, und da werden auch diese Metriken untersucht, auch über mehrere Jahre an verschiedenen Companies, und dann wurde herauskristallisiert, was zum Beispiel High Performer ausmachen, also Unternehmen, die wirklich als High Performer gelten, also wirklich on Top State of the Art, in der im Bereich der Entwicklung sind.
Und weil du, weil du ja gesagt hattest, jetzt, man muss es natürlich realistisch betrachten, auf jeden Fall gebe ich dir recht, nur gibt es trotzdem ein Maß, wenn man zum Beispiel mitspielen möchte und sich vielleicht sagt, Okay, wo stehen wir gerade, dass man sagt, okay, wenn man zu den High Performern zählen möchte, dann ist es schon interessant, dass zum Beispiel die Delivery Lead Time irgendwo zwischen einer Stunde und einem Tag liegt, also schon auf jeden Fall kleiner als
ein Tag. Dass man die Deployment Frequency irgendwo im Bereich von einer Stunde und im Tag hat und die Mean Time to Recover sollte kleiner eine Stunde sein oder vielleicht kleiner als ein Tag, auf jeden Fall kleiner als ein Tag, besser kleiner als eine Stunde und die Change Failrate liegt bei High Performer Unternehmen ungefähr bei 0 bis 15% also nur, dass man zumindest mal. Bild hat von wo müsste man hin, wenn man ein High Performer in der Welt sein möchte? Okay.
Spannende Punkte also. Beim Paar gehe ich mit, beim Paar finde ich finde ich auch krass, dass das so ist. Ich selbst habe das Buch nicht gelesen, ich muss mir anscheinend auch mal angucken, wenn du es empfiehlst. Genau deswegen werden wir es auch mal verlinken. Ich bin auch gespannt, ansonsten würde ich sagen.
Liebe, zuhören, Liebe zuhören falls du Fragen zu dem Thema hast, dann meld dich doch auch gerne bei uns, dann können wir da gerne drauf eingehen oder wenn du Feedback dazu hast, zu der Folge vielleicht Metriken anders betrachtest, als wir es tun oder auch Ergänzung hast immer raus damit, wir würden uns sehr sehr freuen. Die Mail dazu findest du in den Shownotes, genauso wie auch alle anderen Links zu unseren Plattformen und auch ein Link, wo du uns unterstützen kannst.
Falls dir diesen Podcast gefällt, das würde uns sehr freuen, das hilft uns auch, unsere Arbeit hier stetig zu verbessern und fortzuführen oder empfiehl einfach den Podcast weiter, das wäre ebenfalls fantastisch und ansonsten würde ich sagen, hören wir uns alle bei der nächsten Folge wieder, bis dahin eine gute Zeit und bis zum nächsten Mal deine Coaling Buddies gemeinsam besser.