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.