Latest / Coding Buddies | Tech & Dev-Mindset / Wie du Produktivität richtig misst!

Transcript

Wie du Produktivität richtig misst! · Coding Buddies | Tech & Dev-Mindset

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