Latest / Coding Buddies | Tech & Dev-Mindset / 3 Metriken mit denen du nicht deine Produktivität messen solltest

Transcript

3 Metriken mit denen du nicht deine Produktivität messen solltest · Coding Buddies | Tech & Dev-Mindset

0:00
Um wieviel ist denn die Software besser geworden?
0:04
Und anhand dieser Frage merkt man ja schon so was.
0:09
Was was ist die Einheit von der Zahl, die du mir hören willst?
0:13
Sowas? Sie ist 2 besser Coding Body
0:17
deinem Podcast wohnt um Softwareentwicklung und
0:20
aktueller Technews herzlich willkommen.
0:34
Herzlich Willkommen zur neuen Folge des Cody Buddies Podcast.
0:37
Schön, dass du wieder eingeschaltet hast, dass wir uns
0:39
hier wieder versammelt haben. Ich bin natürlich wieder dabei,
0:41
Tino und auch der fantastische Fabi, den ich jetzt begrüßen
0:44
mag. Fabi, Was geht ab, wie geht es
0:47
dir? Hallöchen.
0:49
Halle schön, ich find. Es immer schön, wenn man
0:52
angekündigt wird irgendwie. Ich weiß auch nicht.
0:55
Fühlt sich so an, als wenn man so reinkommt.
0:56
So reingelaufen. Kommt so.
0:58
Ja, ich komm doch. Mal reingelaufen.
0:59
Ja, stimmt. Klatschig Klatsch ich immer so
1:02
mit der Wand ab. Ja, genau so virtuell.
1:06
Und da ist er wieder, und da geht er auch wieder.
1:11
Ja gut, geht es mir ganz gut. Soweit so gut, es ist n bisschen
1:15
kühler geworden, das find ich ja mal super ne.
1:19
Einfach mal nicht schwitzen. Ja, ist auch mal was Schönes.
1:22
Ne, war ja teilweise n sehr warmer Sommer, obwohl.
1:26
Ich es krass finde, weil eigentlich hab ich das Gefühl es
1:28
hat die ganze Zeit nur geregnet und dann war es noch mal richtig
1:30
heiß. Aber.
1:32
So n Wechsel immer ne entweder Regen oder super warm.
1:34
Ja, also immer noch n normaler deutscher Sommer, so wie man ihn
1:37
kennt würd ich. Sagen ja, wie man ihn kennt und
1:40
wie man ihn liebt. Aber jetzt kommt wieder die
1:42
schöne muckelige Winterzeit sei ich schon Herbst erstmal Herbst
1:46
ne, aber ich. Mag den Herbst überspringen wir
1:48
ja scheinbar direkt, das ist ja super kalt geworden.
1:53
Ja, so viel dazu. Aber ich würd mal sagen, starten
1:58
wir in die Folge rein. Ja, ja, ich hab auch ein Thema
2:01
mitgebracht, was krass oder Thema Pass auf was das war haben
2:07
wir da schon mal vor einer Weile nicht im Podcast.
2:10
Aber so mal drüber gesprochen und haben uns gesagt okay das
2:13
kann man doch mal im Podcast beleuchten und zwar das Thema.
2:18
Metriken in der Softwareentwicklung aber.
2:22
Bezüglich der Produktivität innerhalb eines Entwicklungs
2:27
Teams oder sagen wir mal die produktive eines Entwicklers,
2:30
also Einzahl Mehrzahl so. Und ja, was gibt es da so für
2:34
Methoden? Wie kann man das ganze Messen,
2:37
macht es Sinn das zu messen? Das würd ich halt gern mal so n
2:41
bisschen kritisch hinterfragen mit dir und mal.
2:45
Gucken ja, auf welchen Nenner wir da so kommen oder wie wir
2:48
beide das so betrachten. Weil es gibt natürlich, sag ich
2:52
mal gerade denn von vom Manager, also von der Management Ebene
2:57
den Wunsch gewisse Metriken zu haben um einfach zu überwachen.
3:02
Wie produktiv ist denn mein Team?
3:04
Was Produkt XY entwickelt zurzeit können.
3:09
Wir, das messproduktivität ich find überwachen ist finde ich
3:12
klingt so mies. Ja, aber also Monitoren im Sinne
3:16
von Messen, sagen wir mal. Ne, verstehe ich.
3:19
Genau und im Prinzip deshalb, weil man ja sehen möchte.
3:26
Im besten Fall werden wir immer produktiver oder halt frühzeitig
3:28
erkennen zu können, dass sie Produktivität nachlässt, dass
3:31
man halt Gegenmaßnahmen einleiten kann.
3:33
Deswegen sind solche. Metriken ja an sich erstmal vom
3:39
Grundgedanken nicht schlecht, sag ich mal.
3:42
Die Frage ist halt immer, wie gut funktioniert sowas und da
3:45
gibt es natürlich verschiedene Ansätze und die würde ich jetzt
3:48
gerne mal mit dir. Beleuchten ja auf jeden Fall.
3:51
Das ist auch echt ein spannendes Thema, gerade im Bereich der
3:54
Softwareentwickler. Also man versucht ja immer
3:55
irgendwie eine gewisse Art von Produktivität oder Performance
3:59
zu messen, das war ja irgendwie gefühlt schon immer so macht.
4:02
Ja, auch Sinn. Man möchte ja auch irgendwie,
4:05
man hat ja auch einen Anspruch an sich selber, also ich weiß
4:07
nicht, es fängt ja schon finde ich so zu Hause an, wenn du
4:10
sagst, ich möchte jetzt keine Ahnung Geschirr spülen, ich weiß
4:13
nicht wie es dir geht, aber ich versuche halt auch irgendwie,
4:15
dass das schnell geht oder versucht es halt zu optimieren
4:19
oder so und deswegen das ist ja immer so auch ein Anspruch an
4:23
sich selber und ob du jetzt als Einzelperson das machst oder in
4:26
einem Team oder als Unternehmen, das ist ja finde ich.
4:29
Irgendwie eine ganz normale Sache und gerade so bei also.
4:35
Früher auch so bei also früher heute auch noch ne, aber da kann
4:38
man das konnte man das ja mal super messen, wie zum Beispiel
4:41
bei Fabriken finde ich, wenn du sagst, ey, wir produzieren
4:45
heute. Weiß ich nicht. 1000 teile von
4:48
irgendwas. In einer Fabrik ne, und jetzt
4:51
sagt man zum Beispiel ja, hier kommt, dann kommt jemand und
4:55
sagt, wir haben neue Maschinen und diese Maschinen, die
4:57
produzieren viel schneller und viel genauer so und am Ende
5:01
kannst du ja dann zum Beispiel bei so einer Fabrik dich
5:04
hinstellen und sagen Okay, sagen wir mal, letztes Quartal hatten
5:07
wir oder letzten Monat meinte Ich, glaube ich hatten wir 1000
5:10
Teile produziert und diesen Monat sind es mit den neuen
5:13
Maschinen zum Beispiel 5000 teile, das heißt, Wir haben
5:15
unsere Produktivität um 5, also 5 mal, also das fünffache
5:19
erhöht. Voll cool.
5:21
Und dann kannst du vielleicht noch gucken, dass du sagst, OK,
5:23
keine Ahnung, diese Teile, die wir hergestellt haben, sind
5:25
tatsächlich auch besser verarbeitet und halten unter
5:28
irgendwelchen Stresstests das Doppelte oder was auch immer ja
5:32
bisschen kaputt gehen, so kannst du perfekt messen, nur total
5:35
coole Sache und das blöde an der ganzen Geschichte ist ja, dass
5:40
es bei Softwareentwicklung gar nicht so einfach ist.
5:42
Weil wenn du jetzt zum Beispiel sagst okay, du hast irgendwie
5:44
ein Produkt. Irgendwie ein Stück Software und
5:48
dieses Stück Software hatte letzten Monat irgendwie eine
5:52
bestimmte bestimmten Umfang und nächsten Monat hat es auch einen
5:55
bestimmten Umfang, aber du weißt ja nicht immer hundertprozentig
5:59
okay, aber welchen also? Was ist denn jetzt, welcher
6:05
Umfang ist dazu gekommen? Also das ist ja nicht immer nur
6:07
das, was du siehst. Das, was hinzugekommen ist.
6:09
Und das ist ja dann sozusagen nicht so einfach, das Ganze zu
6:12
messen, wenn du nicht genau siehst oder also wie in so einer
6:16
Fabrik an Stückzahlen ey, das ist jetzt Bär geworden und
6:20
deswegen ist halt natürlich die Frage okay wie kann man das zum
6:22
Beispiel in der Software Entwicklung an irgendwie diese
6:25
Performance eben messen. Und das Problem ist, dass dann
6:29
halt oft willkürlich irgendwas gemessen wurde.
6:32
Oder versucht wurde zu messen. Du hast da ja auch schon ganz
6:36
guten Punkt so indirekt angesprochen und zwar?
6:41
Ja, also in der Softwareentwicklung über n
6:43
gewissen Zeitraum, den man jetzt beispielsweise mit seiner
6:46
Messung betrachten möchte. Ist es mehr geworden, hast du ja
6:50
gesagt, das heißt, gehen wir mal davon aus, es sind mehr Zeilen
6:54
Code geworden, Mhm. Das heißt, die Software wächst,
6:58
es kommt irgendwie ne Art Funktionalität rein, weil ich
7:02
gehe jetzt mal davon aus, dass wenn mehr Zeilen Code drin sind,
7:04
auch mehr Funktionalität in dem Produkt steckt, am Ende also in
7:08
der Software. Und deswegen hat man ja immer
7:12
überlegt, so im Laufe der Zeit gibt es ja so wie gesagt,
7:15
verschiedene Metriken und so der erste.
7:19
Irgendwo ja auch logischer Ansatz ist halt genau das zu
7:23
messen, wie umfangreich denn diese Software ist.
7:26
Beispielsweise und da sind. Wir dann wieder beim Thema.
7:31
Wieviel Codezeilen sind denn? Dazu gekommen und deswegen ist
7:36
gab es halt oder gibt es immer noch.
7:38
Ich weiß nicht wer das einsetzt, aber gibt es halt grundsätzlich
7:42
die. Metrik ist noch nicht
7:43
ausgestorben. Genau, sie ist noch nicht
7:45
ausgestorben, aber die Metrik Lines of Code quasi zum Messen,
7:49
die dazugekommen sind, sprich als Entwickler schreibe ich so
7:53
und so viele Zeilen Code am Tag, das heißt ich kann messen.
7:59
Wie viele Zeilen kommen denn über einen gewissen Zeitraum
8:02
durch die jeweiligen Entwickler dazu und kann dann vergleichen?
8:07
Nimmt diese Zahl zu, schreiben sie immer mehr Code, schreiben
8:10
sie weniger Code oder ist es relativ konstant?
8:14
Das bringt natürlich. Probleme mit sich definitiv.
8:19
Also ich bin auch gar kein Fan von dieser Metrik, aber ich
8:22
glaube, es geht auch vielen so, weil man relativ schnell merkt,
8:26
dass Lines of Code ja nicht die gleiche, also nicht jede Zeile
8:31
Code, die dazu kommt, hat ja den gleichen Outcome am Ende also
8:37
output. So gesehen ist gleich, ich habe
8:40
eine Zeile Code mehr. Aber wenn wir jetzt mal den
8:43
Mehrwert betrachten, dann kann der halt sehr, sehr stark
8:46
variieren, von Zeile zu Zeile. Das heißt, ich kann 10 Zeilen
8:51
Code geschrieben haben, an einem Tag, hab damit aber n
8:54
signifikantes Problem beispielsweise gelöst oder
8:57
vielleicht n Bug behoben. Na.
8:59
Oder ich schreib 10 Zeilen Code und das hat eigentlich keinen
9:04
großen Mehrwert gebracht, weil es vielleicht einfach nur ne
9:07
kleine Änderung in der Oberfläche war oder was auch
9:10
immer, aber halt vielleicht so ne Verschönerungsgeschichte war
9:14
in der Software. Wenn sie jetzt ne Oberfläche hat
9:16
und das andere hat aber ein signifikat signifikanten
9:21
Sicherheits eine Sicherheitslücke geschlossen
9:23
oder so, dann dann. Hat das ja extrem
9:26
unterschiedlichen Wert diese Zeilen, da kann man sie ja
9:30
einfach nicht vergleichen. Ich finde da merkt man ja
9:32
relativ schnell, dass das eigentlich an sich keine gute
9:35
Metrik. Ist na vor allem, stell dir mal
9:37
vor, wenn du wenn du sagst Ey Entwickler werden dafür ich nenn
9:41
s jetzt mal belohnt wenn Sie mehr Zeilen Code schreiben, dann
9:45
kannst du dich als Entwickler oder Entwicklerin hinstellen und
9:47
sagen ja okay ich kann diese Lösung die erforderlich ist kann
9:52
ich mit 10 Zeilen Code hinkriegen, aber ich werde ja.
9:55
Quasi sozusagen belohnt dafür, wenn ich mehr schreibe.
9:59
Also mache ich quasi eher die aufgeblähte Lösung, weil dann
10:03
sozusagen ich ja im Endeffekt besser dastehe und ne höhere
10:07
produktiver gelte, produktiver gelte, weil du ja zum Beispiel
10:11
dann auch bei keine Ahnung irgendwelchen Git changes oder
10:13
sonst was siehst. Okay Oh guck mal wie viele
10:15
Zeilencode hinzugekommen sind, und das ist natürlich eine
10:19
absolute Schwachstellung. Genauso kann man sich hinstellen
10:22
und sagen, naja. Welcher Entwickler oder welche
10:24
Entwicklerin mag es denn nicht, wenn es eine Lösung gibt mit 10
10:28
Zeilen, anstatt eine Lösung von 100 oder 1000 Zeilen?
10:30
Welche würde man bevorzugen? Und da, das ist ein extrem guter
10:34
Punkt, das ist auch genau dieser zweite Kritikpunkt, den auf den
10:38
ich mit dir kommen wollte. Schön, dass du es angesprochen
10:40
hast, weil. So gesehen sorgt.
10:46
Das ja dafür, dass vielleicht Entwickler sich denken, oh, ich
10:48
muss mehr zeigen, Code schreiben, diesen dann eventuell
10:52
ist jetzt wie gesagt kein Vorteil oder so, aber
10:55
vielleicht. Unüberlegter machen und mehr
10:58
Code bedeutet auch mehr Wartung. Das heißt, diese ganze Software
11:01
bläht sich auf, wird schwieriger zu warten sein und auch
11:06
schwieriger zu Refact an sein, beispielsweise weil der Code
11:09
sich halt einfach so. Extrem aufbläht, wenn man nach
11:13
dieser Metrik bewertet wird und vielleicht im Hinterkopf hat, Oh
11:17
verdammt, ich muss noch jetzt mal gehen wir mal davon aus, du
11:21
musst sogar irgendwie ne gewisse Metrik schaffen, weil du dann
11:24
als effektiv oder oder als produktiv gilt und denkst dir
11:28
so, oh, ich muss heute noch 30. Zeilen hochschreiben.
11:30
Wieso? Stell dir mal vor.
11:33
Da merkt man ja schon, dass diese Metrik eigentlich gar
11:35
keine Aussagekraft. Hat ich hab meine Aufgabe
11:37
bereits erfüllt, aber ich muss noch 30 Zeilen Code scheiden.
11:42
Das wäre echt totaler Quatsch. Aber könnte man sich da nicht
11:44
hinstellen, jetzt mal eine produktive.
11:48
Eine provokative Frage kann man sich jetzt nicht hinstellen und
11:51
sagen, ja gut, dann könnte man ja ein Maß nehmen, wo man sagt,
11:55
das Produkt in möglichst wenigen Zeilen Code, ist das dann ein
11:58
besseres Maß, also nehmen wir das mal umgekehrt so, ja.
12:05
Ja gut, wenn du es richtig umdrehst, dann mache ich den
12:07
ganzen Tag nichts und bin der produktivste von allem, weil ich
12:09
nichts geschrieben habe. Aber ja, na ja, natürlich.
12:15
Wenn du jetzt komplett ins Gegenteil gehst und sagst, ich
12:18
muss so wenig Code wie möglich schreiben um meine Lösung zu
12:21
finden, dann neigt man ja wieder dazu.
12:25
Unglaublich. Schwierigen Code im Sinne der
12:29
Verständlichkeit zu schreiben, weil nicht jeder Code, der sehr,
12:33
also nicht jede Funktionalität, die sehr mit sehr wenig Code
12:37
gelöst wurde, ist am Ende gut umgesetzt, weil n Entwickler B
12:41
der das nicht entwickelt hat, n Kollege beispielsweise sich das
12:45
irgendwann anguckt und sich denkt, was passiert in diesem
12:47
One Liner. Diese typischen One liner, ich
12:49
schreibe die ganze Funktionalität in einer Zeile,
12:51
weil ich, weil ich einfach Bock hab das so komplett komplex da
12:55
abzubilden und. Alle anderen brauchen dann ne
12:58
halbe Stunde um diese eine Zeile zu verstehen.
13:01
Überspitzt gesagt, aber genau in diese Gefahr läuft man ja rein.
13:05
Es ist ja nicht immer die beste Lösung, manchmal sind ein paar
13:08
Zeilen mehr einfach super fördernd für die
13:11
Verständlichkeit, dann halt auch ne.
13:14
Ja, auf jeden Fall. Und da finde ich, ist es halt
13:16
einfach. Da merkt man irgendwie, dass es
13:17
so Lines of Code an sich, es ist halt ein trade off mit wieviel
13:21
Zeilen Code man sozusagen seine Lösung für ein bestimmtes
13:24
Problem. Oder für eine bestimmte Aufgabe
13:26
umsetzt. Dass man sagt, OK, zu viel ist
13:29
natürlich quatsch, warum sollte ich mehr nehmen als benötigt,
13:31
wird aber immer noch irgendwie so viel, dass es auch noch
13:35
trotzdem weiterhin verständlich bleibt und das also es wird
13:38
relativ schnell klar, finde ich, wenn man einfach mal n bisschen
13:41
darüber nachdenkt, dass Lions of Code vielleicht nicht das die
13:45
beste Möglichkeit sind und ich finde, du hattest auch von von
13:48
Mehrwert vorhin gesprochen und das ist oft auch ein Problem,
13:52
wenn sich wenn sich auf die Produktivität von der von der
13:55
Performance oder von einem Team wird, das halt eben diese dieser
14:01
Output ne, also das Ergebnis was geliefert wird, zum Beispiel 100
14:05
Zeilen Code einfach. Mehr beachtet wird als das
14:10
eigentliche Outcome, also dieser dieser Outcome, der Mehrwert,
14:14
der geschaffen wird, weil wenn du zum Beispiel sagst, Ey und
14:16
ich find, das ist ja schon, du kannst.
14:20
Es damit super darlegen, weil wenn du sagst.
14:23
Ergibt also dieser Output ne wenn du sagst 1000 Zeilen Code
14:26
output ne super krass kannst du auf dem Blatt Papier sehen.
14:29
Ey das sind super viele Zeilen voll gut, da hat jemand
14:32
produktiv gearbeitet oder man sagt zum Beispiel Na ja gut aber
14:35
ne kleinere Lösung wäre halt auch schon schön okay 1000
14:38
Zeilen Code ist jetzt auf einmal eine bisschen unrealistisch,
14:41
aber egal wo man dann aber hinterher merkt, ja okay weiß
14:45
ich nicht, ist zwar weniger Code aber der Mehrwert ist bei der
14:49
einen Seite nicht geschaffen, weil du halt einfach viel zu
14:52
viel Overhead hast und auf der anderen.
14:54
Hast du auch keinen Mehrwert geschaffen, weil keiner mehr
14:56
diesen Code versteht? So, und das ist halt so n
15:00
kleines Problem sag ich jetzt mal oder einer der großen
15:03
Probleme auch von den nachfolgenden.
15:06
Performancekriterien, die wir ja auch noch n bisschen besprechen
15:09
wollen. Dass sozusagen mehr auf dieses
15:11
Ergebnis, auf diesen Output als auf den Mehrwert, diesen
15:14
Outcome, den der Fokus gelegt wird.
15:17
Ja, ja, was halt einfach auch daran liegt, dass du diesen
15:20
Output quasi ja auch besser messen kannst als den Outcome.
15:26
Also wie nehmen wir noch mal kurz dieses Lines of Code
15:29
Beispiel, ich kann natürlich viel schneller auch
15:32
automatisiert feststellen, wieviel Zeilen Code sind denn
15:35
jetzt mit der letzten Änderung in die Software gekommen?
15:39
Das lässt sich ja viel leichter ermitteln.
15:41
Als wieviel Mehrwert wurde geschaffen?
15:43
Genau. Wieviel also mal vereinfacht
15:46
gesagt, um wieviel ist denn die Software besser geworden?
15:51
Und anhand dieser Frage merkt man ja schon so was.
15:57
Was ist die Einheit von der Zahl, die du mir hören möchtest?
16:00
Sowas? Sie ist 2 besser.
16:04
Und das ist halt, da merkt man einfach die Schwäche von dieser
16:07
Metrik. Und deswegen, glaube ich, sind
16:09
da auch relativ viele schnell von weggegangen und es wurden
16:14
sich halt andere Metriken auch in der Zeit überlegt und die
16:16
sind auf jeden Fall schon. Ne Ecke besser haben aber auch
16:21
ihre vor und Nachteile und da würd ich gerne mal auf eine
16:24
Eingehen, im Prinzip auf die. Die Geschwindigkeit in der
16:31
Entwicklung wird ja oft belostet, also velocity.
16:34
Ja genau, die Metrik wird oft Velocity genannt und da hat man
16:38
sich dann halt überlegt, wie kann man denn das Messen, wie
16:42
schnell mein Team entwickelt und ein ein Ansatz ist gerade ja,
16:47
wenn man in der agilen Welt nach Scrum beispielsweise arbeitet
16:52
oder allgemein Kanban nach Tickets halt.
16:56
In der agilen Welt und ich, ich habe Tickets, die müssen
16:58
erledigt werden und. Die sind ja, sagen wir mal, in
17:04
üblichen geschätzt worden. Das heißt, man ermittelt
17:06
ungefähr, wie lange dauert das, und dann erledige ich sie
17:10
beispielsweise im Sprint, oder halt, ja, muss jetzt nicht nach
17:13
Sprint sein in einer gewissen Zeit, und diese Zeit, die ich da
17:16
nehme für meine Messung, kann ich ja gucken, wieviel habe ich
17:22
denn erledigt, also beispielsweise, wir sagen, heute
17:26
ist der Start so ein klassischer Sprint und wir machen.
17:29
Jetzt 2 Wochen und wir nehmen jetzt haben im Team jetzt 10
17:34
Tickets ja beispielsweise und im Schnitt haben die sagen wir 5
17:40
Punkte, dann sind das ja 50 maximal erreichbar.
17:45
Punkte in den 2 Wochen wenn ich sage, das ist jetzt mein
17:48
Zeitraum und ich gucke, wie viele Punkte habe ich denn am
17:51
Ende auch wirklich erreicht, sprich hab ich alle Tickets
17:55
abgeschlossen, hab ich ja logischerweise alle 50 Punkte
17:58
erreicht, das heißt nach meinem Maß habe ich genau meine
18:02
Geschwindigkeit erreicht, die ich möchte.
18:04
Ich bin schnell, weil ich schaffe das alles abzuarbeiten.
18:07
Beziehungsweise wenn du sagst, du hast zum Beispiel keine
18:09
Ahnung. In einer in einem Sprint zum
18:11
Beispiel, sagen wir mal einfach Sprint 1.
18:13
Hast du vielleicht 30 Punkte abgearbeitet?
18:16
Sprint 2 hast du auf einmal 40 geschafft und Sprint genau. 3
18:19
hast du dann. Irgendwie 45 geschafft.
18:21
Das heißt deine Geschwindigkeit, deine Velocity von Punkten, die
18:24
du sozusagen in deinem Zeitraum abgearbeitet hast, dieses
18:27
gestiegen, also bist du schneller geworden.
18:29
So genau. Das wäre nicht der Punkt, was
18:32
ich jetzt sagen wollte ist genau was du meintest, weil wenn ich
18:35
jetzt im nächsten Sprint auf einmal nur noch 20 Punkte mache,
18:37
dann bin ich ja quasi halbiert, mehr als halbiert in meiner
18:41
Geschwindigkeit und das wäre dann quasi so, wollte man die
18:44
Metrik dann verwenden zusammen warum sind wir denn jetzt so
18:47
langsam geworden, was ist passiert oder in deinem Beispiel
18:50
super? Wir werden immer schneller,
18:54
fantastisch und das klingt erstmal logisch, dass man sagt,
18:59
ja, OK, ja gut, ich Messe halt wieviel oder wie schnell schaffe
19:03
ich es meine Tickets abzuarbeiten, ja.
19:06
Klingt ja erstmal schon viel besser als diese Lines of Code.
19:10
Metric hat aber halt auch Probleme und zwar jeder der in
19:14
der agilen Welt mal gearbeitet hat oder vielleicht aktuell tut.
19:18
Liebe zuhören, lieber Zuhörer, falls es bei dir so ist, wirst
19:20
du uns wahrscheinlich. Sehr wahrscheinlich zustimmen.
19:22
Jetzt ist ja genau diese Schätzung, wie lange ein Ticket
19:27
dauert und man dann halt quasi das mit Punkten verseht.
19:32
Ein unfassbar schwieriger Punkt und ein sehr subjektiver Punkt,
19:37
was bei dieser Metrik ja noch viel entscheidender ist, oder?
19:39
Da haben wir. Übrigens auch mal eine Podcast
19:41
Folge drüber gemacht. Falls dich das ein bisschen
19:43
genauer interessiert. Liebe zuhören, lieber Zuhörer,
19:45
damit das noch mal genauestens erläutert und warum es auch
19:49
subjektiv und schwierig ist. Aber ich stimme dir total zu,
19:53
Tino weil im Endeffekt ist es ja um das mal kurz
19:57
zusammenzufassen, also wenn jetzt sagen wir mal, wir beide
20:00
stellen uns irgendwo hin und sagen okay, was meinst du?
20:02
Weit ist zum Beispiel der nächste Turm irgendwo da hinten
20:05
entfernt. Dann werden wir wahrscheinlich
20:08
weder das genau gleiche schätzen, also die genau gleiche
20:12
Maßeinheit, die genau also nicht genau die gleiche meta Einheit
20:16
schätzen sozusagen. Also ich sag dann.
20:17
Grundsätzlich in Fuß schätze und ich in Meter.
20:21
Ja, Instinkte fußmäßig Nein. Aber weißt du was ich meine?
20:26
Also ich sag dann zum Beispiel keine Ahnung, es sind 50 Meter,
20:28
du sagst es sind vielleicht 30 Meter oder was auch immer und am
20:32
Ende unterscheidet sich unsere Schätzung aber auch sozusagen.
20:37
Die unsere Schätzung wird sich auch von der Realität sehr
20:39
wahrscheinlich unterscheiden und damit hast du natürlich auf
20:43
jeden Fall schon mal ne Varianz drin, die dir definitiv.
20:47
Die die, die sich, die sich definitiv mit einschleichen,
20:50
wird in in diese sag ich mal, in diese Varianz deiner
20:55
Geschwindigkeit von sag ich mal Sprint zu Sprint, Iteration zu
20:58
Iteration und was ich auch sehr sehr kritisch dabei finde ist,
21:04
dass wenn wir das jetzt mal weiter denken und sagen okay die
21:08
Entwickler und Entwicklerinnen schätzen diese Tickets, also es
21:12
wird irgendeine Story um eine Aufgabe genommen und.
21:16
Man setzt sich zusammen und schätzt das und sagt Okay das
21:18
ist jetzt vielleicht eine 1, eine 2, eine 3, je nachdem, nach
21:20
welchem Maß man schätzt oder t Shirts heißt und.
21:25
Dann wird hinterher gesagt, okay, ihr wart vielleicht, wenn
21:28
ihr zum Management sagt, ihr Wart und Produktion produktiv.
21:31
So was wäre denn der nächste Schritt, man könnte sich ja
21:34
hinstellen und sagen okay, dann sagen wir beim nächsten Mal,
21:38
wenn zum Beispiel vielleicht schätzt, dass dein Ticket eine 1
21:41
wäre, sagst du okay es ist eine 3.
21:43
So also bläst du im Endeffekt künftig.
21:48
Ich das ganze auf, das heißt ne du schätzt einfach mehr ein als
21:52
es überhaupt in Wirklichkeit einnimmt diese Aufgabe um dann
21:56
hinterher dich feiern zu lassen, dass du so viel abgearbeitet
22:00
hast. Und das ist halt natürlich
22:03
wieder ne sehr, sehr schwierige Sache.
22:08
Ja. Gerade wenn es ne sorry.
22:10
Ja nee, es ist halt auch wie gesagt sehr subjektiv und wenn
22:15
man aber sagt, man will jetzt projektweit diese Metrik
22:20
verwenden, also über mehrere Teams hinweg, dann kannst du
22:24
diesen subjektiven Faktor einfach nicht mehr einfangen,
22:26
weil wie du schon meintest, die einen denken sich so, oh, bevor
22:31
ich hier als unproduktiv gelte. Bewerte ich die Tickets lieber
22:35
als komplexer oder zeitaufwendiger, je nachdem, ob
22:38
man jetzt nach Komplexität oder wirklich nach Zeit schätzt?
22:41
Ja, machen ja auch viele. Dass man denn sagt, nee, ich
22:45
gehe lieber den sicheren Weg und gelte ja auch automatisch als
22:48
produktiver, wenn ich es höher ansetze und es dann schaffe.
22:52
Ist ja besser als zu sagen, Ach naja, es wird schon, ich bin da
22:55
ziemlich optimistisch und nachher machst du schließt du
22:58
keine Tickets ab und giltst halt als super unproduktiv, obwohl du
23:01
quasi gleich performt hast als im letzten Sprint hast dich halt
23:04
nur verschätzt im Prinzip. Ja, und das ist halt die Gefahr.
23:08
Und andererseits kannst du halt auch andere Teams schlecht
23:13
dastehen lassen, wenn du halt deine subjektive Einschätzung
23:17
komplett abweichend ist zum zu den anderen Teams und du halt
23:21
sage ich mal der High Performer in Anführungsstrichen bist der
23:25
50 Punkte umgesetzt hat, was aber nur 2 Tickets waren oder
23:29
wie auch immer, ist jetzt nur eine reine Zahl und die anderen
23:32
sind im Schnitt bei 3035 punkten beispielsweise.
23:37
Und ja, gelten ja dann als weniger produktiv, obwohl sie
23:42
vielleicht einfach realistischer geschätzt haben.
23:45
Ja, und dazu kommt ja auch noch, dass wenn du unterschiedliche
23:48
Teams hast, die vielleicht in einem großen Bereich
23:52
zusammenarbeiten, aber zum Beispiel irgendwie das
23:54
Management will, diese Teams vergleichen.
23:57
Du weißt ja gar, also das Management hat meistens wenig
23:59
wissen darüber, in welchem Kontext jemand.
24:02
Unterwegs ist so, und jedes Team hat sehr wahrscheinlich, also
24:06
ich weiß nicht das. Da wirst du mir wahrscheinlich
24:08
zustimmen. Aber wenn man in
24:10
unterschiedlichen Teams gearbeitet hat, wird es auch
24:12
wird auch unterschiedlich geschätzt und.
24:15
Du kannst es halt im Worst Case gar nicht richtig vergleichen.
24:19
Du kannst nicht sagen, dieses Team schätzt zum Beispiel nach
24:22
Zeit dieses Team, schätzt nach Komplexität, schätzt nach einer
24:25
anderen Skala, was auch immer und das Ganze dann hinterher
24:28
wieder zu auf einen Nenner zu bringen, ist natürlich
24:31
schwierig. Klar kann sich hinstellen und
24:32
sagen, jeder macht das jetzt gleich, aber nichtsdestotrotz
24:35
hast du immer noch eine Unsicherheit drin, der Kontext
24:38
ist ein anderer, wie gesagt, ein Output ist ja nicht gleich
24:40
outcome, also wenn jetzt zum Beispiel jemand sagt, EY, wir
24:42
haben jetzt dieses Ticket und dieses Ticket ist wirklich sehr,
24:45
sehr wichtig. Dann ist es vielleicht auch gar
24:47
nicht so interessant, wie lange es dauert, wenn wir jetzt in
24:51
Zeiteinheiten sind. Aber der Impact, der hinterher
24:54
entsteht. Für das der ist ein.
24:56
Absolvierendes Tickets, ne, das ist halt wichtig.
24:58
Genau und das sind halt so. Punkte, die die, die passen
25:03
einfach nicht zusammen. Und das Problem bei Velocity
25:06
ist, weil wenn man jetzt kann man sich natürlich fragen ja gut
25:08
velocity ja wozu ist es denn da? Also diese ganze Stories
25:13
schätzen und einplanen. Das ist n Planungstool.
25:16
Damit kann zu Kapazitäten planen.
25:18
Damit kann man sagen OK. Es gibt Leute, die zum Beispiel
25:23
das Team, das also das, das kann jetzt diese Kapazität an Arbeit
25:28
aufnehmen, ne, aber? Das zu missbrauchen sag ich
25:33
jetzt mal um ne Produktivität zu messen.
25:36
Das ist halt schwierig und das kann halt auch im Endeffekt,
25:39
wenn jetzt zum Beispiel ei das eine Team diese Punkte aufbläht
25:42
und dadurch sozusagen vermeintlich auf n Blattpapier
25:44
schneller ist als das andere. Auch wieder dazu führen, dass
25:47
natürlich jetzt die Zusammenarbeit zwischen den
25:50
Teams halt stark gefährdet wird. Ne?
25:52
Ja. So, und das willst du auch nicht
25:54
haben. Genau.
25:56
Und jetzt kann man natürlich auch sagen, Na ja, gut, dann.
26:00
Gehst du halt dich zum Beispiel über die Punkte, dass du sagst,
26:03
OK, ich will, also ich angenommen du bist jetzt
26:06
manager, du verstehst diesen Punkt von dir gerade und sagst
26:09
ja OK, dann sind Punkte, kann man manipulieren, dann sagen wir
26:12
OK wieviel Tickets fertig sind am Ende.
26:14
Ne, dann können Sie ja sagen, das sind 30 Punkte, aber am Ende
26:17
zählt wieviel Tickets fertig sind.
26:19
Aber genau das kannst du wiederum ja auch manipulieren,
26:22
indem du denn einfach deine Aufgaben so fein granular
26:24
machst, dass du sagst keine Ahnung, ich mach ne kleine
26:28
Änderung in der Software ist ein Ticket, also versteh mich nicht
26:31
falsch, fein geschnittene Tickets sind Gold wert, weil
26:34
umso besser kannst du sie dann beispielsweise schätzen oder
26:37
überhaupt sind sie dann erst greifbar, aber.
26:40
Wenn du das jetzt wieder in Metrik verpackst.
26:44
Könnte man, könnte man auch wieder übertreiben und sagen,
26:45
wir machen es richtig, richtig fein.
26:47
Granulare Tickets und ich schließe 5 am Tag ab, überspitzt
26:52
gesagt und dann ist das ganze auch wieder hinfällig und das
26:55
ist halt das Problem bei der Velocity, was ich sehe, dass du
26:59
halt immer einen Weg findest um künstlich deine Produktivität zu
27:04
steigern, ohne am Ende diesen Outcome zu steigern, weil wie
27:09
gesagt es ist. Ich finde das ist auch ein gutes
27:11
Beispiel, es ist ja, wenn es eine Wichtige.
27:14
Qualität ist spielt es keine Rolle, ob sie nach 2 oder 3
27:17
Wochen da ist. Ja ne, ist ja nicht, dass der
27:20
Manager sagt, du bist jetzt nicht fertig, du bist fast
27:22
fertig ist egal. Ich will das jetzt nicht mehr.
27:24
Es ist zwar wirklich, wirklich wichtig, dass diese
27:27
Funktionalität in die Software kommt, aber jetzt.
27:29
Nee, du hattest 2 Wochen. Weißt du, das spielt ja am Ende
27:32
dann wirklich keine Rolle mehr, weil der Impact einfach groß ist
27:36
für die Software, dass das dann reinkommt.
27:38
Ja, ja, definitiv. Gebe ich dir recht, aber wenn du
27:42
jetzt weiter guckst und sagst ne, weil ich jetzt das schon mal
27:44
n bisschen angeschnitten hatte und man sagt jetzt Na gut, Pass
27:46
auf, man nimmt das vielleicht als Planung ne und sagt dann
27:49
vielleicht ne, dann könnt ihr ja vielleicht jetzt so n bisschen
27:51
weiter spinnen das Ganze und sagen Na ja pass auf.
27:55
Wir haben jetzt unsere unsere Stories und wir haben jetzt
27:59
erfahrungsgemäß wissen wir, dass so oder also ich hab das glaub
28:04
ich auch schon erlebt, dass man sagt OK ne pro.
28:08
Entwickler oder Entwicklerin kann sozusagen können weiß ich
28:12
nicht. Sagen wir mal 5 Stories in der
28:14
Woche erledigt werden ne nur mal als Beispiel so, dann sag es
28:18
dann gehst du nicht mehr dahin und sagst OK wieviel können wir
28:21
abarbeiten, sondern man sagt OK. Ein Entwickler, eine
28:25
Entwicklerin ist in der Lage, Roundabout 5 Stories storypunkte
28:30
sozusagen ne, also diese geschätzten Punkte abzuarbeiten.
28:32
Dann kann man sich ja hinstellen und sagen, ja gut, OK, das ist
28:35
ja so ne Art von Utilisation oder Auslastung, dass du sagst
28:38
ne. Wieviel, wenn wenn ich das weiß
28:41
wieviel Punkte, also wieviel Tickets kann ich denn dann zum
28:44
Beispiel einer Person zuordnen? Ne könnte ich ja zum Beispiel
28:47
sagen, ja gut, wir haben jetzt 2 Tickets, wenn du von 2 Wochen
28:51
redest 2 Tickets a 5 storypunkte oder?
28:54
4 Tickets mit 2 und 3 Punkten pro Woche oder was auch immer
28:58
ne. Also kannst du ja dann zu.
28:59
Ich muss ja. Ich muss kurz mit rechnen.
29:04
Und das heißt, du kannst im Endeffekt ja ne gewisse
29:07
Auslastung für eine Person irgendwie ne.
29:10
Also wenn du jetzt sagst okay Pass auf jede Person ist 100%
29:14
ausgelastet, hast du vielleicht eine größere Produktivität als
29:17
wenn du sagst jede Person macht nix.
29:22
Also jetzt war wirklich die absoluten Extreme so also also.
29:26
Im Prinzip würde wahrscheinlich. Jeder zustimmen und sagen ja
29:29
klar, wenn die Leute was tun, na dann ist besser, als wenn die
29:31
Leute nichts tun. So und je mehr sie tun, desto
29:33
besser. Okay verstehe ich, verstehe ich
29:36
das heißt, die Metrik dahinter ist zu versuchen, die Auslastung
29:42
möglichst hochzuhalten, und das spricht für eine hohe
29:45
Produktivität, weil den Leuten böse.
29:49
Gesagt, nicht langweilig wird. Genau das ist die Metrik dann am
29:52
Ende. Das wäre die Metrik Utilization
29:54
oder Auslastung eine. Ja, auch oft genutzt wird oder
29:58
auch gerne genutzt wird, gerade vom Management, weil das
30:00
Management dann das ist. Ja, das ist ja, das kommt ja
30:03
alles immer so n bisschen, sag ich mal aus dieser Analogie von
30:06
der Fabrik, ne, es ist ja nur gut, wenn zum Beispiel ne
30:09
Maschine. Arbeitet so und wenn du sagst,
30:15
OK, du hast jetzt zum Beispiel ein Fließband und eine Maschine,
30:18
arbeitet und gibt dann das Teil. Keine Ahnung was auch immer,
30:22
gibt es an die nächste Maschine weiter und du hast 5 Maschinen.
30:26
Ne, und du sagst jetzt OK jetzt wird n Teil hergestellt, erst
30:29
Maschine 1, dann gibt es das Teil Maschine 2 weiter Maschine
30:31
3 Maschinen 4 Maschine 5 Maschine 5 stellst fertig und
30:34
dann ist es fertiggestellt und dann wird das nächste Teil
30:36
angefangen. Da könnte man sich ja relativ
30:38
schnell hinstellen und sagen na ja aber.
30:40
Könnte man nicht sagen, dass 5 Teile immer gleichzeitig
30:43
bearbeitet werden, anstatt dass du sagst ein Teil immer nur bis
30:47
alles fertig ist? Ne würde ja erst mal Sinn machen
30:49
und genauso kannst du ja von dieser Auslastung her auch
30:52
ausgehen und sagen ja komm hier, das können ja auch Entwickler
30:54
und entwicklerinnen können ja auch genau eine hohe Auslastung
30:57
fahren. Also das ist im Prinzip kein
30:58
Leerlauf. Gibt jetzt in der Fabrik, dass
31:01
halt ständig jeder Teilschritt aktiv ist, sozusagen.
31:06
Genauso wie im Team einfach jeder Entwickler dauerhaft aktiv
31:10
ist, sozusagen und immer ein Ticket vor der Nase hat, sagen
31:13
wir mal so. Und das klingt ja erstmal auf
31:17
dem Papier nach einer guten Metrik zu sagen, naja, wenn alle
31:21
bei 100% sind, dann ist es meine maximale Produktivität, fertig.
31:27
Also jetzt kannst du sagen okay, jetzt gehen wir noch hier in
31:31
absoluten Panic Mode und schalten auf 110 Produktivität
31:34
hoch und 110%. Aber genau da ist ja auch die
31:38
Frage, wie lange werden die Entwickler das Mitmachen, weil
31:42
wenn du immer auf Anschlag läuft und da ist auch die Analyse.
31:46
Zu Maschinen oder auch so Fabriken nicht schlecht.
31:50
Du kannst ja nicht immer am Anschlag laufen, weil wie lange
31:54
soll das gut gehen, das kannst du vielleicht für ne gewisse
31:58
Zeit machen, aber ich bin mir ziemlich sicher, dass.
32:02
Sich ne negative Stimmung einstellen wird, wenn die
32:06
Entwickler quasi konstant das Gefühl haben am Limit zu sein.
32:12
Ja, im roten Bereich sozusagen. Ja, genau das, also wenn du halt
32:17
wirklich immer im roten Bereich drehst sozusagen und sagst, nee,
32:21
komm bisschen noch noch 2 Wochen los, bisschen bisschen geht
32:24
noch, dann ist halt wirklich die Frage, wie lange kann man das
32:27
durchhalten. Und da gibt es ja auch
32:31
verschiedene Studien dazu, sage ich mal, die sagen, OK, es ist
32:35
eher schädlich, so eine hohe Auslastung zu haben, gerade in
32:39
Hinsicht der Softwareentwicklung, und das
32:42
kann ich mir halt gut vorstellen, weil ich, wie ich ja
32:44
gerade schon meinte, wenn ich mir vorstelle, das ganze Team
32:47
ist immer im roten Bereich, dann wird es irgendwann.
32:52
Zu beispielsweise mentalen Problemen kommen, zu
32:54
Motivationsproblemen und dann wird diese Produktivität ganz
32:58
schnell in die falsche Richtung kippen.
32:59
Ja, vor allem das witzige an der ganzen Geschichte ist ja auch,
33:02
dass gerade bei wenn du jetzt mal wirklich diese Analogie zu
33:04
einem Fließband nimmst, dann hast du ja eigentlich, sage ich
33:08
jetzt mal. Im Normalfall eher das nicht,
33:12
dass es kommt ja nicht auf einmal neuer Schritt rein, ne,
33:15
dass du zum Beispiel sagst, so, ja jetzt müssen wir aber also ne
33:18
irgendwie so Störfaktoren ne, also kann natürlich schon mal
33:21
sein, dass du irgendwie sagst, ne Maschine fällt aus oder so
33:24
klar gut gehen wir mal davon ab, sondern dass du sagst irgendwie
33:27
ungeplante Arbeit in einem Fließband hast du eher weniger
33:30
ungeplante Arbeit, weil es ist alles durchgetaktet, aber bei
33:33
einer Softwareentwicklung in einem Team.
33:36
In dem Produktteam, was auch immer und.
33:39
Gerne mal. Also wenn jemand jetzt dagegen
33:42
widerspricht, Liebe Zuhörerin, lieber Zuhörer, dann immer raus
33:44
damit. Aber ich glaube, ich möge jetzt
33:47
sprechen oder für immer schweigen.
33:49
Genau. Aber Fakt ist es, dass ja
33:52
wahrscheinlich. Also ich hoffe, dass das jeder
33:54
kennt. Weil also ich kenn es auf jeden
33:55
Fall zur genüge, du hast immer irgendwie ungeplante Arbeit, die
33:59
irgendwie mal wieder reinkommt und wenn du sagst, OK, du hast
34:03
bis zu 100% ausgelassen und jetzt kommt aber jemand und
34:06
sagt, das müssten wir wirklich gerade noch mal einschieben, das
34:09
ist gerade wirklich noch mal wichtig, wie kannst du Sachen
34:13
einschieben, wenn du bei 100% ausgelastet bist?
34:16
Oder vielleicht 110 das funktioniert ja nicht.
34:18
Richtig. So, das kann man sich auch ganz
34:20
gut vorstellen. Wie gut sind denn deine Jonglier
34:23
Künste? Meine.
34:26
Ja, also ich kann mit 3. Bällen kann ich jonglieren.
34:29
Ja, 3 kriegst du hin und jetzt stell dir vor, das sind sind das
34:32
deine 100%. Meine 120% sind das.
34:40
OK, aber. Stellen wir uns mal vor, du, du
34:41
machst das souverän. Das ist genau 3 Bälle ne das das
34:45
schaffst du und jetzt stell ich mich hin und sag aha ich hab
34:49
hier noch einen und wirf den einfach so zu dir rüber und auf
34:53
einmal hast du 4 und musst weiter jonglieren.
34:55
Wie lange wird das gut gehen und das ist ja genauso wenn du quasi
34:58
am Anschlag bist und da einfach keine Zeit und keine keine
35:02
Kapazität mehr über ist. Für diesen vierten Ball und dann
35:06
kommt trotzdem irgendwann derjenige der dir diesen vierten
35:08
Ball zuwirft und am Ende wird. Ich folgendes passieren, dass du
35:12
alle Bälle fallen lässt und. 3. Bälle fallen lassen, ein Ball
35:16
werf ich dir gegen Kopf und dann renn ich weg.
35:18
Ja OK, gut, dann, das heißt, die Produktivität geht erst mal so
35:23
auf, was 25 nee 20% 25% runter und dann auf 0, weil du den
35:28
letzten Ball noch in meine Richtung wirst.
35:31
Kommt drauf an, was man damit jetzt als produktiv versteht.
35:34
Also das. Liegt ja am Auge.
35:35
Des Betrachters. Nein, ich weiß was du.
35:38
Meinst Plot bist ich hab auch 3 Fälle und mit 4 komme ich dann
35:41
auch nicht klar und dann passiert bei mir genau das
35:43
gleiche. Hast du schöne Kettenreaktion im
35:45
Team? Aber ich finde das, das stellt
35:48
es halt einfach sinnbildlich. Ich hoffe man konnte sich das
35:51
jetzt vorstellen, einfach perfekt da, weil es wird nicht
35:54
funktionieren dann und du hast es so schön gesagt, weil es ist
35:58
unvermeidlich, dass irgendein Randthema reinkommt und wenn du
36:02
dann keine Kapazität dafür hast, wird dir das Halt auf die Füße
36:06
fallen am Ende. Also ich meine, selbst wenn du
36:08
von einem Wasserfallmodell aus gehst, wo ihr eigentlich alles
36:11
durchgeplant ist, von A bis z, wo du wirklich sagst das geht,
36:14
hier geht's los, da ist es zu Ende und fertig und dann ist die
36:17
Sache. Dieses Modell wurde ja nicht
36:19
umsonst gechallend, weil du halt einfach ja genau diesen Effekt
36:22
hast, dass du sagst, ey, es kommen neue Sachen rein
36:27
ungeplante Sachen, es ist es kommen Störfaktoren, irgendwas,
36:31
irgendwas muss noch mal angepackt werden oder wie auch
36:34
immer und ja, da kommt man relativ schnell dazu, dass das
36:39
halt einfach auch nicht das richtige Maß ist oder nicht das
36:42
optimale Maß ist. Aber im Endeffekt können wir ja
36:46
zusammenfassen, wenn wir jetzt sagen, Okay Produktivität
36:49
messen. Wir haben jetzt 3 Sachen
36:51
besprochen, die jetzt nicht so optimal offensichtlich laufen,
36:54
also zum einen zum einen, aber die Lines of Code, als zweites
36:58
noch die Velocity, die Geschwindigkeit und als drittes
37:01
die Utilisation, die Auslastung und wie wir gerade einmal
37:06
ordentlich dargelegt haben, sind das jetzt nicht die besten
37:08
Metriken, um irgendwie eine Performance zu messen, eine
37:11
Performance des Teams oder auch eine Einzelperson.
37:14
Genau. Weil sie sich ja einfach ich
37:17
finde, das kann man eigentlich bei allen sagen, sich halt zu
37:20
sehr auf diesen Output konzentrieren und nicht auf den
37:24
Mehrwert, also den Output. Bei der oder während der
37:28
Entwicklung. Genau, ja, aber in dem Sinne
37:31
würde ich sagen, das sind auf jeden Fall jetzt erstmal 3
37:34
Metriken, die sich nicht unbedingt eignen.
37:36
Und jetzt können wir mal. Trotzdem beliebt sind und oft
37:40
stimmt gut. Dass das noch mal sagst, das
37:42
wird nämlich trotzdem noch zu oft, wahrscheinlich auch einfach
37:45
angewendet. Jetzt können wir einfach mal
37:47
einen kleinen Cliffhanger machen und sagen okay, wir haben jetzt
37:50
schon, glaube ich, genug gequatscht hier rüber und
37:53
betrachten einfach mal und gehen einfach mal in der nächsten oder
37:57
in einer der nächsten folgen, ich weiß es noch nicht genau,
38:00
wann wir das besprechen, aber da werden wir uns dann mal angucken
38:04
wie. Kann man es denn überhaupt
38:06
besser machen? Was sind denn Metriken, die
38:08
wirklich dazu führen, dass man vielleicht sinnvoll messen kann,
38:13
wie produktiv sozusagen ein Team war, anhand der Software anhand
38:17
des Ziels, was verfolgt wird? Genau weil da gab es ja über die
38:21
Zeit auch Metriken, die es wirklich besser gemacht haben.
38:25
Und ich finde es gut, dass wir es in der extra Folge machen,
38:27
weil wir sind ja jetzt auch schon fortgeschritten in der
38:29
Zeit und. Haben wir das cool getrennt?
38:31
Gefällt mir gut, machen wir, so Fabi, gute Idee.
38:34
Super und in dem Sinne würde ich sagen, können wir die Folge auch
38:38
abschließen. Jo und ich hoffe, liebe Zuhörer,
38:43
lieber Zuhörer, das hier die Folge gut gefallen hat und.
38:46
Wenn du dich auch bei manchen dieser Metriken wiederfindest im
38:49
Sinne von, es wird danach gemessen oder du kennst das, was
38:53
wir gerade geschildert haben, dann schreib uns gerne mal.
38:55
Oder du sagst vielleicht auch, nee, Moment, Moment, Moment, wir
38:58
benutzen die und die Metrik und die funktioniert super dann.
39:02
Das wissen, weil das ist natürlich einfach n sehr, sehr
39:04
interessantes Thema auch und wenn du was hast.
39:08
Dann schreib uns sehr, sehr gerne über unsere Podcast Mail.
39:11
Die findest du in den Shownotes. Genauso kannst du auch wenn du
39:13
sagst, Ey Coding Buddy ist ja Coding Buddies Podcast, das ist
39:16
ne richtig coole Sache, die gefällt mir richtig super, ich
39:19
bin total begeistert, dann gib uns auch gerne Feedback oder
39:24
hinterlasse ne kleine Spende kannst du auch alles über die
39:26
Podcast Mail machen in den Shownotes oder den Link zur
39:28
Spende findest du auch in den Shownotes und ansonsten?
39:32
Empfehle den Podcast gerne weiter und in dem Sinne würde
39:35
ich sagen, verabschieden wir uns wieder von dir.
39:39
Wir hören uns hoffentlich in der nächsten Folge wieder deine
39:41
Coding Buddies. Gemeinsam besser.
39:52
Was?